Définition de la compatibilité Android 7.0 (N)

Sommaire

1. Introduction

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

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

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

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

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

C'est pourquoi le Projet Android Open Source est à la fois l'implémentation de référence et l'implémentation privilégiée d'Android. Il est vivement recommandé aux implémentateurs d'appareils de baser leurs implémentations dans la mesure du possible sur le code source "en amont" disponible 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 réussir les tests logiciels deviendra beaucoup plus difficile. Il est de la responsabilité de l'implémentateur de s'assurer d'une compatibilité comportementale totale avec l'implémentation Android standard, y compris et au-delà de la Compatibility Test Suite. Enfin, notez que certaines substitutions et modifications de composants sont explicitement interdites par ce document.

De nombreuses ressources auxquelles ce document fait référence sont dérivées directement ou indirectement du SDK Android et seront fonctionnellement identiques aux informations de la documentation de ce SDK. Dans tous les cas où cette définition de la compatibilité ou la suite de tests de compatibilité ne sont pas conformes à la documentation du SDK, la documentation du SDK est considérée comme faisant autorité. Toutes les informations techniques fournies dans les ressources associées de ce document sont considérées comme faisant partie de cette définition de la compatibilité.

2. Types d'appareils

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

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

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

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

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

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

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

L'implémentation d'Android Automotive désigne une unité principale de véhicule qui utilise 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 avoir un écran dont la diagonale physique est égale ou supérieure à 15 cm.
  • DOIT déclarer la fonctionnalité android.hardware.type.automotive.
  • DOIT être compatible avec 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 respecter toutes les exigences de ce document pour être compatibles avec Android 7.0, sauf si l'exigence est explicitement décrite comme ne s'appliquant qu'à un type d'appareil Android spécifique ci-dessus.

2.1 Configurations de l'appareil

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

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

3. Logiciel

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

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

Les implémentations d'appareils DOIVENT prendre en charge/conserver toutes les 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 d'API, s'écarter du comportement documenté ni inclure de no-ops, sauf dans les cas spécifiquement autorisés par cette définition de compatibilité.

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

3.1.1. Extensions Android

Android prend en charge l'extension des API gérées tout en conservant le même 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, les implémentations d'appareils Android 7.0 exécutant le niveau d'API 24 DOIVENT inclure au moins la version 1.

3.2. Compatibilité des API avec une compatibilité douce

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

3.2.1. Autorisations

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

3.2.2. Paramètres de compilation

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

Paramètre Détails
VERSION.RELEASE Version du système Android actuellement en cours d'exécution, au format lisible. Ce champ DOIT contenir l'une des valeurs de chaîne définies dans 7.0.
VERSION.SDK Version du système Android en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 7.0, ce champ DOIT avoir 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 tiers. Pour Android 7.0, ce champ DOIT avoir la valeur entière 7.0_INT.
VERSION.INCREMENTAL Valeur choisie par l'implémentateur de l'appareil pour désigner la version spécifique du système Android actuellement en cours d'exécution, au format lisible par l'homme. Cette valeur NE DOIT PAS être réutilisée pour les différents builds mis à la disposition des utilisateurs finaux. Ce champ est généralement utilisé pour indiquer le numéro de build ou l'identifiant de modification de contrôle source utilisé pour générer le build. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide ("").
JEUX DE SOCIÉTÉ Valeur choisie par l'implémentateur de l'appareil pour identifier le matériel interne spécifique utilisé par l'appareil, au format lisible par l'homme. Ce champ peut être utilisé pour indiquer la révision spécifique de la carte alimentant l'appareil. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
MARQUE Valeur reflétant le nom de la marque associé à l'appareil tel que connu des utilisateurs finaux. DOIT être au format lisible par l'humain et DOIT représenter le fabricant de l'appareil ou la marque de l'entreprise sous laquelle l'appareil est commercialisé. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
SUPPORTED_32_BIT_ABIS Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
SUPPORTED_64_BIT_ABIS Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
CPU_ABI Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
CPU_ABI2 Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
APPAREIL Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code identifiant la configuration des fonctionnalités matérielles et la conception industrielle de l'appareil. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Ce nom d'appareil NE DOIT PAS changer pendant la durée de vie du produit.
FINGERPRINT Chaîne qui identifie de manière unique ce build. Il DOIT être raisonnablement lisible par l'humain. Il DOIT respecter ce modèle:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Exemple :

acme/myproduct/
    mydevice: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 contiennent des caractères d'espacement, ils DOIVENT être remplacés dans l'empreinte de compilation par un autre caractère, tel que le trait de soulignement ("_"). La valeur de ce champ DOIT être encodable en ASCII 7 bits.

MATÉRIEL Nom du matériel (à partir de la ligne de commande du kernel ou de /proc). Il DOIT être raisonnablement lisible par l'humain. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
ORGANISATEUR Chaîne qui identifie de manière unique l'hôte sur lequel le build a été créé, au format lisible par l'utilisateur. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide ("").
ID Identifiant choisi par l'implémentateur de l'appareil pour faire référence à une version spécifique, au format lisible par l'utilisateur. Ce champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisamment significative pour que les utilisateurs finaux puissent distinguer les builds logiciels. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$".
FABRICANT Nom commercial du fabricant d'équipement d'origine (OEM) du produit. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide ("").
MODÈLE Valeur choisie par l'implémentateur de l'appareil contenant le nom de l'appareil tel que connu par l'utilisateur final. Il doit s'agir du même nom que celui sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide ("").
PRODUIT Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code du produit spécifique (code SKU) qui DOIT être unique au sein de la même marque. DOIT être lisible par l'utilisateur, mais n'est pas nécessairement destiné à être vu par les utilisateurs finaux. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Ce nom de produit NE DOIT PAS changer pendant la durée de vie du produit.
SERIAL Un numéro de série matériel, qui DOIT être disponible et unique pour tous les appareils du même MODÈLE et du même FABRICANT. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^([a-zA-Z0-9]{6,20})$".
TAGS Liste de tags choisis par l'implémentateur de l'appareil, séparés par une virgule, qui permet de distinguer davantage le build. Ce champ DOIT contenir l'une des valeurs correspondant aux trois configurations de signature de la plate-forme Android standards : "release-keys", "dev-keys" et "test-keys".
DURÉE Valeur représentant le code temporel de la compilation.
MACH Valeur choisie par l'implémentateur de l'appareil, spécifiant la configuration d'exécution du build. Ce champ DOIT contenir l'une des valeurs correspondant aux trois configurations d'exécution Android typiques: user, userdebug ou eng.
UTILISATEUR Nom ou ID utilisateur de l'utilisateur (ou de l'utilisateur automatique) qui a généré le build. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni contenir la chaîne vide ("").
SECURITY_PATCH Valeur indiquant le niveau du correctif de sécurité d'un build. Il doit indiquer que le build n'est en aucun cas vulnérable à l'un des problèmes décrits dans le bulletin de sécurité public Android désigné. Elle doit être au format [AAAA-MM-JJ] et correspondre à une chaîne définie dans le Bulletin de sécurité public Android ou dans l'Avis de sécurité Android, par exemple "2015-11-01".
BASE_OS Valeur représentant le paramètre FINGERPRINT de la version, qui est par ailleurs identique à cette version, à l'exception des correctifs fournis dans le bulletin de sécurité publique Android. Il DOIT indiquer la valeur correcte. S'il n'existe pas de build correspondant, une chaîne vide ("") doit être renvoyée.

3.2.3. Compatibilité des intents

3.2.3.1. Intents d'application principaux

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

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

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

3.2.3.2. Résolution des intents

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

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

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

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

3.2.3.3. Espaces de noms d'intent

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

3.2.3.4. Intents de diffusion

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

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

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

Implémentations de l'appareil:

  • DOIT respecter l'intent android.settings.HOME_SETTINGS pour afficher un menu de paramètres d'application par défaut pour l'écran d'accueil, si l'implémentation de l'appareil signale android.software.home_screen.
  • DOIT fournir un menu de paramètres qui appelle l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT pour afficher une boîte de dialogue permettant de modifier l'application de SMS par défaut, si l'implémentation de l'appareil signale android.hardware.telephony.
  • DOIT respecter l'intent android.settings.NFC_PAYMENT_SETTINGS pour afficher un menu de paramètres d'application par défaut pour le paiement sans contact, si l'implémentation de l'appareil signale android.hardware.nfc.hce.
  • 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é du code natif est difficile. C'est pourquoi il est FORTEMENT RECOMMANDÉ aux implémentateurs d'appareils d'utiliser les implémentations des bibliothèques listées ci-dessous à partir du projet Open Source Android en amont.

