1. Introduction

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

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

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

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

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

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

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

2. Types d'appareils

Bien que le projet Android Open Source ait été utilisé dans l'implémentation de divers types d'appareils et facteurs de forme, 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 à s'étendre à une plus grande variété de types d'appareils, comme décrit dans cette section.

Un appareil portable Android désigne une implémentation d'appareil Android généralement utilisée en le tenant dans la main (lecteurs MP3, téléphones et tablettes, par exemple). Implémentations pour les appareils portables Android:

• L'appareil DOIT être équipé d'un écran tactile.
• DOIT disposer d'une source d'alimentation permettant la mobilité, telle qu'une batterie.

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

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

Montre Android fait référence à une implémentation d'appareil Android destinée à être portée sur le corps, éventuellement sur le poignet, et sur:

• DOIT disposer d'un écran dont la longueur en diagonale 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.

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

• DOIT disposer d'un écran dont la diagonale physique est supérieure ou égale à 6 pouces.
• DOIT déclarer la fonctionnalité android.hardware.type.automotive.
• DOIT prendre en charge uiMode = UI_MODE_TYPE_CAR.
• Les implémentations Android Automotive DOIVENT prendre en charge toutes les API publiques de l'espace de noms android.car.*.

Toutes les implémentations d'appareils Android qui ne correspondent à aucun des types d'appareils ci-dessus DOIVENT toujours respecter l'ensemble des exigences du présent document pour être compatibles avec Android 7.0, sauf si ces exigences sont explicitement décrites afin de ne s'appliquer qu'à un type d'appareil Android spécifique indiqué ci-dessus.

2.1 Configurations des appareils

Voici un récapitulatif des principales différences de configuration matérielle par type d'appareil. (Les cellules vides correspondent à « MAY »). Toutes les configurations ne sont pas traitées dans ce tableau. consultez les sections dédiées au matériel pour en savoir plus.

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

3. Logiciel

3.1. Compatibilité des API gérées

L'environnement d'exécution géré de bytecode Dalvik est le principal véhicule pour les applications Android. L'interface de programmation d'application (API, Application Programming Interface) Android désigne l'ensemble des interfaces de la plate-forme Android exposées aux applications exécutées dans l'environnement d'exécution géré. 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 ou toute API décorée du marqueur "@SystemApi" dans le code source Android en amont.

Les implémentations d'appareils DOIVENT prendre en charge et préserver l'ensemble des classes, méthodes et éléments associés marqués par l'annotation TestApi (@TestApi).

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

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

3.1.1. Extensions Android

Android permet d'étendre les API gérées tout en conservant la même version du niveau d'API. Les implémentations d'appareils Android DOIVENT précharger l'implémentation AOSP de la bibliothèque partagée ExtShared et des services ExtServices avec des versions supérieures ou égales aux versions minimales autorisées pour chaque niveau d'API. Par exemple, pour les implémentations d'appareils Android 7.0, l'exécution du niveau d'API 24 DOIT inclure au moins la version 1.

3.2. Compatibilité avec les API soft

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

3.2.1. Autorisations

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

3.2.2. Paramètres de compilation

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

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

Compatibilité des intents

Intents d'application principaux

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

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

Les implémentations sur les appareils DOIVENT inclure les principales applications Android, le cas échéant, ou un composant implémentant les mêmes schémas d'intent définis par tous les composants Activité ou Service de ces applications Android principales exposées à d'autres applications, implicitement ou explicitement via l'attribut android:exported.

Résolution d'intent

Android étant 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 d'Android en amont le permet par défaut. les responsables de la mise en œuvre de l'appareil NE DOIVENT PAS accorder de privilèges spéciaux aux applications système utiliser ces modèles d'intent ou empêcher les applications tierces de s'associer à ces modèles et d'en prendre le contrôle. Cette interdiction inclut, sans s'y limiter, la désactivation de l'interface utilisateur du sélecteur, qui permet à l'utilisateur de choisir parmi plusieurs applications qui gèrent toutes le même schéma d'intent.

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

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

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

• DOIT essayer de valider les filtres d'intent en suivant les étapes de validation définies dans la spécification Digital Asset Links, telles qu'elles sont implémentées par le gestionnaire de packages dans le projet Android Open Source en amont.
• DOIT essayer la validation des filtres d'intent lors de l'installation de l'application et définir tous les filtres d'intent UIR correctement validés en tant que gestionnaires d'application par défaut pour leurs UIR.
• PEUT définir des filtres d'intent d'URI spécifiques en tant que gestionnaires d'application par défaut pour leurs URI, s'ils sont validés, mais que la validation d'autres filtres d'URI candidats échoue. Si une implémentation d'un appareil effectue cette opération, elle DOIT fournir à l'utilisateur des remplacements de format par URI appropriés dans le menu des paramètres.
• DOIT fournir à l'utilisateur des commandes de liens vers une application par application dans les paramètres, comme suit: <ph type="x-smartling-placeholder">
  </ph>
  • L'utilisateur DOIT pouvoir ignorer de manière globale le comportement par défaut des liens d'application pour qu'une application soit toujours ouverte, toujours ouverte, ou toujours ouverte, ce qui doit s'appliquer de la même manière à tous les filtres d'intent d'URI des candidats.
  • L'utilisateur DOIT pouvoir afficher la liste des filtres d'intent d'URI candidats.
  • L'implémentation de l'appareil PEUT donner à l'utilisateur la possibilité d'ignorer des filtres d'intent d'URI candidats spécifiques qui ont été validés avec succès, par filtre d'intent.
  • 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 vérification, tandis que d'autres peuvent échouer.

Espaces de noms des intents

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

Intents de diffusion

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

Paramètres d'application par défaut

Android inclut des paramètres permettant aux utilisateurs de sélectionner facilement leurs applications par défaut, par exemple l'écran d'accueil ou les SMS. Le cas échéant, les implémentations d'appareils DOIVENT fournir un menu de paramètres similaire et être compatibles avec le schéma de filtre d'intent et les méthodes d'API décrits dans la documentation du SDK, comme ci-dessous.

Implémentations pour les appareils:

• DOIT respecter l'intent android.settings.HOME_SETTINGS afin d'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.
• DOIT fournir un menu de paramètres qui appelle l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT pour afficher une boîte de dialogue permettant de modifier l'application SMS par défaut, si l'implémentation de l'appareil indique android.hardware.telephony.
• DOIT respecter l'intent android.settings.NFC_PAYMENT_SETTINGS à afficher un menu de paramètres d'application par défaut pour le paiement sans contact, si l'implémentation de l'appareil indique android.hardware.nfc.hce.
• DOIT respecter l'intent android.telecom.action.CHANGE_DEFAULT_DIALER pour afficher une boîte de dialogue permettant à l'utilisateur de modifier l'application Téléphone par défaut, si l'implémentation de l'appareil signale android.hardware.telephony .

3.3. Compatibilité avec les API natives

La compatibilité avec le code natif est complexe. C'est pourquoi les responsables de la mise en œuvre d'appareils sont VIVEMENT RECOMMANDÉS d'utiliser les implémentations des bibliothèques listées ci-dessous à partir du projet Android Open Source en amont.

3.3.1. Interfaces binaires d'application

Le bytecode Dalvik géré peut appeler le code natif fourni dans le fichier .apk de l'application sous la forme d'un fichier ELF .so compilé pour l'architecture matérielle appropriée de l'appareil. Comme le code natif dépend fortement de la technologie de processeur sous-jacente, Android définit un certain nombre d'interfaces binaires d'application (ABI) dans le NDK Android. 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 ci-dessous.

Si une implémentation d'appareil est compatible avec une ABI Android, elle:

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

Notez que les futures versions du NDK Android pourront prendre en charge d'autres ABI. Si l'implémentation d'un appareil n'est pas compatible avec une ABI prédéfinie existante, elle NE DOIT PAS indiquer la prise en charge d'aucune ABI.

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

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

Pour les bibliothèques natives répertoriées ci-dessus, l'implémentation de l'appareil NE DOIT PAS ajouter ni supprimer de fonctions publiques.

Les bibliothèques natives non listées ci-dessus, mais implémentées et fournies dans AOSP, sont réservées et NE DOIVENT PAS être exposées à des applications tierces ciblant le niveau d'API 24 ou supérieur.

Les implémentations d'appareils PEUVENT ajouter des bibliothèques non-AOSP et les exposer directement en tant qu'API aux applications tierces, mais les bibliothèques supplémentaires DOIVENT se trouver dans /vendor/lib ou /vendor/lib64 et DOIVENT être listées dans /vendor/etc/public.libraries.txt .

Notez que les implémentations d'appareils DOIVENT inclure libGLESv3.so et, par conséquent, DOIVENT exporter tous les symboles de fonction OpenGL ES 3.1 et Android Extension Pack tels que définis dans la version du NDK android-24. Bien que tous les symboles doivent être présents, seules les fonctions correspondantes pour les versions et extensions d'OpenGL ES réellement compatibles avec l'appareil doivent être entièrement implémentées.

Bibliothèques graphiques

Vulkan est une API multiplate-forme simple pour des graphismes 3D hautes performances. Les implémentations d'appareils, même si elles n'incluent pas la prise en charge des API Vulkan, DOIVENT respecter les exigences suivantes:

• Il DOIT toujours fournir une bibliothèque native nommée libvulkan.so qui exporte les symboles de fonction pour l'API principale Vulkan 1.0 ainsi que pour les extensions VK_KHR_surface, VK_KHR_android_surface et VK_KHR_swapchain.

Implémentations d'appareils, si les API Vulkan sont compatibles:

• DOIT signaler un ou plusieurs VkPhysicalDevices via l'appel vkEnumeratePhysicalDevices.
• Chaque VkPhysicalDevices énuméré DOIT implémenter entièrement l'API Vulkan 1.0.
• DOIT signaler les indicateurs de fonctionnalité PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL et PackageManager#FEATURE_VULKAN_HARDWARE_VERSION appropriés.
• DOIT énumérer les couches contenues dans des bibliothèques natives nommées libVkLayer*.so dans le répertoire de bibliothèque native du package d'application, via les fonctions vkEnumerateInstanceLayerProperties et vkEnumerateDeviceLayerProperties dans libvulkan.so.
• NE DOIT PAS énumérer les couches fournies par les bibliothèques en dehors du package d'application ni fournir d'autres moyens de traçage ou d'interception de l'API Vulkan, sauf si l'application possède l'attribut android:debuggable=”true”.

Implémentations sur les appareils, si les API Vulkan ne sont pas compatibles:

• DOIT indiquer 0 VkPhysicalDevices via l'appel vkEnumeratePhysicalDevices.
• NE DOIT PAS déclarer d'indicateur de fonctionnalité Vulkan PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL ni PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.

3.3.2. Compatibilité avec le code natif ARM 32 bits

L'architecture ARMv8 rend obsolète 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, via la compatibilité du processeur natif ou via l'émulation logicielle:

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

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 assurer la compatibilité avec les applications créées à l'aide de ce NDK, les appareils DOIVENT inclure les lignes suivantes dans /proc/cpuinfo lorsqu'il est lu par des applications ARM 32 bits:

• "Features:" (Fonctionnalités :), suivi d'une liste de toutes les fonctionnalités facultatives du processeur ARMv7 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 ou non ARM 64 bits.

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 fournissant une implémentation complète de l'API android.webkit.WebView et NE DOIT PAS être signalée sur les appareils ne disposant pas d'une implémentation complète de l'API. L'implémentation Android Open Source utilise le code du projet Chromium pour implémenter android.webkit.WebView. É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 responsables de la mise en œuvre de l'appareil DOIVENT utiliser le build en amont spécifique de Chromium dans la mise en œuvre WebView. Plus spécifiquement :

• Les implémentations d'android.webkit.WebView sur les appareils DOIVENT être basées sur la version Chromium du projet Android Open Source en amont pour Android 7.0. Cette compilation inclut un ensemble spécifique de fonctionnalités et de correctifs de sécurité pour la WebView.

• La chaîne user-agent signalée par WebView DOIT être au format suivant:

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

  • La valeur de la chaîne $(VERSION) DOIT être identique à la valeur d'android.os.Build.VERSION.Release.
  • La valeur de la chaîne $(MODEL) DOIT être identique à la valeur 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 du projet Android Open Source en amont.
  • Il est possible que les implémentations d'appareils omettent "Mobile" dans la chaîne de l'agent utilisateur.

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

Compatibilité du navigateur

Le navigateur autonome PEUT reposer 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 transmettre une chaîne user-agent personnalisée dans l'application de navigateur autonome.

L'application autonome du navigateur (basée sur l'application de navigateur WebKit en amont ou une application tierce de remplacement) DOIT inclure un maximum de HTML5. Au minimum, les implémentations d'appareils DOIVENT être compatibles avec chacune des API suivantes associées à HTML5:

• Cache d'application/opération hors connexion
• <vidéo> d'entraînement
• géolocalisation

De plus, les implémentations d'appareils DOIVENT prendre en charge l'API de stockage Web HTML5/W3C et l'API IndexedDB HTML5/W3C. Notez qu'à mesure que les organismes de normalisation pour le développement Web s'orientent vers le stockage Web, IndexedDB devrait devenir un composant obligatoire dans une prochaine version d'Android.

3.5. Compatibilité comportementale de l'API

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

• Les appareils NE DOIVENT PAS modifier le comportement ni la sémantique d'un intent standard.
• Les appareils NE DOIVENT PAS modifier la sémantique du cycle de vie ou du cycle de vie d'un type particulier de composant système (tel qu'un service, une activité, un 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 la compatibilité comportementale d'une partie importante de la plate-forme, mais pas de toutes. Il est de la responsabilité de l'outil de mise en œuvre de veiller à la compatibilité du comportement avec le projet Android Open Source. C'est pourquoi, dans la mesure du possible, les responsables de la mise en œuvre des appareils DOIVENT utiliser le code source disponible via le projet Android Open Source, plutôt que de réimplémenter des parties importantes du système.

3.6. Espaces de noms de l'API

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

• java.*
• javax.*
• soleil.*
• Android*
• com.android.*

Les modifications interdites incluent :

• Les implémentations d'appareils NE DOIVENT PAS modifier les API affichées publiquement sur la plate-forme Android en modifiant des signatures de méthode ou de classe, ou en supprimant des classes ou des champs de classe.
• Les responsables de l'implémentation des appareils PEUVENT modifier l'implémentation sous-jacente des API, mais ces modifications NE DOIVENT PAS affecter le comportement déclaré ni la signature en langage Java des API exposées publiquement.
• Les responsables de la mise en œuvre des appareils NE DOIVENT PAS ajouter d'éléments exposés publiquement (comme des classes ou interfaces, ou des champs ou méthodes à des classes ou interfaces existantes) aux API ci-dessus.

Un "élément exposé publiquement" est une construction qui n'est pas décorée du repère "@hide" tel qu'il est utilisé dans le code source Android en amont. En d'autres termes, les responsables de la mise en œuvre d'appareils NE DOIVENT PAS exposer de nouvelles API ni modifier les API existantes dans les espaces de noms mentionnés ci-dessus. Les responsables de la mise en œuvre des appareils PEUVENT effectuer des modifications réservées à un usage interne, mais ces modifications NE DOIVENT PAS être annoncées ni présentées aux développeurs.

Les responsables de la mise en œuvre des 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 y faisant référence. Par exemple, les responsables de la mise en œuvre des appareils NE DOIVENT PAS ajouter d'API à com.google.* ou à un espace de noms similaire: seul Google est autorisé à le faire. De même, Google NE DOIT PAS ajouter d'API aux applications et plusieurs espaces de noms. De plus, si l'implémentation d'un appareil inclut des API personnalisées en dehors de l'espace de noms 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-library>) soient affectées par l'utilisation accrue de la mémoire de ces API.

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

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

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

Les implémentations d'appareils DOIVENT être compatibles avec le format complet Dalvik Executable (DEX), ainsi que la spécification et la sémantique du bytecode Dalvik. Les responsables de la mise en œuvre des appareils DOIVENT utiliser ART, l'implémentation de référence en amont du format exécutable Dalvik et le système de gestion de packages de l'implémentation de référence.

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 spécifié dans le tableau suivant. (Consultez la section 7.1.1 pour obtenir les définitions de la taille et de la densité de l'écran.) Notez que les valeurs de mémoire spécifiées ci-dessous sont considérées comme des valeurs minimales et que les implémentations d'appareils PEUVENT allouer plus de mémoire par application.

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

3.8. Compatibilité de l'interface utilisateur

Lanceur d'applications (écran d'accueil)

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

Widgets

Android définit un type de composant, ainsi que l'API et le cycle de vie correspondants qui permettent aux applications de présenter un AppWidget à l'utilisateur final. Il est FORTEMENT RECOMMANDÉ d'intégrer cette fonctionnalité dans les implémentations d'appareils portables. Les implémentations d'appareils qui prennent en charge 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 afficher les affordances d'interface utilisateur pour ajouter, configurer, afficher et supprimer des AppWidgets directement dans le lanceur d'applications.
• Les implémentations d'appareils DOIVENT être capables d'afficher des widgets de 4 x 4 dans la grille standard. Pour en savoir plus, consultez les consignes de conception des widgets d'application dans la documentation du SDK Android.
• 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 à 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 le son, la vibration et 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 l'implémentation d'un appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibreur. Si l'implémentation d'un appareil manque de matériel, les API correspondantes DOIVENT être implémentées en tant que no-ops. Ce comportement est détaillé dans la section 7.

En outre, l'implémentation DOIT afficher correctement toutes les ressources (icônes, fichiers d'animation, etc.) fournies dans les API ou dans le guide de style des icônes de la barre d'état/système. Dans le cas d'un appareil Android Television, il est possible de ne pas afficher les notifications. Les responsables de la mise en œuvre d'appareils PEUVENT fournir une expérience utilisateur différente de celle fournie par l'implémentation Android Open Source de référence pour les notifications. Toutefois, ces systèmes de notification alternatifs DOIVENT prendre en charge les ressources de notification existantes, comme ci-dessus.

Android est compatible avec diverses notifications, par exemple:

• Notifications enrichies . Vues interactives pour les notifications en cours.
• Avertissements . Les utilisateurs peuvent agir sur les vues interactives ou les ignorer sans quitter l'application actuelle.
• Notifications sur l'écran verrouillé . Notifications affichées sur un écran de verrouillage avec un contrôle précis de la visibilité

Les implémentations d'appareils Android, lorsque de telles notifications sont rendues visibles, DOIVENT exécuter correctement les notifications enrichies et prioritaires, et inclure le titre/nom, l'icône et le texte documentés dans les API Android.

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 publiées ou mises à jour. Les implémentations d'appareils DOIVENT envoyer correctement et rapidement des notifications dans leur intégralité à tous les services d'écoute installés et activés par l'utilisateur, y compris toutes les métadonnées associées à l'objet Notification.

Les implémentations d'appareils compatibles avec la fonctionnalité Ne pas déranger DOIVENT respecter les exigences suivantes:

• DOIT implémenter une activité qui répond à l'intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. Pour les implémentations avec UI_MODE_TYPE_NORMAL, il DOIT s'agir d'une activité permettant à l'utilisateur d'autoriser ou de refuser à l'application l'accès aux configurations de règles Ne pas déranger.
• OBLIGATOIRE, lorsque la mise en œuvre de l'appareil a permis à l'utilisateur d'autoriser ou de refuser l'accès des applications tierces à la configuration des règles Ne pas déranger, afficher Règles automatiques Ne pas déranger créées par les applications en plus des règles définies par l'utilisateur et prédéfinies.
• DOIT respecter les valeurs suppressedVisualEffects transmises via NotificationManager.Policy. Si une application a défini l'un des indicateurs SUPPRESSED_EFFECT_SCREEN_OFF ou SUPPRESSED_EFFECT_SCREEN_ON, elle DOIT indiquer à l'utilisateur que les effets visuels sont supprimés dans le menu des paramètres du mode Ne pas déranger.

3.8.4. Rechercher

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

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

Les implémentations d'appareils Android DOIVENT, et celles d'Android Automotive DOIVENT implémenter un assistant sur l'appareil pour gérer l'action d'assistance.

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. Les implémentations d'appareils compatibles avec l'action d'assistance DOIVENT indiquer clairement à l'utilisateur final lorsque le contexte est partagé, en affichant un voyant blanc sur les bords de l'écran. Afin de garantir une visibilité claire pour l'utilisateur final, l'indication DOIT respecter ou dépasser la durée et la luminosité de l'implémentation du projet Android Open Source.

Toasts

Les applications peuvent utiliser l'API Toast pour présenter à l'utilisateur final de courtes chaînes non modales qui disparaissent après un court laps de temps. Les implémentations d'appareils DOIVENT afficher les Toasts des applications aux utilisateurs finaux de façon très visible.

3.8.6. Thèmes

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

Android inclut une famille de thèmes "Holo", qui correspond à un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent s'adapter à l'apparence du thème Hoo, telle que définie par le SDK Android. Les implémentations d'appareils NE DOIVENT PAS modifier les attributs du thème Holo associés aux applications.

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 s'adapter à l'apparence du thème de conception sur les nombreux types d'appareils Android différents. Les implémentations d'appareils DOIVENT être compatibles avec la famille de thèmes "Material" et NE DOIVENT PAS modifier les attributs du thème Material ni leurs éléments exposés aux applications.

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

