Définition de la compatibilité Android 2.3

Copyright © 2010, Google Inc. Tous droits réservés.
compatibilité@android.com

Table des matières

1. Introduction

Ce document énumère les exigences qui doivent être remplies pour que les téléphones mobiles soient compatibles avec Android 2.3.

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 2.3. 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 2.3, 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.

Veuillez noter que cette définition de compatibilité est émise pour correspondre à la mise à jour 2.3.3 vers Android, qui est le niveau API 10. Cette définition est obsolète et remplace la définition de compatibilité pour les versions Android 2.3 antérieures à 2.3.3. (C'est-à-dire que les versions 2.3.1 et 2.3.2 sont obsolètes.) Les futurs appareils compatibles Android exécutant Android 2.3 DOIVENT être livrés avec la version 2.3.3 ou ultérieure.

2. Ressources

1. Niveaux d'exigence de l'IETF RFC2119 : http://www.ietf.org/rfc/rfc2119.txt
2. Présentation du programme de compatibilité Android : http://source.android.com/docs/compatibility/index.html
3. Projet Open Source Android : http://source.android.com/
4. Définitions et documentation de l'API : http://developer.android.com/reference/packages.html
5. Référence sur les autorisations Android : http://developer.android.com/reference/android/Manifest.permission.html
6. Référence android.os.Build : http://developer.android.com/reference/android/os/Build.html
7. Chaînes de version autorisées pour Android 2.3 : http://source.android.com/docs/compatibility/2.3/versions.html
8. Classe android.webkit.WebView : http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5 : http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. Fonctionnalités HTML5 hors ligne : http://dev.w3.org/html5/spec/Overview.html#offline
11. Balise vidéo HTML5 : http://dev.w3.org/html5/spec/Overview.html#video
12. API de géolocalisation HTML5/W3C : http://www.w3.org/TR/geolocation-API/
13. API de base de données Web HTML5/W3C : http://www.w3.org/TR/webdatabase/
14. API HTML5/W3C IndexedDB : http://www.w3.org/TR/IndexedDB/
15. Spécification de la machine virtuelle Dalvik : disponible dans le code source Android, sur dalvik/docs
16. AppWidgets : http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
17. Notifications : http://developer.android.com/guide/topics/ui/notifiers/notifications.html
18. Ressources d'application : http://code.google.com/android/reference/available-resources.html
19. Guide de style des icônes de la barre d'état : http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
20. Gestionnaire de recherche : http://developer.android.com/reference/android/app/SearchManager.html
21. Toasts : http://developer.android.com/reference/android/widget/Toast.html
22. Fonds d'écran animés : https://android-developers.googleblog.com/2010/02/live-wallpapers.html
23. Documentation de l'outil de référence (pour adb, aapt, ddms) : http://developer.android.com/guide/developing/tools/index.html
24. Description du fichier apk Android : http://developer.android.com/guide/topics/fundamentals.html
25. Fichiers manifeste : http://developer.android.com/guide/topics/manifest/manifest-intro.html
26. Outil de test de singe : https://developer.android.com/studio/test/other-testing-tools/monkey
27. Liste des fonctionnalités matérielles Android : http://developer.android.com/reference/android/content/pm/PackageManager.html
28. Prise en charge de plusieurs écrans : http://developer.android.com/guide/practices/screens_support.html
29. android.util.DisplayMetrics : http://developer.android.com/reference/android/util/DisplayMetrics.html
30. android.content.res.Configuration : http://developer.android.com/reference/android/content/res/Configuration.html
31. Espace de coordonnées du capteur : http://developer.android.com/reference/android/hardware/SensorEvent.html
32. API Bluetooth : http://developer.android.com/reference/android/bluetooth/package-summary.html
33. Protocole push NDEF : http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
34. MIFARE MF1S503X : http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
35. MIFARE MF1S703X : http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
36. MIFARE MF0ICU1 : http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
37. MIFARE MF0ICU2 : http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
38. MIFARE AN130511 : http://www.nxp.com/documents/application_note/AN130511.pdf
39. MIFARE AN130411 : http://www.nxp.com/documents/application_note/AN130411.pdf
40. API d'orientation de la caméra : http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
41. android.hardware.Camera : http://developer.android.com/reference/android/hardware/Camera.html
42. Référence sur la sécurité et les autorisations Android : http://developer.android.com/guide/topics/security/security.html
43. Applications pour Android : http://code.google.com/p/apps-for-android

Beaucoup de ces ressources sont dérivées directement ou indirectement du SDK Android 2.3 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

La plate-forme Android comprend un ensemble d'API gérées, un ensemble d'API natives et un ensemble d'API dites « soft » telles que le système Intent et les API d'application Web. Cette section détaille les API matérielles et logicielles qui font partie intégrante de la compatibilité, ainsi que certains autres comportements techniques et d'interface utilisateur pertinents. Les implémentations de périphériques DOIVENT être conformes à toutes les exigences de cette section.

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 2.3 [ 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. Cette section détaille les API « logicielles » et les comportements système requis pour la compatibilité avec Android 2.3. Les implémentations de périphériques DOIVENT répondre à toutes les exigences présentées dans cette section.

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

3.2.3. Compatibilité des intentions

Android utilise les intentions pour réaliser une intégration faiblement couplée entre les applications. Cette section décrit les exigences liées aux modèles d'intention qui DOIVENT être respectées par les implémentations de périphérique. 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 de base, telles qu'un numéroteur téléphonique, un calendrier, un carnet de contacts, un 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
• Calculatrice
• Contacts
• E-mail
• 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émenteurs de périphériques DOIVENT permettre à chaque modèle d'intention référencé à la section 3.2.3.1 d'être remplacé par des applications tierces. Le projet 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.

3.2.3.3. Espaces de noms d'intention

Les implémenteurs de périphériques 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.*. 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.

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.3. Compatibilité API native

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é. Le code natif étant fortement dépendant 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.txt . 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
• DOIT signaler uniquement les ABI documentés dans la dernière version du NDK Android, dans le fichier docs/CPU-ARCH-ABIS.txt
• DEVRAIT être construit en utilisant le code source et les fichiers d'en-tête disponibles dans le projet open source Android en amont

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

• libc (bibliothèque C)
• libm (bibliothèque mathématique)
• 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)
• libEGL.so (gestion native des surfaces OpenGL)
• libjnigraphics.so
• libOpenSLES.so (prise en charge audio de la bibliothèque de sons ouverte)
• 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.

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

De nombreux développeurs et applications s'appuient sur le comportement de la classe android.webkit.WebView [ Resources, 8 ] pour leurs interfaces utilisateur. L'implémentation de WebView doit donc être compatible avec toutes les implémentations Android. De même, un navigateur Web complet et moderne est au cœur de l’expérience utilisateur Android. Les implémentations d'appareil DOIVENT inclure une version d' android.webkit.WebView cohérente avec le logiciel Android en amont, et DOIVENT inclure un navigateur moderne compatible HTML5, comme décrit ci-dessous.

3.4.1. Compatibilité WebView

L'implémentation Android Open Source utilise le moteur de rendu WebKit pour implémenter android.webkit.WebView . 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 WebKit dans l'implémentation de WebView. Spécifiquement:

• Les implémentations android.webkit.WebView des implémentations de périphériques DOIVENT être basées sur la version 533.1 WebKit de l'arborescence Android Open Source en amont pour Android 2.3. Cette version inclut un ensemble spécifique de fonctionnalités et de correctifs de sécurité pour WebView. Les implémenteurs de périphériques PEUVENT inclure des personnalisations à l'implémentation de WebKit ; cependant, de telles personnalisations NE DOIVENT PAS modifier le comportement de WebView, y compris le comportement de rendu.
• La chaîne de l'agent utilisateur signalée par WebView DOIT être dans ce format :
  Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
  • 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) 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.
  • 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

