L'utilisation de "doit", "ne doit pas", "obligatoire", "doit", "ne doit pas", "devrait", "ne devrait pas", "recommandé", "peut" et "facultatif" est conforme à la norme IETF. défini dans la RFC2119 [ Resources, 1 ].

Tel qu'utilisé dans ce document, un « implémenteur de périphérique » ou « implémenteur » est une personne ou une organisation développant une solution matérielle/logicielle exécutant Android 4.4. Une « implémentation de dispositif » 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'appareil DOIVENT répondre aux exigences présentées dans cette définition de compatibilité, y compris tous les documents incorporés par référence.

Lorsque cette définition ou les tests logiciels décrits dans la section 10 sont muets, ambigus ou incomplets, il est de la responsabilité du responsable de la mise en œuvre du dispositif de garantir la compatibilité avec les implémentations existantes.

Pour cette raison, le projet Android Open Source [ Ressources, 3 ] est à la fois la référence et l'implémentation privilégiée d'Android. Les développeurs d'appareils sont fortement encouragés à baser leurs implémentations dans la plus grande mesure possible sur le code source « en amont » disponible dans le projet Android Open Source. Bien que certains composants puissent hypothétiquement être remplacés par des implémentations alternatives, cette pratique est fortement déconseillée, car la réussite des tests logiciels deviendra beaucoup plus difficile. Il est de la responsabilité du responsable de la mise en œuvre de garantir une compatibilité comportementale totale avec l'implémentation Android standard, y compris et au-delà de la suite de tests de compatibilité. Notez enfin que certaines substitutions et modifications de composants sont explicitement interdites par ce document.

2. Ressources

Niveaux d'exigence de l'IETF RFC2119 : http://www.ietf.org/rfc/rfc2119.txt

Présentation du programme de compatibilité Android : http://source.android.com/docs/compatibility/index.html

Projet Open Source Android : http://source.android.com/

Définitions et documentation de l'API : http://developer.android.com/reference/packages.html

Référence sur les autorisations Android : http://developer.android.com/reference/android/Manifest.permission.html

Référence android.os.Build : http://developer.android.com/reference/android/os/Build.html

Chaînes de version autorisées pour Android 4.4 : http://source.android.com/docs/compatibility/4.4/versions.html

Script de rendu : http://developer.android.com/guide/topics/graphics/renderscript.html

Accélération matérielle : http://developer.android.com/guide/topics/graphics/hardware-accel.html

Classe android.webkit.WebView : http://developer.android.com/reference/android/webkit/WebView.html

HTML5 : http://www.whatwg.org/specs/web-apps/current-work/multipage/

Fonctionnalités HTML5 hors ligne : http://dev.w3.org/html5/spec/Overview.html#offline

Balise vidéo HTML5 : http://dev.w3.org/html5/spec/Overview.html#video

API de géolocalisation HTML5/W3C : http://www.w3.org/TR/geolocation-API/

API de stockage Web HTML5/W3C : http://www.w3.org/TR/webstorage/

API HTML5/W3C IndexedDB : http://www.w3.org/TR/IndexedDB/

Spécification de la machine virtuelle Dalvik : disponible dans le code source Android, sur dalvik/docs

AppWidgets : http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

Notifications : http://developer.android.com/guide/topics/ui/notifiers/notifications.html

Ressources d'application : http://code.google.com/android/reference/available-resources.html

Guide de style des icônes de la barre d'état : http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

Gestionnaire de recherche : http://developer.android.com/reference/android/app/SearchManager.html

Toasts : http://developer.android.com/reference/android/widget/Toast.html

Thèmes : http://developer.android.com/guide/topics/ui/themes.html

Classe R.style : http://developer.android.com/reference/android/R.style.html

Fonds d'écran animés : https://android-developers.googleblog.com/2010/02/live-wallpapers.html

Administration des appareils Android : http://developer.android.com/guide/topics/admin/device-admin.html

Référence DevicePolicyManager : http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

API du service d'accessibilité Android : http://developer.android.com/reference/android/accessibilityservice/package-summary.html

API d'accessibilité Android : http://developer.android.com/reference/android/view/accessibility/package-summary.html

Projet Eyes Free : http://code.google.com/p/eyes-free

API de synthèse vocale : http://developer.android.com/reference/android/speech/tts/package-summary.html

Documentation de l'outil de référence (pour adb, aapt, ddms, systrace) : http://developer.android.com/guide/developing/tools/index.html

Description du fichier apk Android : http://developer.android.com/guide/topics/fundamentals.html

Fichiers manifeste : http://developer.android.com/guide/topics/manifest/manifest-intro.html

Outil de test de singe : https://developer.android.com/studio/test/other-testing-tools/monkey

Classe Android android.content.pm.PackageManager et liste des fonctionnalités matérielles : http://developer.android.com/reference/android/content/pm/PackageManager.html

Prise en charge de plusieurs écrans : http://developer.android.com/guide/practices/screens_support.html

android.util.DisplayMetrics : http://developer.android.com/reference/android/util/DisplayMetrics.html

android.content.res.Configuration : http://developer.android.com/reference/android/content/res/Configuration.html

android.hardware.SensorEvent : http://developer.android.com/reference/android/hardware/SensorEvent.html

API Bluetooth : http://developer.android.com/reference/android/bluetooth/package-summary.html

Protocole push NDEF : http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

MIFARE MF1S503X : http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X : http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1 : http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2 : http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511 : http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411 : http://www.nxp.com/documents/application_note/AN130411.pdf

API d'orientation de la caméra : http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

Caméra : http://developer.android.com/reference/android/hardware/Camera.html

Accessoires ouverts Android : http://developer.android.com/guide/topics/usb/accessory.html

API hôte USB : http://developer.android.com/guide/topics/usb/host.html

Référence sur la sécurité et les autorisations Android : http://developer.android.com/guide/topics/security/permissions.html

Applications pour Android : http://code.google.com/p/apps-for-android

DownloadManager Android : http://developer.android.com/reference/android/app/DownloadManager.html

Transfert de fichiers Android : http://www.android.com/filetransfer

Formats multimédia Android : http://developer.android.com/guide/appendix/media-formats.html

Projet de protocole HTTP de diffusion en direct : http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

Transfert de connexion NFC : http://www.nfc-forum.org/specs/spec_list/#conn_handover

Couplage simple et sécurisé Bluetooth à l'aide de NFC : http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

API de multidiffusion Wi-Fi : http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

Assistance à l'action : http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

Spécification de chargement USB : http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

Android Beam : http://developer.android.com/guide/topics/nfc/nfc.html

Audio USB Android : http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

Paramètres de partage Android NFC : http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

Wi-Fi Direct (Wi-Fi P2P) : http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

Widget de verrouillage et d'écran d'accueil : http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

Référence UserManager : http://developer.android.com/reference/android/os/UserManager.html

Référence de stockage externe : https://source.android.com/docs/core/storage

API de stockage externe : http://developer.android.com/reference/android/os/Environment.html

Code court SMS : http://en.wikipedia.org/wiki/Short_code

Client de contrôle à distance multimédia : http://developer.android.com/reference/android/media/RemoteControlClient.html

Gestionnaire d'affichage : http://developer.android.com/reference/android/hardware/display/DisplayManager.html

Rêves : http://developer.android.com/reference/android/service/dreams/DreamService.html

Paramètres liés au développement d'applications Android : http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

Caméra : http://developer.android.com/reference/android/hardware/Camera.Parameters.html

Extension EGL-EGL_ANDROID_RECORDABLE : http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

API d'événements de mouvement : http://developer.android.com/reference/android/view/MotionEvent.html

Configuration de la saisie tactile : http://source.android.com/docs/core/interaction/input/touch-devices.html

Unicode 6.1.0 : http://www.unicode.org/versions/Unicode6.1.0/

Compatibilité WebView : http://www.chromium.org/

Application pour les propriétaires d'appareils Android : http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

API WifiManager : http://developer.android.com/reference/android/net/wifi/WifiManager.html

Exigences de codage matériel RTC : http://www.webmproject.org/hardware/rtc-coding-requirements/

Paramètres.Secure LOCATION_MODE : http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

Résolveur de contenu : http://developer.android.com/reference/android/content/ContentResolver.html

SettingInjectorService : http://developer.android.com/reference/android/location/SettingInjectorService.html

Émulation de carte basée sur l'hôte : http://developer.android.com/guide/topics/connectivity/nfc/hce.html

Fournisseur de téléphonie : http://developer.android.com/reference/android/provider/Telephony.html

Beaucoup de ces ressources sont dérivées directement ou indirectement du SDK Android et seront fonctionnellement identiques aux informations contenues dans la documentation de ce SDK. Dans tous les cas où cette définition de compatibilité ou la suite de tests de compatibilité est en désaccord avec la documentation du SDK, la documentation du SDK fait autorité. Tous les détails techniques fournis dans les références incluses ci-dessus sont considérés par inclusion comme faisant partie de cette définition de compatibilité.

3. Logiciel

3.1. Compatibilité des API gérées

L'environnement d'exécution géré (basé sur Dalvik) est le principal véhicule pour les applications Android. L'interface de programmation d'applications (API) Android est l'ensemble des interfaces de la plate-forme Android exposées aux applications exécutées dans l'environnement de machine virtuelle gérée. Les implémentations d'appareil 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 de périphériques NE DOIVENT PAS omettre d'API gérées, modifier les interfaces ou les signatures d'API, s'écarter du comportement documenté ou inclure des opérations sans opération, sauf lorsque cela est spécifiquement autorisé 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 de tels cas, les API DOIVENT toujours être présentes et se comporter de manière raisonnable. Voir la section 7 pour connaître les exigences spécifiques de ce scénario.

3.2. Compatibilité des API logicielles

En plus des API gérées de la section 3.1, Android inclut également une API « logicielle » importante réservée à l'exécution, sous la forme d'éléments tels que des intentions, des autorisations et des 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émenteurs de périphériques DOIVENT prendre en charge et appliquer toutes les constantes d'autorisation comme documenté par la page de référence des autorisations [ Ressources, 5 ]. Notez que la section 9 répertorie les exigences supplémentaires liées au modèle de sécurité Android.

3.2.2. Paramètres de construction

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

Paramètre	commentaires
VERSION.RELEASE	La version du système Android en cours d'exécution, dans un format lisible par l'homme. Ce champ DOIT avoir l'une des valeurs de chaîne définies dans [ Resources, 7 ].
VERSION.SDK	La version du système Android en cours d'exécution, dans un format accessible au code d'application tierce. Pour Android 4.4, ce champ DOIT avoir la valeur entière 19.
VERSION.SDK_INT	La version du système Android en cours d'exécution, dans un format accessible au code d'application tierce. Pour Android 4.4, ce champ DOIT avoir la valeur entière 19.
VERSION.INCREMENTAL	Une valeur choisie par l'implémenteur de l'appareil désignant la version spécifique du système Android en cours d'exécution, dans un format lisible par l'homme. Cette valeur NE DOIT PAS être réutilisée pour différentes versions mises à la disposition des utilisateurs finaux. Une utilisation typique de ce champ consiste à indiquer quel numéro de build ou quel identifiant de modification de contrôle de source a été utilisé pour générer la build. Il n'y a aucune exigence sur le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ou une chaîne vide ("").
CONSEIL	Une valeur choisie par le responsable de la mise en œuvre du périphérique identifiant le matériel interne spécifique utilisé par le périphérique, dans un format lisible par l'homme. Une utilisation possible de ce champ est d'indiquer la révision spécifique de la carte alimentant l'appareil. La valeur de ce champ DOIT être codable en ASCII 7 bits et correspondre à l'expression régulière `"^[a-zA-Z0-9.,_-]+$"` .
MARQUE	Une valeur reflétant le nom de marque associé à l'appareil tel que connu des utilisateurs finaux. DOIT être dans un format lisible par l'homme et DEVRAIT 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 codable en ASCII 7 bits et correspondre à l'expression régulière `"^[a-zA-Z0-9.,_-]+$"` .
CPU_ABI	Le nom du jeu d'instructions (type de CPU + convention ABI) du code natif. Voir Section 3.3 : Compatibilité des API natives .
CPU_ABI2	Le nom du deuxième jeu d'instructions (type de CPU + convention ABI) du code natif. Voir Section 3.3 : Compatibilité des API natives .
APPAREIL	Une valeur choisie par le développeur du périphérique contenant le nom de développement ou le nom de code identifiant la configuration des fonctionnalités matérielles et la conception industrielle du périphérique. La valeur de ce champ DOIT être codable en ASCII 7 bits et correspondre à l'expression régulière `"^[a-zA-Z0-9.,_-]+$"` .
EMPREINTE DIGITALE	Chaîne qui identifie de manière unique cette build. Il DEVRAIT être raisonnablement lisible par l'homme. 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 digitale NE DOIT PAS inclure de caractères d’espacement. Si d'autres champs inclus dans le modèle ci-dessus comportent des caractères d'espacement, ils DOIVENT être remplacés dans l'empreinte digitale de construction par un autre caractère, tel que le caractère de soulignement ("_"). La valeur de ce champ DOIT être codable en ASCII 7 bits.
MATÉRIEL	Le nom du matériel (à partir de la ligne de commande du noyau ou /proc). Il DEVRAIT être raisonnablement lisible par l'homme. La valeur de ce champ DOIT être codable en ASCII 7 bits et correspondre à l'expression régulière `"^[a-zA-Z0-9.,_-]+$"` .
HÔTE	Une chaîne qui identifie de manière unique l'hôte sur lequel la build a été construite, dans un format lisible par l'homme. Il n'y a aucune exigence sur le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ou une chaîne vide ("").
IDENTIFIANT	Un identifiant choisi par le responsable de la mise en œuvre de l'appareil pour faire référence à une version spécifique, dans un format lisible par l'homme. Ce champ peut être le même que android.os.Build.VERSION.INCREMENTAL, mais DEVRAIT être une valeur suffisamment significative pour que les utilisateurs finaux puissent faire la distinction entre les versions de logiciels. La valeur de ce champ DOIT être codable en ASCII 7 bits et correspondre à l'expression régulière `"^[a-zA-Z0-9.,_-]+$"` .
FABRICANT	Le nom commercial du fabricant d'équipement d'origine (OEM) du produit. Il n'y a aucune exigence sur le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ou une chaîne vide ("").
MODÈLE	Une valeur choisie par le responsable de la mise en œuvre du périphérique contenant le nom du périphérique tel que connu de l'utilisateur final. Cela DEVRAIT être le même nom sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Il n'y a aucune exigence sur le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ou une chaîne vide ("").
PRODUIT	Une valeur choisie par l'implémenteur de l'appareil contenant le nom de développement ou le nom de code du produit spécifique (SKU) qui DEVRAIT être unique au sein de la même marque. DOIT être lisible par l'homme, mais n'est pas nécessairement destiné à être visualisé par les utilisateurs finaux. La valeur de ce champ DOIT être codable en ASCII 7 bits et correspondre à l'expression régulière `"^[a-zA-Z0-9.,_-]+$"` .
EN SÉRIE	Un numéro de série du matériel, qui DOIT être disponible. La valeur de ce champ DOIT être codable en ASCII 7 bits et correspondre à l'expression régulière `"^([a-zA-Z0-9]{6,20})$"` .
MOTS CLÉS	Une liste de balises séparées par des virgules choisies par l'implémenteur du périphérique qui distingue davantage la build. Par exemple, « non signé,débogage ». La valeur de ce champ DOIT être codable en ASCII 7 bits et correspondre à l'expression régulière `"^[a-zA-Z0-9.,_-]+$"` .
TEMPS	Une valeur représentant l’horodatage du moment où la génération a eu lieu.
TAPER	Une valeur choisie par l'implémenteur du périphérique spécifiant la configuration d'exécution de la build. Ce champ DEVRAIT avoir l'une des valeurs correspondant aux trois configurations d'exécution Android typiques : "user", "userdebug" ou "eng". La valeur de ce champ DOIT être codable en ASCII 7 bits et correspondre à l'expression régulière `"^[a-zA-Z0-9.,_-]+$"` .
UTILISATEUR	Un nom ou un ID utilisateur de l'utilisateur (ou de l'utilisateur automatisé) qui a généré la build. Il n'y a aucune exigence sur le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ou une chaîne vide ("").

