Définition de compatibilité Android 4.4

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Révision 1
Dernière mise à jour: 27 novembre 2013

Copyright © 2013, 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 4.4.

L'utilisation des mots "doit", "ne doit pas", "requis", "doit", "ne doit pas", "doit", "ne doit pas", "recommandé", "peut" et "facultatif" est conforme à la norme IETF définie dans la RFC 2119 [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 4.4. 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 4.4, les implémentations d'appareils DOIVENT respecter les exigences présentées dans cette définition de 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, 3] est à la fois l'implémentation de référence et 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 suite de tests de compatibilité. Enfin, notez que certaines substitutions et modifications de composants sont explicitement interdites par ce document.

2. Ressources

1. Niveaux d'exigences de la norme IETF RFC 2119: http://www.ietf.org/rfc/rfc2119.txt
2. Présentation du programme de compatibilité Android: http://source.android.com/docs/compatibility/index.html
3. Projet Android Open Source: http://source.android.com/
4. Définitions et documentation des API: http://developer.android.com/reference/packages.html
5. Documentation de référence sur les autorisations Android: http://developer.android.com/reference/android/Manifest.permission.html
6. Documentation de référence sur android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. Chaînes de version autorisées pour Android 4.4: http://source.android.com/docs/compatibility/4.4/versions.html
8. Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html
9. Accélération matérielle: http://developer.android.com/guide/topics/graphics/hardware-accel.html
10. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12. Fonctionnalités hors connexion HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13. Balise vidéo HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14. API de géolocalisation HTML5/W3C: http://www.w3.org/TR/geolocation-API/
15. API Webstorage HTML5/W3C: http://www.w3.org/TR/webstorage/
16. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
17. Spécification de la machine virtuelle Dalvik: disponible dans le code source Android, à l'adresse dalvik/docs
18. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19. Notifications: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20. Ressources d'application: http://code.google.com/android/reference/available-resources.html
21. Guide de style des icônes de la barre d'état: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22. Gestionnaire de recherche: http://developer.android.com/reference/android/app/SearchManager.html
23. Toasts: http://developer.android.com/reference/android/widget/Toast.html
24. Thèmes: http://developer.android.com/guide/topics/ui/themes.html
25. Classe R.style: http://developer.android.com/reference/android/R.style.html
26. Fonds d'écran animés: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
27. Android Device Administration: http://developer.android.com/guide/topics/admin/device-admin.html
28. Documentation DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29. API Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/package-summary.html
30. API d'accessibilité Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html
31. Projet Eyes Free: http://code.google.com/p/eyes-free
32. API Text-to-Speech: http://developer.android.com/reference/android/speech/tts/package-summary.html
33. Documentation de référence des outils (pour adb, aapt, ddms et systrace): http://developer.android.com/guide/developing/tools/index.html
34. Description du fichier APK Android: http://developer.android.com/guide/topics/fundamentals.html
35. Fichiers manifestes: http://developer.android.com/guide/topics/manifest/manifest-intro.html
36. Outil de test du singe: https://developer.android.com/studio/test/other-testing-tools/monkey
37. Classe android.content.pm.PackageManager et liste des fonctionnalités matérielles Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
38. Compatibilité avec plusieurs écrans: http://developer.android.com/guide/practices/screens_support.html
39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
40. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
41. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
42. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html
43. Protocole NDEF Push: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
49. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
50. API d'orientation de l'appareil photo: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51. Caméra: http://developer.android.com/reference/android/hardware/Camera.html
52. Accessoires Android Open: http://developer.android.com/guide/topics/usb/accessory.html
53. API USB Host: http://developer.android.com/guide/topics/usb/host.html
54. Documentation de référence sur la sécurité et les autorisations Android: http://developer.android.com/guide/topics/security/permissions.html
55. Applications pour Android: http://code.google.com/p/apps-for-android
56. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html
57. Android File Transfer: http://www.android.com/filetransfer
58. Formats multimédias Android: http://developer.android.com/guide/appendix/media-formats.html
59. Draft Protocol HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
60. Transfert de connexion NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover
61. Bluetooth Secure Simple Pairing Using NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62. API Wi-Fi Multicast: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
63. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64. Spécification de recharge USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65. Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66. Audio USB Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67. Paramètres de partage NFC Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69. Widget de l'écran de verrouillage et de l'écran d'accueil: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html
70. Documentation de référence sur UserManager: http://developer.android.com/reference/android/os/UserManager.html
71. Référence sur le stockage externe: /docs/core/storage
72. API de stockage externe: http://developer.android.com/reference/android/os/Environment.html
73. Code court SMS: http://en.wikipedia.org/wiki/Short_code
74. Client de contrôle à distance multimédia: http://developer.android.com/reference/android/media/RemoteControlClient.html
75. Gestionnaire d'affichage: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
76. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html
77. Paramètres liés au développement d'applications Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS
78. Caméra: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
79. Extension EGL-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt
80. API Motion Event: http://developer.android.com/reference/android/view/MotionEvent.html
81. Configuration de l'entrée tactile: http://source.android.com/docs/core/interaction/input/touch-devices.html
82. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/
83. Compatibilité avec WebView: http://www.chromium.org/
84. Application Android Device Owner: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)
85. API WifiManager: http://developer.android.com/reference/android/net/wifi/WifiManager.html
86. Exigences de codage matériel RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/
87. Settings.Secure LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE
88. Résolveur de contenu: http://developer.android.com/reference/android/content/ContentResolver.html
89. SettingInjectorService: http://developer.android.com/reference/android/location/SettingInjectorService.html
90. Émulation de carte basée sur l'hôte: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
91. Fournisseur de téléphonie: http://developer.android.com/reference/android/provider/Telephony.html

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

3. Logiciel

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

L'environnement d'exécution géré (basé sur Dalvik) 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 de VM 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, 4].

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. Consultez la section 7 pour connaître les exigences spécifiques à ce scénario.

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'éléments tels que les intents, les autorisations et les 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, 5]. 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 sur la classe android.os.Build [Resources, 6] qui sont destinées à décrire l'appareil actuel. Pour fournir des valeurs cohérentes et significatives 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	Commentaires
VERSION.RELEASE	Version du système Android actuellement en cours d'exécution, au format lisible. Ce champ DOIT contenir l'une des valeurs de chaîne définies dans [Ressources, 7].
VERSION.SDK	Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 4.4, ce champ DOIT avoir la valeur entière 19.
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 4.4, ce champ DOIT avoir la valeur entière 19.
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 qu'il est 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.,_-]+$".
CPU_ABI	Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Consultez la section 3.3: Compatibilité des API natives.
CPU_ABI2	Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Consultez la section 3.3: Compatibilité des 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 suivre ce modèle : $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Par exemple : acme/myproduct/mydevice:4.4/KRT16/3359:userdebug/test-keys L'empreinte ne DOIT PAS inclure de caractères d'espace. Si d'autres champs inclus dans le modèle ci-dessus contiennent des caractères d'espacement, ils DOIVENT être remplacés dans l'empreinte de compilation par un autre caractère, tel que le trait de soulignement ("_"). La valeur de ce champ DOIT être encodable en ASCII 7 bits.
MATÉRIEL	Nom du matériel (à partir de la ligne de commande du kernel ou de /proc). Il DOIT être raisonnablement lisible par l'humain. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9.,_-]+$".
ORGANISATEUR	Chaîne qui identifie de manière unique l'hôte sur lequel le build a été créé, au format lisible par l'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'humain. 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 contenir la chaîne vide ("").
PRODUIT	Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code du produit spécifique (code SKU) qui DOIT être unique au sein de la même marque. DOIT être lisible par l'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 balises choisies par l'implémentateur de l'appareil, séparées par une virgule, qui permet de distinguer davantage le build. Par exemple, "unsigned,debug". La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9.,_-]+$".
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". La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9.,_-]+$".
UTILISATEUR	Nom ou ID utilisateur de l'utilisateur (ou de l'utilisateur automatique) qui a généré le build. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").

3.2.3. Compatibilité des intents

Les implémentations d'appareils DOIVENT respecter le système d'intents à 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, et qui se lie à chaque modèle d'intent spécifié et implémente un comportement correct.

3.2.3.1. Intents d'application principaux

Le projet Android upstream définit un certain nombre d'applications de base, telles que les contacts, l'agenda, la galerie photo, le lecteur de musique, etc. Les implémentateurs d'appareils PEUVENT remplacer ces applications par d'autres versions.

Toutefois, ces versions alternatives DOIVENT respecter les mêmes modèles d'intent fournis par le projet en amont. Par exemple, si un appareil contient un autre lecteur de musique, il doit toujours respecter le modèle d'intent émis par les applications tierces pour sélectionner un titre.

Les applications suivantes sont considérées comme des applications système Android principales:

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

Les applications système Android de base incluent divers composants Activity ou Service considérés comme "publics". Autrement dit, l'attribut "android:exported" peut être absent ou avoir la valeur "true".

Pour chaque activité ou service définie dans l'une des applications système Android principales qui n'est pas marquée comme non publique via un attribut android:exported avec la valeur "false", les implémentations d'appareil DOIVENT inclure un composant du même type implémentant les mêmes modèles de filtre d'intent que l'application système Android principale.

En d'autres termes, une implémentation d'appareil PEUT remplacer les applications système Android principales. Toutefois, si elle le fait, l'implémentation de l'appareil DOIT prendre en charge tous les modèles d'intent définis par chaque application système Android principale remplacée.