Le composant WebView DEVRAIT inclure la prise en charge d'autant de HTML5 [ Ressources, 9 ] que possible. Au minimum, les implémentations de périphériques DOIVENT prendre en charge chacune de ces API associées à HTML5 dans WebView :

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

De plus, les implémentations de périphériques DOIVENT prendre en charge l'API de stockage Web HTML5/W3C [ Ressources, 13 ] et DEVRAIENT prendre en charge l'API HTML5/W3C IndexedDB [ Ressources, 14 ]. 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.

Les API HTML5, comme toutes les API JavaScript, DOIVENT être désactivées par défaut dans une WebView, à moins que le développeur ne les active explicitement via les API Android habituelles.

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, 9 ] 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, 10 ]
• la balise <video> [ Ressources, 11 ]
• géolocalisation [ Ressources, 12 ]

De plus, les implémentations de périphériques DOIVENT prendre en charge l'API de stockage Web HTML5/W3C [ Ressources, 13 ] et DEVRAIENT prendre en charge l'API HTML5/W3C IndexedDB [ Ressources, 14 ]. 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 open source Android 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, 15 ].

Les implémentations d'appareils avec des écrans classés comme densité moyenne ou faible DOIVENT configurer Dalvik pour allouer au moins 16 Mo de mémoire à chaque application. Les implémentations d'appareils avec des écrans classés comme haute densité ou très haute densité DOIVENT configurer Dalvik pour allouer au moins 24 Mo de mémoire à chaque application. Notez que les implémentations de périphériques PEUVENT allouer plus de mémoire que ces chiffres.