3.2.3. Compatibilité des intentions

Les implémentations d'appareil DOIVENT respecter le système d'intention de couplage lâche d'Android, comme décrit dans les sections ci-dessous. Par « honoré », cela signifie que l'implémenteur du périphérique DOIT fournir une activité ou un service Android qui spécifie un filtre d'intention correspondant et se lie à et implémente un comportement correct pour chaque modèle d'intention spécifié.

3.2.3.1. Intentions principales de l'application

Le projet Android en amont définit un certain nombre d'applications principales, telles que les contacts, le calendrier, la galerie de photos, le lecteur de musique, etc. Les responsables de la mise en œuvre des appareils PEUVENT remplacer ces applications par des versions alternatives.

Cependant, toutes ces versions alternatives DOIVENT respecter les mêmes modèles d'intention fournis par le projet en amont. Par exemple, si un appareil contient un lecteur de musique alternatif, il doit toujours respecter le modèle d'intention émis par des applications tierces pour sélectionner une chanson.

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

Horloge de bureau
Navigateur
Calendrier
Contacts
Galerie
Recherche globale
Lanceur
Musique
Paramètres

Les applications principales du système Android incluent divers composants d'activité ou de 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éfini dans l'une des applications principales du système Android qui n'est pas marqué comme non public via un attribut android:exported avec la valeur « false », les implémentations de périphérique DOIVENT inclure un composant du même type implémentant le même filtre d'intention. modèles en tant qu'application principale du système Android.

En d’autres termes, une implémentation d’appareil PEUT remplacer les applications principales du système Android ; cependant, si tel est le cas, l’implémentation du périphérique DOIT prendre en charge tous les modèles d’intention définis par chaque application principale du système Android remplacée.

3.2.3.2. Remplacements d'intention

Comme Android est une plate-forme extensible, les implémentations de périphérique DOIVENT permettre à chaque modèle d'intention référencé à la section 3.2.3.1 d'être remplacé par des applications tierces. L'implémentation open source Android en amont le permet par défaut ; les implémenteurs de dispositifs NE DOIVENT PAS attacher de privilèges spéciaux à l'utilisation par les applications système de ces modèles d'intention, ni empêcher les applications tierces de se lier à ces modèles et d'en prendre le contrôle. Cette interdiction inclut spécifiquement, mais sans s'y limiter, la désactivation de l'interface utilisateur « Chooser » qui permet à l'utilisateur de choisir entre plusieurs applications qui gèrent toutes le même modèle d'intention.

Cependant, les implémentations d'appareil 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 des données. Par exemple, un filtre d'intention spécifiant l'URI de données « http://www.android.com » est plus spécifique que le filtre de navigateur pour « http:// ». Les implémentations de périphérique DOIVENT fournir une interface utilisateur permettant aux utilisateurs de modifier l'activité par défaut des intentions.

3.2.3.3. Espaces de noms d'intention

Les implémentations d'appareil NE DOIVENT PAS inclure de composant Android qui honore de nouveaux modèles d'intention ou d'intention de diffusion à l'aide d'une ACTION, d'une CATÉGORIE ou d'une autre chaîne de clé dans l'espace de noms android.* ou com.android.*. Les responsables de la mise en œuvre des appareils NE DOIVENT PAS inclure de composants Android qui honorent de nouveaux modèles d'intention ou d'intention de diffusion à l'aide d'une ACTION, d'une CATÉGORIE ou d'une autre chaîne de clé dans un espace de package appartenant à une autre organisation. Les responsables de la mise en œuvre des appareils NE DOIVENT PAS modifier ou étendre les modèles d'intention utilisés par les applications principales répertoriées dans la section 3.2.3.1. Les implémentations de périphériques PEUVENT inclure des modèles d'intention utilisant des espaces de noms clairement et évidemment associés à leur propre organisation.

Cette interdiction est analogue à celle spécifiée pour les classes du langage Java à la section 3.6.

3.2.3.4. Intentions de diffusion

Les applications tierces s'appuient sur la plateforme pour diffuser certaines intentions afin de les informer des changements dans l'environnement matériel ou logiciel. Les appareils compatibles Android DOIVENT diffuser les intentions de diffusion publique en réponse aux événements système appropriés. Les intentions de diffusion sont décrites dans la documentation du SDK.

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

Android 4.4 ajoute des paramètres qui permettent aux utilisateurs de sélectionner leurs applications Accueil et SMS par défaut. Les implémentations de périphériques DOIVENT fournir un menu de paramètres utilisateur similaire pour chacun, compatible avec le modèle de filtre d'intention et les méthodes API décrites dans la documentation du SDK [ Ressources, 91 ].

3.3. Compatibilité API native

3.3.1 Interfaces binaires des applications

Le code managé exécuté dans Dalvik peut appeler le code natif fourni dans le fichier .apk de l'application en tant que fichier ELF .so compilé pour l'architecture matérielle du périphérique approprié. Comme le code natif dépend fortement de la technologie du processeur sous-jacent, 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 de périphérique est compatible avec un ou plusieurs ABI définis, elle DEVRAIT implémenter la compatibilité avec le NDK Android, comme ci-dessous.

Si l’implémentation d’un appareil inclut la prise en charge d’une ABI Android, elle :

DOIT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler du code natif, en utilisant la sémantique standard Java Native Interface (JNI).
DOIT être compatible avec la source (c'est-à-dire compatible avec l'en-tête) et compatible avec le binaire (pour l'ABI) avec chaque bibliothèque requise dans la liste ci-dessous
DOIT signaler avec précision l'interface binaire d'application (ABI) native prise en charge par 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és 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 répertoriés ci-dessous

armeabi-v7a
x86
mips

DEVRAIT être construit en utilisant le code source et les fichiers d'en-tête disponibles dans le projet Android Open Source 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)
Prise en charge minimale du C++
Interface JNI
liblog (journalisation Android)
libz (compression Zlib)
libdl (éditeur 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 native des surfaces OpenGL)
libjnigraphics.so
libOpenSLES.so (prise en charge audio d'OpenSL ES 1.0.1)
libOpenMAXAL.so (prise en charge d'OpenMAX AL 1.0.1)
libandroid.so (prise en charge native des activités Android)
Prise en charge d'OpenGL, comme décrit ci-dessous

Notez que les futures versions d'Android NDK pourraient introduire la prise en charge d'ABI supplémentaires. Si une implémentation de périphérique n'est pas compatible avec un ABI prédéfini existant, elle NE DOIT PAS du tout signaler la prise en charge d'un ABI.

Notez que les implémentations de périphériques DOIVENT inclure libGLESv3.so et qu'elles DOIVENT créer un lien symbolique (symbolique) vers libGLESv2.so. Sur les implémentations de périphériques 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 un défi. Pour cette raison, il convient de répéter que les implémenteurs de périphériques sont TRÈS fortement encouragés à utiliser les implémentations en amont des bibliothèques répertoriées ci-dessus pour garantir la compatibilité.

3.4. Compatibilité Web

3.4.1. Compatibilité WebView

L'implémentation Android Open Source utilise le code du projet Chromium pour implémenter android.webkit.WebView [ Resources, 10 ] . Puisqu'il n'est pas possible de développer une suite de tests complète pour un système de rendu Web, les implémenteurs de périphériques DOIVENT utiliser la version spécifique en amont de Chromium dans l'implémentation de WebView. Spécifiquement:

Les implémentations de l'appareil android.webkit.WebView DOIVENT être basées sur la version Chromium du projet Android Open Source 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 de l'agent utilisateur signalée par WebView DOIT être dans ce format :
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 la même que la valeur de android.os.Build.VERSION.RELEASE .
- La valeur de la chaîne $(LOCALE) est facultative, DEVRAIT suivre les conventions ISO pour le code du pays et la langue, et DEVRAIT faire référence aux paramètres régionaux actuellement configurés du périphérique. S’il est omis, le point-virgule final DOIT également être supprimé.
- La valeur de la chaîne $(MODEL) DOIT être la même que la valeur de android.os.Build.MODEL .
- La valeur de la chaîne $(BUILD) DOIT être la même que la valeur de android.os.Build.ID .
- La valeur de la chaîne $(CHROMIUM_VER) DOIT être la version de Chromium dans le projet Open Source Android en amont.
- Les implémentations de périphériques PEUVENT omettre Mobile dans la chaîne de l'agent utilisateur.

Le composant WebView DEVRAIT inclure la prise en charge d'autant de HTML5 [ Ressources, 11 ] que possible.

3.4.2. Compatibilité du navigateur

Les implémentations d'appareil DOIVENT inclure une application de navigateur autonome pour la navigation Web des utilisateurs généraux. Le navigateur autonome PEUT être basé sur une technologie de navigateur autre que WebKit. Cependant, 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 à la section 3.4.1.

Les implémentations PEUVENT expédier une chaîne d'agent utilisateur 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) DEVRAIT inclure la prise en charge d'autant de HTML5 [ Ressources, 11 ] que possible. Au minimum, les implémentations d'appareil DOIVENT prendre en charge chacune de ces API associées à HTML5 :

cache d'application/opération hors ligne [ Ressources, 12 ]
la balise <video> [ Ressources, 13 ]
géolocalisation [ Ressources, 14 ]

De plus, les implémentations de périphériques DOIVENT prendre en charge l'API de stockage Web HTML5/W3C [ Ressources, 15 ] et DEVRAIENT prendre en charge l'API HTML5/W3C IndexedDB [ Ressources, 16 ]. Notez qu'à mesure que les organismes de normalisation du développement Web privilégient IndexedDB par rapport au stockage Web, IndexedDB devrait devenir un composant obligatoire dans une future version d'Android.

3.5. Compatibilité comportementale des API

Les comportements de chacun des types d'API (gérés, logiciels, natifs et Web) doivent être cohérents avec l'implémentation préférée du projet Android Open Source en amont [ Ressources, 3 ]. Certains domaines spécifiques de compatibilité sont :

Les appareils NE DOIVENT PAS modifier le comportement ou la sémantique d'une intention 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 qu'un service, une activité, un fournisseur de contenu, etc.)
Les appareils NE DOIVENT PAS modifier la sémantique d'une autorisation standard

La liste ci-dessus n'est pas exhaustive. La suite de tests de compatibilité (CTS) teste des parties importantes de la plate-forme pour vérifier leur compatibilité comportementale, mais pas toutes. Il est de la responsabilité du responsable de la mise en œuvre de garantir la compatibilité comportementale avec le projet Android Open Source. Pour cette raison, les implémenteurs de périphériques DEVRAIENT utiliser le code source disponible via le projet Android Open Source lorsque cela est 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 garantir la compatibilité avec les applications tierces, les implémenteurs de périphériques NE DOIVENT PAS apporter de modifications interdites (voir ci-dessous) à ces espaces de noms de packages :

Java.*
javax.*
soleil.*
Android.*
com.android.*

Les modifications interdites incluent :

Les implémentations d'appareil NE DOIVENT PAS modifier les API exposées publiquement sur la plate-forme Android en modifiant les signatures de méthode ou de classe, ou en supprimant des classes ou des champs de classe.
Les implémenteurs de périphériques PEUVENT modifier l'implémentation sous-jacente des API, mais de telles modifications NE DOIVENT PAS avoir d'impact sur le comportement déclaré et la signature en langage Java de toute API exposée publiquement.
Les implémenteurs de périphériques NE DOIVENT PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, ou des champs ou des méthodes aux classes ou interfaces existantes) aux API ci-dessus.

Un « élément exposé publiquement » est toute construction qui n'est pas décorée du marqueur « @hide » tel qu'utilisé dans le code source Android en amont. En d’autres termes, les implémenteurs de périphériques NE DOIVENT PAS exposer de nouvelles API ou modifier les API existantes dans les espaces de noms mentionnés ci-dessus. Les implémenteurs de périphériques PEUVENT apporter des modifications uniquement internes, mais ces modifications NE DOIVENT PAS être annoncées ou autrement exposées aux développeurs.

Les responsables de la mise en œuvre des appareils PEUVENT ajouter des API personnalisées, mais ces API NE DOIVENT PAS se trouver dans un espace de noms appartenant à ou faisant référence à une autre organisation. Par exemple, les implémenteurs de périphériques NE DOIVENT PAS ajouter d'API à 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 sociétés. De plus, si l'implémentation d'un appareil inclut des API personnalisées en dehors de l'espace de noms Android standard, ces API DOIVENT être regroupées dans une bibliothèque partagée Android afin que seules les applications qui les utilisent explicitement (via le mécanisme <uses-library> ) soient affectées par l'utilisation accrue de la mémoire. de ces API.

Si un implémenteur de périphérique propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple en ajoutant de nouvelles fonctionnalités utiles à une API existante ou en ajoutant une nouvelle API), l'implémenteur DEVRAIT visiter source.android.com et commencer le processus de contribution aux modifications et code, selon les informations sur ce site.