Android prend en charge un thème de variante avec des barres système translucides, ce qui permet aux développeurs d'applications d'insérer le contenu de leur application dans la zone située derrière la barre d'état et la barre de navigation. Pour offrir une expérience cohérente aux développeurs dans cette configuration, il est important que le style de l'icône de la barre d'état soit conservé dans les différentes implémentations d'appareils. Par conséquent, les implémentations d'appareils Android DOIVENT utiliser du blanc pour les icônes d'état système (telles que l'intensité du signal et le niveau de la batterie) et les notifications envoyées par le système, sauf si l'icône indique un état problématique ou si une application demande l'affichage d'une barre d'état lumineuse à l'aide de l'indicateur SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Lorsqu'une application demande une barre d'état lumineuse, les implémentations d'appareils Android DOIVENT modifier la couleur des icônes d'état système en noir (pour en savoir plus, consultez R.style).

3.8.7. Fonds d'écran animés

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

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

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

3.8.8. Changement d'activité

Le code source Android en amont inclut l'écran d'aperçu, une interface utilisateur au niveau du système permettant de changer de tâche et d'afficher les activités et les tâches récemment consultées à l'aide d'une vignette de l'état graphique de l'application au moment où l'utilisateur la quitte pour la dernière fois. Les implémentations d'appareils, y compris la touche de navigation des fonctions récentes, comme détaillé dans la section 7.2.3, PEUVENT modifier l'interface, mais DOIVENT respecter les exigences suivantes:

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

Il est FORTEMENT RECOMMANDÉ d'utiliser l'interface utilisateur Android en amont (ou une interface similaire basée sur des vignettes) pour l'écran "Overview" (Aperçu).

3.8.9. Gestion des entrées

Android est compatible avec la gestion des entrées et avec les éditeurs de mode de saisie tiers. Les implémentations d'appareil qui permettent aux utilisateurs d'utiliser des modes de saisie tiers sur l'appareil DOIVENT déclarer la fonctionnalité de plate-forme android.software.input_methods et prendre en charge les API IME, telles que définies dans la documentation du SDK Android.

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 modes de saisie tiers. 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. Commandes multimédias pour l'écran de verrouillage

À partir d'Android 5.0, l'API Remote Control Client a été abandonnée au profit du modèle de notification multimédia, qui permet aux applications multimédias d'intégrer les commandes de lecture affichées sur l'écran de verrouillage. Les implémentations d'appareils qui prennent en charge un écran de verrouillage, sauf s'il s'agit d'une implémentation d'Android Automotive ou d'une montre, DOIVENT afficher les notifications sur l'écran de verrouillage, y compris le modèle de notification multimédia.

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

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

3.8.12. Position

Lorsqu'un appareil est équipé d'un capteur matériel (GPS, par exemple) capable de fournir les coordonnées de localisation, les modes de localisation DOIVENT être affichés dans le menu "Localisation" des paramètres.

3.8.13. Unicode et police

Android est compatible avec les caractères emoji définis dans Unicode 9.0. Toutes les implémentations d'appareils DOIVENT être capables d'afficher ces caractères emoji avec un glyphe de couleur. Lorsque les implémentations d'appareils Android incluent un IME, elles DOIVENT fournir à l'utilisateur un mode de saisie pour ces caractères emoji.

Les appareils portables Android DOIVENT prendre en charge la carnation et les différents emoji familiaux, comme indiqué dans le rapport technique Unicode 51.

Android prend en charge 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 être toutes incluses pour les langues disponibles sur l'appareil, ainsi que pour les symboles latins, grecs et cyrilliques complets, y compris le bloc latin, C-7 et Unicode B.7.

3.8.14. Multifenêtre

Une implémentation d'appareil PEUT choisir de ne pas implémenter de mode multifenêtre, mais s'il a la possibilité d'afficher plusieurs activités en même temps, elle DOIT implémenter ce ou ces modes multifenêtres conformément aux comportements d'application et aux API décrits dans la documentation de prise en charge du mode multifenêtre du SDK Android et respecter les exigences suivantes:

• Les applications peuvent indiquer si elles peuvent fonctionner en mode multifenêtre dans le fichier AndroidManifest.xml, de façon explicite via l'attribut android:resizeableActivity ou implicitement en utilisant targetSdkVersion > 24. Les applications qui définissent explicitement cet attribut sur "false" dans leur fichier manifeste NE DOIVENT pas être lancées en mode multifenêtre. Les applications qui ne définissent pas l'attribut dans leur fichier manifeste (targetSdkVersion < 24) peuvent être lancées en mode multifenêtre, mais le système DOIT avertir le système que l'application peut ne pas fonctionner comme prévu en mode multifenêtre.
• Les implémentations d'appareils NE DOIVENT PAS proposer le mode Écran partagé ou Format libre si la hauteur et la largeur de l'écran sont inférieures à 440 dp.
• Les implémentations d'appareils avec une taille d'écran xlarge DEVRAIT prendre en charge le mode Format libre.
• Les implémentations d'appareils Android TV DOIVENT prendre en charge le mode multifenêtre (Picture-in-picture) et placer ce mode dans l'angle supérieur droit lorsque PIP est activé.
• Les implémentations d'appareils compatibles avec le mode multifenêtre DOIVENT allouer au moins 240 x 135 dp pour la fenêtre PIP.
• Si le mode multifenêtre PIP est pris en charge, la touche KeyEvent.KEYCODE_WINDOW DOIT être utilisée pour contrôler la fenêtre PIP. Sinon, la clé DOIT être disponible pour l'activité de premier plan.

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux applications sécurisées d'effectuer des tâches d'administration des appareils au niveau du système, telles que l'application de règles relatives aux mots de passe ou l'effacement à distance, par le biais de l'API Android Device Administration. Les implémentations d'appareils DOIVENT fournir une implémentation de la classe DevicePolicyManager. Les implémentations d'appareils compatibles avec un écran de verrouillage sécurisé DOIVENT implémenter l'ensemble des règles d'administration des appareils définies dans la documentation du SDK Android et signaler la fonctionnalité de plate-forme android.software.device_admin.

3.9.1 Préparation des appareils

3.9.1.1 Configuration du propriétaire de l'appareil

Si une implémentation d'appareil déclare la fonctionnalité android.software.device_admin, elle DOIT implémenter le provisionnement de l'application Propriétaire de l'appareil d'une application du client Device Policy (DPC), comme indiqué ci-dessous:

• Lorsque aucune donnée utilisateur n'est encore configurée pour l'implémentation de l'appareil, celle-ci: <ph type="x-smartling-placeholder">
  </ph>
  • DOIT signaler true pour DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  • DOIT enregistrer l'application DPC en tant qu'application du propriétaire de l'appareil en réponse à l'action d'intent android.app.action.PROVISION_MANAGED_DEVICE.
  • DOIT enregistrer l'application DPC en tant qu'application propriétaire de l'appareil si l'appareil déclare la compatibilité NFC (communication en champ proche) via le flag de fonctionnalité android.hardware.nfc et reçoit un message NFC contenant un enregistrement de type MIME MIME_TYPE_PROVISIONING_NFC.
• Lorsque l'implémentation de l'appareil contient des données utilisateur: <ph type="x-smartling-placeholder">
  </ph>
  • DOIT indiquer false pour DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  • NE DOIT plus enregistrer d'application DPC en tant qu'application du propriétaire de l'appareil.

Dans les implémentations d'appareils, il est possible qu'une application préinstallée effectue des fonctions d'administration de l'appareil, mais cette application NE DOIT PAS être définie en tant qu'application du propriétaire de l'appareil sans le consentement explicite de l'utilisateur ou de l'administrateur de l'appareil, ni aucune action de leur part.

3.9.1.2 Provisionnement des profils gérés

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

Le processus de provisionnement du profil géré (flux lancé par android.app.action.PROVISION_MANAGED_PROFILE) DOIT correspondre à l'implémentation d'AOSP.

Les implémentations d'appareils DOIVENT fournir les affordances suivantes dans l'interface utilisateur des paramètres pour indiquer à l'utilisateur qu'une fonction système particulière a été désactivée par l'outil de contrôle des règles relatives aux appareils (DPC):

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

3.9.2 Prise en charge des profils gérés

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

• Déclarez android.software.device_admin (voir la section 3.9 Administration des appareils).
• ne sont pas des appareils à faible RAM (voir la section 7.6.1) ;
• Allouez un 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 .
• Prenez en charge les profils gérés via les API android.app.admin.DevicePolicyManager.
• Autorisez la création d'un seul profil géré.
• Utilisez un badge d'icône (semblable au badge professionnel en amont AOSP) pour représenter les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur dotés d'un badge tels que les applications récentes et Notifications.
• Affichez une icône de notification (semblable au badge professionnel en amont AOSP) pour indiquer que l'utilisateur se trouve dans une application de profil géré.
• Afficher un toast indiquant que l'utilisateur se trouve dans le profil géré si et quand l'appareil est réactivé (ACTION_USER_PRESENT) et que l'application au premier plan se trouve dans le profil géré
• Lorsqu'un profil géré existe, afficher une affordance visuelle dans le sélecteur d'intent ; pour permettre à l'utilisateur de transférer l'intent du profil géré à l'utilisateur principal, ou inversement, s'il est activé par l'outil de contrôle des règles relatives aux appareils.
• Lorsqu'un profil géré existe, exposez les affordances utilisateur suivantes pour l'utilisateur principal et le profil géré: <ph type="x-smartling-placeholder">
  </ph>
  • Les données sont séparées pour l'utilisation de la batterie, de l'emplacement, des données mobiles et de l'espace de stockage pour l'utilisateur principal et le profil géré.
  • Gestion indépendante des applications VPN installées dans le profil utilisateur principal ou le profil géré
  • Gestion indépendante des applications installées dans l'utilisateur principal ou le profil géré
  • Gestion indépendante des comptes au sein de l'utilisateur principal ou du profil géré.
• Assurez-vous que le clavier, les contacts et les applications de messagerie préinstallés peuvent rechercher et consulter des informations sur l'appelant dans le profil géré (le cas échéant) et dans le profil principal, si l'outil de contrôle des règles relatives aux appareils le permet. Lorsque les contacts du profil géré sont affichés dans le journal d'appels préinstallé, l'interface utilisateur de l'appel, les notifications d'appels en cours et manqués, les contacts et les applications de chat, ils DOIVENT porter le même badge que celui utilisé pour indiquer les applications du profil géré.
• DOIT s'assurer qu'il répond à toutes les exigences de sécurité applicables à un appareil sur lequel plusieurs utilisateurs sont activés (voir la section 9.5), même si le profil géré n'est pas comptabilisé comme un autre utilisateur en plus de l'utilisateur principal.
• Offrez la possibilité de spécifier un écran de verrouillage distinct répondant aux exigences suivantes pour accorder l'accès aux applications exécutées dans un profil géré.
  • Les implémentations d'appareils DOIVENT respecter l'intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD et afficher une interface permettant de configurer des identifiants d'écran de verrouillage distincts pour le profil géré.
  • Les identifiants de l'écran de verrouillage du profil géré DOIVENT utiliser les mêmes mécanismes de stockage et de gestion des identifiants que le profil parent, comme indiqué sur le site du projet Android Open Source.
  • Les règles de mot de passe de l'outil DPC DOIVENT s'appliquer uniquement aux identifiants de l'écran de verrouillage du profil géré, sauf si elles sont appelées sur l'instance DevicePolicyManager renvoyée par getParentProfileInstance.

3.10. Accessibilité

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

Les implémentations d'appareils incluent les exigences suivantes:

• Les implémentations Android Automotive DOIVENT fournir une implémentation du framework d'accessibilité Android cohérente avec l'implémentation Android par défaut.
• Les implémentations d'appareils (à l'exclusion d'Android Automotive) DOIVENT fournir une implémentation du framework d'accessibilité Android cohérente avec l'implémentation Android par défaut.
• Les implémentations d'appareils (à l'exclusion d'Android Automotive) DOIVENT prendre en charge les implémentations de services d'accessibilité tiers via les API android.accessibilityservice.
• Les implémentations d'appareils (à l'exclusion d'Android Automotive) DOIVENT générer des événements d'accessibilité et les diffuser à toutes les implémentations d'AccessibilityService enregistrées d'une manière cohérente avec l'implémentation Android par défaut.

• Les implémentations d'appareils (appareils Android Automotive et Android Watch sans sortie audio exclues) 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.

• Il est FORTEMENT RECOMMANDÉ de proposer des implémentations de services d'accessibilité sur les appareils Android avec des fonctionnalités comparables ou supérieures aux services d'accessibilité TalkBack** et Switch Access (https://github.com/google/talkback).

• Les montres Android Watch avec sortie audio DOIVENT fournir des implémentations d'un service d'accessibilité sur l'appareil comparable ou supérieure au service d'accessibilité TalkBack (https://github.com/google/talkback).
• Les implémentations d'appareils DOIVENT inclure dans le flux de configuration prêt à l'emploi un mécanisme permettant aux utilisateurs d'activer les services d'accessibilité pertinents, ainsi que des options permettant d'ajuster la taille de la police, la taille d'affichage et les gestes d'agrandissement.

** Pour les langues compatibles avec la synthèse vocale.

Notez également que s'il existe un service d'accessibilité préchargé, il DOIT s'agir d'une application {directBootAware} compatible avec le démarrage direct si l'appareil dispose d'un stockage chiffré à l'aide du chiffrement basé sur les fichiers (FBE).

3.11. Synthèse vocale

Android inclut des API qui permettent aux applications d'utiliser les services de synthèse vocale et aux fournisseurs de services de proposer des implémentations de services de synthèse vocale. Les implémentations d'appareils qui signalent la fonctionnalité android.hardware.audio.output DOIVENT respecter ces exigences liées au framework de synthèse vocale Android.

Implémentations Android Automotive:

• DOIT être compatible avec les API du framework de synthèse vocale Android.
• PEUT prendre en charge l'installation de moteurs de synthèse vocale tiers. S'ils sont compatibles, les partenaires DOIVENT fournir une interface accessible à l'utilisateur qui permet à ce dernier de sélectionner un moteur de synthèse vocale à utiliser au niveau du système.

Toutes les autres implémentations d'appareils:

• DOIT prendre en charge les API du framework de synthèse vocale Android et DEVRAIT inclure un moteur de synthèse vocale compatible avec les langages disponibles sur l'appareil. Notez que le logiciel Open Source Android en amont inclut une implémentation complète du moteur de synthèse vocale.
• DOIT prendre en charge l'installation de moteurs de synthèse vocale tiers.
• DOIT fournir une interface accessible à l'utilisateur permettant de sélectionner un moteur de synthèse vocale à utiliser au niveau du système.

3.12. Framework d'entrée TV

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

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

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 (application TV). Le projet Android Open Source fournit une implémentation de l'application TV.

L'Appli TV DOIT fournir les installations nécessaires à l'installation et à l'utilisation des chaînes de télévision, et répondre aux exigences suivantes:

• Les implémentations d'appareils DOIVENT autoriser l'installation et la gestion d'entrées tierces basées sur TIF ( entrées tierces).
• Les implémentations d'appareils PEUVENT permettre une séparation visuelle entre les entrées basées sur TIF préinstallées (entrées installées) et les entrées tierces.
• Les implémentations d'appareils NE DOIVENT PAS afficher les entrées tierces plus d'une seule action de navigation en dehors de l'application TV (par exemple, étendre une liste d'entrées tierces à partir de l'application TV).

Guide des programmes électronique

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. 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 permettre une séparation visuelle entre les entrées installées et les entrées tierces.
• L'EPG est VIVEMENT RECOMMANDÉ d'afficher les entrées installées et les entrées tierces avec une proéminence égale. L'EPG NE DOIT PAS afficher les entrées tierces plus d'une seule action de navigation à partir des entrées installées sur l'EPG.
• Lors du changement de canal, les implémentations d'appareils DOIVENT afficher les données EPG du programme en cours de lecture.

Navigation

L'appli TV DOIT autoriser la navigation pour les fonctions suivantes à l'aide des touches du pavé directionnel, des touches Retour et Accueil du ou des périphériques d'entrée de l'appareil Android TV (télécommande, application de télécommande ou manette de jeu, par exemple):

• Changer de chaîne de télévision
• Ouverture de l'EPG en cours
• Configurer et régler les entrées tierces basées sur TIF
• Ouverture du menu "Paramètres"...

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

Association d'une appli d'entrée TV

Les implémentations d'appareils Android TV DOIVENT être compatibles avec l'association d'applications d'entrée TV, qui permet à toutes les entrées de fournir des liens entre l'activité en cours et une autre activité (par exemple, un lien vers un contenu associé depuis la programmation en direct). L'appli TV DOIT afficher les liens vers l'appli TV d'entrée lorsqu'elle est fournie.

Décalage temporel

Les implémentations d'appareils Android TV DOIVENT prendre en charge le décalage temporel, qui permet à l'utilisateur de mettre en pause et de reprendre la lecture du contenu en direct. Les implémentations d'appareils DOIVENT fournir à l'utilisateur un moyen de mettre en pause et de reprendre la lecture du programme en cours de lecture, si le décalage temporel est disponible pour ce programme.

Enregistrement TV

Les implémentations d'appareils Android TV sont VIVEMENT RECOMMANDÉES pour permettre l'enregistrement TV. Si l'entrée TV est compatible avec l'enregistrement, l'EPG PEUT fournir un moyen d'enregistrer un programme si l'enregistrement de ce type de programme n'est pas interdit. Les implémentations d'appareils DOIVENT fournir une interface utilisateur permettant de lire les programmes enregistrés.

3.13. Les réglages rapides

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

Android inclut l'API quicksettings, qui permet aux applications tierces d'implémenter des cartes pouvant être ajoutées par l'utilisateur en plus de celles fournies par le système dans le composant d'UI Réglages rapides. Si l'implémentation d'un appareil comporte un composant d'interface utilisateur Réglages rapides, elle:

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

3.14. API Vehicle UI

UI multimédia de véhicule

Toute implémentation d'appareil qui déclare la compatibilité automobile DOIT inclure un framework d'interface utilisateur compatible avec les applications tierces utilisant les API MediaBrowser et MediaSession.

Le framework d'UI prenant en charge les applications tierces qui dépendent de MediaBrowser et de MediaSession présente les exigences visuelles suivantes:

• DOIT afficher les icônes MediaItem et les icônes de notification telles quelles.
• DOIT afficher ces éléments comme décrit par MediaSession (métadonnées, icônes, images, etc.).
• Le titre de l'application DOIT afficher.
• DOIT disposer d'un panneau pour présenter la hiérarchie MediaBrowser.

4. Compatibilité avec les packages d'applications

Les implémentations d'appareils DOIVENT installer et exécuter les fichiers Android ".apk" générés par l'outil "aapt" inclus dans le SDK Android officiel. C'est pourquoi les implémentations d'appareils DOIVENT utiliser le système de gestion de packages de l'implémentation de référence.

Le gestionnaire de packages DOIT prendre en charge la vérification des fichiers ".apk" à l'aide du APK Signature Scheme v2 et de la signature JAR.

Les implémentations d'appareils NE DOIVENT PAS étendre les formats de bytecode .apk, manifest Android, Dalvik bytecode ou RenderScript d'une manière qui empêcherait l'installation et l'exécution de ces fichiers sur d'autres appareils compatibles.

5. Compatibilité multimédia

5.1. Codecs multimédias

Implémentations des appareils :

• DOIT prendre en charge les principaux formats multimédias spécifiés dans la documentation du SDK Android, sauf dans les cas explicitement autorisés dans ce document.

• DOIT prendre en charge les formats multimédias, les encodeurs, les décodeurs, les types de fichiers et les formats de conteneur définis dans les tableaux ci-dessous et signalés via MediaCodecList.

• DOIT également être capable de décoder tous les profils indiqués dans son CamcorderProfile

• DOIT être capable de décoder tous les formats qu'il peut encoder. Cela inclut tous les flux de bits générés par ses encodeurs.

Les codecs DOIVENT avoir pour objectif une latence minimale, c'est-à-dire des codecs...

• NE DEVRAIT PAS utiliser ni stocker les tampons d'entrée, et renvoyer les tampons d'entrée une fois qu'ils auront été traités
• NE DOIT PAS conserver sur les tampons décodés plus longtemps que spécifié par la norme (par exemple, SPS).
• NE DEVRAIT PAS conserver sur les tampons encodés plus longtemps que requis par la structure GOP.

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

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

5.1.1. Codecs audio

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

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

2 L'enregistrement ou la lecture PEUVENT être effectués en mono ou stéréo, mais le décodage des tampons d'entrée AAC des flux multicanaux (c'est-à-dire plus de deux canaux) vers le format PCM via le décodeur audio AAC par défaut de l'API android.media.MediaCodec, DOIT être pris en charge:

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

3 Obligatoire pour les implémentations sur les appareils portables Android.

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

5.1.2. Codecs image

Format/Codec	Encodeur	Décodeur	Détails	Types de fichiers/formats de conteneur acceptés
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)
Brute		REQUIRED		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.3. Codecs vidéo

• Les codecs qui font la promotion d'un profil HDR DOIVENT être compatibles avec l'analyse et la gestion des métadonnées statiques HDR.

• Si un codec multimédia annonce la prise en charge de l'actualisation intra, il DOIT accepter des périodes d'actualisation comprises entre 10 et 60 images et fonctionner avec précision pendant 20% de la période d'actualisation configurée.

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

• Les encodeurs et décodeurs vidéo DOIVENT prendre en charge le format de couleur flexible YUV420 (COLOR_FormatYUV420Flexible).

Format/Codec	Encodeur	Décodeur	Détails	Types de fichiers compatibles/ Formats des conteneurs
H.263	MAI	MAI		3GPP (0,3gp) MPEG-4 (.mp4)
H.264 AVC	OBLIGATOIRE2	OBLIGATOIRE2	Pour en savoir plus, consultez les sections 5.2 et 5.3.	3GPP (0,3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, audio AAC uniquement, recherche impossible, Android 3.0 ou version ultérieure)
HEVC H.265		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 (0,3gp)
VP8 3	OBLIGATOIRE2 (Android 4.3 ou version ultérieure)	OBLIGATOIRE2 (Android 2.3.3 et versions ultérieures)	Pour en savoir plus, consultez les sections 5.2 et 5.3.	WebM (.webm) Matroska (.mkv, Android 4.0 ou version ultérieure)4
VP9		OBLIGATOIRE2 (Android 4.4 ou version ultérieure)	Pour en savoir plus, consultez la section 5.3.	WebM (.webm) Matroska (.mkv, Android 4.0 ou version ultérieure)4

1 Requis pour les implémentations d'appareils qui incluent un appareil photo et définissent android.hardware.camera ou android.hardware.camera.front.

2 Requis pour les implémentations sur les appareils, à l'exception des montres Android.

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

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

5 FORTEMENT RECOMMANDÉ pour Android Automotive, en option pour l'Android Watch et obligatoire pour tous les autres types d'appareils.

6 S'applique uniquement aux implémentations d'appareils Android TV.

5.2. Encodage vidéo

Encodeurs vidéo H.264, VP8, VP9 et HEVC :

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

Les encodeurs vidéo H.263 et MPEG-4 DOIVENT prendre en charge des débits configurables de manière dynamique.

Tous les encodeurs vidéo DOIVENT atteindre les cibles de débit suivants sur deux fenêtres glissantes:

• Il NE DOIT pas dépasser environ 15% du débit entre les intervalles intraframe (I-frame).
• Le débit ne doit pas dépasser environ 100% sur une fenêtre glissante d'une seconde.

5.2.1. H.263

Les implémentations d'appareils Android avec des encodeurs H.263 DOIVENT prendre en charge le profil de référence de niveau 45.

5.2.2. H264

Implémentations d'appareils Android compatibles avec le codec H.264:

• DOIT prendre en charge le profil de référence de niveau 3.
  Toutefois, la prise en charge des types ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) et RS (Redondant Slices) est FACULTATIVE. De plus, pour assurer la compatibilité avec d'autres appareils Android, il est RECOMMANDÉ de ne pas utiliser ASO, FMO et RS pour le profil de référence des encodeurs.
• DOIT prendre en charge les profils d'encodage vidéo SD (définition standard) indiqués dans le tableau suivant.
• DEVRAIT prendre en charge le profil principal de niveau 4.
• DEVRAIT prendre en charge les profils d'encodage vidéo HD (haute définition) comme indiqué dans le tableau suivant.
• De plus, il est FORTEMENT RECOMMANDÉ d'encoder les vidéos HD 1080p à 30 FPS sur les téléviseurs Android.

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

1 Lorsque la compatibilité matérielle est assurée, mais VIVEMENT RECOMMANDÉ pour les appareils Android Television.

5.2.3. VP8

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 720p 1	HD 1080p 1
Résolution vidéo	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Fréquence d'images vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	800 Kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

1 Si le matériel est compatible.

5.3. Décodage vidéo

Implémentations des appareils :

• DOIT prendre en charge le changement dynamique de résolution vidéo et 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 dans la résolution maximale prise en charge par chaque codec sur l'appareil.

• Les implémentations compatibles avec le décodeur Dolby Vision :

• DOIT fournir un extracteur compatible avec Dolby Vision.

• DOIT afficher correctement le contenu Dolby Vision sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

• Les implémentations qui fournissent un extracteur compatible avec Dolby Vision DOIVENT définir l'index de suivi des couches de base rétrocompatibles (le cas échéant) de sorte qu'ils soient identiques à ceux de la couche Dolby Vision combinée.

5.3.1. MPEG-2

Les implémentations d'appareils Android avec des décodeurs MPEG-2 doivent être compatibles avec le profil principal de niveau supérieur.

5.3.2. H.263

Les implémentations d'appareils Android avec des décodeurs H.263 DOIVENT prendre en charge les profils de référence de niveaux 30 et 45.

5.3.3. MPEG-4

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

5.3.4. H.264

Implémentations d'appareils Android avec des décodeurs H.264:

• DOIT être compatible avec le profil principal de niveau 3.1 et le profil de référence.
  La prise en charge des options ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) et RS (segments redondants) est FACULTATIVE.
• DOIT être capable de décoder des vidéos avec les profils SD (définition standard) répertoriés dans le tableau suivant et encodées avec le profil de référence et le profil principal de niveau 3.1 (y compris 720p30).
• DOIT être capable de décoder des vidéos avec les profils HD (haute définition), comme indiqué dans le tableau suivant.
• En outre, les appareils Android Television : <ph type="x-smartling-placeholder">
  </ph>
  • DOIT être compatible avec le profil High Profile 4.2 et le profil de décodage HD 1080p60.
  • DOIT être capable de décoder des vidéos avec les deux profils HD, comme indiqué dans le tableau suivant, et encodées avec le profil de référence, le profil principal ou le profil de niveau élevé 4.2.

	SD (basse qualité)	SD (haute qualité)	HD 720p 1	HD 1080p 1
Résolution vidéo	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Fréquence d'images vidéo	30 ips	30 ips	60 FPS	30 FPS (60 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 supérieure ou égale à la résolution vidéo.

2 OBLIGATOIRES pour les implémentations d'appareils Android Television.

5.3.5. H.265 (HEVC)

Implémentations d'appareils Android, lorsqu'elles sont compatibles avec le codec H.265, comme décrit dans la section 5.1.3:

• DOIT être compatible avec le niveau principal du profil principal de niveau 3 et les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
• DEVRAIT être compatible avec les profils de décodage HD, comme indiqué dans le tableau suivant.
• DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant en cas de décodeur matériel.
• En outre, les appareils Android Television:
• DOIT être compatible avec le profil de décodage HD 720p.
• VIVEMENT RECOMMANDÉ pour prendre en charge le profil de décodage HD 1080p. Si le profil de décodage HD 1080p est pris en charge, il DOIT être compatible avec le profil principal de niveau 4.1 pour le niveau principal.
• DEVRAIT prendre en charge le profil de décodage UHD. Si le profil de décodage UHD est pris en charge, le codec DOIT prendre en charge le profil Main10 de niveau 5.

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Fréquence d'images vidéo	30 ips	30 ips	30 ips	30 FPS (60 FPS1)	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 Television avec décodage matériel H.265.

5.3.6. VP8

Implémentations sur des appareils Android, lorsqu'elles sont compatibles avec le codec VP8, comme décrit dans la section 5.1.3:

• DOIT être compatible avec les profils de décodage SD indiqués dans le tableau suivant.
• DEVRAIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
• Les appareils Android TV DOIVENT être compatibles avec le profil de décodage HD 1080p60.

	SD (basse qualité)	SD (haute qualité)	HD 720p 1	HD 1080p 1
Résolution vidéo	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Fréquence d'images vidéo	30 ips	30 ips	30 FPS (60 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 supérieure ou égale à la résolution vidéo.

2 OBLIGATOIRES pour les implémentations d'appareils Android Television.

5.3.7. VP9

Implémentations sur des appareils Android, lorsqu'elles sont compatibles avec le codec VP9, comme décrit dans la section 5.1.3:

• DOIT être compatible avec les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
• DEVRAIT être compatible avec les profils de décodage HD, comme indiqué dans le tableau suivant.
• DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant, s'il existe un décodeur matériel.

• En outre, les appareils Android Television:

  • DOIT être compatible avec le profil de décodage HD 720p.
  • VIVEMENT RECOMMANDÉ pour prendre en charge le profil de décodage HD 1080p.
  • DEVRAIT prendre en charge le profil de décodage UHD. Si le profil de décodage vidéo UHD est pris en charge, il DOIT être compatible avec une profondeur de couleur de 8 bits et le profil 2 VP9 (10 bits) de l'appareil.

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Fréquence d'images vidéo	30 ips	30 ips	30 ips	30 FPS (60 FPS1)	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 Television avec décodage matériel VP9.

5.4. Enregistrement audio

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

5.4.1. Capture audio brute

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

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

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

Les implémentations d'appareils qui déclarent android.hardware.micro DOIVENT permettre la capture de contenu audio brut présentant 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 acceptée, elle DOIT être effectuée sans suréchantillonnage à un ratio supérieur à 16000:22050 ou 44100:48000. Tout sur-échantillonnage ou sous-échantillonnage DOIT inclure un filtre d'anticrénelage approprié.

5.4.2. Capturer pour la reconnaissance vocale

La source audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION DOIT prendre en charge la capture à l'un des taux d'échantillonnage 44100 et 48000.

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 relativement plates par rapport à la fréquence: plus précisément, ±3 dB, de 100 Hz à 4 000 Hz.
• La sensibilité de l'entrée audio DOIT être définie de sorte qu'une source de niveau de puissance sonore (SPL) de 90 dB à 1 000 Hz donne un signal RMS de 2 500 pour les échantillons 16 bits.
• Les niveaux d'amplitude PCM DOIVENT suivre linéairement les variations SPL d'entrée sur une plage d'au moins 30 dB (de -18 dB à +12 dB avec 90 dB SPL au niveau du micro).
• La distorsion harmonique totale DOIT être inférieure à 1% pour 1 kHz à un niveau d'entrée SPL de 90 dB au niveau du micro.
• S'il est présent, le traitement de réduction du bruit DOIT être désactivé.
• Le contrôle de gain automatique, s'il est présent, DOIT être désactivé.

Si la plate-forme prend en charge des technologies de suppression du bruit optimisées pour la reconnaissance vocale, l'effet DOIT être contrôlable depuis 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 mise en œuvre de la technologie de suppression du bruit.

5.4.3. Capturer pour réacheminer 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:

• ANNEAU_DIFFUSION
• ALARME_FLUX
• NOTIFICATION_STREAM

5.5. Lecture audio

Les implémentations d'appareils qui déclarent android.hardware.audio.output DOIVENT être conformes aux exigences de cette section.

5.5.1. Lecture audio brute

L'appareil DOIT autoriser la lecture de contenus audio bruts présentant les caractéristiques suivantes:

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

L'appareil DOIT permettre la lecture de contenus audio bruts présentant les caractéristiques suivantes:

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

5.5.2. Effets audio

Android fournit une API pour les effets audio pour les implémentations sur les appareils. 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, LoudnessEnhancer.
• DOIT prendre en charge 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 contrôlables 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 être compatibles avec 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 audio compressée en passthrough (où aucun décodage audio n'est effectué sur l'appareil).

Les implémentations d'appareils Android Automotive DOIVENT permettre d'ajuster le volume audio séparément pour chaque flux audio à l'aide du type de contenu ou de l'utilisation définis par AudioAttributes et de l'utilisation de l'audio de la voiture telle que définie publiquement dans android.car.CarAudioManager .

5.6. Latence audio

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

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

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

Les implémentations d'appareils qui déclarent android.hardware.audio.output sont FORTEMENT RECOMMANDÉES pour répondre aux exigences de sortie audio suivantes, voire les dépasser:

• latence de sortie à froid de 100 millisecondes ou moins
• Latence de sortie continue inférieure ou égale à 45 millisecondes
• Minimiser la gigue à froid de sortie

Si l'implémentation d'un appareil répond aux exigences de cette section après un étalonnage initial lors de l'utilisation de l'API OpenSL ES PCM, 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. Inversement, si la mise en œuvre de l'appareil ne répond pas à ces exigences, elle NE DOIT PAS indiquer qu'elle prend en charge l'audio à faible latence.

Les implémentations d'appareils qui incluent android.hardware.micro sont VIVEMENT RECOMMANDÉES pour répondre à ces exigences audio d'entrée:

• latence d'entrée à froid de 100 millisecondes ou moins
• Latence d'entrée continue inférieure ou égale à 30 millisecondes
• une latence aller-retour continue de 50 millisecondes ou moins ;
• Minimiser la gigue d’entrée à froid

5.7. Protocoles de réseau

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

• Streaming progressif HTTP(S)
  Tous les codecs et formats de conteneur requis dans la section 5.1 DOIVENT être compatibles avec le protocole HTTP(S).

• Brouillon de protocole HTTP Live Streaming, version 7
  Les formats de segments multimédias suivants DOIVENT être acceptés:

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

• RTSP (RTP, SDP)

  Le profil vidéo RTP suivant et les codecs associés DOIVENT être compatibles. Pour les exceptions, veuillez consulter les notes de bas de tableau de la section 5.1.

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

5.8. Secure Media

Les implémentations d'appareils compatibles avec la sortie vidéo sécurisée et capables de prendre en charge des surfaces sécurisées DOIVENT déclarer la compatibilité avec Display.FLAG_SECURE. Les implémentations d'appareils qui déclarent la compatibilité avec Display.FLAG_SECURE, si elles prennent en charge un protocole d'affichage sans fil, DOIVENT sécuriser la liaison à l'aide d'un mécanisme cryptographiquement robuste, tel que HDCP 2.x ou version ultérieure pour les écrans sans fil Miracast. De même, s'ils sont compatibles avec un écran externe filaire, les implémentations d'appareils DOIVENT être compatibles HDCP 1.2 ou version ultérieure. Les appareils Android TV DOIVENT être compatibles 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 Android en amont est compatible avec les écrans sans fil (Miracast) et filaires (HDMI) qui répondent à cette exigence.

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

Si une implémentation d'appareil est compatible avec le transport logiciel MIDI (appareils MIDI virtuels) entre applications et sur tous les transports matériels compatibles 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.

Les transports matériels compatibles MIDI sont les suivants:

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

À l'inverse, si l'implémentation de l'appareil fournit une connectivité générique non-MIDI sur un transport matériel compatible MIDI spécifique indiqué ci-dessus, mais n'accepte pas le protocole MIDI via ce transport matériel, elle NE DOIT PAS signaler la prise en charge de la fonctionnalité android.software.midi.

5.10. Audio professionnel

Si l'implémentation d'un 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.

• La mise en œuvre de l'appareil DOIT indiquer la prise en charge de la fonctionnalité android.hardware.audio.low_Latency.
• La latence audio aller-retour continue, telle que définie dans la section 5.6 "Latence audio", DOIT être inférieure ou égale à 20 millisecondes et DOIT être inférieure ou égale à 10 millisecondes sur au moins un chemin pris en charge.
• Si l'appareil est équipé d'un connecteur audio 3,5 mm à 4 conducteurs, la latence audio aller-retour continue DOIT être de 20 millisecondes ou moins sur le chemin du connecteur audio, et de 10 millisecondes ou moins sur le chemin du connecteur audio.
• La mise en œuvre 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 est équipé d'un port HDMI, il DOIT être compatible avec une sortie stéréo et huit canaux avec une profondeur de 20 ou 24 bits et 192 kHz, sans perte de profondeur de bits ni rééchantillonnage.
• La mise en œuvre de l'appareil DOIT indiquer la prise en charge de la fonctionnalité android.software.midi.
• Si l'appareil est équipé d'un connecteur audio de 3,5 mm à quatre conducteurs, il est FORTEMENT RECOMMANDÉ de le mettre en œuvre afin de respecter les spécifications relatives aux appareils mobiles (connecteurs) du document Spécifications relatives aux casques audio filaires (v1.1).

Les latences et les exigences audio USB DOIVENT être satisfaites avec l'API de file d'attente de tampon PCM OpenSL ES.

En outre, une implémentation d'appareil indiquant la prise en charge de cette fonctionnalité DOIT:

• Offrez un niveau de performances de processeur durable lorsque l'audio est actif.
• Minimisez les inexactitudes et les dérives de l'horloge audio par rapport à l'heure standard.
• Minimiser la dérive de l'horloge audio par rapport au CLOCK_MONOTONIC du processeur lorsque les deux sont actifs.
• Minimiser la latence audio par rapport aux transducteurs intégrés à l'appareil
• Minimiser la latence audio via l'audio numérique USB
• Documentez les mesures de latence audio sur tous les chemins.
• Réduisez la gigue des temps d'entrée du rappel de fin de tampon audio, car cela affecte le pourcentage utilisable de la bande passante du processeur complète par le rappel.
• N'apportez aucune sous-utilisation (sortie) ou dépassement (entrée) audio dans des conditions d'utilisation normales avec une latence signalée.
• Aucune différence de latence entre les canaux n'est nécessaire.
• Minimiser la latence moyenne MIDI sur tous les transports
• Minimisez la variabilité de la latence MIDI en cas de charge (gigue) sur tous les transports.
• Fournissez des horodatages MIDI précis sur tous les transports.
• Réduisez le bruit du signal audio sur les transducteurs intégrés à l'appareil, y compris la période qui suit le démarrage à froid.
• N'indiquez aucune différence d'horloge audio entre les côtés d'entrée et de sortie des points de terminaison correspondants, lorsque les deux sont actifs. Exemples de points de terminaison correspondants : micro et haut-parleur de l'appareil, ou entrée et sortie du connecteur audio.
• Gère les rappels de complétion du tampon audio pour les côtés d'entrée et de sortie des points de terminaison correspondants sur le même thread lorsque les deux sont actifs, et entrez le rappel de sortie immédiatement après le retour du rappel d'entrée. S'il n'est pas possible de gérer les rappels sur le même thread, entrez le rappel de sortie peu de temps après la saisie du rappel d'entrée pour permettre à l'application d'avoir une synchronisation cohérente des côtés d'entrée et de sortie.
• Minimisez la différence de phase entre la mise en mémoire tampon de l'audio HAL pour les côtés entrée et sortie des points de terminaison correspondants.
• Réduisez la latence tactile.
• Minimisez la variabilité de la latence tactile en cas de charge (gigue).

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

À partir d'Android 7.0, une nouvelle source d'enregistrement a été ajoutée. Il est accessible à l'aide de la source audio android.media.MediaRecorder.AudioSource.UNPROCESSED. Dans OpenSL ES, vous pouvez y accéder à l'aide du préréglage d'enregistrement SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

Un appareil DOIT respecter toutes les exigences suivantes pour signaler la prise en charge de la source audio non traitée via la propriété android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED:

• L'appareil DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence approximativement plates dans la plage de fréquences moyennes: plus précisément, ±10 dB de 100 Hz à 7 000 Hz.

• L'appareil DOIT présenter des niveaux d'amplitude dans la plage des basses fréquences, plus précisément de ±20 dB de 5 Hz à 100 Hz par rapport à la plage de fréquences moyennes.

• L'appareil DOIT présenter des niveaux d'amplitude dans la plage des hautes fréquences, spécifiquement de ±30 dB de 7 000 Hz à 22 kHz par rapport à la plage de fréquences moyennes.

• La sensibilité de l'entrée audio DOIT être définie de sorte qu'une source de tonalités sinusoïdales de 1 000 Hz lue à un niveau de pression sonore (SPL) de 94 dB génère une réponse avec une RMS de 520 pour les échantillons de 16 bits (ou une valeur complète de -36 dB pour les échantillons à virgule flottante/double précision).

• SNR > 60 dB (différence entre 94 dB SPL et une valeur SPL équivalente de bruit propre, pondéré A).

• La distorsion harmonique totale DOIT être inférieure à 1% pour 1 kHZ à un niveau d'entrée SPL de 90 dB au niveau du micro.

• Le seul traitement de signal autorisé dans le chemin est un multiplicateur de niveau permettant d'atteindre la plage souhaitée. Ce multiplicateur de niveau NE DOIT PAS introduire de retard ni de latence dans le chemin du signal.

• Aucun autre traitement de signal n'est autorisé dans le chemin, comme le contrôle automatique du gain, le filtre passe haut ou l'annulation de l'écho. Si un traitement de signal est présent dans l'architecture pour une raison quelconque, il DOIT être désactivé et introduire zéro délai ou une latence supplémentaire dans le chemin du signal.

Toutes les mesures SPL sont effectuées directement à côté du micro testé.

Si vous utilisez plusieurs micros, ces exigences s'appliquent à chaque micro.

Il est FORTEMENT RECOMMANDÉ qu'un appareil réponde à autant d'exigences concernant le chemin du signal pour la source d'enregistrement non traitée. Toutefois, un appareil doit respecter toutes ces exigences, énumérées ci-dessus, s'il prétend être compatible avec la source audio non traitée.

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

6.1. Outils pour les développeurs

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

• Android Debug Bridge (adb) <ph type="x-smartling-placeholder">
  </ph>
  • Les implémentations d'appareils DOIVENT prendre en charge toutes les fonctions adb décrites dans le SDK Android, y compris dumpsys.
  • Le daemon adb côté appareil DOIT être inactif par défaut et il DOIT y avoir un mécanisme accessible à l'utilisateur pour activer Android Debug Bridge. Si l'implémentation d'un appareil omet le mode périphérique USB, il DOIT implémenter Android Debug Bridge via un réseau local (Ethernet ou 802.11, par exemple).
  • Android est compatible avec adb sécurisé. Le service adb sécurisé active adb sur des hôtes authentifiés connus. Les implémentations d'appareils DOIVENT être compatibles avec adb sécurisé.
• Service Dalvik Debug Monitor (ddms) <ph type="x-smartling-placeholder">
  </ph>
  • Les implémentations d'appareils DOIVENT prendre en charge toutes les fonctionnalités ddms décrites dans le SDK Android.
  • Étant donné que ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme ci-dessus.
• Les implémentations d'appareils Monkey DOIVENT inclure le framework Monkey et le mettre à la disposition des applications.
• SysTrace <ph type="x-smartling-placeholder">
  </ph>
  • 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 il DOIT y avoir un mécanisme accessible par l'utilisateur pour activer Systrace.
  • La plupart des systèmes Linux et Macintosh Apple reconnaissent les appareils Android à l'aide des outils SDK Android standards, sans assistance supplémentaire. mais les systèmes Microsoft Windows ont généralement besoin d'un pilote pour les nouveaux appareils Android. Par exemple, les nouveaux ID de fournisseurs et parfois les nouveaux ID d'appareils 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 comme fourni dans le SDK Android standard, les outils d'implémentation 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'appareils DOIVENT respecter l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS pour afficher les paramètres liés au développement d'applications. L'implémentation Android en amont masque le menu "Options pour les développeurs" par défaut et permet aux utilisateurs de lancer les options pour les développeurs après avoir appuyé sept (7) fois dans Paramètres > À propos de l'appareil > Élément de menu Build Number (Numéro de version). Les implémentations d'appareils DOIVENT fournir 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 ces options, cohérent avec l'implémentation Android en amont.

7. Compatibilité matérielle

Si un appareil inclut un composant matériel 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. Si une API du SDK interagit avec un composant matériel désigné comme facultatif et que l'implémentation de l'appareil ne possède pas ce composant:

• Les définitions de classe complètes (telles que documentées par le SDK) pour les API des composants DOIVENT toujours être présentées.
• Les comportements de l'API DOIVENT être implémentés en tant que no-ops d'une manière raisonnable.
• Les méthodes API DOIVENT renvoyer des valeurs nulles lorsque la documentation du SDK le permet.
• Les méthodes API DOIVENT renvoyer des implémentations no-op de classes dans lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.
• Les méthodes 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 type de scénario dans lequel ces exigences s'appliquent: même sur les appareils autres que des téléphones, ces API doivent être implémentées de manière à être implémentées de manière no-ops raisonnable.

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

7.1. Écran et graphismes

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

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

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

7.1.1. Configuration de l'écran

Taille d'écran

Le framework d'UI Android est compatible avec différentes tailles d'écran et permet aux applications d'interroger la taille d'é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 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 en dp (pixels indépendants de la densité) suivantes.

• La taille d'écran des appareils DOIT être d'au moins 426 dp x 320 dp ("petit", sauf s'il s'agit d'une montre Android).
• Les appareils dont la taille d'écran est définie sur "Normale" DOIT 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 "XL" DOIVENT avoir une taille d'écran d'au moins 960 dp x 720 dp.

De plus :

• Les montres Android DOIVENT disposer d'un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces.
• Les appareils Android Automotive DOIVENT disposer d'un écran dont la diagonale physique est supérieure ou égale à 6 pouces.
• La taille de l'écran des appareils Android Automotive DOIT être d'au moins 750 dp x 480 dp.
• Les autres types d'implémentations d'appareils Android dotés d'un écran intégré physiquement DOIVENT disposer d'un écran d'au moins 2,5 pouces en diagonale.

Les appareils NE DOIVENT EN AUCUN CAS modifier la taille d'écran indiquée.

Les applications peuvent éventuellement indiquer les tailles d'écran compatibles via l'écran <supports-screens> dans le fichier AndroidManifest.xml. Les implémentations d'appareils DOIVENT respecter correctement les exigences des applications prise en charge des écrans de petite taille, de taille normale, de grande taille et très grand, comme décrit dans la documentation du SDK Android.

Format de l'écran

Bien qu'il n'existe aucune restriction concernant la valeur du format de l'écran physique, le format de la surface sur laquelle les applications tierces sont affichées et qui peut être dérivé des valeurs signalées via DisplayMetrics DOIT respecter les exigences suivantes:

• Si uiMode est configuré sur UI_MODE_TYPE_WATCH, la valeur du format PEUT être définie sur 1.0 (1:1).
• Si l'application tierce indique qu'elle peut être redimensionnée via l'attribut android:resizeableActivity, il n'existe aucune restriction concernant la valeur du format.
• Dans tous les autres cas, le format DOIT être une valeur comprise entre 1,3333 (4:3) et 1,86 (environ 16:9), sauf si l'application a indiqué explicitement qu'elle accepte un format d'écran plus élevé via la valeur de métadonnées maxAspectRatio.

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 indiquer une seule des densités du framework Android Android suivantes via les API android.util.DisplayMetrics. Elles DOIVENT exécuter des applications à cette densité standard et NE DOIVENT PAS modifier cette valeur pour l'affichage par défaut.

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

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

Il est FORTEMENT RECOMMANDÉ d'implémenter les appareils pour fournir aux utilisateurs un paramètre permettant de modifier la taille d'affichage. Si une implémentation permet de modifier la taille d'affichage de l'appareil, elle DOIT s'aligner sur l'implémentation AOSP, comme indiqué ci-dessous:

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

Métriques sur le Réseau Display

Les implémentations d'appareils DOIVENT indiquer des valeurs correctes pour toutes les métriques d'affichage définies dans android.util.DisplayMetrics 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 compatibles (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIVENT indiquer au moins une orientation compatible. Par exemple, un appareil avec un écran à orientation fixe en mode paysage, comme un téléviseur ou un ordinateur portable, DOIT indiquer uniquement android.hardware.screen.landscape.

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

Les appareils DOIVENT indiquer la valeur correcte pour leur orientation actuelle lorsqu'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 ni la densité d'écran indiquées lors du changement d'orientation.

Accélération graphique 2D et 3D

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

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

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

Android fournit un pack d'extensions OpenGL ES avec des interfaces Java et une compatibilité native avec les fonctionnalités graphiques avancées telles que la tessellation et le format de compression de texture ASTC. Les implémentations d'appareils Android DOIVENT prendre en charge le pack d'extensions si l'appareil est compatible avec OpenGL ES 3.2 et PEUT le prendre en charge dans les autres cas. Si le pack d'extensions est pris en charge dans son intégralité, l'appareil DOIT identifier la compatibilité à l'aide du flag de fonctionnalité android.hardware.opengles.aep.

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

Notez qu'Android prend en charge les applications qui spécifient éventuellement qu'elles nécessitent des formats de compression de texture OpenGL spécifiques. Ces formats sont généralement propres au fournisseur. Les implémentations d'appareils ne sont pas requises par Android pour implémenter un format de compression de texture spécifique. Cependant, il DOIT indiquer avec précision les formats de compression de texture qu'ils prennent en charge, 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 des graphismes 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue en utilisant un tag de fichier manifeste android:hardwareAccelerated ou des appels d'API directs.

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

De plus, le comportement des implémentations d'appareils DOIT être cohérent avec celui de la documentation du SDK Android concernant l'accélération matérielle.

Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES avec accélération matérielle en tant que cibles de rendu dans une hiérarchie d'UI. Les implémentations d'appareils DOIVENT prendre en charge 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 prend en charge l'affichage 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.

Mode de compatibilité des anciennes applications

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

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

Technologie d'écran

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

• Les appareils DOIVENT prendre en charge les écrans capables d'afficher des images en couleurs 16 bits et DOIVENT prendre en charge des écrans compatibles avec ce type de graphique.
• Les appareils DOIVENT prendre en charge des écrans capables d'afficher des animations.
• Le format de pixel (PAR) de la technologie d'affichage DOIT être compris entre 0,9 et 1,15. Autrement dit, le rapport hauteur/largeur des pixels DOIT être proche du carré (1,0) avec une tolérance de 10 ~ 15 %.

Écrans secondaires

Android prend en charge les écrans secondaires pour activer les fonctionnalités de partage multimédia et les API de développement permettant d'accéder aux écrans externes. Si un appareil est compatible avec un écran externe via une connexion filaire, sans fil ou un écran supplémentaire intégré, l'implémentation de l'appareil DOIT implémenter l'API Display Manager comme décrit dans la documentation du SDK Android.

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

Les appareils DOIVENT prendre en charge 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 pour les appareils:

• 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é à l'adresse http://developer.android.com.
• DOIT fournir au moins une implémentation de clavier virtuel (qu'il y ait ou non un clavier physique), sauf pour les montres Android où la taille de l'écran rend l'utilisation d'un clavier virtuel moins raisonnable.
• 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 (QWERTY ou 12 touches).

7.2.2. Navigation non tactile

Implémentations pour les appareils:

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

7.2.3. Touches de navigation

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

• Les implémentations d'appareils portables Android 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 mettre la fonction Home à la disposition de l'utilisateur et la fonction Retour, sauf si elle se trouve dans UI_MODE_TYPE_WATCH .
• Les implémentations d'appareils Android Watch et aucun autre type d'appareil Android PEUVENT utiliser l'événement d'appui de manière prolongée sur l'événement clé KEYCODE_BACK et l'omettre d'être envoyé à l'application au premier plan.
• Les implémentations Android Automotive DOIVENT fournir la fonction d'accueil et PEUVENT fournir les fonctions "Retour" et "Récentes".
• 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 (par exemple, des boutons mécaniques ou tactiles capacitifs) ou à l'aide de touches logicielles dédiées sur une partie distincte de l'écran, de gestes, de l'écran tactile, etc. Android prend en charge ces deux implémentations. Toutes ces fonctions DOIVENT être accessibles en une seule action (appui, double-clic ou geste, par exemple) lorsqu'elles sont visibles.

La fonction "Récents", si elle est fournie, 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 mis à niveau à partir d'une version antérieure d'Android qui disposent de boutons physiques pour la navigation, mais pas de touches récentes.

Les fonctions Accueil et Retour, si elles sont fournies, DOIVENT avoir chacune 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 uiMode UI_MODE_TYPE_MASK est défini sur UI_MODE_TYPE_WATCH.

La fonction Menu a été abandonnée au profit de la barre d'action depuis Android 4.0. Par conséquent, les nouvelles implémentations d'appareils livrées avec Android 7.0 ou version ultérieure NE DOIVENT PAS comporter de bouton physique dédié à la fonction Menu. Les implémentations d'appareils plus anciennes NE DOIVENT PAS intégrer de bouton physique dédié à la fonction Menu, mais si ce bouton est implémenté et que l'appareil exécute des applications avec la valeur targetSdkVersion > 10, l’implémentation de l’appareil:

• DOIT afficher le bouton à développer sur la barre d'action lorsqu'il est visible et que la fenêtre 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 que vous passez à Android 7.0, ceci est RECOMMANDÉ.
• NE DOIT PAS modifier la position du pop-up de dépassement d'action affiché en sélectionnant le bouton à développer dans la barre d'action.
• PEUT afficher le pop-up de dépassement d'action à une position modifiée sur l'écran lorsqu'il est affiché 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 valeur targetSdkVersion est inférieure à 10, que ce soit par un bouton physique, une touche logicielle ou des gestes. Cette fonction 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 les actions d'assistance et/ou VoiceInteractionService DOIVENT pouvoir lancer une application d'assistance avec une seule interaction (appuyer, double-cliquer ou faire un geste, par exemple) lorsque d'autres touches de navigation sont visibles. Il est FORTEMENT RECOMMANDÉ d'appuyer de manière prolongée sur la page d'accueil pour cette interaction. L'interaction désignée DOIT lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente un VoiceInteractionService ou une activité gérant l'intent ACTION_ASSIST.

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

• Les touches de navigation d'implémentation de l'appareil DOIVENT utiliser une partie distincte de l'écran, qui n'est pas accessible aux applications et NE DOIVENT PAS masquer la partie de l'écran accessible aux applications ni gêner leur fonctionnement.
• Les configurations d'appareils DOIVENT mettre une partie de l'écran à la disposition des applications qui répondent 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'interface utilisateur système ou SYSTEM_UI_FLAG_VISIBLE.
• Les implémentations d'appareils DOIVENT présenter les touches de navigation de façon discrète (en mode sombre, par exemple) 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 (de type souris ou tactile). Toutefois, si une implémentation d'appareil n'est pas compatible avec un système de saisie de pointeur, elle NE DOIT PAS indiquer la constante de fonctionnalité android.hardware.touchscreen ou android.hardware.faketouch. Implémentations d'appareils qui incluent un système d'entrée de pointeur:

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

Android est compatible avec divers écrans tactiles, pavés tactiles et faux périphériques de saisie tactile. Les implémentations d'appareils à écran tactile sont associées à un écran de sorte que l'utilisateur ait l'impression de manipuler directement les éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système ne nécessite aucune affordance supplémentaire pour indiquer les objets manipulés. En revanche, une interface tactile simulée fournit un système de saisie utilisateur qui se rapproche d'un sous-ensemble des fonctionnalités de l'écran tactile. Par exemple, une souris ou une télécommande qui dirige un curseur à l'écran se rapproche d'un toucher tactile, mais oblige l'utilisateur à pointer ou à sélectionner une option, puis à cliquer. De nombreux périphériques d'entrée tels que la souris, le pavé tactile, la souris gyroscopique, le gyroscope, le joystick et le pavé tactile multipoint peuvent prendre en charge les interactions tactiles simulées. Android inclut la constante android.hardware.faketouch, qui correspond à un périphérique d'entrée haute fidélité non tactile (basé sur un pointeur), tel qu'une souris ou un pavé tactile, qui peut émuler de manière adéquate la saisie tactile (y compris la prise en charge des gestes de base). L'appareil indique que l'appareil est compatible avec un sous-ensemble émulé de fonctionnalités tactiles. Les implémentations d'appareils qui déclarent la fonctionnalité tactile simulée DOIVENT respecter les exigences de la section 7.2.5.

Les implémentations d'appareils DOIVENT indiquer la fonctionnalité appropriée correspondant au type d'entrée utilisé. Les implémentations d'appareils qui incluent un écran tactile (tactile unique ou plus) DOIVENT indiquer la constante android.hardware.touchscreen de la plate-forme. Les implémentations d'appareils qui indiquent la constante android.hardware.touchscreen de la plate-forme DOIVENT indiquer également la constante android.hardware.faketouch de la plate-forme. Les implémentations d'appareils qui n'incluent pas d'écran tactile (et qui s'appuient uniquement sur un pointeur) NE DOIVENT PAS signaler de fonctionnalité d'écran tactile, et DOIVENT indiquer uniquement android.hardware.faketouch si elles répondent aux exigences de la section 7.2.5 concernant l'écran tactile artificiel.

Saisie tactile simulée

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

• DOIT indiquer les positions absolues X et Y de l'emplacement du pointeur et afficher un pointeur visuel à l'écran.
• DOIT signaler l'événement tactile avec le code d'action qui spécifie le changement d'état qui se produit sur le pointeur descendant ou vers le haut sur l'écran.
• DOIT prendre en charge le pointeur vers le haut et vers le bas d'un objet à l'écran, ce qui permet aux utilisateurs d'émuler un appui sur un objet à l'écran.
• DOIT prendre en charge les pointeurs vers le bas, vers le haut, vers le bas, puis vers le haut au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler le double appui sur un objet à l'écran.
• DOIT prendre en charge le pointeur vers le bas sur un point arbitraire de l'écran, le déplacement vers n'importe quel autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un déplacement 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 le pointer vers le haut, ce qui permet aux utilisateurs de faire glisser un objet sur l'écran.

Les appareils qui déclarent prendre en charge android.hardware.faketouch.multitouch.distinct DOIVENT respecter les exigences liées à la fonctionnalité faketouch ci-dessus et DOIVENT également prendre en charge le suivi distinct d'au moins deux entrées de pointeur indépendantes.

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 l'implémentation de manettes de jeu qui répondent à cette exigence.

Mappages de boutons

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

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

1 Événement clé

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

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

4 MotionEvent

Commandes analogiques1	Utilisation HID	Bouton Android
Gâchette gauche	0x02, 0x00C5	AXIS_LTRIGGER
Déclencheur droit	0x02, 0x00C4	AXIS_RTRIGGER
Joystick gauche	0x01 0x0030 0 x 01, 0 x 0031	AXIS_X AXIS_Y
Joystick droit	0x01 0x0032 0 x 01, 0 x 0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Télécommande

Les implémentations d'appareils Android TV DOIVENT fournir une télécommande permettant aux utilisateurs d'accéder à l'interface du téléviseur. 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 respecter les exigences définies ci-dessous.

• Échelle de recherche : Les implémentations d'appareils DOIVENT déclencher KEYCODE_SEARCH lorsque l'utilisateur appelle la recherche vocale à l'aide de la télécommande physique ou logicielle.
• Navigation Toutes les télécommandes Android TV DOIVENT inclure les boutons "Retour", "Accueil" et "Sélectionner", et être compatibles avec les événements du pavé directionnel.

7.3. Capteurs

Android inclut des API permettant d'accéder à divers types de capteurs. Ces capteurs sont généralement omis dans les implémentations d'appareils, 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 dans la documentation Android Open Source sur les capteurs. Par exemple, les implémentations d'appareils:

• DOIT indiquer avec précision la présence ou l'absence de capteurs conformément à la classe android.content.pm.PackageManager.
• 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 la valeur "true" ou "false" selon le cas, lorsque les applications tentent d'enregistrer des écouteurs, et non en appelant les écouteurs de capteurs en l'absence des capteurs correspondants, etc.).
• DOIT indiquer toutes les mesures de capteurs en utilisant les valeurs du système international d'unités (métriques) pertinentes pour chaque type de capteur, tel que défini dans la documentation du SDK Android.
• DEVRAIT signaler l'heure de l'événement en nanosecondes comme défini dans la documentation du SDK Android, qui représente l'heure à laquelle l'événement s'est produit et synchronisé avec l'horloge SystemClock.elapsedRealtimeNano(). Il est VIVEMENT RECOMMANDÉ de répondre à ces exigences sur les appareils Android nouveaux et existants, afin de pouvoir passer aux futures versions de la plate-forme, qui pourraient devenir un composant OBLIGATOIRE. La durée de l'erreur de synchronisation DOIT être inférieure à 100 millisecondes.
• DOIT rapporter les données de capteurs avec une latence maximale de 100 millisecondes + 2 * échantillon_time pour le cas d'un capteur diffusé en continu avec une latence minimale requise de 5 ms + 2 * échantillon_time lorsque le processeur de l'application est actif. Ce délai n'inclut pas les délais de filtrage.
• DOIT indiquer le premier échantillon du capteur dans les 400 millisecondes + 2 * sample_time du capteur en cours d'activation. La justesse de cet échantillon peut être égale à 0.

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

Certains types de capteurs sont composites, ce qui signifie qu'ils peuvent être dérivés des données fournies par un ou plusieurs autres capteurs. (par exemple, le capteur d'orientation et le capteur d'accélération linéaire). Les implémentations d'appareils DOIVENT utiliser ces types de capteurs s'ils incluent des capteurs physiques préalables, comme décrit dans la section Types de capteurs. Si l'implémentation d'un appareil inclut un capteur composite, elle DOIT implémenter le capteur comme décrit dans la documentation Open Source d'Android sur les capteurs composites.

Certains capteurs Android acceptent un mode de déclenchement continu, qui renvoie des données en continu. Pour que toute API indiquée dans la documentation du SDK Android soit un capteur continu, les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques qui DOIVENT présenter une gigue inférieure à 3%, la gigue étant définie comme l'écart type de la différence entre les valeurs d'horodatage signalées entre des événements consécutifs.

Notez que les implémentations d'appareils DOIVENT s'assurer que le flux d'événements du capteur NE DOIT PAS empêcher le processeur de l'appareil de passer à l'état "suspendu" ou de sortir de l'état "suspendu".

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

7.3.1. Accéléromètre

Les implémentations d'appareils DOIVENT inclure un accéléromètre à 3 axes. Il est FORTEMENT RECOMMANDÉ d'inclure ce capteur sur les appareils portables Android, les implémentations Android Automotive et les montres Android. Si l'implémentation d'un appareil comprend un accéléromètre à 3 axes, celle-ci:

• DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER.
• DOIT pouvoir signaler des événements avec une fréquence d'au moins 50 Hz pour les montres Android Watch, car ces appareils ont une contrainte d'alimentation plus stricte et une fréquence de 100 Hz pour tous les autres types d'appareils.
• DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.
• DOIT respecter le système de coordonnées du capteur Android, tel que détaillé dans les API Android. Les implémentations Android Automotive DOIVENT être conformes au système de coordonnées du capteur de voiture Android.
• DOIT pouvoir mesurer de la chute libre jusqu'à quatre fois la gravité (4g) ou plus sur n'importe quel axe.
• DOIT avoir une résolution d'au moins 12 bits et DOIT avoir une résolution d'au moins 16 bits.
• DOIT être calibré en cours d'utilisation si les caractéristiques changent au cours du cycle de vie et sont compensées, et conservez les paramètres de compensation entre les redémarrages de l'appareil.
• DEVRAIT être compensé en température.
• DOIT avoir un écart type inférieur ou égal à 0,05 m/s^, où l'écart type doit être calculé par axe sur des échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide.
• DEVRAIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER, comme décrit dans le document du SDK Android. Il est VIVEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_SIGNIFICANT_MOTION sur les appareils Android nouveaux et existants. Si l'un de ces capteurs est implémenté, la somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW, et chaque capteur DOIT être inférieur à 2 mW et à 0,5 mW lorsque l'appareil est dans un état dynamique ou statique.
• Si un capteur gyroscope est inclus, DOIT utiliser les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION, et DOIT utiliser le capteur composite TYPE_GAME_ROTATION_VECTOR. Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_GAME_ROTATION_VECTOR sur les appareils Android nouveaux et existants.
• DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR si un capteur gyroscope et un capteur magnétomètre sont également inclus.

7.3.2. Magnétomètre

Les implémentations d'appareils DOIVENT inclure un magnétomètre (boussole) à 3 axes. Si un appareil comprend 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. Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED sur les appareils Android nouveaux et existants.
• DOIT pouvoir signaler des événements avec une fréquence d'au moins 10 Hz et DOIT rapporter des événements dont la fréquence est d'au moins 50 Hz.
• DOIT respecter le système de coordonnées du capteur Android, tel que détaillé dans les API Android.
• DOIT pouvoir mesurer entre -900 μT et +900 μT sur chaque axe avant la saturation.
• DOIT avoir une valeur de décalage du fer dur inférieure à 700 μT et une valeur inférieure à 200 μT, en plaçant le magnétomètre éloigné des champs magnétiques dynamiques (induits par le courant) et statiques (induits par l'aimant).
• DOIT avoir une résolution égale ou supérieure à 0,6 μT et DOIT avoir une résolution égale ou supérieure à 0,2 μT.
• DEVRAIT être compensé en température.
• DOIT prendre en charge l'étalonnage et la compensation en ligne du biais du fer dur, et préserver les paramètres de compensation entre les redémarrages de l'appareil.
• La compensation du fer doux DOIT être appliquée. L'étalonnage peut être effectué en cours d'utilisation ou pendant la production de l'appareil.
• DEVRAIT avoir un écart type, calculé par axe sur des échantillons collectés sur une période d'au moins 3 secondes au taux d'échantillonnage le plus rapide, ne dépassant pas 0,5 μT.
• DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR si un capteur d'accéléromètre et un capteur 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 DOIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode de traitement par lot à 10 Hz.

7.3.3. GPS

Les implémentations d'appareils DOIVENT inclure un récepteur GPS/GNSS. Si l'implémentation d'un appareil inclut un récepteur GPS/GNSS et signale la capacité aux applications via le flag de fonctionnalité android.hardware.location.gps:

• Il est FORTEMENT RECOMMANDÉ que l'appareil continue de fournir des sorties GPS/GNSS normales aux applications lors d'un appel téléphonique d'urgence, et que ces données de localisation ne soient pas bloquées pendant un appel téléphonique d'urgence.
• Il DOIT prendre en charge les sorties de données de localisation à une fréquence d'au moins 1 Hz lorsqu'elle est demandée via LocationManager#requestLocationUpdate .
• Il DOIT pouvoir déterminer la position en ciel ouvert (signaux forts, multi-chemins négligeables, HDOP < 2) en 10 secondes (temps nécessaire pour la première correction), lorsqu'elle est connectée à un débit Internet d'au moins 0,5 Mbit/s. Cette exigence est généralement satisfaite par l'utilisation d'une certaine forme de technique GPS/GNSS assistée ou prévue pour minimiser le temps de verrouillage GPS/GNSS (les données d'assistance comprennent l'heure de référence, l'emplacement de référence et les éphémères du satellite/l'horloge).
  • Une fois ce calcul de localisation effectué, il est FORTEMENT RECOMMANDÉ que l'appareil puisse déterminer sa position, à ciel ouvert, dans un délai de 10 secondes lorsque les demandes de localisation sont redémarrées, jusqu'à une heure après le calcul initial de la position, même si la demande suivante est effectuée sans connexion de données et/ou après un redémarrage.
• En ciel ouvert, après avoir déterminé la position, lorsque vous êtes à l'arrêt ou que vous vous déplacez avec un carré d'accélération inférieur à 1 mètre par seconde: <ph type="x-smartling-placeholder">
  </ph>
  • Il DOIT pouvoir déterminer la position dans un rayon de 20 mètres et la vitesse à 0,5 mètre par seconde au moins 95% du temps.
  • Il DOIT suivre et signaler simultanément via GnssStatus.Callback au moins huit satellites d'une constellation.
  • Il DOIT pouvoir suivre en même temps au moins 24 satellites de plusieurs constellations (par exemple, le GPS et au moins un satellite de Glonass, Beidou ou Galileo).
• Il DOIT indiquer la génération de la technologie GNSS via l'API de test "getGnssYearOfHardware".
• Il est FORTEMENT RECOMMANDÉ de respecter et DOIT respecter toutes les exigences ci-dessous si la génération de la technologie GNSS est signalée comme ayant l'année "2016" ou version ultérieure.
  • Il DOIT indiquer les mesures GPS dès qu'elles sont trouvées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
  • Il DOIT indiquer les pseudo-plages et taux de pseudo-plage GPS qui, dans des conditions de ciel ouvert après avoir déterminé la position, sont immobiles ou se déplacent avec un carré d'accélération inférieur à 0,2 mètre par seconde (au moins 95% du temps).

Remarque : bien que certaines des exigences relatives aux GPS ci-dessus soient indiquées comme étant VIVEMENT RECOMMANDÉES, la Définition de compatibilité pour la prochaine version majeure devrait les remplacer par des OBLIGATOIRES.

7.3.4. Gyroscope

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

• DOIT implémenter le capteur TYPE_GYROSCOPE et DEVRAIT également implémenter le capteur TYPE_GYROSCOPE_UNCALIBRATED. Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sur les appareils Android nouveaux et existants.
• DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.
• DOIT pouvoir signaler des événements avec une fréquence d'au moins 50 Hz pour les montres Android Watch, car ces appareils ont une contrainte d'alimentation plus stricte et une fréquence de 100 Hz pour tous les autres types d'appareils.
• DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.
• DOIT avoir une résolution de 12 bits ou plus et DOIT avoir une résolution de 16 bits ou plus.
• DOIT être compensée en température.
• DOIT être calibré et compensé en cours d'utilisation, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
• DOIT avoir une variance inférieure ou égale à 1e-7 rad^2 / s^2 par Hz (variance par Hz, ou rad^2 / s). La variance peut varier avec le taux d'échantillonnage, mais elle doit être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyroscope à un taux d'échantillonnage de 1 Hz, il 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 magnétomètre sont également inclus.
• Si un capteur d'accéléromètre est inclus, DOIT utiliser les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION, ainsi que le capteur composite TYPE_GAME_ROTATION_VECTOR. Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_GAME_ROTATION_VECTOR sur les appareils Android nouveaux et existants.

Le baromètre

Les appareils DOIVENT inclure un baromètre (capteur de pression de l'air ambiant). Si l'implémentation d'un appareil comprend un baromètre, celui-ci:

• DOIT implémenter et signaler le capteur TYPE_PRESSURE.
• DOIT pouvoir diffuser des événements dont la fréquence d'actualisation est supérieure ou égale à 5 Hz.
• DOIT disposer d'une précision suffisante pour permettre l'estimation de l'altitude.
• DOIT être compensée en température.

7.3.6. Thermomètre

Les appareils peuvent inclure un thermomètre ambiant (capteur de température). S'il est présent, il DOIT être défini comme SENSOR_TYPE_AMBIENT_TEMPERATURE et il 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 de capteur de température du processeur. S'il est présent, il DOIT être défini comme SENSOR_TYPE_TEMPERATURE, il DOIT mesurer la température du processeur de l'appareil et NE DOIT PAS mesurer d'autres températures. Notez que le type de capteur SENSOR_TYPE_TEMPERATURE a été abandonné dans Android 4.0.

7.3.7. Photomètre

Les implémentations d'appareils PEUVENT inclure un photomètre (capteur de luminosité ambiante).

7.3.8. Capteur de proximité

Les implémentations d'appareils PEUVENT inclure un capteur de proximité. Les appareils qui peuvent passer un appel vocal et indiquer une valeur autre que PHONE_TYPE_NONE dans getPhoneType DOIVENT inclure un capteur de proximité. Si l'implémentation d'un appareil inclut un capteur de proximité, celui-ci:

• 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 l'implémentation d'un 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 indiquées dans cette section DOIVENT être compatibles avec 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 répondant aux exigences de qualité ci-dessous:

• ACCÉLÉROMÈTRE_TYPE_CAPTEUR <ph type="x-smartling-placeholder">
  </ph>
  • DOIT avoir une plage de mesure comprise entre -8 g et +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 400 Hz ou plus.
  • DOIT enregistrer un bruit de mesure inférieur à 400 uG/√Hz.
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 3 mW.
  • DEVRAIT avoir un biais de bruit fixe de \<15 μg √Hz à partir d'un ensemble de données statique de 24 heures.
  • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 1 mg / °C.
  • DOIT présenter une non-linéarité ≤ 0,5 % de la courbe la plus adaptée et une variation de la sensibilité par rapport à la température de ≤ 0,03%/C°.

• GYROSCOPE_TYPE_CAPTEUR

  • DOIT avoir une plage de mesure comprise entre -1 000 et +1 000 dps.
  • DOIT avoir une résolution de mesure d'au moins 16 LSB/dps.
  • DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus.
  • DOIT enregistrer un bruit de mesure inférieur à 0,014 °/s/√ Hz.
  • DEVRAIT avoir un biais fixe et une stabilité de < 0,0002 °/s √Hz à partir d'un ensemble de données statique de 24 heures.
  • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 0,05 °/ s / °C.
  • DEVRAIT avoir un changement de sensibilité par rapport à une température ≤ 0,02% / °C.
  • DEVRAIT présenter une non-linéarité de droite la plus adaptée de ≤ 0,2%.
  • DEVRAIT avoir une densité de bruit ≤ 0,007 °/s/√Hz.

• SENSOR_TYPE_GYROSCOPE_UNCALIBRATED avec les mêmes exigences de qualité que SENSOR_TYPE_GYROSCOPE.

• SENSOR_TYPE_GEOMAGNETIC_FIELD <ph type="x-smartling-placeholder">
  </ph>
  • DOIT avoir une plage de mesure comprise entre -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.
  • DOIT présenter un bruit de mesure 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: <ph type="x-smartling-placeholder">
  </ph>
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 600 événements de capteur.
• PRESSION_TYPE_CAPTEUR <ph type="x-smartling-placeholder">
  </ph>
  • La plage de mesure DOIT être comprise entre 300 et 1 100 hPa au minimum.
  • DOIT avoir une résolution de mesure d'au moins 80 LSB/hPa.
  • DOIT avoir une fréquence de mesure minimale de 1 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 10 Hz ou plus.
  • DOIT enregistrer un bruit de mesure inférieur à 2 Pa/√Hz.
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 2 mW.
• VECTOR_SENSOR_TYPE_GAME_ROTATION_VECTOR <ph type="x-smartling-placeholder">
  </ph>
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 4 mW.
• MOTIF_SIGNIFICANT_TYPE_SENSEUR <ph type="x-smartling-placeholder">
  </ph>
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.
• SENSOR_TYPE_STEP_DETECTOR <ph type="x-smartling-placeholder">
  </ph>
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 100 événements de capteur.
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 4 mW.
• SENSOR_TYPE_STEP_COUNTER <ph type="x-smartling-placeholder">
  </ph>
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.
• SENSOR_TILT_DETECTOR <ph type="x-smartling-placeholder">
  </ph>
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.

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

• L'horodatage du même événement physique signalé par l'accéléromètre, le capteur du gyroscope et le magnétomètre DOIT se situer à une distance de moins de 2,5 millisecondes l'un de l'autre.
• Les codes temporels des événements du capteur du gyroscope DOIVENT être sur la même base de temps que le sous-système de l'appareil photo, avec un écart d'une milliseconde près.
• Les capteurs haute fidélité DOIVENT fournir des échantillons aux applications dans un délai de 5 millisecondes à compter du moment où les données sont disponibles sur le capteur physique de l'application.
• La consommation d'énergie ne doit PAS être supérieure à 0,5 mW lorsque l'appareil est statique et à 2 mW lorsque l'appareil est en mouvement lorsque l'une des combinaisons des capteurs suivants est activée: <ph type="x-smartling-placeholder">
  </ph>
  • MOTIF_SIGNIFICANT_TYPE_SENSEUR
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • DÉTECTEURS_TILT_DÉTECTEURS

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

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 les exigences minimales suivantes en termes de capacité de mise en mémoire tampon:

• SENSOR_TYPE_PROXIMITY: 100 événements liés au capteur

7.3.10. Lecteur d'empreinte digitale

Les implémentations d'appareils dotés d'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 intégralement l'API correspondante, comme décrit dans la documentation du SDK Android.
• DOIT avoir un taux de faux acceptations ne dépassant pas 0,002%.
• est VIVEMENT RECOMMANDÉ d'avoir un taux de faux refus inférieur à 10%, tel que mesuré sur l'appareil
• Il est FORTEMENT RECOMMANDÉ d'avoir une latence inférieure à une seconde, mesurée entre l'appui sur le lecteur d'empreinte digitale et le déverrouillage de l'écran, pour un doigt enregistré.
• DOIT limiter le débit des tentatives d'au moins 30 secondes après cinq faux essais de vérification de l'empreinte digitale.
• DOIT disposer d'une implémentation de keystore intégrée au matériel et effectuer la mise en correspondance des empreintes dans un environnement d'exécution sécurisé (TEE) ou sur une puce dotée d'un canal sécurisé vers le TEE.
• DOIT faire en sorte que toutes les données d'empreintes digitales identifiables soient chiffrées et authentifiées de manière cryptographique de sorte qu'elles ne puissent pas être acquises, lues ou modifiées en dehors de l'environnement d'exécution sécurisé (TEE), comme indiqué dans les consignes d'implémentation sur le site du projet Open Source Android.
• DOIT empêcher l’ajout d’une empreinte digitale sans établir au préalable une chaîne de confiance en demandant à l’utilisateur de confirmer des identifiants existants ou d’ajouter de nouveaux identifiants (code/modèle/mot de passe) sécurisés par TEE. l'implémentation du projet Android Open Source fournit le mécanisme dans le framework pour le faire.
• NE DOIVENT PAS permettre aux applications tierces de faire la distinction entre des empreintes digitales individuelles.
• DOIT respecter l'indicateur DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• En cas de mise à niveau à partir d'une version antérieure à Android 6.0, les données relatives aux empreintes digitales DOIVENT être migrées de manière sécurisée pour répondre aux exigences ci-dessus ou être supprimées.
• DEVRAIT utiliser l'icône d'empreinte Android fournie dans le projet Android Open Source.

7.3.11. Capteurs Android Automotive uniquement

Les capteurs propres à l'automobile sont définis dans le android.car.CarSensorManager API .

Engrenage actuel

Les implémentations Android Automotive DOIVENT fournir l'équipement actuel sous le nom SENSOR_TYPE_GEAR.

7.3.11.2. Mode Jour/Nuit

Les implémentations Android Automotive DOIVENT prendre en charge le mode Jour/Nuit défini sur SENSOR_TYPE_NIGHT. La valeur de cet indicateur DOIT être cohérente avec le mode Jour/Nuit du tableau de bord et DOIT être basée sur l'entrée du capteur de luminosité ambiante. Le capteur de luminosité ambiante sous-jacent PEUT être le même que le photomètre.

Statut en voiture

Les implémentations Android Automotive DOIVENT prendre en charge l'état de conduite défini sur "SENSOR_TYPE_DRIVING_STATUS", avec une valeur par défaut "Drive_STATUS_UNRESTRICTED" lorsque le véhicule est complètement à l'arrêt. Il est de la responsabilité des fabricants d'appareils de configurer SENSOR_TYPE_DRIVING_STATUS conformément à toutes les lois et réglementations en vigueur sur les marchés où le produit est expédié.

7.3.11.4. Vitesse de rotation

Les implémentations Android Automotive DOIVENT indiquer la vitesse du véhicule définie sur SENSOR_TYPE_CAR_SPEED.

7.3.12. Capteur de postures

Les implémentations d'appareils PEUVENT prendre en charge les capteurs de position à 6 degrés de liberté. Il est RECOMMANDÉ de prendre en charge ce capteur avec les appareils portables Android. Si une implémentation d'appareil prend en charge le capteur de pose avec 6 degrés de liberté, elle:

• DOIT implémenter et signaler le capteur TYPE_POSE_6DOF.
• DOIT être plus précis que le vecteur de rotation seul.

7.4. Connectivité des données

7.4.1. Téléphonie

Le terme "Téléphonie" utilisé par les API Android et ce document fait spécifiquement référence au matériel permettant de passer des appels vocaux et d'envoyer des SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent être ou non commutés de paquets, ils sont destinés aux besoins d'Android et sont considérés comme étant indépendants de toute connectivité de données pouvant être implémentée à l'aide du même réseau. En d'autres termes, la fonctionnalité de téléphonie et les API Android se réfèrent spécifiquement aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir des SMS NE DOIVENT PAS signaler la fonctionnalité android.hardware.telephony ni aucune sous-fonctionnalité, qu'elles utilisent ou non un réseau mobile pour la connectivité des données.

Android PEUT être utilisé sur des appareils qui n'incluent pas de matériel téléphonique. Autrement dit, Android est compatible avec les appareils autres que les téléphones. Toutefois, si l'implémentation d'un appareil inclut la téléphonie GSM ou CDMA, elle DOIT être entièrement compatible avec 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.

Compatibilité avec le blocage des numéros

Les implémentations d'appareils de téléphonie Android DOIVENT inclure la prise en charge du blocage des numéros et:

• DOIT implémenter intégralement BlockedNumberContract et l'API correspondante, comme décrit dans la documentation du SDK.
• DOIT bloquer tous les appels et messages provenant d'un numéro de téléphone dans "BlockedNumberProvider" sans aucune interaction avec les applications. Seule exception : le blocage des numéros est temporairement levé, comme décrit dans la documentation du SDK.
• NE DOIT PAS écrire dans le fournisseur de journaux d'appels de la plate-forme pour un appel bloqué.
• NE DOIT PAS écrire au fournisseur de téléphonie pour un message bloqué.
• DOIT implémenter une interface utilisateur de gestion des numéros bloqués, ouverte avec l'intent renvoyé par la méthode TelecomManager.createManageBlockedNumbersIntent().
• NE DOIT PAS permettre aux utilisateurs secondaires d'afficher ni de modifier les numéros bloqués sur l'appareil, car la plate-forme Android suppose que l'utilisateur principal a le contrôle total des services de téléphonie sur l'appareil (une seule instance). Toutes les interfaces utilisateur liées au blocage DOIVENT être masquées pour les utilisateurs secondaires, et la liste des utilisateurs bloqués DOIT quand même être respectées.
• DEVRAIT transférer les numéros bloqués vers le fournisseur lorsqu'un appareil passera à Android 7.0.

7.4.2. IEEE 802.11 (Wi-Fi)

Toutes les implémentations d'appareils Android DOIVENT inclure la prise en charge d'une ou plusieurs formes de la norme 802.11. Si l'implémentation d'un appareil prend en charge la norme 802.11 et expose la fonctionnalité à une application tierce, elle DOIT implémenter l'API Android correspondante et:

• DOIT signaler l'indicateur de fonctionnalité matérielle android.hardware.wifi.
• DOIT implémenter l'API Multicast comme décrit dans la documentation du SDK.
• DOIT prendre en charge le multicast DNS (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à aucun moment de l'opération, y compris dans les cas suivants: <ph type="x-smartling-placeholder">
  </ph>
  • Même lorsque l'écran n'est pas actif.
  • Pour les implémentations d'appareils Android TV, même lorsqu'elles sont en veille.

Wi-Fi Direct

Les implémentations d'appareils DOIVENT inclure la prise en charge du Wi-Fi Direct (Wi-Fi peer-to-peer). Si l'implémentation d'un appareil inclut la compatibilité avec le Wi-Fi Direct, il DOIT implémenter l'API Android correspondante, comme décrit dans la documentation du SDK. Lorsqu'un appareil est compatible avec le Wi-Fi Direct, celui-ci:

• DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct.
• DOIT être compatible avec le fonctionnement Wi-Fi standard.
• DEVRAIT prendre en charge les opérations Wi-Fi et Wi-Fi Direct simultanées.

7.4.2.2. Configuration du lien direct par tunneling en Wi-Fi

Les implémentations d'appareils DOIVENT inclure la prise en charge du TDLS (Wi-Fi Tunneled Direct Link Setup), tel que décrit dans la documentation du SDK Android. Si une implémentation d'appareil prend en charge TDLS et que TDLS est activé par l'API WiFiManager, l'appareil:

• DEVRAIT utiliser le TDLS uniquement lorsque cela est possible ET bénéfique.
• DEVRAIT utiliser une heuristique et NE PAS utiliser le TDLS lorsque ses performances pourraient être pires que de passer par le point d'accès Wi-Fi.

7.4.3. Bluetooth

Les implémentations d'appareils compatibles avec la fonctionnalité android.hardware.vr.high_performance DOIVENT prendre en charge les technologies Bluetooth 4.2 et Bluetooth LE Data Length Extension.

Android est compatible avec le Bluetooth et le Bluetooth à basse consommation. Les implémentations d'appareils qui prennent en charge le Bluetooth et le Bluetooth basse consommation DOIVENT déclarer les fonctionnalités pertinentes de la plate-forme (respectivement android.hardware.bluetooth et android.hardware.bluetooth_le) et implémenter les API de la plate-forme. Les implémentations d'appareils DOIVENT implémenter les profils Bluetooth appropriés, tels que A2DP, AVCP, OBEX, etc., en fonction de l'appareil.

Les implémentations Android Automotive DOIVENT prendre en charge le profil d'accès aux messages (MAP). Les implémentations Android Automotive DOIVENT prendre en charge les profils Bluetooth suivants:

• Appels téléphoniques via un profil mains libres (HFP).
• Lecture de contenus multimédias via un profil de distribution audio (A2DP).
• Contrôle de la lecture multimédia via le profil de contrôle à distance (AVRCP).
• Partage des contacts à l'aide du profil d'accès au répertoire téléphonique (PBAP)

Implémentations d'appareils, y compris la prise en charge de la technologie Bluetooth Low Energy:

• DOIT déclarer la fonctionnalité matérielle android.hardware.bluetooth_le.
• DOIT activer les API Bluetooth basées sur un profil d'attribut générique (GATT), comme décrit dans la documentation du SDK et dans android.bluetooth.
• Il est FORTEMENT RECOMMANDÉ d'implémenter un délai avant expiration d'une adresse privée pouvant être résolue (RPA) de 15 minutes maximum et d'alterner l'adresse une fois le délai expiré afin de protéger la confidentialité des utilisateurs.
• DOIT prendre en charge le déchargement de la logique de filtrage sur le chipset Bluetooth lors de l'implémentation de l'API ScanFilter 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.isOffloadingFilteringSupported().
• DOIT prendre en charge le déchargement de l'analyse par lot sur le chipset Bluetooth, mais si cela n'est pas pris en charge, DOIT indiquer "false" chaque fois que la requête est interrogée via la méthode android.bluetooth.BluetoothAdapter.isOffloadingScanBatchingSupported().
• DEVRAIT prendre en charge les annonces multiples avec au moins 4 emplacements, mais si cela n'est pas pris en charge, DOIT signaler "false" chaque fois que vous effectuez une requête via la méthode android.bluetooth.BluetoothAdapter.isMultipleAdvertiserSupported().

7.4.4. Communication en champ proche

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

• DOIT signaler la fonctionnalité android.hardware.nfc à l'aide de la méthode android.content.pm.PackageManager.hasSystemFeature().
• DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes: <ph type="x-smartling-placeholder">
  </ph>
  • DOIT être capable d'agir en tant que lecteur/rédacteur sur le forum NFC (tel que défini par la spécification technique du forum NFC NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes: <ph type="x-smartling-placeholder">
    </ph>
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • ISO Dep (ISO 14443-4)
    • Types de tags du forum NFC 1, 2, 3 et 4 (définis par le forum NFC)
  • VIVEMENT RECOMMANDÉ pour être capable de lire et d'écrire des messages NDEF ainsi que des données brutes via les normes NFC suivantes. Remarque : bien que les normes NFC ci-dessous soient déclarées comme FORTEMENT RECOMMANDÉES, il est prévu qu'elles soient remplacées par une OBLIGATION dans la définition de compatibilité d'une prochaine version. Ces normes sont facultatives dans cette version, mais seront obligatoires dans les futures versions. Les appareils nouveaux et existants qui exécutent cette version d'Android sont vivement encouragés à répondre à ces exigences dès maintenant afin de pouvoir effectuer la mise à niveau vers les futures versions de la plate-forme.
    • NfcV (ISO 15693)
  • DOIT être capable de lire le code-barres et l'URL (s'ils sont encodés) des produits code-barres NFC Thinfilm.
  • DOIT être capable de transmettre et de recevoir des données via les normes et protocoles peer-to-peer suivants: <ph type="x-smartling-placeholder">
    </ph>
    • ISO 18092
    • LLCP 1.2 (défini par le forum NFC)
    • SDP 1.0 (défini par le NFC Forum)
    • Protocole push NDEF
    • SNEP 1.0 (défini par le NFC Forum)
  • DOIT inclure la compatibilité avec Android Beam.
  • 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 la distribution des messages NDEF entrants.
  • DOIT respecter l'intent android.settings.NFCSHARING_SETTINGS pour afficher les paramètres de partage NFC.
  • 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 SNEP par défaut.
  • DOIT implémenter un client SNEP et tenter d'envoyer un NDEF P2P sortant au serveur SNEP par défaut lorsqu'Android Beam est activé. Si aucun serveur SNEP par défaut n'est trouvé, le client DOIT tenter d'envoyer un e-mail à un serveur NPP.
  • DOIT autoriser les activités de premier plan à définir le message NDEF P2P sortant à l'aide de android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback et android.nfc.NfcAdapter.enableForegroundNdefPush.
  • DEVRAIT utiliser un geste ou confirmer à l'écran, par exemple "Appuyer pour partager", avant d'envoyer des messages NDEF P2P sortants.
  • DEVRAIT activer Android Beam par défaut et DOIT pouvoir envoyer et recevoir des messages à l'aide d'Android Beam, même si un autre mode NFC P2p propriétaire est activé.
  • DOIT prendre en charge le transfert de la 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 passage de la connexion au Bluetooth lors de l'utilisation d'android.nfc.NfcAdapter.setBeamPushUris, en appliquant les spécifications Connection Handover version 1.2 (Transfert de connexion version 1.2) et Bluetooth Secure Simple Pairing Using NFC version 1.0 (Association simple sécurisée Bluetooth avec NFC version 1.0) du forum NFC. Une telle implémentation DOIT implémenter le service LLCP de transfert avec le nom de service "urn:nfc:sn:handover" pour échanger la demande de transfert/sélectionner des enregistrements via NFC, et elle DOIT utiliser le profil push d'objet Bluetooth pour le transfert de données Bluetooth réel. Pour d'anciennes raisons (pour rester compatible avec les appareils Android 4.1), l'implémentation DEVRAIT toujours accepter les requêtes SNEP GET pour échanger la demande de transfert/sélectionner des enregistrements via NFC. Cependant, une implémentation elle-même NE DOIT PAS envoyer de requêtes SNEP GET pour effectuer le transfert de connexion.
  • OBLIGATOIRE D'interroger toutes les technologies compatibles en mode découverte NFC.
  • DOIT être en mode de détection NFC lorsque l'appareil est activé, avec l'écran actif et l'écran de verrouillage déverrouillé.

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

Android est compatible avec le mode HCE (émulation de carte hôte NFC). Si l'implémentation d'un appareil inclut un chipset de contrôleur NFC compatible avec la technologie HCE (pour NfcA et/ou NfcB) et qu'il est compatible avec le routage de l'ID d'application (AID), elle:

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

Si l'implémentation d'un appareil inclut un chipset de contrôleur NFC compatible avec la technologie HCE pour NfcF, et qu'elle met en œuvre cette fonctionnalité pour des applications tierces:

• DOIT indiquer la constante de fonctionnalité android.hardware.nfc.hcef.
• DOIT implémenter les API d'émulation de cartes NFC telles que définies dans le SDK Android.

De plus, les implémentations d'appareils PEUVENT inclure une prise en charge des lecteurs/rédacteurs par les technologies MIFARE suivantes.

• MIFARE Classic
• MIFARE Ultralight
• NDEF sur MIFARE Classic

Notez qu'Android inclut des API pour ces types de MIFARE. Si l'implémentation d'un appareil est compatible avec MIFARE avec le rôle de lecteur/rédacteur:

• DOIT implémenter les API Android correspondantes, comme indiqué par le SDK Android.
• DOIT signaler la fonctionnalité com.nxp.mifare à l'aide de la méthode android.content.pm.PackageManager.hasSystemFeature(). Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et qu'elle n'apparaît donc pas comme une constante dans la classe android.content.pm.PackageManager.
• NE DOIT PAS implémenter les API Android correspondantes ni signaler la fonctionnalité com.nxp.mifare, sauf si elle est également compatible NFC générale, comme décrit dans cette section.

Si l'implémentation d'un appareil n'inclut pas de matériel NFC, il NE DOIT PAS déclarer la fonctionnalité android.hardware.nfc à l'aide de la méthode android.content.pm.PackageManager.hasSystemFeature(). Il DOIT implémenter l'API NFC Android en tant qu'opération no-op.

Étant donné que 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é NFC ou si elles ne déclarent pas la fonctionnalité android.hardware.nfc.

7.4.5. Capacité réseau minimale

Les implémentations d'appareils DOIVENT être compatibles avec 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 d'atteindre un débit de 200 kbit/s ou plus. Exemples de technologies répondant à cette exigence : EDGE, HSPA, EV-DO, 802.11g, Ethernet, PAN Bluetooth, etc.

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

Les appareils PEUVENT mettre en œuvre plusieurs formes de connectivité de données.

Les appareils DOIVENT inclure une pile réseau IPv6 et être compatibles avec 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 requis de compatibilité IPv6 dépend du type de réseau, comme suit:

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

IPv6 DOIT être activé par défaut.

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

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

7.4.6. Paramètres de synchronisation

Pour les implémentations d'appareils, le paramètre de synchronisation automatique principal DOIT être activé par défaut, de sorte que la méthode getMasterSyncAutomatic() renvoie la valeur "true".

7.4.7. Économiseur de données

Les implémentations d'appareils avec une connexion limitée sont FORTEMENT RECOMMANDÉES pour fournir le mode Économiseur de données.

Si une implémentation d'appareil fournit le mode Économiseur de données, celui-ci:

• DOIT prendre en charge toutes les API de la classe ConnectivityManager, comme décrit dans la documentation du SDK.

• DOIT fournir une interface utilisateur dans les paramètres permettant aux utilisateurs d'ajouter des applications à la liste d'autorisation ou d'en supprimer.

À l'inverse, si l'implémentation d'un appareil ne propose pas le mode Économiseur de données, celui-ci:

• DOIT renvoyer la valeur RESTRICT_BACKGROUND_STATUS_DISABLED pour ConnectivityManager.getRestrictBackgroundStatus()

• NE DOIT pas diffuser ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

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

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, en face de l'écran. c'est-à-dire qu'elle filme les scènes de l'autre côté de l'appareil, comme avec un appareil photo traditionnel. Une caméra frontale est une caméra située du même côté de l'appareil que l'écran. c'est-à-dire une caméra généralement utilisée pour filmer l'utilisateur, par exemple pour la visioconférence et d'autres applications similaires.

Si l'implémentation d'un appareil inclut au moins un appareil photo, une application DOIT pouvoir allouer simultanément trois bitmaps RGBA_8888 correspondant à la taille des images produites par le capteur photo ayant la plus grande résolution de l'appareil, alors que l'appareil photo est ouvert pour l'aperçu de base tout en effectuant une capture.

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 comprend au moins une caméra arrière:

• DOIT signaler l'indicateur de fonctionnalité android.hardware.camera et android.hardware.camera.any.
• DOIT avoir une résolution d'au moins 2 mégapixels.
• DOIT intégrer un autofocus matériel ou logiciel dans le pilote de l'appareil photo (transparent pour le logiciel d'application).
• PEUVENT comporter du matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
• PEUT inclure un flash. Si l'appareil photo comporte un flash, la lampe du flash NE DOIT PAS être allumée lorsqu'une instance android.hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de l'appareil photo, sauf si l'application a explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas à l'application de caméra système intégrée à l'appareil, mais uniquement aux applications tierces utilisant Camera.PreviewCallback.

7.5.2. Caméra frontale

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

• DOIT signaler l'indicateur de fonctionnalité android.hardware.camera.any et android.hardware.camera.front.
• DOIT avoir une résolution VGA d'au moins 640 x 480 pixels.
• NE DOIT PAS utiliser une caméra frontale par défaut pour l'API Camera. L'API d'appareil photo d'Android offre une prise en charge spécifique pour les caméras avant et les implémentations d'appareils NE DOIVENT PAS configurer l'API pour traiter une caméra avant comme la caméra arrière par défaut, même s'il s'agit de la seule caméra de l'appareil.
• PEUT inclure des fonctionnalités (autofocus, 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 dupliquer) le flux affiché par une application dans un CameraPreview, comme suit: <ph type="x-smartling-placeholder">
  </ph>
  • 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é la rotation de l'écran de l'appareil photo via un appel à la méthode android.hardware.Camera.setDisplayOrientation(), 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 dupliquer l'image affichée par la vue post-vue de la même manière que le flux d'image d'aperçu de l'appareil photo. Si l'implémentation de l'appareil n'est pas compatible avec la fonctionnalité "Postview", cette exigence ne s'applique évidemment pas.
• NE DOIT PAS mettre en miroir l'image fixe ou les flux vidéo finaux capturés, renvoyés aux rappels d'application ou validés dans l'espace de stockage multimédia.

7.5.3. Caméra externe

Les implémentations d'appareils PEUVENT inclure la prise en charge d'une caméra externe qui n'est pas nécessairement connectée en permanence. Si un appareil est compatible avec une caméra externe:

• DOIT déclarer les indicateurs de fonctionnalité de plate-forme android.hardware.camera.external et android.hardware camera.any .
• PEUT prendre en charge plusieurs appareils photo.
• DOIT prendre en charge la classe vidéo USB (UVC 1.0 ou version ultérieure) si la caméra externe est connectée via le port USB.
• DEVRAIT accepter les compressions vidéo telles que MJPEG pour permettre le transfert de flux d'image non encodés de haute qualité (c'est-à-dire des flux d'images bruts ou compressés indépendamment).
• PEUT prendre en charge l'encodage vidéo basé sur la caméra. S'il est pris en charge, un flux simultané non codé / MJPEG (QVGA ou plus haute résolution) DOIT être accessible à l'implémentation de l'appareil.

7.5.4. Comportement de l'API Camera

Android inclut deux packages d'API permettant d'accéder à l'appareil photo. La nouvelle API android.hardware.camera2 offre des commandes de niveau inférieur à l'application, y compris des flux de rafale et de streaming sans copie efficaces, ainsi que des commandes par image pour l'exposition, le gain, la balance des blancs, la conversion des couleurs, la suppression du bruit, l'amélioration de la netteté, etc.

L'ancien package d'API, android.hardware.Camera, est marqué comme obsolète dans Android 5.0, mais comme il devrait toujours être disponible pour les applications permettant d'utiliser des implémentations d'appareils Android, DOIT garantir la compatibilité 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 à l'appareil photo, 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 type byte[] transmis à onPreviewFrame() doivent en outre ê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 des caméras avant et arrière. (L'encodeur vidéo matériel et l'appareil photo peuvent utiliser n'importe quel format de pixel natif, mais la mise en œuvre de l'appareil DOIT être compatible avec la conversion au format YV12.)
• Pour android.hardware.camera2, les implémentations d'appareil doivent être compatibles avec les formats android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en tant que sorties 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, que l'appareil intègre ou non une mise au point automatique matérielle ou d'autres fonctionnalités. Par exemple, les appareils photo sans mise au point automatique DOIVENT appeler toutes les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela n'a aucun rapport avec un appareil photo sans mise au point automatique). Cette règle s'applique aux caméras avant, Par exemple, même si la plupart des caméras avant ne sont pas compatibles avec l'autofocus, les rappels de l'API doivent toujours être "faussés", comme indiqué dans la description.

Les implémentations d'appareils DOIVENT reconnaître et respecter chaque nom de paramètre défini en tant que constante dans la classe android.hardware.Camera.Parameters, si le matériel sous-jacent est compatible avec cette fonctionnalité. Si le matériel de l'appareil n'est pas compatible avec une fonctionnalité, l'API doit se comporter comme indiqué. À l'inverse, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître des constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters() autres que celles documentées en tant que constantes sur android.hardware.Camera.Parameters. Autrement dit, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres standards de l'appareil photo si le matériel le permet, et NE DOIVENT PAS être compatibles avec les types de paramètres d'appareil photo personnalisés. Par exemple, les implémentations d'appareils qui prennent en charge la capture d'image à l'aide de techniques d'imagerie HDR (High Dynamic Range) DOIVENT prendre en charge le paramètre de l'appareil photo Camera.SCENE_MODE_HDR.

Étant donné que toutes les implémentations d'appareils ne sont pas entièrement compatibles avec l'API android.hardware.camera2, celles-ci DOIVENT indiquer le niveau de compatibilité approprié avec la propriété android.info.supportedHardwareLevel décrite dans le SDK Android, et signaler les indicateurs de fonctionnalité du framework appropriés.

Les implémentations d'appareils DOIVENT également déclarer les fonctionnalités d'appareil photo individuelles d'android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés. un appareil doit définir un flag de fonctionnalité si l'une des caméras associées est compatible avec cette 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 cette image 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 la caméra et que l'entrée de l'image a été ajoutée au Media Store.

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 que la dimension longue de la caméra corresponde à 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 qu'elle s'applique aux appareils principaux en mode paysage ainsi qu'aux appareils en mode portrait.

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimaux

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

Densité et taille de l'écran	Appareil 32 bits	Appareil 64 bits
Appareils Android Watch (en raison de la petite taille de l'écran)	416 Mo	Non applicable
280 ppp ou moins sur les écrans de petite taille mdpi ou inférieur sur les grands écrans ldpi ou inférieur sur les très grands écrans	512 Mo	816 Mo
xhdpi ou supérieur sur les écrans de petite taille/normal hdpi ou supérieur sur les grands écrans mdpi ou supérieur sur les très grands écrans	608 Mo	944 Mo
400 ppp ou plus sur les écrans de petite taille xhdpi ou supérieur sur les grands écrans tvdpi ou supérieur sur les très grands écrans	896 Mo	1 280 Mo
560 ppp ou plus sur les écrans de petite taille ou de taille normale 400 ppp ou plus sur les grands écrans xhdpi ou supérieur sur les très grands écrans	1 344 Mo	1 824 Mo

Les valeurs de mémoire minimales DOIVENT s'ajouter à tout espace mémoire déjà dédié aux composants matériels tels que la radio, la vidéo, etc. qui n'est pas contrôlé par le noyau.

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

Les appareils Android TV DOIVENT disposer d'au moins 4 Go, et les autres implémentations d'appareils DOIVENT disposer d'au moins 3 Go d'espace de stockage non volatile disponible pour les données privées des applications. Autrement dit, la partition /data DOIT être d'au moins 4 Go pour les appareils Android Television et d'au moins 3 Go pour les autres implémentations d'appareils. Il est fortement recommandé de disposer d'au moins 4 Go d'espace de stockage non volatile pour les données privées des applications sur les appareils équipés d'Android afin de pouvoir effectuer une mise à niveau vers les futures versions de la plate-forme.

Les API Android incluent un Gestionnaire de téléchargement que des applications PEUVENT utiliser pour télécharger des fichiers de données. La mise en œuvre du Gestionnaire de téléchargement sur l'appareil DOIT être capable de télécharger des fichiers individuels d'une taille minimale de 100 Mo vers l'emplacement "cache" par défaut.

7.6.2. Stockage partagé des applications

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

Les implémentations d'appareils DOIVENT être configurées avec un espace de stockage partagé installé par défaut, "prêt à l'emploi". Si le stockage partagé n'est pas installé sur Linuxpath /sdcard, le périphérique DOIT inclure un lien symbolique Linux entre /sdcard et le point d'installation réel.

Les implémentations d'appareils PEUVENT comporter du matériel pour un support de stockage amovible accessible à l'utilisateur, tel qu'un emplacement pour carte SD (Secure Digital). Si cet emplacement est utilisé pour satisfaire aux exigences de stockage partagé, la mise en œuvre de l'appareil:

• DOIT ajouter un toast ou un pop-up d'avertissement à l'utilisateur lorsqu'il n'y a pas de carte SD.
• DOIT inclure une carte SD au format FAT d'au moins 1 Go OU montrer sur la boîte et tout autre support disponible au moment de l'achat que la carte SD doit être achetée séparément.
• Par défaut, la carte SD DOIT être installée.

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

Comme indiqué dans la documentation, les implémentations d'appareils DOIVENT appliquer l'autorisation android.permission.WRITE_EXTERNAL_STORAGE à cet espace de stockage partagé. Le 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é (par exemple, un emplacement pour carte SD et une mémoire de stockage interne partagée) DOIVENT n'autoriser que les appareils préinstallés et applications Android privilégiées disposant de l'autorisation WRITE_EXTERNAL_STORAGE pour écrire sur la mémoire de stockage externe secondaire, sauf lors de l'écriture dans leurs répertoires spécifiques au package ou dans le URI renvoyé en déclenchant l'intent ACTION_OPEN_DOCUMENT_TREE.

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

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

• DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer.
• DEVRAIT signaler une classe de périphérique USB de 0x00.
• DEVRAIT indiquer le nom d'interface USB « MTP ».

7.6.3. Stockage adoptable

Il est FORTEMENT RECOMMANDÉ de mettre en œuvre un stockage compatible si le port de l'appareil de stockage amovible se trouve dans un emplacement stable à long terme, comme le compartiment à piles ou un autre couvercle de protection.

Les implémentations d'appareils tels qu'un téléviseur PEUVENT permettre une adoption via des ports USB, car l'appareil est censé être statique et non mobile. Toutefois, pour les autres implémentations d'appareils par nature mobile, il est FORTEMENT RECOMMANDÉ d'implémenter le stockage adoptable dans un emplacement stable à long terme, car toute déconnexion accidentelle peut entraîner des pertes/corruptions 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.

7.7.1. Mode périphérique USB

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

• Le port DOIT pouvoir être connecté à un hôte USB doté d'un port USB standard de type A ou de type C.
• Le port DOIT utiliser un facteur de forme micro-B, micro-AB ou USB Type-C. Il est VIVEMENT RECOMMANDÉ de répondre à ces exigences sur les appareils Android nouveaux et existants, afin de pouvoir passer aux versions futures de la plate-forme.
• Le port DOIT se trouver en bas de l'appareil (en fonction de l'orientation naturelle) ou activer la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), de sorte que l'écran s'affiche correctement lorsque l'appareil est orienté avec le port situé en bas. Il est VIVEMENT RECOMMANDÉ de répondre à ces exigences sur les appareils Android nouveaux et existants, afin de pouvoir être mis à niveau vers les futures versions de la plate-forme.
• Il DOIT permettre à un hôte USB connecté à l'appareil Android d'accéder au contenu du volume de stockage partagé à l'aide du stockage de masse USB ou du protocole de transfert multimédia.
• Il DOIT implémenter l'API Android Open Accessory (AOA) et sa spécification comme indiqué dans la documentation du SDK Android. S'il s'agit d'un appareil portable Android, il DOIT implémenter l'API AOA. Implémentations d'appareils mettant en œuvre la spécification AOA: <ph type="x-smartling-placeholder">
  </ph>
  • DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.accessory.
  • DOIT implémenter la classe audio USB comme indiqué dans la documentation du SDK Android.
  • La classe de stockage de masse USB DOIT inclure la chaîne "android". à la fin de la description de l'interface iInterface chaîne de la mémoire de stockage de masse USB
• Il DEVRAIT prendre en charge la prise en charge d'un courant de 1,5 A pendant le bip et le trafic du haut-parleur, comme indiqué dans la révision 1.2 des spécifications de recharge de batterie USB. Il est VIVEMENT RECOMMANDÉ de répondre à ces exigences sur les appareils Android nouveaux et existants, afin de pouvoir passer aux versions futures de la plate-forme.
• Les appareils de type C DOIVENT détecter les chargeurs de 1,5 A et 3 A conformément à la norme de résistance de type C, et détecter les variations dans l'annonce.
• Les appareils de type C, également compatibles avec le mode hôte USB, sont VIVEMENT RECOMMANDÉS de prendre en charge Power Delivery pour l'échange de données et de rôles liés à l'alimentation.
• Les appareils de type C DOIVENT prendre en charge l'alimentation électrique pour la recharge haute tension et être compatibles avec d'autres modes, comme l'affichage.
• La valeur de iSerialNumber dans le descripteur d'appareil USB standard DOIT être égale à la valeur d'android.os.Build.SERIAL.
• Les appareils de type C sont FORTEMENT RECOMMANDÉS de ne pas prendre en charge les méthodes de recharge propriétaires qui modifient la tension Vbus au-delà des niveaux par défaut, ou qui modifient le rôle du récepteur ou de la source, ce qui peut entraîner des problèmes d'interopérabilité avec les chargeurs ou les appareils compatibles avec les modes USB Power Delivery standards. Bien que cela soit considéré comme "VENTEMENT RECOMMANDÉ", dans les futures versions d'Android, nous pourrions EXÉCUTER tous les appareils de type C pour assurer une interopérabilité totale avec les chargeurs standards de type C.

7.7.2. Mode hôte USB

Si l'implémentation d'un appareil inclut un port USB prenant en charge le mode hôte:

• DEVRAIT utiliser un port USB de type C si l'appareil est compatible avec USB 3.1.
• PEUT utiliser un facteur de forme de port non standard. Si tel est le cas, vous DEVEZ l'expédier avec un câble ou des câbles adaptant le port à un port USB standard de type A ou de type C.
• PEUT utiliser un port USB micro-AB, mais si tel est le cas, DEVEZ l'expédier avec un câble ou des câbles adaptant le port à un port USB standard de type A ou de type C.
• est VIVEMENT RECOMMANDÉ d'implémenter la classe audio USB comme indiqué dans la documentation du SDK Android.
• 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.
• DEVRAIT prendre en charge la recharge de l'appareil en mode hôte. indique un courant source d'au moins 1,5 A, comme indiqué dans la section "Paramètres de terminaison" de la [Révision 1.2 des spécifications du câble et des connecteurs USB Type-C] (http://www.usb.org/developers/docs/usb_31_021517.zip) pour les connecteurs USB Type-C, ou l'utilisation des spécifications du port de recharge en aval(CDP) sur la plage actuelle de recharge pour les connecteurs de recharge micro-USB 1.2.
• Les appareils USB Type-C sont VIVEMENT RECOMMANDÉS de prendre en charge DisplayPort, DOIVENT prendre en charge les débits de données USB SuperSpeed, et sont VIVEMENT RECOMMANDÉS de prendre en charge Power Delivery pour l'échange de données et de rôle de l'alimentation.
• Les appareils équipés de ports de type A ou de type AB NE DOIVENT PAS être expédiés avec un adaptateur convertissant ce port dans un réceptacle de type C.
• DOIT reconnaître tout appareil MTP (Media Transfer Protocol) connecté à distance et rendre leur contenu accessible via les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT et ACTION_CREATE_DOCUMENT, si le framework d'accès au stockage (SAF) est pris en charge.
• Si vous utilisez un port USB de type C et que vous proposez une prise en charge du mode périphérique, vous DEVEZ mettre en œuvre la fonctionnalité de port à double rôle, telle que définie par la spécification USB Type-C (section 4.5.1.3.3).
• DEVRAIT, si la fonctionnalité de port double rôle est prise en charge, implémentez le modèle try.* le plus adapté au facteur de forme de l'appareil. Par exemple, un appareil portable DEVRAIT implémenter le modèle try.SNK.

7.8. Audio

Micro

Il est possible que les implémentations d'appareils omettent l'utilisation d'un micro. Toutefois, si une implémentation d'appareil omet de micro, elle NE DOIT PAS signaler la constante de fonctionnalité android.hardware.micro, et DOIT implémenter l'API d'enregistrement audio au moins comme 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.micro.
• DOIT respecter les exigences concernant l'enregistrement audio décrites dans la section 5.4.
• DOIT respecter les exigences de latence audio décrites dans la section 5.6.
• FORTEMENT RECOMMANDÉ pour l'enregistrement par ultrasons proches, comme décrit dans la section 7.8.3.

Sortie audio

Mises en œuvre d'appareils comprenant un haut-parleur ou un port de sortie audio/multimédia pour un périphérique de sortie audio en tant que casque ou haut-parleur externe:

• DOIT indiquer la constante de fonctionnalité android.hardware.audio.output.
• DOIT respecter les exigences relatives à la lecture audio décrites dans la section 5.5.
• DOIT respecter les exigences de latence audio décrites dans la section 5.6.
• FORTEMENT RECOMMANDÉ pour prendre en charge la lecture par 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 au moins comme no-ops.

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

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, si un appareil comprend un ou plusieurs ports audio analogiques, au moins l'un des ports audio DOIT être un connecteur audio 3,5 mm à 4 conducteurs. Si un appareil est équipé d'un connecteur audio 3, 5 mm à quatre conducteurs:

• DOIT prendre en charge la lecture audio sur des casques stéréo et stéréo avec micro, et DEVRAIT prendre en charge l'enregistrement audio avec des casques stéréo avec micro.
• DOIT prendre en charge les prises audio TRRS dans l'ordre de broche CTIA et DEVRAIT prendre en charge les prises audio dans l'ordre de broche 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 la mise en correspondance des codes de clavier pour les trois plages suivantes d'impédance équivalente entre le micro et les conducteurs de terre sur la fiche audio: <ph type="x-smartling-placeholder">
  </ph>
  • 70 ohms ou moins : KEYCODE_HEADSETHOOK
  • 210-290 Ohm : KEYCODE_VOLUME_UP
  • 360-680 Ohm : KEYCODE_VOLUME_DOWN
• VIVEMENT RECOMMANDÉ de détecter et de mapper le code de clavier pour la plage d'impédance équivalente suivante entre le micro et les conducteurs de terre sur la prise audio: <ph type="x-smartling-placeholder">
  </ph>
  • 110-180 Ohm:KEYCODE_VOICE_ASSIST
• ACTION_HEADSET_PLUG DOIT déclencher ACTION_HEADSET_PLUG sur une fiche, mais seulement lorsque tous les contacts de la fiche sont en contact avec les segments correspondants du connecteur.
• DOIT être capable de générer au moins 150 mV ± 10% de la tension de sortie sur une impédance de haut-parleur de 32 Ohm.
• DOIT avoir une tension de biais du micro comprise entre 1,8 V et 2,9 V.

7.8.3. Presque ultra-sons

Le son proche par ultrasons correspond à la bande 18,5 kHz à 20 kHz. Les implémentations d'appareils DOIVENT indiquer correctement la prise en charge de la fonctionnalité audio proche ultrasons via l'API AudioManager.getProperty, comme suit:

• Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASound est défini sur "true", les sources audio VOICE_RECOGNITION et UNPROCESSED doivent respecter les conditions suivantes: <ph type="x-smartling-placeholder">
  </ph>
  • La réponse de puissance moyenne du micro dans la bande de 18,5 kHz à 20 kHz DOIT être inférieure de 15 dB à la réponse à 2 kHz.
  • Le rapport signal/bruit non pondéré du micro sur 18,5 kHz à 20 kHz pour un ton de 19 kHz à -26 dBFS DOIT ne pas être inférieur à 50 dB.
• Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASound est défini sur "true", la réponse moyenne de l'enceinte entre 18,5 kHz et 20 kHz DOIT être inférieure ou égale à 40 dB en dessous de la réponse à 2 kHz.

7.9. Réalité virtuelle

Android inclut des API et des installations permettant de créer des applications de "réalité virtuelle" (RV), y compris des expériences RV de haute qualité sur mobile. Les implémentations d'appareils DOIVENT implémenter ces API et ces comportements correctement, comme indiqué dans cette section.

7.9.1. Mode Réalité virtuelle

Les implémentations d'appareils portables Android qui prennent en charge un mode pour les applications de RV qui gère le rendu stéréoscopique des notifications et désactive les composants d'interface utilisateur du système monoculaire alors qu'une application de RV est axée sur l'utilisateur DOIVENT déclarer la fonctionnalité android.software.vr.mode. Les appareils qui déclarent cette fonctionnalité DOIVENT inclure une application implémentant android.service.vr.VrListenerService, qui peut être activée par les applications de RV via android.app.Activity#setVrModeEnabled .

7.9.2. Réalité virtuelle hautes performances

Les implémentations d'appareils portables Android DOIVENT identifier la prise en charge de la réalité virtuelle hautes performances pendant des périodes plus longues par l'intermédiaire du flag de fonctionnalité android.hardware.vr.high_performance et respecter les exigences suivantes.

• Les implémentations d'appareils DOIVENT comporter au moins deux cœurs physiques.
• Les implémentations d'appareils DOIVENT déclarer la fonctionnalité android.software.vr.mode.
• Les implémentations d'appareils PEUVENT fournir un cœur exclusif à l'application de premier plan et prendre en charge l'API Process.getExclusiveCores pour renvoyer le nombre de cœurs de processeur exclusifs à l'application de premier plan. Si un cœur exclusif est pris en charge, il ne DOIT autoriser aucun autre processus d'espace utilisateur à s'exécuter sur celui-ci (à l'exception des pilotes de périphériques utilisés par l'application), mais il PEUT permettre à certains processus du noyau de s'exécuter si nécessaire.
• Les implémentations d'appareils DOIVENT être compatibles avec le mode Performances soutenues.
• Les implémentations d'appareils DOIVENT prendre en charge OpenGL ES 3.2.
• Les implémentations d'appareils DOIVENT prendre en charge le niveau de matériel Vulkan de niveau 0 et DOIT prendre en charge le niveau de matériel Vulkan 1.
• Les implémentations d'appareils DOIVENT implémenter EGL_KHR_mutable_render_buffer et EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync et EGL_KHR_wait_sync afin qu'elles puissent être utilisées pour le mode de tampon partagé et exposer les extensions dans la liste des extensions EGL disponibles.
• Le GPU et l'écran DOIVENT être en mesure de synchroniser l'accès au tampon d'affichage partagé de sorte que le rendu en alternance des contenus de réalité virtuelle à 60 images par seconde avec deux contextes de rendu s'affiche sans artefacts de déchirure visibles.
• Les implémentations d'appareils DOIVENT implémenter EGL_IMG_context_Priority et exposer l'extension dans la liste des extensions EGL disponibles.
• Les implémentations d'appareils DOIVENT implémenter GL_EXT_multisample_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 et GL_OVR_multiview_multisample_render_to_texture, et exposer les extensions dans la liste des extensions GL disponibles.
• Les implémentations d'appareils DOIVENT mettre en œuvre les textures EGL_EXT_protect_content et GL_EXT_Protect_textures de sorte qu'elles puissent être utilisées pour la lecture vidéo de texture sécurisée, et exposer les extensions dans la liste des extensions EGL et GL disponibles.
• Les implémentations d'appareils DOIVENT prendre en charge le décodage H.264 d'au moins 3 840 x 2 160 à 30 FPS à 40 Mbit/s (équivalent à quatre instances de 1 920 x 1 080 à 30 FPS ou 10 Mbit/s ou 2 instances de 1 920 x 1 080 à 60 FPS et 20 Mbit/s).
• Les implémentations d'appareils DOIVENT prendre en charge les formats HEVC et VP9, être capables de décoder au moins 1 920 x 1 080 à 30 FPS à 10 Mbit/s et DOIVENT être capables de décoder 3 840 x 2 160 à 30 FPS et 20 Mbit/s (équivalent à 4 instances de 1 920 x 1 050 à 30 FPS).
• Les implémentations des appareils sont VIVEMENT RECOMMANDÉES pour prendre en charge la fonctionnalité android.hardware.sensor.hifi_sensors et DOIVENT respecter les exigences liées au gyroscope, à l'accéléromètre et au magnétomètre pour android.hardware.hifi_sensors.
• Les implémentations d'appareils DOIVENT prendre en charge l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs de température cutanée précises.
• La mise en œuvre de l'appareil DOIT être dotée d'un écran intégré, et sa résolution DOIT être au moins de FullHD(1080p) et FORTEMENT RECOMMANDÉ POUR ÊTRE en QuadHD (1440p) ou supérieure.
• L'écran DOIT mesurer entre 4,7 pouces et 6 pouces en diagonale.
• En mode RV, l'écran DOIT mettre à jour une fréquence d'au moins 60 Hz.
• La latence d'affichage en gris vers gris, du blanc au noir et du noir à blanc DOIT être ≤ 3 ms.
• L'affichage DOIT prendre en charge un mode à faible persistance avec une persistance inférieure ou égale à 5 ms,la persistance étant définie comme la durée pendant laquelle un pixel émet de la lumière.
• Les implémentations d'appareils DOIVENT prendre en charge les technologies Bluetooth 4.2 et Bluetooth LE Data Length Extension section 7.4.3.

8. Performances et puissance

Certains critères minimaux de performances et de puissance sont essentiels à l'expérience utilisateur et ont un impact sur les hypothèses de base que les développeurs auraient lorsqu'ils développent une application. Les montres Android DOIVENT et les autres types d'implémentations d'appareils DOIVENT répondre aux critères suivants.

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

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

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

Les implémentations d'appareils DOIVENT garantir la cohérence des performances d'accès aux fichiers de la mémoire 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 utilisant 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 utilisant 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 utilisant un tampon d'écriture de 4 Ko.

8.3. Modes d'économie d'énergie

Android 6.0 a introduit les modes d'économie d'énergie "Mise en veille des applications" et "Sommeil" pour optimiser l'utilisation de la batterie. Toutes les applications exemptées de ces modes DOIVENT être rendues visibles par l'utilisateur final. En outre, les algorithmes de déclenchement, de maintenance et de wakeup, ainsi que l'utilisation des paramètres système globaux de ces modes d'économie d'énergie NE DOIVENT PAS s'écarter de ceux du projet Android Open Source.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT implémenter une partie ou la totalité des quatre états de veille définis par l'ACPI (Advanced Configuration and Power Interface). Toutefois, si elles implémentent les états d'alimentation S3 et S4, elles ne peuvent entrer dans ces états que lors de la fermeture d'un couvercle qui fait physiquement partie de l'appareil.

8.4. Comptabilisation de la consommation d'énergie

Avec une comptabilisation et des rapports plus précis sur la consommation d'énergie, le développeur de l'application bénéficie à la fois des incitations et des outils nécessaires pour optimiser le modèle de consommation d'énergie de l'application. Par conséquent, les implémentations d'appareils:

• DOIT être en mesure de suivre la consommation d'énergie des composants matériels et de l'attribuer à des applications spécifiques. Plus précisément, les implémentations: <ph type="x-smartling-placeholder">
  </ph>
  • DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle de chaque composant matériel et la décharge approximative de la batterie causée par les composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
  • DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
  • DOIT être attribué au composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à une application.
  • DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence via l'implémentation du module de noyau uid_cputime.
• DOIT mettre cette consommation d'énergie à la disposition du développeur de l'application via la commande shell adb shell dumpsys batterystats.
• DOIT respecter l'intent android.intent.action.POWER_USAGE_SUMMARY et afficher un menu de paramètres qui indique cette consommation d'énergie.

8.5. Performances constantes

Les performances peuvent fluctuer considérablement pour les applications de longue durée très performantes, soit à cause des autres applications s'exécutant en arrière-plan, soit à cause de la limitation du processeur due aux limites de température. Android inclut des interfaces de programmation. Ainsi, lorsque l'appareil est compatible, l'application de premier plan peut demander au système d'optimiser l'allocation des ressources pour faire face à ces fluctuations.

Les implémentations d'appareils DOIVENT prendre en charge le mode Performances soutenues, qui peut fournir à l'application de premier plan un niveau de performances constant pendant une période prolongée lorsqu'elle est demandée via la méthode API Window.setSustainedPerformanceMode(). Une implémentation d'appareil DOIT indiquer précisément la prise en charge du mode Performances soutenues via la méthode API PowerManager.isSustainedPerformanceModeSupported().

Les implémentations d'appareils avec deux cœurs de processeur ou plus DOIVENT fournir au moins un cœur exclusif pouvant être réservé par l'application de premier plan. Si elles sont fournies, les implémentations DOIVENT répondre aux exigences suivantes:

• Les implémentations DOIVENT indiquer via la méthode d'API Process.getExclusiveCores() les numéros d'identification des cœurs exclusifs qui peuvent être réservés par l'application de premier plan supérieure.
• Les implémentations d'appareils NE DOIVENT PAS autoriser les processus d'espace utilisateur, à l'exception des pilotes de périphériques utilisés par l'application pour s'exécuter sur les cœurs exclusifs, mais PEUVENT permettre à certains processus du noyau de s'exécuter si nécessaire.

Si l'implémentation d'un appareil n'est pas compatible avec un cœur exclusif, elle DOIT renvoyer une liste vide via la méthode API Process.getExclusiveCores().

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

Les implémentations d'appareils DOIVENT implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API de la documentation pour les développeurs Android. 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 ou d'autorités. Plus précisément, les appareils compatibles DOIVENT prendre en charge les mécanismes de sécurité décrits dans les sous-sections suivantes.

9.1. Autorisations

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. Plus précisément, les implémentations DOIVENT appliquer chaque autorisation définie dans la documentation du SDK. aucune autorisation ne peut être omise, modifiée ni ignorée. Les implémentations PEUVENT ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'ID d'autorisation ne figurent pas dans l'espace de noms android.*.

Les autorisations dont l'protectionLevel est "PROTECTION_FLAG_PRIVILEGED" DOIVENT être accordées uniquement aux applications préchargées dans le ou les chemins privilégiés de la liste d'autorisation de l'image système, tels que le chemin system/priv-app dans l'implémentation AOSP.

Les autorisations dont le niveau de protection est dangereux sont des autorisations d'exécution. Applications avec targetSdkVersion > 22 lors de l'exécution. Implémentations pour les appareils:

• DOIT afficher une interface dédiée permettant à l'utilisateur de décider s'il faut accorder les autorisations d'exécution demandées et fournir une interface permettant à l'utilisateur de gérer les autorisations d'exécution.
• DOIT comporter 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 dans les cas suivants: <ph type="x-smartling-placeholder">
  </ph>
  • 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 de 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 indiqué dans la documentation de référence sur la sécurité et les autorisations.

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 défini dans la documentation de référence sur la sécurité et les autorisations.

9.4. Autres environnements d'exécution

Les implémentations d'appareils PEUVENT inclure des environnements d'exécution qui exécutent des applications à l'aide d'autres logiciels ou technologies que le format exécutable Dalvik ou du 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 être eux-mêmes des applications Android et respecter le modèle de sécurité Android standard, tel que décrit ailleurs dans la section 9.

Les autres environnements d'exécution 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 l'autorisation <uses-permission> sur le mécanisme d'attention.

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

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

• DEVRAIT installer des applications via 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.
• Les applications installées utilisant un autre environnement d'exécution NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf via les mécanismes Android standards de partage de l'ID utilisateur et du certificat de signature.
• NE DOIVENT PAS lancer ni accorder d'accès aux bacs à sable correspondant à d'autres applications Android, ni en accorder l'accès.
• NE DOIT PAS être lancé avec, ni accordé à d'autres applications, ni accordé à d'autres applications de droits de super-utilisateur (racine) ni de tout autre ID utilisateur.

Les fichiers .apk des environnements d'exécution alternatifs PEUVENT être inclus dans l'image système de l'implémentation d'un appareil, mais DOIVENT être signés avec une clé différente de celle utilisée pour signer d'autres applications incluses dans 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 il existe une autorisation Android correspondante (telle que l'appareil photo, le GPS, etc.), l'environnement d'exécution alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource. Si l'environnement d'exécution n'enregistre pas les capacités de l'application de cette manière, il DOIT indiquer 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 permet de gérer plusieurs utilisateurs et d'isoler complètement les utilisateurs. Les implémentations d'appareils PEUVENT permettre à plusieurs utilisateurs de fonctionner, mais lorsqu'elles sont activées, elles DOIVENT répondre aux exigences suivantes liées à la compatibilité multi-utilisateur:

• Les implémentations d'appareils Android Automotive pour lesquelles la compatibilité multi-utilisateur est activée DOIVENT inclure un compte invité permettant toutes les fonctions fournies par le système du véhicule sans que l'utilisateur ait besoin de se connecter.
• Les implémentations d'appareils qui ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony DOIVENT prendre en charge les profils restreints, une fonctionnalité qui permet aux propriétaires d'appareils de gérer d'autres utilisateurs et leurs fonctionnalités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts dans lesquels d'autres utilisateurs pourront travailler, tout en ayant la possibilité de gérer des restrictions plus précises pour les applications disponibles dans ces environnements.
• À l'inverse, les implémentations d'appareils qui déclarent l'indicateur de fonctionnalité android.hardware.telephony NE DOIVENT PAS prendre en charge les profils restreints, mais DOIVENT s'aligner sur l'implémentation AOSP des contrôles permettant d'autoriser /d'empêcher d'autres utilisateurs d'accéder aux appels vocaux et aux SMS.
• Les implémentations d'appareils DOIVENT, pour chaque utilisateur, mettre en œuvre un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API.
• Chaque instance d'utilisateur sur un appareil Android DOIT posséder des répertoires de stockage externe distincts et isolés. Les implémentations d'appareils PEUVENT stocker les données de plusieurs utilisateurs des données sur le même volume ou système de fichiers. Cependant, l'implémentation de l'appareil DOIT garantir que les applications détenues et exécutées pour le compte d'un utilisateur donné ne peuvent ni répertorier, lire, ni écrire sur 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 au moyen d'un PC hôte. Pour cette raison, les implémentations d'appareils qui utilisent des supports amovibles pour les API de stockage externe DOIVENT chiffrer le contenu de la carte SD si le mode multi-utilisateur est activé à l'aide d'une clé stockée uniquement sur un support non amovible accessible uniquement par le système. Étant donné que le contenu multimédia deviendra ainsi illisible pour un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour permettre aux PC hôtes d'accéder aux données de l'utilisateur actuel. Par conséquent, les implémentations sur les appareils PEUVENT, mais NE DOIVENT PAS activer le mode multi-utilisateur s'ils utilisent des supports amovibles comme stockage externe principal.

9.6. Avertissement relatif aux SMS premium

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

9.7. Fonctionnalités de sécurité 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), le système de bac à sable seccomp et d'autres fonctionnalités de sécurité dans le noyau Linux. SELinux ou toute autre fonctionnalité de sécurité implémentée dans le cadre d'Android:

• DOIT maintenir la compatibilité avec les applications existantes.
• NE DOIT PAS disposer d'une interface utilisateur visible en cas de détection d'une violation de sécurité et de blocage, mais PEUT disposer d'une interface utilisateur visible en cas de non-respect des règles de sécurité débloqué, entraînant ainsi un exploit réussi.
• NE DOIT PAS être configurable par l'utilisateur ou le développeur.

Si une API de configuration des stratégies est exposée à une application susceptible d'affecter une autre application (telle qu'une API Device Administration), l'API NE DOIT PAS autoriser les configurations rompant la compatibilité.

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

Implémentations pour les appareils:

• DOIT définir SELinux sur le mode d'application global.
• DOIT configurer tous les domaines en mode d'application. Aucun domaine en mode permissif n'est autorisé, y compris les domaines spécifiques à un appareil/fournisseur.
• NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le dossier system/sepolicy fourni dans le projet Android Open Source (AOSP) en amont. De plus, la stratégie DOIT se compiler avec toutes les règles "Neverallow" présentes, à la fois pour les domaines AOSP SELinux et pour les domaines spécifiques à l'appareil ou au fournisseur.
• DOIT diviser le framework multimédia en plusieurs processus afin qu'il soit possible d'accorder l'accès à chaque processus de manière plus précise, comme décrit sur le site du projet Android Open Source.