3.8. Compatibilité de l'interface utilisateur

La plate-forme Android comprend certaines API de développement qui permettent aux développeurs de se connecter à l'interface utilisateur du système. Les implémentations d'appareil DOIVENT intégrer ces API d'interface utilisateur standard dans les interfaces utilisateur personnalisées qu'elles développent, comme expliqué ci-dessous.

3.8.1. 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, 16 ]. La version de référence Android Open Source comprend une application Launcher qui comprend des éléments d'interface utilisateur permettant à l'utilisateur d'ajouter, d'afficher et de supprimer des AppWidgets de l'écran d'accueil.

Les responsables de la mise en œuvre du périphérique PEUVENT substituer une alternative au lanceur de référence (c'est-à-dire l'écran d'accueil). Les lanceurs alternatifs DEVRAIENT inclure une prise en charge intégrée des AppWidgets et exposer les éléments de l'interface utilisateur pour ajouter, configurer, afficher et supprimer des AppWidgets directement dans le lanceur. Les lanceurs alternatifs PEUVENT omettre ces éléments d'interface utilisateur ; cependant, s'ils sont omis, le responsable de la mise en œuvre du périphérique DOIT fournir une application distincte accessible depuis le lanceur qui permet aux utilisateurs d'ajouter, de configurer, d'afficher et de supprimer des AppWidgets.

3.8.2. Notifications

Android inclut des API qui permettent aux développeurs d'informer les utilisateurs d'événements notables [ Ressources, 17 ]. Les implémenteurs de dispositifs DOIVENT fournir une prise en charge pour chaque classe de notification ainsi définie ; plus précisément : sons, vibrations, lumière et barre d'état.

De plus, l'implémentation DOIT restituer correctement toutes les ressources (icônes, fichiers son, etc.) fournies dans les API [ Resources, 18 ] ou dans le guide de style des icônes de la barre d'état [ Resources, 19 ]. 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.

3.8.3. Recherche

Android inclut des API [ Ressources, 20 ] 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 du moteur de recherche Web.

Les implémentations de l'appareil peuvent expédier des interfaces utilisateur de recherche alternatives, mais doivent inclure un bouton de recherche dédié dur ou doux, qui peut être utilisé à tout moment dans n'importe quelle application pour invoquer le cadre de recherche, avec le comportement prévu dans la documentation de l'API.

3.8.4. Toasts

Les applications peuvent utiliser l'API "Toast" (définie dans [ Resources, 21 ]) 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 l'appareil doivent afficher des toasts des applications aux utilisateurs finaux de manière élevée.

3.8.5. Fonds d'écran animés

Android définit un type de composant et un cycle de vie et un cycle de vie correspondant qui permet aux applications d'exposer un ou plusieurs "fonds d'écran en direct" à l'utilisateur final [ Ressources, 22 ]. Les fonds d'écran en direct sont des animations, des motifs ou des images similaires avec des capacités d'entrée limitées qui s'affichent comme fond d'écran, derrière d'autres applications.

Le matériel est considéré comme capable de gérer de manière fiable des fonds d'écran en direct s'il peut exécuter tous les fonds d'écran en direct, sans limites de fonctionnalité, à un framerate raisonnable sans effet négatif sur d'autres applications. Si les limitations du matériel provoquent des accidents de fonds d'écran et / ou d'applications, de dysfonctionnement, de consommer un processeur excessif ou de la batterie, ou de s'exécuter à des fréquences d'images inacceptablement faibles, le matériel est considéré comme incapable de faire fonctionner du papier peint en direct. Par exemple, certains fonds d'écran en direct peuvent utiliser un contexte GL 1.0 ou 2.0 ouvert pour rendre leur contenu. Le papier peint en direct ne fonctionnera pas de manière fiable sur le matériel qui ne prend pas en charge plusieurs contextes OpenGL, car l'utilisation du fond d'écran en direct d'un contexte OpenGL peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

Les implémentations de périphériques capables de gérer de manière fiable les fonds d'écran en direct comme décrit ci-dessus doivent implémenter des fonds d'écran en direct. Les implémentations de dispositifs déterminées à ne pas exécuter les fonds d'écran en direct comme décrit ci-dessus ne doivent pas implémenter des fonds d'écran en direct.

4. Compatibilité des emballages d'application

Les implémentations de périphériques doivent installer et exécuter les fichiers Android ".APK" tels que générés par l'outil "AAPT" inclus dans le SDK Android officiel [ Resources, 23 ].

Les implémentations de périphériques ne doivent pas étendre ni les formats ByTecode [ Resources , Android de. . Les implémenteurs de périphériques doivent utiliser l'implémentation en amont de référence de Dalvik et le système de gestion des packages de l'implémentation de référence.

5. Compatibilité multimédia

Les implémentations de périphériques doivent implémenter pleinement toutes les API multimédias. Les implémentations de l'appareil doivent inclure la prise en charge de tous les codecs multimédias décrits ci-dessous et doivent répondre aux directives de traitement sonore décrites ci-dessous. Les implémentations de l'appareil doivent inclure au moins une forme de sortie audio, telles que les haut-parleurs, la prise casque, la connexion de haut-parleur externe, etc.

5.1. Codecs multimédias

Les implémentations de périphériques doivent prendre en charge les codecs multimédias comme détaillé dans les sections suivantes. Tous ces codecs sont fournis comme implémentations de logiciels dans l'implémentation Android préférée du projet Android Open-source.

Veuillez noter que ni Google ni l'alliance Open Handsset ne font aucune représentation selon laquelle ces codecs ne sont pas grevés par des brevets tiers. Les personnes ayant l'intention d'utiliser ce code source dans les produits matériels ou logiciels sont informés que les implémentations de ce code, y compris dans les logiciels open source ou Shareware, peuvent nécessiter des licences de brevet des détenteurs de brevets concernés.

Les tableaux ci-dessous ne répertorient pas les exigences de débit binaire spécifiques pour la plupart des codecs vidéo. La raison en est qu'en pratique, le matériel de périphérique actuel ne prend pas nécessairement en charge les débits binaires qui mappent 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é sur le matériel, jusqu'aux limites définies par les spécifications.

5.1.1. Décodeurs de médias

Les implémentations de périphérique doivent inclure une implémentation d'un décodeur pour chaque codec et format décrit dans le tableau ci-dessous. Notez que les décodeurs pour chacun de ces types de supports sont fournis par le projet Android Open-source en amont.

5.1.2. Encodeurs multimédias

Les implémentations de périphériques doivent inclure des encodeurs pour autant de formats de médias répertoriés dans la section 5.1.1. que possible. Cependant, certains encodeurs n'ont pas de sens pour les appareils qui manquent de matériel facultatif; Par exemple, un encodeur pour la vidéo H.263 n'a pas de sens, si l'appareil n'a pas de caméras. Les implémentations de périphériques doivent donc implémenter les encodeurs multimédias en fonction des conditions décrites dans le tableau ci-dessous.

Voir la section 7 pour plus de détails sur les conditions dans lesquelles le matériel peut être omis par les implémentations de périphériques.

En plus des encodeurs énumérés ci-dessus, les implémentations de périphériques doivent inclure un encodeur H.264. Notez que la définition de compatibilité pour une future version est prévue pour modifier cette exigence pour "doit". Autrement dit, le codage H.264 est facultatif dans Android 2.3 mais sera requis par une future version. Les appareils existants et nouveaux qui exécutent Android 2.3 sont très fortement encouragés à répondre à cette exigence dans Android 2.3 , ou ils ne pourront pas atteindre la compatibilité Android lorsqu'ils sont mis à niveau vers la future version.

5.2. Enregistrement audio

Lorsqu'une application a utilisé l'API android.media.AudioRecord pour commencer à enregistrer un flux audio, les implémentations de périphériques devraient échantillonner et enregistrer l'audio avec chacun de ces comportements:

• 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é.
• L'appareil doit présenter des caractéristiques d'amplitude approximativement plates en fonction de la fréquence; Plus précisément, ± 3 dB, de 100 Hz à 4000 Hz
• La sensibilité à l'entrée audio doit être définie de telle sorte qu'une source de niveau de puissance sonore (SPL) de 90 dB à 1000 Hz donne un RMS de 5000 pour des échantillons 16 bits.
• Les niveaux d'amplitude PCM doivent suivre linéairement les modifications de SPL d'entrée sur au moins une plage de 30 dB de -18 dB à +12 dB RE 90 dB SPL au microphone.
• La distorsion harmonique totale doit être inférieure à 1% de 100 Hz à 4000 Hz à un niveau d'entrée SPL de 90 dB.

Remarque: Bien que les exigences décrites ci-dessus soient indiquées comme "devraient" pour Android 2.3, la définition de compatibilité pour une future version est prévue pour les changer en "MUST". Autrement dit, ces exigences sont facultatives dans Android 2.3, mais seront nécessaires par une future version. Les appareils existants et nouveaux qui exécutent Android 2.3 sont très fortement encouragés à répondre à ces exigences dans Android 2.3 , ou ils ne pourront pas atteindre la compatibilité Android lorsqu'ils sont mis à niveau vers la future version.

5.3. Latence audio

La latence audio est largement définie comme l'intervalle entre lorsqu'une application demande une lecture audio ou une opération d'enregistrement, et lorsque l'implémentation de l'appareil commence réellement l'opération. De nombreuses classes d'applications reposent sur de courtes latences pour réaliser des effets en temps réel tels que des effets sonores ou une communication VOIP. Les implémentations de périphériques qui incluent le matériel microphone et Declare android.hardware.microphone doivent répondre à toutes les exigences de latence audio décrites dans cette section. Voir la section 7 pour plus de détails sur les conditions dans lesquelles le matériel de microphone peut être omis par les implémentations de périphériques.

Aux fins de cette section:

• "La latence de sortie de froid" est définie comme étant l'intervalle entre le moment où une application demande la lecture audio et quand le son commence à jouer, lorsque le système audio a été inactif et alimenté avant la demande
• "La latence de sortie chaude" est définie comme étant l'intervalle entre le moment où une application demande la lecture audio et quand le son commence à jouer, lorsque le système audio a été récemment utilisé mais est actuellement inactif (c'est-à-dire silencieux)
• La "latence de sortie continue" est définie comme étant l'intervalle entre le moment où une application émet un échantillon à jouer et lorsque l'orateur joue physiquement le son correspondant, tandis que l'appareil est actuellement en arrière
• La "latence d'entrée à froid" est définie comme étant l'intervalle entre le moment où une application demande l'enregistrement audio et lorsque le premier échantillon est livré à l'application via son rappel, lorsque le système audio et le microphone ont été inactifs et alimentés avant la demande
• La "latence d'entrée continue" est définie comme lorsqu'un son ambiant se produit et lorsque l'échantillon correspondant à ce son est livré à une application d'enregistrement via son rappel, tandis que l'appareil est en mode d'enregistrement

En utilisant les définitions ci-dessus, les implémentations de périphériques devraient présenter chacune de ces propriétés:

• latence de sortie à froid de 100 millisecondes ou moins
• latence de sortie chaude de 10 millisecondes ou moins
• latence de sortie continue de 45 millisecondes ou moins
• latence d'entrée à froid de 100 millisecondes ou moins
• latence d'entrée continue de 50 millisecondes ou moins

Remarque: Bien que les exigences décrites ci-dessus soient indiquées comme "devraient" pour Android 2.3, la définition de compatibilité pour une future version est prévue pour les changer en "MUST". Autrement dit, ces exigences sont facultatives dans Android 2.3, mais seront nécessaires par une future version. Les appareils existants et nouveaux qui exécutent Android 2.3 sont très fortement encouragés à répondre à ces exigences dans Android 2.3 , ou ils ne pourront pas atteindre la compatibilité Android lorsqu'ils sont mis à niveau vers la future version.

Si une implémentation de périphérique répond aux exigences de cette section, elle peut signaler la prise en charge de l'audio à faible latence, en signalant la fonctionnalité "Android.Hardware.Audio.Low-LATCTY" via la classe android.content.pm.PackageManager . [ Ressources, 27 ] Inversement, si la mise en œuvre de l'appareil ne répond pas à ces exigences, elle ne doit pas signaler la prise en charge de l'audio à faible latence.

6. Compatibilité des outils du développeur

Les implémentations de périphériques doivent prendre en charge les outils de développeur Android fourni dans le SDK Android. Plus précisément, les appareils compatibles Android doivent être compatibles avec:

• Android Debug Bridge (connu sous le nom de BAD) [ Ressources, 23 ]
  Les implémentations de périphériques doivent prendre en charge toutes les fonctions adb comme documentée dans le SDK Android. Le démon adb côté périphérique doit être inactif par défaut, mais il doit y avoir un mécanisme accessible à l'utilisateur pour activer le pont de débogage Android.
• Dalvik Debug Monitor Service (connu sous le nom de DDMS) [ Ressources, 23 ]
  Les implémentations de périphériques doivent prendre en charge toutes les fonctionnalités ddms comme documentée dans le SDK Android. Comme ddms utilise adb , la prise en charge ddms doit ê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, 26 ]
  Les implémentations de l'appareil doivent inclure le cadre de singe et les rendre disponibles pour les applications à utiliser.