Notez que les restrictions ci-dessus correspondent aux conventions standard 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 de périphériques DOIVENT prendre en charge la spécification complète du bytecode Dalvik Executable (DEX) et la sémantique de la machine virtuelle Dalvik [ Ressources, 17 ].

Les implémentations de périphériques DOIVENT configurer Dalvik pour allouer de la mémoire conformément à la plate-forme Android en amont et comme spécifié dans le tableau suivant. (Voir la section 7.1.1 pour les définitions de taille d'écran et de densité d'écran.)

Notez que les valeurs de mémoire spécifiées ci-dessous sont considérées comme des valeurs minimales, et les implémentations de périphériques PEUVENT allouer plus de mémoire par application.

Taille de l'écran	Densité de l'écran	Mémoire d'application
petit / normal / grand	ldpi / mdpi	16 Mo
petit / normal / grand	tvdpi / hdpi	32 Mo
petit / normal / grand	xhdpi	64 Mo
petit / normal / grand	400 dpi	96 Mo
petit / normal / grand	xxhdpi	128 Mo
petit / normal / grand	xxxhdpi	256 Mo
très grand	mdpi	32 Mo
très grand	tvdpi / hdpi	64 Mo
très grand	xhdpi	128 Mo
très grand	400 dpi	192 Mo
très grand	xxhdpi	256 Mo
très grand	xxxhdpi	512 Mo

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur (écran d'accueil)

Android comprend une application de lancement (écran d'accueil) et la prise en charge d'applications tierces pour remplacer le lanceur de périphérique (écran d'accueil). Les implémentations d'appareil qui permettent à des applications tierces de remplacer l'écran d'accueil de l'appareil DOIVENT déclarer la fonctionnalité de plateforme android.software.home_screen .

3.8.2. Widgets

Android définit un type de composant, une API et un cycle de vie correspondants qui permettent aux applications d'exposer un "AppWidget" à l'utilisateur final [ Ressources, 18 ]. Les implémentations d'appareils qui prennent en charge l'intégration de widgets sur l'écran d'accueil DOIVENT répondre aux exigences suivantes et déclarer la prise en charge de la fonctionnalité de plate-forme android.software.app_widgets .

Les lanceurs de périphériques DOIVENT inclure une prise en charge intégrée des AppWidgets et exposer les possibilités de l'interface utilisateur pour ajouter, configurer, afficher et supprimer des AppWidgets directement dans le lanceur.
Les implémentations de périphériques DOIVENT être capables de restituer des widgets de 4 x 4 dans la taille de grille standard. (Voir les directives de conception d'App Widget dans la documentation du SDK Android [ Ressources, 18 ] pour plus de détails.
Les implémentations de périphérique qui incluent la prise en charge de 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 ], en utilisant les fonctionnalités matérielles et logicielles de l'appareil.

Certaines API permettent aux applications d'effectuer des notifications ou d'attirer l'attention à l'aide de matériel, notamment du son, des vibrations et de la lumière. Les implémentations de périphérique 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 de mise en œuvre du périphérique. Par exemple, si l’implémentation d’un appareil inclut un vibrateur, il DOIT implémenter correctement les API de vibration. Si l'implémentation d'un périphérique manque de matériel, les API correspondantes DOIVENT être implémentées sans opération. Notez que ce comportement est détaillé plus en détail dans la section 7.

De plus, l'implémentation DOIT restituer correctement toutes les ressources (icônes, fichiers son, 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émenteurs d'appareil PEUVENT fournir une expérience utilisateur alternative pour les notifications à celle fournie par l'implémentation de référence Android Open Source ; cependant, de tels systèmes de notification alternatifs DOIVENT prendre en charge les ressources de notification existantes, comme ci-dessus.

Android inclut la prise en charge de notifications riches, telles que des vues interactives pour les notifications en cours. Les implémentations d'appareil DOIVENT afficher et exécuter correctement des notifications riches, comme documenté dans les API Android.

3.8.4. Recherche

Android inclut des API [ Ressources, 22 ] qui permettent aux développeurs d'incorporer la recherche dans leurs applications et d'exposer les données de leur application dans la recherche globale du système. De manière générale, 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 les résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour effectuer une recherche dans leurs propres applications et permettent aux développeurs de fournir des résultats à l'interface utilisateur de recherche globale commune.

Les mises en œuvre de dispositifs DOIVENT inclure une interface utilisateur de recherche unique, partagée à l'échelle du système, capable de suggestions en temps réel en réponse aux entrées de l'utilisateur. Les implémentations de périphériques DOIVENT implémenter les API qui permettent aux développeurs de réutiliser cette interface utilisateur pour fournir une recherche au sein de leurs propres applications. Les implémentations de périphériques 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 de recherche globale. Si aucune application tierce n'est installée et utilise cette fonctionnalité, le comportement par défaut DEVRAIT être d'afficher les résultats et les suggestions des moteurs de recherche Web.

3.8.5. Toasts

Les applications peuvent utiliser l'API "Toast" (définie dans [ Ressources, 23 ]) pour afficher de courtes chaînes non modales à l'utilisateur final, qui disparaissent après une brève période de temps. Les implémentations de périphériques DOIVENT afficher les toasts des applications aux utilisateurs finaux de manière à haute visibilité.

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 correspondre à l'apparence du thème Holo telle que définie par le SDK Android [ Ressources, 24 ]. Les implémentations de périphériques NE DOIVENT PAS modifier les attributs du thème Holo exposés aux applications [ Ressources, 25 ].

Android comprend également une famille de thèmes « Device Default » sous la forme d'un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent correspondre à l'apparence du thème de l'appareil tel que défini par le responsable de la mise en œuvre de l'appareil. Les implémentations de périphériques PEUVENT modifier les attributs du thème DeviceDefault exposés aux applications [ Ressources, 25 ].

À partir de la version 4.4, Android prend désormais en charge une nouvelle variante de thème avec des barres système translucides, permettant aux développeurs d'applications de remplir la zone située derrière la barre d'état et de navigation avec le contenu de leur application. Pour permettre une expérience de développeur cohérente dans cette configuration, il est important que le style de l'icône de la barre d'état soit conservé dans les différentes implémentations d'appareils. Par conséquent, les implémentations d'appareils Android DOIVENT utiliser du blanc pour les icônes d'état du système (telles que la force du signal et le niveau de la batterie) et les notifications émises par le système, à moins que l'icône n'indique un état problématique [ Ressources, 25 ].

3.8.7. Fonds d'écran animés

Android définit un type de composant, une API et un cycle de vie correspondants qui permettent aux applications d'exposer un ou plusieurs "Live Wallpapers" à l'utilisateur final [ Ressources, 26 ]. Les fonds d'écran animés sont des animations, des motifs ou des images similaires avec des capacités de saisie limitées qui s'affichent comme fond d'écran, derrière d'autres applications.

Le matériel est considéré comme capable d'exécuter de manière fiable des fonds d'écran animés s'il peut exécuter tous les fonds d'écran animés, sans aucune limitation de fonctionnalité, à une fréquence d'images raisonnable et sans effets négatifs sur les autres applications. Si des limitations matérielles entraînent le blocage, le dysfonctionnement des fonds d'écran et/ou des applications, une consommation excessive d'énergie du processeur ou de la batterie, ou une exécution à des fréquences d'images inacceptablement basses, le matériel est considéré comme incapable d'exécuter un fond d'écran animé. À titre d'exemple, certains fonds d'écran animés peuvent utiliser un contexte Open GL 1.0 ou 2.0 pour restituer leur contenu. Le fond d'écran animé ne fonctionnera pas de manière fiable sur du matériel qui ne prend pas en charge plusieurs contextes OpenGL, car l'utilisation du fond d'écran animé d'un contexte OpenGL peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

Les implémentations d'appareils capables d'exécuter des fonds d'écran animés de manière fiable, comme décrit ci-dessus, DEVRAIENT implémenter des fonds d'écran animés. Les implémentations d'appareils déterminées comme n'exécutant pas 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 comprend une interface utilisateur permettant d'afficher des 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 de périphériques PEUVENT modifier ou éliminer cette interface utilisateur ; cependant, une future version d’Android devrait utiliser plus largement cette fonctionnalité. Les implémentations d'appareils sont fortement encouragées à utiliser l'interface utilisateur Android en amont (ou une interface similaire basée sur des vignettes) pour les applications récentes, sinon elles pourraient ne pas être compatibles avec une future version d'Android.

3.8.9. Gestion des entrées

Android inclut la prise en charge de la gestion des entrées et la prise en charge des éditeurs de méthodes de saisie tiers. Les implémentations d'appareil 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 telles que définies dans la documentation du SDK Android.

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

3.8.10. Écran de verrouillage de la télécommande multimédia

Android inclut la prise en charge de l'API de contrôle à distance qui permet aux applications multimédias de s'intégrer aux commandes de lecture affichées dans une vue distante, comme l'écran de verrouillage de l'appareil [ Ressources, 74 ]. Les implémentations d'appareil qui prennent en charge l'écran de verrouillage dans l'appareil et permettent aux utilisateurs d'ajouter des widgets sur l'écran d'accueil DOIVENT inclure la prise en charge de l'intégration des télécommandes dans l'écran de verrouillage de l'appareil [ Ressources, 69 ].

3.8.11. Rêves

Android inclut la prise en charge d'économiseurs d'écran interactifs appelés Dreams [ Resources, 76 ]. Dreams permet aux utilisateurs d'interagir avec des applications lorsqu'un appareil de chargement est inactif ou connecté à une station d'accueil. Les implémentations de périphériques DOIVENT inclure la prise en charge de Dreams et fournir une option de paramètres permettant aux utilisateurs de configurer Dreams.

3.8.12. Emplacement

Les modes de localisation DOIVENT être affichés dans le menu Localisation dans Paramètres [ Ressources, 87 ]. Les services de localisation fournis via le SettingInjectorService introduit dans Android 4.4 doivent être affichés dans le même menu Localisation [ Ressources, 89 ].

3.8.13. Unicode

Android 4.4 inclut la prise en charge des caractères emoji de couleur. Les implémentations d'appareils Android DOIVENT fournir à l'utilisateur une méthode de saisie pour les caractères Emoji définis dans Unicode 6.1 [ Ressources, 82 ] et DOIVENT être capables de restituer ces caractères emoji sous forme de glyphe de couleur.

3.9. Administration des appareils

Android inclut des fonctionnalités qui permettent aux applications sensibles à la sécurité d'exécuter des fonctions d'administration des appareils au niveau du système, telles que l'application de politiques de mot de passe ou l'effacement à distance, via l'API d'administration des appareils Android [ Ressources, 27 ]. Les implémentations de périphériques DOIVENT fournir une implémentation de la classe DevicePolicyManager [ Resources, 28 ]. Les implémentations d'appareils qui incluent la prise en charge de l'écran de verrouillage DOIVENT prendre en charge la gamme complète des politiques d'administration des appareils définies dans la documentation du SDK Android [ Ressources, 27 ].

Les implémentations de périphériques PEUVENT avoir une application préinstallée exécutant des fonctions d'administration de périphérique, mais cette application NE DOIT PAS être définie par défaut comme application par défaut du propriétaire de périphérique [ Ressources, 84 ].

3.10. Accessibilité

Android fournit une couche d'accessibilité qui aide les utilisateurs handicapés à 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 des mécanismes de retour alternatifs, tels que la synthèse vocale, le retour haptique et la navigation trackball/d-pad [ Ressources, 29 ]. Les implémentations d'appareil DOIVENT fournir une implémentation du cadre d'accessibilité Android cohérente avec l'implémentation Android par défaut. Plus précisément, les implémentations de périphériques DOIVENT répondre aux exigences suivantes.

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

De plus, les implémentations de périphérique DEVRAIENT fournir une implémentation d'un service d'accessibilité sur le périphérique, et DEVRAIENT fournir un mécanisme permettant aux utilisateurs d'activer le service d'accessibilité pendant la configuration du périphérique. Une implémentation open source d'un service d'accessibilité est disponible auprès du projet Eyes Free [ Ressources, 31 ].

3.11. Texte pour parler

Android inclut des API qui permettent aux applications d'utiliser les services de synthèse vocale (TTS) et permettent aux fournisseurs de services de fournir des implémentations de services TTS [ Ressources, 32 ]. Les implémentations d'appareil DOIVENT répondre à ces exigences liées au framework Android TTS :

Les implémentations d'appareil DOIVENT prendre en charge les API du cadre Android TTS et DEVRAIENT inclure un moteur TTS prenant en charge les langues disponibles sur l'appareil. Notez que le logiciel open source Android en amont inclut une implémentation complète du moteur TTS.
Les implémentations de périphériques DOIVENT prendre en charge l'installation de moteurs TTS tiers.
Les mises en œuvre de dispositifs DOIVENT fournir une interface accessible à l'utilisateur qui permet aux utilisateurs de sélectionner un moteur TTS à utiliser au niveau du système.

4. Compatibilité des emballages d'application

Les implémentations de périphériques 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 des appareils NE DOIVENT PAS étendre les formats .apk [ Ressources, 34 ], Android Manifest [ Ressources, 35 ], bytecode Dalvik [ Ressources, 17 ] ou renderscript de manière à empêcher ces fichiers de s'installer et de s'exécuter correctement sur d'autres appareils compatibles. Les implémenteurs de périphériques DEVRAIENT utiliser l'implémentation de référence en amont de Dalvik et le système de gestion de paquets de l'implémentation de référence.

5. Compatibilité multimédia

Les implémentations de périphériques DOIVENT inclure au moins une forme de sortie audio, telle que des haut-parleurs, une prise casque, une connexion de haut-parleur externe, etc.

5.1. Codecs multimédias

Les implémentations de périphériques DOIVENT prendre en charge les formats multimédias de base spécifiés dans la documentation du SDK Android [ Ressources, 58 ], sauf lorsque cela est explicitement autorisé dans ce document. Plus précisément, les implémentations de périphérique DOIVENT prendre en charge les formats multimédias, les encodeurs, les décodeurs, les types de fichiers et les formats de conteneurs définis dans les tableaux ci-dessous. Tous ces codecs sont fournis sous forme d'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 garantissent que ces codecs ne sont pas grevés de brevets tiers. Ceux qui ont l'intention d'utiliser ce code source dans des produits matériels ou logiciels sont informés que les implémentations de ce code, y compris dans des logiciels open source ou des sharewares, peuvent nécessiter des licences de brevet auprès des titulaires de brevets concernés.

Notez que ces tableaux ne répertorient pas les exigences spécifiques en matière de débit binaire pour la plupart des codecs vidéo, car le matériel actuel des appareils ne prend pas nécessairement en charge des débits binaires correspondant exactement aux débits binaires requis spécifiés par les normes pertinentes. Au lieu de cela, les implémentations de périphériques DEVRAIENT prendre en charge le débit binaire le plus élevé possible sur le matériel, jusqu'aux limites définies par les spécifications.

Taper	Formater/Codecs	Encodeur	Décodeur	Détails	Types de fichiers/formats de conteneurs
l'audio	Profil MPEG-4 AAC (AAC LC)	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de microphone et définissent `android.hardware.microphone` .	REQUIS	Prise en charge du contenu mono/stéréo/5.0/5.1* avec des taux d'échantillonnage standard de 8 à 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS raw AAC (.aac, décodage sous Android 3.1+, encodage sous Android 4.0+, ADIF non pris en charge) MPEG-TS (.ts, non consultable, Android 3.0+)
	Profil MPEG-4 HE AAC (AAC+)	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de microphone et définissent android.hardware.microphone	REQUIS	Prise en charge du contenu mono/stéréo/5.0/5.1* avec des taux d'échantillonnage standard de 16 à 48 kHz.
	Profil MPEG-4 HE AAC v2 (AAC+ amélioré)		REQUIS	Prise en charge du contenu mono/stéréo/5.0/5.1* avec des taux d'échantillonnage standard de 16 à 48 kHz.
	Type d'objet audio MPEG-4 ER AAC ELD (AAC à faible délai amélioré)	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de microphone et définissent android.hardware.microphone	REQUIS	Prise en charge du contenu mono/stéréo avec des taux d'échantillonnage standard de 16 à 48 kHz.
	AMR-NB	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de microphone et définissent `android.hardware.microphone` .	REQUIS	4,75 à 12,2 kbps échantillonnés à 8 kHz	3GPP (.3gp)
	AMR-WB	OBLIGATOIRE pour les implémentations d'appareils qui incluent du matériel de microphone et définissent `android.hardware.microphone` .	REQUIS	9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz	3GPP (.3gp)
	FLAC		REQUIS (Android 3.1+)	Mono/Stéréo (pas de multicanal). Fréquences d'échantillonnage jusqu'à 48 kHz (mais jusqu'à 44,1 kHz est recommandé sur les appareils dotés d'une sortie de 44,1 kHz, car le sous-échantillonneur de 48 à 44,1 kHz n'inclut pas de filtre passe-bas). 16 bits recommandés ; aucun tramage n'est appliqué pour 24 bits.	FLAC (.flac) uniquement
	MP3		REQUIS	Mono/stéréo 8-320 Kbps à débit constant (CBR) ou variable (VBR)	MP3 (.mp3)
	MIDI		REQUIS	MIDI Type 0 et 1. DLS versions 1 et 2. XMF et Mobile XMF. Prise en charge des formats de sonnerie RTTTL/RTX, OTA et iMelody	Tapez 0 et 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
	Vorbis		REQUIS		Ogg (.ogg) Matroska (.mkv)
	PCM/ONDE	REQUIS	REQUIS	PCM linéaire 8 bits et 16 bits** (taux jusqu'aux limites du matériel). Les appareils DOIVENT prendre en charge les taux d'échantillonnage pour l'enregistrement PCM brut à des fréquences de 8 000, 16 000 et 44 100 Hz.	VAGUE (.wav)
Image	JPEG	REQUIS	REQUIS	Base+progressif	JPEG (.jpg)
	GIF		REQUIS		GIF (.gif)
	PNG	REQUIS	REQUIS		PNG (.png)
	PGB		REQUIS		BMP (.bmp)
	WEBP	REQUIS	REQUIS		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` .	REQUIS		3GPP (.3gp) MPEG-4 (.mp4)
	H.264AVC	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` .	REQUIS	Profil de base (PA)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, audio AAC uniquement, non consultable, Android 3.0+)
	MPEG-4SP		REQUIS		3GPP (.3gp)
	VP8****	REQUIS (Androïde 4.3+)	REQUIS (Android 2.3.3+)		WebM (.webm) et Matroska (.mkv, Android 4.0+)***
	VP9		REQUIS (Androïde 4.4+)		WebM (.webm) et Matroska (.mkv, Android 4.0+)***

*Remarque : seul un sous-mixage du contenu 5.0/5.1 est requis ; l'enregistrement ou le rendu de plus de 2 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 de périphériques DEVRAIENT prendre en charge l'écriture de fichiers Matroska WebM.
****Remarque : Pour une qualité acceptable des services de streaming vidéo Web et de vidéoconférence, les implémentations de périphériques DEVRAIENT utiliser un codec matériel VP8 qui répond aux exigences de [ Ressources, 86 ].

5.2. Encodage vidéo

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

	SD (basse qualité)	SD (haute qualité)	HD (lorsque pris en charge par le matériel)
Résolution vidéo	176 x 144 pixels	480 x 360 pixels	1280 x 720 pixels
Frame rate vidéo	12 images par seconde	30 images par seconde	30 images par seconde
Bitrate vidéo	56 Kbit/s	500 Kbit/s ou plus	2 Mbit/s ou plus
Un codec audio	AAC-LC	AAC-LC	AAC-LC
Canaux audio	1 (mono)	2 (stéréo)	2 (stéréo)
Bitrate audio	24 Kbit/s	128 Kbit/s	192 Kbit/s

	SD (basse qualité)	SD (haute qualité)	HD 720p (Lorsque pris en charge par le matériel)	HD 1080p (Lorsque pris en charge par le matériel)
Résolution vidéo	320 x 180 pixels	640 x 360 pixels	1280 x 720 pixels	1920 x 1080 pixels
Frame rate vidéo	30 images par seconde	30 images par seconde	30 images par seconde	30 images par seconde
Bitrate 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 DEVRAIENT prendre en charge les profils de décodage vidéo VP8, VP9 et H.264 suivants. Les mises en œuvre de périphériques DEVRAIENT également prendre en charge la commutation dynamique de résolution vidéo au sein du même flux pour les codecs VP8, VP9 et H.264.

	SD (basse qualité)	SD (haute qualité)	HD 720p (Lorsque pris en charge par le matériel)	HD 1080p (Lorsque pris en charge par le matériel)
Résolution vidéo	320 x 180 pixels	640 x 360 pixels	1280 x 720 pixels	1920 x 1080 pixels
Frame rate vidéo	30 images par seconde	30 images par seconde	30 images par seconde	30 images par seconde
Bitrate 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 démarrer l'enregistrement d'un flux audio, les implémentations de périphérique qui incluent du matériel de microphone et déclarent android.hardware.microphone DOIVENT échantillonner et enregistrer l'audio avec chacun de ces comportements :

Le dispositif DEVRAIT présenter des caractéristiques d'amplitude par rapport à la fréquence approximativement plates ; plus précisément, ±3 dB, de 100 Hz à 4000 Hz
La sensibilité de l'entrée audio DEVRAIT être réglée de telle sorte qu'une source de niveau de puissance sonore (SPL) de 90 dB à 1 000 Hz produise une valeur RMS de 2 500 pour des échantillons de 16 bits.
Les niveaux d'amplitude PCM DEVRAIENT suivre linéairement les changements de SPL d'entrée sur au moins une plage de 30 dB allant de -18 dB à +12 dB pour un SPL de 90 dB au niveau du microphone.
La distorsion harmonique totale DEVRAIT être inférieure à 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, s'il est présent, DOIT être désactivé.
Le contrôle automatique du gain, s'il est présent, DOIT être désactivé.

Depuis Android 4.4, la classe android.media.MediaRecorder.AudioSource a une nouvelle source audio : REMOTE_SUBMIX . Les appareils DOIVENT correctement implémenter 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 mélange de tous les flux audio, à l'exception des éléments suivants :

STREAM_RING
STREAM_ALARM
STREAM_NOTIFICATION

Remarque : bien que certaines des exigences décrites ci-dessus soient indiquées comme « DEVRAIT » depuis Android 4.3, la définition de compatibilité d'une future version est prévue pour les remplacer par « DOIT ». Autrement dit, ces exigences sont facultatives dans Android 4.4 mais seront requises par une future version. Les appareils existants et nouveaux fonctionnant sous Android sont fortement encouragés à répondre à ces exigences , sinon ils ne pourront pas atteindre la compatibilité Android lors de la mise à niveau vers la future version.

Si la plate-forme prend en charge les technologies de suppression du bruit adaptées à la reconnaissance vocale, l'effet DOIT être contrôlable à partir de l'API android.media.audiofx.NoiseSuppressor . De plus, le champ « uuid » pour le descripteur d'effet du suppresseur de bruit DOIT identifier de manière unique chaque mise en œuvre de la technologie de suppression du bruit.

5.5. Latence audio

La latence audio est le délai nécessaire au passage d'un signal audio à travers 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 une trame de données codées PCM et le moment où le son correspondant peut être entendu par un auditeur externe ou observé par un transducteur.
La « latence de sortie froide » est définie comme la latence de sortie pour la première image, lorsque le système de sortie audio a été inactif et mis hors tension avant la demande.
La « latence de sortie continue » est définie comme la latence de sortie pour les images suivantes, une fois que l'appareil est déjà en train de lire de l'audio.
La « latence d'entrée » est l'intervalle entre le moment où un son externe est présenté à l'appareil et le moment où une application lit la trame correspondante de données codé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 la première image, lorsque le système d'entrée audio a été inactif et mis hors tension avant la demande.
La « latence d'entrée continue » est définie comme la latence d'entrée pour les images suivantes, alors que l'appareil capture déjà l'audio.
« API de file d'attente de tampon OpenSL ES PCM » est l'ensemble des API OpenSL ES liées au PCM dans Android NDK ; voir racine_NDK /docs/opensles/index.html

Conformément à la section 5 , toutes les implémentations de périphériques compatibles DOIVENT inclure au moins une forme de sortie audio. Les implémentations de périphériques DEVRAIENT satisfaire ou dépasser ces exigences de latence de sortie :

latence de sortie froide de 100 millisecondes ou moins
latence de sortie continue de 45 millisecondes ou moins

Si une implémentation de périphérique répond aux exigences de cette section après tout étalonnage initial lors de l'utilisation de l'API de file d'attente de tampon OpenSL ES PCM, pour la latence de sortie continue et la latence de sortie froide sur au moins un périphérique de sortie audio pris en charge, 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 ] Inversement, si la mise en œuvre du périphérique ne répond pas à ces exigences, elle NE DOIT PAS signaler la prise en charge de l'audio à faible latence.

Conformément à la section 7.2.5 , le matériel du microphone peut être omis par les implémentations de périphériques.

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

latence d'entrée froide de 100 millisecondes ou moins
latence d'entrée continue de 50 millisecondes ou moins

5.6. Protocoles réseau

Les appareils DOIVENT prendre en charge les protocoles de réseau multimédia pour la lecture audio et vidéo, comme spécifié dans la documentation du SDK Android [ Ressources, 58 ]. Plus précisément, les appareils DOIVENT prendre en charge les protocoles de réseau multimédia suivants :

RTSP (RTP, SDP)
Streaming progressif HTTP(S)
Projet de protocole HTTP(S) Live Streaming, version 3 [ Ressources, 59 ]

6. Compatibilité des outils et des options de développement

6.1. Outils de développement

Les implémentations d'appareil DOIVENT prendre en charge les outils de développement Android fournis dans le SDK Android. Plus précisément, les appareils compatibles Android DOIVENT être compatibles avec :

Pont de débogage Android (connu sous le nom d'adb) [ Ressources, 33 ]
Les implémentations de périphériques DOIVENT prendre en charge toutes les fonctions adb telles que documentées dans le SDK Android. Le démon adb côté appareil DOIT être inactif par défaut et il DOIT y avoir un mécanisme accessible à l'utilisateur pour activer le pont de débogage Android.
Android inclut la prise en charge de la base de données sécurisée. Secure adb active adb sur des hôtes authentifiés connus. Les implémentations de périphériques DOIVENT prendre en charge la base de données sécurisée.
Service Dalvik Debug Monitor (connu sous le nom de ddms) [ Ressources, 33 ]
Les implémentations d'appareil DOIVENT prendre en charge toutes les fonctionnalités ddms telles que documentées dans le SDK Android. Comme ddms utilise adb , la prise en charge de ddms DEVRAIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé le pont de débogage Android, comme ci-dessus.
Singe [ Ressources, 36 ]
Les implémentations de périphériques DOIVENT inclure le framework Monkey et le rendre disponible pour les applications.
SysTrace [ Ressources, 33 ]
Les implémentations d'appareil DOIVENT prendre en charge l'outil systrace tel que documenté dans le SDK Android. Systrace doit être inactif par défaut et il DOIT y avoir un mécanisme accessible à l'utilisateur pour activer Systrace.

La plupart des systèmes basés sur Linux et des systèmes Apple Macintosh reconnaissent les appareils Android à l'aide des outils standard du SDK Android, sans prise en charge supplémentaire ; cependant, les systèmes Microsoft Windows nécessitent généralement un pilote pour les nouveaux appareils Android. (Par exemple, les nouveaux identifiants du fournisseur et parfois les nouveaux ID de périphérique nécessitent des pilotes USB personnalisés pour les systèmes Windows.) Si une implémentation de périphérique n'est pas reconnue par l'outil adb tel que prévu dans le SDK Android standard, les implémentateurs de périphériques doivent fournir des pilotes Windows permettant aux développeurs de se connecter à L'appareil utilisant le protocole adb . Ces pilotes doivent être fournis pour Windows XP, Windows Vista, Windows 7 et Windows 8, dans les versions 32 bits et 64 bits.

6.2. Options de développeur

Android inclut la prise en charge des développeurs pour configurer les paramètres liés au développement d'applications. Les implémentations de périphériques doivent honorer le Android.settings.application_development_settings l'intention de montrer les paramètres liés au développement des applications [ Resources, 77 ]. L'implémentation Android en amont masque le menu Options du développeur par défaut et permet aux utilisateurs de lancer des options de développeur après avoir appuyé sur sept (7) fois sur les paramètres> About Device> Build Number Menu élément. Les implémentations de l'appareil doivent fournir une expérience cohérente pour les options de développeur. Plus précisément, les implémentations de périphériques doivent masquer les options de développeur par défaut et doivent fournir un mécanisme pour activer les options de développeur conformément à l'implémentation Android en amont.

6.2.1. Expérimental

Android 4.4 présente Art, un runtime Android expérimental, accessible dans le menu Options du développeur pour l'aperçu. Les implémentations de l'appareil doivent inclure l'art (libart.so) et prendre en charge le double démarrage à partir des options de développeur, mais doivent conserver dalvik (libdvm.so) comme l'exécution par défaut.

7. Compatibilité matérielle

Si un périphérique comprend un composant matériel particulier qui a 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 Android SDK. Si une API du SDK interagit avec un composant matériel qui est indiqué comme facultatif et que l'implémentation de l'appareil ne possède pas ce composant:

Les définitions complètes des classes (comme documentées par le SDK) pour les API du composant doivent toujours être présentes
Les comportements de l'API doivent être mis en œuvre comme non optionnels d'une manière raisonnable
Les méthodes de l'API doivent renvoyer les valeurs nulles là où la documentation du SDK
Les méthodes API doivent renvoyer les implémentations sans opération de classes où les valeurs nulles ne sont pas autorisées par la documentation SDK
Les méthodes API ne doivent pas lancer des exceptions non documentées par la documentation SDK

Un exemple typique d'un scénario où ces exigences s'appliquent est l'API de téléphonie: même sur les dispositifs non téléphoniques, ces API doivent être implémentées en tant que non-opérations raisonnables.

Les implémentations de périphériques doivent signaler avec précision les informations précises de configuration matérielle via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) sur la classe android.content.pm.PackageManager . [ Ressources, 37 ]

7.1. Affichage et graphiques

Android comprend des installations qui ajustent automatiquement les actifs d'application et les dispositions d'interface utilisateur de manière appropriée pour l'appareil, afin de garantir que les applications tierces fonctionnent bien sur une variété de configurations matérielles [ Ressources, 38 ]. Les appareils doivent implémenter correctement ces API et comportements, comme détaillé dans cette section.

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

La "taille de diagonale physique" est la distance en pouces entre deux coins opposés de la partie illuminée de l'affichage.
"DPI" (ce qui signifie "points par pouce") est le nombre de pixels englobés par une portée horizontale ou verticale linéaire de 1 ". Lorsque les valeurs DPI sont répertoriées, le DPI horizontal et vertical doit se situer dans la plage.
Le "rapport d'aspect" est le rapport de la dimension plus longue de l'écran à la dimension plus courte. Par exemple, un affichage de 480x854 pixels serait 854/480 = 1,779, ou à peu près "16: 9".
Un "pixel indépendant de la densité" ou ("DP") est l'unité de pixel virtuelle normalisée à un écran de 160 dpi, calculée comme: pixels = dps * (density / 160) .

7.1.1. Configuration de l'écran

Taille de l'écran

Le framework d'interface utilisateur Android prend en charge une variété de tailles d'écran différentes et permet aux applications d'interroger la taille de l'écran de l'appareil (alias "disposition d'écran") via android.content.res.Configuration.screenLayout avec le SCREENLAYOUT_SIZE_MASK . Les implémentations de périphériques doivent signaler la taille de l'écran correcte telle que définie dans la documentation Android SDK [ Ressources, 38 ] et déterminée par la plate-forme Android en amont. Plus précisément, les implémentations de périphériques doivent signaler la taille de l'écran correcte en fonction des dimensions d'écran de pixels (DP) indépendantes de la densité logique suivantes.

Les appareils doivent avoir des tailles d'écran d'au moins 426 dp x 320 dp («petit»)
Les appareils qui signalent la taille de l'écran «normal» doivent avoir des tailles d'écran d'au moins 480 dp x 320 dp
Les appareils qui rapportent la taille de l'écran «grande» doivent avoir des tailles d'écran d'au moins 640 dp x 480 dp
Les appareils qui signalent la taille de l'écran «Xlarge» doivent avoir des tailles d'écran d'au moins 960 dp x 720 dp

De plus, les appareils doivent avoir des tailles d'écran d'au moins 2,5 pouces de taille diagonale physique.

Les appareils ne doivent pas modifier leur taille d'écran signalée à tout moment.

Les applications indiquent éventuellement les tailles d'écran qu'elles prennent en charge via l'attribut <supports-screens> dans le fichier AndroidManifest.xml. Les implémentations de l'appareil doivent honorer correctement la prise en charge indiquée des applications pour les écrans petits, normaux, grands et xlarge, comme décrit dans la documentation Android SDK.

Rapport hauteur/largeur de l'écran

Le rapport d'aspect doit être une valeur de 1,3333 (4: 3) à 1,86 (environ 16: 9)

Densité d'écran

Le cadre d'interface utilisateur Android définit un ensemble de densités logiques standard pour aider les développeurs d'applications cibles des ressources d'application. Les implémentations de périphériques doivent signaler l'une des densités de framework Android logiques suivantes via les API android.util.DisplayMetrics et doivent exécuter des applications à cette densité standard.

120 DPI, connu sous le nom de «LDPI»
160 DPI, connu sous le nom de «MDPI»
213 DPI, connu sous le nom de 'TVDPI'
240 DPI, connu sous le nom de «HDPI»
320 dpi, connu sous le nom de «xhdpi»
400 dpi, connu sous le nom de «400dpi»
480 dpi, connu sous le nom de «xxhdpi»
640 dpi, connu sous le nom de «xxxhdpi»

Les implémentations de l'appareil doivent définir la densité du cadre Android standard qui est numériquement la plus proche de la densité physique de l'écran, à moins que la densité logique pousse la taille de l'écran rapportée en dessous du minimum pris en charge. Si la densité du cadre Android standard qui est numériquement la plus proche de la densité physique se traduit par une taille d'écran plus petite que la taille d'écran compatible la plus petite prise en charge (320 dp largeur), les implémentations de périphériques doivent signaler la densité de framework Android standard la plus basse suivante.

7.1.2. Afficher les métriques

Les implémentations de périphériques doivent signaler les valeurs correctes pour toutes les mesures d'affichage définies dans android.util.DisplayMetrics [ Resources, 39 ].

7.1.3. Orientation de l'écran

Les appareils doivent prendre en charge l'orientation dynamique par des applications à l'orientation du portrait ou du paysage. C'est-à-dire que l'appareil doit respecter la demande de l'application pour une orientation d'écran spécifique. Les implémentations de l'appareil peuvent sélectionner l'orientation du portrait ou du paysage par défaut.

Les périphériques doivent signaler la valeur correcte de l'orientation actuelle de l'appareil, chaque fois que vous êtes interrogé via le android.content.res.configuration.orientation, Android.view.display.getOrientation (), ou d'autres API.

Les appareils ne doivent pas modifier la taille ou la densité de l'écran rapportée lors du changement d'orientation.

Les appareils doivent signaler les orientations d'écran qu'ils prennent en charge ( android.hardware.screen.portrait et / ou android.hardware.screen.landscape ) et doivent signaler au moins une orientation prise en charge. Par exemple, un appareil avec un écran de paysage d'orientation fixe, comme un téléviseur ou un ordinateur portable, ne doit signaler android.hardware.screen.landscape .

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

Les implémentations de périphériques doivent prendre en charge OpenGL ES 1.0 et 2.0, comme incarnée et détaillée dans les documentations Android SDK. Les implémentations de périphériques doivent prendre en charge OpenGL ES 3.0 sur les périphériques capables de prendre en charge OpenGL ES 3.0. Les implémentations de périphériques doivent également prendre en charge Android Renderscript, comme détaillé dans la documentation Android SDK [ Resources, 8 ].

Les implémentations de périphériques doivent également s'identifier correctement comme prenant en charge OpenGL ES 1.0, OpenGL ES 2.0 ou OpenGL ES 3.0. C'est-à-dire:

Les API gérées (comme via la méthode GLES10.getString() ) doivent signaler la prise en charge d'OpenGl ES 1.0 et OpenGL ES 2.0
Les API natives C / C ++ OpenGL (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 OpenGL ES 2.0.
Les implémentations de périphériques qui déclarent la prise en charge d'OpenGL ES 3.0 doivent prendre en charge les API gérées OpenGL ES 3.0 et inclure la prise en charge des API C / C ++ natives. Sur les implémentations de périphériques 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 de périphériques peuvent implémenter toutes les extensions OpenGl ES souhaitées. Cependant, les implémentations de périphériques doivent signaler via les API gérées et natives OpenGl ES toutes les chaînes d'extension qu'ils prennent en charge, et à l'inverse ne doit pas signaler les chaînes d'extension qu'ils ne soutiennent pas.

Notez qu'Android inclut la prise en charge des applications pour spécifier éventuellement qu'elles nécessitent des formats de compression de texture OpenGL spécifiques. Ces formats sont généralement spécifiques au fournisseur. Android n'est pas requis par Android pour implémenter un format de compression de texture spécifique. Cependant, ils doivent signaler avec précision les formats de compression de texture qu'ils prennent en charge, via la méthode getString() dans l'API OpenGL.

Android comprend un mécanisme pour les applications pour déclarer qu'ils voulaient 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 via l'utilisation d'une balise manifeste android:hardwareAccelerated ou des appels API directs [ Ressources, 9 ].

Dans dans la par défaut, dans les implémentations de périphériques, les implémentations de périphériques doivent activer l'accélération matérielle et désactiver l'accélération matérielle si le développeur demande donc en définissant android:hardwareAccelerated="false" ou désactiver l'accélération matérielle directement via les API Android View.

De plus, les implémentations de périphériques doivent présenter un comportement cohérent avec la documentation Android SDK sur l'accélération matérielle [ Ressources, 9 ].

Android comprend un objet TextureView qui permet aux développeurs d'intégrer directement les textures OpenGL ES accélérées par le matériel en tant que cibles de rendu dans une hiérarchie d'interface utilisateur. Les implémentations de périphériques doivent prendre en charge l'API TextureView et doivent présenter un comportement cohérent avec l'implémentation Android en amont.

Android inclut la prise en charge d' EGL_ANDROID_RECORDABLE , un attribut eGlConfig qui indique si l'EGLConfig prend en charge le rendu à un anativewindow qui enregistre des images à une vidéo. Les implémentations de périphérique doivent prendre en charge l' EGL_ANDROID_RECORDABLE Extension [ Ressources, 79 ].

7.1.5. Mode de compatibilité des applications héritées

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne dans un mode équivalent d'écran "normal" (largeur 320dp) au profit des applications héritées non développées pour les anciennes versions d'Android qui prédisaient l'indépendance de la taille d'un écran. Les implémentations de périphériques doivent inclure la prise en charge du mode de compatibilité des applications héritées telles qu'implémentées par le code open source Android en amont. Autrement dit, les implémentations de l'appareil ne doivent pas modifier les déclencheurs ou les seuils auxquels le mode de compatibilité est activé et ne doit pas modifier le comportement du mode de compatibilité lui-même.

7.1.6. Types d'écran

Les écrans d'implémentation des appareils sont classés comme l'un des deux types:

Implémentations d'affichage à pixels fixes: l'écran est un seul panneau qui ne prend en charge qu'une seule largeur et hauteur de pixels. En règle générale, l'écran est physiquement intégré à l'appareil. Les exemples incluent les téléphones mobiles, les tablettes, etc.
Implémentations d'affichage de pixels variables: l'implémentation de l'appareil n'a pas d'écran embarqué et comprend un port de sortie vidéo tel que VGA, HDMI ou un port sans fil pour l'affichage, ou a un écran embarqué qui peut modifier les dimensions de pixels. Les exemples incluent les téléviseurs, les décodeurs, etc.

Implémentations de périphériques à pixels fixes

Les implémentations de périphériques à pixels fixes peuvent utiliser des écrans de toutes les dimensions de pixels, à condition qu'elles répondent aux exigences définies par cette définition de compatibilité.

Les implémentations à pixels fixes peuvent inclure un port de sortie vidéo pour une utilisation avec un affichage externe. Cependant, si cet affichage est utilisé pour exécuter des applications, l'appareil doit répondre aux exigences suivantes:

L'appareil doit signaler la même configuration d'écran et les mesures d'affichage, comme détaillé dans les sections 7.1.1 et 7.1.2, comme l'affichage du pixel fixe.
L'appareil doit signaler la même densité logique que l'affichage à pixels fixe.
L'appareil doit signaler les dimensions de l'écran qui sont les mêmes ou très proches de l'affichage à pixels fixe.

Par exemple, une tablette de 7 "diagonale avec une résolution 1024x600 pixels est considérée ne sont exécutés que dans une grande fenêtre MDPI, que le port d'affichage ou de sortie vidéo à pixels fixe soit utilisé.

Implémentations de périphériques à pixels variables

Les implémentations de périphériques à pixels variables doivent prendre en charge au moins un des 1280x720, 1920x1080 ou 3840x2160 (c'est-à-dire 720p, 1080p ou 4k). Les implémentations de périphérique avec des affichages de pixels variables ne doivent prendre en charge aucune autre configuration ou mode d'écran. Les implémentations de périphérique avec des écrans de pixels variables peuvent modifier la configuration ou le mode d'é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 de périphériques à pixels variables doivent signaler les compartiments de configuration suivants pour ces dimensions de pixels:

1280x720 (également connu sous le nom de 720p): «grande» taille d'écran, densité «tvdpi» (213 dpi)
1920x1080 (également connu sous le nom de 1080p): «grande» taille d'écran, «xhdpi» (320 dpi) densité
3840x2160 (également connu sous le nom de 4K): «grande» taille d'écran, «xxxhdpi» (640 dpi)

Pour plus de clarté, les implémentations de périphériques avec des dimensions de pixels variables sont limitées à 720p, 1080p ou 4k dans Android 4.4, et doivent être configurées pour signaler la taille de l'écran et les seaux de densité comme indiqué ci-dessus.

7.1.7. Technologie d'écran

La plate-forme Android comprend des API qui permettent aux applications de rendre des graphiques riches à l'affichage. Les appareils doivent prendre en charge toutes ces API telles que définies par le SDK Android, sauf si spécifiquement autorisé dans ce document. Spécifiquement:

Les appareils doivent prendre en charge les écrans capables de rendre des graphiques couleur 16 bits et doivent prendre en charge les affichages capables de graphiques couleur 24 bits.
Les appareils doivent prendre en charge les écrans capables de rendre des animations.
La technologie d'affichage utilisée doit avoir un rapport d'aspect pixel (PAR) entre 0,9 et 1,1. C'est-à-dire que le rapport d'aspect pixel doit être proche du carré (1,0) avec une tolérance de 10%.

7.1.8. Écrans externes

Android inclut la prise en charge de l'affichage secondaire pour activer les capacités de partage des médias et les API des développeurs pour accéder aux écrans externes. Si un périphérique prend en charge un affichage externe via une connexion d'affichage câblée, sans fil ou intégré, la mise en œuvre de l'appareil doit implémenter l'API Display Manager comme décrit dans la documentation Android SDK [ Resources, 75 ]. Les implémentations de périphériques qui prennent en charge la sortie vidéo sécurisée et sont 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 de périphériques qui déclarent la prise en charge de Display.FLAG_SECURE , doivent prendre en charge HDCP 2.x ou plus pour les écrans sans fil Miracast ou HDCP 1.2 ou plus pour les écrans câblés. L'implémentation open source Android en amont comprend la prise en charge des affichages sans fil (Miracast) et Wired (HDMI) qui satisfait à cette exigence.

7.2. Des dispositifs d'entrée

7.2.1. Clavier

Implémentations d'appareils :

Doit inclure la prise en charge du cadre de gestion des entrées (qui permet aux développeurs tiers de créer des moteurs de gestion des entrées - IE Soft Keyboard) comme détaillé sur http://developer.android.com
Doit fournir au moins une implémentation du clavier souple (peu importe si un clavier dur est présent)
Peut inclure des implémentations de clavier souples supplémentaires
Peut inclure un clavier matériel
Ne doit pas inclure un clavier matériel qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard [ Resources, 40 ] (c'est-à-dire Qwerty ou 12 key)

7.2.2. Navigation non tactile

Implémentations d'appareils :

Peut omettre une option de navigation non touchée (c'est-à-dire peut omettre un trackball, un d-pad ou une roue)
Doit signaler 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 l'édition du texte, compatibles avec les moteurs de gestion des entrées. L'implémentation Open Source Android en amont comprend un mécanisme de sélection adapté à une utilisation avec des périphériques qui manquent d'entrées de navigation non touchés.

7.2.3. Touches de navigation

La maison, les récentes et les fonctions de dos sont essentielles au paradigme de navigation Android. Les implémentations de l'appareil doivent rendre ces fonctions à la disposition de l'utilisateur à tout moment lors de l'exécution des 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 peuvent être implémentés à l'aide de touches logicielles dédiées sur une partie distincte de l'écran, des gestes, du panneau tactile, etc. Android prend en charge les deux implémentations. Toutes ces fonctions doivent être accessibles avec une seule action (par exemple, TAP, double-cliquez ou geste) lorsqu'il est visible.

Les fonctions Back and Recents doivent avoir un bouton ou une icône visible à moins que ce soit caché avec d'autres fonctions de navigation en mode plein écran. La fonction domestique doit avoir un bouton ou une icône visible à moins que ce soit caché avec d'autres fonctions de navigation en mode plein écran.

La fonction de menu est obsolète en faveur de la barre d'action depuis Android 4.0. Les implémentations de périphérique ne doivent pas implémenter un bouton physique dédié pour la fonction de menu. Si le bouton de menu physique est implémenté et que l'appareil exécute des applications avec targetSdkVersion > 10, l'implémentation de l'appareil:

Pour un lancement d'un appareil avec Android 4.4, doit afficher le bouton de débordement d'action sur la barre d'action lorsque la barre d'action est visible et le menu de débordement d'action résultant n'est pas vide.
Pour un appareil existant lancé avec une version antérieure mais la mise à niveau vers Android 4.4, devrait afficher le bouton de débordement d'action sur la barre d'action lorsque la barre d'action est visible et que la fenêtre de menu d'action résultante n'est pas vide.
Ne doit pas modifier la position de la fenêtre de débordement d'action affichée en sélectionnant le bouton de débordement dans la barre d'action.
Peut rendre la fenêtre de débordement d'action à une position modifiée sur l'écran lorsqu'elle est affichée en sélectionnant le bouton de menu physique.

Pour la compatibilité en arrière, les implémentations de périphériques doivent mettre à disposition la fonction de menu aux applications lorsque targetSdkVersion <= 10, soit par un bouton physique, une clé logicielle ou des gestes. Cette fonction de menu doit être présentée à moins que les autres fonctions de navigation.

Android prend en charge Assist Action [ Resources, 63 ]. Les implémentations de l'appareil doivent mettre l'action d'assistance à la disposition de l'utilisateur à tout moment lors de l'exécution des applications. L'action d'assistance doit être mise en œuvre comme une pression longue sur le bouton d'accueil ou un geste de balayage sur la touche d'accueil du logiciel. Cette fonction peut être implémentée via un autre bouton physique, une clé logicielle ou des gestes, mais doit être accessible avec une seule action (par exemple, TAP, double-cliquez ou geste) lorsque d'autres touches de navigation sont visibles.

Les implémentations de l'appareil peuvent utiliser une partie distincte de l'écran pour afficher les touches de navigation, mais si c'est le cas, il faut répondre à ces exigences:

Les clés de navigation de l'implémentation des appareils doivent utiliser une partie distincte de l'écran, non disponible pour les applications, et ne doivent pas obscurcir ou interférer autrement avec la partie de l'écran disponible pour les applications.
Les implémentations de l'appareil doivent mettre à disposition une partie de l'affichage aux applications qui répondent aux exigences définies à la section 7.1.1 .
Les implémentations de périphérique 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 de périphérique doivent présenter les clés de navigation dans un mode discret "profil bas" (par exemple, Damed) lorsque les applications spécifient SYSTEM_UI_FLAG_LOW_PROFILE .
Les implémentations de périphérique doivent masquer les touches de navigation lorsque les applications spécifient SYSTEM_UI_FLAG_HIDE_NAVIGATION .

7.2.4. Saisie sur écran tactile

Les implémentations de périphérique doivent avoir un système d'entrée de pointeur quelconque (soit de type souris, soit toucher). Cependant, si une implémentation de périphérique ne prend pas en charge un système de pointeur, il ne doit pas signaler la fonctionnalité android.hardware.touchscreen ou android.hardware.faketouch . Les implémentations de périphériques qui incluent un système d'entrée de pointeur:

Devrait prendre en charge les pointeurs entièrement suivis indépendamment, si le système d'entrée de l'appareil prend en charge plusieurs pointeurs
Doit signaler la valeur de android.content.res.Configuration.touchscreen [ Ressources, 40 ] correspondant au type de l'écran tactile spécifique sur l'appareil

Android comprend la prise en charge d'une variété d'écrans tactiles, de pads tactiles et de faux périphériques d'entrée tactile. Les implémentations de périphériques basées sur l'écran tactile sont associées à un affichage [ Ressources, 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 ne nécessite aucune offre supplémentaire pour indiquer les objets manipulés. En revanche, une fausse interface tactile fournit un système d'entrée utilisateur qui se rapproche d'un sous-ensemble de capacités à écran tactile. Par exemple, une souris ou une télécommande qui entraîne un curseur à l'écran se rapproche du toucher, mais nécessite que l'utilisateur pointe ou se concentre puis cliquez. De nombreux dispositifs d'entrée comme la souris, le trackpad, la souris aérienne à base de gyroscope, le gyroscoptère, le joystick et le trackpad multi-tacles peuvent prendre en charge les fausses interactions tactiles. Android 4.0 comprend la fonctionnalité constante android.hardware.faketouch , qui correspond à un dispositif d'entrée non-touché à haute fidélité (c'est-à-dire basé sur le pointeur tel qu'une souris ou un trackpad qui peut émuler une entrée tactile adéquate (y compris le geste de base Prise en charge), et indique que le périphérique prend en charge un sous-ensemble émulé de fonctionnalité à écran tactile. Les implémentations de l'appareil qui déclarent la fonction de fausse touche doivent répondre aux fausses exigences tactiles de la section 7.2.5 .

Les implémentations de périphérique doivent signaler la fonction correcte correspondant au type d'entrée utilisé. Les implémentations de périphériques qui incluent un écran tactile (unique ou mieux) doivent signaler la fonction de plate-forme constante android.hardware.touchscreen . Les implémentations de périphériques qui rapportent la fonction de plate-forme constante android.hardware.touchscreen doivent également signaler la fonctionnalité de plate-forme constante android.hardware.faketouch . Les implémentations de périphériques qui n'incluent pas d'écran tactile (et qui s'appuient uniquement sur un périphérique de pointeur) ne doivent signaler aucune fonctionnalité tactile et ne doivent signaler que android.hardware.faketouch s'ils répondent aux fausses exigences tactiles de la section 7.2.5 .

7.2.5. Fausse saisie tactile

Implémentations de l'appareil qui déclarent la prise en charge de android.hardware.faketouch

Doit signaler les positions d'écran 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 [ Ressources, 80 ] qui spécifie le changement d'état qui se produit sur le pointeur en down ou up l'écran [ Resources, 80 ]
Doit prendre en charge le pointeur down et up sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler Appuyez sur un objet à l'écran
Doit prendre en charge le pointeur down , pointeur up , pointeur down puis pointer up au même endroit sur un objet sur l'écran dans un seuil de temps, ce qui permet aux utilisateurs d'imiter le double appuyer sur un objet sur l'écran [ Resources, 80 ]
Doit prendre en charge le pointeur down sur un point arbitraire à l'écran, le pointeur se déplace vers tout autre point arbitraire de l'écran, suivi d'un pointeur up , qui permet aux utilisateurs d'imiter une glisser
Doit prendre en charge le pointeur down pour permettre aux utilisateurs de déplacer rapidement l'objet vers une position différente à l'écran, puis de pointer up sur l'écran, ce qui permet aux utilisateurs de lancer un objet à l'écran

Les appareils qui déclarent la prise en charge de android.hardware.faketouch.multitouch.distinct doivent répondre aux exigences pour FAKETOUCH ci-dessus, et doivent également prendre en charge le suivi distinct de deux ou plusieurs entrées de pointeur indépendantes.

7.2.6. Microphone

Les implémentations de l'appareil peuvent omettre un microphone. Cependant, si une implémentation de périphérique omet un microphone, il ne doit pas signaler la fonctionnalité android.hardware.microphone et doit implémenter l'API d'enregistrement audio en tant qu'OPO, par section 7 . Inversement, les implémentations de périphériques qui possèdent un microphone:

Doit signaler la fonctionnalité android.hardware.microphone constante
Devrait répondre aux exigences de qualité audio dans la section 5.4
Devrait répondre aux exigences de latence audio dans la section 5.5

7.3. Capteurs

Android comprend des API pour accéder à une variété de types de capteurs. Les implémentations des appareils peuvent généralement omettre ces capteurs, comme prévu dans les sous-sections suivantes. Si un appareil comprend un type de capteur particulier qui a 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 Android SDK. Par exemple, les implémentations de l'appareil:

Doit signaler avec précision la présence ou l'absence de capteurs par la classe android.content.pm.PackageManager . [ Ressources, 37 ]
Doit retourner une liste précise de capteurs pris en charge via SensorManager.getSensorList() et des méthodes similaires
Doit se comporter raisonnablement pour toutes les autres API de capteurs (par exemple, en renvoyant True ou Faux, selon les applications, les applications tentent d'enregistrer les auditeurs, sans appeler les auditeurs de capteurs lorsque les capteurs correspondants ne sont pas présents; etc.)
Doit signaler toutes les mesures de capteurs en utilisant les valeurs internationales du système international pertinent (IE Metric) pour chaque type de capteur tel que défini dans la documentation Android SDK [ Resources, 41 ]

La liste ci-dessus n'est pas complète; 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. (Les exemples incluent le capteur d'orientation et le capteur d'accélération linéaire.) Les implémentations de l'appareil doivent implémenter ces types de capteurs, lorsqu'ils incluent les capteurs physiques préalables.

Android comprend une notion de capteur de "streaming", qui est celle qui renvoie les données en continu, plutôt que uniquement lorsque les données changent. Les implémentations de périphériques doivent fournir en continu des échantillons de données périodiques pour toute API indiquée par la documentation du SDK Android comme un capteur de streaming. Notez que les implémentations de l'appareil doivent garantir que le flux de capteurs ne doit pas empêcher le processeur de l'appareil d'entrer dans un état de suspension ou de se réveiller d'un état de suspension.

7.3.1. Accéléromètre

Les implémentations de l'appareil doivent inclure un accéléromètre à 3 axes. Si une implémentation de périphérique comprend un accéléromètre à 3 axes, IT:

Devrait être en mesure de livrer des événements à 120 Hz ou plus. Notez que bien que la fréquence accéléromètre ci-dessus soit indiquée comme "doit" pour Android 4.4, la définition de compatibilité pour une future version est prévue pour les changer en "MUST". Autrement dit, ces normes sont facultatives dans Android mais seront nécessaires dans les versions futures. Les appareils existants et nouveaux qui exécutent Android sont très fortement encouragés à répondre à ces exigences dans Android afin qu'ils puissent passer vers les futures versions de la plate-forme
Doit se conformer au système de coordonnées du capteur Android comme détaillé dans les API Android (voir [ Resources, 41 ])
Doit être capable de mesurer de la chute libre jusqu'à deux fois la gravité (2G) ou plus sur un vecteur tridimensionnel
Doit avoir 8 bits de précision ou plus
Doit avoir un écart-type pas supérieur à 0,05 m / s ^ 2

7.3.2. Magnétomètre

Les implémentations de l'appareil doivent inclure un magnétomètre à 3 axes (c.-à-d. Compass.) Si un appareil comprend un magnétomètre à 3 axes, IT:

Doit être en mesure de livrer des événements à 10 Hz ou plus
Doit se conformer au système de coordonnées du capteur Android comme détaillé dans les API Android (voir [ Ressources, 41 ]).
Doit être capable d'échantillonner une gamme de forces de champ adéquates pour couvrir le champ géomagnétique
Doit avoir 8 bits de précision ou plus
Doit avoir un écart-type ne dépassant pas 0,5 µt

7.3.3. GPS

Les implémentations de l'appareil doivent inclure un récepteur GPS. Si une implémentation de périphérique comprend un récepteur GPS, il doit inclure une forme de technique "assistée GPS" pour minimiser le temps de verrouillage GPS.

7.3.4. Gyroscope

Les implémentations de dispositifs doivent inclure un capteur de changement de gyroscope (c.-à-d.) Les appareils ne doivent pas inclure de capteur de gyroscope à moins qu'un accéléromètre à 3 axes ne soit également inclus. Si une implémentation de périphérique comprend un gyroscope, IT:

Doit être compensé par la température.
Doit être capable de mesurer des changements d'orientation jusqu'à 5,5 * Pi Radians / Second (c'est-à-dire environ 1 000 degrés par seconde).
Devrait être en mesure de livrer 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 est prévue pour les changer en "Must". Autrement dit, ces normes sont facultatives dans Android mais seront nécessaires dans les versions futures. Les appareils existants et nouveaux qui exécutent Android sont très fortement encouragés à répondre à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
Doit avoir 12 bits de précision ou plus
Doit avoir une variance pas supérieure à 1e-7 rad ^ 2 / s ^ 2 par Hz (variance par Hz, ou rad ^ 2 / s). La variance peut varier avec le taux d'échantillonnage, mais doit être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyro à 1 Hz d'échantillonnage, il ne devrait pas être supérieur à 1e-7 rad ^ 2 / s ^ 2.
Doit avoir des horodatages aussi près du lorsque l'événement matériel s'est produit que possible. La latence constante doit être supprimée.

7.3.5. Baromètre

Les implémentations de l'appareil peuvent inclure un baromètre (c.-à-d. Capteur de pression d'air ambiant.) Si une implémentation de l'appareil comprend un baromètre, IT:

Doit être capable de livrer des événements à 5 Hz ou plus
Doit avoir une précision adéquate pour permettre l'estimation de l'altitude
Doit être compensé la température

7.3.6. Thermomètre

Les implémentations de l'appareil peuvent inclure un thermomètre ambiant (c.-à-d. Le capteur de température). S'il est présent, il doit être défini comme SENSOR_TYPE_AMBIENT_TEMPERATURE et il doit mesurer la température ambiante (pièce) en degrés Celsius.

Les implémentations de l'appareil peuvent mais ne devraient pas inclure un capteur de température CPU. S'il doit être défini comme SENSOR_TYPE_TEMPERATURE , il doit mesurer la température du processeur du dispositif, et il ne doit pas mesurer aucune autre température. Remarque Le type de capteur SENSOR_TYPE_TEMPERATURE a été déprécié dans Android 4.0.

7.3.7. Photomètre

Les implémentations de l'appareil peuvent inclure un photomètre (c.-à-d. Capteur de lumière ambiante.)

7.3.8. Capteur de proximité

Les implémentations de l'appareil peuvent inclure un capteur de proximité. Si une implémentation de périphérique comprend un capteur de proximité, il doit mesurer la proximité d'un objet dans le même sens que l'écran. C'est-à-dire que le capteur de proximité doit être orienté pour détecter des objets proches de l'écran, car l'intention principale de ce type de capteur est de détecter un téléphone utilisé par l'utilisateur. Si une implémentation de périphérique comprend un capteur de proximité avec toute autre orientation, il ne doit pas être accessible via cette API. Si une implémentation de périphérique a un capteur de proximité, il doit être 1 bits de précision ou plus.

7.4. Connectivité des données

7.4.1. Téléphonie

"Téléphonie" tel qu'utilisé par les API Android et ce document fait référence spécifiquement au matériel lié à la mise en place 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 à commutation de paquets, ils sont aux fins d'Android considérés comme indépendants de toute connectivité de données qui peut être implémentée à l'aide du même réseau. En d'autres termes, la fonctionnalité et les API de la téléphonie Android se réfèrent spécifiquement aux appels vocaux et aux SMS; Par exemple, les implémentations de périphériques qui ne peuvent pas placer les appels ou envoyer / recevoir des messages SMS ne doivent pas signaler la fonctionnalité "Android.hardware.tephony" ou toute sous-fonction, qu'elles utilisent un réseau cellulaire pour la connectivité des données.

Android peut être utilisé sur des appareils qui n'incluent pas le matériel de téléphonie. Autrement dit, Android est compatible avec des appareils qui ne sont pas des téléphones. Cependant, si une implémentation de périphérique inclut la téléphonie GSM ou CDMA, elle doit implémenter une prise en charge complète de l'API pour cette technologie. Les implémentations de périphériques qui n'incluent pas le matériel de téléphonie doivent implémenter les API complètes en tant que non-opérations.

7.4.2. IEEE 802.11 (Wi-Fi)

Les implémentations de périphériques Android doivent inclure la prise en charge d'une ou plusieurs formes de 802.11 (b / g / a / n, etc.) Si une implémentation de périphérique inclut la prise en charge du 802.11, il doit implémenter l'API Android correspondant.

Les implémentations de périphériques doivent implémenter l'API de multidiffusion comme décrit dans la documentation SDK [ Resources, 62 ]. Les implémentations de périphériques qui incluent la prise en charge Wi-Fi doivent prendre en charge la multidiffusion DNS (MDN). Les implémentations de l'appareil ne doivent pas filtrer les paquets MDNS (224.0.0.251) à tout moment de fonctionnement, y compris lorsque l'écran n'est pas dans un état actif.

7.4.2.1. Wi-Fi Direct

Les implémentations de l'appareil doivent inclure la prise en charge du Wi-Fi Direct (Wi-Fi Peer-to-Peer). Si une implémentation de périphérique inclut la prise en charge du Wi-Fi Direct, il doit implémenter l'API Android correspondant comme décrit dans la documentation SDK [ Resources, 68 ]. Si une implémentation de périphérique inclut la prise en charge du Wi-Fi Direct, alors IT:

Doit soutenir l'opération Wi-Fi régulière
Devrait prendre en charge le fonctionnement direct Wi-Fi et Wi-Fi simultanément

7.4.2.2. Configuration du lien direct tunnelé Wi-Fi

Les implémentations de périphériques doivent inclure la prise en charge de la configuration des liens directs tunnels Wi-Fi (TDLS) comme décrit dans la documentation Android SDK [ Resources, 85 ]. Si une implémentation de périphérique inclut la prise en charge de TDLS et TDLS est activée par l'API WifiManager, le périphérique:

Ne devrait utiliser TDLS que lorsqu'il est possible et bénéfique.
Devrait avoir une heuristique et ne pas utiliser TDL lorsque ses performances peuvent être pires que de passer par le point d'accès Wi-Fi.

7.4.3. Bluetooth

Les implémentations de l'appareil doivent inclure un émetteur-récepteur Bluetooth. Les implémentations de périphériques qui incluent un émetteur-récepteur Bluetooth doivent activer l'API Bluetooth basée sur RFCOMM comme décrit dans la documentation SDK et déclarer la fonctionnalité matérielle Android.Hardware.Bluetooth [ Resources, 42 ]. Les implémentations de périphériques doivent implémenter les profils Bluetooth pertinents, tels que A2DP, AVRCP, OBEX, etc., le cas échéant pour l'appareil.

Les implémentations de périphériques qui incluent la prise en charge de Bluetooth GATT (Profil d'attribut générique) pour activer la communication avec les appareils Bluetooth Smart ou Smart Ready doivent activer l'API Bluetooth basée sur GATT comme décrit dans la documentation SDK et Declare Fonction matérielle Android.Hardware.Bluetooth_le [ Ressources, 42 ].

7.4.4. Near Field Communications

Les implémentations de périphériques doivent inclure un émetteur-récepteur et un matériel connexe pour les communications en champ proche (NFC). Si une implémentation de périphérique inclut le matériel NFC, alors IT:

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 d'agir en tant que lecteur / écrivain du forum NFC (tel que défini par la spécification technique du forum NFC NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes:
  - NFCA (ISO14443-3A)
  - NFCB (ISO14443-3B)
  - NFCF (JIS 6319-4)
  - Isodep (ISO 14443-4)
  - NFC Forum Tag Types 1, 2, 3, 4 (défini par le forum NFC)
Devrait être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes. Notez que même si les normes NFC ci-dessous sont indiquées comme "devraient", la définition de compatibilité d'une future version est prévue pour les changer en "MUST". Autrement dit, ces normes sont facultatives dans cette version, mais seront nécessaires dans les versions futures. Les appareils existants et nouveaux qui exécutent cette version d'Android sont très fortement encouragés à répondre à ces exigences maintenant afin qu'ils puissent passer vers les 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 de pair à pair:
- ISO 18092
- LLCP 1.0 (défini par le forum NFC)
- SDP 1.0 (défini par le forum NFC)
- Protocole de push NDEF [ Ressources, 43 ]
- SNEP 1.0 (défini par le forum NFC)
Doit inclure la prise en charge de 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 envoyés aux applications à l'aide de l'intention Android.nfc.Action_NDEF_Discovered. La désactivation du faisceau Android dans les paramètres ne doit pas désactiver l'envoi du message NDEF entrant.
- Les implémentations de périphériques doivent honorer le Android.settings.nfcsharing_settings l'intention d'afficher les paramètres de partage NFC [ Resources, 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 P2P NDEF sortant au serveur SNEP par défaut lorsque le faisceau Android est activé. Si aucun serveur SNEP par défaut n'est trouvé, le client doit tenter d'envoyer à un serveur NPP.
- Doit permettre aux activités de premier plan pour définir le message P2P NDEF sortant à l'aide d'Android.nfc.nfcadapter.setndefpushMessage et Android.nfc.nfcadapter.SetndefpushMessageCallback et Android.nfc.nfcadapter.enablefoughndefpush.
- Devrait utiliser une confirmation de geste ou à l'écran, telle que «Touch to Beam», avant d'envoyer des messages P2P NDEF sortants.
- Devrait activer le faisceau Android par défaut
- Doit prendre en charge le transfert de connexion NFC à Bluetooth lorsque l'appareil prend en charge le profil push Bluetooth. Les implémentations de périphériques doivent prendre en charge le transfert de connexion à Bluetooth lors de l'utilisation d'Android.nfc.nfcadapter.setBeampushuris, en implémentant la "version de connexion version 1.2" [ Resources, 60 ] et "Bluetooth sécurisé simple apparié à l'aide de NFC version 1.0" [ Resources, 61 ] le forum NFC. Une telle implémentation doit implémenter le service de transfert LLCP avec le nom du service "URN: NFC: SN: transfert" pour échanger la demande de transfert / sélectionner les enregistrements via NFC, et il doit utiliser le profil push de l'objet Bluetooth pour le transfert de données Bluetooth réel. Pour des raisons héritées (pour rester compatibles avec les appareils Android 4.1), l'implémentation doit toujours accepter les demandes SNEP Get pour l'échange des enregistrements de requête / sélection de transfert sur NFC. Cependant, une implémentation elle-même ne doit pas envoyer de demandes SNEP Get pour effectuer un transfert de connexion.
Doit interroger toutes les technologies prises en charge en mode Discovery NFC.
Devrait être en mode Discovery NFC pendant que l'appareil est éveillé avec l'écran actif et l'écran de verrouillage déverrouillé.

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

Android 4.4 introduit la prise en charge du mode d'émulation de carte hôte NFC (HCE). Si une implémentation de périphérique comprend un contrôleur NFC capable de HCE et de routage d'ID d'application (AID), alors IT:

Doit signaler la 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 de périphériques peuvent inclure la prise en charge des lecteurs / écrivains pour les technologies mifare suivantes.

Mifare Classic (NXP MF1S503X [ Ressources, 44 ], MF1S703X [ Ressources, 45 ])
Mifare ultraght (NXP MF0ICU1 [ Ressources, 46 ], MF0ICU2 [ Ressources, 47 ])
NDEF on MIFARE Classic (NXP AN130511 [ Resources, 48 ], AN130411 [ Resources, 49 ])

Note that Android includes APIs for these MIFARE types. If a device implementation supports MIFARE in the reader/writer role, it:

MUST implement the corresponding Android APIs as documented by the Android SDK
MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() method. [ Resources, 37 ] Note that this is not a standard Android feature, and as such does not appear as a constant on the PackageManager class.
MUST NOT implement the corresponding Android APIs nor report the com.nxp.mifare feature unless it also implements general NFC support as described in this section

If a device implementation does not include NFC hardware, it MUST NOT declare the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method [ Resources, 37 ], and MUST implement the Android NFC API as a no-op.

As the classes android.nfc.NdefMessage and android.nfc.NdefRecord represent a protocol-independent data representation format, device implementations MUST implement these APIs even if they do not include support for NFC or declare the android.hardware.nfc feature.

7.4.5. Capacité réseau minimale

Device implementations MUST include support for one or more forms of data networking. Specifically, device implementations MUST include support for at least one data standard capable of 200Kbit/sec or greater. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.

Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (Wi-Fi).

Devices MAY implement more than one form of data connectivity.

7.4.6. Paramètres de synchronisation

Device implementations MUST have the master auto-sync setting on by default so that the method getMasterSyncAutomatically() returns "true" [ Resources, 88 ].

7.5. Appareils photo

Device implementations SHOULD include a rear-facing camera, and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

7.5.1. Caméra orientée vers l'arrière

Device implementations SHOULD include a rear-facing camera. If a device implementation includes a rear-facing camera, it:

MUST have a resolution of at least 2 megapixels
SHOULD have either hardware auto-focus, or software auto-focus implemented in the camera driver (transparent to application software)
MAY have fixed-focus or EDOF (extended depth of field) hardware
MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes of a Camera.Parameters object. Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback .

7.5.2. Avant face à la caméra

Device implementations MAY include a front-facing camera. If a device implementation includes a front-facing camera, it:

MUST have a resolution of at least VGA (that is, 640x480 pixels)
MUST NOT use a front-facing camera as the default for the Camera API. That is, the camera API in Android has specific support for front-facing cameras, and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on the appareil.
MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in Section 7.5.1.
MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:

If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 50 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
Otherwise, the preview MUST be mirrored along the device's default horizontal axis.

MUST mirror the image displayed by the postview in the same manner as the camera preview image stream. (If the device implementation does not support postview, this requirement obviously does not apply.)
MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

7.5.3. Comportement de l'API de la caméra

Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int) , then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
Device implementations MUST support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.)

Device implementations MUST implement the full Camera API included in the Android SDK documentation [ Resources, 51 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types. For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 78 ]).

Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.

Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store.

7.5.4. Orientation de la caméra

Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimum

Device implementations MUST have at least 340MB of memory available to the kernel and userspace. The 340MB MUST be in addition to any memory dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

Device implementations with less than 512MB of memory available to the kernel and userspace MUST return the value "true" for ActivityManager.isLowRamDevice() .

Device implementations MUST have at least 1GB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 1GB. Device implementations that run Android are very strongly encouraged to have at least 2GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.

The Android APIs include a Download Manager that applications may use to download data files [ Resources, 56 ]. The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default "cache" location.

7.6.2. Shared External Storage

Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 1GB in size.

Device implementations MUST be configured with shared storage mounted by default, "out of the box". If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps. The upstream Android Open Source Project includes an implementation that uses internal device storage for shared external storage APIs; device implementations SHOULD use this configuration and software implementation.

Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP). Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol. If the device implementation supports Media Transfer Protocol:

The device implementation SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 57 ].
The device implementation SHOULD report a USB device class of 0x00 .
The device implementation SHOULD report a USB interface name of 'MTP'.

If the device implementation lacks USB ports, it MUST provide a host computer with access to the contents of shared storage by some other means, such as a network file system.

It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) MUST NOT allow Android applications to write to the secondary external storage, except for their package-specific directories on the secondary external storage, but SHOULD expose content from both storage paths transparently through Android's media scanner service and android.provider.MediaStore.

7.7. USB

Device implementations SHOULD include a USB client port, and SHOULD include a USB host port.

If a device implementation includes a USB client port:

the port MUST be connectable to a USB host with a standard USB-A port
the port SHOULD use the micro USB form factor on the device side. Existing and new devices that run Android are very strongly encouraged to meet these requirements in Android so they will be able to upgrade to the future platform releases
the port SHOULD be centered in the middle of an edge. Device implementations SHOULD either locate the port on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new devices that run Androidare very strongly encouraged to meet these requirements in Android so they will be able to upgrade to future platform releases.
if the device has other ports (such as a non-USB charging port) it SHOULD be on the same edge as the micro-USB port
it MUST allow a host connected to the device to access the contents of the shared storage volume using either USB mass storage or Media Transfer Protocol
it MUST implement the Android Open Accessory API and specification as documented in the Android SDK documentation, and MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 52 ]
it MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 66 ]
it SHOULD implement support for USB battery charging specification [ Resources, 64 ] Existing and new devices that run Android are very strongly encouraged to meet these requirements so they will be able to upgrade to the future platform releases
The value of iSerialNumber in USB standard device descriptor MUST be equal to the value of android.os.Build.SERIAL.

If a device implementation includes a USB host port:

it MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to standard USB-A
it MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 53 ]

Device implementations MUST implement the Android Debug Bridge. If a device implementation omits a USB client port, it MUST implement the Android Debug Bridge via local-area network (such as Ethernet or 802.11)

8. Compatibilité des performances

Device implementations MUST meet the key performance metrics of an Android- compatible device defined in the table below:

Métrique	Performance Threshold	commentaires
Application Launch Time	The following applications should launch within the specified time. Browser: less than 1300ms Contacts: less than 700ms Settings: less than 700ms	The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
Simultaneous Applications	When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

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

Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 54 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

9.1. Autorisations

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 54 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

9.2. UID et isolation des processus

Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 54 ].

9.3. Autorisations du système de fichiers

Device implementations MUST support the Android file access permissions model as defined in the Security and Permissions reference [ Resources, 54 ].

9.4. Environnements d'exécution alternatifs

Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

Alternate runtimes MUST abide by the Android sandbox model. Spécifiquement:

Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource . If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

9.5. Prise en charge multi-utilisateurs

Android includes support for multiple users and provides support for full user isolation [ Resources, 70 ].

Device implementations MUST meet these requirements related to multi-user support [ Resources, 71 ]:

As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]
Android includes support for restricted profiles, a feature that allows device owners to manage additional users and their capabilities on the device. With restricted profiles, device owners can quickly set up separate environments for additional users to work in, with the ability to manage finer-grained restrictions in the apps that are available in those environments. Device implementations that include support for multiple users MUST include support for restricted profiles. The upstream Android Open Source Project includes an implementation that satisfies this requirement.

Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multi-user is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 72 ] for primary external storage.

