Révision 1
Dernière mise à jour: 12 janvier 2015
Copyright © 2015, Google Inc. Tous droits réservés.
compatibility@android.com
Sommaire
1. Introduction
Ce document énonce les exigences à respecter pour que les appareils soient compatibles avec Android 5.0.
L'utilisation des termes "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" est conforme à la norme IETF définie dans RFC2119 [Ressources, 1].
Dans ce document, un "implémentateur d'appareils" ou "implémentateur" désigne une personne ou une organisation qui développe une solution matérielle/logicielle exécutant Android 5.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 5.0, les implémentations d'appareils DOIVENT respecter les exigences présentées dans cette définition de la compatibilité, y compris les documents incorporés par référence.
Lorsque cette définition ou les tests logiciels décrits dans la section 10 sont silencieux, ambigus ou incomplets, il incombe à l'implémentateur de l'appareil de s'assurer de la compatibilité avec les implémentations existantes.
C'est pourquoi le projet Android Open Source [Ressources, 2] est à la fois l'implémentation de référence et l'implémentation privilégiée d'Android. Les implémentateurs d'appareils sont fortement encouragés à 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, cette pratique est fortement déconseillée, car réussir les tests logiciels devient beaucoup plus difficile. Il est de la responsabilité de l'implémentateur de garantir une compatibilité comportementale totale avec l'implémentation Android standard, y compris au-delà de la Compatibility Test Suite. Enfin, notez que certaines substitutions et modifications de composants sont explicitement interdites par ce document.
De nombreuses ressources listées dans la section 14 sont dérivées directement ou indirectement du SDK Android et seront fonctionnellement identiques aux informations de la documentation de ce SDK. Dans le cas où cette définition de la compatibilité ou la suite de tests de compatibilité ne sont pas conformes à la documentation du SDK, la documentation du SDK est considérée comme faisant autorité. Tous les détails techniques fournis dans les références incluses dans la section 14 sont considérés comme faisant partie de cette définition de la compatibilité.
2. Types d'appareils
Bien que le projet Android Open Source ait été utilisé pour implémenter différents types et facteurs de forme d'appareils, de nombreux aspects de l'architecture et des exigences de compatibilité ont été optimisés pour les appareils portables. À partir d'Android 5.0, le projet Android Open Source vise à prendre en charge une plus grande variété de types d'appareils, comme décrit dans cette section.
Appareil Android portable désigne une implémentation d'appareil Android qui est généralement utilisée en le tenant dans la main, comme les lecteurs MP3, les téléphones et les tablettes. Implémentations d'appareils Android portables:
- DOIT être équipé d'un écran tactile intégré
- DOIT disposer d'une source d'alimentation permettant la mobilité, comme une batterie
Un appareil Android TV désigne une implémentation d'appareil Android qui est une interface de divertissement permettant de consommer des contenus multimédias numériques, des films, des jeux, des applications et/ou de la télévision en direct pour les utilisateurs assis à environ trois mètres (interface utilisateur "relax" ou "10 pieds"). Appareils Android TV:
- DOIT comporter un écran intégré OU inclure un port de sortie vidéo, tel que VGA, HDMI ou un port sans fil pour l'affichage
- DOIT déclarer les fonctionnalités android.software.leanback et android.hardware.type.television [Ressources, 3]
Un appareil Android Watch désigne une implémentation d'appareil Android destinée à être portée sur le corps, peut-être au poignet, et:
- DOIT avoir un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces
- DOIT déclarer la fonctionnalité android.hardware.type.watch
- DOIT être compatible avec uiMode = UI_MODE_TYPE_WATCH [Resources, 4]
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 5.0, sauf si l'exigence est explicitement décrite comme ne s'appliquant qu'à un type d'appareil Android spécifique.
2.1 Configurations de l'appareil
Voici un récapitulatif des principales différences de configuration matérielle par type d'appareil. (Les cellules vides indiquent "POURRA"). Toutes les configurations ne sont pas couvertes dans ce tableau. Pour en savoir plus, consultez les sections matérielles concernées.
|
Catégorie |
Fonctionnalité |
Section |
Micro à main |
Télévision |
Montre |
Autre |
|
Entrée |
Pavé directionnel |
OBLIGATOIRE |
||||
|
Écran tactile |
OBLIGATOIRE |
OBLIGATOIRE |
DOIT |
|||
|
Micro |
OBLIGATOIRE |
DOIT |
OBLIGATOIRE |
DOIT |
||
|
Capteurs |
Accéléromètre |
DOIT |
DOIT |
DOIT |
||
|
GPS |
DOIT |
|||||
|
Connectivité |
Wi-Fi |
DOIT |
OBLIGATOIRE |
DOIT |
||
|
Wi-Fi Direct |
DOIT |
DOIT |
DOIT |
|||
|
Bluetooth |
DOIT |
OBLIGATOIRE |
OBLIGATOIRE |
DOIT |
||
|
Bluetooth à basse consommation |
DOIT |
OBLIGATOIRE |
DOIT |
DOIT |
||
|
Mode périphérique/ hôte USB |
DOIT |
|
DOIT |
|||
|
Sortie |
Ports de sortie audio et/ou de haut-parleur |
OBLIGATOIRE |
OBLIGATOIRE |
OBLIGATOIRE |
3. Logiciel
3.1. Compatibilité avec les API gérées
L'environnement d'exécution de bytecode Dalvik géré est le principal moyen de transport des applications Android. L'API Android est l'ensemble d'interfaces de la plate-forme Android exposées aux applications exécutées dans l'environnement d'exécution géré. Les implémentations d'appareils DOIVENT fournir des implémentations complètes, y compris tous les comportements documentés, de toute API documentée exposée par le SDK Android [Ressources, 5] ou de toute API décorée avec le repère "@SystemApi" dans le code source Android en amont.
Les implémentations d'appareils NE DOIVENT PAS omettre d'API gérées, modifier les interfaces ou les signatures d'API, s'écarter du comportement documenté ni inclure de no-ops, sauf dans les cas spécifiquement autorisés par cette définition de compatibilité.
Cette définition de compatibilité permet d'omettre certains types de matériel pour lesquels Android inclut des API par les implémentations d'appareils. Dans ce cas, les API DOIVENT toujours être présentes et se comporter de manière raisonnable. Pour connaître les exigences spécifiques à ce scénario, consultez la section 7.
3.2. Compatibilité des API avec une compatibilité douce
En plus des API gérées de la section 3.1, Android inclut également une API "soft" importante, 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 [Ressources, 6]. Notez que la section 9 liste des exigences supplémentaires liées au modèle de sécurité Android.
3.2.2. Paramètres de compilation
Les API Android incluent un certain nombre de constantes dans la classe android.os.Build [Ressources, 7] qui sont destinées à décrire l'appareil actuel. Pour fournir des valeurs cohérentes et pertinentes dans les implémentations d'appareils, le tableau ci-dessous inclut des restrictions supplémentaires sur les formats de ces valeurs auxquelles les implémentations d'appareils DOIVENT se conformer.
|
Paramètre |
Détails |
|
VERSION.RELEASE |
Version du système Android actuellement en cours d'exécution, au format lisible. Ce champ DOIT contenir l'une des valeurs de chaîne définies dans [Resources, 8]. |
|
VERSION.SDK |
Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 5.0, ce champ DOIT avoir la valeur entière 21. |
|
VERSION.SDK_INT |
Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 5.0, ce champ DOIT avoir la valeur entière 21. |
|
VERSION.INCREMENTAL |
Valeur choisie par l'implémentateur de l'appareil pour désigner la version spécifique du système Android en cours d'exécution, au format lisible par l'homme. Cette valeur NE DOIT PAS être réutilisée pour les différents builds mis à la disposition des utilisateurs finaux. L'utilisation typique de ce champ consiste à indiquer le numéro de build ou l'identifiant de modification de contrôle source utilisé pour générer le build. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide (""). |
|
JEUX DE SOCIÉTÉ |
Valeur choisie par l'implémentateur de l'appareil pour identifier le matériel interne spécifique utilisé par l'appareil, au format lisible par l'homme. Ce champ peut être utilisé pour indiquer la révision spécifique de la carte alimentant l'appareil. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". |
|
MARQUE |
Valeur reflétant le nom de la marque associé à l'appareil tel que connu des utilisateurs finaux. DOIT être au format lisible par l'homme et DOIT représenter le fabricant de l'appareil ou la marque de l'entreprise sous laquelle l'appareil est commercialisé. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". |
|
SUPPORTED_ABIS |
Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives. |
|
SUPPORTED_32_BIT_ABIS |
Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives. |
|
SUPPORTED_64_BIT_ABIS |
Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives. |
|
CPU_ABI |
Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives. |
|
CPU_ABI2 |
Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives. |
|
APPAREIL |
Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code identifiant la configuration des fonctionnalités matérielles et la conception industrielle de l'appareil. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". |
|
FINGERPRINT |
Chaîne qui identifie de manière unique ce build. Il DOIT être raisonnablement lisible par l'humain. Il DOIT respecter ce modèle: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Exemple : acme/myproduct/mydevice:5.0/LRWXX/3359:userdebug/test-keys L'empreinte ne doit PAS inclure d'espaces blancs. Si d'autres champs inclus dans le modèle ci-dessus contiennent des caractères d'espace, ils DOIVENT être remplacés dans l'empreinte de compilation par un autre caractère, tel que le trait de soulignement ("_"). La valeur de ce champ DOIT être encodable en ASCII 7 bits. |
|
MATÉRIEL |
Nom du matériel (à partir de la ligne de commande du kernel ou de /proc). Il DOIT être raisonnablement lisible par l'humain. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". |
|
ORGANISATEUR |
Chaîne qui identifie de manière unique l'hôte sur lequel le build a été créé, au format lisible par l'homme. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide (""). |
|
ID |
Identifiant choisi par l'implémentateur de l'appareil pour faire référence à une version spécifique, au format lisible par l'utilisateur. Ce champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisamment significative pour que les utilisateurs finaux puissent distinguer les builds logiciels. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$". |
|
FABRICANT |
Nom commercial du fabricant d'équipement d'origine (OEM) du produit. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide (""). |
|
MODÈLE |
Valeur choisie par l'implémentateur de l'appareil contenant le nom de l'appareil tel que connu par l'utilisateur final. Il DOIT s'agir du même nom que celui sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide (""). |
|
PRODUIT |
Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code du produit spécifique (code SKU) qui DOIT être unique au sein de la même marque. DOIT être lisible par l'humain, mais n'est pas nécessairement destiné à être vu par les utilisateurs finaux. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". |
|
SERIAL |
Un numéro de série matériel, qui DOIT être disponible. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^([a-zA-Z0-9]{6,20})$". |
|
TAGS |
Liste de tags choisis par l'implémentateur de l'appareil, séparés par une virgule, qui permet de distinguer davantage le build. Ce champ DOIT contenir l'une des valeurs correspondant aux trois configurations de signature de la plate-forme Android standards: release-keys, dev-keys et test-keys. |
|
DURÉE |
Valeur représentant le code temporel de la compilation. |
|
MACH |
Valeur choisie par l'implémentateur de l'appareil spécifiant la configuration d'exécution du build. Ce champ DOIT avoir l'une des valeurs correspondant aux trois configurations d'exécution Android typiques: user, userdebug ou eng. |
|
UTILISATEUR |
Nom ou ID utilisateur de l'utilisateur (ou de l'utilisateur automatique) qui a généré le build. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide (""). |
3.2.3. Compatibilité des intents
Les implémentations d'appareils DOIVENT respecter le système d'intent à liaison lâche d'Android, comme décrit dans les sections ci-dessous. Par "respecté", on entend que l'implémentateur de l'appareil DOIT fournir une activité ou un service Android qui spécifie un filtre d'intent correspondant qui se lie et implémente un comportement correct pour chaque modèle d'intent spécifié.
3.2.3.1. Intents d'application principaux
Les intents Android permettent aux composants d'application de demander des fonctionnalités à d'autres composants Android. Le projet Android en amont inclut une liste d'applications considérées comme des applications Android de base, qui implémente plusieurs modèles d'intent pour effectuer des actions courantes. Les applications principales d'Android sont les suivantes:
- Horloge de bureau
- Navigateur
- Agenda
- Contacts
- Galerie
- GlobalSearch
- Lanceur d'applications
- Musique
- Paramètres
Les implémentations d'appareils DOIVENT inclure les applications Android de base, le cas échéant, mais DOIVENT inclure un composant implémentant les mêmes modèles d'intent définis par tous les composants d'activité ou de service "publics" de ces applications Android de base. Notez que les composants Activity ou Service sont considérés comme "publics" lorsque l'attribut android:exported est absent ou a la valeur "true".
3.2.3.2. Forçages d'intents
Étant donné qu'Android est une plate-forme extensible, les implémentations d'appareils DOIVENT permettre à chaque modèle d'intent référencé dans la section 3.2.3.1 d'être remplacé par des applications tierces. L'implémentation Open Source Android en amont permet cela par défaut. Les implémentateurs d'appareils NE DOIVENT PAS associer des droits spéciaux à l'utilisation de ces modèles d'intent par les applications système, ni empêcher les applications tierces de se lier à ces modèles et de les contrôler. Cette interdiction inclut spécifiquement, mais sans s'y limiter, la désactivation de l'interface utilisateur "Chooser" qui permet à l'utilisateur de choisir parmi plusieurs applications qui gèrent toutes le même modèle d'intent.
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) si l'activité par défaut fournit un filtre plus spécifique pour l'URI de données. Par exemple, un filtre d'intent spécifiant l'URI de données "http://www.android.com" est plus spécifique que le filtre du navigateur pour "http://". Les implémentations d'appareils DOIVENT fournir une interface utilisateur permettant aux utilisateurs de modifier l'activité par défaut pour les intents.
3.2.3.3. Espaces de noms d'intent
Les implémentations d'appareils NE DOIVENT PAS inclure de composant Android qui respecte les nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans l'espace de noms android.* ou com.android.*. Les implémentateurs d'appareils NE DOIVENT PAS inclure de composants Android qui respectent les nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans un espace de package appartenant à une autre organisation. Les implémentateurs d'appareils NE DOIVENT PAS modifier ni étendre les modèles d'intent utilisés par les applications principales listées dans la section 3.2.3.1. Les implémentations d'appareils PEUVENT inclure des modèles d'intent utilisant des espaces de noms clairement et évidemment associés à leur propre organisation. Cette interdiction est semblable à celle spécifiée pour les classes de langage Java dans la section 3.6.
3.2.3.4. Intents de diffusion
Les applications tierces s'appuient sur la plate-forme pour diffuser certains intents afin de les informer des modifications apportées à l'environnement matériel ou logiciel. Les appareils compatibles avec Android DOIVENT diffuser les intents de diffusion publique en réponse aux événements système appropriés. Les intents de diffusion sont décrits dans la documentation du SDK.
3.2.3.5. Paramètres de l'application par défaut
Android inclut des paramètres qui permettent aux utilisateurs de sélectionner facilement leurs applications par défaut, par exemple pour l'écran d'accueil ou les SMS. Lorsque cela est approprié, les implémentations d'appareils DOIVENT fournir un menu de paramètres similaire et être compatibles avec le modèle de filtre d'intent et les méthodes d'API décrites dans la documentation du SDK, comme indiqué ci-dessous.
Implémentations de l'appareil:
- DOIT respecter l'intent android.settings.HOME_SETTINGS pour afficher un menu de paramètres d'application par défaut pour l'écran d'accueil, si l'implémentation de l'appareil signale android.software.home_screen [Ressources, 10]
- DOIT fournir un menu de paramètres qui appelle l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT pour afficher une boîte de dialogue permettant de modifier l'application de SMS par défaut, si l'implémentation de l'appareil signale android.hardware.telephony [Ressources, 9]
- 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 [Resources, 10]
3.3. Compatibilité avec les API natives
3.3.1 Interfaces binaires d'application
Le bytecode Dalvik géré peut appeler le code natif fourni dans le fichier .apk de l'application en tant que fichier .so ELF compilé pour l'architecture matérielle de l'appareil appropriée. Étant donné que le code natif est fortement dépendant de la technologie de processeur sous-jacente, Android définit un certain nombre d'interfaces binaires d'application (ABI) dans le NDK Android. Les implémentations d'appareils DOIVENT être compatibles avec une ou plusieurs ABI définies et DOIVENT implémenter la compatibilité avec le NDK Android, comme indiqué ci-dessous.
Si une implémentation d'appareil prend en charge une ABI Android, elle:
- DOIT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler le code natif, à l'aide de la sémantique standard de l'interface Java Native Interface (JNI)
- DOIT être compatible avec la source (c'est-à-dire avec l'en-tête) et avec le binaire (pour l'ABI) avec chaque bibliothèque requise de la liste ci-dessous
- DOIT prendre en charge l'ABI 32 bits équivalent si une ABI 64 bits est prise en charge
- DOIT indiquer avec précision l'interface binaire d'application (ABI) native prise en charge par l'appareil, via les paramètres android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS et android.os.Build.SUPPORTED_64_BIT_ABIS, chacun étant une liste d'ABI séparés par une virgule, de la plus à la moins préférée
- DOIT signaler, via les paramètres ci-dessus, uniquement les ABI documentées dans la dernière version du NDK Android, "Guide du programmeur NDK | Gestion des ABI" dans le répertoire docs/.
- DOIT être compilé à l'aide du code source et des fichiers d'en-tête disponibles dans le projet Open Source Android en amont
Les API de code natif suivantes DOIVENT être disponibles pour les applications qui incluent du code natif:
- libc (bibliothèque C)
- libm (bibliothèque mathématique)
- Compatibilité minimale avec C++
- Interface JNI
- liblog (journalisation Android)
- libz (compression zlib)
- libdl (lecteur de liens dynamique)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libEGL.so (gestion des surfaces OpenGL natives)
- libjnigraphics.so
- libOpenSLES.so (compatibilité audio OpenSL ES 1.0.1)
- libOpenMAXAL.so (compatibilité avec OpenMAX AL 1.0.1)
- libandroid.so (prise en charge des activités Android natives)
- libmediandk.so (compatibilité avec les API multimédias natives)
- Prise en charge d'OpenGL, comme décrit ci-dessous
Notez que les futures versions du NDK Android peuvent prendre en charge des ABI supplémentaires. Si une implémentation d'appareil n'est pas compatible avec une ABI prédéfinie existante, elle NE DOIT PAS signaler la prise en charge d'une quelconque ABI.
Notez que les implémentations d'appareils DOIVENT inclure libGLESv3.so et DOIVENT créer un lien symbolique (lien symbolique) vers libGLESv2.so. À son tour, DOIT exporter tous les symboles de fonction OpenGL ES 3.1 et Android Extension Pack [Resources, 11] tels que définis dans la version du NDK android-21. Bien que tous les symboles doivent être présents, seules les fonctions correspondantes pour les versions et les extensions OpenGL ES réellement compatibles avec l'appareil doivent être entièrement implémentées.
La compatibilité du code natif est difficile. C'est pourquoi les implémentateurs d'appareils sont très fortement encouragés à utiliser les implémentations des bibliothèques listées ci-dessus à partir du projet Open Source Android en amont.
3.4. Compatibilité Web
3.4.1. Compatibilité avec WebView
|
L'implémentation complète de l'API android.webkit.Webview PEUT être fournie sur les appareils Android Watch, mais DOIT l'être sur tous les autres types d'implémentations d'appareils. |
La fonctionnalité de plate-forme android.software.webview DOIT être signalée sur tout appareil qui fournit une implémentation complète de l'API android.webkit.WebView et NE DOIT PAS être signalée sur les appareils sans implémentation complète de l'API. L'implémentation Open Source d'Android utilise le code du projet Chromium pour implémenter android.webkit.WebView [Ressources, 12]. Étant donné qu'il n'est pas possible de développer une suite de tests complète pour un système de rendu Web, les implémentateurs d'appareils DOIVENT utiliser le build en amont spécifique de Chromium dans l'implémentation de WebView. Plus spécifiquement :
- Les implémentations android.webkit.WebView de l'appareil DOIVENT être basées sur le build Chromium du projet Android Open Source en amont pour Android 5.0. Cette version inclut un ensemble spécifique de correctifs de fonctionnalités et de sécurité pour WebView [Ressources, 13].
- 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)) 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 est compatible avec la fonctionnalité, DOIT se conformer à la spécification HTML5 [Ressources, 14].
3.4.2. Compatibilité avec les navigateurs
|
Les appareils Android TV et les montres PEUVENT omettre une application de navigateur, mais DOIVENT prendre en charge les modèles d'intent publics décrits 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 prendre en charge autant que possible les fonctionnalités HTML5 [Ressources, 14]. Au minimum, les implémentations d'appareils DOIVENT prendre en charge chacune de ces API associées à HTML5:
- cache de l'application/opération hors connexion [Ressources, 15]
- la balise
- géolocalisation [Ressources, 17]
De plus, les implémentations d'appareils DOIVENT être compatibles avec l'API Webstorage HTML5/W3C [Ressources, 18] et DEVRAIENT être compatibles avec l'API IndexedDB HTML5/W3C [Ressources, 19]. Notez que, à mesure que les organismes de normalisation du développement Web passent à IndexedDB plutôt qu'à Webstorage, IndexedDB devrait devenir un composant obligatoire dans une prochaine version d'Android.
3.5. Compatibilité du comportement des API
Les comportements de chacun des types d'API (gérés, souples, natifs et Web) doivent être cohérents avec l'implémentation privilégiée du projet Open Source Android en amont [Ressources, 2]. Voici quelques domaines de compatibilité spécifiques:
- Les appareils NE DOIVENT PAS modifier le comportement ni la sémantique d'un intent standard.
- Les appareils NE DOIVENT PAS modifier le cycle de vie ou la sémantique du cycle de vie d'un type particulier de composant système (tel que Service, Activity, ContentProvider, etc.).
- Les appareils NE DOIVENT PAS modifier la sémantique d'une autorisation standard.
La liste ci-dessus n'est pas exhaustive. La suite de tests de compatibilité (CTS) teste des parties importantes de la plate-forme pour vérifier sa compatibilité comportementale, mais pas toutes. Il incombe à l'implémentateur de s'assurer de la compatibilité comportementale avec le projet Android Open Source. C'est pourquoi les implémentateurs d'appareils DOIVENT utiliser le code source disponible via le projet Android Open Source dans la mesure du possible, plutôt que de réimplémenter des parties importantes du système.
3.6. Espaces de noms d'API
Android suit les conventions d'espace de noms de package et de classe définies par le langage de programmation Java. Pour assurer la compatibilité avec les applications tierces, les implémentateurs d'appareils NE DOIVENT PAS apporter de modifications interdites (voir ci-dessous) à ces espaces de noms de packages:
- java.*
- javax.*
- sun.*
- android.*
- com.android.*
Les modifications interdites incluent les suivantes :
- Les implémentations d'appareils NE DOIVENT PAS modifier les API exposées publiquement sur la plate-forme Android en modifiant les signatures de méthode ou de classe, ni en supprimant des classes ou des champs de classe.
- Les implémentateurs d'appareils PEUVENT modifier l'implémentation sous-jacente des API, mais de telles modifications NE DOIVENT PAS avoir d'incidence sur le comportement indiqué et la signature en langage Java de toute API exposée publiquement.
- Les implémentateurs d'appareils NE DOIVENT PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, ou des champs ou des méthodes à des classes ou interfaces existantes) aux API ci-dessus.
Un "élément exposé publiquement" est toute construction qui n'est pas décorée avec le repère "@hide" tel qu'il est utilisé dans le code source Android en amont. En d'autres termes, les implémentateurs d'appareils NE DOIVENT PAS exposer de nouvelles API ni modifier les API existantes dans les espaces de noms indiqués ci-dessus. Les implémentateurs d'appareils PEUVENT apporter des modifications internes uniquement, mais ces modifications NE DOIVENT PAS être annoncées ni exposées aux développeurs.
Les implémentateurs d'appareils PEUVENT ajouter des API personnalisées, mais ces API NE DOIVENT PAS se trouver dans un espace de noms appartenant à une autre organisation ou faisant référence à une autre organisation. Par exemple, les implémentateurs d'appareils NE DOIVENT PAS ajouter d'API à l'espace de noms com.google.* ou à un espace de noms similaire: seul Google peut le faire. De même, Google NE DOIT PAS ajouter d'API aux espaces de noms d'autres entreprises. De plus, si une implémentation d'appareil inclut des API personnalisées en dehors du namespace Android standard, ces API DOIVENT être empaquetées dans une bibliothèque partagée Android afin que seules les applications qui les utilisent explicitement (via le
Si un implémentateur d'appareil propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple, en ajoutant une nouvelle fonctionnalité utile à une API existante ou en ajoutant une nouvelle API), il DOIT consulter source.android.com et commencer le processus d'envoi de modifications et de code, conformément aux informations disponibles sur ce site.
Notez que les restrictions ci-dessus correspondent aux conventions standards de dénomination des API dans le langage de programmation Java. Cette section vise simplement à renforcer ces conventions et à les rendre contraignantes en les incluant dans cette définition de compatibilité.
3.7. Compatibilité avec l'environnement d'exécution
Les implémentations d'appareils DOIVENT être compatibles avec le format Dalvik Executable (DEX) complet, ainsi que la spécification et la sémantique du bytecode Dalvik [Resources, 20]. Les implémentateurs d'appareils DOIVENT utiliser ART, l'implémentation en amont de référence du format exécutable Dalvik et le système de gestion des paquets de l'implémentation de référence.
Les implémentations d'appareils DOIVENT configurer les environnements d'exécution Dalvik pour allouer de la mémoire conformément à la plate-forme Android en amont et comme indiqué dans le tableau suivant. (Consultez la section 7.1.1 pour connaître les définitions de la taille et de la densité de l'écran.)
Notez que les valeurs de mémoire spécifiées ci-dessous sont considérées comme des valeurs minimales, et que les implémentations d'appareils PEUVENT allouer plus de mémoire par application.
|
Disposition de l'écran |
Densité de l'écran |
Mémoire d'application minimale |
|
petite / normale |
120 PPP (ldpi) |
16 Mo |
|
160 ppp (mdpi) |
||
|
213 ppp (tvdpi) |
32 Mo |
|
|
240 ppp (hdpi) |
||
|
320 ppp (xhdpi) |
64 Mo |
|
|
400 ppp (400 dpi) |
96 Mo |
|
|
480 dpi (xxhdpi) |
128 Mo |
|
|
560 ppp (560dpi) |
192 Mo |
|
|
640 ppp (xxxhdpi) |
256 Mo |
|
|
grande |
120 PPP (ldpi) |
16 Mo |
|
160 ppp (mdpi) |
32 Mo |
|
|
213 ppp (tvdpi) |
64 Mo |
|
|
240 ppp (hdpi) |
||
|
320 ppp (xhdpi) |
128 Mo |
|
|
400 ppp (400 dpi) |
192 Mo |
|
|
480 dpi (xxhdpi) |
256 Mo |
|
|
560 ppp (560dpi) |
384 Mo |
|
|
640 ppp (xxxhdpi) |
512 Mo |
|
|
xlarge |
160 ppp (mdpi) |
64 Mo |
|
213 ppp (tvdpi) |
96 Mo |
|
|
240 ppp (hdpi) |
||
|
320 ppp (xhdpi) |
192 Mo |
|
|
400 ppp (400 dpi) |
288 Mo |
|
|
480 dpi (xxhdpi) |
384 Mo |
|
|
560 ppp (560dpi) |
576 Mo |
|
|
640 ppp (xxxhdpi) |
768 Mo |
3.8. Compatibilité de l'interface utilisateur
3.8.1. Lanceur (écran d'accueil)
Android inclut une application de lanceur (écran d'accueil) et prend en charge les applications tierces pour remplacer le lanceur de l'appareil (écran d'accueil). Les implémentations d'appareils qui permettent aux applications tierces de remplacer l'écran d'accueil de l'appareil DOIVENT déclarer la fonctionnalité de plate-forme android.software.home_screen.
3.8.2. Widgets
|
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 [Resources, 21], une fonctionnalité qui est fortement RECOMMANDÉE pour les implémentations d'appareils portables. Les implémentations d'appareils compatibles avec l'intégration de widgets sur l'écran d'accueil DOIVENT respecter les exigences suivantes et déclarer la prise en charge de la fonctionnalité de plate-forme android.software.app_widgets.
- Les lanceurs d'appareils DOIVENT inclure la prise en charge intégrée des AppWidgets et exposer les affordances de l'interface utilisateur pour ajouter, configurer, afficher et supprimer des AppWidgets directement dans le lanceur.
- Les implémentations d'appareils DOIVENT être capables d'afficher des widgets de 4 x 4 pixels dans la taille de grille standard. Pour en savoir plus, consultez les consignes de conception des widgets d'application dans la documentation du SDK Android [Ressources, 21].
- Les implémentations d'appareils qui prennent en charge l'écran de verrouillage PEUVENT prendre en charge les widgets d'application sur l'écran de verrouillage.
3.8.3. Notifications
Android inclut des API qui permettent aux développeurs d'avertir les utilisateurs d'événements notables [Ressources, 22], à l'aide des fonctionnalités matérielles et logicielles de l'appareil.
Certaines API permettent aux applications d'envoyer des notifications ou d'attirer l'attention à l'aide de matériel, en particulier du son, de la vibration et de la lumière. Les implémentations d'appareils DOIVENT prendre en charge les notifications qui utilisent des fonctionnalités matérielles, comme décrit dans la documentation du SDK et dans la mesure du possible avec le matériel d'implémentation de l'appareil. Par exemple, si une implémentation d'appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibration. Si une implémentation d'appareil ne dispose pas de matériel, les API correspondantes DOIVENT être implémentées en tant que no-ops. Ce comportement est décrit plus en détail dans la section 7.
En outre, l'implémentation DOIT afficher correctement toutes les ressources (icônes, fichiers audio, etc.) fournies dans les API [Ressources, 23] ou dans le guide de style des icônes de la barre d'état/système [Ressources, 24]. Les implémentateurs d'appareils PEUVENT proposer une expérience utilisateur alternative pour les notifications que celle fournie par l'implémentation Open Source Android de référence. Toutefois, ces systèmes de notification alternatifs DOIVENT prendre en charge les ressources de notification existantes, comme indiqué ci-dessus.
Android est compatible avec diverses notifications, par exemple:
- Notifications enrichies : vues interactives pour les notifications en cours.
- Notifications d'alerte : les utilisateurs peuvent interagir avec les vues interactives ou les ignorer sans quitter 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é.
Les implémentations d'appareils DOIVENT afficher et exécuter correctement ces notifications, y compris le titre/nom, l'icône et le texte, comme indiqué dans les API Android [Resources, 25].
Android inclut des API Notification Listener Service qui permettent aux applications (une fois activées explicitement par l'utilisateur) de recevoir une copie de toutes les notifications au fur et à mesure de leur publication ou de leur mise à jour. Les implémentations d'appareils DOIVENT envoyer correctement et rapidement l'intégralité des notifications à tous ces services d'écouteur installés et activés par l'utilisateur, y compris toutes les métadonnées associées à l'objet Notification.
3.8.4. Recherche
Android inclut des API [Ressources, 26] qui permettent aux développeurs d'intégrer la recherche dans leurs applications et d'exposer les données de leur application dans la recherche système globale. De manière générale, cette fonctionnalité consiste en une interface utilisateur unique, au niveau du système, qui permet aux utilisateurs de saisir des requêtes, d'afficher des suggestions à mesure qu'ils saisissent du texte et d'afficher des résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour fournir une recherche dans leurs propres applications et de fournir des résultats à l'interface utilisateur de recherche globale commune.
Les implémentations d'appareils Android DOIVENT inclure une recherche globale, une interface utilisateur de recherche unique, partagée et à l'échelle du système, capable de proposer des suggestions en temps réel en réponse à l'entrée utilisateur. Les implémentations d'appareils DOIVENT implémenter les API qui permettent aux développeurs de réutiliser cette interface utilisateur pour fournir une recherche dans leurs propres applications. Les implémentations d'appareils qui implémentent l'interface de recherche globale DOIVENT implémenter les API qui permettent aux applications tierces d'ajouter des suggestions au champ de recherche lorsqu'il est exécuté en mode recherche globale. Si aucune application tierce n'est installée pour utiliser cette fonctionnalité, le comportement par défaut DOIT être d'afficher les résultats et les suggestions du moteur de recherche Web.
3.8.5. Notifications toast
Les applications peuvent utiliser l'API "Toast" pour afficher des chaînes courtes non modales à l'utilisateur final, qui disparaissent après un court laps de temps [Resources, 27]. Les implémentations d'appareils DOIVENT afficher les toasts des applications aux utilisateurs finaux de manière très visible.
3.8.6. Thèmes
Android fournit des "thèmes" comme mécanisme permettant aux applications d'appliquer des styles à l'ensemble d'une activité ou d'une application.
Android inclut une famille de thèmes "Holo" sous la forme d'un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent reproduire l'apparence du thème Holo tel que défini par le SDK Android [Resources, 28]. Les implémentations d'appareils NE DOIVENT PAS modifier les attributs du thème Holo exposés aux applications [Resources, 29].
Android 5.0 inclut une famille de thèmes "Material" sous la forme d'un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent adapter l'apparence du thème de conception à la grande variété de types d'appareils Android. Les implémentations d'appareils DOIVENT prendre en charge la famille de thèmes "Material" et NE DOIVENT PAS modifier les attributs du thème Material ni les éléments exposés aux applications [Ressources, 30].
Android inclut également une famille de thèmes "Par défaut de l'appareil" en tant qu'ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent reproduire l'apparence du thème de l'appareil tel que défini par l'implémentateur de l'appareil. Les implémentations de l'appareil PEUVENT modifier les attributs de thème par défaut de l'appareil exposés aux applications [Ressources, 29].
Android est compatible avec un nouveau thème de variante avec des barres système transparentes, ce qui permet aux développeurs d'applications de remplir la zone derrière la barre d'état et de navigation avec le contenu de leur application. Pour offrir une expérience de développement cohérente dans cette configuration, il est important que le style des icônes de la barre d'état soit conservé dans les différentes implémentations d'appareils. Par conséquent, les implémentations d'appareils Android DOIVENT utiliser le blanc pour les icônes d'état du système (telles que l'intensité du signal et le niveau de la batterie) et les notifications émises par le système, sauf si l'icône indique un état problématique [Resources, 29].
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 [Ressources, 31]. Les fonds d'écran animés sont des animations, des motifs ou des images similaires avec des fonctionnalités de saisie limitées qui s'affichent en tant que fond d'écran, derrière d'autres applications.
Le matériel est considéré comme capable d'exécuter de manière fiable des fonds d'écran animés s'il peut exécuter tous les fonds d'écran animés, sans aucune limitation de fonctionnalité, à une fréquence d'images raisonnable et sans effet négatif sur d'autres applications. Si des limites matérielles provoquent le plantage et/ou le dysfonctionnement des fonds d'écran et/ou des applications, ou qu'elles consomment une puissance de processeur ou de batterie excessive, ou qu'elles s'exécutent à des fréquences d'images inacceptablement faibles, le matériel est considéré comme incapable d'exécuter un fond d'écran animé. Par exemple, certains fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne s'exécute pas de manière fiable sur du matériel qui n'est pas compatible avec plusieurs contextes OpenGL, car l'utilisation d'un contexte OpenGL par le fond d'écran animé peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.
Les implémentations d'appareils capables d'exécuter des fonds d'écran animés de manière fiable, comme décrit ci-dessus, DOIVENT implémenter des fonds d'écran animés et, lorsqu'elles sont implémentées, DOIVENT signaler l'indicateur de fonctionnalité de la plate-forme android.software.live_wallpaper.
3.8.8. Changement d'activité
|
Étant donné que la touche de navigation de la fonction "Récents" est FACULTATIVE, les exigences d'implémentation de l'écran d'aperçu sont FACULTATIVES pour les appareils Android TV et les appareils Android Watch. |
Le code source Android en amont inclut l'écran d'aperçu [Resources, 32], une interface utilisateur au niveau du système pour le changement de tâche et l'affichage des activités et tâches récemment consultées à l'aide d'une image miniature de l'état graphique de l'application au moment où l'utilisateur a quitté l'application pour la dernière fois. Les implémentations d'appareils incluant la touche de navigation de la fonction "Récents", comme indiqué dans la section 7.2.3, PEUVENT modifier l'interface, mais DOIVENT respecter les exigences suivantes:
- DOIT afficher les éléments récents associés en tant que groupe qui se déplace ensemble
- DOIT prendre en charge au moins 20 activités affichées
- DOIT afficher au moins le titre de quatre activités à la fois
- DOIT afficher la couleur de surlignage, l'icône et le titre de l'écran dans les éléments récents
- DOIT implémenter le comportement d'épinglage d'écran [Ressources, 33] et fournir à l'utilisateur un menu de paramètres pour activer/désactiver la fonctionnalité
- DOIT afficher une affordance de fermeture ("x"), mais PEUT retarder cette action jusqu'à ce que l'utilisateur interagisse avec les écrans
Nous vous recommandons vivement d'utiliser l'interface utilisateur Android en amont (ou une interface basée sur des miniatures similaire) pour l'écran "Vue d'ensemble".
3.8.9. Gestion des entrées
Android est compatible avec la gestion des entrées et les éditeurs de méthodes d'entrée tiers [Resources, 34]. Les implémentations d'appareils qui permettent aux utilisateurs d'utiliser des méthodes de saisie tierces sur l'appareil DOIVENT déclarer la fonctionnalité de plate-forme android.software.input_methods et prendre en charge les API IME, comme défini dans la documentation du SDK Android.
Les implémentations d'appareils qui déclarent la fonctionnalité android.software.input_methods DOIVENT fournir un mécanisme accessible à l'utilisateur pour ajouter et configurer des méthodes de saisie tierces. Les implémentations d'appareils DOIVENT afficher l'interface des paramètres en réponse à l'intent android.settings.INPUT_METHOD_SETTINGS.
3.8.10. Contrôle des contenus multimédias sur l'écran de verrouillage
L'API Client de télécommande est obsolète à partir d'Android 5.0 au profit du modèle de notification multimédia, qui permet aux applications multimédias de s'intégrer aux commandes de lecture affichées sur l'écran de verrouillage [Ressources, 35]. Les implémentations d'appareils compatibles avec un écran de verrouillage doivent prendre en charge le modèle de notification multimédia ainsi que d'autres notifications.
3.8.11. Rêves
Android est compatible avec les écrans de veille interactifs appelés "Dreams" [Resources, 36]. Dreams permet aux utilisateurs d'interagir avec des applications lorsqu'un appareil connecté à une source d'alimentation est inactif ou posé sur un socle. Les appareils Android Watch PEUVENT implémenter Dreams, mais les autres types d'implémentations d'appareils DOIVENT prendre en charge Dreams et fournir une option de paramètres permettant aux utilisateurs de configurer Dreams en réponse à l'intent android.settings.DREAM_SETTINGS.
3.8.12. Position
Lorsqu'un appareil dispose d'un capteur matériel (par exemple, un GPS) capable de fournir les coordonnées de localisation, les modes de localisation DOIVENT s'afficher dans le menu "Localisation" de "Paramètres" [Ressources, 37].
3.8.13. Unicode et police
Android est compatible avec les caractères emoji en couleur. Lorsque les implémentations d'appareils Android incluent un IME, les appareils DOIVENT fournir à l'utilisateur une méthode de saisie pour les caractères emoji définis dans Unicode 6.1 [Ressources, 38]. Tous les appareils DOIVENT être capables d'afficher ces caractères emoji sous forme de glyphes en couleur.
Android 5.0 est compatible avec la police Roboto 2 avec différentes épaisseurs (sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light), qui DOIVENT toutes être incluses pour les langues disponibles sur l'appareil et la couverture complète de l'Unicode 7.0 pour le latin, le grec et le cyrillique, y compris les plages Latin Extended A, B, C et D, ainsi que tous les glyphes du bloc des symboles de devise de l'Unicode 7.0.
3.9. Gestion de l'appareil
Android inclut des fonctionnalités qui permettent aux applications axées sur la sécurité d'effectuer des fonctions d'administration des appareils au niveau du système, telles que l'application de stratégies de mot de passe ou l'effacement à distance, via l'API Android Device Administration [Ressources, 39]. Les implémentations d'appareils DOIVENT fournir une implémentation de la classe DevicePolicyManager [Resources, 40]. Les implémentations d'appareils qui incluent la prise en charge de l'écran de verrouillage DOIVENT prendre en charge l'ensemble des règles d'administration des appareils définies dans la documentation du SDK Android [Ressources, 39] et signaler la fonctionnalité de plate-forme android.software.device_admin.
Les implémentations d'appareils PEUVENT comporter une application préinstallée qui effectue des fonctions d'administration de l'appareil, mais cette application NE DOIT PAS être définie par défaut comme application propriétaire de l'appareil [Ressources, 41].
3.10. Accessibilité
Android fournit une couche d'accessibilité qui aide les utilisateurs ayant un handicap à naviguer plus facilement sur leurs appareils. De plus, Android fournit des API de plate-forme qui permettent aux implémentations de services d'accessibilité de recevoir des rappels pour les événements utilisateur et système, et de générer d'autres mécanismes de rétroaction, tels que la synthèse vocale, le retour haptique et la navigation avec le pavé tactile/le pavé directionnel [Ressources, 42]. Les implémentations d'appareils DOIVENT fournir une implémentation du framework d'accessibilité Android conforme à l'implémentation Android par défaut. Les implémentations d'appareils DOIVENT répondre aux exigences suivantes:
- DOIT prendre en charge les implémentations de services d'accessibilité tiers via les API android.accessibilityservice [Ressources, 43]
- DOIT générer des AccessibilityEvents et les transmettre à toutes les implémentations AccessibilityService enregistrées de manière cohérente avec l'implémentation Android par défaut
- Sauf s'il s'agit d'une montre Android sans sortie audio, les implémentations d'appareils DOIVENT fournir un mécanisme accessible à l'utilisateur pour activer et désactiver les services d'accessibilité, et DOIVENT afficher cette interface en réponse à l'intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.
En outre, les implémentations d'appareil DOIVENT fournir une implémentation d'un service d'accessibilité sur l'appareil et DOIVENT fournir un mécanisme permettant aux utilisateurs d'activer le service d'accessibilité lors de la configuration de l'appareil. Une implémentation Open Source d'un service d'accessibilité est disponible dans le projet Eyes Free [Ressources, 44].
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 [Resources, 45]. Les implémentations d'appareils signalant la fonctionnalité android.hardware.audio.output DOIVENT respecter ces exigences liées au framework TTS Android.
Implémentations de l'appareil:
- DOIT être compatible avec les API du framework TTS Android et DOIT inclure un moteur TTS compatible avec les langues disponibles sur l'appareil. Notez que le logiciel Open Source Android en amont inclut une implémentation de moteur TTS complète.
- DOIT prendre en charge l'installation de moteurs TTS tiers
- DOIT fournir une interface accessible aux utilisateurs qui leur permet de sélectionner un moteur TTS à utiliser au niveau du système
3.12. TV Input Framework
Le framework d'entrée Android TV (TIF) simplifie la diffusion de contenu en direct sur les appareils Android TV. TIF fournit une API standard pour créer des modules d'entrée qui contrôlent les appareils Android TV. Les implémentations d'appareils Android TV DOIVENT prendre en charge le framework d'entrée pour la télévision [Ressources, 46].
Les implémentations d'appareils compatibles avec le TIF DOIVENT déclarer la fonctionnalité de plate-forme android.software.live_tv.
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 [Resources, 47].
Les implémentations d'appareils NE DOIVENT PAS étendre les formats .apk [Ressources, 48], Android Manifest [Ressources, 49], bytecode Dalvik [Ressources, 20] 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
Les implémentations d'appareils DOIVENT prendre en charge les principaux formats multimédias spécifiés dans la documentation du SDK Android [Ressources, 50], sauf dans les cas explicitement autorisés dans ce document. Plus précisément, les implémentations d'appareils DOIVENT prendre en charge les formats multimédias, les encodeurs, les décodeurs, les types de fichiers et les formats de conteneur définis dans les tableaux ci-dessous. Tous ces codecs sont fournis en tant qu'implémentations logicielles dans l'implémentation Android préférée du Projet Android Open Source.
Veuillez noter que ni Google ni l'Open Handset Alliance ne font aucune déclaration selon laquelle ces codecs sont exempts de brevets tiers. Les personnes qui souhaitent utiliser ce code source dans des produits matériels ou logiciels sont informées que les implémentations de ce code, y compris dans des logiciels Open Source ou des sharewares, peuvent nécessiter des licences de brevets de la part des titulaires de brevets concernés.
5.1.1. Codecs audio
|
Format / Codec |
Encodeur |
Décodeur |
Détails |
Types de fichiers/Formats de conteneurs compatibles |
|
Profil MPEG-4 AAC (AAC LC) |
OBLIGATOIRE1 |
REQUIRED |
Compatibilité avec les contenus mono/stéréo/5.0/5.12 avec des taux d'échantillonnage standards de 8 à 48 kHz. |
• 3GPP (.3gp) • MPEG-4 (.mp4, .m4a) • AAC brut ADTS (.aac, décodage sous Android 3.1 ou version ultérieure, encodage sous Android 4.0 ou version ultérieure, ADIF non pris en charge) • MPEG-TS (.ts, non accessible, Android 3.0 ou version ultérieure) |
|
Profil MPEG-4 HE AAC (AAC+) |
OBLIGATOIRE1 (Android 4.1 ou version ultérieure) |
REQUIRED |
Compatibilité avec les contenus mono/stéréo/5.0/5.12 avec des taux d'échantillonnage standards de 16 à 48 kHz. |
|
|
MPEG-4 HE AACv2 Profil (AAC+ amélioré) |
|
REQUIRED |
Compatibilité avec les contenus mono/stéréo/5.0/5.12 avec des taux d'échantillonnage standards de 16 à 48 kHz. |
|
|
AAC ELD (AAC à faible latence amélioré) |
OBLIGATOIRE1 (Android 4.1 ou version ultérieure) |
REQUIRED (Android 4.1 ou version ultérieure) |
Compatibilité avec le contenu mono/stéréo avec des taux d'échantillonnage standards de 16 à 48 kHz. |
|
|
AMR-NB |
OBLIGATOIRE3 |
OBLIGATOIRE3 |
4,75 à 12,2 kbit/s échantillonnés à 8 kHz |
3GPP (.3gp) |
|
AMR-WB |
OBLIGATOIRE3 |
OBLIGATOIRE3 |
9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz |
|
|
FLAC |
|
REQUIRED (Android 3.1 et versions ultérieures) |
Mono/Stéréo (pas de multicanaux) Taux d'échantillonnage jusqu'à 48 kHz (mais jusqu'à 44,1 kHz recommandé sur les appareils avec sortie 44,1 kHz, car le convertisseur 48 kHz vers 44,1 kHz n'inclut pas de filtre passe-bas). 16 bits recommandés ; aucun tramage 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 |
REQUIRED4 (Android 4.1 ou version ultérieure) |
REQUIRED |
PCM linéaire 16 bits (débits jusqu'à la limite du matériel). Les appareils DOIVENT prendre en charge les taux d'échantillonnage pour l'enregistrement PCM brut aux fréquences de 8 000, 11 025, 16 000 et 44 100 Hz. |
WAVE (.wav) |
|
Opus |
REQUIRED (Android 5.0 ou version ultérieure) |
Matroska (.mkv) |
1 Obligatoire pour les implémentations d'appareils qui définissent android.hardware.microphone, mais facultatif pour les implémentations d'appareils Android Watch.
2 Seul le downmix du contenu 5.0/5.1 est obligatoire. L'enregistrement ou le rendu de plus de deux canaux est facultatif.
3 Obligatoire pour les implémentations d'appareils Android portables.
4 Obligatoire pour les implémentations d'appareils qui définissent android.hardware.microphone, y compris les implémentations d'appareils Android Watch.
5.1.2. Codecs d'image
|
Format / Codec |
Encodeur |
Décodeur |
Détails |
Types de fichiers/Formats de conteneurs compatibles |
|
JPEG |
REQUIRED |
REQUIRED |
Base+progressive |
JPEG (.jpg) |
|
GIF |
|
REQUIRED |
|
GIF (.gif) |
|
PNG |
REQUIRED |
REQUIRED |
|
PNG (.png) |
|
BMP |
|
REQUIRED |
|
BMP (.bmp) |
|
WebP |
REQUIRED |
REQUIRED |
|
WebP (.webp) |
5.1.3. Codecs vidéo
|
Les codecs vidéo sont facultatifs pour les implémentations d'appareils Android Watch. |
|
Format / Codec |
Encodeur |
Décodeur |
Détails |
Types de fichiers/Formats de conteneurs compatibles |
|
H.263 |
OBLIGATOIRE1 |
REQUIRED2 |
|
• 3GPP (.3gp) • MPEG-4 (.mp4) |
|
H.264 AVC |
REQUIRED2 |
REQUIRED2 |
• 3GPP (.3gp) • MPEG-4 (.mp4) • MPEG-TS (.ts, audio AAC uniquement, non accessible par recherche, Android 3.0 et versions ultérieures) |
|
|
H.265 HEVC |
REQUIRED2 |
Pour en savoir plus, consultez la section 5.3. |
MPEG-4 (.mp4) |
|
|
MPEG-4 SP |
|
REQUIRED2 |
|
3GPP (.3gp) |
|
VP83 |
REQUIRED2 (Android 4.3 ou version ultérieure) |
REQUIRED2 (Android 2.3.3 et versions ultérieures) |
• WebM (.webm) [Ressources, 110] • Matroska (.mkv, Android 4.0 et versions ultérieures)4 |
|
|
VP9 |
REQUIRED2 (Android 4.4 ou version ultérieure) |
Pour en savoir plus, consultez la section 5.3. |
• WebM (.webm) [Ressources, 110] • Matroska (.mkv, Android 4.0 et versions ultérieures)4 |
1 Obligatoire pour les implémentations d'appareils qui incluent du matériel d'appareil photo et définissent android.hardware.camera ou android.hardware.camera.front.
2 Obligatoire pour les implémentations d'appareils, à l'exception des appareils Android Watch.
3 Pour une qualité acceptable des services de streaming vidéo Web et de visioconférence, les implémentations d'appareils DOIVENT utiliser un codec VP8 matériel conforme aux exigences de [Ressources, 51].
4 Les implémentations d'appareils DOIVENT prendre en charge l'écriture de fichiers Matroska WebM.
5.2. Encodage vidéo
|
Les codecs vidéo sont facultatifs pour les implémentations d'appareils Android Watch. |
Les implémentations d'appareils Android compatibles avec le codec H.264 DOIVENT prendre en charge le niveau 3 du profil de référence et les profils d'encodage vidéo SD (Standard Definition) suivants. Elles DOIVENT également prendre en charge le niveau 4 du profil principal et les profils d'encodage vidéo HD (High Definition) suivants. Il est vivement recommandé d'encoder des vidéos HD 1080p à 30 FPS sur les appareils Android TV.
|
SD (basse qualité) |
SD (haute qualité) |
HD 720p1 |
HD 1080p1 |
|
|
Résolution vidéo |
320 x 240 px |
720 x 480 px |
1 280 x 720 px |
1 920 x 1 080 px |
|
Fréquence d'images vidéo |
20 fps |
30 ips |
30 ips |
30 ips |
|
Bitrate vidéo |
384 kbit/s |
2 Mbit/s |
4 Mbit/s |
10 Mbit/s |
1 Si le matériel est compatible, mais FORTEMENT RECOMMANDÉ pour les appareils Android TV.
Les implémentations d'appareils Android compatibles avec le codec VP8 DOIVENT prendre en charge les profils d'encodage vidéo SD et DOIVENT prendre en charge les profils d'encodage vidéo HD (haute définition) suivants.
|
SD (basse qualité) |
SD (haute qualité) |
HD 720p1 |
HD 1080p1 |
|
|
Résolution vidéo |
320 x 180 px |
640 x 360 px |
1 280 x 720 px |
1 920 x 1 080 px |
|
Fréquence d'images vidéo |
30 ips |
30 ips |
30 ips |
30 ips |
|
Bitrate 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. |
Les implémentations d'appareils DOIVENT prendre en charge le changement dynamique de la résolution vidéo dans le même flux pour les codecs VP8, VP9, H.264 et H.265.
Les implémentations d'appareils Android avec des décodeurs H.264 DOIVENT prendre en charge le niveau 3 du profil de référence et les profils de décodage vidéo SD suivants, et DOIVENT prendre en charge les profils de décodage HD. Les appareils Android TV DOIVENT être compatibles avec le profil High Profile de niveau 4.2 et le profil de décodage HD 1080p.
|
SD (basse qualité) |
SD (haute qualité) |
HD 720p1 |
HD 1080p1 |
|
|
Résolution vidéo |
320 x 240 px |
720 x 480 px |
1 280 x 720 px |
1 920 x 1 080 px |
|
Fréquence d'images vidéo |
30 ips |
30 ips |
30 FPS / 60 FPS2 |
30 FPS / 60 FPS2 |
|
Bitrate vidéo |
800 Kbit/s |
2 Mbit/s |
8 Mbit/s |
20 Mbit/s |
1 Obligatoire pour les implémentations d'appareils Android TV, mais uniquement pour les autres types d'appareils si le matériel est compatible.
2 Obligatoire pour les implémentations d'appareils Android Television.
Les implémentations d'appareils Android compatibles avec le codec VP8, comme décrit dans la section 5.1.3, DOIVENT prendre en charge les profils de décodage SD suivants et DOIVENT prendre en charge les profils de décodage HD. Les appareils Android TV DOIVENT être compatibles avec le profil de décodage HD 1080p.
|
SD (basse qualité) |
SD (haute qualité) |
HD 720p1 |
HD 1080p1 |
|
|
Résolution vidéo |
320 x 180 px |
640 x 360 px |
1 280 x 720 px |
1 920 x 1 080 px |
|
Fréquence d'images vidéo |
30 ips |
30 ips |
30 FPS / 60 FPS2 |
30 / 60 FPS2 |
|
Bitrate vidéo |
800 Kbit/s |
2 Mbit/s |
8 Mbit/s |
20 Mbit/s |
1 Obligatoire pour les implémentations d'appareils Android TV, mais uniquement pour les autres types d'appareils si le matériel est compatible.
2 Obligatoire pour les implémentations d'appareils Android Television.
Les implémentations d'appareils Android, lorsqu'elles prennent en charge le codec VP9 comme décrit dans la section 5.1.3, DOIVENT prendre en charge les profils de décodage vidéo SD suivants et DOIVENT prendre en charge les profils de décodage HD. Il est vivement recommandé que les appareils Android TV soient compatibles avec le profil de décodage HD 1080p et DOIVENT être compatibles avec le profil de décodage UHD. Lorsque le profil de décodage vidéo UHD est pris en charge, il DOIT prendre en charge la profondeur de couleur de 8 bits.
|
SD (basse qualité) |
SD (haute qualité) |
HD 720p 1 |
HD 1080p 2 |
UHD 2 |
|
|
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 vidéo |
30 ips |
30 ips |
30 ips |
30 ips |
30 ips |
|
Bitrate vidéo |
600 Kbits/s |
1,6 Mbit/s |
4 Mbit/s |
10 Mbit/s |
20 Mbit/s |
1 Obligatoire pour les implémentations d'appareils Android TV, mais uniquement pour les autres types d'appareils si le matériel est compatible.
2 FORTEMENT RECOMMANDÉ pour les implémentations d'appareils Android TV lorsque le matériel est compatible.
Les implémentations d'appareils Android, lorsqu'elles sont compatibles avec le codec H.265 comme décrit dans la section 5.1.3, DOIVENT prendre en charge le niveau principal du profil principal de niveau 3 et les profils de décodage vidéo SD suivants, et DOIVENT prendre en charge les profils de décodage HD. Les appareils Android TV DOIVENT être compatibles avec le niveau 4.1 du profil principal et le profil de décodage HD 1080p, et DEVRAIENT être compatibles avec le niveau 5 du profil principal Main10 et le profil de décodage UHD.
|
SD (basse qualité) |
SD (haute qualité) |
HD 720p 1 |
HD 1080p 1 |
UHD 2 |
|
|
Résolution vidéo |
352 x 288 px |
640 x 360 px |
1 280 x 720 px |
1 920 x 1 080 px |
3 840 x 2 160 px |
|
Fréquence d'images vidéo |
30 ips |
30 ips |
30 ips |
30 ips |
30 ips |
|
Bitrate vidéo |
600 Kbits/s |
1,6 Mbit/s |
4 Mbit/s |
10 Mbit/s |
20 Mbit/s |
1 Obligatoire pour l'implémentation d'appareils Android TV, mais uniquement pour les autres types d'appareils si le matériel est compatible.
2 Obligatoire pour les implémentations d'appareils Android TV lorsque le matériel est compatible.
5.4. Enregistrement audio
Bien que certaines des exigences décrites dans cette section soient indiquées comme "DEVOIR" depuis Android 4.3, la définition de la compatibilité pour une future version prévoit de les remplacer par "DEVOIR". Les appareils Android existants et nouveaux sont très fortement encouragés à respecter ces exigences, sans quoi ils ne pourront pas être compatibles avec Android lors de la mise à niveau vers la future version.
5.4.1. Capture audio RAW
Les implémentations d'appareils qui déclarent android.hardware.microphone DOIVENT permettre la capture de contenu audio brut avec les caractéristiques suivantes:
- Format: PCM linéaire, 16 bits
- Taux d'échantillonnage: 8 000, 11 025, 16 000 et 44 100
- Canaux: mono
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
5.4.2. Enregistrer pour la reconnaissance vocale
En plus des spécifications d'enregistrement ci-dessus, lorsqu'une application a commencé à enregistrer un flux audio à l'aide de la source audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:
- L'appareil DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence à peu près plates: plus précisément, ±3 dB, de 100 Hz à 4 000 Hz.
- La sensibilité d'entrée audio DOIT être définie de sorte qu'une source de niveau de puissance acoustique (SPL) de 90 dB à 1 000 Hz génère une valeur efficace de 2 500 pour les échantillons 16 bits.
- Les niveaux d'amplitude PCM DOIVENT suivre de manière linéaire les variations de SPL d'entrée sur une plage d'au moins 30 dB, allant de -18 dB à +12 dB par rapport à 90 dB SPL au niveau du micro.
- La distorsion harmonique totale DOIT être inférieure à 1% pour 1 kHz à un niveau d'entrée de 90 dB SPL au niveau du micro.
- Le traitement de réduction du bruit, le cas échéant, DOIT être désactivé.
- Le contrôle de gain automatique, le cas échéant, DOIT être désactivé
Si la plate-forme est compatible avec les technologies de suppression du bruit optimisées pour la reconnaissance vocale, l'effet DOIT être contrôlable à partir de l'API android.media.audiofx.NoiseSuppressor. De plus, le champ UUID du descripteur d'effet du suppresseur de bruit DOIT identifier de manière unique chaque implémentation de la technologie de suppression du bruit.
5.4.3. Capture pour le redirignement de la lecture
La classe android.media.MediaRecorder.AudioSource inclut la source audio REMOTE_SUBMIX. Les appareils qui déclarent android.hardware.audio.output DOIVENT implémenter correctement la source audio REMOTE_SUBMIX afin que, lorsqu'une application utilise l'API android.media.AudioRecord pour enregistrer à partir de cette source audio, elle puisse capturer un mix de tous les flux audio, à l'exception des suivants:
- STREAM_RING
- STREAM_ALARM
- STREAM_NOTIFICATION
5.5. Lecture audio
Les implémentations d'appareils qui déclarent android.hardware.audio.output DOIVENT respecter les exigences de cette section.
5.5.1. Lecture audio brute
L'appareil DOIT permettre la lecture de contenu audio brut avec les caractéristiques suivantes:
- Format: PCM linéaire, 16 bits
- Taux d'échantillonnage: 8 000, 11 025, 16 000, 22 050, 32 000 et 44 100
- Canaux: mono, stéréo
L'appareil DOIT permettre la lecture de contenu audio brut avec les caractéristiques suivantes:
- Taux d'échantillonnage: 24 000, 48 000
5.5.2. Effets audio
Android fournit une API pour les effets audio pour les implémentations d'appareils [Resources, 52]. 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 prendre en charge l'implémentation de l'API Visualizer, contrôlable via la classe Visualizer
- DOIT être compatible avec les implémentations EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB et EFFECT_TYPE_VIRTUALIZER, qui peuvent être contrôlées via les sous-classes AudioEffect BassBoost, EnvironmentalReverb, PresetReverb et Virtualizer.
5.5.3. Volume de sortie audio
Les implémentations d'appareils Android TV DOIVENT prendre en charge le volume principal du système et l'atténuation du volume de sortie audio numérique sur les sorties compatibles, à l'exception de la sortie de passthrough audio compressé (où aucun décodage audio n'est effectué sur l'appareil).
5.6. Latence audio
La latence audio correspond au délai de transmission d'un signal audio dans un système. De nombreuses classes d'applications s'appuient sur des latences courtes pour obtenir des effets sonores en temps réel.
Aux fins de cette section, utilisez les définitions suivantes:
- Latence de sortie : intervalle entre le moment où une application écrit un frame de données encodées en PCM et le moment où le son correspondant peut être entendu par un écouteur externe ou observé par un transducteur.
- Latence de sortie à froid : 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 : latence de sortie pour les images suivantes, une fois que l'appareil lit de l'audio.
- Latence d'entrée : intervalle entre le moment où un son externe est présenté à l'appareil et celui où une application lit le frame correspondant de données codées PCM.
- Latence d'entrée à froid : somme du temps d'entrée perdu et de la latence d'entrée pour le premier frame, lorsque le système d'entrée audio était inactif et éteint avant la requête.
- Latence d'entrée continue : latence d'entrée pour les images suivantes lorsque l'appareil capture du son.
- Jitter de sortie à froid : variance entre les mesures distinctes des valeurs de latence de sortie à froid.
- Jitter d'entrée à froid : variance entre les mesures distinctes des valeurs de latence d'entrée à froid.
- Latence aller-retour continue : somme de la latence d'entrée continue, de la latence de sortie continue et de 5 millisecondes.
- API OpenSL ES de file d'attente de tampon PCM : ensemble d'API OpenSL ES liées au PCM dans le NDK Android. Consultez NDK_root/docs/opensles/index.html.
Les implémentations d'appareils qui déclarent android.hardware.audio.output DOIVENT répondre à ces exigences de sortie audio ou les dépasser:
- Latence de sortie à froid de 100 millisecondes ou moins
- une latence de sortie continue de 45 millisecondes ou moins
- réduire le jitter de sortie à froid ;
Si une implémentation d'appareil répond aux exigences de cette section après tout calibrage initial lors de l'utilisation de l'API de file d'attente de tampon PCM OpenSL ES, pour la latence de sortie continue et la latence de sortie à froid sur au moins un appareil de sortie audio compatible, elle PEUT signaler la prise en charge de l'audio à faible latence, en signalant la fonctionnalité android.hardware.audio.low_latency via la classe android.content.pm.PackageManager [Resources, 53]. À 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.
Les implémentations d'appareils qui incluent android.hardware.microphone DOIVENT respecter ces exigences audio d'entrée:
- une latence d'entrée à froid de 100 millisecondes ou moins
- une latence d'entrée continue de 30 millisecondes ou moins ;
- une latence aller-retour continue de 50 millisecondes ou moins
- réduire le jitter d'entrée à froid ;
5.7. Protocoles de réseau
Les appareils DOIVENT prendre en charge les protocoles de réseau multimédia pour la lecture audio et vidéo, comme indiqué dans la documentation du SDK Android [Ressources, 50]. Plus précisément, les appareils DOIVENT être compatibles avec les protocoles réseau multimédias suivants:
- RTSP (RTP, SDP)
- Streaming progressif HTTP(S)
- Draft protocol for HTTP(S) Live Streaming, version 3 [Resources, 54]
5.8. Secure Media
Les implémentations d'appareils compatibles avec la sortie vidéo sécurisée et capables de prendre en charge les surfaces sécurisées DOIVENT déclarer la prise en charge de Display.FLAG_SECURE. Les implémentations d'appareils qui déclarent la prise en charge de Display.FLAG_SECURE, si elles sont compatibles avec un protocole d'affichage sans fil, DOIVENT sécuriser la liaison avec un mécanisme cryptographique puissant tel que HDCP 2.x ou version ultérieure pour les écrans sans fil Miracast. De même, si elles sont compatibles avec un écran externe filaire, les implémentations de l'appareil DOIVENT être compatibles avec HDCP 1.2 ou version ultérieure. Les implémentations d'appareils Android TV DOIVENT être compatibles avec HDCP 2.2 pour les appareils compatibles avec la résolution 4K et HDCP 1.4 ou version ultérieure pour les résolutions inférieures. L'implémentation Open Source d'Android en amont prend en charge les écrans sans fil (Miracast) et filaires (HDMI) qui répondent à cette exigence.
6. Compatibilité des outils et options pour les développeurs
6.1. Outils pour les développeurs
Les implémentations d'appareils DOIVENT prendre en charge les outils de développement Android fournis dans le SDK Android. Les appareils Android compatibles DOIVENT être compatibles avec:
- Android Debug Bridge (adb) [Resources, 55]
Les implémentations d'appareils DOIVENT prendre en charge toutes les fonctions adb, comme indiqué dans le SDK Android, y compris dumpsys [Resources, 56]. Le daemon adb côté appareil DOIT être inactif par défaut, et un mécanisme accessible à l'utilisateur DOIT être disponible pour activer Android Debug Bridge. Si une implémentation d'appareil omet le mode périphérique USB, elle DOIT implémenter le pont de débogage Android via un réseau local (tel qu'Ethernet ou 802.11).
Android est compatible avec adb sécurisé. adb sécurisé active adb sur les hôtes authentifiés connus. Les implémentations d'appareils DOIVENT être compatibles avec adb sécurisé.
- Dalvik Debug Monitor Service (ddms) [Resources, 57]
Les implémentations d'appareils DOIVENT prendre en charge toutes les fonctionnalités ddms, comme indiqué dans le SDK Android. Comme ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme indiqué ci-dessus.
- Singe [Ressources, 58]
Les implémentations d'appareils DOIVENT inclure le framework Monkey et le rendre disponible pour les applications.
- SysTrace [Ressources, 59]
Les implémentations d'appareils DOIVENT prendre en charge l'outil Systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut, et un mécanisme accessible par l'utilisateur doit être disponible pour l'activer.
La plupart des systèmes Linux et des systèmes Apple Macintosh reconnaissent les appareils Android à l'aide des outils du SDK Android standard, sans assistance supplémentaire. Toutefois, les systèmes Microsoft Windows nécessitent généralement un pilote pour les nouveaux appareils Android. (Par exemple, les nouveaux ID de fournisseur et parfois les nouveaux ID d'appareil nécessitent des pilotes USB personnalisés pour les systèmes Windows.) Si une implémentation d'appareil n'est pas reconnue par l'outil adb fourni dans le SDK Android standard, les implémentateurs d'appareils DOIVENT fournir des pilotes Windows permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb. Ces pilotes DOIVENT être fournis pour Windows XP, Windows Vista, Windows 7, Windows 8 et Windows 9, en versions 32 bits et 64 bits.
6.2. Options pour les développeurs
Android permet aux développeurs de configurer les paramètres liés au développement d'applications. Les implémentations d'appareils DOIVENT respecter l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS pour afficher les paramètres liés au développement d'applications [Resources, 60]. L'implémentation Android en amont masque le menu "Options pour les développeurs" par défaut et permet aux utilisateurs de lancer les options pour les développeurs après avoir appuyé sept fois sur l'élément de menu Settings > About Device > Build Number (Paramètres > À propos de l'appareil > Numéro de version). Les implémentations d'appareils DOIVENT offrir une expérience cohérente pour les options pour les développeurs. Plus précisément, les implémentations d'appareils DOIVENT masquer les options pour les développeurs par défaut et DOIVENT fournir un mécanisme permettant d'activer les options pour les développeurs qui est cohérent avec l'implémentation Android en amont.
7. Compatibilité matérielle
Si un appareil inclut un composant matériel particulier associé à une API pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android. Si une API du SDK interagit avec un composant matériel déclaré comme facultatif et que l'implémentation de l'appareil ne possède pas ce composant:
- Les définitions de classe complètes (telles que documentées par le SDK) pour les API du composant DOIVENT toujours être présentées.
- Les comportements de l'API DOIVENT être implémentés comme des opérations sans action de manière raisonnable.
- Les méthodes d'API DOIVENT renvoyer des valeurs nulles lorsque la documentation du SDK l'autorise.
- Les méthodes d'API DOIVENT renvoyer des implémentations sans opération de classes pour lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.
- Les méthodes d'API NE DOIVENT PAS générer d'exceptions non documentées par la documentation du SDK.
L'API de téléphonie est un exemple typique de scénario où ces exigences s'appliquent: même sur les appareils autres que des téléphones, ces API doivent être implémentées comme des opérations sans opération raisonnables.
Les implémentations d'appareils DOIVENT signaler de manière cohérente des informations de configuration matérielle précises via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) de la classe android.content.pm.PackageManager pour la même empreinte de compilation. [Resources, 53]
7.1. Écran et graphismes
Android inclut des fonctionnalités qui ajustent automatiquement les éléments d'application et les mises en page de l'interface utilisateur en fonction de l'appareil, afin de s'assurer que les applications tierces fonctionnent correctement sur diverses configurations matérielles [Resources, 61]. 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 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 dpi sont indiquées, les dpi horizontaux et verticaux doivent se trouver dans la plage.
- format : rapport entre la dimension la plus longue de l'écran et la dimension la plus courte. Par exemple, un écran de 480 x 854 pixels correspond à 854 / 480 = 1,779, soit environ "16:9".
- Pixel indépendant de la densité (dp) : unité de pixel virtuel normalisée à un écran de 160 ppp, calculée comme suit : pixels = dp * (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 d'écran de l'appareil (également appelée "mise en page de l'écran") via android.content.res.Configuration.screenLayout avec SCREENLAYOUT_SIZE_MASK. Les implémentations d'appareils DOIVENT indiquer la taille d'écran correcte, telle que définie dans la documentation du SDK Android [Resources, 61] 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 (taille "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 autres types d'implémentations d'appareils Android, avec un écran physiquement intégré, DOIVENT avoir un écran d'au moins 6,35 cm de diagonale physique.
Les appareils NE DOIVENT PAS modifier la taille d'écran indiquée à tout moment.
Les applications peuvent indiquer les tailles d'écran qu'elles acceptent via l'attribut
7.1.1.2. Format d'écran
|
Les appareils Android Watch peuvent avoir un format de 1,0 (1:1). |
Le format de l'écran DOIT être compris entre 1,3333 (4:3) et 1,86 (environ 16:9), mais les appareils Android Watch PEUVENT avoir un format de 1,0 (1:1), car une telle implémentation d'appareil utilisera UI_MODE_TYPE_WATCH comme android.content.res.Configuration.uiMode.
7.1.1.3. Densité d'écran
Le framework d'UI Android définit un ensemble de densités logiques standards pour aider les développeurs d'applications à cibler les ressources d'application. Les implémentations d'appareils DOIVENT n'indiquer qu'une seule des densités logiques du framework Android suivantes via les API android.util.DisplayMetrics, et DOIVENT exécuter les applications à cette densité standard et NE DOIVENT PAS modifier la valeur à tout moment pour l'affichage par défaut.
- 120 PPP (ldpi)
- 160 ppp (mdpi)
- 213 ppp (tvdpi)
- 240 ppp (hdpi)
- 320 ppp (xhdpi)
- 400 ppp (400 dpi)
- 480 dpi (xxhdpi)
- 560 ppp (560dpi)
- 640 ppp (xxxhdpi)
Les implémentations d'appareils DOIVENT définir la densité de framework Android standard la plus proche numériquement de la densité physique de l'écran, sauf si cette densité logique fait passer la taille d'écran indiquée en dessous de la taille minimale prise en charge. Si la densité du framework Android standard la plus proche numériquement de la densité physique donne une taille d'écran inférieure à la plus petite taille d'écran compatible prise en charge (320 dp de largeur), les implémentations d'appareil DOIVENT indiquer la densité du framework Android standard la plus basse.
7.1.2. Métriques sur le Réseau Display
Les implémentations d'appareils DOIVENT indiquer les valeurs correctes pour toutes les métriques d'affichage définies dans android.util.DisplayMetrics [Resources, 62] et DOIVENT indiquer les mêmes valeurs, que l'écran intégré ou externe soit utilisé comme écran par défaut.
7.1.3. Orientation de l'écran
Les appareils DOIVENT indiquer les orientations d'écran qu'ils prennent en charge (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIVENT indiquer au moins une orientation compatible. Par exemple, un appareil doté d'un écran en mode paysage à orientation fixe, comme un téléviseur ou un ordinateur portable, DOIT uniquement signaler android.hardware.screen.landscape.
Les appareils qui signalent les deux orientations d'écran DOIVENT être compatibles avec l'orientation dynamique des applications en mode portrait ou paysage. Autrement dit, l'appareil doit respecter la demande de l'application pour une orientation d'écran spécifique. Les implémentations d'appareils PEUVENT sélectionner l'orientation portrait ou paysage par défaut.
Les appareils DOIVENT indiquer la valeur correcte pour l'orientation actuelle de l'appareil, chaque fois qu'ils sont interrogés via android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres API.
Les appareils NE DOIVENT PAS modifier la taille ou la densité d'écran signalée lors du changement d'orientation.
7.1.4. Accélération graphique 2D et 3D
Les implémentations d'appareils DOIVENT être compatibles avec OpenGL ES 1.0 et 2.0, comme indiqué et détaillé dans la documentation du SDK Android. Les implémentations d'appareils DOIVENT être compatibles avec OpenGL ES 3.0 ou 3.1 sur les appareils compatibles. Les implémentations d'appareils DOIVENT également prendre en charge Android RenderScript, comme indiqué dans la documentation du SDK Android [Ressources, 63].
Les implémentations d'appareils DOIVENT également s'identifier correctement comme étant compatibles avec OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 ou OpenGL 3.1. Par exemple :
- Les API gérées (par exemple, via la méthode GLES10.getString()) DOIVENT signaler la prise en charge d'OpenGL ES 1.0 et d'OpenGL ES 2.0.
- Les API OpenGL natives C/C++ (API disponibles pour les applications via libGLES_v1CM.so, libGLES_v2.so ou libEGL.so) DOIVENT signaler la prise en charge d'OpenGL ES 1.0 et d'OpenGL ES 2.0.
- Les implémentations d'appareils qui déclarent la prise en charge d'OpenGL ES 3.0 ou 3.1 DOIVENT prendre en charge les API gérées correspondantes et inclure la prise en charge des API C/C++ natives. Sur les implémentations d'appareils qui déclarent la prise en charge d'OpenGL ES 3.0 ou 3.1, libGLESv2.so DOIT exporter les symboles de fonction correspondants en plus des symboles de fonction OpenGL ES 2.0.
En plus d'OpenGL ES 3.1, Android fournit un pack d'extension avec des interfaces Java [Ressources, 64] et une prise en charge native des fonctionnalités graphiques avancées telles que la tessellation et le format de compression de texture ASTC. Les implémentations d'appareils Android PEUVENT prendre en charge ce pack d'extension et DOIVENT identifier la prise en charge via l'indicateur de fonctionnalité android.hardware.opengles.aep uniquement si elles sont entièrement implémentées.
De plus, les implémentations d'appareils PEUVENT implémenter toutes les extensions OpenGL ES souhaitées. Toutefois, les implémentations d'appareils DOIVENT signaler via les API natives et gérées OpenGL ES toutes les chaînes d'extension qu'elles prennent en charge, et inversement NE DOIVENT PAS signaler les chaînes d'extension qu'elles ne prennent pas en charge.
Notez qu'Android permet aux applications de spécifier facultativement qu'elles nécessitent des formats de compression de texture OpenGL spécifiques. Ces formats sont généralement propres au fournisseur. Android n'exige pas d'implémenter de format de compression de texture spécifique pour les implémentations d'appareils. Toutefois, ils DOIVENT signaler avec précision tous les formats de compression de texture qu'ils acceptent, via la méthode getString() de l'API OpenGL.
Android inclut un mécanisme permettant aux applications de déclarer qu'elles souhaitent activer l'accélération matérielle pour les graphiques 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue à l'aide d'une balise de fichier manifeste android:hardwareAccelerated ou d'appels d'API directs [Resources, 65].
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 [Ressources, 65].
Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES accélérées par matériel en tant que cibles de rendu dans une hiérarchie d'UI. Les implémentations d'appareils DOIVENT être compatibles avec l'API TextureView et DOIVENT présenter un comportement cohérent avec l'implémentation Android en amont.
Android est compatible avec EGL_ANDROID_RECORDABLE, un attribut EGLConfig qui indique si EGLConfig est compatible avec le rendu dans un ANativeWindow qui enregistre des images dans une vidéo. Les implémentations d'appareils DOIVENT prendre en charge l'extension EGL_ANDROID_RECORDABLE [Ressources, 66].
7.1.5. Ancien mode de compatibilité des applications
Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne en mode équivalent de taille d'écran "normale" (largeur de 320 dp) pour le bénéfice des anciennes applications qui n'ont pas été développées pour les anciennes versions d'Android antérieures à l'indépendance de la taille d'écran. Les implémentations d'appareils DOIVENT prendre en charge le mode de compatibilité des anciennes applications tel qu'implémenté par le code Open Source Android en amont. Autrement dit, les implémentations d'appareils NE DOIVENT PAS modifier les déclencheurs ou les seuils à partir desquels le mode de compatibilité est activé, et NE DOIVENT PAS modifier le comportement du mode de compatibilité lui-même.
7.1.6. Technologie d'affichage
La plate-forme Android inclut des API qui permettent aux applications d'afficher des graphiques riches. Les appareils DOIVENT prendre en charge toutes ces API telles que définies par le SDK Android, sauf si cela est spécifiquement autorisé dans ce document.
- Les appareils DOIVENT être compatibles avec les écrans capables d'afficher des graphiques couleur 16 bits et DOIVENT être compatibles avec les écrans capables d'afficher des graphiques couleur 24 bits.
- Les appareils DOIVENT être compatibles avec les écrans capables d'afficher des animations.
- La technologie d'affichage utilisée doit avoir un format de pixel (PAR) compris entre 0,9 et 1,15. Autrement dit, le format de pixel DOIT être proche du carré (1,0) avec une tolérance de 10 à 15 %.
7.1.7. Écrans externes
Android est compatible avec l'écran secondaire pour activer les fonctionnalités de partage multimédia et les API pour les développeurs permettant d'accéder aux écrans externes. Si un appareil est compatible avec un écran externe via une connexion filaire, sans fil ou intégrée, l'implémentation de l'appareil DOIT implémenter l'API du gestionnaire d'affichage, comme décrit dans la documentation du SDK Android [Ressources, 67].
7.2. Périphériques d'entrée
7.2.1. Clavier
|
Les appareils Android Watch peuvent implémenter un clavier virtuel, mais les autres types d'implémentations d'appareils doivent le faire. |
Implémentations de l'appareil:
- DOIT inclure la prise en charge du framework de gestion des entrées (qui permet aux développeurs tiers de créer des éditeurs de méthode d'entrée, c'est-à-dire un clavier virtuel), comme indiqué sur http://developer.android.com.
- DOIT fournir au moins une implémentation de clavier virtuel (que le clavier physique soit présent ou non), sauf pour les appareils Android Watch, où la taille de l'écran rend moins raisonnable l'utilisation d'un clavier virtuel
- PEUT inclure des implémentations de clavier virtuel supplémentaires
- POURRA inclure un clavier physique
- NE DOIT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard [Ressources, 68] (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 [Resources, 68]
- DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour la sélection et la modification du texte, compatible avec les moteurs de gestion des entrées. L'implémentation Open Source d'Android en amont inclut un mécanisme de sélection adapté aux appareils qui ne disposent pas d'entrées de navigation non tactiles.
7.2.3. Touches de navigation
|
Les 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 sur les événements de touche KEYCODE_HOME, KEYCODE_APP_SWITCH et KEYCODE_BACK) sont essentielles au paradigme de navigation Android. Par conséquent :
- Les implémentations d'appareils Android portables DOIVENT fournir les fonctions Accueil, Récents et Retour.
- Les implémentations d'appareils Android TV DOIVENT fournir les fonctions Accueil et Retour.
- Les implémentations d'appareils Android Watch DOIVENT proposer la fonction Accueil à l'utilisateur, ainsi que la fonction Retour, sauf lorsqu'elles sont en mode UI_MODE_TYPE_WATCH.
- Tous les autres types d'implémentations d'appareils DOIVENT fournir les fonctions "Accueil" et "Retour".
Ces fonctions PEUVENT être implémentées via des boutons physiques dédiés (tels que des boutons tactiles mécaniques ou capacitifs) ou à l'aide de touches logicielles dédiées sur une partie distincte de l'écran, des gestes, d'un écran tactile, etc. Android accepte les deux implémentations. Toutes ces fonctions DOIVENT être accessibles par une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) lorsqu'elles sont visibles.
La fonction "Récents", le cas échéant, DOIT comporter un bouton ou une icône visible, sauf si elle est masquée avec d'autres fonctions de navigation en mode plein écran. Cela ne s'applique pas aux appareils qui passent d'anciennes versions d'Android et qui disposent de boutons physiques pour la navigation et pas de touche "Récents".
Les fonctions "Accueil" et "Retour", le cas échéant, DOIVENT chacune comporter un bouton ou une icône visible, sauf si elles sont masquées avec d'autres fonctions de navigation en mode plein écran ou lorsque l'attribut uiMode UI_MODE_TYPE_MASK est défini sur UI_MODE_TYPE_WATCH.
La fonction Menu est obsolète depuis Android 4.0 et a été remplacée par la barre d'action. Par conséquent, les nouvelles implémentations d'appareils livrées avec Android 5.0 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 5.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 d'overflow d'action à une position modifiée à l'écran lorsqu'il s'affiche en sélectionnant le bouton de menu physique
Pour assurer la rétrocompatibilité, les implémentations d'appareils DOIVENT mettre la fonction Menu à la disposition des applications lorsque targetSdkVersion est inférieur ou égal à 10, soit par un bouton physique, une clé 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.
Android est compatible avec l'action d'assistance [Resources, 69]. Les implémentations d'appareils Android, à l'exception des appareils Android Watch, DOIVENT mettre l'action d'assistance à la disposition de l'utilisateur à tout moment lorsqu'il exécute des applications. L'action d'assistance DOIT être implémentée en tant qu'appui prolongé sur le bouton d'accueil ou en tant que geste de balayage vers le haut sur la touche d'accueil logicielle. Cette fonction PEUT être implémentée via un autre bouton physique, une touche logicielle ou un geste, mais DOIT être accessible avec une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) lorsque d'autres touches de navigation sont visibles.
Les implémentations d'appareils PEUVENT utiliser une partie distincte de l'écran pour afficher les touches de navigation. Si tel est le cas, elles DOIVENT respecter les exigences suivantes:
- Les touches de navigation de l'implémentation de l'appareil DOIVENT utiliser une partie distincte de l'écran, qui n'est pas disponible pour les applications, et NE DOIVENT PAS masquer ni interférer avec la partie de l'écran disponible pour les applications.
- Les implémentations d'appareils DOIVENT mettre à la disposition des applications une partie de l'écran qui répond aux exigences définies dans la section 7.1.1.
- Les implémentations d'appareils DOIVENT afficher les touches de navigation lorsque les applications ne spécifient pas de mode d'UI système ou spécifient SYSTEM_UI_FLAG_VISIBLE.
- Les implémentations d'appareils DOIVENT présenter les touches de navigation dans un mode "bas profil" discret (par exemple, atténué) lorsque les applications spécifient SYSTEM_UI_FLAG_LOW_PROFILE.
- Les implémentations d'appareils DOIVENT masquer les touches de navigation lorsque les applications spécifient SYSTEM_UI_FLAG_HIDE_NAVIGATION.
7.2.4. Saisie par écran tactile
|
Les 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 de pointeur (similaire à une souris ou à un écran tactile). Toutefois, si une implémentation d'appareil n'est pas compatible avec un système de saisie par pointeur, elle NE DOIT PAS signaler la constante de fonctionnalité android.hardware.touchscreen ou android.hardware.faketouch. Implémentations d'appareils qui incluent un système de saisie par pointeur:
- DOIT prendre en charge les pointeurs entièrement suivis de manière indépendante, si le système d'entrée de l'appareil prend en charge plusieurs pointeurs
- DOIT indiquer la valeur d'android.content.res.Configuration.touchscreen [Ressources, 68] correspondant au type d'écran tactile spécifique de l'appareil
Android est compatible avec différents écrans tactiles, pavés tactiles et faux périphériques d'entrée tactile. Les implémentations d'appareils à écran tactile sont associées à un écran [Resources, 70] de sorte que l'utilisateur a l'impression de manipuler directement des éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système n'a pas besoin d'affordances supplémentaires pour indiquer les objets manipulés. À l'inverse, une interface tactile simulée fournit un système de saisie utilisateur qui s'approche d'un sous-ensemble des fonctionnalités d'un écran tactile. Par exemple, une souris ou une télécommande qui dirige un curseur à l'écran s'approche de la saisie tactile, mais nécessite que l'utilisateur pointe ou mette en surbrillance l'élément, puis clique dessus. De nombreux périphériques d'entrée tels que la souris, le pavé tactile, la souris sans fil à gyroscope, le pointeur à gyroscope, le joystick et le pavé tactile multipoint peuvent prendre en charge les interactions tactiles simulées. Android 5.0 inclut la constante de fonctionnalité android.hardware.faketouch, qui correspond à un périphérique d'entrée non tactile (basé sur un pointeur) haute fidélité, tel qu'une souris ou un pavé tactile, qui peut émuler correctement la saisie tactile (y compris la prise en charge des gestes de base) et indique que l'appareil est compatible avec un sous-ensemble émulé des fonctionnalités de l'écran tactile. Les implémentations d'appareils qui déclarent la fonctionnalité de faux appui DOIVENT respecter les exigences de la section 7.2.5.
Les implémentations d'appareils DOIVENT signaler la fonctionnalité appropriée correspondant au type d'entrée utilisé. Les implémentations d'appareils qui incluent un écran tactile (à un seul contact ou mieux) DOIVENT signaler la constante de fonctionnalité de plate-forme android.hardware.touchscreen. Les implémentations d'appareils qui signalent la constante de fonctionnalité de plate-forme android.hardware.touchscreen DOIVENT également signaler la constante de fonctionnalité de plate-forme android.hardware.faketouch. Les implémentations d'appareils qui n'incluent pas d'écran tactile (et qui ne reposent que sur un dispositif de pointage) NE DOIVENT PAS signaler de fonctionnalité d'écran tactile et DOIVENT signaler uniquement android.hardware.faketouch s'ils répondent aux exigences de l'écran tactile simulé de la section 7.2.5.
7.2.5. Saisie tactile fictive
Implémentations d'appareils qui déclarent la prise en charge d'android.hardware.faketouch:
- DOIT indiquer les positions X et Y absolues de l'emplacement du pointeur à l'écran et afficher un pointeur visuel à l'écran [Ressources, 71]
- 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 [Ressources, 71]
- DOIT prendre en charge le pointeur vers le bas et vers le haut sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler un appui sur un objet à l'écran
- DOIT prendre en charge le pointeur vers le bas, le pointeur vers le haut, le pointeur vers le bas, puis le pointeur vers le haut au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler un double appui sur un objet à l'écran [Resources, 71]
- 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 à l'écran, ce qui leur permet de lancer un objet à l'écran
Les appareils qui déclarent être compatibles avec android.hardware.faketouch.multitouch.distinct DOIVENT respecter les exigences de faketouch ci-dessus et DOIVENT également prendre en charge le suivi distinct de deux ou plusieurs entrées de pointeur indépendantes.
7.2.6. Compatibilité avec les manettes de jeu
Les implémentations d'appareils Android TV DOIVENT prendre en charge les mappages de boutons pour les manettes de jeu, comme indiqué ci-dessous. L'implémentation Android en amont inclut une implémentation pour les contrôleurs de jeu qui répond à cette exigence.
7.2.6.1. Mappages des boutons
Les implémentations d'appareils Android TV DOIVENT prendre en charge les mappages de clés suivants:
|
Button |
Utilisation des périphériques HID2 |
Bouton Android |
|
A1 |
0x09 0x0001 |
KEYCODE_BUTTON_A (96) |
|
B1 |
0x09 0x0002 |
KEYCODE_BUTTON_B (97) |
|
X1 |
0x09 0x0004 |
KEYCODE_BUTTON_X (99) |
|
Y1 |
0x09 0x0005 |
KEYCODE_BUTTON_Y (100) |
|
0x01 0x00393 |
||
|
0x01 0x00393 |
||
|
0x09 0x0007 |
KEYCODE_BUTTON_L1 (102) |
|
|
0x09 0x0008 |
KEYCODE_BUTTON_R1 (103) |
|
|
0x09 0x000E |
KEYCODE_BUTTON_THUMBL (106) |
|
|
0x09 0x000F |
KEYCODE_BUTTON_THUMBR (107) |
|
|
0x0c 0x0223 |
KEYCODE_HOME (3) |
|
|
0x0c 0x0224 |
KEYCODE_BACK (4) |
1 [Ressources, 72]
2 Les utilisations HID ci-dessus doivent être déclarées dans une autorité de certification de manette de jeu (0x01 0x0005).
3 Cette utilisation doit avoir une valeur minimale logique de 0, une valeur maximale logique de 7, une valeur minimale physique de 0, une valeur maximale physique de 315, des unités en degrés et une taille de rapport de 4. La valeur logique est définie comme étant la rotation dans le sens des aiguilles d'une montre à partir de l'axe vertical. Par exemple, une valeur logique de 0 représente une absence de rotation et la pression sur le bouton "Haut", tandis qu'une valeur logique de 1 représente une rotation de 45 degrés et la pression sur les touches "Haut" et "Gauche".
4 [Resources, 71]
|
Commandes analogiques1 |
Utilisation des périphériques HID |
Bouton Android |
|
0x02 0x00C5 |
AXIS_LTRIGGER |
|
|
0x02 0x00C4 |
AXIS_RTRIGGER |
|
|
0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
|
|
0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
1 [Ressources, 71]
7.2.7. Télécommande
Les implémentations d'appareils Android TV DOIVENT fournir une télécommande pour permettre aux utilisateurs d'accéder à l'interface TV. La télécommande peut être une télécommande physique ou une télécommande logicielle accessible depuis un téléphone mobile ou une tablette. La télécommande DOIT répondre aux exigences définies ci-dessous.
- Facilité d'accès à la recherche : les implémentations d'appareils DOIVENT déclencher KEYCODE_SEARCH lorsque l'utilisateur appelle la recherche vocale sur la télécommande physique ou logicielle.
- Navigation : toutes les télécommandes Android TV DOIVENT inclure les boutons "Retour", "Accueil" et "Sélection", et prendre en charge les événements de la croix directionnelle [Ressources, 72].
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 associé à une API pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android et la documentation Open Source Android sur les capteurs [Ressources, 73]. Par exemple, les implémentations d'appareils:
- DOIT signaler avec précision la présence ou l'absence de capteurs conformément à la classe android.content.pm.PackageManager [Ressources, 53]
- DOIT renvoyer une liste précise des capteurs compatibles via SensorManager.getSensorList() et des méthodes similaires
- DOIT se comporter de manière raisonnable pour toutes les autres API de capteurs (par exemple, en renvoyant "true" ou "false" selon les cas lorsque les applications tentent d'enregistrer des écouteurs, en n'appelant pas les écouteurs de capteurs lorsque les capteurs correspondants ne sont pas présents, etc.)
- DOIT signaler toutes les mesures des capteurs à l'aide des valeurs du système international d'unités (métriques) appropriées pour chaque type de capteur, comme défini dans la documentation du SDK Android [Ressources, 74]
- DOIT indiquer l'heure de l'événement en nanosecondes, comme défini dans la documentation du SDK Android. Représente l'heure à laquelle l'événement s'est produit et synchronisé avec l'horloge SystemClock.elapsedRealtimeNano(). Les appareils Android existants et nouveaux sont très fortement encouragés à respecter ces exigences afin de pouvoir passer aux futures versions de la plate-forme, où ce composant pourrait devenir OBLIGATOIRE. L'erreur de synchronisation DOIT être inférieure à 100 millisecondes [Ressources, 75].
La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et de la documentation Open Source Android sur les capteurs [Ressources, 73] doit être considéré comme faisant autorité.
Certains types de capteurs sont composites, ce qui signifie qu'ils peuvent être dérivés des données fournies par un ou plusieurs autres capteurs. (Exemples : capteur d'orientation et capteur d'accélération linéaire.) Les implémentations d'appareils DOIVENT implémenter ces types de capteurs lorsqu'ils incluent les capteurs physiques requis, comme décrit dans [Resources, 76]. Si une implémentation d'appareil inclut un capteur composite, elle DOIT implémenter le capteur comme décrit dans la documentation Open Source Android sur les capteurs composites [Ressources, 76].
Certains capteurs Android sont compatibles avec un mode de déclenchement "continu", qui renvoie des données en continu [Resources, 77]. Pour toute API indiquée par la documentation du SDK Android comme étant un capteur continu, les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques dont le jitter DOIT être inférieur à 3%, où le jitter est défini comme l'écart type de la différence entre les valeurs de code temporel signalées entre les événements consécutifs.
Notez que les implémentations de l'appareil DOIVENT s'assurer que le flux d'événements du capteur NE DOIT PAS empêcher le processeur de l'appareil de passer en état de suspension ou de se réveiller d'un état de suspension.
Enfin, lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme de la consommation d'énergie indiquée par chaque capteur.
7.3.1. Accéléromètre
Les implémentations d'appareils DOIVENT inclure un accéléromètre à trois axes. Nous vous recommandons vivement d'inclure ce capteur sur les appareils Android portables et les montres Android. Si une implémentation d'appareil inclut un accéléromètre à trois axes, elle:
- DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER [Resources, 78]
- DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz et DOIT signaler des événements jusqu'à au moins 200 Hz
- DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans les API Android [Ressources, 74]
- DOIT être capable de mesurer de la chute libre jusqu'à quatre fois la gravité (4 g) ou plus sur n'importe quel axe
- Doit avoir une résolution d'au moins 8 bits et DEVRAIT avoir une résolution d'au moins 16 bits
- DOIT être calibré en cours d'utilisation si les caractéristiques changent au cours du cycle de vie et compensées, et conserver les paramètres de compensation entre les redémarrages de l'appareil
- DOIT être compensé en température
- DOIT avoir une déviation standard ne dépassant pas 0,05 m/s^, où la déviation standard doit être calculée par axe sur les échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide
- DOIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER, comme décrit dans le document du SDK Android. Nous recommandons vivement 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 vous 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 de gyroscope et un capteur de magnétomètre sont également inclus
7.3.2. Magnétomètre
Les implémentations d'appareils DOIVENT inclure un magnétomètre (boussole) à trois axes. Si un appareil inclut un magnétomètre 3 axes, il:
- DOIT implémenter le capteur TYPE_MAGNETIC_FIELD et DOIT également implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED. Nous encourageons vivement les appareils Android existants et nouveaux à implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED.
- DOIT pouvoir générer des rapports sur les événements jusqu'à une fréquence d'au moins 10 Hz et DOIT générer des rapports sur les événements jusqu'à au moins 50 Hz
- DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans les API Android [Ressources, 74]
- DOIT être capable de mesurer entre -900 μT et +900 μT sur chaque axe avant de saturer
- DOIT avoir une valeur de décalage de fer dur inférieure à 700 μT et DEVRAIT avoir une valeur inférieure à 200 μT, en plaçant le magnétomètre loin des champs magnétiques dynamiques (induits par le courant) et statiques (induits par le magnétisme).
- DOIT avoir une résolution égale ou plus dense que 0,6 μT et DEVRAIT avoir une résolution égale ou plus dense que 0,2 μT
- DOIT être compensé en température
- DOIT prendre en charge la calibration et la compensation en ligne du biais de l'appareil physique, et préserver les paramètres de compensation entre les redémarrages de l'appareil
- La compensation du fer doux doit être appliquée. Le calibrage peut être effectué pendant l'utilisation ou lors de la production de l'appareil.
- DOIT avoir une écart type, calculé par axe sur les échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide, ne dépassant pas 0,5 μT
- DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR, si un capteur d'accéléromètre et un capteur de gyroscope sont également inclus
- PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR si un capteur d'accéléromètre est également implémenté. Toutefois, s'il est implémenté, il DOIT consommer moins de 10 mW et DEVRAIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode par lot à 10 Hz.
7.3.3. GPS
Les implémentations d'appareils DOIVENT inclure un récepteur GPS. Si l'implémentation d'un appareil inclut un récepteur GPS, elle DOIT inclure une forme de technique "GPS assisté" pour réduire le temps de verrouillage du GPS.
7.3.4. Gyroscope
Les implémentations d'appareils DOIVENT inclure un gyroscope (capteur de changement angulaire). Les appareils NE DOIVENT PAS inclure de capteur de gyroscope, sauf si un accéléromètre à trois axes est également inclus. Si une implémentation d'appareil inclut un gyroscope:
- DOIT implémenter le capteur TYPE_GYROSCOPE et DOIT également implémenter le capteur TYPE_GYROSCOPE_UNCALIBRATED. Nous vous recommandons vivement d'implémenter le capteur SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sur les appareils Android existants et nouveaux.
- DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde
- DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz et DOIT signaler des é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
- DOIT être calibré et compensé pendant l'utilisation, et conserver les paramètres de compensation entre les redémarrages de l'appareil
- DOIT avoir une variance ne dépassant pas 1e-7 rad² / s² par Hz (variance par Hz, ou rad² / s). La variance peut varier avec le taux d'échantillonnage, mais doit être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyro à un taux d'échantillonnage de 1 Hz, elle ne doit pas dépasser 1e-7 rad^2/s^2.
- DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR, si un capteur d'accéléromètre et un capteur de magnétomètre sont également inclus
- Si un capteur d'accéléromètre est inclus, vous DEVEZ implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION, et DEVREZ implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR. Nous vous 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.
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.4. Connectivité des données
7.4.1. Téléphonie
Le terme "téléphonie" utilisé par les API Android et ce document fait spécifiquement référence au matériel lié à la réalisation d'appels vocaux et à l'envoi de messages SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent ou non être commutés par paquets, ils sont considérés comme indépendants de toute connectivité de données pouvant être implémentée sur le même réseau. En d'autres termes, les fonctionnalités et les API de "téléphonie" Android font spécifiquement référence aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir de messages SMS NE DOIVENT PAS signaler la fonctionnalité android.hardware.telephony ni aucune sous-fonctionnalité, que ce soit ou non via un réseau mobile pour la connectivité de données.
Android peut être utilisé sur des appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android est compatible avec des appareils autres que des téléphones. Toutefois, si l'implémentation d'un appareil inclut la téléphonie GSM ou CDMA, elle DOIT prendre en charge entièrement l'API pour cette technologie. Les implémentations d'appareils qui n'incluent pas de matériel de téléphonie DOIVENT implémenter les API complètes en tant que no-ops.
7.4.2. IEEE 802.11 (Wi-Fi)
|
Les implémentations d'appareils Android TV DOIVENT inclure la prise en charge du Wi-Fi. |
Les implémentations d'appareils Android TV DOIVENT être compatibles avec une ou plusieurs formes de 802.11 (b/g/a/n, etc.), et les autres types d'implémentation d'appareils Android DOIVENT être compatibles avec une ou plusieurs formes de 802.11. Si l'implémentation d'un appareil inclut la prise en charge de la norme 802.11 et expose la fonctionnalité à une application tierce, elle DOIT implémenter l'API Android correspondante et:
- DOIT indiquer le commutateur de fonctionnalité matérielle android.hardware.wifi
- DOIT implémenter l'API multicast comme décrit dans la documentation du SDK [Ressources, 79]
- DOIT être compatible avec le multicast DNS (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à tout moment de l'opération, y compris lorsque l'écran n'est pas actif
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 Wi-Fi Direct, elle DOIT implémenter l'API Android correspondante, comme décrit dans la documentation du SDK [Ressources, 80]. 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 l'opération simultanée du Wi-Fi et du Wi-Fi Direct
7.4.2.2. Configuration du lien direct en tunnel Wi-Fi
|
Les implémentations d'appareils Android TV DOIVENT prendre en charge la configuration de liaison directe en tunnel Wi-Fi (TDLS). |
Les implémentations d'appareils Android TV DOIVENT être compatibles avec la configuration de liaison directe en tunnel Wi-Fi (TDLS, Tunneled Direct Link Setup), et les autres types d'implémentations d'appareils Android DOIVENT être compatibles avec le TDLS Wi-Fi, comme décrit dans la documentation du SDK Android [Ressources, 81]. 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 bénéfique
- DOIT avoir une heuristique et NE PAS utiliser TDLS lorsque ses performances peuvent être pires que celles du point d'accès Wi-Fi
7.4.3. Bluetooth
|
Les implémentations d'appareils Android TV DOIVENT être compatibles avec le Bluetooth et le Bluetooth LE, et les implémentations d'appareils Android Watch DOIVENT être compatibles avec le Bluetooth. |
Android est compatible avec le Bluetooth et le Bluetooth à basse consommation [Resources, 82]. Les implémentations d'appareils qui incluent la prise en charge du Bluetooth et du Bluetooth à basse consommation DOIVENT déclarer les fonctionnalités de plate-forme pertinentes (android.hardware.bluetooth et android.hardware.bluetooth_le, respectivement) et implémenter les API de la plate-forme. Les implémentations d'appareils DOIVENT implémenter les profils Bluetooth pertinents tels que A2DP, AVCP, OBEX, etc., selon les besoins de l'appareil. Les implémentations d'appareils Android Television DOIVENT prendre en charge le Bluetooth et le Bluetooth LE.
Implémentations d'appareils prenant en charge le Bluetooth à basse consommation:
- DOIT déclarer la fonctionnalité matérielle android.hardware.bluetooth_le
- DOIT activer les API Bluetooth basées sur le GATT (profil d'attribut générique) comme décrit dans la documentation du SDK et dans [Resources, 82]
- DOIT prendre en charge le transfert de la logique de filtrage vers le chipset Bluetooth lors de l'implémentation de l'API ScanFilter [Resources, 83] et DOIT indiquer la valeur correcte de l'emplacement où la logique de filtrage est implémentée chaque fois qu'elle est interrogée via la méthode android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported()
- DOIT prendre en charge le transfert de la numérisation groupée vers le chipset Bluetooth, mais si ce n'est pas le cas, DOIT renvoyer la valeur "false" chaque fois qu'il est interrogé via la méthode android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported().
- DOIT prendre en charge la publicité multiple avec au moins quatre emplacements, mais si ce n'est pas le cas, DOIT renvoyer "false" chaque fois qu'il est interrogé via la méthode android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported()
7.4.4. Communication en champ proche
Les implémentations d'appareils DOIVENT inclure un émetteur-récepteur et du matériel associé pour la technologie NFC (communication en champ proche). Si une implémentation d'appareil inclut du matériel NFC et prévoit de le mettre à la disposition d'applications tierces, elle:
- DOIT signaler la fonctionnalité android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature() [Resources, 53]
- 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 6319-4)
- IsoDep (ISO 14443-4)
- Types de tags NFC Forum 1, 2, 3 et 4 (définis par le forum NFC)
- DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes. Notez que, bien que les normes NFC ci-dessous soient indiquées comme "DEVRAIENT", la définition de la compatibilité pour une future version prévoit de les remplacer par "DOIT". Ces normes sont facultatives dans cette version, mais elles seront obligatoires dans les versions ultérieures. Nous recommandons vivement aux appareils existants et nouveaux exécutant cette version d'Android de répondre à ces exigences dès maintenant afin de pouvoir passer aux futures versions de la plate-forme.
- NfcV (ISO 15693)
- DOIT être capable de transmettre et de recevoir des données via les normes et protocoles peer-to-peer suivants :
- ISO 18092
- LLCP 1.0 (défini par le forum NFC)
- SDP 1.0 (défini par le forum NFC)
- Protocole NDEF Push [Ressources, 84]
- SNEP 1.0 (défini par le forum NFC)
- DOIT inclure la prise en charge d'Android Beam [Resources, 85]:
- DOIT implémenter le serveur par défaut SNEP. Les messages NDEF valides reçus par le serveur SNEP par défaut DOIVENT être distribués aux applications à l'aide de l'intent android.nfc.ACTION_NDEF_DISCOVERED. La désactivation d'Android Beam dans les paramètres NE DOIT PAS désactiver l'envoi du message NDEF entrant.
- DOIT respecter l'intent android.settings.NFCSHARING_SETTINGS pour afficher les paramètres de partage NFC [Ressources, 86]
- DOIT implémenter le serveur NPP. Les messages reçus par le serveur NPP DOIVENT être traités de la même manière que le serveur par défaut SNEP.
- DOIT implémenter un client SNEP et tenter d'envoyer un NDEF P2P sortant au serveur SNEP par défaut lorsque Android Beam est activé. Si aucun serveur SNEP par défaut n'est trouvé, le client DOIT tenter d'envoyer un message à un serveur NPP.
- DOIT autoriser les activités de premier plan à définir le message NDEF P2P sortant à l'aide d'android.nfc.NfcAdapter.setNdefPushMessage, d'android.nfc.NfcAdapter.setNdefPushMessageCallback et d'android.nfc.NfcAdapter.enableForegroundNdefPush
- DOIT utiliser un geste ou une confirmation à l'écran, comme "Appuyer pour transférer", avant d'envoyer des messages NDEF P2P sortants
- DOIT activer Android Beam par défaut et DOIT pouvoir envoyer et recevoir des données à l'aide d'Android Beam, même lorsqu'un autre mode P2P NFC propriétaire est activé
- DOIT prendre en charge le transfert de connexion NFC vers le Bluetooth lorsque l'appareil est compatible avec le profil Bluetooth Object Push. Les implémentations d'appareils DOIVENT prendre en charge le transfert de connexion vers le Bluetooth lorsque vous utilisez android.nfc.NfcAdapter.setBeamPushUris, en implémentant les spécifications "Connection Handover version 1.2" [Resources, 87] et "Bluetooth Secure Simple Pairing Using NFC version 1.0" [Resources, 88] du NFC Forum. Une telle implémentation DOIT implémenter le service LLCP de transfert avec le nom de service "urn:nfc:sn:handover" pour échanger les enregistrements de requête/sélection de transfert via NFC, et DOIT utiliser le profil Bluetooth Object Push Profile pour le transfert de données Bluetooth. Pour des raisons d'ancienneté (pour rester compatible avec les appareils Android 4.1), l'implémentation DOIT toujours accepter les requêtes GET SNEP pour échanger la requête de transfert/sélectionner des enregistrements via NFC. Toutefois, une implémentation elle-même NE DOIT PAS envoyer de requêtes GET SNEP pour effectuer la passation de connexion.
- DOIT interroger toutes les technologies compatibles en mode découverte NFC
- DOIT être en mode de découverte NFC lorsque l'appareil est actif, que l'écran est actif et que l'écran de verrouillage est déverrouillé
- 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 :
(Notez que les liens publics ne sont pas disponibles pour les spécifications JIS, ISO et NFC Forum citées ci-dessus.)
Android 5.0 est compatible avec le mode NFC HCE (Host Card Emulation). Si l'implémentation d'un appareil inclut un contrôleur NFC compatible avec le routage HCE et l'ID d'application (AID), il:
- DOIT indiquer la constante de fonctionnalité android.hardware.nfc.hce
- DOIT prendre en charge les API NFC HCE telles que définies dans le SDK Android [Ressources, 10]
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() [Resources, 53]. 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 PackageManager.
- NE DOIT PAS implémenter les API Android correspondantes ni signaler la fonctionnalité com.nxp.mifare, sauf s'il implémente également la prise en charge générale de la technologie NFC, comme décrit dans cette section
Si une implémentation d'appareil n'inclut pas de matériel NFC, elle NE DOIT PAS déclarer la fonctionnalité android.hardware.nfc de la méthode android.content.pm.PackageManager.hasSystemFeature() [Resources, 53] et DOIT implémenter l'API NFC Android comme une opération sans effet.
Comme les classes android.nfc.NdefMessage et android.nfc.NdefRecord représentent un format de représentation de données indépendant du protocole, les implémentations d'appareils DOIVENT implémenter ces API, même si elles n'incluent pas la compatibilité avec la technologie NFC ni ne déclarent la fonctionnalité android.hardware.nfc.
7.4.5. Capacité réseau minimale
Les implémentations d'appareils DOIVENT prendre en charge une ou plusieurs formes de mise en réseau de données. Plus précisément, les implémentations d'appareils DOIVENT prendre en charge au moins une norme de données capable de 200 kbit/s ou plus. EDGE, HSPA, EV-DO, 802.11g, Ethernet, PAN Bluetooth, etc. sont des exemples de technologies qui répondent à cette exigence.
Les implémentations d'appareils où une norme de réseau physique (telle qu'Ethernet) constitue la connexion de données principale DOIVENT également prendre en charge au moins une norme de données sans fil courante, telle que 802.11 (Wi-Fi).
Les appareils PEUVENT implémenter plusieurs formes de connectivité de données.
7.4.6. Paramètres de synchronisation
Le paramètre de synchronisation automatique principale doit être activé par défaut dans les implémentations d'appareils afin que la méthode getMasterSyncAutomatically() renvoie "true" [Resources, 89].
7.5. Caméras
Les implémentations d'appareils DOIVENT inclure une caméra arrière et PEUVENT inclure une caméra avant. Une caméra arrière est une caméra située sur le côté de l'appareil, à l'opposé de l'écran. Autrement dit, elle capture des scènes à l'arrière de l'appareil, comme une caméra traditionnelle. Une caméra avant est une caméra située du même côté de l'appareil que l'écran. Autrement dit, il s'agit d'une caméra généralement utilisée pour prendre une photo de l'utilisateur, par exemple pour les visioconférences et les applications similaires.
Si une implémentation d'appareil inclut au moins une caméra, une application DOIT pouvoir allouer simultanément trois bitmaps égaux à la taille des images produites par le capteur d'appareil photo de la plus haute résolution de l'appareil.
7.5.1. Caméra arrière
Les implémentations d'appareils DOIVENT inclure une caméra arrière. Si l'implémentation d'un appareil inclut au moins une caméra arrière:
- DOIT signaler le commutateur de fonctionnalité android.hardware.camera et android.hardware.camera.any
- Doit avoir une résolution d'au moins 2 mégapixels
- L'autofocus matériel ou logiciel doit être implémenté dans le pilote de l'appareil photo (transparent pour le logiciel d'application).
- POURRAIENT être équipés d'un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF)
- POURRA inclure un flash. Si l'appareil photo inclut un flash, la lampe de flash NE DOIT PAS être allumée lorsqu'une instance android.hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de l'appareil photo, sauf si l'application a explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas à l'application d'appareil photo système intégrée de l'appareil, mais uniquement aux applications tierces qui utilisent Camera.PreviewCallback.
7.5.2. Caméra avant
Les implémentations d'appareils PEUVENT inclure une caméra avant. Si l'implémentation d'un appareil inclut au moins une caméra avant, elle:
- DOIT signaler le commutateur de fonctionnalité android.hardware.camera.any et android.hardware.camera.front
- DOIT avoir une résolution d'au moins VGA (640 x 480 pixels)
- NE DOIT PAS utiliser une caméra avant par défaut pour l'API Camera. L'API Appareil photo d'Android est compatible avec les caméras avant. Les implémentations d'appareils NE DOIVENT PAS configurer l'API pour qu'elle traite une caméra avant comme la caméra arrière par défaut, même si elle est la seule caméra de l'appareil.
- POURRA inclure des fonctionnalités (comme le focus automatique, le flash, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1
- DOIT refléter horizontalement (c'est-à-dire en miroir) le flux affiché par une application dans un CameraPreview, comme suit :
- Si l'implémentation de l'appareil peut être pivotée par l'utilisateur (par exemple, automatiquement via un accéléromètre ou manuellement via une entrée utilisateur), l'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation actuelle de l'appareil.
- Si l'application actuelle a explicitement demandé que l'écran de l'appareil photo soit pivoté via un appel à la méthode android.hardware.Camera.setDisplayOrientation()[Resources, 90], l'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application.
- Sinon, l'aperçu DOIT être mis en miroir le long de l'axe horizontal par défaut de l'appareil.
- DOIT refléter l'image affichée par le postview de la même manière que le flux d'images d'aperçu de l'appareil photo. Si l'implémentation de l'appareil n'est pas compatible avec la postview, cette exigence ne s'applique évidemment pas.
- NE DOIT PAS refléter les flux d'images fixes ou vidéo capturés renvoyés aux rappels d'application ou enregistrés dans le stockage multimédia
7.5.3. Caméra externe
Les implémentations d'appareils avec le mode hôte USB PEUVENT inclure la compatibilité avec une caméra externe connectée au port USB. Si un appareil est compatible avec une caméra externe:
- DOIT déclarer la fonctionnalité de plate-forme android.hardware.camera.external et android.hardware camera.any
- Doit être compatible avec la classe vidéo USB (UVC 1.0 ou version ultérieure)
- Peut être compatible avec plusieurs caméras
La prise en charge de la compression vidéo (par exemple, MJPEG) est RECOMMANDÉE pour permettre le transfert de flux non encodés de haute qualité (c'est-à-dire des flux d'images bruts ou compressés indépendamment). L'encodage vidéo basé sur l'appareil photo peut être pris en charge. Si tel est le cas, un flux non encodé/ MJPEG simultané (résolution QVGA ou supérieure) DOIT être accessible à l'implémentation de l'appareil.
7.5.4. Comportement de l'API Camera
Android inclut deux packages d'API pour accéder à l'appareil photo. L'API android.hardware.camera2 la plus récente expose le contrôle de l'appareil photo de niveau inférieur à l'application, y compris des flux de streaming/rafale efficaces sans copie et des commandes par frame de l'exposition, du gain, des gains de balance des blancs, de la conversion des couleurs, du dénoyage, de l'accentuation, etc.
L'ancien package d'API, android.hardware.Camera, est marqué comme obsolète dans Android 5.0. Toutefois, comme il doit toujours être disponible pour que les applications puissent utiliser les implémentations d'appareils Android, vous devez assurer la prise en charge continue de l'API, comme décrit dans cette section et dans le SDK Android.
Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à la caméra, pour toutes les caméras disponibles:
- Si une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int), l'appareil DOIT utiliser android.hardware.PixelFormat.YCbCr_420_SP pour les données d'aperçu fournies aux rappels d'application.
- Si une application enregistre une instance android.hardware.Camera.PreviewCallback et que le système appelle la méthode onPreviewFrame() lorsque le format d'aperçu est YCbCr_420_SP, les données du byte[] transmises à onPreviewFrame() doivent également être au format d'encodage NV21. Autrement dit, NV21 DOIT être la valeur par défaut.
- Pour android.hardware.Camera, les implémentations d'appareils DOIVENT prendre en charge le format YV12 (comme indiqué par la constante android.graphics.ImageFormat.YV12) pour les aperçus de l'appareil photo pour les caméras avant et arrière. (L'encodeur vidéo matériel et la caméra peuvent utiliser n'importe quel format de pixel natif, mais l'implémentation de l'appareil DOIT prendre en charge la conversion en YV12.)
- Pour android.hardware.camera2, les implémentations d'appareils doivent prendre en charge les formats android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en sortie via l'API android.media.ImageReader.
Les implémentations d'appareils DOIVENT toujours implémenter l'API Camera complète incluse dans la documentation du SDK Android [Ressources, 91], que l'appareil inclue ou non un autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo qui ne disposent pas d'autofocus DOIVENT toujours appeler les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela n'a aucune pertinence pour un appareil photo sans autofocus). Notez que cela s'applique aux caméras avant. Par exemple, même si la plupart des caméras avant ne sont pas compatibles avec la mise au point automatique, les rappels d'API doivent toujours être "faussés" comme décrit.
Les implémentations d'appareils DOIVENT reconnaître et respecter chaque nom de paramètre défini comme constante dans la classe android.hardware.Camera.Parameters, si le matériel sous-jacent est compatible avec la fonctionnalité. Si le matériel de l'appareil n'est pas compatible avec une fonctionnalité, l'API doit se comporter comme indiqué dans la documentation. À l'inverse, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters() autres que celles documentées en tant que constantes sur android.hardware.Camera.Parameters. Autrement dit, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres d'appareil photo standards si le matériel le permet et NE DOIVENT PAS prendre en charge les types de paramètres d'appareil photo personnalisés. Par exemple, les implémentations d'appareils compatibles avec la capture d'images à l'aide de techniques d'imagerie HDR (High Dynamic Range) DOIVENT prendre en charge le paramètre de l'appareil photo Camera.SCENE_MODE_HDR [Resources, 92].
É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 [Ressources, 93] et indiquer les indicateurs de fonctionnalité de framework appropriés [Ressources, 94].
Les implémentations d'appareils DOIVENT également déclarer les fonctionnalités individuelles de la caméra d'android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés [Resources, 94]. Un appareil doit définir l'indicateur de fonctionnalité si l'un de ses appareils photo connectés est compatible avec la fonctionnalité.
Les implémentations d'appareils DOIVENT diffuser l'intent Camera.ACTION_NEW_PICTURE chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée de la photo a été ajoutée au Media Store.
Les implémentations d'appareils DOIVENT diffuser l'intent Camera.ACTION_NEW_VIDEO chaque fois qu'une nouvelle vidéo est enregistrée par l'appareil photo et que l'entrée de l'image a été ajoutée au store multimédia.
7.5.5. Orientation de l'appareil photo
Les caméras avant et arrière, le cas échéant, DOIVENT être orientées de sorte à faire correspondre la dimension longue de la caméra à la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil, c'est-à-dire aux appareils en mode paysage et en mode portrait.
7.6. Mémoire et stockage
7.6.1. Mémoire et stockage minimums
|
Les appareils Android TV doivent disposer d'au moins 5 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 d'écran |
Appareil 32 bits |
Appareil 64 bits |
|
Appareils Android Watch (en raison des écrans plus petits) |
416 Mo |
Non applicable |
|
xhdpi ou version inférieure sur les écrans de petite/moyenne taille hdpi ou moins sur les grands écrans mdpi ou moins sur les écrans très grands |
512 Mo |
832 Mo |
|
400 dpi ou plus sur les écrans de petite/moyenne taille xhdpi ou version ultérieure sur les grands écrans tvdpi ou version ultérieure sur les écrans très grands |
896 Mo |
1 280 Mo |
|
560 dpi ou plus sur les écrans de petite/moyenne taille 400 dpi ou plus sur les grands écrans xhdpi ou version ultérieure sur les écrans très grands |
1 344 Mo |
1 824 Mo |
Les valeurs de mémoire minimale DOIVENT s'ajouter à tout espace de mémoire déjà dédié à des composants matériels tels que la radio, la vidéo, etc. qui ne sont pas sous le contrôle du noyau.
Les appareils Android TV doivent disposer d'au moins 5 Go, et les autres implémentations d'appareils doivent disposer d'au moins 1,5 Go d'espace de stockage non volatile disponible pour les données privées de l'application. Autrement dit, la partition /data doit être d'au moins 5 Go pour les appareils Android TV et d'au moins 1,5 Go pour les autres implémentations d'appareils. Les implémentations d'appareils exécutant Android sont très fortement encouragées à disposer d'au moins 3 Go de stockage non volatile pour les données privées de l'application afin de pouvoir passer aux futures versions de la plate-forme.
Les API Android incluent un gestionnaire de téléchargement que les applications PEUVENT utiliser pour télécharger des fichiers de données [Ressources, 95]. L'implémentation de l'appareil du Gestionnaire de téléchargement DOIT être capable de télécharger des fichiers individuels d'au moins 100 Mo à l'emplacement par défaut du "cache".
7.6.2. Stockage partagé de l'application
Les implémentations d'appareils DOIVENT proposer un stockage partagé pour les applications, également souvent appelé "stockage externe partagé".
Les implémentations d'appareils DOIVENT être configurées avec un stockage partagé installé par défaut. Si le stockage partagé n'est pas installé sur le chemin d'accès Linux /sdcard, l'appareil DOIT inclure un lien symbolique Linux de /sdcard au point d'installation réel.
Les implémentations d'appareils PEUVENT comporter du matériel pour le stockage amovible accessible par l'utilisateur, tel qu'un emplacement pour carte Secure Digital (SD). Si ce créneau est utilisé pour répondre à l'exigence de stockage partagé, l'implémentation de l'appareil:
- DOIT implémenter une interface utilisateur de type toast ou pop-up avertissant l'utilisateur en cas d'absence de carte SD
- DOIT inclure une carte SD au format FAT de 1 Go ou plus OU indiquer sur la boîte et sur tout autre matériel disponible au moment de l'achat que la carte SD doit être achetée séparément
- DOIT installer la carte SD par défaut
Les implémentations d'appareils PEUVENT également allouer de l'espace de stockage interne (non amovible) en tant qu'espace de stockage partagé pour les applications, comme indiqué dans le projet Android Open Source en amont. Les implémentations d'appareils DOIVENT utiliser cette configuration et cette implémentation logicielle. Si une implémentation d'appareil utilise un stockage interne (non amovible) pour répondre à l'exigence de stockage partagé, ce stockage DOIT avoir une taille d'au moins 1 Go et être installé sur /sdcard (ou /sdcard DOIT être un lien symbolique vers l'emplacement physique s'il est installé ailleurs).
Les implémentations d'appareils DOIVENT appliquer l'autorisation android.permission.WRITE_EXTERNAL_STORAGE sur cet espace de stockage partagé, comme indiqué dans la documentation. Sinon, l'espace de stockage partagé DOIT être accessible en écriture par toute application qui obtient cette autorisation.
Les implémentations d'appareils qui incluent plusieurs chemins d'espace de stockage partagé (comme un emplacement pour carte SD et un espace de stockage interne partagé) DOIVENT n'autoriser que les applications Android préinstallées et privilégiées disposant de l'autorisation WRITE_EXTERNAL_STORAGE à écrire sur l'espace de stockage externe secondaire, à l'exception des répertoires spécifiques au package sur l'espace de stockage externe secondaire. Elles DOIVENT toutefois exposer le contenu des deux chemins d'espace 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, les implémentations d'appareils DOIVENT fournir un mécanisme permettant d'accéder au contenu du stockage partagé à partir d'un ordinateur hôte, tel que le stockage de masse USB (UMS) ou le protocole MTP (Media Transfer Protocol). Les implémentations d'appareils PEUVENT utiliser le stockage de masse USB, mais DOIVENT utiliser le protocole de transfert multimédia. Si l'implémentation de l'appareil est compatible avec le protocole Media Transfer, elle:
- DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer [Resources, 96]
- DOIT indiquer une classe d'appareil USB de 0x00
- DOIT indiquer un nom d'interface USB de "MTP"
Si l'implémentation de l'appareil ne comporte pas de ports USB, elle DOIT fournir à un ordinateur hôte un accès au contenu du stockage partagé par un autre moyen, tel qu'un système de fichiers réseau.
7.7. USB
Les implémentations d'appareils DOIVENT prendre en charge le mode périphérique USB et le mode hôte USB.
Si l'implémentation d'un appareil inclut un port USB compatible avec le mode périphérique:
- Le port DOIT être connectable à un hôte USB doté d'un port USB Type-A ou Type-C standard.
- Le port DOIT utiliser le facteur de forme USB micro-B, micro-AB ou Type-C. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
- Le port DOIT se trouver en bas de l'appareil (selon l'orientation naturelle) ou permettre la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), afin que l'affichage s'affiche correctement lorsque l'appareil est orienté avec le port en bas. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
- Il DOIT implémenter l'API et la spécification Android Open Accessory (AOA) comme indiqué dans la documentation du SDK Android. S'il s'agit d'un appareil Android portable, il DOIT implémenter l'API AOA. Implémentations d'appareils implémentant la spécification AOA :
- DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.accessory [Ressources, 97]
- DOIT implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android [Ressources, 98]
- Il DOIT être compatible avec la consommation d'un courant de 1,5 A pendant le chirp HS et le trafic, comme spécifié dans la spécification de recharge de la batterie USB, version 1.2 [Ressources, 99]. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
- La valeur de iSerialNumber dans le descripteur d'appareil standard USB DOIT être égale à la valeur d'android.os.Build.SERIAL.
Si une implémentation d'appareil inclut un port USB compatible avec le mode hôte:
- DOIT utiliser un port USB Type-C si l'implémentation de l'appareil est compatible avec USB 3.1
- PEUT utiliser un facteur de forme de port non standard, mais doit être fourni avec un ou plusieurs câbles permettant de l'adapter à un port USB de type A ou C standard
- PEUT utiliser un port USB micro-AB, mais si tel est le cas, DOIT être fourni avec un ou plusieurs câbles permettant d'adapter le port à un port USB Type-A ou Type-C standard
- Il est FORTEMENT RECOMMANDÉ d'implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android [Ressources, 98].
- DOIT implémenter l'API hôte USB Android comme indiqué dans le SDK Android et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.host [Ressources, 100]
- DOIT prendre en charge la plage de courant de sortie du port en aval de la recharge de 1,5 A à 5 A, comme spécifié dans la spécification de recharge de la batterie USB, version 1.2 [Ressources, 99].
7.8. Audio
7.8.1. Micro
|
Les appareils Android portables et les montres doivent impérativement 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
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 la fonctionnalité android.hardware.audio.output
- DOIVENT respecter les exigences de lecture audio de la section 5.5
- DOIT respecter les exigences de latence audio de la section 5.6
À l'inverse, si l'implémentation d'un appareil n'inclut pas de haut-parleur ni de port de sortie audio, elle NE DOIT PAS signaler la fonctionnalité de sortie android.hardware.audio et DOIT implémenter les API liées à la sortie audio en tant que no-ops au moins.
L'implémentation de l'appareil Android Watch PEUT, mais NE DOIT PAS, avoir une sortie audio. En revanche, les autres types d'implémentations d'appareils Android DOIVENT avoir une sortie audio et déclarer android.hardware.audio.output.
7.8.2.1. Ports audio analogiques
Pour être compatible avec les casques et autres accessoires audio utilisant la prise audio 3,5 mm dans l'écosystème Android [Ressources, 101], si une implémentation d'appareil inclut un ou plusieurs ports audio analogiques, au moins l'un des ports audio DOIT être un connecteur audio 3,5 mm à quatre conducteurs. Si l'implémentation d'un appareil comporte une prise audio 3,5 mm à quatre conducteurs, elle:
- DOIT être compatible avec la lecture audio sur des casques stéréo et des casques stéréo avec micro, et DOIT être compatible avec l'enregistrement audio à partir de casques stéréo avec micro
- DOIT être compatible avec les prises audio TRRS avec la disposition des broches CTIA et DOIT être compatible avec les prises audio avec la disposition des broches OMTP
- DOIT prendre en charge la détection du micro sur l'accessoire audio branché, si l'implémentation de l'appareil est compatible avec un micro, et diffuser android.intent.action.HEADSET_PLUG avec la valeur supplémentaire du micro définie sur 1
- DOIT prendre en charge la détection et le mappage sur les codes de touche pour les trois plages d'impédance équivalente suivantes entre le micro et les conducteurs de terre sur la prise audio :
- 70 ohms ou moins: KEYCODE_HEADSETHOOK
- 210 à 290 ohms: KEYCODE_VOLUME_UP
- 360 à 680 ohms: KEYCODE_VOLUME_DOWN
- DOIT prendre en charge la détection et le mappage sur le code de touche pour la plage d'impédance équivalente suivante entre le micro et les conducteurs de terre sur la prise audio :
- 110 à 180 ohms : KEYCODE_VOICE_ASSIST
- DOIT déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une prise, mais uniquement après que tous les contacts de la prise ont touché leurs segments correspondants sur la prise
- DOIT être capable de piloter au moins 150 mV +/- 10% de la tension de sortie sur une impédance d'enceinte de 32 ohms
- La tension de polarisation du micro doit être comprise entre 1,8 V et 2,9 V.
8. Compatibilité des performances
Certains critères de performances minimaux sont essentiels à l'expérience utilisateur et ont un impact sur les hypothèses de référence que les développeurs peuvent avoir lors du développement d'une application. Les appareils Android Watch DOIVENT et les autres implémentations d'appareils DOIVENT respecter les critères suivants:
8.1. Cohérence de l'expérience utilisateur
Les implémentations d'appareils DOIVENT fournir une interface utilisateur fluide en assurant un taux de rafraîchissement et des temps de réponse cohérents pour les applications et les jeux. Les implémentations d'appareils DOIVENT répondre aux exigences suivantes:
- Latence de frame cohérente : la latence de frame incohérente ou le délai de rendu des frames NE DOIT PAS se produire plus de cinq fois par seconde et DOIT être inférieur à 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 assurer la cohérence des performances d'accès aux fichiers 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 de 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 de 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 de 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 de l'appareil DOIVENT garantir des performances de lecture aléatoire de 3,5 Mo/s pour un fichier de 256 Mo à l'aide d'un tampon d'écriture de 4 ko.
9. Compatibilité des modèles de sécurité
Les implémentations d'appareils DOIVENT implémenter un modèle de sécurité conforme au modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API [Ressources, 102] dans la documentation pour les développeurs Android. Les implémentations d'appareils DOIVENT prendre en charge l'installation d'applications autosignées sans nécessiter d'autorisations/certificats supplémentaires de la part de tiers/autorités. Plus précisément, les appareils compatibles DOIVENT prendre en charge les mécanismes de sécurité décrits dans les sous-sections suivantes.
9.1. Autorisations
Les implémentations d'appareils DOIVENT prendre en charge le modèle d'autorisations Android tel que défini dans la documentation pour les développeurs Android [Ressources, 102]. 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.*.
9.2. UID et isolation des processus
Les implémentations d'appareils DOIVENT prendre en charge le modèle de bac à sable d'application Android, dans lequel chaque application s'exécute en tant qu'UID unique de style Unix et dans un processus distinct. Les implémentations d'appareils DOIVENT prendre en charge l'exécution de plusieurs applications avec le même ID utilisateur Linux, à condition que les applications soient correctement signées et construites, comme défini dans la référence sur la sécurité et les autorisations [Ressources, 102].
9.3. Autorisations du système de fichiers
Les implémentations d'appareils DOIVENT prendre en charge le modèle d'autorisations d'accès aux fichiers Android tel que défini dans la référence sur la sécurité et les autorisations [Ressources, 102].
9.4. Environnements d'exécution alternatifs
Les implémentations d'appareils PEUVENT inclure des environnements d'exécution qui exécutent des applications à l'aide d'un autre logiciel ou d'une autre technologie que le format exécutable Dalvik ou le code natif. Toutefois, ces environnements d'exécution alternatifs NE DOIVENT PAS compromettre le modèle de sécurité Android ni la sécurité des applications Android installées, comme décrit dans cette section.
Les environnements d'exécution alternatifs DOIVENT eux-mêmes être des applications Android et respecter le modèle de sécurité Android standard, comme décrit ailleurs dans la section 9.
Les environnements d'exécution alternatifs NE DOIVENT PAS être autorisés à accéder aux ressources protégées par des autorisations non demandées dans le fichier AndroidManifest.xml de l'environnement d'exécution via le
Les environnements d'exécution alternatifs NE DOIVENT PAS autoriser les applications à utiliser des fonctionnalités protégées par des autorisations Android limitées aux applications système.
Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android. Plus précisément, les environnements d'exécution alternatifs:
- DOIT installer les applications via le PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.)
- PEUT fournir un seul bac à sable Android partagé par toutes les applications utilisant l'environnement d'exécution alternatif
- et les applications installées à l'aide d'un autre environnement d'exécution NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf via les mécanismes Android standards d'ID utilisateur partagé et de certificat de signature
- NE DOIT PAS lancer avec, accorder ni être accordé à l'accès aux bacs à sable correspondant à d'autres applications Android
- NE DOIT PAS être lancé avec, être accordé ou accorder à d'autres applications des droits d'accès 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, l'environnement d'exécution DOIT lister toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement d'exécution.
9.5. Compatibilité multi-utilisateur
|
Cette fonctionnalité est facultative pour tous les types d'appareils. |
Android est compatible avec plusieurs utilisateurs et prend en charge l'isolation complète des utilisateurs [Resources, 103]. Les implémentations d'appareils PEUVENT permettre l'utilisation de plusieurs utilisateurs, mais lorsqu'elles sont activées, elles DOIVENT respecter les exigences suivantes concernant la prise en charge multi-utilisateur [Resources, 104]:
- Les implémentations d'appareils qui ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony DOIVENT prendre en charge les profils dont l'accès est limité, une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour les utilisateurs supplémentaires, et gérer des restrictions plus précises dans les applications disponibles dans ces environnements.
- À l'inverse, les implémentations d'appareils qui déclarent le flag de fonctionnalité android.hardware.telephony NE DOIVENT PAS prendre en charge les profils limités, mais DOIVENT s'aligner sur l'implémentation des commandes AOSP pour autoriser /désactiver l'accès d'autres utilisateurs aux appels vocaux et aux SMS.
- Les implémentations d'appareils DOIVENT, pour chaque utilisateur, implémenter un modèle de sécurité conforme au modèle de sécurité de la plate-forme Android tel que défini dans le document de référence sur la sécurité et les autorisations des API [Ressources, 102].
- Les implémentations d'appareils PEUVENT prendre en charge la création d'utilisateurs et de profils gérés via les API android.app.admin.DevicePolicyManager. Si elles sont prises en charge, elles DOIVENT déclarer le flag de fonctionnalité de plate-forme android.software.managed_users.
- Les implémentations d'appareils qui déclarent le flag de fonctionnalité android.software.managed_users DOIVENT utiliser le badge d'icône AOSP en amont pour représenter les applications gérées et d'autres éléments d'interface utilisateur de badge, tels que "Recents" (Éléments récents) et "Notifications".
- Chaque instance utilisateur sur un appareil Android DOIT disposer de répertoires de stockage externes distincts et isolés. Les implémentations d'appareils PEUVENT stocker les données de plusieurs utilisateurs sur le même volume ou le même système de fichiers. Toutefois, l'implémentation de l'appareil DOIT s'assurer que les applications appartenant à un utilisateur donné et exécutées en son nom ne peuvent pas lister, lire ni écrire des données appartenant à un autre utilisateur. Notez que les supports amovibles, tels que les emplacements pour cartes SD, peuvent permettre à un utilisateur d'accéder aux données d'un autre utilisateur via un PC hôte. Pour cette raison, les implémentations d'appareils qui utilisent des supports amovibles pour les API de stockage externe principales DOIVENT chiffrer le contenu de la carte SD si la multi-utilisateur est activée à l'aide d'une clé stockée uniquement sur des supports non amovibles accessibles uniquement au système. Comme cela rend les supports multimédias illisibles par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour fournir aux PC hôtes un accès aux données de l'utilisateur actuel. Par conséquent, les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS activer la multi-utilisation si elles utilisent des supports amovibles [Ressources, 105] pour le stockage externe principal.
9.6. Avertissement concernant les SMS premium
Android permet d'avertir les utilisateurs de tout message SMS sortant surtaxé [Ressources, 106] . Les SMS premium sont des messages envoyés à un service enregistré auprès d'un opérateur qui peuvent entraîner des frais pour l'utilisateur. Les implémentations d'appareils qui déclarent la prise en charge d'android.hardware.telephony DOIVENT avertir les utilisateurs avant d'envoyer un message SMS à des numéros identifiés par des expressions régulières définies dans le fichier /data/misc/sms/codes.xml de l'appareil. Le projet Android Open Source en amont fournit une implémentation qui répond à cette exigence.
9.7. Fonctionnalités de sécurité du noyau
Le bac à sable Android inclut des fonctionnalités qui utilisent le système de contrôle des accès obligatoire (MAC) Security-Enhanced Linux (SELinux) et d'autres fonctionnalités de sécurité du noyau Linux. SELinux ou toute autre fonctionnalité de sécurité implémentée sous le framework Android:
- DOIT assurer la compatibilité avec les applications existantes
- NE DOIT PAS 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, ce qui entraîne un exploit réussi
- NE DOIT PAS être configurable par l'utilisateur ou 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 répondre aux 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/un fournisseur.
- NE DOIT PAS modifier, omettre ni remplacer les règles neverallow présentes dans le dossier external/sepolicy fourni dans le projet Android Open Source (AOSP) en amont. La stratégie DOIT compiler avec toutes les règles neverallow présentes, à la fois pour les domaines SELinux AOSP et les domaines spécifiques à l'appareil/au fournisseur.
Les implémentations d'appareils DOIVENT conserver la règle SELinux par défaut fournie dans le dossier external/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 Android Open Source en amont.
9.8. Confidentialité
Si l'appareil implémente une fonctionnalité dans le système qui capture les contenus affichés à l'écran et/ou enregistre le flux audio diffusé sur l'appareil, il DOIT informer l'utilisateur en continu chaque fois que cette fonctionnalité est activée et qu'elle capture/enregistre activement.
9.9. Chiffrement complet de disque
|
Facultatif pour les implémentations d'appareils Android sans écran de verrouillage. |
Si l'implémentation de l'appareil comporte un écran de verrouillage, l'appareil DOIT prendre en charge le chiffrement de disque complet des données privées de l'application (partition /data), ainsi que la partition de la carte SD si elle fait partie permanente et non amovible de l'appareil [Resources, 107]. Pour les appareils compatibles avec le chiffrement de disque complet, le chiffrement de disque complet DOIT être activé en permanence une fois que l'utilisateur a terminé l'expérience prête à l'emploi. Bien que cette exigence soit indiquée comme "RECOMMANDÉE" pour cette version de la plate-forme Android, elle est TRÈS RECOMMANDÉE, car elle devrait passer à "OBLIGATOIRE" dans les futures versions d'Android. Le chiffrement DOIT utiliser AES avec une clé de 128 bits (ou plus) et un mode conçu pour le stockage (par exemple, AES-XTS, AES-CBC-ESSIV). La clé de chiffrement NE DOIT PAS être écrite sur le stockage à tout moment sans être chiffrée. Sauf lorsqu'elle est utilisée, la clé de chiffrement DOIT être chiffrée AES avec le code de verrouillage de l'écran étiré à l'aide d'un algorithme d'étirement lent (par exemple, PBKDF2 ou scrypt). Si l'utilisateur n'a pas spécifié de code secret pour l'écran de verrouillage ou a désactivé l'utilisation du code secret pour le chiffrement, le système DOIT utiliser un code secret par défaut pour encapsuler la clé de chiffrement. Si l'appareil fournit un keystore intégré au matériel, l'algorithme d'étirement de mot de passe DOIT être lié de manière cryptographique à ce keystore. La clé de chiffrement NE DOIT PAS être envoyée en dehors de l'appareil (même lorsqu'elle est encapsulée avec le code secret de l'utilisateur et/ou la clé liée au matériel). Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité dm-crypt du kernel Linux.
9.10. démarrage validé
Les implémentations d'appareils DOIVENT prendre en charge le démarrage validé pour l'intégrité de l'appareil. Si la fonctionnalité est prise en charge, elle DOIT déclarer le flag de fonctionnalité de plate-forme android.software.verified_boot. Bien que cette exigence soit indiquée comme "DEVOIR" pour cette version de la plate-forme Android, elle est FORTEMENT RECOMMANDÉE, car elle devrait passer à "DEVOIR" dans les futures versions d'Android. 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 kernel Linux.
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 les implémentateurs d'appareils sont très fortement encouragés à apporter le moins de modifications possible à l'implémentation de référence et privilégiée d'Android disponible dans le projet Android Open Source. Cela réduit le risque d'introduire des bugs qui créent des incompatibilités nécessitant des retouches et des mises à jour potentielles de l'appareil.
10.1. Compatibility Test Suite
Les implémentations d'appareils DOIVENT réussir les tests de la suite de compatibilité Android (CTS) [Ressources, 108] disponibles sur le projet Android Open Source, à l'aide du logiciel final fourni sur l'appareil. En outre, les implémentateurs d'appareils DOIVENT utiliser autant que possible l'implémentation de référence dans l'arborescence Open Source Android et DOIVENT assurer la compatibilité en cas d'ambiguïté dans le CTS et pour toute réimplémentation de parties du code source de référence.
Le CTS est conçu pour être exécuté sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bugs. Le CTS sera versionné indépendamment de cette définition de compatibilité, et plusieurs révisions du CTS peuvent être publiées pour Android 5.0. Les implémentations d'appareils DOIVENT réussir les tests de la dernière version de CTS disponible au moment où le logiciel de l'appareil est finalisé.
10.2. Validateur CTS
Les implémentations d'appareils DOIVENT exécuter correctement tous les cas applicables dans le vérificateur CTS. Le vérificateur CTS est inclus dans la suite de tests de compatibilité. Il est destiné à être exécuté par un opérateur humain pour tester les fonctionnalités qui ne peuvent pas être testées par un système automatisé, comme le bon fonctionnement d'une caméra et de capteurs.
Le vérificateur CTS propose des tests pour de nombreux types de matériel, y compris certains matériels facultatifs. Les implémentations d'appareils DOIVENT réussir tous les tests du matériel dont elles disposent. Par exemple, si un appareil possède un accéléromètre, il DOIT exécuter correctement le scénario de test de l'accéléromètre dans le vérificateur CTS. Les cas de test des fonctionnalités indiquées comme facultatives par ce document de définition de la compatibilité PEUVENT être ignorés ou omis.
Chaque appareil et chaque build DOIVENT exécuter correctement le vérificateur CTS, comme indiqué ci-dessus. Toutefois, comme de nombreuses versions sont très similaires, les implémentateurs d'appareils ne sont pas tenus d'exécuter explicitement le vérificateur CTS sur des versions qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui ne diffèrent d'une implémentation ayant réussi le vérificateur CTS que par l'ensemble des paramètres régionaux, de la marque, etc. PEUVENT omettre le test du vérificateur CTS.
11. Logiciels pouvant être mis à jour
Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer de mises à niveau "en direct". Autrement dit, un redémarrage de l'appareil PEUT être nécessaire.
N'importe quelle méthode peut être utilisée, à condition qu'elle puisse remplacer l'intégralité du logiciel préinstallé sur l'appareil. Par exemple, l'une des approches suivantes répond à cette exigence:
- Téléchargements Over The Air (OTA) avec mise à jour hors connexion via le 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), l'appareil DOIT prendre en charge le téléchargement Over-the-air avec mise à jour hors connexion via le redémarrage.
Le mécanisme de mise à jour utilisé DOIT être compatible avec les mises à jour sans effacer les données utilisateur. Autrement dit, le mécanisme de mise à jour DOIT préserver les données privées et les données partagées de l'application. Notez que le logiciel Android en amont inclut un mécanisme de mise à jour qui répond à cette exigence.
Pour les implémentations d'appareils lancées avec Android 5.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 des blocs dans le projet Android Open Source en amont, ajoutée depuis Android 5.0, répond à cette exigence.
Si une erreur est détectée dans l'implémentation d'un appareil après sa sortie, mais dans la durée de vie raisonnable du produit déterminée en consultation avec l'équipe de compatibilité Android, et qu'elle affecte la compatibilité des applications tierces, l'implémentateur de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible qui peut être appliquée conformément au mécanisme décrit ci-dessus.
12. Journal des modifications du document
Le tableau suivant récapitule les modifications apportées à la définition de la compatibilité dans cette version.
|
Section(s) |
Résumé des modifications |
|
1. Introduction |
Mise à jour des exigences pour faire référence à la documentation du SDK comme source d'informations. |
|
2. Types d'appareils |
Définitions incluses pour les types d'appareils pour les appareils portables, les téléviseurs et les montres. |
|
2.1 Configuration de l'appareil |
Ajout d'une liste non exhaustive pour illustrer l'écart de configuration matérielle entre les appareils. |
|
3.1. Compatibilité avec les API gérées |
DOIT également fournir des implémentations complètes des API avec le repère "@SystemApi" dans le code source Android en amont. |
|
3.2.2. Paramètres de compilation |
Ajout des paramètres SUPPORTED_ABIS, SUPPORTED_32_BIT_ABIS et SUPPORTED_64_BIT_ABIS dans la liste, modification de PRODUCT pour exiger des codes SKU de produit uniques et modification de TAGS. |
|
3.2.3.1. Intents d'application principaux |
Clarification du texte indiquant que l'exigence de compatibilité concerne principalement le modèle d'intents |
|
3.2.3.5. Paramètres de l'application par défaut |
Ajout de nouvelles exigences pour l'écran d'accueil, la technologie NFC et les applications de SMS par défaut. |
|
3.3.1 Interfaces binaires d'application |
Ajout d'exigences pour prendre en charge l'ABI 32 bits équivalente si une ABI 64 bits est prise en charge. Les paramètres ont été mis à jour pour refléter ce changement. |
|
3.4.1. Compatibilité avec WebView |
Compatibilité avec WebView requise pour tous les appareils, à l'exception des appareils Android Watch. Suppression de l'exigence de chaîne de paramètres régionaux. |
|
3.4.2. Compatibilité avec les navigateurs |
Les appareils Android TV et les montres peuvent omettre une application de navigateur, mais tous les autres types d'implémentations d'appareils DOIVENT en inclure une. |
|
3.7. Compatibilité avec l'environnement d'exécution |
Mise à jour des exigences minimales en termes de mémoire pour les applications |
|
3.8.2. Widgets |
La prise en charge des widgets est facultative pour tous les types d'appareils, mais recommandée pour les appareils portables. |
|
3.8.3. Notifications |
Définitions étendues des types de notifications compatibles. |
|
3.8.4. Recherche |
Les appareils Android TV DOIVENT inclure la recherche globale. Tous les autres types d'appareils DOIVENT. |
|
3.8.6. Thèmes |
Les appareils DOIVENT être compatibles avec le thème Material. |
|
3.8.7. Fonds d'écran animés |
Les appareils qui incluent un fond d'écran animé DOIVENT signaler le flag de fonctionnalité de plate-forme android.software.live_wallpaper. |
|
3.8.8. Changement d'activité |
Recommandation : prise en charge de la nouvelle interface utilisateur "Récents". DOIT afficher au moins le titre de quatre activités à la fois. |
|
3.8.10. Télécommande multimédia pour l'écran de verrouillage |
Abandon de l'API client de télécommande au profit du modèle de notification multimédia |
|
3.8.11. Rêves |
Facultatif pour les appareils Android Watch. Obligatoire pour tous les autres types d'appareils. |
|
3.8.13 Unicode et police |
DOIT être compatible avec Roboto 2 en plus des exigences existantes. |
|
3.12. TV Input Framework |
Les implémentations d'appareils Android TV DOIVENT être compatibles avec le Television Input Framework. |
|
5.1. Codecs multimédias |
Ajout de trois sections pour les codecs audio, image et vidéo. |
|
5.4 Enregistrement audio |
divisé en sous-sections ; |
|
5.4.1. Capture audio brute |
Caractéristiques définies pour la capture audio brute sur les appareils qui déclarent android.hardware.microphone |
|
5.5. Lecture audio |
Ajout de la section 5.5. Lecture audio avec deux sous-sections: 5.5.1 Effets audio et 5.5.2. Volume de sortie audio |
|
5.6 Latence audio |
Ajout de définitions et d'exigences pour le jitter de sortie à froid, le jitter d'entrée à froid et la latence aller-retour continue. |
|
5.8 Médias sécurisés |
Inclut les exigences concernant les contenus multimédias sécurisés à partir de la version 7.1.8. Écrans externes et exigences supplémentaires pour Android TV |
|
6.1. Outils pour les développeurs |
Ressources mises à jour. |
|
6.2.1. Version expérimentale |
Section supprimée |
|
7. Compatibilité matérielle |
Mise à jour pour indiquer que les implémentations d'appareils DOIVENT signaler de manière cohérente une configuration matérielle précise pour le même identifiant de build. |
|
7.1.1.1. Taille d'écran |
Mise à jour pour refléter la taille d'écran des appareils Android Watch et indiquer que la valeur ne peut pas changer |
|
7.1.1.2. Format d'écran |
Mise à jour pour refléter le format d'écran des appareils Android Watch (1:1). |
|
7.1.3. Orientation de l'écran |
Mise à jour pour indiquer que les appareils avec un écran en mode paysage à orientation fixe DOIVENT uniquement signaler cette orientation. |
|
7.1.4. Accélération graphique 2D et 3D |
Ajout de la mention "Peut-être" pour les appareils Android compatibles avec le pack d'extensions Android. |
|
(ancienne) 7.1.6. Types d'écrans |
Section supprimée |
|
7.1.6. Technologie d'affichage |
Le format de pixel (PAR) a été mis à jour pour être compris entre 0,9 et 1,15. (tolérance d'environ 15 %) |
|
7.1.7. Écrans externes |
Suppression d'une partie de la section et déplacement vers la section 5.8. Médias sécurisés. |
|
7.2.2. Navigation non tactile |
Les appareils Android TV DOIVENT être compatibles avec la croix directionnelle. |
|
7.2.3. Touches de navigation |
Langue incluse pour la prise en charge sur différents types d'appareils. |
|
7.2.4. Saisie par pression tactile |
Les appareils Android Watch DOIVENT être compatibles avec la saisie tactile. |
|
7.2.6. Compatibilité avec les manettes de jeu |
Ajout d'une section sur les exigences concernant Android TV. |
|
7.2.7. Télécommande |
Ajout d'une section sur les exigences concernant Android TV. |
|
7.3. Capteurs |
Redéfini les capteurs synthétiques en tant que capteurs composites et les capteurs de streaming en tant que capteurs continus. Les capteurs doivent indiquer l'heure de l'événement en nanosecondes. |
|
7.3.1. Accéléromètre |
Clarification des types de capteurs requis et révision des seuils d'exigence |
|
7.3.2. Magnétomètre |
Clarification des types de capteurs requis et révision des seuils d'exigence |
|
7.3.4. Gyroscope |
Clarification des types de capteurs requis et révision des seuils d'exigence |
|
7.3.5. Le baromètre |
Modification de la valeur "MAY" (POURRA) en "SHOULD" (DEVRA) pour l'implémentation du baromètre. DOIT implémenter et signaler le capteur TYPE_PRESSURE. |
|
7.3.6. Thermomètre |
Les appareils peuvent inclure un thermomètre ambiant. POURRA, MAIS NE DOIT PAS inclure de thermomètre de processeur. |
|
7.3.8. 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é. |
|
7.4.2. IEEE 802.11 (Wi-Fi) |
Les appareils Android TV doivent impérativement être compatibles avec le Wi-Fi. Les appareils compatibles avec le Wi-Fi doivent signaler android.hardware.wifi. |
|
7.4.2.1. Wi-Fi Direct |
DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct. |
|
7.4.2.2. Configuration du lien direct en tunnel Wi-Fi |
Les appareils Android TV DOIVENT être compatibles avec le Wi-Fi TDLS. |
|
7.5. Caméras |
Si une implémentation d'appareil inclut au moins une caméra, une application DOIT pouvoir allouer simultanément trois bitmaps égaux à la taille des images produites par le capteur d'appareil photo de la plus haute résolution de l'appareil. |
|
7.5.3. Caméras externes |
Ajout d'exigences selon lesquelles les implémentations d'appareils avec le mode hôte USB PEUVENT inclure la prise en charge d'une caméra externe. |
|
7.5.5. Fonctionnalités du système de l'appareil photo |
Ajout d'une liste des fonctionnalités de la caméra et du moment où elles doivent être définies. |
|
7.6.1. Mémoire et stockage minimums |
Mise à jour des conditions requises pour les appareils 32 bits et 64 bits. Suppression de l'exigence de mémoire SVELTE. Les appareils doivent disposer d'au moins 1,5 Go d'espace de stockage non volatile. |
|
7.6.2. Stockage partagé de l'application |
Mise à jour des exigences concernant l'espace de stockage amovible accessible par l'utilisateur |
| 7.6.2. Stockage partagé de l'application | Mise à jour des exigences concernant les applications système préinstallées pouvant écrire sur un stockage externe secondaire. |
|
7.7. USB |
Suppression des exigences concernant les ports de recharge qui doivent se trouver sur le même bord que le port micro-USB. Mise à jour des conditions requises pour le mode hôte et le mode périphérique. |
|
7.7. USB |
Correction des fautes de frappe dans la section USB. |
|
7.8.1. Audio |
Déplacement de la section sur le micro ici. Ajout d'exigences pour les ports de sortie audio et analogiques. |
|
8. Compatibilité des performances |
Ajout d'exigences concernant la cohérence de l'interface utilisateur. |
|
9.5. Compatibilité multi-utilisateur |
La prise en charge multi-utilisateur est facultative pour tous les types d'appareils. Exigences détaillées par type d'appareil dans la section. |
|
9.5. Compatibilité multi-utilisateur |
Chiffrement de la carte SD requis pour le stockage externe principal. |
|
9.7. Fonctionnalités de sécurité du noyau |
PEUT avoir une interface utilisateur visible lorsqu'une violation de sécurité non bloquée se produit, ce qui entraîne un exploit réussi. Aucun domaine en mode permissif n'est autorisé. |
|
9.9. Chiffrement complet de disque |
Les appareils dotés d'un écran de verrouillage DOIVENT prendre en charge le chiffrement de disque complet. Pour les nouveaux appareils, le chiffrement de disque complet doit être activé dès la sortie de l'usine. |
|
9.10 Démarrage validé |
Ajout d'une section recommandant que les implémentations d'appareils prennent en charge le démarrage validé pour l'intégrité de l'appareil. |
|
10.3. Applications de référence |
Section supprimée du CDD. |
|
11. Logiciels pouvant être mis à jour |
Si un appareil est compatible avec le profil 802.11 ou le profil Bluetooth PAN (Personal Area Network), il DOIT prendre en charge le téléchargement Over-the-air avec la mise à jour hors connexion via le redémarrage. |
|
14. Ressources |
Ressources déplacées de la section 2 vers la section 14 |
13. Nous contacter
Vous pouvez rejoindre le forum de compatibilité Android [Ressources, 109] et demander des précisions ou soulever les problèmes que vous pensez que le document ne couvre pas.
14. Ressources
1. Niveaux d'exigences de la norme IETF RFC 2119: http://www.ietf.org/rfc/rfc2119.txt
2. Projet Android Open Source: http://source.android.com/
3. Fonctionnalités Android Television: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK
4. Fonctionnalité Android Watch: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH
5. Définitions et documentation des API: http://developer.android.com/reference/packages.html
6. Documentation de référence sur les autorisations Android: http://developer.android.com/reference/android/Manifest.permission.html
7. Documentation de référence android.os.Build: http://developer.android.com/reference/android/os/Build.html
8. Chaînes de version autorisées pour Android 5.0: http://source.android.com//docs/compatibility/5.0/versions
9. Fournisseur de téléphonie: http://developer.android.com/reference/android/provider/Telephony.html
10. Émulation de carte basée sur l'hôte: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
11. Android Extension Pack: http://developer.android.com/guide/topics/graphics/opengl.html#aep
12. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
13. Compatibilité avec WebView: http://www.chromium.org/
14. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
15. Fonctionnalités hors connexion HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
16. Balise vidéo HTML5: http://dev.w3.org/html5/spec/Overview.html#video
17. API de géolocalisation HTML5/W3C: http://www.w3.org/TR/geolocation-API/
18. API Webstorage HTML5/W3C: http://www.w3.org/TR/webstorage/
19. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
20. Format Dalvik Executable et spécification du bytecode: disponible dans le code source Android, à l'adresse dalvik/docs
21. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
22. Notifications: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
23. Ressources d'application: https://developer.android.com/guide/topics/resources/available-resources.html
24. Guide de style des icônes de la barre d'état: http://developer.android.com/design/style/iconography.html
25. Ressources sur les notifications: https://developer.android.com/design/patterns/notifications.html
26. Gestionnaire de recherche: http://developer.android.com/reference/android/app/SearchManager.html
27. Toasts: http://developer.android.com/reference/android/widget/Toast.html
28. Thèmes: http://developer.android.com/guide/topics/ui/themes.html
29. Classe R.style: http://developer.android.com/reference/android/R.style.html
30. Material Design: http://developer.android.com/reference/android/R.style.html#Theme_Material
31. Fonds d'écran animés: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html
32. Ressources sur l'écran "Vue d'ensemble" : http://developer.android.com/guide/components/recents.html
33. Épinglage d'écran: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning
34. Modes de saisie: http://developer.android.com/guide/topics/text/creating-input-method.html
35. Notification multimédia: https://developer.android.com/reference/android/app/Notification.MediaStyle.html
36. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html
37. Settings.Secure LOCATION_MODE:
http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE
38. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/
39. Android Device Administration: http://developer.android.com/guide/topics/admin/device-admin.html
40. Documentation DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
41. Application Android Device Owner:
42. API Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html
43. API d'accessibilité Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html
44. Projet Eyes Free: http://code.google.com/p/eyes-free
45. API Text-to-Speech: http://developer.android.com/reference/android/speech/tts/package-summary.html
46. Television Input Framework: /devices/tv/index.html
47. Documentation de référence des outils (pour adb, aapt, ddms et systrace): http://developer.android.com/guide/developing/tools/index.html
48. Description du fichier APK Android: http://developer.android.com/guide/components/fundamentals.html
49. Fichiers manifestes: http://developer.android.com/guide/topics/manifest/manifest-intro.html
50. Formats multimédias Android: http://developer.android.com/guide/appendix/media-formats.html
51. Exigences de codage matériel RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/
52. API AudioEffect: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html
53. Classe Android android.content.pm.PackageManager et liste des fonctionnalités matérielles:
http://developer.android.com/reference/android/content/pm/PackageManager.html
54. Draft Protocol HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
55. ADB: http://developer.android.com/tools/help/adb.html
56. Dumpsys: https://developer.android.com/studio/command-line/dumpsys.html
57. DDMS: http://developer.android.com/tools/debugging/ddms.html
58. Outil de test du singe: http://developer.android.com/tools/help/monkey.html
59. Outil Systrace: http://developer.android.com/tools/help/systrace.html
60. Paramètres liés au développement d'applications Android:
61. Compatibilité avec plusieurs écrans: http://developer.android.com/guide/practices/screens_support.html
62. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
63. RenderScript: http://developer.android.com/guide/topics/renderscript/
64. Pack d'extensions Android pour OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html
65. Accélération matérielle: http://developer.android.com/guide/topics/graphics/hardware-accel.html
66. Extension EGL-EGL_ANDROID_RECORDABLE:
http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt
67. Gestionnaire d'affichage: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
68. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
69. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
70. Configuration de la saisie tactile: http://source.android.com/docs/core/interaction/input/touch-devices
71. API Motion Event: http://developer.android.com/reference/android/view/MotionEvent.html
72. API Key Event: http://developer.android.com/reference/android/view/KeyEvent.html
73. Capteurs Open Source Android: http://source.android.com/docs/core/interaction/sensors
74. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
75. Événement de capteur avec code temporel: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp
76. Capteurs composites Open Source Android: http://source.android.com/devices/sensors/composite_sensors.html
77. Mode de déclenchement continu: http://source.android.com/devices/sensors/base_triggers.html#continuous
78. Capteur d'accéléromètre: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER
79. API Wi-Fi Multicast: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
80. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
81. API WifiManager: http://developer.android.com/reference/android/net/wifi/WifiManager.html
82. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html
83. API Bluetooth ScanFilter: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html
84. Protocole NDEF Push: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
85. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html
86. Paramètres de partage NFC Android:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
87. Transfert de connexion NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover
88. Bluetooth Secure Simple Pairing Using NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf
89. Résolveur de contenu: http://developer.android.com/reference/android/content/ContentResolver.html
90. API d'orientation de l'appareil photo: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
91. Caméra: http://developer.android.com/reference/android/hardware/Camera.html
92. Caméra: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
93. Niveau matériel de l'appareil photo: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL
94. Compatibilité avec les versions de l'appareil photo: http://source.android.com/docs/core/camera/versioning
95. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html
96. Android File Transfer: http://www.android.com/filetransfer
97. Accessoires Android Open: http://developer.android.com/guide/topics/usb/accessory.html
98. Audio USB Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
99. Spécification de recharge de la batterie USB, version 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip
100. API USB Host: http://developer.android.com/guide/topics/usb/host.html
101. Casque audio filaire: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec
102. Documentation de référence sur la sécurité et les autorisations Android: http://developer.android.com/guide/topics/security/permissions.html
103. Documentation de référence sur UserManager: http://developer.android.com/reference/android/os/UserManager.html
104. Référence sur le stockage externe: http://source.android.com/docs/core/storage
105. API de stockage externe: http://developer.android.com/reference/android/os/Environment.html
106. Code court SMS: http://en.wikipedia.org/wiki/Short_code
107. Chiffrement Open Source Android: http://source.android.com/devices/tech/encryption/index.html
108. Présentation du programme de compatibilité Android: http://source.android.com/docs/compatibility
109. Forum sur la compatibilité Android: https://groups.google.com/forum/#!forum/android-compatibility
110. Projet WebM: http://www.webmproject.org/
Bon nombre de ces ressources sont dérivées directement ou indirectement du SDK Android et sont fonctionnellement identiques aux informations de la documentation de ce SDK. Dans tous les cas où cette définition de la compatibilité ou la suite de tests de compatibilité ne sont pas conformes à la documentation du SDK, la documentation du SDK est considérée comme faisant autorité. Tous les détails techniques fournis dans les références ci-dessus sont considérés comme faisant partie de cette définition de compatibilité.