Definizione di compatibilità con Android 2.1

Copyright © 2010, Google Inc. Tutti i diritti riservati.
compatibilità@android.com

1. Introduzione

Questo documento elenca i requisiti che devono essere soddisfatti affinché i telefoni cellulari siano compatibili con Android 2.1.

L'uso di "deve", "non deve", "richiesto", "deve", "non deve", "dovrebbe", "non dovrebbe", "consigliato", "può" e "facoltativo" è conforme allo standard IETF definito in RFC2119 [ Risorse, 1 ].

Come utilizzato in questo documento, un "implementatore del dispositivo" o "implementatore" è una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 2.1. Una "implementazione del dispositivo" o "implementazione" è la soluzione hardware/software così sviluppata.

Per essere considerato compatibile con Android 2.1, implementazioni del dispositivo:

  • DEVE soddisfare i requisiti presentati nella presente Definizione di compatibilità, inclusi eventuali documenti incorporati tramite riferimento.
  • DEVE superare la versione più recente di Android Compatibility Test Suite (CTS) disponibile al momento del completamento dell'implementazione del software del dispositivo. (Il CTS è disponibile come parte del progetto Android Open Source [ Risorse, 2 ].) Il CTS testa molti, ma non tutti, i componenti descritti in questo documento.

Laddove questa definizione o il CTS siano silenziosi, ambigui o incompleti, è responsabilità dell'implementatore del dispositivo garantire la compatibilità con le implementazioni esistenti. Per questo motivo, il progetto Android Open Source [ Risorse, 3 ] è sia l'implementazione di riferimento che quella preferita di Android. Gli implementatori dei dispositivi sono fortemente incoraggiati a basare le proprie implementazioni sul codice sorgente "upstream" disponibile dal progetto Android Open Source. Sebbene alcuni componenti possano ipoteticamente essere sostituiti con implementazioni alternative, questa pratica è fortemente sconsigliata, poiché superare i test CTS diventerà sostanzialmente più difficile. È responsabilità dell'implementatore garantire la piena compatibilità comportamentale con l'implementazione Android standard, inclusa e oltre la Compatibility Test Suite. Infine, si noti che alcune sostituzioni e modifiche di componenti sono esplicitamente vietate da questo documento.