La plupart des systèmes basés sur Linux et des systèmes Apple Macintosh reconnaissent les appareils Android à l'aide des outils SDK Android standard, sans support supplémentaire; Cependant, les systèmes Microsoft Windows nécessitent généralement un pilote pour de 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 et Windows 7, dans les versions 32 bits et 64 bits.

7. Compatibilité matérielle

Android est destiné à permettre aux implémenteurs de périphériques de créer des facteurs et des configurations de forme innovants. Dans le même temps, les développeurs Android rédigent des applications innovantes qui reposent sur les différents matériels et fonctionnalités disponibles via les API Android. Les exigences de cette section établissent un équilibre entre les innovations disponibles pour les implémenteurs d'appareils et les besoins des développeurs pour s'assurer que leurs applications ne sont disponibles que pour les appareils où ils fonctionneront correctement.

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, 27 ]

7.1. Affichage et graphiques

Android 2.3 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, 28 ]. Les appareils doivent implémenter correctement ces API et comportements, comme détaillé dans cette section.

7.1.1. Configurations d'écran

Les implémentations de l'appareil peuvent utiliser des écrans de toutes les dimensions de pixels, à condition qu'elles répondent aux exigences suivantes:

• Les écrans doivent être d'au moins 2,5 pouces de taille diagonale physique
• La densité doit être d'au moins 100 dpi
• Le rapport d'aspect doit être compris entre 1,333 (4: 3) et 1,779 (16: 9)
• La technologie d'affichage utilisée se compose de pixels carrés