9.6. Avertissement SMS premium

Android includes support for warning users for any outgoing premium SMS message [ Resources, 73 ] . Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement.

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

The Android Sandbox includes features that can use the Security-Enhanced Linux (SELinux) mandatory access control (MAC) system and other security features in the Linux kernel. SELinux or any other security features, if implemented below the Android framework:

MUST maintain compatibility with existing applications
MUST not have a visible user interface, even when violations are detected
SHOULD NOT be user or developer configurable

If any API for configuration of policy is exposed to an application that can affect another application (such as a Device Administration API), the API MUST NOT allow configurations that break compatibility.

Devices MUST implement SELinux and meet the following requirements, which are satisfied by the reference implementation in the upstream Android Open Source Project.

it MUST support a SELinux policy that allows the SELinux mode to be set on a per-domain basis with:

domains that are in enforcing mode in the upstream Android Open Source implementation (such as installd, netd, and vold) MUST be in enforcing mode
domain(s) for third-party applications SHOULD remain in permissive mode to ensure continued compatibility

it SHOULD load policy from /sepolicy file on the device
it MUST support dynamic updates of the SELinux policy file without requiring a system image update
it MUST log any policy violations without breaking applications or affecting system behavior

Device implementations SHOULD retain the default SELinux policy provided in the upstream Android Open Source Project, until they have first audited their additions to the SELinux policy. Device implementations MUST be compatible with the upstream Android Open Source Project.