2. Risorse
  • Livelli dei requisiti IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  • Panoramica del programma di compatibilità Android: http://source.android.com/compatibility/index.html
  • Progetto open source Android: http: //source.android.com/
  • Definizioni e documentazione API: http://developer.android.com/reference/packages.html
  • Riferimento per le autorizzazioni Android: http://developer.android.com/reference/android/Manifest.permission. html
  • riferimento android.os.Build: http://developer.android.com/reference/android/os/Build.html
  • Stringhe della versione consentita per Android 2.1: http://source.android.com/docs/compatibility/2.1/versions .html
  • classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  • HTML5: http://www.whatwg.org/specs/web-apps/current-work/
    • specifica
  • multipagina/
  • Dalvik Virtual Machine: disponibile nel codice sorgente Android, su dalvik/docs
    •
  • AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  • Notifiche: http://developer.android.com /guide/topics/ui/notifiers/notifications.html
  • Risorse dell'applicazione: http://code.google.com/android/reference/available-resources.html
  • Guida allo stile delle icone della barra di stato: http://developer.android.com/ guide/practices/ui_guideline /icon_design.html#statusbarstructure
  • Gestione ricerca: http://developer.android.com/reference/android/app/SearchManager.html
  • Toast: http://developer.android.com/reference/android/widget /Toast.html
  • Sfondi animati: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  • App per Android: http://code.google.com/p/apps-for-android
  • Riferimenti documentazione dello strumento (per adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  • Descrizione del file apk Android: http://developer.android.com/guide/topics/fundamentals .html
  • File manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  • Strumento di test delle scimmie: https://developer.android.com/studio/test/other-testing-tools/ scimmia
  • che supporta più schermi: 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
  • Spazio delle coordinate del sensore: http://developer.android.com/reference/android/hardware/SensorEvent.html
  • Riferimento per la sicurezza e le autorizzazioni Android: http://developer.android.com/guide/topics/security/security.html
  • Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

    • Molte di queste risorse derivano direttamente o indirettamente dall'SDK di Android 2.1 e saranno funzionalmente identiche alle informazioni contenute nella documentazione dell'SDK . In tutti i casi in cui la presente Definizione di compatibilità o la Suite di test di compatibilità non sono d'accordo con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Tutti i dettagli tecnici forniti nei riferimenti sopra inclusi sono considerati per inclusione parte della presente Definizione di compatibilità.

    3. Software

    La piattaforma Android include un set di API gestite, un set di API native e un corpo di cosiddette API "soft" come il sistema Intent e le API delle applicazioni web. Questa sezione descrive in dettaglio le API hardware e software che sono parte integrante della compatibilità, nonché alcuni altri comportamenti tecnici e dell'interfaccia utente rilevanti. Le implementazioni del dispositivo DEVONO essere conformi a tutti i requisiti di questa sezione.

    3.1. Compatibilità API gestite

    L'ambiente di esecuzione gestito (basato su Dalvik) è il veicolo principale per le applicazioni Android. L'API (Application Programming Interface) Android è l'insieme di interfacce della piattaforma Android esposte alle applicazioni in esecuzione nell'ambiente VM gestito. Le implementazioni del dispositivo DEVONO fornire implementazioni complete, inclusi tutti i comportamenti documentati, di qualsiasi API documentata esposta dall'SDK di Android 2.1 [ Risorse, 4 ].

    Le implementazioni del dispositivo NON DEVONO omettere alcuna API gestita, alterare le interfacce o le firme API, discostarsi dal comportamento documentato o includere no-op, tranne dove specificamente consentito dalla presente Definizione di compatibilità.

    3.2. Compatibilità API soft

    Oltre alle API gestite della Sezione 3.1, Android include anche una significativa API "soft" solo runtime, sotto forma di elementi come intenti, autorizzazioni e aspetti simili delle applicazioni Android che non possono essere applicati all'applicazione tempo di compilazione. Questa sezione descrive in dettaglio le API "soft" e i comportamenti del sistema richiesti per la compatibilità con Android 2.1. Le implementazioni del dispositivo DEVONO soddisfare tutti i requisiti presentati in questa sezione.

    3.2.1. Autorizzazioni

    Gli implementatori del dispositivo DEVONO supportare e applicare tutte le costanti di autorizzazione come documentato dalla pagina di riferimento sulle autorizzazioni [ Risorse, 5 ]. Tieni presente che la Sezione 10 elenca i requisiti aggiuntivi relativi al modello di sicurezza Android.

    3.2.2. Parametri di build

    Le API Android includono una serie di costanti nella classe android.os.Build [ Resources, 6 ] che hanno lo scopo di descrivere il dispositivo corrente. Per fornire valori coerenti e significativi tra le implementazioni del dispositivo, la tabella seguente include ulteriori restrizioni sui formati di questi valori a cui le implementazioni del dispositivo DEVONO conformarsi.

    Parametro Commenti
    android.os.Build.VERSION.RELEASE La versione del sistema Android attualmente in esecuzione, in formato leggibile dall'uomo. Questo campo DEVE avere uno dei valori stringa definiti in [ Risorse, 7 ].
    android.os.Build.VERSION.SDK La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 2.1, questo campo DEVE avere il valore intero 7.
    android.os.Build.VERSION.INCREMENTAL Un valore scelto dall'implementatore del dispositivo che designa la build specifica del sistema Android attualmente in esecuzione, in formato leggibile dall'uomo. Questo valore NON DEVE essere riutilizzato per build diverse spedite agli utenti finali. Un utilizzo tipico di questo campo è indicare quale numero di build o identificatore di modifica del controllo del codice sorgente è stato utilizzato per generare la build. Non ci sono requisiti sul formato specifico di questo campo, tranne che NON DEVE essere null o una stringa vuota ("").
    android.os.Build.BOARD Un valore scelto dall'implementatore del dispositivo che identifica l'hardware interno specifico utilizzato dal dispositivo, in formato leggibile dall'uomo. Un possibile utilizzo di questo campo è quello di indicare la revisione specifica della scheda che alimenta il dispositivo. Non ci sono requisiti sul formato specifico di questo campo, tranne che NON DEVE essere null o una stringa vuota ("").
    android.os.Build.BRAND Un valore scelto dall'implementatore del dispositivo che identifica il nome dell'azienda, organizzazione, individuo, ecc. che ha prodotto il dispositivo, in formato leggibile dall'uomo. Un possibile utilizzo di questo campo è indicare l'OEM e/o il corriere che ha venduto il dispositivo. Non ci sono requisiti sul formato specifico di questo campo, tranne che NON DEVE essere null o una stringa vuota ("").
    android.os.Build.DEVICE Un valore scelto dall'implementatore del dispositivo che identifica la specifica configurazione o revisione del corpo (a volte chiamato "design industriale") del dispositivo. Non ci sono requisiti sul formato specifico di questo campo, tranne che NON DEVE essere null o una stringa vuota ("").
    android.os.Build.FINGERPRINT Una stringa che identifica in modo univoco questa build. DOVREBBE essere ragionevolmente leggibile dall'uomo. DEVE seguire questo modello:
    $(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
    Per esempio:
    acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keys
    L'impronta digitale NON DEVE contenere spazi. Se altri campi inclusi nel modello precedente contengono spazi, DOVREBBERO essere sostituiti con il carattere di sottolineatura ASCII ("_") nell'impronta digitale.
    android.os.Build.HOST Una stringa che identifica in modo univoco l'host su cui è stata creata la build, in formato leggibile dall'uomo. Non ci sono requisiti sul formato specifico di questo campo, tranne che NON DEVE essere null o una stringa vuota ("").
    android.os.Build.ID Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una versione specifica, in formato leggibile dall'uomo. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DOVREBBE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere tra build di software. Non ci sono requisiti sul formato specifico di questo campo, tranne che NON DEVE essere null o una stringa vuota ("").
    android.os.Build.MODEL Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo noto all'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non ci sono requisiti sul formato specifico di questo campo, tranne che NON DEVE essere null o una stringa vuota ("").
    android.os.Build.PRODUCT Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice del dispositivo. DEVE essere leggibile dall'uomo, ma non è necessariamente destinato alla visualizzazione da parte degli utenti finali. Non ci sono requisiti sul formato specifico di questo campo, tranne che NON DEVE essere null o una stringa vuota ("").
    android.os.Build.TAGS Un elenco di tag separati da virgole scelti dall'implementatore del dispositivo che distinguono ulteriormente la build. Ad esempio, "unsigned,debug". Questo campo NON DEVE essere nullo o una stringa vuota (""), ma un singolo tag (come "release") va bene.
    android.os.Build.TIME Un valore che rappresenta il timestamp di quando si è verificata la compilazione.
    android.os.Build.TYPE Un valore scelto dall'implementatore del dispositivo specificando la configurazione di runtime della build. Questo campo DOVREBBE avere uno dei valori corrispondenti alle tre tipiche configurazioni di runtime di Android: "user", "userdebug" o "eng".
    android.os.Build.USER Un nome o ID utente dell'utente (o utente automatizzato) che ha generato la build. Non ci sono requisiti sul formato specifico di questo campo, tranne che NON DEVE essere null o una stringa vuota ("").

    3.2.3. Compatibilità degli intent

    Android utilizza gli intent per ottenere un'integrazione liberamente accoppiata tra le applicazioni. Questa sezione descrive i requisiti relativi ai modelli di intenti che DEVONO essere rispettati dalle implementazioni del dispositivo. Con "onorato" si intende che l'implementatore del dispositivo DEVE fornire un'attività o un servizio Android che specifica un filtro di intento corrispondente e si lega e implementa il comportamento corretto per ogni modello di intento specificato.

    3.2.3.1. Intenti dell'applicazione principale

    Il progetto upstream Android definisce una serie di applicazioni principali, come un combinatore telefonico, un calendario, una rubrica, un lettore musicale e così via. Gli implementatori del dispositivo POSSONO sostituire queste applicazioni con versioni alternative.

    Tuttavia, qualsiasi versione alternativa di questo tipo DEVE rispettare gli stessi modelli di intenti forniti dal progetto upstream. Ad esempio, se un dispositivo contiene un lettore musicale alternativo, deve comunque rispettare lo schema di intenti emesso dalle applicazioni di terze parti per scegliere un brano.

    Le seguenti applicazioni sono considerate applicazioni principali del sistema Android:

    • Orologio da tavolo
    • Browser
    • Calendario
    • Calcolatrice
    • Fotocamera
    • Contatti
    • Galleria
    • e-mail
    • GlobalSearch
    • Launcher
    • LivePicker (ovvero l'applicazione di selezione sfondi animati; PUÒ essere omessa se il dispositivo non supporta gli sfondi animati, secondo la Sezione 3.8.5. )
    • Messaggi (noti anche come "Mms")
    • Musica
    • Impostazioni
    • del telefono
    • Registratore di suoni

    Le applicazioni principali del sistema Android includono varie attività o componenti di servizio considerati "pubblici". Cioè, l'attributo "android:exported" potrebbe essere assente o avere il valore "true".

    Per ogni attività o servizio definito in una delle app principali del sistema Android che non è contrassegnato come non pubblico tramite un attributo android:exported con il valore "false", le implementazioni del dispositivo DEVONO includere un componente dello stesso tipo che implementa lo stesso filtro di intenti pattern come app principale del sistema Android.

    In altre parole, l’implementazione di un dispositivo PUÒ sostituire le app principali del sistema Android; tuttavia, in tal caso, l'implementazione del dispositivo DEVE supportare tutti i modelli di intenti definiti da ciascuna app di sistema Android principale da sostituire.

    3.2.3.2. Sostituzioni dell'intento

    Poiché Android è una piattaforma estensibile, gli implementatori del dispositivo DEVONO consentire che ogni modello di intento definito nelle app di sistema principali venga sovrascritto da applicazioni di terze parti. Il progetto open source Android upstream lo consente per impostazione predefinita; gli implementatori del dispositivo NON DEVONO attribuire privilegi speciali all'utilizzo di questi modelli di intenti da parte delle applicazioni di sistema, né impedire ad applicazioni di terze parti di legarsi e assumere il controllo di questi modelli. Questo divieto include specificamente, ma non è limitato alla disabilitazione dell'interfaccia utente "Scelta" che consente all'utente di selezionare tra più applicazioni che gestiscono tutte lo stesso modello di intenti.

    Nota: questa sezione è stata modificata da Erratum EX6580.

    3.2.3.3. Spazi dei nomi degli intenti

    Gli implementatori dei dispositivi NON DEVONO includere alcun componente Android che rispetti nuovi modelli di intenti o intenti di trasmissione utilizzando un'AZIONE, una CATEGORIA o un'altra stringa chiave nello spazio dei nomi android.*. Gli implementatori del dispositivo NON DEVONO includere componenti Android che rispettino nuovi modelli di intenti o intenti di trasmissione utilizzando un'AZIONE, una CATEGORIA o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione. Gli implementatori del dispositivo NON DEVONO alterare o estendere nessuno dei modelli di intenti utilizzati dalle app principali elencate nella Sezione 3.2.3.1.

    Questo divieto è analogo a quello specificato per le classi del linguaggio Java nella Sezione 3.6.

    3.2.3.4. Intenti di trasmissione

    Le applicazioni di terze parti si affidano alla piattaforma per trasmettere determinati intenti per notificare loro le modifiche nell'ambiente hardware o software. I dispositivi compatibili con Android DEVONO trasmettere gli intenti di trasmissione pubblica in risposta agli eventi di sistema appropriati. Gli intenti di trasmissione sono descritti nella documentazione dell'SDK.

    3.3. Compatibilità API nativa

    Il codice gestito in esecuzione in Dalvik può richiamare il codice nativo fornito nel file .apk dell'applicazione come file ELF .so compilato per l'architettura hardware del dispositivo appropriata. Le implementazioni del dispositivo DEVONO includere il supporto per il codice in esecuzione nell'ambiente gestito per richiamare il codice nativo, utilizzando la semantica JNI (Java Native Interface) standard. Le seguenti API DEVONO essere disponibili per il codice nativo:

    • libc (libreria C)
    • libm (libreria matematica)
    • interfaccia JNI
    • libz (compressione Zlib)
    • liblog (registrazione Android)
    • Supporto minimo per C++
    • Supporto per OpenGL, come descritto di seguito
      • Le implementazioni del dispositivo DEVONO supportare

    OpenGL ES 1.0 . I dispositivi privi di accelerazione hardware DEVONO implementare OpenGL ES 1.0 utilizzando un renderer software. Le implementazioni del dispositivo DOVREBBERO implementare tanto OpenGL ES 1.1 quanto supportato dall'hardware del dispositivo. Le implementazioni del dispositivo DOVREBBERO fornire un'implementazione per OpenGL ES 2.0, se l'hardware è in grado di fornire prestazioni ragionevoli su tali API.

    Queste librerie DEVONO essere compatibili con il codice sorgente (ovvero compatibili con l'intestazione) e compatibili con il codice binario (per una determinata architettura del processore) con le versioni fornite in Bionic dal progetto Android Open Source. Poiché le implementazioni Bionic non sono completamente compatibili con altre implementazioni come la libreria GNU C, gli implementatori del dispositivo DOVREBBERO utilizzare l'implementazione Android. Se gli implementatori del dispositivo utilizzano un'implementazione diversa di queste librerie, DEVONO garantire la compatibilità di intestazione, file binario e comportamento.

    Le implementazioni del dispositivo DEVONO riportare accuratamente l'Application Binary Interface (ABI) nativa supportata dal dispositivo, tramite l'API android.os.Build.CPU_ABI . L'ABI DEVE essere una delle voci documentate nell'ultima versione di Android NDK, nel file docs/CPU-ARCH-ABIS.txt . Tieni presente che versioni aggiuntive di Android NDK potrebbero introdurre il supporto per ABI aggiuntivi.

    La compatibilità del codice nativo è impegnativa. Per questo motivo, va ripetuto che gli implementatori dei dispositivi sono MOLTO fortemente incoraggiati a utilizzare le implementazioni upstream delle librerie sopra elencate, per garantire la compatibilità.

    3.4. Compatibilità API Web

    Molti sviluppatori e applicazioni si affidano al comportamento della classe android.webkit.WebView [ Resources, 8 ] per le loro interfacce utente, quindi l'implementazione WebView deve essere compatibile con tutte le implementazioni Android. L'implementazione Android Open Source utilizza il motore di rendering WebKit per implementare WebView.

    Poiché non è possibile sviluppare una suite di test completa per un browser web, gli implementatori del dispositivo DEVONO utilizzare la specifica build upstream di WebKit nell'implementazione WebView. Nello specifico:

    • WebView DEVE utilizzare la build WebKit 530.17 dall'albero Android Open Source upstream per Android 2.1. Questa build include un insieme specifico di funzionalità e correzioni di sicurezza per WebView.
    • La stringa dello user agent riportata da WebView DEVE essere in questo formato:
      Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
      • di La stringa $(VERSION) DEVE essere uguale al valore di android.os.Build.VERSION.RELEASE
      • Il valore della stringa $(LOCALE) DOVREBBE seguire le convenzioni ISO per il codice paese e la lingua e DOVREBBE fare riferimento alla locale attualmente configurata del dispositivo
      • Il valore della stringa $(MODEL) DEVE essere uguale al valore di android.os.Build.MODEL
      • Il valore della stringa $(BUILD) DEVE essere uguale al valore di android.os.Build.ID
    Le implementazioni
      • android.os.Build.ID

    fornire una stringa dell'agente utente personalizzata nell'applicazione browser autonoma. Inoltre, il browser autonomo PUÒ essere basato su una tecnologia browser alternativa (come Firefox, Opera, ecc.). Tuttavia, anche se viene fornita un'applicazione browser alternativa, il componente WebView fornito alle applicazioni di terze parti DEVE essere basato su WebKit, come sopra.

    La configurazione di WebView DEVE includere il supporto per il database HTML5, la cache dell'applicazione e le API di geolocalizzazione [ Risorse, 9 ]. Il WebView DEVE includere il supporto per il tag HTML5 <video> in qualche forma. L'applicazione browser autonoma (basata sull'applicazione browser WebKit upstream o su una sostituzione di terze parti) DEVE includere il supporto per le stesse funzionalità HTML5 appena elencate per WebView.

    3.5. Compatibilità comportamentale dell'API

    I comportamenti di ciascuno dei tipi di API (gestita, soft, nativa e web) devono essere coerenti con l'implementazione preferita del progetto open source Android upstream [ Risorse, 3 ]. Alcune aree specifiche di compatibilità sono:

    • I dispositivi NON DEVONO modificare il comportamento o il significato di un intento standard
    • I dispositivi NON DEVONO alterare il ciclo di vita o la semantica del ciclo di vita di un particolare tipo di componente di sistema (come Servizio, Attività, ContentProvider, ecc.) I
    • dispositivi NON DEVONO modificare la semantica di una particolare autorizzazione

    L'elenco precedente non è completo e spetta agli implementatori del dispositivo garantire la compatibilità comportamentale. Per questo motivo, gli implementatori del dispositivo DOVREBBERO utilizzare, ove possibile, il codice sorgente disponibile tramite il progetto Android Open Source, anziché reimplementare parti significative del sistema.

    La Compatibility Test Suite (CTS) verifica la compatibilità comportamentale di parti significative della piattaforma, ma non di tutte. È responsabilità dell'implementatore garantire la compatibilità comportamentale con il progetto Android Open Source.

    3.6. Spazi dei nomi API

    Android segue le convenzioni degli spazi dei nomi dei pacchetti e delle classi definite dal linguaggio di programmazione Java. Per garantire la compatibilità con applicazioni di terze parti, gli implementatori del dispositivo NON DEVONO apportare modifiche vietate (vedere di seguito) a questi spazi dei nomi dei pacchetti:

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

    modifiche vietate includono:

    • Le implementazioni del dispositivo DEVONO NON modificare le API esposte pubblicamente sulla piattaforma Android modificando metodi o firme di classe oppure rimuovendo classi o campi di classe.
    • Gli implementatori del dispositivo POSSONO modificare l'implementazione sottostante delle API, ma tali modifiche NON DEVONO influire sul comportamento dichiarato e sulla firma del linguaggio Java di qualsiasi API esposta pubblicamente.
    • Gli implementatori del dispositivo NON DEVONO aggiungere alcun elemento esposto pubblicamente (come classi o interfacce, o campi o metodi a classi o interfacce esistenti) alle API di cui sopra.

    Un "elemento esposto pubblicamente" è qualsiasi costrutto che non è decorato con il marcatore "@hide" nel codice sorgente Android upstream. In altre parole, gli implementatori del dispositivo NON DEVONO esporre nuove API o alterare le API esistenti negli spazi dei nomi sopra indicati. Gli implementatori del dispositivo POSSONO apportare modifiche solo interne, ma tali modifiche NON DEVONO essere pubblicizzate o altrimenti esposte agli sviluppatori.

    Gli implementatori del dispositivo POSSONO aggiungere API personalizzate, ma tali API NON DEVONO trovarsi in uno spazio dei nomi di proprietà o fare riferimento a un'altra organizzazione. Ad esempio, gli implementatori del dispositivo NON DEVONO aggiungere API allo spazio dei nomi com.google.* o simile; solo Google può farlo. Allo stesso modo, Google NON DEVE aggiungere API agli spazi dei nomi di altre società.

    Se l'implementatore di un dispositivo propone di migliorare uno degli spazi dei nomi dei pacchetti di cui sopra (ad esempio aggiungendo nuove funzionalità utili a un'API esistente o aggiungendo una nuova API), l'implementatore DOVREBBE visitare source.android.com e iniziare il processo per apportare modifiche e codice, secondo le informazioni su quel sito.

    Tieni presente che le restrizioni di cui sopra corrispondono alle convenzioni standard per la denominazione delle API nel linguaggio di programmazione Java; questa sezione mira semplicemente a rafforzare tali convenzioni e renderle vincolanti attraverso l'inclusione in questa definizione di compatibilità.

    3.7. Compatibilità della macchina virtuale

    Le implementazioni del dispositivo DEVONO supportare la specifica completa del bytecode Dalvik Executable (DEX) e la semantica della macchina virtuale Dalvik [ Risorse, 10 ].

    Le implementazioni dei dispositivi DEVONO configurare Dalvik per allocare almeno 16 MB di memoria a ciascuna applicazione su dispositivi con schermi classificati come a media o bassa densità. Le implementazioni dei dispositivi DEVONO configurare Dalvik per allocare almeno 24 MB di memoria a ciascuna applicazione su dispositivi con schermi classificati come ad alta densità. Tieni presente che le implementazioni del dispositivo POSSONO allocare più memoria di queste cifre, ma non sono obbligate a farlo.

    3.8. Compatibilità dell'interfaccia utente

    La piattaforma Android include alcune API per sviluppatori che consentono agli sviluppatori di collegarsi all'interfaccia utente del sistema. Le implementazioni dei dispositivi DEVONO incorporare queste API dell'interfaccia utente standard nelle interfacce utente personalizzate che sviluppano, come spiegato di seguito.

    3.8.1. Widget

    Android definisce un tipo di componente, l'API corrispondente e il ciclo di vita che consente alle applicazioni di esporre un "AppWidget" all'utente finale [ Risorse, 11 ]. La versione di riferimento Android Open Source include un'applicazione Launcher che include elementi dell'interfaccia utente che consentono all'utente di aggiungere, visualizzare e rimuovere AppWidget dalla schermata principale.

    Gli implementatori del dispositivo POSSONO sostituire un'alternativa al Launcher di riferimento (ad esempio la schermata iniziale). I launcher alternativi DOVREBBERO includere il supporto integrato per gli AppWidget ed esporre gli elementi dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere gli AppWidget direttamente nel Launcher. I lanciatori alternativi POSSONO omettere questi elementi dell'interfaccia utente; tuttavia, se vengono omessi, l'implementatore del dispositivo DEVE fornire un'applicazione separata accessibile dal Launcher che consenta agli utenti di aggiungere, configurare, visualizzare e rimuovere AppWidget.

    3.8.2. Notifiche

    Android include API che consentono agli sviluppatori di avvisare gli utenti di eventi importanti [ Risorse, 12 ]. Gli implementatori del dispositivo DEVONO fornire supporto per ciascuna classe di notifica così definita; nello specifico: suoni, vibrazioni, luce e barra di stato.

    Inoltre, l'implementazione DEVE eseguire correttamente il rendering di tutte le risorse (icone, file audio, ecc.) fornite nelle API [ Risorse, 13 ] o nella guida allo stile delle icone della barra di stato [ Risorse, 14 ]. Gli implementatori del dispositivo POSSONO fornire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'implementazione Android Open Source di riferimento; tuttavia, tali sistemi di notifica alternativi DEVONO supportare le risorse di notifica esistenti, come sopra.

    Android include API [ Risorse, 15 ] che consentono agli sviluppatori di incorporare la ricerca nelle loro applicazioni ed esporre i dati dell'applicazione nella ricerca del sistema globale. In generale, questa funzionalità è costituita da un'unica interfaccia utente a livello di sistema che consente agli utenti di immettere query, visualizzare suggerimenti durante la digitazione e visualizzare i risultati. Le API Android consentono agli sviluppatori di riutilizzare questa interfaccia per fornire la ricerca all'interno delle proprie app e di fornire risultati all'interfaccia utente di ricerca globale comune.

    Le implementazioni del dispositivo DEVONO includere un'unica interfaccia utente di ricerca condivisa a livello di sistema in grado di fornire suggerimenti in tempo reale in risposta all'input dell'utente. Le implementazioni dei dispositivi DEVONO implementare le API che consentono agli sviluppatori di riutilizzare questa interfaccia utente per fornire la ricerca all'interno delle proprie applicazioni. Le implementazioni del dispositivo DEVONO implementare le API che consentono alle applicazioni di terze parti di aggiungere suggerimenti alla casella di ricerca quando viene eseguita in modalità di ricerca globale. Se non sono installate applicazioni di terze parti che utilizzano questa funzionalità, il comportamento predefinito DOVREBBE essere quello di visualizzare i risultati e i suggerimenti del motore di ricerca web.

    Le implementazioni del dispositivo POSSONO fornire interfacce utente di ricerca alternative, ma DOVREBBERO includere un pulsante di ricerca dedicato, hardware o software, che può essere utilizzato in qualsiasi momento all'interno di qualsiasi app per richiamare il framework di ricerca, con il comportamento previsto nella documentazione dell'API.

    3.8.4. Toast

    Le applicazioni possono utilizzare l'API "Toast" (definita in [ Risorse, 16 ]) per visualizzare brevi stringhe non modali all'utente finale, che scompaiono dopo un breve periodo di tempo. Le implementazioni dei dispositivi DEVONO visualizzare i toast dalle applicazioni agli utenti finali in modo ad alta visibilità.

    3.8.5. Live Wallpapers

    Android definisce un tipo di componente e l'API e il ciclo di vita corrispondenti che consentono alle applicazioni di esporre uno o più "Live Wallpapers" all'utente finale [ Risorse, 17 ]. Gli sfondi animati sono animazioni, motivi o immagini simili con capacità di input limitate che vengono visualizzati come sfondi, dietro altre applicazioni.

    L'hardware è considerato in grado di eseguire in modo affidabile sfondi live se è in grado di eseguire tutti gli sfondi live, senza limitazioni di funzionalità, a un framerate ragionevole senza effetti negativi su altre applicazioni. Se le limitazioni dell'hardware causano l'arresto anomalo, il malfunzionamento degli sfondi e/o delle applicazioni, un consumo eccessivo della CPU o della batteria o l'esecuzione a frame rate inaccettabilmente bassi, l'hardware è considerato incapace di eseguire sfondi animati. Ad esempio, alcuni sfondi animati possono utilizzare un contesto Open GL 1.0 o 2.0 per visualizzare il proprio contenuto. Lo sfondo animato non funzionerà in modo affidabile su hardware che non supporta più contesti OpenGL poiché l'utilizzo dello sfondo animato di un contesto OpenGL potrebbe entrare in conflitto con altre applicazioni che utilizzano anch'esse un contesto OpenGL.

    Le implementazioni dei dispositivi in ​​grado di eseguire sfondi live in modo affidabile come descritto sopra DOVREBBERO implementare sfondi live. Le implementazioni del dispositivo determinate per non eseguire sfondi live in modo affidabile come descritto sopra NON DEVONO implementare sfondi live.

    4. Compatibilità del software di riferimento

    Gli implementatori del dispositivo DEVONO testare la compatibilità dell'implementazione utilizzando le seguenti applicazioni open source:

    • Calcolatrice (inclusa nell'SDK)
    • Lunar Lander (inclusa nell'SDK)
    • Le applicazioni "App per Android" [ Risorse, 18 ].

    Ciascuna app sopra DEVE essere avviata e comportarsi correttamente durante l'implementazione, affinché l'implementazione sia considerata compatibile.

    Inoltre, le implementazioni del dispositivo DEVONO testare ciascuna voce di menu (inclusi tutti i sottomenu) di ciascuna di queste applicazioni di test del fumo:

    • ApiDemos (incluso nell'SDK)
    • ManualSmokeTests (incluso nel CTS)

    Ciascun caso di test nelle applicazioni sopra DEVE essere eseguito correttamente sul dispositivo implementazione.

    5. Compatibilità del packaging delle applicazioni

    Le implementazioni dei dispositivi DEVONO installare ed eseguire i file ".apk" di Android generati dallo strumento "aapt" incluso nell'SDK ufficiale di Android [ Risorse, 19 ].

    Le implementazioni dei dispositivi NON DEVONO estendere i formati .apk [ Resources, 20 ], Android Manifest [ Resources, 21 ] o Dalvik bytecode [ Resources, 10 ] in modo tale da impedire l'installazione e il corretto funzionamento di tali file su altri dispositivi compatibili . Gli implementatori del dispositivo DOVREBBERO utilizzare l'implementazione upstream di riferimento di Dalvik e il sistema di gestione dei pacchetti dell'implementazione di riferimento.

    6. Compatibilità multimediale

    Le implementazioni del dispositivo DEVONO supportare i seguenti codec multimediali. Tutti questi codec vengono forniti come implementazioni software nell'implementazione Android preferita dal progetto Android Open Source.

    Tieni presente che né Google né Open Handset Alliance rilasciano alcuna garanzia che questi codec non siano gravati da brevetti di terze parti. Coloro che intendono utilizzare questo codice sorgente in prodotti hardware o software sono informati che le implementazioni di questo codice, inclusi software open source o shareware, potrebbero richiedere licenze di brevetto da parte dei relativi titolari dei brevetti.

    Nome (.Wav) Base X Base
    audio
    Codificatore Decodificatore Dettagli Formato file/contenitore
    AAC LC/LTP   X Contenuti mono/stereo in qualsiasi combinazione di bit rate standard fino a 160 kbps e frequenze di campionamento comprese tra 8 e 48 kHz 3GPP (.3gp) e MPEG-4 (.mp4, .m4a). Nessun supporto per AAC non elaborato (.aac)
    HE-AACv1 (AAC+)   X
    HE-AACv2 (AAC+ potenziato)   X
    AMR-NB X X Da 4,75 a 12,2 kbps campionati a 8kHz 3GPP (.3gp)
    AMR-WB   X 9 velocità da 6,60 kbit/s a 23,85 kbit/s campionati a 16kHz 3GPP (.3gp)
    MP3   X Mono/Stereo 8-320 Kbps costante (CBR) o bit rate variabile (VBR) MP3 (.mp3)
    MIDI   X MIDI Tipo 0 e 1. DLS versione 1 e 2. XMF e mobile XMF. Supporto per formati di suoneria RTTTL/RTX, OTA e IMELODY Tipo 0 e 1 (.mid, .xmf, .mxmf). Anche rtttl/rtx (.rtttl, .rtx), ota (.ota) e imelody (.imy)
    ogg vorbis   X   OGG (.OGG)
    PCM   X IMMAGINE OGNA (.WAV)
    immagine
    di Base XX Base X Base X Base+Progressive Progressi  
    GIF   X   
    Png x x   
    BMP   X   
    Video
    H.263 X X   File 3GPP (.3GP)
    H.264   X   3GPP (.3GP) e MPEG-4 (.mp4) file
    MPEG4 Simple Profile   X   File 3GPP (.3GP)

    Nota che la tabella sopra non elenca requisiti di bitrate specifici per la maggior parte dei codec video. La ragione di ciò è che, in pratica, l'attuale hardware del dispositivo non supporta necessariamente i bitrati che mappano esattamente ai bitrati richiesti specificati dagli standard pertinenti. Invece, le implementazioni del dispositivo dovrebbero supportare il bitrate più alto pratico sull'hardware, fino ai limiti definiti dalle specifiche.

    7.

    Le implementazioni di dispositivi di compatibilità degli strumenti per sviluppatori devono supportare gli strumenti di sviluppatori Android forniti nell'SDK Android. In particolare, i dispositivi compatibili con Android devono essere compatibili con:

    • Android Debug Bridge (noto come ADB) [ Risorse, 19 ]
      Le implementazioni del dispositivo devono supportare tutte le funzioni adb come documentate nell'SDK Android. Il demone adb lato dispositivo dovrebbe essere inattivo per impostazione predefinita, ma ci deve essere un meccanismo accessibile dall'utente per accendere il ponte di debug Android.
    • Dalvik Debug Monitor Service (noto come DDMS) [ Risorse, 19 ]
      Le implementazioni del dispositivo devono supportare tutte le funzionalità ddms come documentato nell'SDK Android. Poiché ddms utilizza adb , il supporto per ddms dovrebbe essere inattivo per impostazione predefinita, ma deve essere supportato ogni volta che l'utente ha attivato il ponte di debug Android, come sopra.
    • Monkey [ Risorse, 22 ]
      Le implementazioni del dispositivo devono includere il framework delle scimmie e renderlo disponibile per le applicazioni da utilizzare.

    8. Compatibilità hardware

    Android ha lo scopo di supportare gli implementatori di dispositivi che creano fattori e configurazioni innovativi in ​​forma. Allo stesso tempo, gli sviluppatori Android si aspettano determinati hardware, sensori e API su tutto il dispositivo Android. Questa sezione elenca le funzionalità hardware che tutti i dispositivi compatibili Android 2.1 devono supportare.

    Se un dispositivo include un particolare componente hardware che ha un'API corrispondente per gli sviluppatori di terze parti, l'implementazione del dispositivo deve implementare tale API come definita nella documentazione SDK Android. Se un'API nell'SDK interagisce con un componente hardware che si afferma opzionale e l'implementazione del dispositivo non possiede quel componente: le

    • definizioni di classe per le API del componente devono essere presenti,
    • i comportamenti dell'API devono essere implementati come non-op in un modo ragionevole
    • I metodi API devono restituire i valori null ove consentiti dai
    • metodi API della documentazione SDK devono restituire implementazioni no-op di classi in cui i valori null non sono consentiti dalla documentazione SDK
      • un esempio

    tipico di uno scenario in cui si applicano questi requisiti è l'API di telefonia: anche su non -Dispositivi per telefoni, queste API devono essere implementate come no-op ragionevoli.

    Le implementazioni del dispositivo devono segnalare accurate informazioni di configurazione hardware accurate tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) sulla classe android.content.pm.PackageManager .

    8.1. Display

    Android 2.1 include strutture che eseguono determinate operazioni di ridimensionamento e trasformazione automatiche in alcune circostanze, per garantire che le applicazioni di terze parti funzionino ragionevolmente bene su una varietà di configurazioni hardware [ risorse, 23 ]. I dispositivi devono implementare correttamente questi comportamenti, come dettagliato in questa sezione.

    Per Android 2.1, queste sono le configurazioni di visualizzazione più comuni:

    larghezza Normale basso di basso 480 480 480 - 5,5 High
    del tipo di schermo (pixel) altezza (pixel) intervallo di lunghezza diagonale (pollici) Dimensioni schermo Gruppo di densità dello schermo
    QVGA 240 320 220 - 3.0 Piccola
    WQVGA 240 400 3.2 - 3,5basso normale
    FWQVGA 240 432 3.5 - 3.8
    HVGA acontenuto320 480 320 - 3.5
    WVGA 480 800 3,3 - 4.0 FWVGA NORMAL HIGH
    480 854 3.5 - 4.0 WVGA HighNormale
    Medium FWVGA 480 854 554 -
    5.8 Implementazioni di dispositivi grandi grandi di grandi

    dimensioni corrispondente a una delle configurazioni standard sopra deve essere configurata per segnalare la dimensione dello schermo indicata alle applicazioni tramite android.content.res.Configuration [ Risorse, 24 ] classe.

    Alcuni pacchetti. APK hanno manifesti che non li identificano come supportando un intervallo di densità specifico. Quando si eseguono tali applicazioni, si applicano i seguenti vincoli:

    • le implementazioni del dispositivo devono interpretare le risorse in un .APK che non ha una qualificatore di densità come inadempiente al "mezzo" (noto come "MDPI" nella documentazione SDK.)
    • Quando si opera su una densità "bassa" Schermo, le implementazioni del dispositivo devono ridimensionare le risorse medi/MDPI di un fattore di 0,75.
    • Quando si opera su una schermata di densità "alta", le implementazioni del dispositivo devono aumentare le risorse medi/MDPI di un fattore di 1,5.
    • Le implementazioni del dispositivo non devono ridimensionare le risorse all'interno di un intervallo di densità e devono ridimensionare le attività esattamente di questi fattori tra gamme di densità.

    8.1.2. Configurazioni di visualizzazione non standard

    Configurazioni di visualizzazione che non corrispondono a una delle configurazioni standard elencate nella Sezione 8.1.1 richiedono una considerazione aggiuntiva e il lavoro sia compatibile. Gli implementatori di dispositivi devono contattare il team di compatibilità Android come previsto nella Sezione 12 per ottenere classificazioni per secchio, densità e fattore di ridimensionamento delle dimensioni dello schermo. Se forniti con queste informazioni, le implementazioni del dispositivo devono implementarle come specificato.

    Si noti che alcune configurazioni di visualizzazione (come schermi molto grandi o molto piccoli e alcuni rapporti di aspetto) sono fondamentalmente incompatibili con Android 2.1; Pertanto gli implementatori di dispositivi sono incoraggiati a contattare il team di compatibilità Android il più presto possibile nel processo di sviluppo.

    8.1.3.

    Le implementazioni del dispositivo

    di visualizzazione delle metriche

    devono segnalare i valori corretti per tutte le metriche di visualizzazione definite in android.util.DisplayMetrics [ Risorse, 25 ].

    8.2.

    Implementazioni del dispositivo

    per tastiera

    :

    • devono includere il supporto per il framework di gestione delle input (che consente agli sviluppatori di terze parti di creare motori di gestione input - cioè tastiera soft) come dettagliato su sviluppatore.android.com
    • deve fornire almeno un'implementazione di tastiera soft (indipendentemente dal fatto che a La tastiera dura è presente)
    • può includere ulteriori implementazioni di tastiera morbida
    • che possono includere una tastiera hardware
    • non deve includere una tastiera hardware che non corrisponde a uno dei formati specificati in android.content.res.Configuration.keyboard [ Risorse, 24 ] (cioè, ovvero Qwerty o 12-key)

    8.3.

    Implementazioni del dispositivo

    di navigazione non touch

    :

    • possono omettere le opzioni di navigazione non touch (ovvero può omettere una trackball, un D-pad o una ruota)
    • deve segnalare il valore corretto per android.content.res.Configuration.navigation [ Risorse, 24 ]

    8.4.

    I dispositivi compatibili

    dell'orientamento dello schermo

    devono supportare l'orientamento dinamico mediante applicazioni per l'orientamento dello schermo del ritratto o del paesaggio. Cioè, il dispositivo deve rispettare la richiesta dell'applicazione per un specifico orientamento allo schermo. Le implementazioni del dispositivo possono selezionare l'orientamento del ritratto o del paesaggio come predefinito.

    I dispositivi devono segnalare il valore corretto per l'orientamento corrente del dispositivo, ogni volta che interrogati tramite Android.Content.res.configuration.orientation, android.view.display.getorientation () o altre API.

    8.5.

    Implementazioni del dispositivo

    di input touchscreen

    :

    • deve avere un touchscreen
    • che può avere touchscreen capacativo o resistivo
    • deve segnalare il valore di android.content.res.Configuration [ Risorse, 24 ] che riflettono corrispondente al tipo di touchscreen specifico sul dispositivo
      • 8.6

    .

    Implementazioni del dispositivo

    USB

      :
    • deve implementare un client USB, collegato a un host USB con una porta USB-A standard
    • deve implementare il ponte di debug Android su USB (come descritto nella Sezione 7)
    • deve implementare le specifiche di archiviazione di massa USB, per consentire un host connesso al dispositivo per accedere al contenuto del volume /SDCard
    • dovrebbe utilizzare il fattore di forma micro USB sul lato del dispositivo
    • può includere una porta non standard sul lato del dispositivo, ma in tal caso deve essere spedito con un cavo in grado di collegare il pinout personalizzato a Porta USB-A standard

    8.7. Le chiavi di navigazione

    nelle funzioni di casa, menu e arretramento sono essenziali per il paradigma di navigazione Android. Le implementazioni del dispositivo devono rendere queste funzioni disponibili per l'utente in ogni momento, indipendentemente dallo stato dell'applicazione. Queste funzioni dovrebbero essere implementate tramite pulsanti dedicati. Possono essere implementati utilizzando software, gesti, pannelli touch, ecc., Ma in tal caso devono essere sempre accessibili e non oscuri o interferire con l'area di visualizzazione dell'applicazione disponibile.

    Gli implementari del dispositivo dovrebbero anche fornire una chiave di ricerca dedicata. Gli implementari del dispositivo possono anche fornire chiavi di invio e fine per le telefonate.

    8.8.

    Le implementazioni del dispositivo

    di reti dati wireless

    devono includere il supporto per la rete di dati ad alta velocità wireless. In particolare, le implementazioni del dispositivo devono includere il supporto per almeno uno standard di dati wireless in grado di 200 kbit/sec o superiore. Esempi di tecnologie che soddisfano questo requisito includono Edge, HSPA, EV-DO, 802.11g, ecc.

    Se un'implementazione del dispositivo include una particolare modalità per la quale l'SDK Android include un'API (cioè WiFi, GSM o CDMA), il L'implementazione deve supportare l'API.

    I dispositivi possono implementare più di una forma di connettività dati wireless. I dispositivi possono implementare la connettività dei dati cablati (come Ethernet), ma devono comunque includere almeno una forma di connettività wireless, come sopra.

    8.9.

    Le implementazioni del dispositivo

    della fotocamera

    devono includere una fotocamera. La fotocamera inclusa:

    • deve avere una risoluzione di almeno 2 megapixel
    • dovrebbe avere un focus automatico hardware o il software automatico implementato nel driver della fotocamera (trasparente al software applicativo)
    • può avere focus fisse o EDOF (profondità di campo estesa) L'hardware
    • può includere un flash. Se la fotocamera include un flash, la lampada flash non deve essere illuminata mentre un'istanza Android.hardware.camera.previewCallback è stata registrata su una superficie di anteprima della fotocamera, a meno che l'applicazione non abbia esplicitamente abilitato il flash abilitando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON Oggetto Camera.Parameters Parameters. Si noti che questo vincolo non si applica all'applicazione della fotocamera di sistema integrata del dispositivo, ma solo alle applicazioni di terze parti utilizzando Camera.PreviewCallback .

    Le implementazioni del dispositivo devono implementare i seguenti comportamenti per le API relative alla fotocamera:

    1. se un'applicazione non ha mai chiamato Android.hardware.camera.parameters.setPreviewFormat (INT), il dispositivo deve utilizzare Android.hardware.pixelFormat.ycbcr_420_sp per anteprima forniti per callback dell'applicazione.
    2. Se un'applicazione registra un Android.hardware.camera.previewCallback e il sistema chiama il metodo OnPreviewFrame () quando il formato di anteprima è YCBCR_420_SP, i dati nel byte [] passati in supreviewFrame () devono essere ulteriormente nel formato di codifica NV21. (Questo è il formato usato in modo nativo dalla famiglia hardware 7K.) Cioè, NV21 deve essere il valore predefinito.

    Le implementazioni del dispositivo devono implementare l'API della fotocamera completa inclusa nella documentazione SDK Android 2.1 [ Risorse, 26 ]), indipendentemente dal fatto che il dispositivo includa autofocus hardware o altre funzionalità. Ad esempio, le telecamere prive di autofocus devono comunque chiamare qualsiasi android.hardware.Camera.AutoFocusCallback istanze (anche se ciò non ha rilevanza per una fotocamera non autofocus.) Le

    implementazioni del dispositivo devono riconoscere e onorare ogni nome di parametro definito come una costante sul costante sulla costante su android.hardware.Camera.Parameters Classe, se l'hardware sottostante supporta la funzione. Se l'hardware del dispositivo non supporta una funzione, l'API deve comportarsi come documentata. Al contrario, le implementazioni del dispositivo non devono onorare o riconoscere le costanti di stringa passate al metodo android.hardware.Camera.setParameters() diverso da quelli documentati come costanti su android.hardware.Camera.Parameters , a meno che le costanti non siano prefissate con una stringa che indica il Nome dell'implementatore del dispositivo. Cioè, le implementazioni del dispositivo devono supportare tutti i parametri della fotocamera standard se l'hardware consente e non devono supportare i tipi di parametri della fotocamera personalizzati a meno che i nomi dei parametri non siano chiaramente indicati tramite un prefisso di stringa in modo non standard.

    8.10.

    Le implementazioni del dispositivo

    accelerometro

    devono includere un accelerometro a 3 assi e devono essere in grado di consegnare eventi a 50 Hz o superiore. Il sistema di coordinate utilizzato dall'accelerometro deve rispettare il sistema di coordinate del sensore Android, come dettagliato nelle API Android (vedi [ Risorse, 27 ]).

    8.11.

    Le implementazioni del dispositivo

    della bussola

    devono includere una bussola a 3 assi e devono essere in grado di consegnare eventi 10 Hz o superiore. Il sistema di coordinate utilizzato dalla bussola deve rispettare il sistema di coordinate del sensore Android come definito nell'API Android (vedi [ Risorse, 27 ]).

    8.12.

    Le implementazioni del dispositivo

    GPS

    devono includere un GPS e dovrebbero includere una qualche forma di tecnica "GPS assistita" per ridurre al minimo il tempo di blocco GPS.

    8.13. Telefonia

    Android 2.1 può essere utilizzata su dispositivi che non includono hardware di telefonia. Cioè, Android 2.1 è compatibile con dispositivi che non sono telefoni. Tuttavia, se un'implementazione di un dispositivo include la telefonia GSM o CDMA, deve implementare il supporto completo per l'API per quella tecnologia. Le implementazioni del dispositivo che non includono hardware di telefonia devono implementare le API complete come no-op.

    Vedi anche Sezione 8.8, Wireless Data Networking.

    8.14.

    Le implementazioni

    di memoria e

    dispositivo di archiviazione devono avere almeno 92 MB di memoria disponibili per il kernel e lo spazio utenti. I 92 MB devono essere in aggiunta a qualsiasi memoria dedicata ai componenti hardware come radio, memoria e così via che non è sotto il controllo del kernel.

    Le implementazioni del dispositivo devono avere almeno 150 MB di memoria non volatile disponibile per i dati dell'utente. Cioè, la partizione /data deve essere di almeno 150 MB.

    Nota: questa sezione è stata modificata da Erratum EX6580.

    8.15.

    Le implementazioni dei dispositivi

    di archiviazione condivisa dell'applicazione

    devono offrire archiviazione condivisa per le applicazioni. L'archiviazione condivisa fornita deve avere dimensioni di almeno 2 GB.

    Le implementazioni del dispositivo devono essere configurate con archiviazione condivisa montata per impostazione predefinita, "Out of the Box". Se l'archiviazione condivisa non è montata sul percorso /sdcard Linux, il dispositivo deve includere un collegamento simbolico Linux da /sdcard al punto di montaggio effettivo.

    Le implementazioni del dispositivo devono applicare come documentata l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE in questo archivio condiviso. L'archiviazione condivisa deve altrimenti essere scrivibile da qualsiasi applicazione che ottenga tale autorizzazione.

    Le implementazioni del dispositivo possono avere hardware per l'archiviazione rimovibile accessibile dall'utente, come una scheda digitale sicura. In alternativa, le implementazioni del dispositivo possono allocare l'archiviazione interna (non rimovibile) come archiviazione condivisa per le app.

    Indipendentemente dalla forma di archiviazione condivisa utilizzata, l'archiviazione condivisa deve implementare l'archiviazione di massa USB, come descritto nella Sezione 8.6. Come spedito fuori dalla scatola, l'archiviazione condivisa deve essere montato con il filesystem Fat.

    È illustrativo considerare due esempi comuni. Se un'implementazione di un dispositivo include uno slot per schede SD per soddisfare il requisito di archiviazione condiviso, una scheda SD in formato grasso di 2 GB di dimensioni o più grandi deve essere inclusa con il dispositivo venduto agli utenti e deve essere montata per impostazione predefinita. In alternativa, se un'implementazione del dispositivo utilizza un'archiviazione fissa interna per soddisfare questo requisito, che l'archiviazione deve essere di dimensioni di 2 GB o più grande e montata su /sdcard (o /sdcard deve essere un collegamento simbolico alla posizione fisica se è montata altrove.) Nota altrove.)

    Nota : Questa sezione è stata aggiunta da Erratum EX6580.

    8.16.

    Le implementazioni del dispositivo

    Bluetooth

    devono includere un ricetrasmettitore Bluetooth. Le implementazioni del dispositivo devono abilitare l'API Bluetooth basata su RFCOMM come descritto nella documentazione SDK [ Risorse, 29 ]. Le implementazioni del dispositivo dovrebbero implementare profili Bluetooth pertinenti, come A2DP, AVRCP, OBEX, ecc. A seconda del dispositivo.

    Nota: questa sezione è stata aggiunta da Erratum EX6580.

    9. Compatibilità alle prestazioni

    Uno degli obiettivi del programma di compatibilità Android è quello di consentire un'esperienza di applicazione coerente ai consumatori. Le implementazioni compatibili devono garantire non solo le applicazioni semplicemente eseguite correttamente sul dispositivo, ma che lo fanno con prestazioni ragionevoli e una buona esperienza utente nel complesso. Le implementazioni del dispositivo devono soddisfare le metriche delle prestazioni chiave di un dispositivo compatibile con Android 2.1 definito nella tabella seguente:

    Tempo di lancio dei
    commenti soglia delle prestazioni metriche
    Le seguenti applicazioni dovrebbero essere avviate entro il tempo specificato.
    • Browser: meno di 1300 ms
    • mms/SMS: meno di 700 ms
    • AlarmClock: meno di 650 ms
    		 il tempo di lancio viene misurato come tempo totale per completare il caricamento dell'attività predefinita per l'applicazione, incluso il tempo impiegato per avviare il processo Linux, caricare l'android Pacchetto nella VM Dalvik e chiama OnCreate.
    Le applicazioni simultanee quando sono state lanciate più applicazioni, rilanciando un'applicazione già running dopo che è stata lanciata, deve richiedere meno del tempo di lancio originale.  

    10. Le implementazioni del dispositivo di compatibilità del modello di sicurezza

    devono implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android come definito nel documento di riferimento di sicurezza e autorizzazioni nelle API [ Risorse, 28 ] nella documentazione di Sviluppatore Android. Le implementazioni del dispositivo devono supportare l'installazione di applicazioni autofirmate senza richiedere autorizzazioni/certificati aggiuntivi da terzi/autorità. In particolare, i dispositivi compatibili devono supportare i meccanismi di sicurezza descritti nelle sottosezioni seguenti.

    10.1.

    Le implementazioni dei dispositivi

    per autorizzazioni

    devono supportare il modello di autorizzazioni Android come definito nella documentazione dello sviluppatore Android [ risorse, 28 ]. In particolare, le implementazioni devono applicare ciascuna autorizzazione definita come descritto nella documentazione SDK; Nessuna autorizzazione può essere omessa, modificata o ignorata. Le implementazioni possono aggiungere ulteriori autorizzazioni, a condizione che le nuove stringhe ID autorizzazione non si trovino nello spazio dei nomi Android.

    10.2.

    Le implementazioni di dispositivi di

    isolamento UID e di processo

    devono supportare il modello Sandbox dell'applicazione Android, in cui ogni applicazione viene eseguita come un unico UID in stile UNIX e in un processo separato.

    Le implementazioni del dispositivo devono supportare l'esecuzione di più applicazioni come lo stesso ID utente Linux, a condizione che le applicazioni siano adeguatamente firmate e costruite, come definite nel riferimento di sicurezza e autorizzazioni [ risorse, 28 ].

    10.3.

    Le autorizzazioni del dispositivo

    per autorizzazioni del filesystem

    devono supportare il modello di autorizzazioni di accesso ai file Android come definito in come definito nel riferimento di sicurezza e autorizzazioni [ risorse, 28 ].

    11.

    Le implementazioni del dispositivo sui test di test di compatibilità devono passare la suite di test di compatibilità Android (CTS) [ Risorse, 2 ] disponibili dal progetto Open Source Android, utilizzando il software di spedizione finale sul dispositivo. Inoltre, gli implementatori di dispositivi dovrebbero utilizzare l'implementazione di riferimento nell'albero open source Android il più possibile e devono garantire la compatibilità in caso di ambiguità nei CT e per eventuali reimplementazioni delle parti del codice sorgente di riferimento.

    Il CTS è progettato per essere eseguito su un dispositivo reale. Come ogni software, il CTS può contenere di sé bug. Il CTS sarà versione indipendentemente da questa definizione di compatibilità e possono essere rilasciate molteplici revisioni del CTS per Android 2.1. Le implementazioni del dispositivo devono passare l'ultima versione CTS disponibile al momento del completamento del software del dispositivo.

    12. Le implementazioni del dispositivo del software aggiornabili

    devono includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire aggiornamenti "live", ovvero un riavvio del dispositivo.

    Qualsiasi metodo può essere utilizzato, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, uno qualsiasi dei seguenti approcci soddisferà questo requisito:

    • download over-the-air (OTA) con aggiornamento offline tramite riavvio
    • aggiornamenti "legati" tramite USB da un PC host
    • "Offline" aggiornamenti tramite un riavvio e aggiornamento da un file in onda in onda Archiviazione rimovibile

    Il meccanismo di aggiornamento utilizzato deve supportare gli aggiornamenti senza cancellare i dati dell'utente. Si noti che il software Android a monte include un meccanismo di aggiornamento che soddisfa questo requisito.

    Se si trova un errore in un'implementazione del dispositivo dopo che è stato rilasciato, ma all'interno della sua ragionevole durata del prodotto che viene determinato in consultazione con il team di compatibilità Android per influire sulla compatibilità delle applicazioni THID-Party, l'implementatore del dispositivo deve correggere l'errore tramite un software Aggiornamento disponibile che può essere applicato per il meccanismo appena descritto.

    13. Contattaci

    È possibile contattare gli autori di documenti all'indirizzo compatibilità@android.com per chiarimenti e per far emergere eventuali problemi che ritieni che il documento non copra.