Les implémentations d'appareils DOIVENT conserver la règle SELinux par défaut fournie dans le dossier system/sepolicy du projet Android Open Source en amont et ne l'ajouter à cette règle 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.

Les appareils DOIVENT implémenter un mécanisme de bac à sable pour les applications de noyau permettant de filtrer les appels système à l'aide d'une règle configurable à partir de programmes multithread. Le projet Open Source Android en amont répond à cette exigence en activant seccomp-BPF avec la synchronisation des groupes de threads (TSYNC), comme décrit dans la section "Configuration du noyau" sur source.android.com.

9.8. Confidentialité

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

Si l'implémentation d'un appareil dispose d'un mécanisme qui achemine par défaut le trafic de données réseau via un serveur proxy ou une passerelle VPN (par exemple, le préchargement d'un service VPN avec android.permission.CONTROL_VPN accordé), l'implémentation de l'appareil DOIT demander le consentement de l'utilisateur avant d'activer ce mécanisme, sauf si le VPN est activé par l'outil de contrôle des règles relatives aux appareils via DevicePolicyManager.setAlwaysOnVpnPackage(). Dans ce cas, l'utilisateur n'a pas besoin de fournir un consentement distinct, mais il DOIT seulement en être notifié.

Les implémentations d'appareils DOIVENT être livrées avec un magasin d'autorité de certification vide ajouté par l'utilisateur, et DOIVENT préinstaller les mêmes certificats racine pour le magasin d'autorités de certification approuvés par le système que ceux fournis en amont dans le projet Android Open Source.