3.3.1. Interfaces binaires d'application

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

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

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

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

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 (lecteur de liens dynamique)
  • libEGL.so (gestion des surfaces OpenGL natives)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (journalisation Android)
  • libmediandk.so (compatibilité avec les API multimédias natives)
  • libm (bibliothèque mathématique)
  • libOpenMAXAL.so (compatibilité avec OpenMAX AL 1.0.1)
  • libOpenSLES.so (compatibilité audio OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (compatibilité minimale avec C++)
  • libvulkan.so (Vulkan)
  • libz (compression zlib)
  • Interface JNI
  • Prise en charge d'OpenGL, comme décrit ci-dessous

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

Les bibliothèques natives non listées ci-dessus, mais implémentées et fournies dans AOSP en tant que bibliothèques système, sont réservées et NE DOIVENT PAS être exposées aux applications tierces qui ciblent le niveau d'API 24 ou une version ultérieure.

Les implémentations d'appareils PEUVENT ajouter des bibliothèques autres que l'AOSP et les exposer directement en tant qu'API aux applications tierces. Toutefois, 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, à leur tour, DOIVENT exporter tous les symboles de fonction OpenGL ES 3.1 et du pack d'extensions Android tels que définis dans la version android-24 du NDK. Bien que tous les symboles doivent être présents, seules les fonctions correspondantes pour les versions et extensions OpenGL ES réellement compatibles avec l'appareil doivent être entièrement implémentées.

3.3.1.1. Bibliothèques graphiques

Vulkan est une API multiplate-forme simple permettant la création de graphiques 3D hautes performances. Les implémentations d'appareils, même si elles n'incluent pas la prise en charge des API Vulkan, DOIVENT répondre aux exigences suivantes:

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

Implémentations de l'appareil, si elles incluent la prise en charge des API Vulkan:

  • 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 indiquer les indicateurs de fonctionnalité PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL et PackageManager#FEATURE_VULKAN_HARDWARE_VERSION appropriés.
  • DOIT énumérer les calques, contenus dans les bibliothèques natives nommées libVkLayer*.so dans le répertoire de bibliothèques natives du package d'application, via les fonctions vkEnumerateInstanceLayerProperties et vkEnumerateDeviceLayerProperties dans libvulkan.so
  • NE DOIT PAS énumérer les calques fournis par des bibliothèques en dehors du package d'application, ni fournir d'autres moyens de suivre ou d'intercepter l'API Vulkan, sauf si l'application dispose de l'attribut android:debuggable=”true”.

Implémentations d'appareils, si elles n'incluent pas la prise en charge des API Vulkan:

3.3.2. Compatibilité du code natif ARM 32 bits

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

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

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

  • "Fonctionnalités: ", suivi d'une liste des fonctionnalités de processeur ARMv7 facultatives compatibles avec l'appareil.
  • "Architecture du 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

Les appareils Android Watch peuvent, mais toutes les autres implémentations d'appareils doivent fournir une implémentation complète de l'API android.webkit.Webview.

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

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

  • La chaîne d'agent utilisateur signalée par la WebView DOIT respecter le format suivant:

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

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

Le composant WebView DOIT prendre en charge autant de fonctionnalités HTML5 que possible et, s'il le fait, DOIT respecter la spécification HTML5.

3.4.2. Compatibilité avec les navigateurs

Les implémentations d'Android Television, de Watch et d'Android Automotive PEUVENT omettre une application de navigateur, mais DOIVENT prendre en charge les modèles d'intent publics, comme décrit dans la section 3.2.3.1. Tous les autres types d'implémentations d'appareils DOIVENT inclure une application de navigateur autonome pour la navigation Web des utilisateurs.

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

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

L'application de navigateur autonome (qu'elle soit basée sur l'application de navigateur WebKit en amont ou sur un remplacement tiers) DOIT être compatible avec autant de fonctionnalités HTML5 que possible. Les implémentations d'appareils doivent au minimum prendre en charge chacune des API associées à HTML5:

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

3.5. Compatibilité du comportement des API

Les comportements de chacun des types d'API (gérée, souple, native et Web) doivent être cohérents avec l'implémentation privilégiée du projet Open Source Android 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 le cycle de vie ou la sémantique du cycle de vie d'un type particulier de composant système (tel que Service, Activity, ContentProvider, etc.).
  • Les appareils NE DOIVENT PAS modifier la sémantique d'une autorisation standard.

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

3.6. Espaces de noms d'API

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

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

Les modifications interdites incluent les suivantes :

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

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

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

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

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

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

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

Les implémentations d'appareils DOIVENT configurer les environnements d'exécution Dalvik pour allouer de la mémoire conformément à la plate-forme Android en amont et comme indiqué dans le tableau suivant. (Consultez la section 7.1.1 pour connaître les définitions de la taille et de la densité de l'écran.) Notez que les valeurs de mémoire spécifiées ci-dessous sont considérées comme des valeurs minimales, et que les implémentations d'appareils PEUVENT allouer plus de mémoire par application.

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

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur (écran d'accueil)

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

3.8.2. Widgets

Les widgets sont facultatifs pour toutes les implémentations d'appareils Android, mais ils DOIVENT être compatibles avec les appareils Android portables.

Android définit un type de composant, ainsi qu'une API et un cycle de vie correspondants, qui permettent aux applications d'exposer un AppWidget à l'utilisateur final. Il est vivement recommandé de prendre en charge cette fonctionnalité dans les implémentations d'appareils portables. Les implémentations d'appareils compatibles avec l'intégration de widgets sur l'écran d'accueil DOIVENT respecter les exigences suivantes et déclarer la prise en charge de la fonctionnalité de plate-forme android.software.app_widgets.

  • Les lanceurs d'appareils DOIVENT inclure une prise en charge intégrée des AppWidgets et exposer des affordances d'interface utilisateur permettant d'ajouter, de configurer, d'afficher et de supprimer des AppWidgets directement dans le lanceur.
  • Les implémentations d'appareils DOIVENT être capables d'afficher des widgets de 4 x 4 dans la taille de grille standard. Pour en savoir plus, consultez les Consignes de conception des widgets d'application dans la documentation du SDK Android.
  • Les implémentations d'appareils compatibles avec 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'informer 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 du son, des vibrations et de la lumière. Les implémentations d'appareils DOIVENT prendre en charge les notifications qui utilisent des fonctionnalités matérielles, comme décrit dans la documentation du SDK et dans la mesure du possible avec le matériel d'implémentation de l'appareil. Par exemple, si une implémentation d'appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibration. Si une implémentation d'appareil ne dispose pas de matériel, les API correspondantes DOIVENT être implémentées en tant que no-ops. Ce comportement est décrit plus en détail dans la section 7.

De plus, 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, qui, dans le cas d'un appareil Android TV, inclut la possibilité de ne pas afficher les notifications. Les implémentateurs d'appareils PEUVENT proposer une expérience utilisateur alternative pour les notifications que celle fournie par l'implémentation Android Open Source de référence. Toutefois, ces systèmes de notification alternatifs DOIVENT prendre en charge les ressources de notification existantes, comme indiqué ci-dessus.

Les implémentations Android Auto peuvent gérer la visibilité et le timing des notifications pour réduire la distraction du conducteur, mais doivent afficher les notifications qui utilisent CarExtender lorsque les applications le demandent.

Android est compatible avec diverses notifications, par exemple:

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

Lorsque ces notifications sont rendues visibles, les implémentations d'appareils Android DOIVENT exécuter correctement les notifications Rich et Heads-up, et inclure le titre/nom, l'icône et le texte, comme indiqué dans la documentation des 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 lorsqu'elles sont publiées ou mises à jour. Les implémentations d'appareils DOIVENT envoyer correctement et rapidement l'intégralité des notifications à tous ces services d'écouteur installés et activés par l'utilisateur, y compris toutes les métadonnées associées à l'objet Notification.

Les implémentations d'appareils compatibles avec la fonctionnalité Ne pas déranger DOIVENT répondre aux 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é dans laquelle l'utilisateur peut accorder ou refuser à l'application l'accès aux configurations de règles de Ne pas déranger.
  • DOIT : lorsque l'implémentation de l'appareil a fourni un moyen à l'utilisateur d'autoriser ou de refuser l'accès des applications tierces à la configuration de la règle de non-déranger, afficher les règles de non-déranger automatiques créées par les applications ainsi que les règles prédéfinies et créées par l'utilisateur.
  • 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.

Android inclut des API qui permettent aux développeurs d'intégrer la recherche dans leurs applications et d'exposer les données de leur application dans la recherche système globale. En général, cette fonctionnalité consiste en une interface utilisateur unique, à l'échelle du système, qui permet aux utilisateurs de saisir des requêtes, d'afficher des suggestions au fur et à mesure de la saisie et d'afficher des résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour fournir une recherche dans leurs propres applications et de fournir des résultats à l'interface utilisateur de recherche globale commune.

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

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

Android inclut également les API Assist, qui permettent 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 quand le contexte est partagé en affichant une lumière blanche autour des bords de l'écran. Pour 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 Open Source Android.

3.8.5. Notifications toast

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

3.8.6. Thèmes

Android fournit des "thèmes" 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" sous la forme d'un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent reproduire l'apparence du thème Holo tel que défini par le SDK Android. Les implémentations d'appareils NE DOIVENT PAS modifier les attributs du thème Holo exposé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 adapter l'apparence du thème de conception à la grande variété de types d'appareils Android. Les implémentations d'appareils DOIVENT prendre en charge la famille de thèmes "Material" et NE DOIVENT PAS modifier les attributs de thème Material ni les éléments exposés aux applications.

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

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

3.8.7. Fonds d'écran animés

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

Le matériel est considéré comme capable d'exécuter de manière fiable des fonds d'écran animés s'il peut exécuter tous les fonds d'écran animés, sans aucune limitation de fonctionnalité, à une fréquence d'images raisonnable et sans effet négatif sur d'autres applications. Si des limites matérielles provoquent le plantage ou le dysfonctionnement des fonds d'écran et/ou des applications, ou qu'elles consomment une quantité excessive d'énergie de la batterie ou du processeur, ou qu'elles s'exécutent à une fréquence d'images inacceptablement faible, le matériel est considéré comme incapable d'exécuter un fond d'écran animé. Par exemple, certains fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne s'exécute pas de manière fiable sur du matériel qui n'est pas compatible avec plusieurs contextes OpenGL, car l'utilisation d'un contexte OpenGL par le fond d'écran animé peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

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

3.8.8. Changement d'activité

Étant donné que la touche de navigation de la fonction "Récents" est FACULTATIVE, l'implémentation de l'écran d'aperçu est FACULTATIVE pour les implémentations Android Watch et Android Automotive, et RECOMMANDÉE pour les appareils Android Television. Il devrait toujours exister une méthode permettant de passer d'une activité à une autre dans les implémentations Android Auto.

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 tâches récemment consultées à l'aide d'une image miniature de l'état graphique de l'application au moment où l'utilisateur a quitté l'application pour la dernière fois. Les implémentations d'appareils incluant la touche de navigation de la fonctionnalité "Récents", comme indiqué 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.
  • DOIT afficher au moins le titre de quatre activités à la fois.
  • DOIVENT implémenter le comportement d'épinglage de l'écran et fournir à l'utilisateur un menu de paramètres pour activer/désactiver la fonctionnalité.
  • DOIT afficher la couleur de surbrillance, l'icône et le titre de l'écran dans les éléments récents.
  • DOIT afficher une affordance de fermeture ("x"), mais PEUT retarder cette action jusqu'à ce que l'utilisateur interagisse avec les écrans.
  • DOIT implémenter un raccourci pour passer facilement à l'activité précédente
  • PEUT afficher les éléments récents associés sous forme de groupe qui se déplace ensemble.
  • DOIT déclencher l'action de commutation rapide entre les deux applications les plus récemment utilisées lorsque la touche de fonction "Récents" est enfoncée deux fois.
  • DOIT déclencher le mode multifenêtre en écran partagé, le cas échéant, lorsque la touche de fonction "Récents" est enfoncée de manière prolongée.

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

3.8.9. Gestion des entrées

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

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

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

L'API Client de télécommande est obsolète à partir d'Android 5.0 et est remplacée par le modèle de notification multimédia, qui permet aux applications multimédias de s'intégrer aux commandes de lecture affichées sur l'écran de verrouillage. Les implémentations d'appareils compatibles avec un écran de verrouillage, sauf si elles sont implémentées pour Android Automotive ou une montre, DOIVENT afficher les notifications de 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 écrans de veille interactifs, auparavant appelés Dreams. Les écrans de veille permettent aux utilisateurs d'interagir avec les applications lorsqu'un appareil connecté à une source d'alimentation est inactif ou posé sur une station d'accueil. Les appareils Android Watch PEUVENT implémenter des économiseurs d'écran, mais les autres types d'implémentations d'appareils DOIVENT prendre en charge les économiseurs d'écran et fournir une option de paramètres permettant aux utilisateurs de les configurer en réponse à l'intent android.settings.DREAM_SETTINGS.

3.8.12. Position

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

3.8.13. Unicode et police

Android est compatible avec les caractères emoji définis dans Unicode 9.0. Toutes les implémentations d'appareils DOIVENT être capables d'afficher ces caractères emoji sous forme de glyphes en couleur. Lorsque les implémentations d'appareils Android incluent un IME, celui-ci DOIT fournir à l'utilisateur une méthode de saisie pour ces caractères emoji.

Les appareils Android portables DOIVENT être compatibles avec les emoji de couleur de peau et les différentes familles d'emoji, comme indiqué dans le rapport technique Unicode 51.

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

3.8.14. Multifenêtre

Une implémentation d'appareil peut choisir de ne pas implémenter de modes multifenêtre, mais si elle est capable d'afficher plusieurs activités en même temps, elle DOIT implémenter ces modes multifenêtre conformément aux comportements d'application et aux API décrits dans la documentation d'assistance sur le 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, soit explicitement via l'attribut android:resizeableActivity, soit implicitement en définissant la valeur targetSdkVersion sur > 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 fournir un avertissement indiquant que l'application risque de ne pas fonctionner comme prévu en mode multifenêtre.
  • Les implémentations d'appareils NE DOIVENT PAS proposer de 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 DOIVENT être compatibles avec le mode Format libre.
  • Les implémentations d'appareils Android TV DOIVENT être compatibles avec le mode multifenêtre Picture-in-picture (PIP) et placer le mode multifenêtre PIP en haut à droite lorsque le mode PIP est activé.
  • Les implémentations d'appareils compatibles avec le mode PIP et le mode multifenêtre DOIVENT allouer au moins 240 x 135 dp pour la fenêtre PIP.
  • Si le mode multifenêtre PIP est compatible, la touche KeyEvent.KEYCODE_WINDOW DOIT être utilisée pour contrôler la fenêtre PIP. Sinon, la touche DOIT être disponible pour l'activité de premier plan.

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux applications axées sur la sécurité d'effectuer des fonctions d'administration d'appareils au niveau du système, telles que l'application de règles de mot de passe ou l'effacement à distance, via l'API Android Device Administration. 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 de l'appareil

3.9.1.1 Provisionnement du propriétaire de l'appareil

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

Les implémentations d'appareils PEUVENT inclure une application préinstallée qui effectue des fonctions d'administration de l'appareil, mais cette application NE DOIT PAS être définie comme application du propriétaire de l'appareil sans le consentement explicite ou l'action de l'utilisateur ou de l'administrateur de l'appareil.

3.9.1.2 Provisionnement de profils gérés

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

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

Les implémentations d'appareils DOIVENT fournir les affordances utilisateur suivantes dans l'interface utilisateur des paramètres pour indiquer à l'utilisateur quand une fonction système particulière a été désactivée par le contrôleur de stratégie d'appareil (DPC):

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

3.9.2 Prise en charge des profils gérés

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

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

  • Déclarez le flag de fonctionnalité de plate-forme android.software.managed_users .
  • Prise en charge des profils gérés via les API android.app.admin.DevicePolicyManager.
  • Autorisez la création d'un seul profil géré.
  • Utilisez un badge d'icône (similaire au badge de travail en amont d'AOSP) pour représenter les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur avec badge, comme "Récents" et "Notifications".
  • Affichez une icône de notification (similaire au badge professionnel en amont d'AOSP) pour indiquer quand l'utilisateur se trouve dans une application de profil géré.
  • Affichez un message indiquant que l'utilisateur se trouve dans le profil géré si et quand l'appareil se réveille (ACTION_USER_PRESENT) et que l'application au premier plan se trouve dans le profil géré.
  • Si un profil géré existe, affichez une affordance visuelle dans le sélecteur d'intent pour permettre à l'utilisateur de transférer l'intent du profil géré vers l'utilisateur principal ou inversement, si cette fonctionnalité est activée par le contrôleur de stratégie d'appareil.
  • Si un profil géré existe, exposez les affordances utilisateur suivantes pour l'utilisateur principal et le profil géré :
    • Comptabilisation distincte de l'utilisation de la batterie, de la position, 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 l'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 dans le profil utilisateur principal ou géré.
  • Assurez-vous que les applications de numérotation, de contacts et de messagerie préinstallées peuvent rechercher et consulter les informations sur l'appelant du profil géré (le cas échéant) ainsi que celles du profil principal, si le contrôleur de stratégie d'appareil le permet. Lorsque les contacts du profil géré s'affichent dans le journal des appels préinstallé, l'interface utilisateur de l'appel, les notifications d'appel en cours et manqués, les applications de contacts et de messagerie, ils DOIVENT être associés au 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 avec plusieurs utilisateurs activés (voir la section 9.5), même si le profil géré n'est pas comptabilisé comme un autre utilisateur en plus de l'utilisateur principal.
  • 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 Open Source Android.
    • Les règles de mot de passe du DPC DOIVENT s'appliquer uniquement aux identifiants de l'écran de verrouillage du profil géré, sauf si elles sont appelées sur l'instance DevicePolicyManager renvoyée par getParentProfileInstance.

3.10. Accessibilité

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

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

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

  • Les implémentations d'appareils (appareils Android Auto et Android Watch sans sortie audio exclue) DOIVENT fournir un mécanisme accessible à l'utilisateur pour activer et désactiver les services d'accessibilité, et DOIVENT afficher cette interface en réponse à l'intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

  • Il est vivement recommandé d'implémenter des services d'accessibilité sur les appareils Android avec sortie audio, dont les fonctionnalités sont comparables ou supérieures à celles des services d'accessibilité TalkBack** et Switch Access (https://github.com/google/talkback).

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

** Pour les langues acceptées par la synthèse vocale.

Notez également que si un service d'accessibilité préchargé est présent, 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 (TTS) et aux fournisseurs de services de fournir 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 TTS Android.

Implémentations Android Automotive:

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

Toutes les autres implémentations d'appareils:

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

3.12. TV Input Framework

Le framework d'entrée Android TV (TIF) simplifie la diffusion de contenus en direct sur les appareils Android TV. TIF fournit une API standard pour créer des modules d'entrée qui contrôlent les appareils Android TV. Les implémentations d'appareils Android TV DOIVENT être compatibles avec le TV Input Framework.

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

3.12.1. Application TV

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

L'application TV DOIT fournir des fonctionnalités permettant d'installer et d'utiliser des chaînes TV, et doit répondre aux exigences suivantes:

  • Les implémentations d'appareils DOIVENT permettre l'installation et la gestion d'entrées tierces basées sur le TIF ( entrées tierces).
  • Les implémentations d'appareils PEUVENT fournir une séparation visuelle entre les entrées basées sur le 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 action de navigation de l'application TV (c'est-à-dire développer une liste d'entrées tierces à partir de l'application TV).

3.12.1.1. Guide des programmes électroniques

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

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

3.12.1.2. Navigation

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

  • Changer de chaîne TV
  • Ouverture de l'EPG
  • Configurer et ajuster les entrées tierces basées sur le format TIF
  • Ouverture du menu "Paramètres"

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

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

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

3.12.1.4. Décalage temporel

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

3.12.1.5. Enregistrement TV

Il est vivement recommandé d'implémenter l'enregistrement TV dans les appareils Android TV. Si l'entrée TV est compatible avec l'enregistrement, l'EPG peut permettre d'enregistrer un programme si l'enregistrement de ce programme n'est pas interdit. Les implémentations d'appareils DOIVENT fournir une interface utilisateur pour lire les programmes enregistrés.

3.13. Les réglages rapides

Les implémentations d'appareils Android DOIVENT inclure un composant d'UI de Réglages rapides permettant d'accéder rapidement aux actions fréquemment utilisées ou nécessaires de toute urgence.

Android inclut l'API quicksettings, qui permet aux applications tierces d'implémenter des cartes pouvant être ajoutées par l'utilisateur à côté des cartes fournies par le système dans le composant d'UI des paramètres rapides. Si une implémentation d'appareil comporte un composant d'interface utilisateur des paramètres rapides, elle:

  • DOIT permettre à l'utilisateur d'ajouter ou de supprimer des cartes d'une application tierce dans les paramètres rapides.
  • NE DOIT PAS ajouter automatiquement une carte d'une application tierce directement aux Réglages rapides.
  • DOIT afficher toutes les cartes ajoutées par l'utilisateur à partir d'applications tierces, ainsi que les cartes de réglage rapide fournies par le système.

3.14. API d'interface utilisateur du véhicule

3.14.1. Interface utilisateur des médias du véhicule

Toute implémentation d'appareil qui déclare la prise en charge de l'automobile DOIT inclure un framework d'UI pour prendre en charge les applications tierces qui utilisent les API MediaBrowser et MediaSession.

Le framework d'UI compatible avec 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 sans les modifier.
  • DOIT afficher ces éléments tels que décrits par MediaSession (par exemple, métadonnées, icônes, images).
  • DOIT afficher le titre de l'application.
  • Doit comporter un tiroir pour présenter la hiérarchie MediaBrowser.

4. Compatibilité du packaging 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 des paquets de l'implémentation de référence.

Le gestionnaire de paquets DOIT être compatible avec la vérification des fichiers ".apk" à l'aide du schéma de signature des fichiers APK v2 et de la signature JAR.

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

5. Compatibilité multimédia

5.1. Codecs multimédias

Implémentations d'appareils :

  • DOIT prendre en charge les formats multimédias principaux 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 en mesure de décoder tous les profils signalés dans son CamcorderProfile

  • DOIT pouvoir 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 viser une latence minimale. En d'autres termes, les codecs :

  • NE DOIT PAS consommer et stocker les tampons d'entrée et ne les renvoyer qu'une fois traités
  • NE DOIT PAS conserver les tampons décodés plus longtemps que spécifié par la norme (par exemple, SPS).
  • NE DOIT PAS conserver les tampons encodés plus longtemps que nécessaire par la structure GOP.

Tous les codecs listé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 Android Open Source.

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

5.1.1. Codecs audio

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

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

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

  • le décodage est effectué sans downmix (par exemple, un flux AAC 5.0 doit être décodé en cinq canaux PCM, un flux AAC 5.1 doit être décodé en six canaux PCM) ;
  • les métadonnées de plage dynamique, telles que définies dans "Contrôle de la plage dynamique (DRC)" dans la norme ISO/CEI 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. Il s'agit de: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL et KEY_AAC_ENCODED_TARGET_LEVEL.

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

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

5.1.2. Codecs d'image

Format/Codec Encodeur Décodeur Détails Types de fichiers/Formats de conteneurs compatibles
JPEG REQUIRED REQUIRED Base+progressive JPEG (.jpg)
GIF REQUIRED GIF (.gif)
PNG REQUIRED REQUIRED PNG (.png)
BMP REQUIRED BMP (.bmp)
WebP REQUIRED REQUIRED WebP (.webp)
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 annonçant la compatibilité avec les profils HDR DOIVENT prendre en charge 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 prendre en charge les périodes d'actualisation comprises entre 10 et 60 images et fonctionner avec une précision de 20% de la période d'actualisation configurée.

  • Les codecs vidéo DOIVENT prendre en charge des tailles de tampon d'octets de sortie et d'entrée qui peuvent accueillir le plus grand frame compressé et non compressé possible, comme dicté par la norme et la configuration, mais aussi ne pas 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/
Formats de conteneurs compatibles
H.263 MAI MAI
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC OBLIGATOIRE 2 OBLIGATOIRE 2 Pour en savoir plus, consultez les sections 5.2 et 5.3.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, audio AAC uniquement, non accessible par recherche, Android 3.0 ou version ultérieure)
H.265 HEVC OBLIGATOIRE 5 Pour en savoir plus, consultez la section 5.3. MPEG-4 (.mp4)
MPEG-2 FORTEMENT RECOMMANDÉ 6 Main Profile MPEG2-TS
MPEG-4 SP OBLIGATOIRE 2 3GPP (.3gp)
VP8 3 OBLIGATOIRE 2
(Android 4.3 et versions ultérieures) 		OBLIGATOIRE 2
(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 et versions ultérieures) 4
VP9 OBLIGATOIRE 2
(Android 4.4 et versions ultérieures) 		Pour en savoir plus, consultez la section 5.3.
  • WebM (.webm)
  • Matroska (.mkv, Android 4.0 et versions ultérieures) 4

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

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

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

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

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

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

5.2. Encodage vidéo

Les codecs vidéo sont facultatifs pour les implémentations d'appareils Android Watch.

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

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

L'encodeur vidéo H.263 et MPEG-4 DOIT prendre en charge les débits configurables de manière dynamique.

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

  • Il ne doit pas dépasser environ 15% du débit entre les intervalles d'images intra-cadres (I-frames).
  • Il ne doit pas dépasser environ 100% du débit 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 être compatibles avec le niveau de profil de référence 45.

5.2.2. H-264

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

  • DOIT être compatible avec le niveau 3 du profil de référence.
    Toutefois, la prise en charge de l'ordre des tranches arbitraire (ASO, Arbitrary Slice Ordering), de l'ordre des macroblocs flexible (FMO, Flexible Macroblock Ordering) et des tranches redondantes (RS, Redundant Slices) est FACULTATIVE. De plus, pour assurer la compatibilité avec d'autres appareils Android, il est RECOMMANDÉ que les encodeurs n'utilisent pas ASO, FMO et RS pour le profil de référence.
  • DOIT prendre en charge les profils d'encodage vidéo SD (définition standard) du tableau suivant.
  • DOIT prendre en charge le profil principal de niveau 4.
  • DOIT prendre en charge les profils d'encodage vidéo HD (haute définition) indiqués dans le tableau suivant.
  • De plus, il est vivement recommandé d'encoder des vidéos HD 1080p à 30 FPS sur les appareils Android TV.
SD (basse qualité) SD (haute qualité) HD 720p 1 HD 1080p 1
Résolution vidéo 320 x 240 px 720 x 480 px 1 280 x 720 px 1 920 x 1 080 px
Fréquence d'images de la vidéo 20 fps 30 ips 30 ips 30 ips
Débit vidéo 384 kbit/s 2 Mbit/s 4 Mbit/s 10 Mbit/s

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

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 DEVRAIENT 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 1 280 x 720 px 1 920 x 1 080 px
Fréquence d'images de la vidéo 30 ips 30 ips 30 ips 30 ips
Débit vidéo 800 Kbit/s 2 Mbit/s 4 Mbit/s 10 Mbit/s

1 Si le matériel est compatible.

5.3. Décodage vidéo

Les codecs vidéo sont facultatifs pour les implémentations d'appareils Android Watch.

Implémentations d'appareils :

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

  • Implémentations compatibles avec le décodeur Dolby Vision :

  • DOIT fournir un extracteur compatible avec Dolby Vision.

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

  • Les implémentations qui fournissent un extracteur compatible avec Dolby Vision DOIVENT définir l'indice de piste de la ou des couches de base rétrocompatibles (le cas échéant) sur le même que celui 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 élevé.

5.3.2. H.263

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

5.3.3. MPEG-4

Les implémentations d'appareils Android avec des décodeurs MPEG-4 DOIVENT être compatibles avec le profil simple de niveau 3.

5.3.4. H.264

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

  • DOIT prendre en charge le profil principal de niveau 3.1 et le profil de référence.
    La prise en charge de l'ordre des tranches arbitraire (ASO, Arbitrary Slice Ordering), de l'ordre des macroblocs flexible (FMO, Flexible Macroblock Ordering) et des tranches redondantes (RS, Redundant Slices) est FACULTATIVE.
  • DOIT être capable de décoder les vidéos avec les profils SD (Standard Definition) listés dans le tableau suivant et encodés avec le profil de référence et le profil principal de niveau 3.1 (y compris 720p30).
  • DOIT être en mesure de décoder les vidéos avec les profils HD (haute définition) indiqués dans le tableau suivant.
  • De plus, les appareils Android TV :
    • DOIT être compatible avec le profil High Profile Level 4.2 et le profil de décodage HD 1080p60.
    • DOIT être capable de décoder les vidéos avec les deux profils HD indiqués dans le tableau suivant et encodées avec le profil de référence, le profil principal ou le profil High Profile Level 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 1 280 x 720 px 1 920 x 1 080 px
Fréquence d'images de la vidéo 30 ips 30 ips 60 FPS 30 FPS (60 FPS 2)
Débit vidéo 800 Kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

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

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

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 prendre en charge le niveau 3 du profil principal et les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
  • DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
  • DOIT être compatible avec les profils de décodage HD indiqués dans le tableau suivant en cas de présence d'un décodeur matériel.
  • En outre, les appareils Android TV:
  • DOIT être compatible avec le profil de décodage HD 720p.
  • Il est vivement recommandé de 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 niveau 4.1 du profil principal.
  • DOIT être compatible avec 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 de la catégorie principale.
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p UHD
Résolution vidéo 352 x 288 px 720 x 480 px 1 280 x 720 px 1 920 x 1 080 px 3 840 x 2 160 px
Fréquence d'images de la vidéo 30 ips 30 ips 30 ips 30 fps (60 fps 1) 60 FPS
Débit vidéo 600 Kbits/s 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

1 OBLIGATOIRE pour les implémentations d'appareils Android TV avec décodage matériel H.265.

5.3.6. VP8

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

  • DOIT prendre en charge les profils de décodage SD du tableau suivant.
  • DOIT prendre en charge les profils de décodage HD du tableau suivant.
  • Les appareils Android TV doivent impérativement ê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 1 280 x 720 px 1 920 x 1 080 px
Fréquence d'images de la vidéo 30 ips 30 ips 30 FPS (60 FPS 2) 30 (60 FPS 2)
Débit vidéo 800 Kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

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

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

5.3.7. VP9

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

  • DOIT prendre en charge les profils de décodage vidéo SD indiqués dans le tableau suivant.
  • DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
  • 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 TV:

    • DOIT être compatible avec le profil de décodage HD 720p.
    • Il est vivement recommandé de prendre en charge le profil de décodage HD 1080p.
    • DOIT être compatible avec le profil de décodage UHD. Si le profil de décodage vidéo UHD est pris en charge, il DOIT prendre en charge la profondeur de couleur 8 bits et DEVRAIT prendre en charge le profil 2 du VP9 (10 bits).
SD (basse qualité) SD (haute qualité) HD – 720p HD – 1080p UHD
Résolution vidéo 320 x 180 px 640 x 360 px 1 280 x 720 px 1 920 x 1 080 px 3 840 x 2 160 px
Fréquence d'images de la vidéo 30 ips 30 ips 30 ips 30 fps (60 fps 1) 60 FPS
Débit vidéo 600 Kbits/s 1,6 Mbit/s 4 Mbit/s 5 Mbit/s 20 Mbit/s

1 OBLIGATOIRE pour les implémentations d'appareils Android TV avec décodage matériel VP9.

5.4. Enregistrement audio

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

5.4.1. Capture audio RAW

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

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

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

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

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

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

5.4.2. Enregistrer pour la reconnaissance vocale

La source audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION DOIT prendre en charge la capture à l'un des taux d'échantillonnage, 44 100 et 48 000.

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

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

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

5.4.3. Capture pour le redirignement de la lecture

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

  • STREAM_RING
  • STREAM_ALARM
  • STREAM_NOTIFICATION

5.5. Lecture audio

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

5.5.1. Lecture audio brute

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

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

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

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

5.5.2. Effets audio

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

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

5.5.3. Volume de sortie audio

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

Les implémentations d'appareils Android Auto 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 définie publiquement dans android.car.CarAudioManager .

5.6. Latence audio

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

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

  • latence de sortie ; Intervalle entre le moment où une application écrit un frame de données encodé en PCM et le moment où le son correspondant est présenté à l'environnement via un transducteur sur l'appareil ou qu'un signal quitte l'appareil via un port et peut être observé en externe.
  • Latence de sortie à froid Latence de sortie pour le premier frame, lorsque le système de sortie audio était inactif et éteint avant la requête.
  • latence de sortie continue . La latence de sortie pour les frames suivants, une fois que l'appareil lit de l'audio.
  • latence d'entrée ; Intervalle entre le moment où un son est présenté par l'environnement à l'appareil via un transducteur ou un signal qui y entre via un port, et le moment où une application lit le frame correspondant de données codées PCM.
  • entrée perdue . Portion initiale d'un signal d'entrée inutilisable ou indisponible.
  • Latence d'entrée à froid Somme du temps d'entrée perdu et de la latence d'entrée pour le premier frame, lorsque le système d'entrée audio était inactif et éteint avant la requête.
  • latence d'entrée continue . Latence d'entrée pour les images suivantes lorsque l'appareil capture l'audio.
  • jitter de sortie à froid . Variabilité entre les mesures distinctes des valeurs de latence de sortie à froid.
  • jitter d'entrée à froid . Variabilité entre les mesures distinctes des valeurs de latence d'entrée à froid.
  • latence aller-retour continue ; Somme de la latence d'entrée continue, de la latence de sortie continue et d'une période de tampon. La période de tampon permet à l'application de traiter le signal et de réduire la différence de phase entre les flux d'entrée et de sortie.
  • API de file d'attente de tampon PCM OpenSL ES Ensemble des API OpenSL ES liées au PCM dans le NDK Android.

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

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

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

Il est vivement recommandé que les implémentations d'appareils incluant android.hardware.microphone respectent les exigences audio d'entrée suivantes:

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

5.7. Protocoles de réseau

Les appareils DOIVENT ê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 être compatibles avec les protocoles réseau multimédias suivants:

Formats de segments Référence(s) Compatibilité avec les codecs requise
MPEG-2 Transport Stream ISO 13818 Codecs vidéo :
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Pour en savoir plus sur les formats H.264 AVC, MPEG-2-4 SP et MPEG-2,consultez la section 5.1.3.

Codecs audio:

  • AAC
Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.1.
AAC avec cadrage ADTS et tags ID3 ISO 13818-7 Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.1.
WebVTT WebVTT

  • RTSP (RTP, SDP)

    Le profil audio vidéo RTP et les codecs associés suivants DOIVENT être pris en charge. Pour connaître les exceptions, veuillez consulter les notes de bas de page du tableau de la section 5.1.

Nom du profil Référence(s) Compatibilité avec les codecs requise
H264 AVC RFC 6184 Pour en savoir plus sur le format H264 AVC, consultez la section 5.1.3.
MP4A-LATM RFC 6416 Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.1.
H263-1998 RFC 3551
RFC 4629
RFC 2190 		Pour en savoir plus sur le format H.263, consultez la section 5.1.3.
H263-2000 RFC 4629 Pour en savoir plus sur le format H.263, 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 le format MPEG-4 SP, consultez la section 5.1.3.
mpeg4-generic RFC 3640 Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.1.
MP2T RFC 2250 Pour en savoir plus, consultez la section MPEG-2 Transport Stream sous HTTP Live Streaming.

5.8. Secure Media

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

5.9. MIDI (Musical Instrument Digital Interface)

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

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

  • Mode hôte USB (section 7.7 USB)
  • Mode périphérique USB (section 7.7 USB)
  • MIDI via Bluetooth LE dans le rôle de maître (section 7.4.3 Bluetooth)

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

5.10. Audio professionnel

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

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

Les latences et les exigences audio USB DOIVENT être respectées à l'aide de l'API de file d'attente de tampon PCM OpenSL ES.

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

  • Fournir un niveau durable de performances du processeur lorsque l'audio est actif
  • Réduisez l'imprécision et la dérive de l'horloge audio par rapport à l'heure normale.
  • Réduisez la dérive de l'horloge audio par rapport au CLOCK_MONOTONIC du processeur lorsque les deux sont actifs.
  • Minimisez la latence audio sur les transducteurs de l'appareil.
  • Réduire la latence audio via l'audio numérique USB
  • Documentez les mesures de latence audio sur tous les chemins.
  • Réduisez le jitter dans les temps d'entrée du rappel de finalisation du tampon audio, car cela affecte le pourcentage utilisable de la bande passante complète du processeur par le rappel.
  • Ne fournissez aucun sous-dépassement audio (sortie) ni dépassement audio (entrée) en utilisation normale avec la latence indiquée.
  • Ne pas avoir de différence de latence entre les canaux
  • Minimisez la latence moyenne MIDI sur tous les transports.
  • Minimisez la variabilité de la latence MIDI sous charge (jitter) sur tous les transports.
  • Fournissez des codes temporels MIDI précis pour tous les transports.
  • Réduisez le bruit du signal audio sur les transducteurs de l'appareil, y compris la période immédiatement après le démarrage à froid.
  • Fournissez une différence de horloge audio nulle entre les côtés d'entrée et de sortie des points de terminaison correspondants, lorsque les deux sont actifs. Le micro et le haut-parleur intégrés à l'appareil, ou l'entrée et la sortie du connecteur audio sont des exemples de points de terminaison correspondants.
  • Gérez les rappels d'achèvement du tampon audio pour les côtés d'entrée et de sortie des points de terminaison correspondants sur le même thread lorsque les deux sont actifs, et entrez dans le rappel de sortie immédiatement après le retour du rappel d'entrée. Si vous ne pouvez pas gérer les rappels sur le même thread, saisissez le rappel de sortie peu de temps après le rappel d'entrée pour permettre à l'application de définir un timing cohérent entre les côtés d'entrée et de sortie.
  • Minimisez la différence de phase entre le tamponnage audio HAL pour les côtés d'entrée et de sortie des points de terminaison correspondants.
  • Réduire la latence tactile
  • Minimisez la variabilité de la latence tactile sous charge (jitter).

5.11. Capturer pour Unprocessed

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

Un appareil DOIT répondre à 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 à peu près plates dans la plage de fréquences moyennes, à savoir ±10 dB de 100 Hz à 7 000 Hz.

  • L'appareil DOIT présenter des niveaux d'amplitude dans la plage de fréquences basses: 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 de fréquences élevées: plus précisément, 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é sinusoïdale de 1 000 Hz lue à un niveau de pression acoustique (SPL) de 94 dB génère une réponse avec une valeur RMS de 520 pour les échantillons 16 bits (ou -36 dB à pleine échelle pour les échantillons à virgule flottante/double précision).

  • Taux de signal sur bruit > 60 dB (différence entre 94 dB SPL et le niveau de pression acoustique équivalent du bruit propre, pondéré A).

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

  • Le seul traitement de signal autorisé dans le chemin est un multiplicateur de niveau pour ajuster le niveau à la plage souhaitée. Ce multiplicateur de niveau NE DOIT PAS entraîner de retard ni de latence dans le chemin du signal.

  • Aucun autre traitement de signal n'est autorisé dans le chemin, comme la commande de gain automatique, le filtre passe-haut ou la suppression de l'écho. Si, pour une raison quelconque, un traitement du signal est présent dans l'architecture, il DOIT être désactivé et ne doit pas entraîner de retard ni de latence supplémentaire dans le chemin du signal.

Toutes les mesures de niveau de pression acoustique sont effectuées directement à côté du micro testé.

Pour les configurations multimicro, ces exigences s'appliquent à chaque micro.

Il est FORTEMENT RECOMMANDÉ qu'un appareil réponde à autant que possible des exigences concernant le chemin du signal pour la source d'enregistrement non traitée. Toutefois, un appareil doit répondre à toutes ces exigences, listées ci-dessus, s'il prétend prendre en charge la source audio non traitée.

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

6.1. Outils pour les développeurs

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

  • Android Debug Bridge (adb)
    • Les implémentations d'appareils DOIVENT prendre en charge toutes les fonctions adb, comme indiqué dans le SDK Android, y compris dumpsys.
    • Le daemon adb côté appareil DOIT être inactif par défaut, et un mécanisme accessible par l'utilisateur DOIT être disponible pour activer Android Debug Bridge. Si une implémentation d'appareil omet le mode périphérique USB, elle DOIT implémenter Android Debug Bridge via un réseau local (tel qu'Ethernet ou 802.11).
    • Android est compatible avec adb sécurisé. adb sécurisé active adb sur les hôtes authentifiés connus. Les implémentations d'appareils DOIVENT être compatibles avec adb sécurisé.
  • Service Dalvik Debug Monitor (ddms)
    • Les implémentations d'appareils DOIVENT prendre en charge toutes les fonctionnalités ddms, comme indiqué dans le SDK Android.
    • Comme ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme indiqué ci-dessus.
  • Les implémentations d'appareils Monkey DOIVENT inclure le framework Monkey et le mettre à la disposition des applications.
  • SysTrace
    • Les implémentations d'appareils DOIVENT prendre en charge l'outil systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut, et un mécanisme accessible par l'utilisateur doit être disponible pour l'activer.
    • La plupart des systèmes Linux et des systèmes Apple Macintosh reconnaissent les appareils Android à l'aide des outils Android SDK standards, sans assistance supplémentaire. Toutefois, les systèmes Microsoft Windows nécessitent généralement un pilote pour les nouveaux appareils Android. (Par exemple, les nouveaux ID de fournisseur et parfois les nouveaux ID d'appareil nécessitent des pilotes USB personnalisés pour les systèmes Windows.)
    • Si une implémentation d'appareil n'est pas reconnue par l'outil adb fourni dans le SDK Android standard, les implémentateurs d'appareils DOIVENT fournir des pilotes Windows permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb. Ces pilotes DOIVENT être fournis pour Windows XP, Windows Vista, Windows 7, Windows 8 et Windows 10, en versions 32 bits et 64 bits.

6.2. Options pour les développeurs

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

Les implémentations d'Android Automotive peuvent limiter l'accès au menu "Options pour les développeurs" en le masquant ou en le désactivant visuellement lorsque le véhicule est en mouvement.

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éclaré comme facultatif et que l'implémentation de l'appareil ne dispose pas de ce composant:

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

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

Les implémentations d'appareils DOIVENT systématiquement signaler des informations de configuration matérielle précises via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) de la classe android.content.pm.PackageManager pour le même identifiant de build.

7.1. Écran et graphismes

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

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

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

7.1.1. Configuration de l'écran

7.1.1.1. Taille d'écran

Les appareils Android Watch (décrits dans la section 2) peuvent avoir des tailles d'écran plus petites, comme décrit dans cette section.

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

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

De plus :

  • Les appareils Android Watch DOIVENT avoir un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces.
  • Les appareils Android Automotive doivent disposer d'un écran dont la diagonale physique est supérieure ou égale à 6 pouces.
  • Les appareils Android Automotive doivent avoir une taille d'écran d'au moins 750 dp x 480 dp.
  • Les autres types d'implémentations d'appareils Android, avec un écran physiquement intégré, DOIVENT avoir un écran d'au moins 6,35 cm de diagonale.

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

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

7.1.1.2. Format d'écran

Bien qu'il n'y ait aucune restriction concernant la valeur du format d'écran de l'écran physique, le format d'écran 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, aucune restriction n'est appliquée à la valeur du format.
  • Dans tous les autres cas, le format DOIT être compris entre 1,3333 (4:3) et 1,86 (environ 16:9), sauf si l'application a indiqué explicitement qu'elle prend en charge un format d'écran plus élevé via la valeur de métadonnées maxAspectRatio.

7.1.1.3. Densité d'écran

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

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

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

Nous vous RECOMMANDONS vivement d'offrir aux utilisateurs un paramètre leur permettant de modifier la taille de l'écran. 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 de l'écran NE DOIT PAS être agrandie de plus de 1,5 fois la densité native ni produire une dimension d'écran minimale effective inférieure à 320 dp (équivalent au qualificatif de ressource sw320dp), selon la première éventualité.
  • La taille de l'écran NE DOIT PAS être réduite à moins de 0,85 fois la densité native.
  • Pour assurer une bonne usabilité et des tailles de police cohérentes, nous vous RECOMMANDONS de fournir la mise à l'échelle suivante des options d'affichage natif (tout en respectant les limites spécifiées ci-dessus) :
  • Petite: 0,85x
  • Par défaut: 1x (échelle d'affichage native)
  • Grande: 1,15 x
  • Plus grand: x 1,3
  • Plus grande : x 1,45

7.1.2. Métriques sur le Réseau Display

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

7.1.3. Orientation de l'écran

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

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

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

Les appareils NE DOIVENT PAS modifier la taille ou la densité d'écran signalées lorsqu'ils changent d'orientation.

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

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

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

  • Les API gérées (par exemple, via la méthode GLES10.getString()) DOIVENT signaler la prise en charge d'OpenGL ES 1.0 et d'OpenGL ES 2.0.
  • Les API OpenGL C/C++ natives (API disponibles pour les applications via libGLES_v1CM.so, libGLES_v2.so ou libEGL.so) DOIVENT indiquer la prise en charge d'OpenGL ES 1.0 et d'OpenGL ES 2.0.
  • Les implémentations d'appareils qui déclarent la prise en charge d'OpenGL ES 3.0, 3.1 ou 3.2 DOIVENT être compatibles avec les API gérées correspondantes et inclure la prise en charge des API C/C++ natives. Sur les implémentations d'appareils qui déclarent la prise en charge d'OpenGL ES 3.0, 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'extension OpenGL ES avec des interfaces Java et une prise en charge native des fonctionnalités graphiques avancées telles que le tessellation et le format de compression de texture ASTC. Les implémentations d'appareils Android DOIVENT être compatibles avec le pack d'extensions si l'appareil est compatible avec OpenGL ES 3.2 et PEUVENT l'être dans le cas contraire. Si le pack d'extension est entièrement compatible, l'appareil DOIT identifier la compatibilité via l'indicateur de fonctionnalité android.hardware.opengles.aep.

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

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

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

Les implémentations d'appareils DOIVENT activer l'accélération matérielle par défaut et DOIVENT la désactiver si le développeur le demande en définissant android:hardwareAccelerated="false" ou en désactivant l'accélération matérielle directement via les API View Android.

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

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

Android est compatible avec EGL_ANDROID_RECORDABLE, un attribut EGLConfig qui indique si EGLConfig est compatible avec le rendu dans un ANativeWindow qui enregistre des images dans une vidéo. Les implémentations d'appareils DOIVENT être compatibles avec l'extension EGL_ANDROID_RECORDABLE.

7.1.5. Ancien mode de compatibilité des applications

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

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

7.1.6. Technologie d'affichage

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

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

7.1.7. Écrans secondaires

Android est compatible avec les écrans secondaires pour permettre le partage de contenus multimédias et les API pour les développeurs afin d'accéder aux écrans externes. Si un appareil est compatible avec un écran externe via une connexion filaire, sans fil ou intégrée, l'implémentation de l'appareil DOIT implémenter l'API Display Manager, comme décrit dans la documentation du SDK Android.

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

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

7.2.1. Clavier

Les implémentations d'Android Watch et d'Android Auto peuvent implémenter un clavier virtuel. Toutes les autres implémentations d'appareils DOIVENT implémenter un clavier virtuel et:

Implémentations de l'appareil:

  • DOIT être compatible avec le framework de gestion des entrées (qui permet aux développeurs tiers de créer des éditeurs de méthode d'entrée, c'est-à-dire des claviers virtuels), comme indiqué sur http://developer.android.com.
  • DOIT fournir au moins une implémentation de clavier virtuel (que le clavier physique soit présent ou non), sauf pour les appareils Android Watch, où la taille de l'écran rend l'utilisation d'un clavier virtuel moins pertinente.
  • 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

Les appareils Android TV DOIVENT être compatibles avec la croix directionnelle.

Implémentations de l'appareil:

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

7.2.3. Touches de navigation

Les exigences de disponibilité et de visibilité des fonctions "Accueil", "Récents" et "Retour" varient selon les types d'appareils, comme décrit dans cette section.

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

  • Les implémentations d'appareils Android portables DOIVENT fournir les fonctions Accueil, Recents et Retour.
  • Les implémentations d'appareils Android TV DOIVENT fournir les fonctions "Accueil" et "Retour".
  • Les implémentations d'appareils Android Watch DOIVENT proposer la fonction "Accueil" et la fonction "Retour", sauf lorsqu'elles sont en mode UI_MODE_TYPE_WATCH .
  • Les implémentations d'appareils Android Watch (et aucun autre type d'appareil Android) PEUVENT utiliser l'événement de pression prolongée sur l'événement de touche KEYCODE_BACK et ne pas l'envoyer à l'application de premier plan.
  • Les implémentations d'Android Automotive DOIVENT fournir la fonction Accueil et PEUVENT fournir les fonctions Retour et Récents.
  • Tous les autres types d'implémentations d'appareils DOIVENT fournir les fonctions "Accueil" et "Retour".

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

Si elle est fournie, la fonction "Éléments récents" doit comporter un bouton ou une icône visible, sauf si elle est masquée avec d'autres fonctions de navigation en mode plein écran. Cela ne s'applique pas aux appareils qui passent d'anciennes versions d'Android et qui disposent de boutons physiques pour la navigation et pas de touche "Récents".

Si elles sont fournies, les fonctions "Accueil" et "Retour" doivent chacune comporter un bouton ou une icône visible, sauf si elles sont masquées avec d'autres fonctions de navigation en mode plein écran ou lorsque le paramètre uiMode UI_MODE_TYPE_MASK est défini sur UI_MODE_TYPE_WATCH.

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

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

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

Les implémentations d'appareils Android compatibles avec l'action d'assistance et/ou VoiceInteractionService DOIVENT pouvoir lancer une application d'assistance avec une seule interaction (par exemple, appuyer, double-cliquer ou effectuer un geste) lorsque d'autres touches de navigation sont visibles. Nous vous recommandons vivement d'utiliser l'appui de manière prolongée sur l'icône d'accueil comme 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é qui gère l'intent ACTION_ASSIST.

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

  • Les touches de navigation de l'implémentation de l'appareil DOIVENT utiliser une partie distincte de l'écran, qui n'est pas disponible pour les applications. Elles NE DOIVENT PAS masquer ni interférer avec la partie de l'écran disponible pour les applications.
  • Les implémentations d'appareils DOIVENT mettre à disposition une partie de l'écran pour les 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'UI système ou spécifient SYSTEM_UI_FLAG_VISIBLE.
  • Les implémentations d'appareils DOIVENT présenter les touches de navigation dans un mode "bas profil" discret (par exemple, en mode atténuation) 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 appareils Android portables et les montres doivent impérativement être compatibles avec la saisie tactile.

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

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

Android est compatible avec différents écrans tactiles, pavés tactiles et faux périphériques d'entrée tactile. Les implémentations d'appareils à écran tactile sont associées à un écran 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 n'a pas besoin d'affordances supplémentaires pour indiquer les objets manipulés. À l'inverse, une interface tactile simulée fournit un système de saisie utilisateur qui s'approche d'un sous-ensemble des fonctionnalités d'un écran tactile. Par exemple, une souris ou une télécommande qui contrôle un curseur à l'écran s'apparente à l'écran tactile, mais l'utilisateur doit d'abord pointer ou sélectionner un élément, puis cliquer. De nombreux périphériques d'entrée, comme la souris, le pavé tactile, la souris sans fil à gyroscope, le pointeur à gyroscope, le joystick et le pavé tactile multipoint, peuvent prendre en charge les interactions tactiles simulées. Android inclut la constante de fonctionnalité android.hardware.faketouch, qui correspond à un périphérique d'entrée non tactile (basé sur un pointeur) haute fidélité, tel qu'une souris ou un pavé tactile, qui peut émuler de manière adéquate la saisie tactile (y compris la prise en charge des gestes de base) et indique que l'appareil est compatible avec un sous-ensemble émulé des fonctionnalités de l'écran tactile. Les implémentations d'appareils qui déclarent la fonctionnalité de faux appui DOIVENT respecter les exigences de la section 7.2.5.

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

7.2.5. Saisie tactile fictive

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

  • DOIT indiquer les positions X et Y absolues à l'écran 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 lorsque le pointeur descend ou monte sur l'écran.
  • DOIT prendre en charge le pointeur vers le bas et vers le haut sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler un appui sur un objet à l'écran.
  • DOIT prendre en charge le pointeur vers le bas, le pointeur vers le haut, le pointeur vers le bas, puis le pointeur vers le haut au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler un double appui sur un objet à l'écran.
  • DOIT prendre en charge le pointeur vers le bas sur un point arbitraire de l'écran, le déplacement du pointeur vers un autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un glissement tactile.
  • DOIT prendre en charge le pointeur vers le bas, puis permettre aux utilisateurs de déplacer rapidement l'objet vers une autre position à l'écran, puis de pointer vers le haut, ce qui leur permet de lancer un objet à l'écran.

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

7.2.6. Compatibilité avec les manettes de jeu

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

7.2.6.1. Mappages des boutons

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

Bouton Utilisation de l'HID 2 Bouton Android
A 1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B 1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X 1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y 1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
Croix directionnelle vers le haut 1
Croix directionnelle vers le bas 1 		0x01 0x0039 3 AXIS_HAT_Y 4
Pavé directionnel vers la gauche 1
Pavé directionnel vers la droite 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_BUTTON_R1 (103)
Clic sur le stick gauche 1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clic sur 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 KeyEvent

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

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

4 MotionEvent

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

1 MotionEvent

7.2.7. Télécommande

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

7.3. Capteurs

Android inclut des API permettant d'accéder à différents types de capteurs. Les implémentations d'appareils peuvent généralement omettre ces capteurs, comme indiqué dans les sous-sections suivantes. Si un appareil inclut un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android et la documentation Open Source Android sur les capteurs. 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 capteur (par exemple, en renvoyant "true" ou "false" selon les cas lorsque les applications tentent d'enregistrer des écouteurs, en n'appelant pas les écouteurs de capteur lorsque les capteurs correspondants ne sont pas présents, etc.).
  • DOIT signaler toutes les mesures des capteurs à l'aide des valeurs du système international d'unités (métriques) appropriées pour chaque type de capteur, comme défini dans la documentation du SDK Android.
  • DOIT signaler l'heure de l'événement en nanosecondes, comme défini dans la documentation du SDK Android. Cette valeur représente l'heure à laquelle l'événement s'est produit et est synchronisée avec l'horloge SystemClock.elapsedRealtimeNano(). Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme, où ce composant pourrait devenir OBLIGATOIRE. L'erreur de synchronisation DOIT être inférieure à 100 millisecondes.
  • DOIT signaler les données du capteur avec une latence maximale de 100 millisecondes + 2 * sample_time pour le cas d'un capteur en streaming avec une latence minimale requise de 5 ms + 2 * sample_time lorsque le processeur d'application est actif. Ce délai n'inclut pas les délais de filtrage.
  • DOIT signaler le premier échantillon du capteur dans les 400 millisecondes + 2 * sample_time de l'activation du capteur. Une précision de 0 est acceptable pour cet exemple.

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et des documentations Open Source Android sur les capteurs doit être considéré comme faisant autorité.

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

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

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

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

7.3.1. Accéléromètre

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

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

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

7.3.3. GPS

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

  • Il est FORTEMENT RECOMMANDÉ que l'appareil continue de fournir des sorties GPS/GNSS normales aux applications pendant un appel téléphonique d'urgence et que la sortie de localisation ne soit pas bloquée pendant un appel téléphonique d'urgence.
  • Il DOIT prendre en charge les sorties de position à une fréquence d'au moins 1 Hz lorsqu'elles sont demandées via LocationManager#requestLocationUpdate .
  • Il doit pouvoir déterminer la position en plein ciel (signaux forts, multichemin négligeable, HDOP < 2) en 10 secondes (temps de première correction rapide), lorsqu'il est connecté à une connexion Internet d'au moins 0,5 Mbit/s. Cette exigence est généralement satisfaite par l'utilisation d'une forme de technique GPS/GNSS assistée ou prédictive pour réduire le temps de verrouillage GPS/GNSS (les données d'assistance incluent l'heure de référence, l'emplacement de référence et l'éphéméride/l'horloge du satellite).
    • Après avoir effectué un tel calcul de position, il est FORTEMENT RECOMMANDÉ que l'appareil puisse déterminer sa position, en plein air, sous 10 secondes, lorsque les requêtes de localisation sont redémarrées, jusqu'à une heure après le calcul de position initial, même lorsque la requête ultérieure est effectuée sans connexion de données et/ou après un cycle d'alimentation.
  • En plein air, après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 1 mètre par seconde au carré :
    • Il doit pouvoir déterminer la position à 20 mètres près et la vitesse à 0, 5 mètre par seconde près, au moins 95% du temps.
    • Il doit suivre et signaler simultanément au moins huit satellites d'une constellation via GnssStatus.Callback.
    • Il DOIT pouvoir suivre simultanément au moins 24 satellites de plusieurs constellations (par exemple, GPS + au moins un des systèmes Glonass, Beidou ou Galileo).
  • Il DOIT indiquer la génération de la technologie GNSS via l'API de test "getGnssYearOfHardware".
  • Il est vivement recommandé de respecter toutes les conditions ci-dessous et VOUS DEVEZ les respecter si la génération de la technologie GNSS est indiquée comme étant l'année 2016 ou plus récente.
    • Il DOIT signaler les mesures GPS dès qu'elles sont détectées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
    • Il DOIT indiquer les pseudo-distances et les taux de pseudo-distance GPS qui, dans des conditions d'ensoleillement après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 0, 2 m/s², sont suffisants pour calculer la position à 20 m près et la vitesse à 0, 2 m/s près, au moins 95% du temps.

Notez que certaines des exigences GPS ci-dessus sont considérées comme "FORTEMENT RECOMMANDÉES". La définition de la compatibilité de la prochaine version majeure devrait les remplacer par "OBLIGATOIRE".

7.3.4. Gyroscope

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

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

7.3.5. Le baromètre

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

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

7.3.6. Thermomètre

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

Les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS, inclure un capteur de température du processeur. S'il est présent, il DOIT être défini comme SENSOR_TYPE_TEMPERATURE, DOIT mesurer la température du processeur de l'appareil et NE DOIT PAS mesurer d'autre température. Notez que le type de capteur SENSOR_TYPE_TEMPERATURE a été abandonné dans Android 4.0.

Pour les implémentations Android Automotive, SENSOR_TYPE_AMBIENT_TEMPERATURE DOIT mesurer la température à l'intérieur de l'habitacle du véhicule.

7.3.7. Photomètre

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

7.3.8. Capteur de proximité

Les implémentations d'appareils PEUVENT inclure un capteur de proximité. Les appareils pouvant passer un appel vocal et indiquant une valeur autre que PHONE_TYPE_NONE dans getPhoneType DOIVENT inclure un capteur de proximité. Si une implémentation d'appareil inclut un capteur de proximité, elle:

  • DOIT mesurer la proximité d'un objet dans la même direction que l'écran. Autrement dit, le capteur de proximité DOIT être orienté pour détecter les objets proches de l'écran, car l'objectif principal de ce type de capteur est de détecter un téléphone utilisé par l'utilisateur. Si une implémentation d'appareil inclut un capteur de proximité avec une autre orientation, il NE DOIT PAS être accessible via cette API.
  • Doit avoir une précision d'au moins 1 bit.

7.3.9. Capteurs haute fidélité

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

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

  • SENSOR_TYPE_ACCELEROMETER
    • Doit avoir une plage de mesure d'au moins -8 g à +8 g.
    • Doit avoir une résolution de mesure d'au moins 1 024 LSB/G.
    • Doit avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus.
    • Le bruit de mesure doit être inférieur à 400 µG/√Hz.
    • DOIT implémenter une forme de ce capteur sans réveil avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur.
    • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 3 mW.
    • DOIT avoir une stabilité de biais de bruit stationnaire de moins de 15 μg √Hz à partir d'un ensemble de données statiques de 24 heures.
    • Le changement de biais par rapport à la température doit être ≤ +/- 1 mg / °C.
    • La non-linéarité de la ligne d'ajustement doit être inférieure ou égale à 0,5%, et la variation de la sensibilité en fonction de la température doit être inférieure ou égale à 0,03%/°C.

  • SENSOR_TYPE_GYROSCOPE

    • DOIT avoir une plage de mesure d'au moins -1 000 et +1 000 dps.
    • Doit avoir une résolution de mesure d'au moins 16 LSB/dps.
    • Doit avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus.
    • DOIT avoir un bruit de mesure inférieur à 0,014°/s/√Hz.
    • DOIT avoir une stabilité de biais stationnaire inférieure à 0,0002 °/s √Hz à partir d'un ensemble de données statiques sur 24 heures.
    • Le biais doit changer de ≤ +/- 0,05 °/ s / °C en fonction de la température.
    • La sensibilité doit changer de ≤ 0,02% / °C en fonction de la température.
    • La non-linéarité de la droite d'ajustement optimal doit être inférieure ou égale à 0,2%.
    • DOIT avoir une densité de bruit de ≤ 0,007 °/s/√Hz.

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

  • SENSOR_TYPE_GEOMAGNETIC_FIELD
    • DOIT avoir une plage de mesure d'au moins -900 et +900 uT.
    • Doit avoir une résolution de mesure d'au moins 5 LSB/uT.
    • Doit avoir une fréquence de mesure minimale de 5 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 50 Hz ou plus.
    • Le bruit de mesure doit être inférieur à 0,5 uT.
  • SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED avec les mêmes exigences de qualité que SENSOR_TYPE_GEOMAGNETIC_FIELD, et en plus :
    • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 600 événements de capteur.
  • SENSOR_TYPE_PRESSURE
    • DOIT avoir une plage de mesure d'au moins 300 et 1 100 hPa.
    • DOIT avoir une résolution de mesure d'au moins 80 LSB/hPa.
    • Doit avoir une fréquence de mesure minimale de 1 Hz ou moins.
    • DOIT avoir une fréquence de mesure maximale de 10 Hz ou plus.
    • Le bruit de mesure doit être inférieur à 2 Pa/√Hz.
    • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
    • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 2 mW.
  • SENSOR_TYPE_GAME_ROTATION_VECTOR
    • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
    • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 4 mW.
  • SENSOR_TYPE_SIGNIFICANT_MOTION
    • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
  • SENSOR_TYPE_STEP_DETECTOR
    • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 100 événements de capteur.
    • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
    • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 4 mW.
  • SENSOR_TYPE_STEP_COUNTER
    • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
  • SENSOR_TILT_DETECTOR
    • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.

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

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

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

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

  • SENSOR_TYPE_PROXIMITY: 100 événements de capteur

7.3.10. Lecteur d'empreinte digitale

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

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

7.3.11. Capteurs Android Automotive uniquement

Les capteurs spécifiques au secteur automobile sont définis dans le fichier android.car.CarSensorManager API .

7.3.11.1. Engrenage actuel

Les implémentations Android Auto devraient fournir la vitesse actuelle sous la forme 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 comme 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 lumière ambiante. Le capteur de luminosité ambiante sous-jacent PEUT être le même que le photomètre.

7.3.11.3. État de la conduite

Les implémentations Android Automotive DOIVENT prendre en charge l'état de conduite défini comme SENSOR_TYPE_DRIVING_STATUS, avec une valeur par défaut de DRIVE_STATUS_UNRESTRICTED lorsque le véhicule est complètement à l'arrêt et garé. Il incombe aux fabricants d'appareils de configurer SENSOR_TYPE_DRIVING_STATUS conformément à toutes les lois et réglementations applicables aux marchés où le produit est distribué.

7.3.11.4. Vitesse de rotation des roues

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

7.3.12. Capteur de position

Les implémentations d'appareils PEUVENT prendre en charge un capteur de position à six degrés de liberté. Il est RECOMMANDÉ que les appareils Android portables soient compatibles avec ce capteur. Si une implémentation d'appareil est compatible avec un capteur de position à six 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 dans ce document fait spécifiquement référence au matériel lié à la réalisation d'appels vocaux et à l'envoi de messages SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent être ou non commutés par paquets, ils sont considérés comme indépendants de toute connectivité de données pouvant être implémentée sur le même réseau. En d'autres termes, les fonctionnalités et les API de "téléphonie" Android font spécifiquement référence aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir de messages SMS NE DOIVENT PAS signaler la fonctionnalité android.hardware.telephony ni ses sous-fonctionnalités, que les appareils utilisent un réseau mobile pour la connectivité de données ou non.

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

7.4.1.1. Compatibilité du blocage de numéros

Les implémentations d'appareils Android Telephony DOIVENT inclure la fonctionnalité de blocage des numéros et:

  • DOIT implémenter entièrement 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. La seule exception est lorsque le blocage de numéro est temporairement levé, comme décrit dans la documentation du SDK.
  • NE DOIT PAS écrire au fournisseur du journal 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 UI de gestion des numéros bloqués, qui s'ouvre avec l'intent renvoyé par la méthode TelecomManager.createManageBlockedNumbersIntent().
  • NE DOIT PAS permettre aux utilisateurs secondaires de consulter ni de modifier les numéros bloqués sur l'appareil, car la plate-forme Android suppose que l'utilisateur principal a le contrôle total des services de téléphonie, une seule instance, sur l'appareil. L'interface utilisateur liée au blocage DOIT être masquée pour les utilisateurs secondaires, et la liste de blocage DOIT toujours être respectée.
  • Les numéros bloqués devraient être migrés vers le fournisseur lorsqu'un appareil passe à Android 7.0.

7.4.2. IEEE 802.11 (Wi-Fi)

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

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

7.4.2.1. Wi-Fi Direct

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

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

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

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

7.4.3. Bluetooth

Les implémentations de la montre Android doivent impérativement être compatibles avec le Bluetooth. Les implémentations d'Android TV DOIVENT être compatibles avec le Bluetooth et le Bluetooth LE. Les implémentations Android Auto doivent ÊTRE compatibles avec le Bluetooth et DEVRIENT être compatibles avec le Bluetooth LE.

Les implémentations d'appareils compatibles avec la fonctionnalité android.hardware.vr.high_performance DOIVENT être compatibles avec le Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE.

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

Les implémentations d'Android Auto DEVRAIENT être compatibles avec le profil d'accès aux messages (MAP). Les implémentations Android Auto doivent être compatibles avec les profils Bluetooth suivants:

  • Appels téléphoniques via le profil mains libres (HFP)
  • Lecture de contenus multimédias via le profil de distribution audio (A2DP)
  • Contrôle de la lecture de contenus multimédias via le profil de télécommande (AVRCP).
  • Partage de contacts à l'aide du profil d'accès au carnet d'adresses (PBAP)

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

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

7.4.4. Communication en champ proche

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

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

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

Android est compatible avec le mode NFC Host Card Emulation (HCE). Si l'implémentation d'un appareil inclut un chipset de contrôleur NFC compatible avec la technologie HCE (pour NfcA et/ou NfcB) et qu'il prend en charge le routage de l'ID d'application (AID), il:

  • DOIT signaler la constante de fonctionnalité android.hardware.nfc.hce.
  • DOIT prendre en charge 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 implémente la fonctionnalité pour les applications tierces, elle:

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

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

  • MIFARE Classic
  • MIFARE Ultralight
  • NDEF sur MIFARE Classic

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

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

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

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

7.4.5. Capacité réseau minimale

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

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

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

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

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

IPv6 DOIT être activé par défaut.

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

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

7.4.6. Paramètres de synchronisation

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

7.4.7. Économiseur de données

Il est vivement recommandé d'implémenter le mode Économiseur de données pour les appareils connectés à un réseau limité.

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

  • 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 ou de supprimer des applications de la liste d'autorisation.

À l'inverse, si une implémentation d'appareil ne fournit pas le mode Économiseur de données:

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

  • NE DOIT PAS diffuser ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

  • DOIT comporter 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, à l'opposé de l'écran. Autrement dit, elle capture des scènes à l'arrière de l'appareil, comme une caméra traditionnelle. Une caméra avant est une caméra située du même côté de l'appareil que l'écran. C'est-à-dire une caméra généralement utilisée pour prendre une photo de l'utilisateur, par exemple pour les visioconférences et les applications similaires.

Si une implémentation d'appareil inclut au moins une caméra, une application DOIT pouvoir allouer simultanément trois bitmaps RGBA_8888 égaux à la taille des images produites par le capteur d'appareil photo de la plus haute résolution de l'appareil, lorsque la caméra est ouverte à des fins d'aperçu de base et de capture d'image.

7.5.1. Caméra arrière

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

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

7.5.2. Caméra avant

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

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

7.5.3. Caméra externe

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

  • DOIT déclarer les indicateurs de fonctionnalité de la plate-forme android.hardware.camera.external et android.hardware camera.any .
  • Peut être compatible avec plusieurs caméras.
  • DOIT être compatible avec la classe vidéo USB (UVC 1.0 ou version ultérieure) si la caméra externe se connecte via le port USB.
  • DOIT prendre en charge les compressions vidéo telles que MJPEG pour permettre le transfert de flux non encodés de haute qualité (c'est-à-dire des flux d'images bruts ou compressés indépendamment).
  • PEUT prendre en charge l'encodage vidéo basé sur la caméra. Si elle est prise en charge, l'implémentation de l'appareil doit pouvoir accéder à un flux non encodé / MJPEG simultané (résolution VGA ou supérieure).

7.5.4. Comportement de l'API Camera

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

L'ancien package d'API, android.hardware.Camera, est marqué comme obsolète dans Android 5.0. Toutefois, comme il doit toujours être disponible pour que les applications puissent utiliser les implémentations d'appareils Android, vous devez assurer la 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 à la caméra, pour toutes les caméras disponibles:

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

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

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

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

Les implémentations d'appareils DOIVENT également déclarer les fonctionnalités de caméra 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 l'indicateur de fonctionnalité si l'un de ses appareils photo connectés est compatible avec la fonctionnalité.

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

Les implémentations d'appareils DOIVENT diffuser l'intent Camera.ACTION_NEW_VIDEO chaque fois qu'une nouvelle vidéo est enregistrée par 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 à faire correspondre la dimension longue de la caméra à la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil, c'est-à-dire aux appareils en mode paysage et en mode portrait.

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimums

Les appareils Android TV doivent disposer d'au moins 4 Go d'espace de stockage non volatile pour les données privées de l'application.

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

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

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

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

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

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

7.6.2. Stockage partagé de l'application

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

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

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

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

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

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

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

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

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

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

7.6.3. Stockage adoptable

Nous vous RECOMMANDONS vivement d'implémenter le stockage adoptable si le port de l'appareil de stockage amovible se trouve dans un emplacement stable à long terme, comme dans le compartiment de la batterie ou sous une autre protection.

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

7.7. USB

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

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 être connectable à un hôte USB doté d'un port USB Type-A ou Type-C standard.
  • Le port DOIT utiliser le facteur de forme USB micro-B, micro-AB ou Type-C. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
  • Le port DOIT se trouver en bas de l'appareil (selon l'orientation naturelle) ou permettre la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), afin que l'affichage s'affiche correctement lorsque l'appareil est orienté avec le port en bas. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
  • Il doit 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 Media Transfer.
  • Il DOIT implémenter l'API et la spécification Android Open Accessory (AOA) comme indiqué dans la documentation du SDK Android. S'il s'agit d'un appareil Android portable, il DOIT implémenter l'API AOA. Implémentations d'appareils implémentant la spécification AOA :
    • DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.accessory.
    • 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 chaîne iInterface de la description de l'interface du stockage de masse USB.
  • Il DOIT être compatible avec un courant de 1,5 A pendant le chirp HS et le trafic, comme spécifié dans la spécification de recharge de la batterie USB, version 1.2. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
  • Les appareils Type-C DOIVENT détecter les chargeurs 1,5 A et 3 A conformément à la norme de résistance Type-C, et ils doivent détecter les modifications de la publicité.
  • Il est vivement recommandé que les appareils Type-C compatibles avec le mode hôte USB prennent en charge la recharge par Power Delivery pour le transfert de données et le changement de rôle d'alimentation.
  • Les appareils Type-C DOIVENT être compatibles avec Power Delivery pour la recharge haute tension et les modes alternatifs tels que la sortie d'écran.
  • La valeur de iSerialNumber dans le descripteur d'appareil standard USB DOIT être égale à celle d'android.os.Build.SERIAL.
  • Il est vivement recommandé que les appareils Type-C ne prennent pas en charge les méthodes de recharge propriétaires qui modifient la tension Vbus au-delà des niveaux par défaut ou qui modifient les rôles de source/piège, car cela pourrait entraîner des problèmes d'interopérabilité avec les chargeurs ou les appareils compatibles avec les méthodes de recharge USB standard. Bien que cette fonctionnalité soit "FORTEMENT RECOMMANDÉE", dans les futures versions d'Android, nous pourrons exiger que tous les appareils Type-C soient compatibles avec l'interopérabilité complète avec les chargeurs Type-C standards.

7.7.2. Mode hôte USB

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

  • DOIT utiliser un port USB Type-C si l'implémentation de l'appareil est compatible avec USB 3.1.
  • PEUT utiliser un facteur de forme de port non standard, mais doit être fourni avec un ou plusieurs câbles permettant de l'adapter à un port USB type-A ou type-C standard.
  • PEUT utiliser un port USB micro-AB, mais si c'est le cas, DOIT être fourni avec un ou plusieurs câbles permettant de l'adapter à un port USB Type-A ou Type-C standard.
  • Il est FORTEMENT RECOMMANDÉ d'implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android.
  • 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.
  • DOIT prendre en charge la recharge de l'appareil en mode hôte, en annonçant un courant de source d'au moins 1,5 A, comme indiqué dans la section "Paramètres de terminaison" de la [spécification de la version 1.2 du câble et du connecteur USB Type-C] (http://www.usb.org/developers/docs/usb_31_021517.zip) pour les connecteurs USB Type-C ou en utilisant la plage de courant de sortie du port en aval de recharge(CDP) comme indiqué dans les spécifications de recharge de la batterie USB, version 1.2 pour les connecteurs Micro-AB.
  • Il est vivement recommandé que les appareils USB Type-C soient compatibles avec DisplayPort, qu'ils acceptent les débits de données USB SuperSpeed et qu'ils soient compatibles avec Power Delivery pour le transfert de données et le changement de rôle d'alimentation.
  • Les appareils dotés de ports de type A ou de type AB NE DOIVENT PAS être livrés avec un adaptateur permettant de convertir ce port en prise de type C.
  • DOIT reconnaître tous les appareils MTP (Media Transfer Protocol) connectés à distance et rendre leurs contenus accessibles via les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT et ACTION_CREATE_DOCUMENT, si le Storage Access Framework (SAF) est compatible.
  • Si vous utilisez un port USB Type-C et que vous prenez en charge le mode périphérique, vous DEVEZ implémenter la fonctionnalité de port à double rôle telle que définie par la spécification USB Type-C (section 4.5.1.3.3).
  • Si la fonctionnalité de port à double rôle est prise en charge, vous DEVEZ implémenter le modèle Try.* le plus adapté au facteur de forme de l'appareil. Par exemple, un appareil portable DOIT implémenter le modèle Try.SNK.

7.8. Audio

7.8.1. Micro

Les implémentations Android Handheld, Watch et Automotive DOIVENT inclure un micro.

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

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

7.8.2. Sortie audio

Les montres Android peuvent inclure une sortie audio.

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

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

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

L'implémentation d'un appareil Android Watch peut, mais ne doit pas, comporter une sortie audio. En revanche, les autres types d'implémentations d'appareils Android doivent comporter une sortie audio et déclarer android.hardware.audio.output.

7.8.2.1. Ports audio analogiques

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

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

7.8.3. Ultrasons proches

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

  • Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND est défini sur "true", les sources audio VOICE_RECOGNITION et UNPROCESSED doivent respecter les exigences suivantes :
    • La réponse moyenne de puissance du micro dans la bande de fréquences 18,5 kHz à 20 kHz NE DOIT PAS être inférieure de plus de 15 dB à la réponse à 2 kHz.
    • Le rapport signal/bruit non pondéré du micro entre 18,5 kHz et 20 kHz pour un son de 19 kHz à -26 dBFS DOIT être d'au moins 50 dB.
  • Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est défini sur "true", la réponse moyenne du haut-parleur dans la plage de fréquences 18,5 kHz à 20 kHz DOIT être supérieure d'au moins 40 dB à la réponse à 2 kHz.

7.9. Réalité virtuelle

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

7.9.1. Mode réalité virtuelle

Les implémentations d'appareils Android portables compatibles avec un mode pour les applications de RV qui gèrent le rendu stéréoscopique des notifications et désactivent les composants d'interface utilisateur du système monoculaire lorsque l'attention de l'utilisateur est dirigée vers une application de RV DOIVENT déclarer la fonctionnalité android.software.vr.mode. Les appareils déclarant cette fonctionnalité DOIVENT inclure une application implémentant android.service.vr.VrListenerService pouvant être activée par les applications de réalité virtuelle via android.app.Activity#setVrModeEnabled .

7.9.2. Réalité virtuelle hautes performances

Les implémentations d'appareils Android portables DOIVENT indiquer la prise en charge de la réalité virtuelle hautes performances pour des périodes d'utilisation plus longues via l'indicateur 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 PEUVENT prendre en charge l'API Process.getExclusiveCores pour renvoyer les numéros des cœurs de processeur exclusifs à l'application de premier plan principale. Si le noyau exclusif est pris en charge, il DOIT empêcher l'exécution d'autres processus d'espace utilisateur (à l'exception des pilotes d'appareils utilisés par l'application), mais PEUT autoriser l'exécution de certains processus de noyau si nécessaire.
  • Les implémentations d'appareils DOIVENT prendre en charge le mode Performances soutenues.
  • Les implémentations d'appareils DOIVENT être compatibles avec OpenGL ES 3.2.
  • Les implémentations d'appareils DOIVENT être compatibles avec le niveau de matériel Vulkan 0 et DEVRAIENT être compatibles avec 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'ils puissent être utilisés pour le mode tampon partagé, et exposer les extensions dans la liste des extensions EGL disponibles.
  • Le GPU et l'écran DOIVENT pouvoir synchroniser l'accès au tampon d'affichage partagé afin que le rendu alterné des contenus VR à 60 FPS avec deux contextes de rendu soit affiché 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_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 et GL_OVR_multiview_multisampled_render_to_texture, et exposer les extensions dans la liste des extensions GL disponibles.
  • Les implémentations d'appareils DOIVENT implémenter EGL_EXT_protected_content et GL_EXT_protected_textures afin qu'ils puissent être utilisés pour la lecture vidéo sécurisée des textures, 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 et 40 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 FPS et 10 Mbit/s ou 2 instances de 1 920 x 1 080 à 60 FPS et 20 Mbit/s).
  • Les implémentations d'appareils DOIVENT être compatibles avec HEVC et VP9, DOIVENT être en mesure de décoder au moins 1 920 x 1 080@30 fps - 10 Mbit/s et DOIVENT être en mesure de décoder 3 840 x 2 160@30 fps - 20 Mbit/s (équivalent à 4 instances de 1 920 x 1 080@30 fps - 5 Mbit/s).
  • Il est vivement recommandé que les implémentations de l'appareil soient compatibles avec 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 précises pour la température cutanée.
  • L'implémentation de l'appareil DOIT comporter un écran intégré, dont la résolution DOIT être d'au moins FullHD(1080p) et EST FORTEMENT RECOMMANDÉE d'être QuadHD (1440p) ou plus.
  • L'écran doit mesurer entre 4,7 et 6 pouces de diagonale.
  • L'écran doit se mettre à jour à au moins 60 Hz en mode VR.
  • La latence d'affichage pour les transitions gris-gris, blanc-noir et noir-blanc DOIT être inférieure ou égale à 3 ms.
  • L'écran DOIT prendre en charge un mode à faible persistance avec une persistance de 5 ms maximum,la persistance étant définie comme la durée pendant laquelle un pixel émet de la lumière.
  • Les implémentations d'appareils DOIVENT être compatibles avec le Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE (section 7.4.3).

8. Performances et puissance

Certains critères de performances et d'alimentation minimaux sont essentiels à l'expérience utilisateur et ont un impact sur les hypothèses de référence des développeurs lorsqu'ils développent une application. Les appareils Android Watch DOIVENT respecter les critères suivants, et les autres types d'implémentations d'appareils DOIVENT les respecter.

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

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

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

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

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

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

8.3. Modes d'économie d'énergie

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 visibles par l'utilisateur final. De plus, les algorithmes de déclenchement, de maintenance, de réveil et d'utilisation des paramètres système globaux de ces modes d'économie d'énergie DOIVENT respecter le projet Open Source Android.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT implémenter l'un ou l'ensemble des quatre états d'alimentation en veille définis par l'ACPI (Advanced Configuration and Power Interface), mais si elles implémentent les états d'alimentation S3 et S4, elles ne peuvent passer à ces états que lorsque le capot qui fait partie physiquement de l'appareil est fermé.

8.4. Comptabilisation de la consommation d'énergie

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

  • DOIT pouvoir suivre la consommation d'énergie des composants matériels et attribuer cette consommation à des applications spécifiques. Plus précisément, les implémentations :
    • DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
    • DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
    • DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
    • DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence grâce à 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 cohérentes

Les performances peuvent fluctuer de manière importante pour les applications de longue durée hautes performances, soit en raison des autres applications exécutées en arrière-plan, soit en raison du débit limité du processeur en raison de limites de température. Android inclut des interfaces programmatiques afin que, lorsque l'appareil est compatible, l'application de premier plan puisse 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 cohérent pendant une durée prolongée lorsqu'il est demandé via la méthode d'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 d'API PowerManager.isSustainedPerformanceModeSupported().

Les implémentations d'appareils comportant au moins deux cœurs de processeur DOIVENT fournir au moins un cœur exclusif pouvant être réservé par l'application de premier plan supérieure. Le cas échéant, les implémentations DOIVENT répondre aux exigences suivantes:

  • Les implémentations DOIVENT signaler via la méthode d'API Process.getExclusiveCores() les numéros d'ID des cœurs exclusifs pouvant être réservés par l'application de premier plan supérieure.
  • Les implémentations d'appareils DOIVENT empêcher l'exécution de tout processus d'espace utilisateur, à l'exception des pilotes d'appareil utilisés par l'application sur les cœurs exclusifs, mais PEUVENT autoriser l'exécution de certains processus de noyau si nécessaire.

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

9.1. Autorisations

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

Les autorisations avec un protectionLevel de PROTECTION_FLAG_PRIVILEGED ne doivent être accordées qu'aux applications préchargées dans le ou les chemins d'accès privilégiés de la liste d'autorisations de l'image système, comme 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. Les applications avec targetSdkVersion > 22 les demandent au moment de l'exécution. Implémentations de l'appareil:

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

9.2. UID et isolation des processus

Les implémentations d'appareils DOIVENT prendre en charge le modèle de bac à sable d'application Android, dans lequel chaque application s'exécute en tant qu'UID unique de style Unix et dans un processus distinct. Les implémentations d'appareils DOIVENT prendre en charge l'exécution de plusieurs applications avec le même ID utilisateur Linux, à condition que les applications soient correctement signées et créées, comme défini dans la documentation de référence sur la sécurité et les autorisations.

9.3. Autorisations du système de fichiers

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

9.4. Environnements d'exécution alternatifs

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

Les environnements d'exécution alternatifs DOIVENT eux-mêmes être des applications Android et respecter le modèle de sécurité Android standard, comme décrit 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 le mécanisme <uses-permission>.

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

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

  • DOIT installer les applications via le PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).
  • PEUT fournir un seul bac à sable Android partagé par toutes les applications utilisant l'environnement d'exécution alternatif.
  • Les applications installées à l'aide d'un autre environnement d'exécution NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf via les mécanismes Android standards d'ID utilisateur partagé et de certificat de signature.
  • NE DOIT PAS se lancer avec, accorder ni être autorisé à accéder aux bacs à sable correspondant à d'autres applications Android.
  • NE DOIT PAS être lancée avec, ni être accordée, ni accorder à d'autres applications des droits de super-utilisateur (root) ou de tout autre ID utilisateur.

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

Lors de l'installation d'applications, les environnements d'exécution alternatifs DOIVENT obtenir le consentement de l'utilisateur pour les autorisations Android utilisées par l'application. Si une application doit utiliser une ressource d'appareil pour laquelle une autorisation Android correspondante est disponible (appareil photo, GPS, etc.), le runtime alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource. Si l'environnement d'exécution n'enregistre pas les fonctionnalités de l'application de cette manière, il DOIT lister toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement d'exécution.

9.5. Compatibilité multi-utilisateur

Cette fonctionnalité est facultative pour tous les types d'appareils.

Android est compatible avec plusieurs utilisateurs et offre une isolation complète des utilisateurs. Les implémentations d'appareils PEUVENT permettre l'utilisation par plusieurs utilisateurs, mais lorsqu'elles le font, elles DOIVENT respecter les exigences suivantes concernant la prise en charge du mode multi-utilisateur:

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

9.6. Avertissement concernant les SMS premium

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

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

Le bac à sable Android inclut des fonctionnalités qui utilisent le système de contrôle des accès obligatoire (MAC) de Security-Enhanced Linux (SELinux), l'exécution en bac à sable seccomp et d'autres fonctionnalités de sécurité du noyau Linux. SELinux ou toute autre fonctionnalité de sécurité implémentée sous le framework Android:

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

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

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

Implémentations de l'appareil:

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

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

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

9.8. Confidentialité

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

Si une implémentation d'appareil comporte un mécanisme qui achemine le trafic de données réseau via un serveur proxy ou une passerelle VPN par défaut (par exemple, le préchargement d'un service VPN avec l'autorisation android.permission.CONTROL_VPN accordée), l'implémentation de l'appareil DOIT demander le consentement de l'utilisateur avant d'activer ce mécanisme, sauf si ce VPN est activé par le contrôleur de stratégie de l'appareil via DevicePolicyManager.setAlwaysOnVpnPackage(), auquel cas l'utilisateur n'a pas besoin de donner un consentement distinct, mais DOIT simplement être informé.

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

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

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

9.9. Chiffrement du stockage des données

Facultatif pour les implémentations d'appareils Android sans écran de verrouillage sécurisé.

Si l'implémentation de l'appareil est compatible avec 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 de données des données privées de l'application (partition /data), ainsi que la partition de stockage partagé de l'application (partition /sdcard) si elle fait partie permanente et non amovible de l'appareil.

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

Les implémentations d'appareils DOIVENT respecter l'exigence de chiffrement du stockage des données ci-dessus en implémentant le chiffrement basé sur les fichiers (FBE).

9.9.1. Démarrage direct

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. Plus précisément, 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 les emplacements de stockage chiffrés par appareil (DE) et par identifiant (CE) sont disponibles pour l'utilisateur.

9.9.2. Chiffrement basé sur les fichiers

Implémentations d'appareils compatibles avec FBE:

  • DOIT démarrer sans demander à l'utilisateur de fournir des identifiants et autoriser les applications compatibles avec le démarrage direct à accéder au stockage chiffré de l'appareil (DE) après la diffusion du message LOCKED_BOOT_COMPLETED.
  • DOIT n'autoriser l'accès au stockage chiffré par identifiants (CE) qu'après que l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (code, code PIN, schéma ou empreinte digitale, par exemple) et que le message ACTION_USER_UNLOCKED a été diffusé. Les implémentations d'appareils NE DOIVENT PAS proposer de méthode permettant de déverrouiller le stockage protégé par le CE sans les identifiants fournis par l'utilisateur.
  • DOIT prendre en charge le démarrage validé et s'assurer que les clés de chiffrement côté client sont liées de manière cryptographique à la racine matérielle de confiance 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 du nom de fichier à l'aide d'AES avec une longueur de clé de 256 bits en mode CBC-CTS.
  • PEUT prendre en charge d'autres algorithmes de chiffrement, longueurs de clé et modes pour le chiffrement du contenu et du nom des fichiers, mais DOIT utiliser les algorithmes, longueurs de clé et modes pris en charge de manière obligatoire par défaut.
  • DOIT rendre les applications essentielles préchargées (Alarme, Téléphone, Messenger, par exemple) compatibles avec le Démarrage direct.

Les clés protégeant les zones de stockage CE et DE:

  • DOIT être lié de manière cryptographique à un Keystore avec support matériel. Les clés CE doivent être associées aux identifiants de l'écran de verrouillage de l'utilisateur. Si l'utilisateur n'a pas spécifié d'identifiants pour l'écran de verrouillage, les clés CE DOIVENT être associées à un code secret par défaut.
  • DOIVENT être uniques et distinctes. Autrement dit, la clé CE ou DE d'un utilisateur ne doit pas correspondre à celle d'un autre utilisateur.

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

9.10. Intégrité de l'appareil

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

Les implémentations d'appareils DOIVENT indiquer correctement, via la méthode de l'API système PersistentDataBlockManager.getFlashLockState(), si l'état de leur bootloader permet le flashage de l'image système. L'état FLASH_LOCK_UNKNOWN est réservé aux implémentations d'appareils mises à 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 le flag de fonctionnalité de plate-forme android.software.verified_boot.
  • Effectuez une vérification à 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 de l'étape suivante avant d'exécuter le code de l'étape suivante.
  • Utilisez des algorithmes de validation aussi sécurisés que les recommandations actuelles du NIST pour les algorithmes de hachage (SHA-256) et les tailles de clé publique (RSA-2048).
  • NE DOIT PAS permettre le démarrage lorsque la validation du système échoue, sauf si l'utilisateur accepte de tenter le démarrage de toute façon, auquel cas les données de tous les 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 Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité dm-verity du noyau Linux.

À partir d'Android 6.0, les implémentations d'appareils avec des performances de cryptographie AES (Advanced Encryption Standard) supérieures à 50 Mo/s DOIVENT prendre en charge le démarrage validé pour l'intégrité de l'appareil.

Si une implémentation d'appareil est déjà lancée sans prendre en charge le démarrage validé sur une version antérieure d'Android, cet appareil ne peut pas prendre en charge cette fonctionnalité avec une mise à jour logicielle du 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 cryptographiques via l'API KeyChain ou l'API Keystore.

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

  • NE DOIT PAS limiter le nombre de clés pouvant être générées et DOIT au moins permettre d'importer plus de 8 192 clés.
  • L'authentification de l'écran de verrouillage DOIT limiter le nombre 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 :
    • DOIT disposer d'implémentations matérielles des algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que des fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du système Android Keystore.
    • DOIT effectuer 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 que si l'authentification aboutit. Le projet Open Source Android en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper qui peut être utilisée pour répondre à cette exigence.

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

9.11.1. Écran de verrouillage sécurisé

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

  • Si la méthode d'authentification est basée sur un secret connu, elle NE DOIT PAS être traitée comme un écran de verrouillage sécurisé, sauf si elle répond à toutes les exigences suivantes :
    • L'entropie de la longueur d'entrée la plus courte autorisée DOIT être supérieure à 10 bits.
    • L'entropie maximale de toutes les entrées possibles DOIT être supérieure à 18 bits.
    • NE DOIT PAS remplacer l'une 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é du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_SOMETHING .
  • La méthode d'authentification, si elle est basée sur un jeton physique ou la position, NE DOIT PAS être traitée comme un écran de verrouillage sécurisé, sauf si elle répond à toutes les exigences suivantes :
    • Il doit comporter un mécanisme de remplacement permettant d'utiliser l'une des méthodes d'authentification principales basées 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 ne permettre que l'authentification principale de déverrouiller l'écran lorsque l'application DPC (Device Policy Controller) a défini la stratégie 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 la méthode d'authentification est basée sur la biométrie, elle NE DOIT PAS être traitée comme un écran de verrouillage sécurisé, sauf si elle répond à toutes les exigences suivantes :
    • Il doit comporter un mécanisme de remplacement permettant d'utiliser l'une des méthodes d'authentification principales basées 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 que l'authentification principale à déverrouiller l'écran lorsque l'application DPC (Device Policy Controller) a défini la règle de la fonctionnalité Keguard en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
    • Il DOIT avoir un taux de fausse acceptation égal ou supérieur à celui requis pour un lecteur d'empreinte digitale, comme décrit dans la section 7.3.10. Sinon, il DOIT être désactivé et ne permettre que l'authentification principale de déverrouiller l'écran 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 traitée comme un écran de verrouillage sécurisé, elle :
  • Si la méthode d'authentification est basée sur un jeton physique, la localisation ou des données biométriques dont le taux de fausse acceptation est supérieur à celui requis pour les capteurs d'empreinte digitale, comme décrit dans la section 7.3.10, elle :

9.12. Suppression des données

Les appareils DOIVENT fournir aux utilisateurs un mécanisme permettant d'effectuer un "rétablissement de la configuration d'usine" qui permet de supprimer de manière logique et physique toutes les données, à l'exception des suivantes:

  • Image système
  • Tous les fichiers du 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. Cette méthode doit respecter les normes du secteur applicables à la suppression des données, telles que la norme NIST SP800-88. Cette méthode DOIT être utilisée pour l'implémentation de l'API wipeData() (qui fait partie de l'API Android Device Administration) décrite dans la section 3.9 "Gestion des appareils".

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

9.13. Mode démarrage sécurisé

Android propose un mode permettant aux utilisateurs de démarrer en 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 Démarrage sécurisé", permet à l'utilisateur de désinstaller les applications tierces potentiellement dangereuses.

Il est vivement recommandé d'implémenter le mode Démarrage sécurisé sur les appareils Android et de respecter les exigences suivantes:

  • Les implémentations d'appareils DOIVENT permettre à l'utilisateur d'accéder au mode de démarrage sécurisé à partir du menu de démarrage, qui est accessible via un workflow différent de celui du démarrage normal.

  • Les implémentations d'appareils DOIVENT fournir à l'utilisateur la possibilité de passer en mode de démarrage sécurisé de manière ininterrompue par les applications tierces installées sur l'appareil, sauf si l'application tierce est un contrôleur de stratégie d'appareil et a défini l'indicateur UserManager.DISALLOW_SAFE_BOOT sur "true".

  • Les implémentations d'appareils DOIVENT permettre à l'utilisateur de désinstaller toutes les applications tierces en mode sans échec.

9.14. Isolation du système 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 éviter toute interaction malveillante ou involontaire entre le framework Android ou les applications tierces et les sous-systèmes du véhicule. Voici ces fonctionnalités de sécurité:

  • Messages de contrôle des accès provenant des sous-systèmes du véhicule du framework Android, par exemple, liste d'autorisation des types et sources de messages autorisés.
  • Surveillance des attaques par déni de service provenant du framework Android ou d'applications tierces. Cela permet de se protéger contre les logiciels malveillants qui inondent le réseau du véhicule de trafic, ce qui peut entraîner un dysfonctionnement des sous-systèmes du véhicule.

10. Tests de compatibilité des logiciels

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

Toutefois, notez qu'aucun package de test logiciel n'est totalement complet. C'est pourquoi il est FORTEMENT RECOMMANDÉ aux implémentateurs d'appareils de procéder au minimum de modifications possibles à l'implémentation de référence et privilégiée d'Android disponible sur le Projet Android Open Source. Vous réduirez ainsi le risque d'introduire des bugs qui créent des incompatibilités nécessitant des retouches et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

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

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

10.2. Validateur CTS

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

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

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

11. Logiciels pouvant être mis à jour

Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer de mises à niveau en temps réel. Autrement dit, 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 OTA (Over The Air) avec mise à jour hors connexion via un redémarrage.
  • Mises à jour "partagée" via USB à partir d'un PC hôte.
  • Mises à jour "hors connexion" via un redémarrage et une mise à jour à partir d'un fichier sur un stockage amovible.

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

Le mécanisme de mise à jour utilisé DOIT être compatible avec les mises à jour sans effacer les données utilisateur. Autrement dit, le mécanisme de mise à jour DOIT préserver les données privées et 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 DOIT permettre de vérifier que l'image système est identique au résultat attendu après une mise à jour OTA. L'implémentation OTA basée sur les blocs dans le projet Android Open Source en amont, ajoutée depuis Android 5.1, répond à cette exigence.

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

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

12. Journal des modifications du document

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

Pour obtenir un résumé des modifications apportées aux sections sur les personnes:

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

12.1. Conseils pour afficher le journal des modifications

Les modifications sont marquées comme suit:

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

  • Documentation
    Modifications esthétiques ou liées à la compilation.

Pour une meilleure visibilité, ajoutez les paramètres d'URL pretty=full et no-merges à vos URL de journal des modifications.

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité Android et demander des précisions ou signaler les problèmes que vous pensez ne pas être couverts par le document.