Les implémentations de dispositifs avec un écran répondant aux exigences ci-dessus sont considérées comme compatibles et aucune action supplémentaire n'est nécessaire. L'implémentation Android Framework calcule automatiquement les caractéristiques de l'affichage telles que le godet de taille d'écran et le seau de densité. Dans la majorité des cas, les décisions du cadre sont les bonnes. Si les calculs de cadre par défaut sont utilisés, aucune action supplémentaire n'est nécessaire. Les implémenteurs de périphériques souhaitant modifier les valeurs par défaut ou utiliser un écran qui ne répond pas aux exigences ci-dessus doit contacter l'équipe de compatibilité Android pour obtenir des conseils, comme prévu dans la section 12.

Les unités utilisées par les exigences ci-dessus 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".

Les implémentations de périphérique doivent utiliser uniquement les affichages avec une seule configuration statique. C'est-à-dire que les implémentations de périphériques ne doivent pas activer les configurations d'écran multiples. Par exemple, comme une télévision typique prend en charge plusieurs résolutions telles que 1080p, 720p, etc., cette configuration n'est pas compatible avec Android 2.3. (Cependant, la prise en charge de ces configurations est sous enquête et prévue pour une future version d'Android.)

7.1.2. Afficher les mesures

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

7.1.3. Prise en charge de l'écran déclaré

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 petits, moyens et grands écrans, comme décrit dans la documentation du SDK Android.