Lorsque les appareils sont acheminés via un VPN ou qu'une autorité de certification racine est installée, l'implémentation DOIT afficher un avertissement indiquant que le trafic réseau peut être surveillé par l'utilisateur.

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

9.9. Chiffrement du stockage des données

Si l'implémentation de l'appareil prend en charge un écran de verrouillage sécurisé comme décrit dans la section 9.11.1, l'appareil DOIT prendre en charge le chiffrement du stockage des données privées de l'application (/partition des données), 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 du stockage des données et dont les performances de chiffrement AES (Advanced Encryption Standard) sont supérieures à 50 Mio/s, le chiffrement du stockage des données DOIT être activé par défaut au moment de la configuration initiale de l'utilisateur. Si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android avec le chiffrement désactivé par défaut, cet appareil ne peut pas répondre aux exigences via une mise à jour logicielle système et PEUT donc être exempté.

Les implémentations d'appareils DOIVENT respecter les exigences de chiffrement du stockage des données ci-dessus via la mise en œuvre du chiffrement basé sur les fichiers (FBE).

9.9.1. Démarrage direct

Tous les appareils DOIVENT implémenter les API du mode Démarrage direct, même s'ils ne sont pas compatibles avec le chiffrement du stockage. En particulier, les intents LOCKED_BOOT_COMPLETED et ACTION_USER_UNLOCKED doivent toujours être diffusés pour signaler aux applications compatibles avec le démarrage direct que l'utilisateur peut accéder à des emplacements de stockage chiffrés sur l'appareil (DE) et CE.