3.2.3.2. Forçages d'intents

Comme 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 l'un des 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'intents 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 4.4 ajoute des paramètres permettant aux utilisateurs de sélectionner leurs applications d'accueil et de SMS par défaut. Les implémentations d'appareils DOIVENT fournir un menu de paramètres utilisateur similaire pour chacun, compatible avec le modèle de filtre d'intent et les méthodes d'API décrites dans la documentation du SDK [Ressources, 91].

3.3. Compatibilité avec les API natives

3.3.1 Interfaces binaires d'application

Le code géré exécuté dans Dalvik 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. Comme 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, dans le fichier docs/CPU-ARCH-ABIS.html. Si une implémentation d'appareil est compatible avec une ou plusieurs ABI définies, elle DOIT implémenter la compatibilité avec le NDK Android, comme indiqué ci-dessous.

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

• DOIT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler le code natif, à l'aide de la sémantique standard de Java Native Interface (JNI)
• DOIT être compatible avec la source (c'est-à-dire avec l'en-tête) et avec le binaire (pour l'ABI) avec chaque bibliothèque requise de la liste ci-dessous
• DOIT signaler avec précision l'interface binaire d'application (ABI) native compatible avec l'appareil, via l'API android.os.Build.CPU_ABI et les paramètres android.os.Build.CPU_ABI2.
• DOIT signaler, via android.os.Build.CPU_ABI2, uniquement les ABI documentées dans la dernière version du NDK Android, dans le fichier docs/CPU-ARCH-ABIS.html
• DOIT signaler, via android.os.Build.CPU_ABI, un seul des ABI listés ci-dessous
• armeabi-v7a
• x86
• mips
• 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.0)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.0)
• 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)
• 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 ABI.

Notez que les implémentations d'appareils DOIVENT inclure libGLESv3.so et DOIVENT associer un lien symbolique (symbolique) à libGLESv2.so. Sur les implémentations d'appareils qui déclarent la prise en charge d'OpenGL ES 3.0, libGLESv2.so DOIT exporter les symboles de fonction OpenGL ES 3.0 en plus des symboles de fonction OpenGL ES 2.0.

La compatibilité du code natif est difficile. C'est pourquoi nous rappelons que les implémentateurs d'appareils sont TRÈS fortement encouragés à utiliser les implémentations en amont des bibliothèques listées ci-dessus pour assurer la compatibilité.

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

L'implémentation Open Source d'Android utilise le code du projet Chromium pour implémenter android.webkit.WebView [Resources, 10] . É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 Open Source Android en amont pour Android 4.4. Cette version inclut un ensemble spécifique de fonctionnalités et de correctifs de sécurité pour WebView. [Ressources, 83]
• La chaîne user-agent signalée par la WebView DOIT être au format suivant:
  Mozilla/5.0 (Linux; Android $(VERSION); $(LOCALE); $(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 de android.os.Build.VERSION.RELEASE.
  • La valeur de la chaîne $(LOCALE) est facultative. Elle DOIT respecter les conventions ISO pour le code pays et la langue, et DOIT faire référence aux paramètres régionaux configurés actuellement sur l'appareil. Si cette option est omise, le point-virgule final DOIT également être supprimé.
  • La valeur de la chaîne $(MODEL) DOIT être identique à celle de android.os.Build.MODEL.
  • La valeur de la chaîne $(BUILD) DOIT être identique à celle de 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 de l'agent utilisateur.

Le composant WebView DOIT être compatible avec autant que possible de fonctionnalités HTML5 [Ressources, 11].

3.4.2. Compatibilité avec les navigateurs

Les 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 HTML5 [Ressources, 11]. 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 [Resources, 12]
• la balise <video> [Ressources, 13]
• géolocalisation [Ressources, 14]

De plus, les implémentations d'appareils DOIVENT être compatibles avec l'API WebStorage HTML5/W3C [Ressources, 15] et DEVRAIENT être compatibles avec l'API IndexedDB HTML5/W3C [Ressources, 16]. 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, 3]. Voici quelques domaines de compatibilité spécifiques:

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

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

3.6. Espaces de noms d'API

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

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

Les modifications interdites incluent les suivantes:

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

Un "élément exposé publiquement" est 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 mécanisme <uses-library>) soient affectées par l'augmentation de l'utilisation de la mémoire de ces API.

Si un implémentateur d'appareil propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple, en ajoutant une nouvelle fonctionnalité utile à une API existante ou en ajoutant une nouvelle API), il DOIT 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é des machines virtuelles

Les implémentations d'appareils DOIVENT être compatibles avec la spécification complète du bytecode Dalvik Executable (DEX) et la sémantique de la machine virtuelle Dalvik [Resources, 17].

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

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.

Taille de l'écran	Densité de l'écran	Mémoire de l'application
petite / normale / grande	ldpi / mdpi	16 Mo
petite / normale / grande	tvdpi / hdpi	32 Mo
petite / normale / grande	xhdpi	64 Mo
petite / normale / grande	400 dpi	96 Mo
petite / normale / grande	xxhdpi	128 Mo
petite / normale / grande	xxxhdpi	256 Mo
xlarge	mdpi	32 Mo
xlarge	tvdpi / hdpi	64 Mo
xlarge	xhdpi	128 Mo
xlarge	400 dpi	192 Mo
xlarge	xxhdpi	256 Mo
xlarge	xxxhdpi	512 Mo

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur (écran d'accueil)

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

3.8.2. Widgets

Android définit un type de composant, ainsi qu'une API et un cycle de vie correspondants, qui permettent aux applications d'exposer un "AppWidget" à l'utilisateur final [Resources, 18]. 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 compatibilité avec la fonctionnalité de plate-forme android.software.app_widgets.

• Les lanceurs d'appareils DOIVENT inclure une prise en charge intégrée des AppWidgets et exposer des affordances d'interface utilisateur 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 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, 18].
• Les implémentations d'appareils qui prennent en charge l'écran de verrouillage DOIVENT prendre en charge les widgets d'application sur l'écran de verrouillage.

3.8.3. Notifications

Android inclut des API qui permettent aux développeurs d'informer les utilisateurs d'événements notables [Ressources, 19], à 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. Notez que 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, 20] ou dans le guide de style des icônes de la barre d'état/système [Ressources, 21]. 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 les notifications enrichies, telles que les vues interactives pour les notifications en cours. Les implémentations d'appareils DOIVENT afficher et exécuter correctement les notifications enrichies, comme indiqué dans les API Android.

3.8.4. Recherche

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

Les implémentations d'appareils DOIVENT inclure 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 DOIVENT implémenter les API qui permettent aux applications tierces d'ajouter des suggestions au champ de recherche lorsqu'il est exécuté en mode recherche globale. Si aucune application tierce utilisant cette fonctionnalité n'est installée, le comportement par défaut DOIT être l'affichage des résultats et des suggestions du moteur de recherche Web.

3.8.5. Notifications toast

Les applications peuvent utiliser l'API "Toast" (définie dans [Resources, 23]) pour afficher de courtes chaînes non modales à l'utilisateur final, qui disparaissent après une courte période. 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, 24]. Les implémentations d'appareils NE DOIVENT PAS modifier les attributs du thème Holo exposés aux applications [Resources, 25].

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 d'appareils PEUVENT modifier les attributs de thème DeviceDefault exposés aux applications [Resources, 25].

À partir de la version 4.4, Android est désormais 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 la barre de navigation avec le contenu de leur application. Pour offrir une expérience de développement cohérente dans cette configuration, il est important que le style des icônes de la barre d'état soit conservé 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, 25].

3.8.7. Fonds d'écran animés

Android définit un type de composant, ainsi qu'une API et un cycle de vie correspondants, qui permettent aux applications d'exposer un ou plusieurs "fonds d'écran animés" à l'utilisateur final [Resources, 26]. 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é, à un débit 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 Open GL 1.0 ou 2.0 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. Les implémentations d'appareils déterminées à ne pas exécuter de fonds d'écran animés de manière fiable, comme décrit ci-dessus, NE DOIVENT PAS implémenter de fonds d'écran animés.

3.8.8. Affichage des applications récentes

Le code source Android en amont inclut une interface utilisateur permettant d'afficher les applications récentes à 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 PEUVENT modifier ou supprimer cette interface utilisateur. Toutefois, une future version d'Android est prévue pour exploiter davantage cette fonctionnalité. Les implémentations d'appareils sont fortement encouragées à utiliser l'interface utilisateur Android en amont (ou une interface basée sur des miniatures similaire) pour les applications récentes, sinon elles risquent de ne pas être compatibles avec une future version d'Android.

3.8.9. Gestion des entrées

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

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

3.8.10. Télécommande multimédia pour l'écran de verrouillage

Android est compatible avec l'API Remote Control, qui permet aux applications multimédias de s'intégrer aux commandes de lecture affichées dans une vue à distance, comme l'écran de verrouillage de l'appareil [Resources, 74]. Les implémentations d'appareils compatibles avec l'écran de verrouillage de l'appareil et permettant aux utilisateurs d'ajouter des widgets sur l'écran d'accueil DOIVENT inclure la prise en charge de l'intégration de commandes à distance sur l'écran de verrouillage de l'appareil [Resources, 69].

3.8.11. Rêves