7.1.4. Orientation de l'écran

Les dispositifs compatibles doivent prendre en charge l'orientation dynamique par 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 appareils qui ne peuvent pas être physiquement tournés peuvent répondre à cette exigence par des applications "Letterboxing" qui demandent le mode portrait, en utilisant seulement une partie de l'écran disponible.

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.

7.1.5. Accélération graphique 3D

Les implémentations de périphériques doivent prendre en charge OpenGL ES 1.0, comme l'exige les API Android 2.3. Pour les appareils qui manquent de matériel d'accélération 3D, une implémentation logicielle d'OpenGL ES 1.0 est fournie par le projet Android Open-source en amont. Les implémentations de périphérique doivent prendre en charge OpenGL ES 2.0.

Les implémentations peuvent omettre l'assistance Open Gl es 2.0; Cependant, si l'assistance est omise, les implémentations de périphériques ne doivent pas signaler en tant que prise en charge OpenGL ES 2.0. Plus précisément, si une implémentation de périphérique manque de prise en charge OpenGL ES 2.0:

• Les API gérées (comme via la méthode GLES10.getString() ) ne doivent pas signaler la prise en charge d'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) ne doit pas signaler la prise en charge d'OpenGL ES 2.0.

Inversement, si une implémentation de périphérique prend en charge OpenGL ES 2.0, elle doit signaler avec précision cette prise en charge via les itinéraires qui viennent d'être répertoriés.

Notez qu'Android 2.3 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 2.3 est requis par Android 2.3 pour implémenter tout 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.

7.2. Des dispositifs d'entrée

Android 2.3 prend en charge un certain nombre de modalités pour la saisie des utilisateurs. Les implémentations de périphériques doivent prendre en charge les périphériques d'entrée utilisateur comme prévu dans cette section.

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 - c'est-à-dire un clavier souple) comme détaillé sur 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, 30 ] (c'est-à-dire Qwerty ou 12 key)

7.2.2. Navigation sans contact

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, 30 ]
• 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. Le code 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. Clés de navigation

Les fonctions à domicile, à menu et à 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, quel que soit l'état d'application. Ces fonctions doivent être implémentées via des boutons dédiés. Ils peuvent être mis en œuvre à l'aide de logiciels, de gestes, de panneaux tactiles, etc., mais si c'est le cas, ils doivent toujours être accessibles et non obscurs ou interférer avec la zone d'affichage de l'application disponible.

Les implémenteurs de périphériques doivent également fournir une clé de recherche dédiée. Les implémenteurs de périphériques peuvent également fournir des clés d'envoi et de fin pour les appels téléphoniques.

7.2.4. Entrée à l'écran tactile