9.9.2. Chiffrement basé sur les fichiers

Implémentations d'appareils compatibles avec FBE:

• DOIT démarrer sans demander d'identifiants à l'utilisateur et autoriser les applications compatibles avec le démarrage direct à accéder à l'espace de stockage chiffré de l'appareil après la diffusion du message LOCKED_BOOT_COMPLETED.
• NE DOIT autoriser l'accès au stockage chiffré par identifiants (CE) qu'une fois que l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (par exemple, code secret, code, schéma ou empreinte) et que le message ACTION_USER_UNLOCKED est diffusé. Les implémentations d'appareils NE DOIVENT PAS proposer de méthode permettant de déverrouiller le stockage protégé par la technologie CE sans les identifiants fournis par l'utilisateur.
• DOIT être compatible avec le démarrage validé et s'assurer que les clés DE sont liées de manière cryptographique à la racine de confiance matérielle de l'appareil.
• DOIT prendre en charge le chiffrement du contenu des fichiers à l'aide d'AES avec une longueur de clé de 256 bits en mode XTS.
• DOIT prendre en charge le chiffrement des noms de fichiers à l'aide de l'algorithme AES avec une longueur de clé de 256 bits en mode CBC-CTS.
• PEUVENT prendre en charge d'autres algorithmes de chiffrement, longueurs de clé et modes pour le chiffrement du contenu et des noms de fichiers, mais DOIT utiliser les algorithmes de chiffrement, longueurs de clé et modes obligatoires par défaut.
• DEVRAIT faire en sorte que les applis essentielles préchargées (par exemple Alarme, Téléphone, Messenger) soient compatibles avec le démarrage direct.