Android est compatible avec les écrans de veille interactifs appelés "Dreams" [Resources, 76]. Dreams permet aux utilisateurs d'interagir avec des applications lorsqu'un appareil en charge est inactif ou posé sur un socle. Les implémentations d'appareils DOIVENT être compatibles avec Dreams et fournir une option de paramètres permettant aux utilisateurs de configurer Dreams.

3.8.12. Position

Les modes de localisation DOIVENT s'afficher dans le menu "Position" des paramètres [Ressources, 87]. Les services de localisation fournis via SettingInjectorService, introduit dans Android 4.4, doivent s'afficher dans le même menu "Position" [Resources, 89].

3.8.13. Unicode

Android 4.4 est compatible avec les caractères emoji en couleur. Les implémentations d'appareils Android DOIVENT fournir à l'utilisateur un mode de saisie pour les caractères emoji définis dans Unicode 6.1 [Ressources, 82] et DOIVENT être capables d'afficher ces caractères emoji en glyphes de couleur.

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux applications axées sur la sécurité d'effectuer des fonctions d'administration d'appareils au niveau du système, telles que l'application de stratégies de mot de passe ou l'effacement à distance, via l'API Android Device Administration [Resources, 27]. Les implémentations d'appareils DOIVENT fournir une implémentation de la classe DevicePolicyManager [Ressources, 28]. Les implémentations d'appareils qui incluent la prise en charge de l'écran de verrouillage DOIVENT prendre en charge l'ensemble des stratégies d'administration des appareils définies dans la documentation du SDK Android [Ressources, 27].

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, 84].

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, 29]. Les implémentations d'appareils DOIVENT fournir une implémentation du framework d'accessibilité Android conforme à l'implémentation Android par défaut. Plus précisément, les implémentations d'appareils DOIVENT respecter les exigences suivantes.

• Les implémentations d'appareils DOIVENT prendre en charge les implémentations de services d'accessibilité tiers via les API android.accessibilityservice [Ressources, 30].
• Les implémentations d'appareils DOIVENT générer AccessibilityEvents et transmettre ces événements à toutes les implémentations AccessibilityService enregistrées de manière cohérente avec l'implémentation Android par défaut.
• 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.

De plus, 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, 31].

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 TTS [Resources, 32]. Les implémentations d'appareils DOIVENT respecter les exigences suivantes concernant le framework TTS Android:

• Les implémentations d'appareils DOIVENT être compatibles avec les API du framework TTS Android et DOIVENT 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.
• Les implémentations d'appareils DOIVENT prendre en charge l'installation de moteurs TTS tiers.
• Les implémentations d'appareils DOIVENT fournir une interface accessible aux utilisateurs qui leur permet de sélectionner un moteur TTS à utiliser au niveau du système.

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 [Ressources, 33].

Les implémentations d'appareils NE DOIVENT PAS étendre les formats .apk [Ressources, 34], Android Manifest [Ressources, 35], bytecode Dalvik [Ressources, 17] ou bytecode renderscript de manière à empêcher l'installation et l'exécution correcte de ces fichiers sur d'autres appareils compatibles. Les implémentateurs d'appareils DOIVENT utiliser l'implémentation en amont de référence de Dalvik et le système de gestion des paquets de l'implémentation de référence.

5. Compatibilité multimédia

Les implémentations d'appareils DOIVENT inclure au moins une forme de sortie audio, comme des haut-parleurs, une prise casque, une connexion à des haut-parleurs externes, etc.

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, 58], 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 ne sont pas soumis à des 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.

Notez que ces tableaux ne répertorient pas les exigences de débit spécifiques pour la plupart des codecs vidéo, car le matériel de l'appareil actuel n'est pas nécessairement compatible avec les débits qui correspondent exactement aux débits requis spécifiés par les normes applicables. Au lieu de cela, les implémentations d'appareils DOIVENT prendre en charge le débit le plus élevé possible sur le matériel, jusqu'aux limites définies par les spécifications.

Type	Format / Codec	Encodeur	Décodeur	Détails	Type(s) de fichier/Formats de conteneur
Audio	Profil MPEG-4 AAC (AAC LC)	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de micro et définissent android.hardware.microphone.	REQUIRED	Compatibilité avec les contenus mono/stéréo/5.0/5.1* avec des taux d'échantillonnage standards de 8 à 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC brut ADTS (.aac, décodage sous Android 3.1 et versions ultérieures, encodage sous Android 4.0 et versions ultérieures, ADIF non pris en charge) MPEG-TS (.ts, non accessible, Android 3.0 ou version ultérieure)
	Profil MPEG-4 HE AAC (AAC+)	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de micro et définissent android.hardware.microphone	REQUIRED	Compatibilité avec les contenus mono/stéréo/5.0/5.1* avec des taux d'échantillonnage standards de 16 à 48 kHz.
	Profil MPEG-4 HE AAC v2 (AAC+ amélioré)		REQUIRED	Compatibilité avec les contenus mono/stéréo/5.0/5.1* avec des taux d'échantillonnage standards de 16 à 48 kHz.
	Type d'objet audio MPEG-4 ER AAC ELD (AAC à faible latence amélioré)	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de micro et définissent android.hardware.microphone	REQUIRED	Compatibilité avec le contenu mono/stéréo avec des taux d'échantillonnage standards de 16 à 48 kHz.
	AMR-NB	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de micro et définissent android.hardware.microphone.	REQUIRED	4,75 à 12,2 kbit/s échantillonnés à 8 kHz	3GPP (.3gp)
	AMR-WB	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de micro et définissent android.hardware.microphone.	REQUIRED	9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz	3GPP (.3gp)
	FLAC		OBLIGATOIRE (Android 3.1 ou version ultérieure)	Mono/Stéréo (pas de multicanaux) Taux d'échantillonnage jusqu'à 48 kHz (mais jusqu'à 44,1 kHz est 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 ; pas de dither appliqué pour 24 bits.	FLAC (.flac) uniquement
	MP3		REQUIRED	Mono/Stéréo 8-320 kbit/s CBR (débit constant) ou VBR (débit variable)	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)
	PCM/WAVE	REQUIRED	REQUIRED	PCM linéaire 8 bits et 16 bits** (taux jusqu'à la limite du matériel). Les appareils DOIVENT prendre en charge les taux d'échantillonnage pour l'enregistrement PCM brut aux fréquences 8 000,16 000 et 44 100 Hz.	WAVE (.wav)
Image	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)
Vidéo	H.263	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de caméra et définissent android.hardware.camera ou android.hardware.camera.front.	REQUIRED		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de caméra et définissent android.hardware.camera ou android.hardware.camera.front.	REQUIRED	Profil de référence (PR)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, audio AAC uniquement, non accessible par recherche, Android 3.0 et versions ultérieures)
	MPEG-4 SP		REQUIRED		3GPP (.3gp)
	VP8****	OBLIGATOIRE (Android 4.3 ou version ultérieure)	OBLIGATOIRE (Android 2.3.3 ou version ultérieure)		WebM (.webm) et Matroska (.mkv, Android 4.0 et versions ultérieures)***
	VP9		OBLIGATOIRE (Android 4.4 ou version ultérieure)		WebM (.webm) et Matroska (.mkv, Android 4.0 et versions ultérieures)***

• *Remarque: Seul le downmix du contenu 5.0/5.1 est obligatoire. L'enregistrement ou le rendu de plus de deux canaux est facultatif.
• **Remarque: La capture PCM linéaire 16 bits est obligatoire. La capture PCM linéaire 8 bits n'est pas obligatoire.
• ***Remarque: Les implémentations d'appareils DOIVENT prendre en charge l'écriture de fichiers WebM Matroska.
• ****Remarque: Pour une qualité acceptable du streaming vidéo Web et des services de visioconférence, les implémentations d'appareils DOIVENT utiliser un codec VP8 matériel qui répond aux exigences de [Ressources, 86].

5.2. Encodage vidéo

Les implémentations d'appareils Android qui incluent une caméra arrière et déclarent android.hardware.camera DOIVENT prendre en charge les profils d'encodage vidéo H.264 suivants.

	SD (basse qualité)	SD (haute qualité)	HD (si le matériel est compatible)
Résolution vidéo	176 x 144 px	480 x 360 px	1 280 x 720 px
Fréquence d'images de la vidéo	12 fps	30 ips	30 ips
Débit vidéo	56 kbit/s	500 kbit/s ou plus	2 Mbit/s ou plus
Codec audio	AAC-LC	AAC-LC	AAC-LC
Chaînes audio	1 (mono)	2 (stéréo)	2 (stéréo)
Débit audio	24 kbit/s	128 Kbits/s	192 kbit/s

Les implémentations d'appareils Android qui incluent une caméra arrière et déclarent android.hardware.camera DOIVENT prendre en charge les profils d'encodage vidéo VP8 suivants

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

5.3. Décodage vidéo

Les implémentations d'appareils Android DOIVENT prendre en charge les profils de décodage vidéo VP8, VP9 et H.264 suivants. Les implémentations d'appareils DOIVENT également prendre en charge le changement dynamique de la résolution vidéo dans le même flux pour les codecs VP8, VP9 et H.264.

	SD (basse qualité)	SD (haute qualité)	HD 720p (si le matériel est compatible)	HD 1080p (si le matériel est compatible)
Résolution vidéo	320 x 180 px	640 x 360 px	1 280 x 720 px	1 920 x 1 080 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	800 Kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.4. Enregistrement audio