9.8. Confidentialité

If the device implements functionality in the system that captures the contents displayed on the screen and/or records the audio stream played on the device, it MUST continuously notify the user whenever this functionality is enabled and actively capturing/recording.

9.9. Chiffrement complet du disque

IF the device has lockscreen, the device MUST support full-disk encryption.

10. Tests de compatibilité logicielle

Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1. Suite de tests de compatibilité

Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.4. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

10.2. Vérificateur CTS

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verifier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

10.3. Applications de référence

Device implementers MUST test implementation compatibility using the following open source applications:

The "Apps for Android" applications [ Resources, 55 ]
Replica Island (available in Google Play Store)

Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

11. Logiciel pouvant être mis à jour

Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

Over-the-air (OTA) downloads with offline update via reboot
"Tethered" updates over USB from a host PC
"Offline" updates via a reboot and update from a file on removable storage

The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

12. Document Changelog

The following table contains a summary of the changes to the Compatibility Definition in this release.

Sections)	Summary of change
3.2.2. Paramètres de construction	Revised descriptions of BRAND, DEVICE, and PRODUCT. SERIAL is now required.
3.2.3.5. Default App Settings	New section that adds requirement to comply with new default application settings
3.3.1 Interfaces binaires des applications	Clarified allowed values for the `android.os.Build.CPU_ABI` and `android.os.Build.CPU_ABI2` parameters.
3.4.1. Compatibilité WebView	Added Chromium as required WebView implementation.
3.7. Compatibilité des machines virtuelles	Added requirement for xxhdpi and 400dpi screen densities.
3.8.6. Thèmes	Updated to reflect use of translucent system bars.
3.8.12. Emplacement	New section that adds requirement location settings be centralized.
3.8.13. Unicode	New section that adds requirement for emoji support.
3.9. Administration des appareils	Noted preinstalled administrative applications cannot be the default Device Owner application.
5.1. Codecs multimédias	Added VP9 decoder requirement. Added recommended specification for hardware VP8 codecs.
5.3. Décodage vidéo	Added VP9. Added recommendation for dynamic resolution switching.
5.4. Enregistrement audio	Added `REMOTE_SUBMIX` as new required audio source. Made use of `android.media.audiofx.NoiseSuppressor` API a requirement.
6.2.1 Experimental	New section that introduces the ART runtime and requires Dalvik as the default runtime.
7.1.1. Configuration de l'écran	Replaced 1.85 aspect ratio with 1.86. Added 400dpi screen density.
7.1.6. Types d'écran	Added 640 dpi (4K) resolution configuration.
7.2.3. Touches de navigation	Added Recents function as essential; demoted Menu function in priority.
7.3.6. Thermomètre	Added SENSOR_TYPE_AMBIENT_TEMPERATURE as recommended thermometer.
7.4.2.2. Wi-Fi Tunneled Direct Link Setup	New section that adds support for Wi-Fi Tunneled Direct Link Setup (TDLS).
7.4.4. Near Field Communications	Added Host Card Emulation (HCE) as a requirement. Replaced SNEP GET with Logical Link Control Protocol (LLCP) and added the Bluetooth Object Push Profile as a requirement.
7.4.6. Paramètres de synchronisation	New section that adds requirement auto-sync data be enabled by default.
7.6.1. Mémoire et stockage minimum	Added `ActivityManager.isLowRamDevice()` setting requirement for devices with less than 512MB of memory. Increased storage requirements from 512MB and 1GB to 1GB and 2GB, respectively.
7.6.2. Shared "External" Storage	Editorial fixes such as change of section name, and moved text that fits in this section from section 9.5. Noted applications may write to their package-specific directories on secondary external storage.
7.7. USB	Added requirement all devices report a USB serial number.
9.5. Prise en charge multi-utilisateurs	Moved non multi-user specific text to section 7.6.2.
9.7. Fonctionnalités de sécurité du noyau	Rewritten to note switch of SELinux to enforcing mode and requirement SELinux output not be rendered in the user interface.
9.8. Confidentialité	New section that adds requirement audio and video recording must trigger continuous notifications to the user.
9.9. Chiffrement complet du disque	New section that adds requirement devices with lockscreen support full-disk encryption.
12. Document Changelog	New section that summarizes changes in the CDD by section.

13. Contactez-nous

You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.