Implémentations d'appareils :

• Doit avoir un écran tactile
• Peut avoir un écran tactile capacitif ou résistif
• Doit signaler la valeur de android.content.res.Configuration [ Ressources, 30 ] reflétant correspondant au type de l'écran tactile spécifique sur l'appareil
• Devrait prendre en charge les pointeurs entièrement suivis indépendamment, si l'écran tactile prend en charge plusieurs pointeurs

7.3. Capteurs

Android 2.3 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, 27 ]
• 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.)

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.

Les API Android 2.3 introduisent 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 Android 2.3 SDK pour être un capteur de streaming.

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:

• Doit être en mesure de livrer des événements à 50 Hz ou plus
• Doit se conformer au système de coordonnées du capteur Android comme détaillé dans les API Android (voir [ Ressources, 31 ])
• 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, 31 ]).
• 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 capable de mesurer les changements d'orientation jusqu'à 5,5 * Pi Radians / Second (c'est-à-dire environ 1 000 degrés par seconde)
• Doit être capable de livrer des événements à 100 Hz ou plus
• Doit avoir 8 bits de précision ou plus

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

7.3.7. Thermomètre

Les implémentations de dispositifs peuvent mais ne doivent pas inclure de thermomètre (c.-à-d. Capteur de température) Si une implémentation de dispositif inclut un thermomètre, il doit mesurer la température du processeur de l'appareil. Il ne doit pas mesurer aucune autre température. (Notez que ce type de capteur est déprécié dans les API Android 2.3.)

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

La connectivité réseau et l'accès à Internet sont des fonctionnalités vitales d'Android. Pendant ce temps, l'interaction de périphérique à périphérique ajoute une valeur significative aux appareils et applications Android. Les implémentations de l'appareil doivent répondre aux exigences de connectivité des données dans cette section.

7.4.1. Téléphonie

"Téléphonie" telle qu'utilisée par les API Android 2.3 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 2.3 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 2.3 peut être utilisé sur des appareils qui n'incluent pas le matériel de téléphonie. Autrement dit, Android 2.3 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 (WiFi)

Android 2.3 Les implémentations de périphériques 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.

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 [ Resources, 32 ]. 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.

La suite de test de compatibilité comprend des cas qui couvrent le fonctionnement de base de l'API Bluetooth Android RFCOMM. Cependant, comme Bluetooth est un protocole de communication entre les appareils, il ne peut pas être entièrement testé par des tests unitaires fonctionnant sur un seul appareil. Par conséquent, les implémentations de l'appareil doivent également passer la procédure de test Bluetooth basée sur l'homme décrite à l'annexe A.

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, 27 ]
• 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)
    • NFCV (ISO 15693)
    • Isodep (ISO 14443-4)
    • NFC Forum Tag Types 1, 2, 3, 4 (défini par le forum NFC)
  • 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, 33 ]
  • Doit rechercher toutes les technologies prises en charge dans le mode de découverte NFC.
  • Devrait être en mode NFC Discovery pendant que l'appareil est éveillé avec l'écran actif.

  (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.)

  De plus, les implémentations de périphériques devraient prendre en charge les technologies MIFARE largement déployées suivantes.

  • Mifare Classic (NXP MF1S503X [ RESSOURCES, 34 ], MF1S703X [ RESSOURCES, 35 ])
  • Mifare Ultralight (NXP MF0ICU1 [ Ressources, 36 ], MF0ICU2 [ Ressources, 37 ])
  • NDEF sur Mifare Classic (NXP AN130511 [ Ressources, 38 ], AN130411 [ Ressources, 39 ])

  Notez qu'Android 2.3.3 comprend des API pour ces types mifare. Si une implémentation de périphérique prend en charge Mifare, IT:

  • Doit implémenter les API Android correspondantes comme indiqué par le SDK Android
  • Doit signaler la fonction com.nxp.mifare à partir de la méthode android.content.pm.PackageManager.hasSystemFeature() . [ Ressources, 27 ] Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et, en tant que telle, n'apparaît pas comme une constante sur la classe PackageManager .
  • Ne doit pas implémenter les API Android correspondantes ni signaler la fonction com.nxp.mifare à moins qu'elle ne mette également en œuvre la prise en charge générale de la NFC comme décrit dans cette section

  Si une implémentation de périphérique n'inclut pas le matériel NFC, il ne doit pas déclarer la fonctionnalité Android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature() [ Resources, 27 ], et doit implémenter l'API Android 2.3 NFC comme un no-op.

  Comme les classes android.nfc.NdefMessage et android.nfc.NdefRecord représentent un format de représentation de données indépendants du protocole, les implémentations de périphériques doivent implémenter ces API même s'ils n'incluent pas la prise en charge de NFC ou de déclarer la fonctionnalité Android.Hardware.nfc.

  7.4.5. Capacité de réseau minimum

  Les implémentations de périphériques doivent inclure la prise en charge d'une ou plusieurs formes de réseautage de données. 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 (WiFi).

  Devices MAY implement more than one form of data connectivity.

  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 2.3 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 le dispositif.
  • 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, 40 ] 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 data returned to any "postview" camera callback handlers, in the same manner as the camera preview image stream. (If the device implementation does not support postview callbacks, 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:

  1. 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.
  2. 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.
  3. Device implementations SHOULD support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. Note that the Compatibility Definition for a future version is planned to change this requirement to "MUST". That is, YV12 support is optional in Android 2.3 but will be required by a future version. Existing and new devices that run Android 2.3 are very strongly encouraged to meet this requirement in Android 2.3 , or they will not be able to attain Android compatibility when upgraded to the future version.

  Device implementations MUST implement the full Camera API included in the Android 2.3 SDK documentation [ Resources, 41 ]), 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.

  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, a 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. Memory and Storage

  The fundamental function of Android 2.3 is to run applications. Device implementations MUST the requirements of this section, to ensure adequate storage and memory for applications to run properly.

  7.6.1. Minimum Memory and Storage

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

  Device implementations MUST have at least 150MB of non-volatile storage available for user data. That is, the /data partition MUST be at least 150MB.

  Beyond the requirements above, device implementations SHOULD have at least 1GB of non-volatile storage available for user data. Note that this higher requirement is planned to become a hard minimum in a future version of Android. Device implementations are strongly encouraged to meet these requirements now, or else they may not be eligible for compatibility for a future version of Android.

  The Android APIs include a Download Manager that applications may use to download data files. The Download Manager implementation MUST be capable of downloading individual files 55MB in size, or larger. The Download Manager implementation SHOULD be capable of downloading files 100MB in size, or larger.

  7.6.2. Application Shared 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.

  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 or Media Transfer Protocol.

  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) SHOULD modify the core applications such as the media scanner and ContentProvider to transparently support files placed in both locations.

  7.7. USB

  Implémentations d'appareils :

  • MUST implement a USB client, connectable to a USB host with a standard USB-A port
  • MUST implement the Android Debug Bridge over USB (as described in Section 7)
  • MUST implement the USB mass storage specification, to allow a host connected to the device to access the contents of the /sdcard volume
  • SHOULD use the micro USB form factor on the device side
  • MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of connecting the custom pinout to standard USB-A port

  8. Performance Compatibility

  Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.3 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 MMS/SMS: less than 700ms AlarmClock: less than 650ms	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. Security Model Compatibility

  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, 42 ] 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, 42 ]. 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 and Process Isolation

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

  9.3. Filesystem Permissions

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

  9.4. Alternate Execution Environments

  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.

  10. Software Compatibility Testing

  The Android Open-Source Project includes various testing tools to verify that device implementations are compatible. 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 2.3 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 2.3. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

  MUST pass the most recent version of the Android Compatibility Test Suite (CTS) available at the time of the device implementation's software is completed. (The CTS is available as part of the Android Open Source Project [ Resources, 2 ].) The CTS tests many, but not all, of the components outlined in this document.

  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 Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

  10.3. Reference Applications

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

  • The "Apps for Android" applications [ Resources, 43 ].
  • Replica Island (available in Android Market; only required for device implementations that support with OpenGL ES 2.0)

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

  11. Updatable Software

  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. 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. Contact Us

  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.

  Appendix A - Bluetooth Test Procedure

  The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

  The test procedure is based on the BluetoothChat sample app included in the Android open-source project tree. The procedure requires two devices:

  • a candidate device implementation running the software build to be tested
  • a separate device implementation already known to be compatible, and of a model from the device implementation being tested -- that is, a "known good" device implementation

  The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

  Setup and Installation

  1. Build BluetoothChat.apk via 'make samples' from an Android source code tree.
  2. Install BluetoothChat.apk on the known-good device.
  3. Install BluetoothChat.apk on the candidate device.

  Test Bluetooth Control by Apps

  1. Launch BluetoothChat on the candidate device, while Bluetooth is disabled.
  2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

  Test Pairing and Communication

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
  3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
  4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
  5. Close the BluetoothChat app on both devices by pressing Home .
  6. Unpair each device from the other, using the device Settings app.

  Test Pairing and Communication in the Reverse Direction

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the candidate device discoverable from within BluetoothChat (using the Menu).
  3. On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
  4. Send 10 or messages from each device, and verify that the other device receives them correctly.
  5. Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

  Test Re-Launches

  1. Re-launch the Bluetooth Chat app on both devices.
  2. Send 10 or messages from each device, and verify that the other device receives them correctly.

  Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.