Lorsqu'une application a utilisé l'API android.media.AudioRecord pour commencer à enregistrer un flux audio, les implémentations d'appareils qui incluent du matériel de micro et déclarent android.hardware.microphone DOIVENT échantillonner et enregistrer l'audio avec chacun de ces comportements:

• L'appareil DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence à peu près plates, en particulier ±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.
• Le taux de distorsion harmonique totale DOIT être inférieur à 1% pour 1 kHz à un niveau d'entrée de 90 dB SPL.

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:

• Le traitement de réduction du bruit, le cas échéant, DOIT être désactivé.
• Le contrôle automatique du gain, le cas échéant, DOIT être désactivé.

À partir d'Android 4.4, la classe android.media.MediaRecorder.AudioSource dispose d'une nouvelle source audio: REMOTE_SUBMIX. Les appareils 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

Remarque:Bien que certaines des exigences décrites ci-dessus soient indiquées comme "DOIT" depuis Android 4.3, la définition de compatibilité d'une future version devrait les remplacer par "DOIT". Autrement dit, ces exigences sont facultatives dans Android 4.4, mais elles seront obligatoires dans une prochaine version. Les appareils existants et nouveaux exécutant Android sont très fortement encouragés à respecter ces exigences, sinon ils ne pourront pas atteindre la compatibilité Android lors de la mise à niveau vers la future version.

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

• La "latence de sortie" est définie comme l'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.
• La "latence de sortie à froid" est définie comme la latence de sortie du premier frame, lorsque le système de sortie audio était inactif et éteint avant la requête.
• La "latence de sortie continue" est définie comme la latence de sortie pour les images suivantes, une fois que l'appareil diffuse déjà du contenu audio.
• La "latence d'entrée" correspond à l'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 encodées PCM.
• La "latence d'entrée à froid" est définie comme la 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 a été inactif et éteint avant la requête.
• La "latence d'entrée continue" est définie comme la latence d'entrée pour les images suivantes, lorsque l'appareil capture déjà l'audio.
• "API OpenSL ES PCM buffer queue" est l'ensemble des API OpenSL ES liées au PCM dans le NDK Android. Consultez NDK_root/docs/opensles/index.html.

Conformément à la section 5, toutes les implémentations d'appareils compatibles DOIVENT inclure au moins une forme de sortie audio. Les implémentations d'appareils DOIVENT respecter ou dépasser ces exigences de latence de sortie:

• Latence de sortie à froid de 100 millisecondes ou moins
• une latence de sortie continue de 45 millisecondes ou moins

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. [Ressources, 37] À 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.

Conformément à la section 7.2.5, le matériel du micro peut être omis par les implémentations d'appareils.

Les implémentations d'appareils qui incluent du matériel de micro et déclarent android.hardware.microphone DOIVENT répondre à ces exigences de latence audio d'entrée:

• une latence d'entrée à froid de 100 millisecondes ou moins
• une latence d'entrée continue de 50 millisecondes ou moins ;

5.6. 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, 58]. Plus précisément, les appareils DOIVENT prendre en charge les protocoles réseau multimédias suivants:

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

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

6.1. Outils pour les développeurs

Les implémentations d'appareils DOIVENT être compatibles avec les outils de développement Android fournis dans le SDK Android. Plus précisément, les appareils Android doivent être compatibles avec les éléments suivants:

• Android Debug Bridge (connu sous le nom d'adb) [Ressources, 33]
  Les implémentations d'appareils DOIVENT prendre en charge toutes les fonctions adb, comme indiqué dans le SDK Android. Le daemon adb côté appareil DOIT être inactif par défaut, et un mécanisme accessible par l'utilisateur DOIT être disponible pour activer Android Debug Bridge.
• Android est compatible avec adb sécurisé. adb sécurisé active adb sur les hôtes authentifiés connus. Les implémentations d'appareils DOIVENT être compatibles avec adb sécurisé.
• Service de surveillance du débogage Dalvik (ddms) [Ressources, 33]
  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 ci-dessus.
• Monkey [Ressources, 36]
  Les implémentations d'appareils DOIVENT inclure le framework Monkey et le mettre à la disposition des applications.
• SysTrace [Ressources, 33]
  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 SDK Android standards, sans assistance supplémentaire. Toutefois, les systèmes Microsoft Windows nécessitent généralement un pilote pour les nouveaux appareils Android. (Par exemple, les nouveaux ID de fournisseur et parfois les nouveaux ID d'appareil nécessitent des pilotes USB personnalisés pour les systèmes Windows.) Si une implémentation d'appareil n'est pas reconnue par l'outil adb fourni dans le SDK Android standard, les implémentateurs d'appareils DOIVENT fournir des pilotes Windows permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb. Ces pilotes DOIVENT être fournis pour Windows XP, Windows Vista, Windows 7 et Windows 8, en versions 32 bits et 64 bits.

6.2. Options pour les développeurs

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

6.2.1. Version expérimentale

Android 4.4 introduit ART, un environnement d'exécution Android expérimental, accessible en version Preview dans le menu "Options pour les développeurs". Les implémentations d'appareils DOIVENT inclure ART (libart.so) et prendre en charge le double démarrage à partir des options pour les développeurs, mais DOIVENT conserver Dalvik (libdvm.so) comme environnement d'exécution par défaut.

7. Compatibilité matérielle

Si un appareil inclut un composant matériel particulier qui dispose d'une API correspondante pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android. Si une API du SDK interagit avec un composant matériel déclaré comme facultatif et que l'implémentation de l'appareil ne 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ésentes.
• 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 cela est autorisé par la documentation du SDK.
• Les méthodes d'API DOIVENT renvoyer des implémentations sans opération de classes pour lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.
• Les méthodes d'API NE DOIVENT PAS générer d'exceptions non documentées par la documentation du SDK.

L'API Telephony est un exemple typique de scénario où ces exigences s'appliquent: même sur les appareils autres que les téléphones, ces API doivent être implémentées en tant que no-ops raisonnables.

Les implémentations d'appareils DOIVENT fournir des informations de configuration matérielle précises via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) de la classe android.content.pm.PackageManager. [Ressources, 37]

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, 38]. Les appareils DOIVENT implémenter correctement ces API et ces comportements, comme indiqué dans cette section.

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

• La "taille diagonale physique" correspond à la distance en pouces entre deux coins opposés de la partie éclairée de l'écran.
• "ppp" (points par pouce) correspond au 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 être compris dans la plage.
• Le "format" correspond au 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".
• Un "pixel indépendant de la densité" ("dp") est l'unité de pixel virtuel normalisée à un écran de 160 ppp, calculée comme suit : pixels = dps * (density / 160).

7.1.1. Configuration de l'écran

Taille d'écran

Le framework d'UI Android est compatible avec différentes tailles d'écran et permet aux applications 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 [Ressources, 38] 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").
• 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, la diagonale de l'écran des appareils doit mesurer au moins 6,3 cm.

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

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

Format d'écran

Le format DOIT être compris entre 1,3333 (4:3) et 1,86 (environ 16:9).

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 signaler l'une des densités logiques du framework Android suivantes via les API android.util.DisplayMetrics et DOIVENT exécuter des applications à cette densité standard.

• 120 PPP (ldpi)
• 160 PPP, également appelé "mdpi"
• 213 ppp (également appelé "tvdpi")
• 240 ppp, également appelé "hdpi"
• 320 PPP (également appelé "xhdpi")
• 400 ppp (400 dpi)
• 480 ppp (également appelé "xxhdpi")
• 640 ppp, également appelé "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 signalé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 des valeurs correctes pour toutes les métriques d'affichage définies dans android.util.DisplayMetrics [Ressources, 39].

7.1.3. Orientation de l'écran

Les appareils DOIVENT prendre en charge 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.

Les appareils DOIVENT indiquer les orientations d'écran compatibles (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIVENT indiquer au moins une orientation compatible. Par exemple, un appareil 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.

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 sur les appareils compatibles avec OpenGL ES 3.0. Les implémentations d'appareils DOIVENT également prendre en charge Android Renderscript, comme indiqué dans la documentation du SDK Android [Ressources, 8].

Les implémentations d'appareils DOIVENT également s'identifier correctement comme étant compatibles avec OpenGL ES 1.0, OpenGL ES 2.0 ou OpenGL ES 3.0. 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++ (c'est-à-dire celles 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 compatibilité avec OpenGL ES 3.0 DOIVENT être compatibles avec les API gérées OpenGL ES 3.0 et inclure la compatibilité avec les API C/C++ natives. Sur les implémentations d'appareils qui déclarent la prise en charge d'OpenGL ES 3.0, libGLESv2.so DOIT exporter les symboles de fonction OpenGL ES 3.0 en plus des symboles de fonction OpenGL ES 2.0.

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, elles 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émentations d'appareils pour implémenter un format de compression de texture spécifique. Toutefois, ils DOIVENT signaler avec précision tous les formats de compression de texture qu'ils prennent en charge, via la méthode getString() de l'API OpenGL.

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

Sous Android 4.4, 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, 9].

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

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

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. Types d'écrans

Les écrans d'implémentation de l'appareil sont classés en deux types:

• Implémentations d'écrans à pixels fixes: l'écran est un seul panneau qui n'accepte qu'une seule largeur et hauteur de pixel. En règle générale, l'écran est physiquement intégré à l'appareil. Il peut s'agir, par exemple, de téléphones mobiles, de tablettes, etc.
• Implémentations d'écran à pixels variables: l'implémentation de l'appareil n'a pas d'écran intégré et inclut un port de sortie vidéo tel que VGA, HDMI ou un port sans fil pour l'affichage, ou dispose d'un écran intégré pouvant modifier les dimensions des pixels. Exemples : téléviseurs, boîtiers décodeurs, etc.

Implémentations d'appareils à pixels fixes

Les implémentations d'appareils à pixels fixes PEUVENT utiliser des écrans de toutes dimensions de pixels, à condition qu'ils répondent aux exigences définies dans cette définition de compatibilité.

Les implémentations à pixels fixes PEUVENT inclure un port de sortie vidéo à utiliser avec un écran externe. Toutefois, si cet écran est utilisé pour exécuter des applications, l'appareil DOIT répondre aux exigences suivantes:

• L'appareil DOIT indiquer la même configuration d'écran et les mêmes métriques d'affichage, comme indiqué dans les sections 7.1.1 et 7.1.2, que l'écran à pixels fixes.
• L'appareil DOIT indiquer la même densité logique que l'écran à pixels fixes.
• L'appareil DOIT indiquer des dimensions d'écran identiques ou très proches de celles de l'écran à pixels fixes.

Par exemple, une tablette de 7 pouces de diagonale avec une résolution de 1 024 x 600 pixels est considérée comme une implémentation d'affichage mdpi de grande taille à pixels fixes. S'il contient un port de sortie vidéo qui affiche en 720p ou 1080p, l'implémentation de l'appareil DOIT mettre à l'échelle la sortie afin que les applications ne soient exécutées que dans une grande fenêtre mdpi, que l'écran à pixels fixes ou le port de sortie vidéo soit utilisé ou non.

Implémentations d'appareils à pixels variables

Les implémentations d'appareils à pixels variables DOIVENT prendre en charge au moins l'une des résolutions 1 280 x 720, 1 920 x 1 080 ou 3 840 x 2 160 (720p, 1080p ou 4K). Les implémentations d'appareils avec des écrans à pixels variables NE DOIVENT PAS prendre en charge d'autres configurations ou modes d'écran. Les implémentations d'appareils avec des écrans à pixels variables PEUVENT modifier la configuration ou le mode de l'écran au moment de l'exécution ou du démarrage. Par exemple, un utilisateur d'un décodeur peut remplacer un écran 720p par un écran 1080p, et l'implémentation de l'appareil peut s'ajuster en conséquence.

De plus, les implémentations d'appareils à pixels variables DOIVENT signaler les buckets de configuration suivants pour ces dimensions de pixel:

• 1 280 x 720 (également appelé 720p) : taille d'écran "grande", densité "tvdpi" (213 ppp)
• 1 920 x 1 080 (également appelé 1080p) : taille d'écran "grande", densité "xhdpi" (320 dpi)
• 3 840 x 2 160 (également appelé 4K) : taille d'écran "grande", densité "xxxhdpi" (640 ppp)

Pour plus de clarté, les implémentations d'appareils avec des dimensions de pixel variables sont limitées à 720p, 1080p ou 4K sous Android 4.4, et DOIVENT être configurées pour signaler les tailles d'écran et les plages de densité, comme indiqué ci-dessus.

7.1.7. 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. Plus spécifiquement :

• 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,1. Autrement dit, le format de pixel DOIT être proche du carré (1,0) avec une tolérance de 10 %.

7.1.8. É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 Display Manager, comme décrit dans la documentation du SDK Android [Ressources, 75]. 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. Plus précisément, les implémentations d'appareils qui déclarent être compatibles avec Display.FLAG_SECURE DOIVENT être compatibles avec HDCP 2.x ou version ultérieure pour les écrans sans fil Miracast ou HDCP 1.2 ou version ultérieure pour les écrans filaires. 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.

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

7.2.1. Clavier

Implémentations de l'appareil:

• DOIT inclure la prise en charge du framework de gestion des entrées (qui permet aux développeurs tiers de créer des moteurs de gestion des entrées, c'est-à-dire des claviers virtuels), comme indiqué sur http://developer.android.com
• DOIT fournir au moins une implémentation de clavier virtuel (que le clavier physique soit présent ou non)
• 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, 40] (c'est-à-dire QWERTY ou 12 touches)

7.2.2. Navigation non tactile

Implémentations de l'appareil:

• PEUT omettre une option de navigation non tactile (c'est-à-dire un trackball, un pavé directionnel ou une roue)
• DOIT indiquer la valeur correcte pour android.content.res.Configuration.navigation [Resources, 40]
• 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 Android en amont inclut un mécanisme de sélection adapté aux appareils qui ne disposent pas d'entrées de navigation non tactiles.

7.2.3. Touches de navigation

Les fonctions Accueil, Récents et Retour sont essentielles au paradigme de navigation Android. Les implémentations d'appareils DOIVENT mettre ces fonctions à la disposition de l'utilisateur en permanence lors de l'exécution d'applications. 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 prend en charge 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.

Les fonctions "Retour" et "Récents" DOIVENT comporter un bouton ou une icône visible, sauf si elles sont masquées avec d'autres fonctions de navigation en mode plein écran. La fonction d'accueil 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.

La fonction Menu est obsolète depuis Android 4.0 et a été remplacée par la barre d'action. Les implémentations d'appareils NE DOIVENT PAS implémenter de bouton physique dédié pour la fonction Menu. 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:

• Pour un appareil lancé avec Android 4.4, le bouton à développer d'action doit s'afficher dans la barre d'action lorsque celle-ci est visible et que le pop-up du menu à développer d'action qui en résulte n'est pas vide.
• Pour un appareil existant lancé avec une version antérieure, mais mis à niveau vers Android 4.4, le bouton de menu à développer doit s'afficher dans la barre d'action lorsque la barre d'action est visible et que le pop-up du menu à développer d'action qui en résulte n'est pas vide.
• NE DOIT PAS modifier la position du pop-up à développer d'action affiché en sélectionnant le bouton à développer dans la barre d'action.
• PEUT afficher le pop-up de débordement d'action à une position modifiée sur l'écran lorsqu'il s'affiche en sélectionnant le bouton de menu physique.

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

Android est compatible avec l'action d'assistance [Resources, 63]. Les implémentations d'appareils DOIVENT mettre l'action d'assistance à la disposition de l'utilisateur en permanence 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 des gestes, mais DOIT être accessible en 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 à disposition une partie de l'écran pour les applications qui répondent aux exigences définies dans la section 7.1.1.
• Les implémentations d'appareils DOIVENT afficher les touches de navigation lorsque les applications ne spécifient pas de mode d'interface utilisateur 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" (par exemple, atténué) discret 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 pression tactile

Les implémentations d'appareils DOIVENT comporter un système d'entrée par 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 au pointeur, elle NE DOIT PAS signaler la constante de fonctionnalité android.hardware.touchscreen ou android.hardware.faketouch. Implémentations d'appareils qui incluent un système de saisie par pointeur:

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

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

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

7.2.5. Saisie tactile simulée

Implémentations d'appareils qui déclarent la compatibilité avec android.hardware.faketouch

• DOIT indiquer les positions X et Y absolues de l'emplacement du pointeur et afficher un pointeur visuel à l'écran [Ressources, 80]
• DOIT signaler l'événement tactile avec le code d'action [Resources, 80] qui spécifie le changement d'état qui se produit lorsque le pointeur passe à down ou up à l'écran [Resources, 80]
• DOIT être compatible avec les pointeurs down et up sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler l'appui sur un objet à l'écran
• DOIT prendre en charge le pointeur down, le pointeur up, le pointeur down, puis le pointeur up 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, 80]
• DOIT prendre en charge le pointeur down sur un point arbitraire de l'écran, le déplacement du pointeur vers un autre point arbitraire de l'écran, suivi d'un pointeur up, ce qui permet aux utilisateurs d'émuler un glissement tactile
• DOIT prendre en charge le pointeur down, puis permettre aux utilisateurs de déplacer rapidement l'objet vers une autre position à l'écran, puis le pointeur up à l'écran, ce qui permet aux utilisateurs de lancer un objet à l'écran

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

7.2.6. 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 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 fonctionnalité android.hardware.microphone
• DOIT respecter les exigences de qualité audio de la section 5.4
• DOIT respecter les exigences de latence audio de la section 5.5

7.3. Capteurs

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

• DOIT indiquer avec précision la présence ou l'absence de capteurs selon la classe android.content.pm.PackageManager. [Ressources, 37]
• 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 (c'est-à-dire métriques) appropriées pour chaque type de capteur, comme défini dans la documentation du SDK Android [Ressources, 41]

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android doit être considéré comme faisant autorité.

Certains types de capteurs sont synthétiques, 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.

Android inclut une notion de capteur "streaming", qui renvoie des données en continu, et non seulement lorsque les données changent. Les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques pour toute API indiquée par la documentation du SDK Android comme étant un capteur de streaming. Notez que les implémentations de l'appareil DOIVENT s'assurer que le flux de capteurs ne doit pas empêcher le processeur de l'appareil de passer en état de suspension ou de se réveiller à partir d'un état de suspension.

7.3.1. Accéléromètre

Les implémentations d'appareils DOIVENT inclure un accéléromètre à trois axes. Si une implémentation d'appareil inclut un accéléromètre à trois axes, elle:

• DOIT pouvoir envoyer des événements à 120 Hz ou plus. Notez que, bien que la fréquence de l'accéléromètre ci-dessus soit indiquée comme "DOIT" pour Android 4.4, la définition de compatibilité d'une future version prévoit de la remplacer par "DOIT". Autrement dit, ces normes sont facultatives dans Android, mais elles seront obligatoires dans les futures versions. Les appareils existants et nouveaux exécutant Android sont très fortement encouragés à respecter ces exigences dans Android afin de pouvoir passer aux futures versions de la plate-forme.
• DOIT respecter le système de coordonnées des capteurs Android tel que décrit dans les API Android (voir [Ressources, 41])
• DOIT être capable de mesurer de la chute libre jusqu'à deux fois la gravité (2 g) ou plus sur n'importe quel vecteur tridimensionnel
• Doit avoir une précision d'au moins 8 bits
• La déviation standard doit être inférieure ou égale à 0,05 m/s².

7.3.2. Magnétomètre

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

• DOIT pouvoir envoyer des événements à 10 Hz ou plus
• DOIT respecter le système de coordonnées des capteurs Android tel que décrit dans les API Android (voir [Ressources, 41]).
• DOIT être capable d'échantillonner une plage de champs magnétiques adaptée pour couvrir le champ géomagnétique
• Doit avoir une précision d'au moins 8 bits
• La déviation standard doit être inférieure ou égale à 0,5 µT.

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 (c'est-à-dire un 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 être compensé en température.
• DOIT être capable de mesurer les changements d'orientation jusqu'à 5,5*Pi radians/seconde (soit environ 1 000 degrés par seconde).
• DOIT pouvoir envoyer des événements à 200 Hz ou plus. Notez que bien que la fréquence du gyroscope ci-dessus soit indiquée comme "DOIT" pour Android 4.4, la définition de compatibilité d'une future version prévoit de la remplacer par "DOIT". Autrement dit, ces normes sont facultatives dans Android, mais elles seront obligatoires dans les futures versions. Les appareils existants et nouveaux exécutant Android sont très vivement encouragés à répondre à ces exigences afin de pouvoir passer aux futures versions de la plate-forme.
• Doit avoir une précision de 12 bits ou plus
• DOIT avoir une variance ne dépassant pas 1e-7 rad² / s² par Hz (variance par Hz, ou rad² / s). La variance peut varier avec le taux d'échantillonnage, mais doit être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyro à un taux d'échantillonnage de 1 Hz, elle ne doit pas dépasser 1e-7 rad²/s².
• DOIVENT comporter des codes temporels aussi proches que possible du moment où l'événement matériel s'est produit. La latence constante doit être supprimée.

7.3.5. Le baromètre

Les implémentations d'appareils PEUVENT inclure un baromètre (c'est-à-dire un capteur de pression atmosphérique ambiante). Si une implémentation d'appareil inclut un baromètre, elle:

• 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 (c'est-à-dire un 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 (c'est-à-dire un capteur de lumière ambiante).

7.3.8. Capteur de proximité

Les implémentations d'appareils PEUVENT 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. Si une implémentation d'appareil est équipée d'un capteur de proximité, elle 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 à l'aide du même réseau. En d'autres termes, les fonctionnalités et API de "téléphonie" Android font spécifiquement référence aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir de messages SMS NE DOIVENT PAS signaler la fonctionnalité "android.hardware.telephony" ni ses sous-fonctionnalités, que 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 une implémentation d'appareil inclut la téléphonie GSM ou CDMA, elle DOIT implémenter une compatibilité complète avec l'API de cette technologie. Les implémentations d'appareils qui n'incluent pas de matériel de téléphonie DOIVENT implémenter les API complètes en tant que no-ops.

7.4.2. IEEE 802.11 (Wi-Fi)

Les implémentations d'appareils Android DOIVENT prendre en charge une ou plusieurs formes de 802.11 (b/g/a/n, etc.). Si une implémentation d'appareil inclut la prise en charge de la norme 802.11, elle DOIT implémenter l'API Android correspondante.

Les implémentations d'appareils DOIVENT implémenter l'API multicast comme décrit dans la documentation du SDK [Ressources, 62]. Les implémentations d'appareils qui incluent la compatibilité Wi-Fi DOIVENT prendre en charge le DNS multicast (mDNS). Les implémentations d'appareils NE DOIVENT 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 le Wi-Fi direct, elle DOIT implémenter l'API Android correspondante, comme décrit dans la documentation du SDK [Ressources, 68]. Si l'implémentation d'un appareil est compatible avec le Wi-Fi direct, elle:

• 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 DOIVENT prendre en charge la configuration du lien direct en tunnel Wi-Fi (TDLS) comme décrit dans la documentation du SDK Android [Ressources, 85]. Si l'implémentation d'un appareil inclut la prise en charge de TDLS et que TDLS est activé par l'API WiFiManager, l'appareil:

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

7.4.3. Bluetooth

Les implémentations d'appareils DOIVENT inclure un émetteur-récepteur Bluetooth. Les implémentations d'appareils qui incluent un émetteur-récepteur Bluetooth DOIVENT activer l'API Bluetooth basée sur RFCOMM, comme décrit dans la documentation du SDK, et déclarer la fonctionnalité matérielle android.hardware.bluetooth [Ressources, 42]. Les implémentations d'appareils DOIVENT implémenter les profils Bluetooth pertinents, tels que A2DP, AVRCP, OBEX, etc., en fonction de l'appareil.

Les implémentations d'appareils qui incluent la prise en charge du Bluetooth GATT (profil d'attribut générique) pour permettre la communication avec des appareils Bluetooth Smart ou Smart Ready DOIVENT activer l'API Bluetooth basée sur GATT comme décrit dans la documentation du SDK et déclarer la fonctionnalité matérielle android.hardware.bluetooth_le [Ressources, 42].

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, elle:

• DOIT signaler la fonctionnalité android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature(). [Ressources, 37]
• 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 du 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 les normes NFC ci-dessous sont indiquées comme "DEVRAIENT". La définition de la compatibilité d'une future version prévoit de les remplacer par "DOIT". Autrement dit, ces normes sont facultatives dans cette version, mais elles seront obligatoires dans les versions futures. Les appareils existants et nouveaux exécutant cette version d'Android sont très vivement encouragés à 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, 43]
  • SNEP 1.0 (défini par le forum NFC)
• DOIT inclure la prise en charge d'Android Beam [Ressources, 65]:
  • 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.
  • Les implémentations d'appareils DOIVENT respecter l'intent android.settings.NFCSHARING_SETTINGS pour afficher les paramètres de partage NFC [Ressources, 67].
  • DOIT implémenter le serveur NPP. Les messages reçus par le serveur NPP DOIVENT être traités de la même manière que le serveur par défaut SNEP.
  • DOIT implémenter un client SNEP et tenter d'envoyer un NDEF P2P sortant au serveur SNEP par défaut lorsque la fonctionnalité Android Beam est activée. Si aucun serveur SNEP par défaut n'est trouvé, le client DOIT essayer 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
  • DOIT prendre en charge le transfert de la connexion NFC vers le Bluetooth lorsque l'appareil est compatible avec le profil Bluetooth Object Push. Les implémentations d'appareils doivent prendre en charge le transfert de connexion vers le Bluetooth lorsque vous utilisez android.nfc.NfcAdapter.setBeamPushUris, en implémentant les spécifications "Connection Handover version 1.2" [Resources, 60] et "Bluetooth Secure Simple Pairing Using NFC version 1.0" [Resources, 61] du NFC Forum. Une telle implémentation DOIT implémenter le service LLCP de transfert avec le nom de service "urn:nfc:sn:handover" pour échanger les enregistrements de requête/sélection de transfert via NFC, et DOIT utiliser le profil Bluetooth Object Push Profile pour le transfert de données Bluetooth. Pour des raisons d'ancienneté (pour rester compatible avec les appareils Android 4.1), l'implémentation DOIT toujours accepter les requêtes GET SNEP pour échanger la requête de transfert/sélectionner des enregistrements via NFC. Toutefois, une implémentation elle-même NE DOIT PAS envoyer de requêtes GET SNEP pour effectuer la passation de connexion.
• DOIT interroger toutes les technologies compatibles en mode découverte NFC.
• DOIT être en mode découverte NFC lorsque l'appareil est actif, que l'écran est actif et que l'écran de verrouillage est déverrouillé.

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

Android 4.4 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, 90]

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

