Définition de la compatibilité Android 2.1

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

1. Introduction

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

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.1. Une « implémentation de dispositif » ou « implémentation » est la solution matérielle/logicielle ainsi développée.

Pour être considéré comme compatible avec Android 2.1, les implémentations d'appareil :

  • DOIT répondre aux exigences présentées dans cette définition de compatibilité, y compris tous les documents incorporés par référence.
  • DOIT réussir la version la plus récente de la suite de tests de compatibilité Android (CTS) disponible au moment de la mise en œuvre du logiciel de l'appareil. (Le CTS est disponible dans le cadre du projet Android Open Source [ Ressources, 2 ].) Le CTS teste de nombreux composants, mais pas tous, décrits dans ce document.

Lorsque cette définition ou le CTS est muet, ambigu ou incomplet, il incombe au 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 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 CTS deviendra considérablement 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 requis de l'IETF RFC2119 : http://www.ietf.org/rfc/rfc2119.txt
  • Présentation du programme de compatibilité Android : http://source.android.com/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 des autorisations Android : http://developer.android.com/reference/android/Manifest.permission.
    • Référence
  • html
  • android.os.Build : http://developer.android.com/reference/android/os/Build.html
  • Chaînes de version autorisées pour Android 2.1 : http://source.android.com/docs/compatibility/2.1/versions
    • Classe
  • .html
  • android.webkit.WebView : http://developer.android.com/reference/android/webkit/WebView.html
  • HTML5 : http://www.whatwg.org/specs/web-apps/current-work/ multipage/
  • 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_guideline /icon_design.html#statusbarstructure
  • Gestionnaire de recherche : http://developer.android.com/reference/android/app/SearchManager.html
  • Toasts : http://developer.android.com/reference/android/widget /Toast.html
  • Live Wallpapers : https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  • Applications pour Android : http://code.google.com/p/apps-for-android
  • Référence documentation de l'outil (pour adb, aapt, ddms) : http://developer.android.com/guide/developing/tools/index.html
  • Description du fichier apk Android : http://developer.android.com/guide/topics/fundamentals
    • Fichiers manifeste
  • .html
  •  : http://developer.android.com/guide/topics/manifest/manifest-intro.html
  • Outil de test Monkey : https://developer.android.com/studio/test/other-testing-tools/ singe
  • prenant en charge plusieurs écrans : http://developer.android.com/guide/practices/screens_support.html
  • android.content.res.Configuration : http://developer.android.com/reference/android/content/res/Configuration. html
  • android.util.DisplayMetrics : http://developer.android.com/reference/android/util/DisplayMetrics.html
  • android.hardware.Camera : http://developer.android.com/reference/android/hardware/Camera. html
  • Espace de coordonnées du capteur : http://developer.android.com/reference/android/hardware/SensorEvent.html
  • Référence sur la sécurité et les autorisations Android : http://developer.android.com/guide/topics/security/security.html
  • Bluetooth API : http://developer.android.com/reference/android/bluetooth/package-summary.html

    • Beaucoup de ces ressources sont dérivées directement ou indirectement du SDK Android 2.1 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 plateforme 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.1 [ 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é.

    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 niveau de l'application. temps de compilation. Cette section détaille les API « logicielles » et les comportements système requis pour la compatibilité avec Android 2.1. 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 [ Ressources, 6 ] destinées à décrire le périphérique 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
    android.os.Build.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 ].
    android.os.Build.VERSION.SDK Version du système Android en cours d'exécution, dans un format accessible au code d'application tierce. Pour Android 2.1, ce champ DOIT avoir la valeur entière 7.
    android.os.Build.VERSION.INCREMENTAL Une valeur choisie par l'implémenteur du périphérique 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 expédiées aux 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 ("").
    android.os.Build.BOARD Une valeur choisie par le responsable de l'implémentation 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. 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 ("").
    android.os.Build.BRAND Une valeur choisie par le responsable de la mise en œuvre de l'appareil identifiant le nom de l'entreprise, de l'organisation, de l'individu, etc. qui a produit l'appareil, dans un format lisible par l'homme. Une utilisation possible de ce champ est d'indiquer l'OEM et/ou le transporteur qui a vendu l'appareil. 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 ("").
    android.os.Build.DEVICE Une valeur choisie par le réalisateur du périphérique identifiant la configuration ou la révision spécifique du corps (parfois appelée « conception industrielle ») du périphérique. 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 ("").
    android.os.Build.FINGERPRINT Une chaîne qui identifie de manière unique cette version. Il DEVRAIT être raisonnablement lisible par l'homme. Il DOIT suivre ce modèle :
    $(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
    Par exemple:
    acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keys
    L'empreinte digitale NE DOIT PAS inclure d'espaces. Si d'autres champs inclus dans le modèle ci-dessus comportent des espaces, ils DEVRAIENT être remplacés par le caractère de soulignement ASCII (« _ ») dans l'empreinte digitale.
    android.os.Build.HOST 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 ("").
    android.os.Build.ID Un identifiant choisi par l'implémenteur 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. 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 ("").
    android.os.Build.MODEL Une valeur choisie par l'implémenteur du périphérique contenant le nom du périphérique 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 ("").
    android.os.Build.PRODUCT Une valeur choisie par l'implémenteur du périphérique contenant le nom de développement ou le nom de code du périphérique. DOIT être lisible par l'homme, mais n'est pas nécessairement destiné à être visualisé par les 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 ("").
    android.os.Build.TAGS Une liste de balises séparées par des virgules choisies par l'implémenteur de l'appareil qui distinguent davantage la build. Par exemple, « non signé,débogage ». Ce champ NE DOIT PAS être nul ni contenir une chaîne vide (""), mais une seule balise (telle que "release") convient.
    android.os.Build.TIME Une valeur représentant l'horodatage du moment où la build a eu lieu.
    android.os.Build.TYPE 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".
    android.os.Build.USER 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

    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 d'application principales

    Le projet Android en amont définit un certain nombre d'applications principales, 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
    • Appareil photo
    • Contacts
    • Galerie
    • de courrier électronique
    • GlobalSearch
    • Launcher
    • LivePicker (c'est-à-dire l'application de sélection de Live Wallpaper ; PEUT être omise si l'appareil ne prend pas en charge Live Wallpapers, conformément à la section 3.8.5. )
    • Messagerie (AKA "Mms")
    • Musique
    • Paramètres
    • du téléphone
    • SoundRecorder

    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 défini dans les applications système principales 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.

    Remarque : cette section a été modifiée par l'erratum EX6580.

    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 plate-forme pour diffuser certaines intentions afin de les informer des modifications apportées à 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 géré 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é. Les implémentations de périphériques DOIVENT 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). Les API suivantes DOIVENT être disponibles pour le code natif :

    • libc (bibliothèque C)
    • libm (bibliothèque mathématique)
    • Interface JNI
    • libz (compression Zlib)
    • liblog (journalisation Android)
    • Prise en charge minimale de C++
    • Prise en charge d'OpenGL, comme décrit ci-dessous.
      • Les implémentations de périphériques DOIVENT prendre en charge OpenGL ES

    1.0 . Les appareils dépourvus d'accélération matérielle DOIVENT implémenter OpenGL ES 1.0 à l'aide d'un moteur de rendu logiciel. Les implémentations de périphériques DEVRAIENT implémenter autant d'OpenGL ES 1.1 que le matériel du périphérique le prend en charge. Les implémentations de périphériques DEVRAIENT fournir une implémentation pour OpenGL ES 2.0, si le matériel est capable de fournir des performances raisonnables sur ces API.

    Ces bibliothèques DOIVENT être compatibles source (c'est-à-dire compatible en-tête) et compatible binaire (pour une architecture de processeur donnée) avec les versions fournies dans Bionic par le projet Android Open Source. Étant donné que les implémentations Bionic ne sont pas entièrement compatibles avec d'autres implémentations telles que la bibliothèque GNU C, les implémenteurs de périphériques DEVRAIENT utiliser l'implémentation Android. Si les implémenteurs de périphériques utilisent une implémentation différente de ces bibliothèques, ils DOIVENT garantir la compatibilité des en-têtes, des binaires et du comportement.

    Les implémentations d'appareil DOIVENT 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 . L'ABI DOIT être l'une des entrées documentées dans la dernière version du NDK Android, dans le fichier docs/CPU-ARCH-ABIS.txt . Notez que des versions supplémentaires d'Android NDK peuvent introduire la prise en charge d'ABI supplémentaires.

    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, afin de garantir la compatibilité.

    3.4. Compatibilité de l'API 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. L'implémentation Android Open Source utilise le moteur de rendu WebKit pour implémenter WebView.

    Puisqu'il n'est pas possible de développer une suite de tests complète pour un navigateur Web, les implémenteurs de périphériques DOIVENT utiliser la version spécifique en amont de WebKit dans l'implémentation de WebView. Plus précisément :

    • WebView DOIT utiliser la version 530.17 WebKit de l'arborescence Android Open Source en amont pour Android 2.1. Cette version inclut un ensemble spécifique de fonctionnalités et de correctifs de sécurité pour WebView.
    • 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/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
      • du 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. de l'appareil
      • 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
    Les implémentations
      • android.os.Build.ID

    PEUVENT expédier une chaîne d'agent utilisateur personnalisée dans l'application de navigateur autonome. De plus, le navigateur autonome PEUT être basé sur une technologie de navigateur alternative (telle que Firefox, Opera, etc.). Cependant, même si une autre application de navigateur est livrée, le composant WebView fourni aux applications tierces DOIT être basé sur WebKit, comme ci-dessus.

    La configuration WebView DOIT inclure la prise en charge de la base de données HTML5, du cache d'application et des API de géolocalisation [ Ressources, 9 ]. La WebView DOIT inclure la prise en charge de la balise HTML5 <video> sous une forme ou une autre. L'application de navigateur autonome (qu'elle soit basée sur l'application de navigateur WebKit en amont ou sur un remplacement tiers) DOIT inclure la prise en charge des mêmes fonctionnalités HTML5 que celles répertoriées pour WebView.

    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 signification 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 particulière

    La liste ci-dessus n'est pas exhaustive et il incombe aux implémenteurs de périphériques de garantir la compatibilité comportementale. 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.

    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.

    3.6. Espaces de noms 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.*
    • sun.*
    • android.*
    • com.android.*
      • Les

    modifications interdites incluent :

    • Les implémentations de périphériques DOIVENT NE modifiez PAS 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 » 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.

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

    Les implémentations d'appareils DOIVENT configurer Dalvik pour allouer au moins 16 Mo de mémoire à chaque application sur les appareils dotés d'écrans classés comme densité moyenne ou faible. Les implémentations d'appareils DOIVENT configurer Dalvik pour allouer au moins 24 Mo de mémoire à chaque application sur les appareils dotés d'écrans classés comme haute densité. Notez que les implémentations de périphériques PEUVENT allouer plus de mémoire que ces chiffres, mais ce n'est pas obligatoire.

    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, 11 ]. 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, 12 ]. 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, 13 ] ou dans le guide de style des icônes de la barre d'état [ Resources, 14 ]. 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 comprend des API [ Ressources, 15 ] 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 périphériques PEUVENT proposer des interfaces utilisateur de recherche alternatives, mais DEVRAIENT inclure un bouton de recherche dédié, matériel ou logiciel, qui peut être utilisé à tout moment dans n'importe quelle application pour appeler le cadre de recherche, avec le comportement prévu dans la documentation de l'API.

    3.8.4.

    Les applications

    Toasts

    peuvent utiliser l'API "Toast" (définie dans [ Ressources, 16 ]) 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.5. Live Wallpapers

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

    4. Compatibilité des logiciels de référence

    Les implémenteurs de périphériques DOIVENT tester la compatibilité de l'implémentation à l'aide des applications open source suivantes :

    • Calculatrice (incluse dans le SDK)
    • Lunar Lander (inclus dans le SDK)
    • Les applications "Applications pour Android" [ Ressources, 18 ].

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

    De plus, les implémentations de l'appareil DOIVENT tester chaque élément de menu (y compris tous les sous-menus) de chacune de ces applications de test de fumée :

    • ApiDemos (inclus dans le SDK)
    • ManualSmokeTests (inclus dans CTS)

    Chaque scénario de test dans les applications ci-dessus DOIT s'exécuter correctement sur l'appareil. mise en œuvre.

    5. Compatibilité des packages d'applications

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

    Les implémentations d'appareils NE DOIVENT PAS étendre les formats .apk [ Ressources, 20 ], Android Manifest [ Ressources, 21 ] ou bytecode Dalvik [ Ressources, 10 ] 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.

    6. Compatibilité multimédia

    Les mises en œuvre de périphériques DOIVENT prendre en charge les codecs multimédia suivants. 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.

    Nom
    audio
    Encodeur Détails du décodeur Format de fichier/conteneur
    AAC LC/LTP   X Contenu mono/stéréo dans n'importe quelle combinaison de débits binaires standard jusqu'à 160 kbps et de taux d'échantillonnage compris entre 8 et 48 kHz 3GPP (.3gp) et MPEG-4 (.mp4, .m4a). Pas de prise en charge de l'AAC brut (.aac)
    HE-AACv1 (AAC+)   X
    HE-AACv2 (AAC+ amélioré)   X
    AMR-NB X X 4,75 à 12,2 kbps échantillonnés à 8 kHz 3GPP (.3gp)
    AMR-WB   X 9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz 3GPP (.3gp)
    MP3   X Mono/Stéréo 8-320 Kbps débit constant (CBR) ou variable (VBR) MP3 (.mp3)
    MIDI   X 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 Type 0 et 1 (.mid, .xmf, .mxmf). Également RTTTL/RTX (.rtttl, .rtx), OTA (.ota) et iMelody (.imy)
    Ogg Vorbis   X   Ogg (.ogg)
    PCM   X PCM linéaire 8 et 16 bits (débits dans la limite du matériel) WAVE (.wav)
    Image
    JPEG X X base+progressif  
    GIF   X   
    PNG X X   
    PGB   X   
    Vidéo
    H.263 X X   Fichiers 3GPP (.3gp)
    H.264   X   Fichiers 3GPP (.3gp) et MPEG-4 (.mp4)
    MPEG4 Simple Profile   X   Fichier 3GPP (.3gp)

    Notez que le tableau ci-dessus ne répertorie pas les exigences spécifiques en matière de débit binaire pour la plupart des codecs vidéo. La raison en est qu'en pratique, le matériel actuel des appareils ne prend pas nécessairement en charge des débits binaires correspondant exactement aux débits requis spécifiés par les normes en vigueur. 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.

    7. Compatibilité des outils de développement

    Les implémentations d'appareils 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 :

    • Android Debug Bridge (connu sous le nom d'adb) [ Ressources, 19 ]
      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 DEVRAIT être inactif par défaut, mais il DOIT y avoir un mécanisme accessible à l'utilisateur pour activer le pont de débogage Android.
    • Service Dalvik Debug Monitor (connu sous le nom de ddms) [ Ressources, 19 ]
      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, 22 ]
      Les implémentations de périphériques DOIVENT inclure le framework Monkey et le rendre disponible pour les applications.

    8. Compatibilité matérielle

    Android est destiné à aider les développeurs d'appareils à créer des facteurs de forme et des configurations innovants. Dans le même temps, les développeurs Android attendent certains matériels, capteurs et API sur tous les appareils Android. Cette section répertorie les fonctionnalités matérielles que tous les appareils compatibles Android 2.1 doivent prendre en charge.

    Si un appareil inclut un composant matériel particulier doté d'une API correspondante pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme défini dans la documentation du SDK Android. Si une API du SDK interagit avec un composant matériel déclaré facultatif et que l'implémentation du périphérique ne possède pas ce composant : les

    • définitions de classe pour les API du composant DOIVENT être présentes,
    • les comportements de l'API DOIVENT être implémentés comme non opérationnels d'une manière raisonnable.
    • Les méthodes API DOIVENT renvoyer des valeurs nulles lorsque la documentation du SDK le permet.
    • Les méthodes API DOIVENT renvoyer des implémentations sans opération de classes où les valeurs nulles ne sont pas autorisées par la documentation du SDK.
      • Un exemple typique

    d'un scénario où ces exigences s'appliquent est l'API de téléphonie : même sur des -appareils téléphoniques, ces API doivent être implémentées de manière raisonnable.

    Les implémentations de périphériques DOIVENT rapporter avec précision des informations précises sur la configuration matérielle via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) sur la classe android.content.pm.PackageManager .

    8.1. Display

    Android 2.1 inclut des fonctionnalités qui effectuent certaines opérations de mise à l'échelle et de transformation automatiques dans certaines circonstances, pour garantir que les applications tierces fonctionnent raisonnablement bien sur une variété de configurations matérielles [ Ressources, 23 ]. Les appareils DOIVENT correctement mettre en œuvre ces comportements, comme détaillé dans cette section.

    Pour Android 2.1, voici les configurations d'affichage les plus courantes :

    3,5 WVGA 480 800 4,8 - 5,5 appareils
    Type d'écran Largeur (pixels) Hauteur (pixels) Plage de longueur diagonale (pouces) Groupe de tailles d'écran Groupe de densité d'écran
    QVGA 240 320 2,6 - 3,0 Petit Faible
    WQVGA 240 400 3,2 - 3,5 Normal Faible
    FWQVGA 240 432 3,5 - 3,8 Normal Faible
    HVGA 320 480 3,0 - 3,5 Normal Moyen
    WVGA 480 800 3,3 - 4,0 Normal Élevé
    FWVGA 480 854- 4,0 Normal Élevé
    Grand Moyen FWVGA 480 854 5,0
    - 5,8 Implémentations d'de taille moyenne et

    grande correspondant à l'une des configurations standards ci-dessus DOIT être configuré pour signaler la taille d'écran indiquée aux applications via la classe android.content.res.Configuration [ Resources, 24 ].

    Certains packages .apk ont ​​des manifestes qui ne les identifient pas comme prenant en charge une plage de densité spécifique. Lors de l'exécution de telles applications, les contraintes suivantes s'appliquent :

    • Les implémentations de périphériques DOIVENT interpréter les ressources d'un .apk dépourvues de qualificatif de densité comme étant par défaut "moyenne" (appelée "mdpi" dans la documentation du SDK.) Lors de l'exécution d'
    • une densité "faible". écran, les implémentations de périphériques DOIVENT réduire les actifs moyen/mdpi d'un facteur de 0,75.
    • Lorsqu'elles fonctionnent sur un écran « haute » densité, les implémentations de périphériques DOIVENT augmenter les actifs moyen/mdpi d'un facteur de 1,5.
    • Les implémentations de périphériques NE DOIVENT PAS mettre à l'échelle les actifs dans une plage de densité, et DOIVENT mettre à l'échelle les actifs exactement en fonction de ces facteurs entre les plages de densité.

    8.1.2. Configurations d'affichage non standard

    Les configurations d'affichage qui ne correspondent pas à l'une des configurations standard répertoriées dans la section 8.1.1 nécessitent une considération et des travaux supplémentaires pour être compatibles. Les responsables de la mise en œuvre des appareils DOIVENT contacter l'équipe de compatibilité Android comme prévu à la section 12 pour obtenir des classifications pour la taille de l'écran, la densité et le facteur de mise à l'échelle. Lorsqu’elles reçoivent ces informations, les mises en œuvre de périphériques DOIVENT les implémenter comme spécifié.

    Notez que certaines configurations d'affichage (comme les écrans très grands ou très petits, et certains formats d'image) sont fondamentalement incompatibles avec Android 2.1 ; par conséquent, les développeurs d'appareils sont encouragés à contacter l'équipe de compatibilité Android le plus tôt possible dans le processus de développement.

    8.1.3.

    Les implémentations de périphériques de

    métriques d'affichage

    DOIVENT signaler des valeurs correctes pour toutes les métriques d'affichage définies dans android.util.DisplayMetrics [ Ressources, 25 ].

    8.2.

    Implémentations de périphériques

    de clavier

     :

    • DOIVENT 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 logiciel) comme détaillé sur développeur.android.com
    • DOIT fournir au moins une implémentation de clavier logiciel (qu'il s'agisse ou non d'un clavier logiciel). un clavier matériel est présent)
    • PEUT inclure des implémentations de clavier logiciel 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 [ Ressources, 24 ] (c'est-à-dire, QWERTY, ou 12 touches)

    8.3.

    Implémentations de dispositifs

    de navigation non tactiles

     :

    • PEUVENT omettre les options de navigation non tactiles (c'est-à-dire, peuvent omettre une boule de commande, un pavé directionnel ou une molette)
    • DOIVENT signaler la valeur correcte pour android.content.res.Configuration.navigation [ Ressources, 24 ]

    8.4. Orientation de l'écran

    Les appareils compatibles DOIVENT prendre en charge l'orientation dynamique des applications vers une orientation d'écran portrait ou paysage. Autrement dit, l'appareil doit respecter la demande de l'application concernant une orientation spécifique de l'écran. Les implémentations de périphériques PEUVENT sélectionner l'orientation portrait ou paysage par défaut.

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

    8.5. Entrée sur écran tactile

    Implémentations de périphérique :

    • DOIT avoir un écran tactile
    • PEUT avoir un écran tactile capacitif ou résistif
    • DOIT rapporter la valeur de android.content.res.Configuration [ Ressources, 24 ] reflétant correspondant au type d'écran tactile spécifique sur l'appareil
      • 8.6

    .

    Implémentations de périphériques

    USB

       :
    • DOIVENT implémenter un client USB, connectable à un hôte USB avec un port USB-A standard
    • DOIVENT implémenter le pont de débogage Android sur USB (comme décrit dans la section 7)
    • DOIVENT implémenter la spécification de stockage de masse USB, pour permettre à un hôte connecté au périphérique pour accéder au contenu du volume /sdcard
    • DEVRAIT utiliser le facteur de forme micro USB du côté du périphérique
    • PEUT inclure un port non standard du côté du périphérique, mais si c'est le cas DOIT être livré avec un câble capable de connecter le brochage personnalisé à port USB-A standard

    8.7. Touches de navigation

    Les fonctions Accueil, Menu et Retour sont essentielles au paradigme de navigation Android. Les implémentations de périphérique DOIVENT rendre ces fonctions disponibles à l'utilisateur à tout moment, quel que soit l'état de l'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.

    8.8.

    Les implémentations de périphériques

    de réseautage de données sans fil

    doivent inclure la prise en charge du réseau de données à grande vitesse sans fil. Plus précisément, les implémentations de périphériques doivent inclure la prise en charge d'au moins une norme de données sans fil capable de 200kbit / sec ou plus. Des exemples de technologies qui satisfont à cette exigence incluent Edge, HSPA, EV-DO, 802.11g, etc.

    Si une implémentation d'un appareil comprend une modalité particulière pour laquelle le SDK Android comprend une API (c'est-à-dire WiFi, GSM ou CDMA), le L'implémentation doit prendre en charge l'API.

    Les appareils peuvent implémenter plus d'une forme de connectivité de données sans fil. Les appareils peuvent implémenter la connectivité des données filaires (comme Ethernet), mais doivent néanmoins inclure au moins une forme de connectivité sans fil, comme ci-dessus.

    8.9.

    Les implémentations de l'appareil

    photo

    doivent inclure une caméra. La caméra incluse:

    • doit avoir une résolution d'au moins 2 mégapixels
    • doit avoir une mise au point automatique matérielle, soit un logiciel automatique implémenté dans le pilote de la caméra (transparent vers le logiciel d'application)
    • peut avoir une focale fixe ou un EDOF (profondeur de champ étendue) Le matériel
    • peut inclure un flash. Si l'appareil photo comprend un flash, la lampe flash ne doit pas être éclairée tandis qu'une instance Android.Hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de l'appareil photo, à moins que l'application ait explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un Camera.Parameters OBJET. Notez que cette contrainte ne s'applique pas à l'application de caméra système intégrée de l'appareil, mais uniquement aux applications tierces à l'aide de Camera.PreviewCallback .

    Les implémentations de périphériques doivent implémenter les comportements suivants pour les API liés à la caméra:

    1. si une application n'a jamais appelé Android.Hardware.Camera.Parameters.SetPreViewFormat (INT), alors l'appareil doit utiliser Android.Hardware.PixElformat.YCBCR_420_P rappels d'application.
    2. Si une application enregistre une instance Android.Hardware.Camera.PreViewCallback et que le système appelle la méthode onPreviewFrame () lorsque le format d'aperçu est ycbcr_420_sp, les données dans le format d'octet [] dans OnPreViewFrame () doivent être en outre dans le format d'encodage NV21. (Il s'agit du format utilisé nativement par la famille de matériel 7k.) C'est-à-dire que NV21 doit être la valeur par défaut.

    Les implémentations de périphériques doivent implémenter l'API de la caméra complète incluse dans la documentation SDK Android 2.1 [ Ressources, 26 ]), que le périphérique comprenne une autofocus matérielle ou d'autres capacités. Par exemple, les caméras qui manquent d'autofocus doivent toujours appeler toutes les instances android.hardware.Camera.AutoFocusCallback (même si cela n'a aucune pertinence pour une caméra non autofocus.) Les implémentations de l'appareil

    doivent reconnaître et honorer chaque nom de paramètre défini comme une constante sur la constante sur la constante sur la constante sur la constante. android.hardware.Camera.Parameters Classe, si le matériel sous-jacent prend en charge la fonctionnalité. Si le matériel de l'appareil ne prend pas en charge une fonctionnalité, l'API doit se comporter comme documentée. 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 , unless the constants are prefixed with a string indicating the Nom de l'implémentateur de périphérique. Autrement dit, les implémentations de périphériques doivent prendre en charge tous les paramètres de caméra standard si le matériel le permet, et ne doit pas prendre en charge les types de paramètres de caméra personnalisés, sauf si les noms de paramètres sont clairement indiqués via un préfixe de chaîne non standard.

    8.10.

    Les implémentations des périphériques

    d'accéléromètre

    doivent inclure un accéléromètre à 3 axes et doivent être capables de livrer des événements à 50 Hz ou plus. Le système de coordonnées utilisé par l'accéléromètre doit se conformer au système de coordonnées du capteur Android comme détaillé dans les API Android (voir [ Resources, 27 ]).

    8.11.

    Les implémentations des périphériques

    de boussole

    doivent inclure une boussole à 3 axes et doivent être capables de livrer des événements 10 Hz ou plus. Le système de coordonnées utilisé par la boussole doit se conformer au système de coordonnées du capteur Android tel que défini dans l'API Android (voir [ Resources, 27 ]).

    8.12.

    Les implémentations de périphériques

    GPS

    doivent inclure un GPS et doivent inclure une forme de technique "assistée GPS" pour minimiser le temps de verrouillage GPS.

    8.13. Téléphonie

    Android 2.1 peut être utilisée sur des appareils qui n'incluent pas le matériel de téléphonie. Autrement dit, Android 2.1 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 le support complet 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.

    Voir également la section 8.8, Réseautage de données sans fil.

    8.14.

    Les implémentations

    de la mémoire et

    des périphériques de stockage doivent avoir au moins 92 Mo de mémoire disponibles pour le noyau et l'espace utilisateur. Le 92 Mo doit s'ajouter à toute mémoire dédiée aux composants matériels tels que la radio, la mémoire, etc., ce n'est pas sous le contrôle du noyau.

    Les implémentations de l'appareil doivent avoir au moins 150 Mo de stockage non volatile disponible pour les données utilisateur. C'est-à-dire que la partition /data doit être d'au moins 150 Mo.

    Remarque: Cette section a été modifiée par Erratum EX6580.

    8.15.

    Les implémentations de périphériques

    de stockage partagées d'applications

    doivent offrir un stockage partagé pour les applications. Le stockage partagé fourni doit avoir une taille d'au moins 2 Go.

    Les implémentations de périphérique doivent être configurées avec un stockage partagé monté par défaut, "Out of the Box". Si le stockage partagé n'est pas monté sur le chemin Linux /sdcard , le périphérique doit inclure un lien symbolique Linux de /sdcard au point de montage réel.

    Les implémentations de périphérique doivent appliquer comme documenté android.permission.WRITE_EXTERNAL_STORAGE sur ce stockage partagé. Le stockage partagé doit autrement être écrit par toute application qui obtient cette autorisation.

    Les implémentations de l'appareil peuvent avoir du matériel pour un stockage amovible accessible aux utilisateurs, comme une carte numérique sécurisée. Alternativement, les implémentations de périphériques peuvent allouer le stockage interne (non amovible) en tant que stockage partagé pour les applications.

    Quelle que soit la forme du stockage partagé utilisé, le stockage partagé doit implémenter un stockage de masse USB, comme décrit dans la section 8.6. Comme expédié de la boîte, le stockage partagé doit être monté avec le système de fichiers FAT.

    Il est illustratif de considérer deux exemples courants. Si une implémentation de l'appareil comprend un emplacement de carte SD pour satisfaire l'exigence de stockage partagé, une carte SD à format gras 2 Go de taille ou plus doit être incluse avec l'appareil comme les utilisateurs et doit être monté par défaut. Alternativement, si une implémentation de périphérique utilise un stockage fixe interne pour satisfaire cette exigence, ce stockage doit être de 2 Go de taille ou plus et monté sur /sdcard (ou /sdcard doit être un lien symbolique vers l'emplacement physique s'il est monté ailleurs.) Remarque

    Remarque : Cette section a été ajoutée par Erratum EX6580.

    8.16.

    Les implémentations de l'appareil

    Bluetooth

    doivent inclure un émetteur-récepteur Bluetooth. Les implémentations de périphériques doivent activer l'API Bluetooth basée sur RFCOMM comme décrit dans la documentation SDK [ Resources, 29 ]. 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.

    Remarque: Cette section a été ajoutée par Erratum EX6580.

    9. Compatibilité des performances

    L'un des objectifs du programme de compatibilité Android consiste à permettre une expérience d'application cohérente aux consommateurs. Les implémentations compatibles doivent garantir non seulement que les applications s'exécutent simplement correctement sur l'appareil, mais qu'elles le font avec des performances raisonnables et une bonne expérience utilisateur globale. Les implémentations de périphériques doivent respecter les mesures de performances clés d'un périphérique compatible Android 2.1 défini dans le tableau ci-dessous:

    Metric Performances Seuil Commentaires
    Application Temps de lancement de l'application Les applications suivantes doivent être lancées dans le délai spécifié.
    • Navigateur: moins de 1300 ms
    • MMS / SMS: moins de 700 ms
    • AlarmClock: moins de 650 ms,
    		 le temps de lancement est mesuré comme le temps total pour terminer le chargement de l'activité par défaut pour l'application, y compris le temps nécessaire pour démarrer le processus Linux, charger l'androïde Emballage dans la machine virtuelle Dalvik et appelez OnCreate.
    Les applications simultanées lorsque plusieurs applications ont été lancées, la relance d'une application déjà coupée après son lancement doit prendre moins que le temps de lancement d'origine.  

    10.

    Implémentations de dispositifs de compatibilité des modèles de sécurité doit implémenter un modèle de sécurité cohérent avec le modèle de sécurité Android Platform tel que défini dans la sécurité et le document de référence des autorisations dans les API [ Resources, 28 ] dans la documentation du développeur Android. Les implémentations de l'appareil doivent prendre en charge l'installation d'applications auto-signées sans nécessiter d'autorisations / certificats supplémentaires à des tiers / autorités. Plus précisément, les dispositifs compatibles doivent prendre en charge les mécanismes de sécurité décrits dans les sous-sections suivantes.

    10.1.

    Les implémentations des périphériques

    d'autorisations

    doivent prendre en charge le modèle Android des autorisations telles que définies dans la documentation du développeur Android [ Resources, 28 ]. Plus précisément, les implémentations doivent appliquer chaque autorisation définie comme décrit dans la documentation SDK; Aucune autorisation ne peut être omise, modifiée ou ignorée. Les implémentations peuvent ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'ID d'autorisation ne soient pas dans l'espace de noms Android.

    10.2.

    Les implémentations de périphériques

    UID et d'isolement de processus

    doivent prendre en charge le modèle de bac à sandbox de l'application Android, dans laquelle chaque application s'exécute comme un UID de style Unix unique et dans un processus distinct. Les implémentations de périphériques doivent prendre en charge l'exécution de plusieurs applications comme le même ID utilisateur Linux, à condition que les applications soient correctement signées et construites, telles que définies dans la référence de sécurité et les autorisations [ Resources, 28 ].

    10.3.

    Les implémentations des périphériques

    d'autorisations de système de fichiers

    doivent prendre en charge le modèle d'autorisations d'accès aux fichiers Android tel que défini comme défini dans la référence de sécurité et des autorisations [ Resources, 28 ].

    11. Les implémentations de périphériques de la suite de tests de compatibilité

    doivent passer la suite de tests de compatibilité Android (CTS) [ Ressources, 2 ] disponibles à partir du projet Open Source Android, en utilisant le logiciel d'expédition final sur l'appareil. De plus, les implémenteurs de périphériques doivent utiliser autant que possible l'implémentation de référence dans l'arbre open source Android et doivent assurer la compatibilité des cas d'ambiguïté dans CTS et pour toute réimplémentation des parties du code source de référence.

    Le CTS est conçu pour être exécuté sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bogues. Le CTS sera versé indépendamment de cette définition de compatibilité, et plusieurs révisions du CTS peuvent être publiées pour Android 2.1. Les implémentations de l'appareil doivent passer la dernière version CTS disponible au moment où le logiciel de périphérique est terminé.

    12. Les implémentations de périphériques logicielles à jour

    doivent inclure un mécanisme pour remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer des mises à niveau "en direct" - c'est-à-dire qu'un redémarrage de l'appareil peut être nécessaire.

    Toute méthode peut être utilisée, à condition qu'il puisse remplacer l'intégralité du logiciel préinstallé sur l'appareil. Par exemple, l'une des approches suivantes satisfera à cette exigence:

    • les téléchargements en direct (OTA) avec mise à jour hors ligne via
      • les mises à jour "
    • attachées
    • " à redémarrage " Stockage amovible

    Le mécanisme de mise à jour utilisé doit prendre en charge les mises à jour sans essuyer les données utilisateur. Notez que le logiciel Android en amont comprend un mécanisme de mise à jour qui satisfait à cette exigence.

    Si une erreur est trouvée dans une implémentation de dispositif après sa sortie, mais dans sa durée de vie raisonnable de produit déterminée en consultation avec l'équipe de compatibilité Android pour affecter la compatibilité des applications Thid-Parts, l'implémentateur de périphérique doit corriger l'erreur via un logiciel Mise à jour disponible qui peut être appliquée par le mécanisme qui vient d'être décrit.

    13. Contactez-nous,

    vous pouvez contacter les auteurs du document à compatibilité@android.com pour des clarifications et pour soulever tous les problèmes que vous pensez que le document ne couvre pas.