Clés protégeant les espaces de stockage CE et DE:

• DOIT être lié de manière cryptographique à un keystore intégré au matériel. Les clés CE doivent être liées aux identifiants de l'écran de verrouillage de l'utilisateur. Si l'utilisateur n'a spécifié aucun identifiant d'écran de verrouillage, les clés CE DOIVENT être liées à un code secret par défaut.
• DOIT être unique et distinct, c'est-à-dire que la clé CE ou DE d'un utilisateur ne peut pas correspondre à celle d'un autre utilisateur.

Le projet Android Open Source en amont fournit une implémentation à privilégier pour cette fonctionnalité, basée sur la fonctionnalité de chiffrement ext4 du noyau Linux.

9.9.3. Chiffrement complet du disque

Implémentations d'appareils compatibles avec le chiffrement complet du disque (FDE). DOIT utiliser l'algorithme AES avec une clé de 128 bits (ou plus) et un mode conçu pour le stockage (par exemple, AES-XTS ou AES-CBC-ESSIV). La clé de chiffrement NE DOIT PAS être écrite dans l'espace de stockage sans avoir été chiffrée. En dehors d'une utilisation active, la clé de chiffrement DOIT être chiffrée par AES avec les identifiants de l'écran de verrouillage étirés à l'aide d'un algorithme d'étirement lent (par exemple, PBKDF2 ou scrypt). Si l'utilisateur n'a pas spécifié d'identifiants d'écran de verrouillage ou a désactivé l'utilisation du code secret pour le chiffrement, le système DOIT utiliser un code secret par défaut pour encapsuler la clé de chiffrement. Si l'appareil fournit une base de données de clés avec support matériel, l'algorithme d'étirement de mot de passe DOIT être lié de manière cryptographique à ce magasin de clés. La clé de chiffrement NE DOIT PAS être envoyée depuis l'appareil (même si elle est encapsulée avec le code secret de l'utilisateur et/ou la clé liée au matériel). Le projet Open Source Android en amont fournit une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité de noyau Linux dm-crypt.