• MIFARE Classic (NXP MF1S503x [Ressources, 44], MF1S703x [Ressources, 45])
• MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 47])
• NDEF sur MIFARE Classic (NXP AN130511 [Resources, 48], AN130411 [Resources, 49])

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 le SDK Android
• DOIT signaler la fonctionnalité com.nxp.mifare à partir de la méthode android.content.pm.PackageManager.hasSystemFeature(). [Resources, 37] 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 à partir de la méthode android.content.pm.PackageManager.hasSystemFeature() [Ressources, 37] 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, 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 maître doit être activé par défaut pour les implémentations d'appareils afin que la méthode getMasterSyncAutomatically() renvoie "true" [Resources, 88].

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.

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 une caméra arrière, elle:

• Doit avoir une résolution d'au moins 2 mégapixels
• Le pilote de l'appareil photo DOIT implémenter la mise au point automatique matérielle ou logicielle (transparente pour le logiciel d'application).
• POURRAIENT être équipés d'un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF)
• POURRA inclure un flash. Si la caméra 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 une caméra avant:

• 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. Autrement dit, l'API de l'appareil photo d'Android est compatible avec les caméras avant spécifiques, et les implémentations d'appareils NE DOIVENT PAS configurer l'API pour traiter une caméra avant comme la caméra arrière par défaut, même si elle est la seule caméra de l'appareil.
• PEUVENT 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, 50], l'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application.
• Sinon, l'aperçu DOIT être mis en miroir le long de l'axe horizontal par défaut de l'appareil.
• DOIT refléter l'image affichée par le postview de la même manière que le flux d'images d'aperçu de la caméra. (Si l'implémentation de l'appareil n'est pas compatible avec la postview, cette exigence ne s'applique évidemment pas.)
• NE DOIT PAS refléter les flux d'images fixes ou vidéo capturés renvoyés aux rappels d'application ou enregistrés dans le stockage multimédia

7.5.3. Comportement de l'API Camera

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées aux caméras, à la fois pour les caméras avant et arrière:

1. 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.
2. 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 de byte[] transmises à onPreviewFrame() doivent également être au format d'encodage NV21. Autrement dit, NV21 DOIT être la valeur par défaut.
3. Les implémentations d'appareils DOIVENT prendre en charge le format YV12 (comme indiqué par la constante android.graphics.ImageFormat.YV12) pour les aperçus de l'appareil photo, à la fois pour les caméras avant et arrière. (L'encodeur vidéo matériel et la caméra peuvent utiliser n'importe quel format de pixel natif, mais l'implémentation de l'appareil DOIT prendre en charge la conversion en YV12.)

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

Les implémentations d'appareils DOIVENT reconnaître et respecter chaque nom de paramètre défini en tant que constante sur 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 de l'appareil NE DOIVENT PAS respecter ni reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters(), à l'exception de 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 caméra Camera.SCENE_MODE_HDR [Resources, 78].

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 store multimédia.

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

7.5.4. 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 implémentations d'appareils DOIVENT disposer d'au moins 340 Mo de mémoire disponible pour le noyau et l'espace utilisateur. Les 340 Mo doivent s'ajouter à toute mémoire dédiée aux composants matériels tels que la radio, la vidéo, etc. qui ne sont pas sous le contrôle du noyau.

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

Les implémentations d'appareils DOIVENT disposer d'au moins 1 Go d'espace de stockage non volatile pour les données privées de l'application. Autrement dit, la partition /data doit être d'au moins 1 Go. Les implémentations d'appareils exécutant Android sont très vivement encouragées à disposer d'au moins 2 Go de stockage non volatile pour les données privées de l'application afin qu'elles puissent passer aux futures versions de la plate-forme.

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

7.6.2. Stockage externe partagé

Les implémentations d'appareils DOIVENT proposer un espace de stockage partagé pour les applications. L'espace de stockage partagé fourni doit être d'au moins 1 Go.

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 DOIVENT appliquer l'autorisation android.permission.WRITE_EXTERNAL_STORAGE sur ce stockage partagé, comme indiqué dans la documentation. Sinon, le stockage partagé DOIT être accessible en écriture par toute application qui obtient cette autorisation.

Les implémentations d'appareils PEUVENT comporter du matériel pour le stockage amovible accessible par l'utilisateur, comme une carte Secure Digital. 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. Le projet Open Source Android en amont inclut une implémentation qui utilise l'espace de stockage interne de l'appareil pour les API de stockage externe partagé. Les implémentations d'appareils DOIVENT utiliser cette configuration et cette implémentation logicielle.

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 de transfert multimédia:

• L'implémentation de l'appareil DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer [Resources, 57].
• L'implémentation de l'appareil DOIT indiquer une classe d'appareil USB de 0x00.
• L'implémentation de l'appareil 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.

Prenons deux exemples courants pour illustrer ce point. Si l'implémentation d'un appareil inclut un port de carte SD pour répondre à l'exigence de stockage partagé, une carte SD au format FAT d'une taille d'au moins 1 Go DOIT être incluse avec l'appareil tel qu'il est vendu aux utilisateurs et DOIT être montée par défaut. Si une implémentation d'appareil utilise un stockage fixe interne pour répondre à cette exigence, 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 qui incluent plusieurs chemins de stockage partagés (tels qu'un emplacement pour carte SD et un stockage interne partagé) NE DOIVENT PAS autoriser les applications Android à écrire sur le stockage externe secondaire, à l'exception de leurs répertoires spécifiques au package sur le stockage externe secondaire, mais DOIVENT exposer le contenu des deux chemins de stockage de manière transparente via le service de numérisation multimédia d'Android et android.provider.MediaStore.

7.7. USB

Les implémentations d'appareils DOIVENT inclure un port client USB et un port hôte USB.

Si une implémentation d'appareil inclut un port client USB:

• Le port DOIT être connectable à un hôte USB doté d'un port USB-A standard.
• Le port DOIT utiliser le facteur de forme micro USB sur le côté de l'appareil. Les appareils existants et nouveaux exécutant Android sont très fortement encouragés à respecter ces exigences dans Android afin de pouvoir passer aux futures versions de la plate-forme.
• Le port DOIT être centré au milieu d'un bord. Les implémentations d'appareils DOIVENT placer le port en bas de l'appareil (selon l'orientation naturelle) ou activer 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. Nous recommandons vivement aux appareils existants et nouveaux exécutant Android de répondre à ces exigences dans Android afin qu'ils puissent passer aux futures versions de la plate-forme.
• Si l'appareil comporte d'autres ports (tels qu'un port de recharge autre qu'USB), ils DOIVENT se trouver sur le même bord que le port micro-USB.
• Il DOIT permettre à un hôte connecté à l'appareil d'accéder au contenu du volume de stockage partagé à l'aide de la mémoire de stockage de masse USB ou du protocole Media Transfer Protocol.
• Il DOIT implémenter l'API et la spécification Android Open Accessory comme indiqué dans la documentation du SDK Android, et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.accessory [Ressources, 52].
• Il DOIT implémenter la classe audio USB comme indiqué dans la documentation du SDK Android [Ressources, 66].
• Il DOIT prendre en charge la spécification de recharge de la batterie USB [Ressources, 64]. Les appareils existants et nouveaux exécutant Android sont très fortement encouragés à répondre à ces exigences pour pouvoir passer aux futures versions de la plate-forme.
• La valeur de iSerialNumber dans le descripteur d'appareil standard USB DOIT être égale à celle d'android.os.Build.SERIAL.

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

• Il peut utiliser un facteur de forme de port non standard, mais dans ce cas, il doit être fourni avec un ou plusieurs câbles permettant d'adapter le port à un port USB-A standard.
• Il 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, 53].

Les implémentations d'appareils DOIVENT implémenter Android Debug Bridge. Si une implémentation d'appareil omet un port client USB, elle DOIT implémenter le pont de débogage Android via un réseau local (tel qu'Ethernet ou 802.11).

8. Compatibilité des performances

Les implémentations d'appareils DOIVENT respecter les principales métriques de performances d'un appareil compatible avec Android définies dans le tableau ci-dessous:

Métrique	Seuil de performances	Commentaires
Heure de lancement de l'application	Les applications suivantes doivent être lancées dans le délai spécifié. Navigateur: moins de 1 300 ms Contacts: moins de 700 ms Paramètres: moins de 700 ms	Le temps de lancement correspond au temps total nécessaire pour charger l'activité par défaut de l'application, y compris le temps nécessaire pour démarrer le processus Linux, charger le package Android dans la VM Dalvik et appeler onCreate.
Applications simultanées	Lorsque plusieurs applications ont été lancées, le temps de relance d'une application déjà en cours d'exécution doit être inférieur au temps de lancement initial.

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, 54] de la documentation pour les développeurs Android. Les implémentations d'appareils DOIVENT prendre en charge l'installation d'applications autosignées sans nécessiter d'autorisations/certificats supplémentaires de la part de tiers/autorités. Plus précisément, les appareils compatibles DOIVENT prendre en charge les mécanismes de sécurité décrits dans les sous-sections suivantes.

9.1. Autorisations

Les implémentations d'appareils DOIVENT prendre en charge le modèle d'autorisations Android tel que défini dans la documentation destinée aux développeurs Android [Resources, 54]. 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, 54].

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, 54].

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 la machine virtuelle Dalvik ou le code natif. Toutefois, ces environnements d'exécution alternatifs NE DOIVENT PAS compromettre le modèle de sécurité Android ni la sécurité des applications Android installées, comme décrit dans cette section.

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

Les environnements d'exécution alternatifs NE DOIVENT PAS être autorisés à accéder aux ressources protégées par des autorisations non demandées dans le fichier AndroidManifest.xml de l'environnement d'exécution via le mécanisme <uses-permission>.

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

Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android. Plus spécifiquement :

• Les autres environnements d'exécution DOIVENT installer les applications via le PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).
• Les environnements d'exécution alternatifs PEUVENT fournir un seul bac à sable Android partagé par toutes les applications utilisant l'environnement d'exécution alternatif.
• Les environnements d'exécution alternatifs et les applications installées à l'aide d'un environnement d'exécution alternatif 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.
• Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec, accorder ni être autorisés à accéder aux bacs à sable correspondant à d'autres applications Android.

Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec, ni être accordés, ni accorder à d'autres applications des droits de super-utilisateur (root) ou de tout autre ID utilisateur.

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

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