9.10. Intégrité de l'appareil

Les exigences suivantes garantissent la transparence de l'état d'intégrité de l'appareil.

Les implémentations d'appareils DOIVENT indiquer correctement, via la méthode PersistentDataBlockManager.getFlashLockState() de l'API système, si l'état de leur bootloader permet de flasher l'image système. L'état FLASH_LOCK_UNKNOWN est réservé aux implémentations d'appareils qui effectuent une mise à niveau à partir d'une version antérieure d'Android où cette nouvelle méthode d'API système n'existait pas.

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éclarez l'indicateur de fonctionnalité de la plate-forme android.software.valid_boot.
• Effectuez une vérification sur chaque séquence de démarrage.
• Commencez la validation à partir d'une clé matérielle immuable qui est la racine de confiance et remontez jusqu'à la partition système.
• Implémentez chaque étape de vérification pour vérifier l'intégrité et l'authenticité de tous les octets à l'étape suivante, avant d'exécuter le code lors de l'étape suivante.
• Utilisez des algorithmes de vérification aussi performants que les recommandations actuelles du NIST pour les algorithmes de hachage (SHA-256) et les tailles de clés publiques (RSA-2048).
• NE DOIT PAS autoriser le démarrage en cas d'échec de la vérification du système, sauf si l'utilisateur consent à tenter quand même de démarrer. Dans ce cas, les données des blocs de stockage non validés NE DOIVENT pas être utilisées.
• NE DOIT PAS autoriser la modification des partitions validées sur l'appareil, sauf si l'utilisateur a explicitement déverrouillé le bootloader.

Le projet Open Source Android 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 chiffrement AES (Advanced Encryption Standard) supérieures à 50 Mio/seconde DOIVENT prendre en charge le démarrage validé pour vérifier l'intégrité de l'appareil.

Si l'implémentation d'un appareil est déjà lancée sans être compatible avec le démarrage validé sur une version antérieure d'Android, l'appareil ne peut pas ajouter la prise en charge de cette fonctionnalité avec une mise à jour logicielle système et est donc exempté de cette exigence.

9.11. Clés et identifiants

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

Toutes les implémentations d'appareils Android DOIVENT répondre aux exigences suivantes:

• NE DEVRAIT pas limiter le nombre de clés pouvant être générées et DOIT autoriser au moins l'importation de plus de 8 192 clés.
• L'authentification sur l'écran de verrouillage DOIT limiter le taux de tentatives et DOIT comporter un algorithme d'intervalle exponentiel entre les tentatives. Au-delà de 150 tentatives infructueuses, le délai DOIT être d'au moins 24 heures par tentative.
• Lorsque l'implémentation de l'appareil est compatible avec un écran de verrouillage sécurisé, elle DOIT sauvegarder l'implémentation du keystore avec du matériel sécurisé et respecter les exigences suivantes: <ph type="x-smartling-placeholder">
  </ph>
  • DOIT disposer d'implémentations reposant sur du matériel d'algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que des fonctions de hachage des familles MD5, SHA1 et SHA-2, afin de prendre en charge correctement les algorithmes compatibles avec le système Android Keystore.
  • DOIT procéder à l'authentification de l'écran de verrouillage dans le matériel sécurisé et n'autoriser l'utilisation des clés liées à l'authentification qu'en cas de réussite. 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.

Notez que si l'implémentation d'un appareil est déjà lancée sur une version antérieure d'Android, l'appareil n'est pas tenu de disposer d'un keystore intégré au matériel, sauf s'il déclare la fonctionnalité android.hardware.fingerprint, qui nécessite un keystore intégré au matériel.

9.11.1. Écran de verrouillage sécurisé

Les implémentations d'appareils PEUVENT ajouter ou modifier des méthodes d'authentification pour déverrouiller l'écran de verrouillage, mais DOIVENT respecter les exigences suivantes:

• Si elle est basée sur un secret connu, la méthode d'authentification NE DOIT PAS être traitée comme un écran de verrouillage sécurisé, sauf si elle répond à toutes les exigences suivantes: <ph type="x-smartling-placeholder">
  </ph>
  • L'entropie de la longueur d'entrées la plus courte DOIT être supérieure à 10 bits.
  • L'entropie maximale de toutes les entrées possibles DOIT être supérieure à 18 bits.
  • NE DOIT remplacer aucune des méthodes d'authentification existantes (code, schéma, mot de passe) implémentées et fournies dans AOSP.
  • DOIT être désactivé lorsque l'application DPC (Device Policy Controller) a défini la règle de qualité des mots de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_SOMETHING .
• Si elle est basée sur un jeton physique ou sur l'emplacement, la méthode d'authentification NE DOIT PAS être traitée comme un écran de verrouillage sécurisé, sauf si elle répond à toutes les exigences suivantes: <ph type="x-smartling-placeholder">
  </ph>
  • Il DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principales basée sur un secret connu et répondant aux exigences pour être considéré comme un écran de verrouillage sécurisé.
  • Elle DOIT être désactivée et n'autoriser l'authentification principale à déverrouiller l'écran que lorsque l'application de contrôle des règles relatives aux appareils (DPC) a défini la règle avec la méthode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_UNSPECIFIED .
• Si elle est basée sur la biométrie, la méthode d'authentification NE DOIT PAS être traitée comme un écran de verrouillage sécurisé, sauf si elle répond à toutes les exigences suivantes: <ph type="x-smartling-placeholder">
  </ph>
  • Il DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principales basée sur un secret connu et répondant aux exigences pour être considéré comme un écran de verrouillage sécurisé.
  • Il DOIT être désactivé et n'autoriser l'authentification principale à déverrouiller l'écran que lorsque l'application DPC (Device Policy Controller) a défini la règle de fonctionnalité de protection en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • Il DOIT avoir un taux de faux taux d'acceptation égal ou supérieur à celui requis pour un lecteur d'empreinte digitale, tel que décrit dans la section 7.3.10. Il DOIT être désactivé et n'autoriser l'authentification principale pour déverrouiller l'écran que lorsque l'application DPC (Device Policy Controller) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• Si la méthode d'authentification ne peut pas être considérée comme un écran de verrouillage sécurisé: <ph type="x-smartling-placeholder">
  </ph>
  • DOIT renvoyer false pour les méthodes KeyguardManager.isKeyguardSecure() et KeyguardManager.isDeviceSecure().
  • DOIT être désactivé lorsque l'application DPC (Device Policy Controller) a défini la règle de qualité des mots de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_UNSPECIFIED .
  • NE DOIT PAS réinitialiser les délais d'expiration du mot de passe définis par DevicePolicyManager.setPasswordExpirationTimeout().
  • NE DOIT PAS authentifier l'accès aux keystores si l'application a appelé KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).
• Si la méthode d'authentification est basée sur un jeton physique, l'emplacement ou les données biométriques ayant un taux de faux acceptations supérieur à celui requis pour les capteurs d'empreinte digitale, comme décrit dans la section 7.3.10, elle: <ph type="x-smartling-placeholder">
  </ph>
  • NE DOIT PAS réinitialiser les délais d'expiration du mot de passe définis par DevicePolicyManager.setPasswordExpirationTimeout().
  • NE DOIT PAS authentifier l'accès aux keystores si l'application a appelé KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).

9.12. Suppression des données

Les appareils DOIVENT fournir aux utilisateurs un mécanisme permettant de rétablir la configuration d'usine. qui permet la suppression logique et physique de toutes les données, à l'exception des suivantes:

• Image système
• Tous les fichiers de système d'exploitation requis par l'image système

Toutes les données générées par l'utilisateur DOIVENT être supprimées. Cela DOIT respecter les normes sectorielles pertinentes pour la suppression des données, telles que NIST SP800-88. Il DOIT être utilisé pour l'implémentation de l'API clearData() (qui fait partie de l'API Android Device Administration) décrite dans la section 3.9 Administration des appareils.

Les appareils PEUVENT fournir une effacement rapide des données qui effectue une effacement des données logique.

9.13. Mode de démarrage sécurisé

Android propose un mode permettant aux utilisateurs de démarrer dans un mode où seules les applications système préinstallées sont autorisées à s'exécuter et toutes les applications tierces sont désactivées. Ce mode, appelé "mode de démarrage sécurisé", permet à l'utilisateur de désinstaller les applications tierces potentiellement dangereuses.

Les implémentations sur les appareils Android sont VIVEMENT RECOMMANDÉES pour implémenter le mode Démarrage sécurisé et répondre aux exigences suivantes:

• Les implémentations d'appareils DOIVENT fournir à l'utilisateur la possibilité d'activer le mode de démarrage sécurisé à partir du menu de démarrage, accessible via un workflow différent de celui du démarrage normal.

• Les implémentations d'appareils DOIVENT fournir à l'utilisateur la possibilité d'activer le mode de démarrage sécurisé de manière ininterrompue par rapport aux applications tierces installées sur l'appareil, sauf si l'application tierce est un outil de contrôle des règles relatives aux appareils et a défini l'indicateur UserManager.DISALLOW_SAFE_BOOT sur "true".

• Les implémentations d'appareils DOIVENT donner à l'utilisateur la possibilité de désinstaller des applications tierces en mode sans échec.

9.14. Isolation des systèmes de véhicule automobile

Les appareils Android Automotive doivent échanger des données avec des sous-systèmes critiques du véhicule, par exemple en utilisant le HAL du véhicule pour envoyer et recevoir des messages sur les réseaux du véhicule tels que le bus CAN. Les implémentations d'appareils Android Automotive DOIVENT implémenter des fonctionnalités de sécurité sous les couches du framework Android pour empêcher toute interaction malveillante ou involontaire entre le framework Android ou des applications tierces et les sous-systèmes des véhicules. Ces fonctionnalités de sécurité sont les suivantes:

• Contrôle des messages provenant de sous-systèmes de véhicule du framework Android, par exemple, ajout à la liste d'autorisation des types et des sources de messages autorisés
• Surveillance contre les attaques par déni de service à partir du framework Android ou d'applications tierces. Cela permet d'éviter que des logiciels malveillants inondent le réseau des véhicules de trafic, ce qui peut entraîner des dysfonctionnements dans leurs sous-systèmes.

10. Tests de compatibilité logicielle

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

Notez toutefois qu'aucun package de test logiciel n'est complet. C'est pourquoi les responsables de la mise en œuvre d'appareils sont VIVEMENT RECOMMANDÉS d'apporter le moins de modifications possible à la référence et à l'implémentation préférée d'Android disponible dans le projet Android Open Source. Cela réduira le risque d'introduire des bugs qui créent des incompatibilités nécessitant des préparations et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

Les implémentations d'appareils DOIVENT être validées par la suite de test de compatibilité Android (CTS) disponible dans le projet Android Open Source, avec le logiciel d'expédition final installé sur l'appareil. De plus, les responsables de la mise en œuvre d'appareils DOIVENT utiliser autant que possible l'implémentation de référence dans l'arborescence Android Open Source, et DOIVENT assurer la compatibilité en cas d'ambiguïté dans CTS et pour toute réimplémentation de parties du code source de référence.

La CTS est conçue pour être exécutée sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bugs. Les versions de la CTS seront indépendantes de cette définition de compatibilité, et plusieurs révisions de la CTS pourront être publiées pour Android 7.0. Les implémentations d'appareils DOIVENT passer avec succès la dernière version CTS disponible au moment où le logiciel de l'appareil est terminé.

10.2. Vérificateur CTS

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

L'outil de vérification CTS effectue 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 liés au matériel dont ils 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 l'outil de vérification CTS. Les scénarios de test des fonctionnalités indiquées comme facultatives dans ce document de définition de compatibilité PEUVENT être ignorés ou omis.

Chaque appareil et chaque build DOIVENT exécuter correctement l'outil de vérification CTS, comme indiqué ci-dessus. Cependant, étant donné que de nombreux builds sont très similaires, les développeurs d'appareils ne sont pas censés exécuter explicitement le vérificateur CTS sur les builds qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui diffèrent d'une implémentation ayant réussi le vérificateur CTS uniquement par l'ensemble des paramètres régionaux inclus, des éléments de branding, etc. PEUVENT omettre le test CTS Verifier.

11. Logiciels à mettre à jour

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

Vous pouvez utiliser n'importe quelle méthode, à condition qu'elle puisse remplacer l'intégralité du logiciel préinstallé sur l'appareil. Par exemple, l'une des approches suivantes répond à cette exigence:

• Téléchargements "Over The Air (OTA)" avec mise à jour hors connexion via un redémarrage
• Mises à jour "partagées" via USB à partir d'un PC hôte.
• Mises à jour "hors connexion" par un redémarrage et la mise à jour à partir d'un fichier stocké sur un espace de stockage amovible.

Toutefois, si l'implémentation de l'appareil inclut la prise en charge d'une connexion de données illimitée, comme le profil 802.11 ou le profil Bluetooth PAN (Personal Area Network), elle DOIT prendre en charge les téléchargements OTA avec une mise à jour hors connexion via un redémarrage.

Le mécanisme de mise à jour utilisé DOIT accepter 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 7.0 ou version ultérieure, le mécanisme de mise à jour DEVRAIT permettre de vérifier que l'image système est identique au résultat attendu après une OTA. La mise en œuvre de l'OTA basée sur des 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 les limites de la durée de vie raisonnable du produit, déterminée en collaboration avec l'équipe de compatibilité Android pour affecter la compatibilité des applications tierces, le responsable de la mise en œuvre de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible pouvant être appliquée conformément au mécanisme que nous venons de décrire.

Android inclut des fonctionnalités qui permettent à l'application Propriétaire de l'appareil (le cas échéant) de contrôler l'installation des mises à jour du système. Pour faciliter cette opération, le sous-système de mise à jour du système des appareils qui signalent android.software.device_admin DOIT implémenter le comportement décrit dans la classe SystemUpdatePolicy.

12. Journal des modifications du document

Pour obtenir un résumé des modifications apportées à la définition de compatibilité dans cette version:

• Journal des modifications du document

Pour obtenir un résumé des modifications apportées à des sections spécifiques:

1. Introduction
2. Types d'appareils
3. Logiciels
4. Package d'application
5. Multimédia
6. Options et outils pour les développeurs
7. Compatibilité matérielle
8. Performances et puissance
9. Modèle de sécurité
10. Test de compatibilité logicielle
11. Logiciel pouvant être mis à jour
12. Journal des modifications du document
13. Nous contacter

12.1. Conseils d'affichage du journal des modifications

Les modifications sont marquées comme suit:

• CDD
  Modifications importantes apportées aux exigences de compatibilité.

• Google Docs
  Modifications esthétiques ou liées à la construction.

Pour un affichage optimal, ajoutez les paramètres d'URL pretty=full et no-merges aux URL de votre journal de modifications.

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité Android pour demander des éclaircissements ou signaler des problèmes qui, selon vous, ne sont pas couverts par le document.