9.5. Compatibilité multi-utilisateur

Android est compatible avec plusieurs utilisateurs et prend en charge l'isolation complète des utilisateurs [Resources, 70].

Les implémentations d'appareils DOIVENT respecter les exigences suivantes concernant la prise en charge du mode multi-utilisateur [Ressources, 71]:

• Comme le comportement des API de téléphonie sur les appareils avec plusieurs utilisateurs n'est actuellement pas défini, les implémentations d'appareils qui déclarent android.hardware.telephony NE DOIVENT PAS activer la prise en charge multi-utilisateur.
• 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, 54].
• Android est compatible avec les profils limités, 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 que d'autres utilisateurs puissent y travailler, et gérer des restrictions plus précises dans les applications disponibles dans ces environnements. Les implémentations d'appareils compatibles avec plusieurs utilisateurs DOIVENT être compatibles avec les profils restreints. Le projet Android Open Source en amont inclut une implémentation qui répond à cette exigence.

Chaque instance utilisateur sur un appareil Android DOIT disposer de répertoires de stockage externes distincts et isolés. Les implémentations d'appareils PEUVENT stocker les données de plusieurs utilisateurs sur le même volume ou le même système de fichiers. Toutefois, l'implémentation de l'appareil DOIT s'assurer que les applications appartenant à un utilisateur donné et exécutées en son nom ne peuvent pas lister, lire ni écrire des données appartenant à un autre utilisateur. Notez que les supports amovibles, tels que les emplacements pour cartes SD, peuvent permettre à un utilisateur d'accéder aux données d'un autre utilisateur via un PC hôte. Pour cette raison, les implémentations d'appareils qui utilisent des supports amovibles pour les API de stockage externe DOIVENT chiffrer le contenu de la carte SD si la multi-utilisation est activée à l'aide d'une clé stockée uniquement sur des supports non amovibles accessibles uniquement au système. Comme les supports multimédias ne seront plus lisibles par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour fournir aux PC hôtes un accès aux données de l'utilisateur actuel. Par conséquent, les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS activer le multi-utilisateur si elles utilisent des supports amovibles [Ressources, 72] pour le stockage externe principal.

9.6. Avertissement concernant les SMS premium

Android permet d'avertir les utilisateurs de tout message SMS premium sortant [Ressources, 73] . 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 de android.hardware.telephony DOIVENT avertir les utilisateurs avant d'envoyer un message SMS aux 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 pouvant utiliser le système de contrôle des accès obligatoire (MAC) de Security-Enhanced Linux (SELinux) et d'autres fonctionnalités de sécurité du noyau Linux. SELinux ou toute autre fonctionnalité de sécurité, si implémentée sous le framework Android:

• DOIT assurer la compatibilité avec les applications existantes
• NE DOIT PAS comporter d'interface utilisateur visible, même en cas de non-respect
• 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 et répondre aux exigences suivantes, qui sont satisfaites par l'implémentation de référence dans le projet Open Source Android en amont.

• Il doit prendre en charge une stratégie SELinux qui permet de définir le mode SELinux par domaine avec:
• Les domaines qui sont en mode d'application dans l'implémentation Open Source Android en amont (tels que installd, netd et vold) DOIVENT être en mode d'application.
• Le ou les domaines des applications tierces DOIVENT rester en mode permissif pour assurer la compatibilité.
• Il devrait charger la stratégie à partir du fichier /sepolicy sur l'appareil.
• Il DOIT prendre en charge les mises à jour dynamiques du fichier de règles SELinux sans nécessiter de mise à jour de l'image système.
• Il DOIT consigner tous les cas de non-respect des règles sans interrompre les applications ni affecter le comportement du système.

Les implémentations d'appareils DOIVENT conserver la règle SELinux par défaut fournie dans le projet Open Source Android en amont, jusqu'à ce qu'elles aient d'abord audité leurs ajouts à la règle SELinux. 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 lu 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

Si l'appareil dispose d'un écran de verrouillage, il DOIT être compatible avec le chiffrement de disque complet.

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 fortement encouragés à apporter le moins de modifications possible à la référence et à l'implémentation 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, 2] 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 4.4. Les implémentations d'appareils DOIVENT réussir les tests de la dernière version du 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 l'ensemble 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 censés 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.

10.3. Applications de référence

Les implémentateurs d'appareils DOIVENT tester la compatibilité de l'implémentation à l'aide des applications Open Source suivantes:

• Les applications "Applications pour Android" [Ressources, 55]
• Replica Island (disponible sur le Google Play Store)

Chaque application ci-dessus DOIT se lancer et se comporter correctement dans l'implémentation pour que l'implémentation soit considérée comme compatible.

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 espace de stockage amovible

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.

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
3.2.2. Paramètres de compilation	Descriptions révisées de BRAND, DEVICE et PRODUCT. SERIAL est désormais obligatoire.
3.2.3.5. Paramètres de l'application par défaut	Nouvelle section qui ajoute l'obligation de respecter les nouveaux paramètres d'application par défaut
3.3.1 Interfaces binaires d'application	Clarification des valeurs autorisées pour les paramètres android.os.Build.CPU_ABI et android.os.Build.CPU_ABI2.
3.4.1. Compatibilité avec WebView	Ajout de Chromium en tant qu'implémentation WebView requise.
3.7. Compatibilité des machines virtuelles	Ajout d'une exigence pour les densités d'écran xxhdpi et 400 ppp.
3.8.6. Thèmes	Mise à jour pour refléter l'utilisation des barres système transparentes.
3.8.12. Position	Nouvelle section qui ajoute l'exigence que les paramètres de localisation soient centralisés.
3.8.13. Unicode	Nouvelle section qui ajoute l'obligation de prendre en charge les emoji.
3.9. Gestion de l'appareil	Les applications administratives préinstallées indiquées ne peuvent pas être l'application propriétaire de l'appareil par défaut.
5.1. Codecs multimédias	Ajout d'une exigence de décodeur VP9. Ajout de la spécification recommandée pour les codecs VP8 matériels.
5.3. Décodage vidéo	Ajout de VP9. Ajout d'une recommandation pour le changement de résolution dynamique.
5.4. Enregistrement audio	Ajout de REMOTE_SUBMIX en tant que nouvelle source audio obligatoire. L'utilisation de l'API android.media.audiofx.NoiseSuppressor est obligatoire.
6.2.1 Expérimental	Nouvelle section qui présente l'environnement d'exécution ART et nécessite Dalvik comme environnement d'exécution par défaut.
7.1.1. Configuration de l'écran	Remplacement du format 1,85 par 1,86. Ajout de la densité d'écran de 400 ppp.
7.1.6. Types d'écrans	Ajout de la configuration de la résolution 640 ppp (4K).
7.2.3. Touches de navigation	Ajout de la fonction "Récents" comme essentielle. Déclassement de la fonction "Menu" en priorité.
7.3.6. Thermomètre	Ajout de SENSOR_TYPE_AMBIENT_TEMPERATURE comme thermomètre recommandé.
7.4.2.2. Configuration du lien direct en tunnel Wi-Fi	Nouvelle section qui ajoute la prise en charge de la configuration du lien direct en tunnel (TDLS) Wi-Fi.
7.4.4. Communication en champ proche	Ajout de l'émulation de carte hôte (HCE) comme exigence. Remplacement de SNEP GET par le protocole LLCP (Logical Link Control Protocol) et ajout du profil Bluetooth Object Push en tant qu'exigence.
7.4.6. Paramètres de synchronisation	Nouvelle section qui ajoute l'exigence de synchronisation automatique des données par défaut.
7.6.1. Mémoire et stockage minimums	Ajout d'une exigence de paramètre ActivityManager.isLowRamDevice() pour les appareils disposant de moins de 512 Mo de mémoire. Augmentation des exigences de stockage de 512 Mo et 1 Go à 1 Go et 2 Go, respectivement.
7.6.2. Stockage partagé "externe"	Corrections éditoriales, comme le changement de nom de section et le déplacement du texte qui convient dans cette section depuis la section 9.5. Les applications notées peuvent écrire dans leurs répertoires spécifiques au package sur un espace de stockage externe secondaire.
7.7. USB	Ajout d'une exigence selon laquelle tous les appareils doivent indiquer un numéro de série USB.
9.5. Compatibilité multi-utilisateur	Le texte non spécifique aux multi-utilisateurs a été déplacé vers la section 7.6.2.
9.7. Fonctionnalités de sécurité du noyau	Réécrit pour indiquer le passage de SELinux en mode d'application forcée et l'exigence que la sortie SELinux ne soit pas affichée dans l'interface utilisateur.
9.8. Confidentialité	Nouvelle section qui ajoute l'enregistrement audio et vidéo obligatoire doit déclencher des notifications continues à l'utilisateur.
9.9. Chiffrement complet de disque	Nouvelle section qui ajoute une exigence pour les appareils avec écran de verrouillage compatible avec le chiffrement de disque complet.
12. Journal des modifications du document	Nouvelle section récapitulant les modifications apportées au CDD par section.

 

13. Nous contacter

Vous pouvez contacter les auteurs du document à l'adresse compatibility@android.com pour obtenir des précisions et signaler les problèmes que vous pensez ne pas être couverts par le document.