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.2. Una "implementazione del dispositivo" o "implementazione" è la soluzione hardware/software così sviluppata.

Per essere considerato compatibile con Android 2.2, 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/docs/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 delle versioni consentite per Android 2.2: http://source.android.com/docs/compatibility/2.2/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/multipage/

Specifiche della Dalvik Virtual Machine: disponibili nel codice sorgente Android, su dalvik/docs

AppWidget: 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 ricerche: 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

Documentazione dello strumento di riferimento (per adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html

Descrizione del file apk di 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/monkey

Elenco delle funzionalità hardware Android: http://developer.android.com/reference/android/content/pm/PackageManager.html

Supporto di 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 alla sicurezza e alle autorizzazioni Android: http://developer.android.com/guide/topics/security/security.html

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

Molte di queste risorse derivano direttamente o indirettamente dall'SDK di Android 2.2 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 gestita

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.2 [ 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 in fase di runtime, sotto forma di intenti, autorizzazioni e aspetti simili delle applicazioni Android che non possono essere applicati in fase di compilazione dell'applicazione. Questa sezione descrive in dettaglio le API "soft" e i comportamenti del sistema richiesti per la compatibilità con Android 2.2. 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. Costruisci parametri

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.2, questo campo DEVE avere il valore intero 8.
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 rese disponibili 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, dell'organizzazione, dell'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.2/ERC77/3359:userdebug/test-keys` L'impronta digitale NON DEVE includere caratteri di spazi bianchi. Se altri campi inclusi nel modello precedente contengono caratteri di spazio bianco, DEVONO essere sostituiti nell'impronta digitale creata con un altro carattere, ad esempio il carattere di sottolineatura ("_").
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 che specifica 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 un ID utente dell'utente (o dell'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 intenti

Android utilizza gli intenti 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
Navigatore
Calendario
Calcolatrice
Telecamera
Contatti
E-mail
Galleria
Ricerca globale
Lanciatore
LivePicker (ovvero, l'applicazione di selezione degli sfondi animati; PUÒ essere omessa se il dispositivo non supporta gli sfondi animati, secondo la Sezione 3.8.5.)
Messaggistica (aka "Mms")
Musica
Telefono
Impostazioni
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. Override dell'intento

Poiché Android è una piattaforma estensibile, gli implementatori del dispositivo DEVONO consentire che ogni modello di intento a cui si fa riferimento nella Sezione 3.2.3.1 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.

3.2.3.3. Spazi dei nomi di intenti

Gli implementatori del dispositivo 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 di 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 i cambiamenti 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à 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. Allo stesso modo, un'esperienza web completa è fondamentale per l'esperienza utente Android. Le implementazioni del dispositivo DEVONO includere una versione di android.webkit.WebView coerente con il software Android originale e DEVONO includere un browser moderno compatibile con HTML5, come descritto di seguito.

3.4.1. Compatibilità WebView

L'implementazione Android Open Source utilizza il motore di rendering WebKit per implementare android.webkit.WebView . Poiché non è possibile sviluppare una suite di test completa per un sistema di rendering web, gli implementatori del dispositivo DEVONO utilizzare la specifica build upstream di WebKit nell'implementazione WebView. Nello specifico:

Le implementazioni android.webkit.WebView delle implementazioni del dispositivo DEVONO essere basate sulla build WebKit 533.1 dall'albero Android Open Source upstream per Android 2.2. Questa build include un insieme specifico di funzionalità e correzioni di sicurezza per WebView. Gli implementatori del dispositivo POSSONO includere personalizzazioni nell'implementazione WebKit; tuttavia, tali personalizzazioni NON DEVONO alterare il comportamento di WebView, incluso il comportamento di rendering.
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/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
- Il valore della 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

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> . Le API HTML5, come tutte le API JavaScript, DEVONO essere disabilitate per impostazione predefinita in una WebView, a meno che lo sviluppatore non le abiliti esplicitamente tramite le consuete API Android.

3.4.2. Compatibilità del browser

Le implementazioni del dispositivo DEVONO includere un'applicazione browser autonoma per la navigazione web degli utenti generici. Il browser autonomo PUÒ essere basato su una tecnologia browser diversa da WebKit. Tuttavia, anche se viene fornita un'applicazione browser alternativa, il componente android.webkit.WebView fornito alle applicazioni di terze parti DEVE essere basato su WebKit, come descritto nella Sezione 3.4.1.

Le implementazioni POSSONO fornire una stringa dell'agente utente personalizzata nell'applicazione browser autonoma.

L'applicazione browser autonoma (basata sull'applicazione WebKit Browser upstream o su una sostituzione di terze parti) DOVREBBE includere il supporto per la maggior parte possibile di HTML5 [ Risorse, 9 ]. Come minimo, le implementazioni del dispositivo DEVONO supportare la geolocalizzazione HTML5, la cache dell'applicazione, le API del database e il tag <video> nell'applicazione browser autonoma.

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 un particolare permesso

L'elenco precedente non è completo e spetta agli implementatori dei dispositivi 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 dello spazio 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 (vedi sotto) a questi spazi dei nomi dei pacchetti:

Giava.*
javax.*
sole.*
androide.*
com.android.*

Le modifiche vietate includono:

Le implementazioni del dispositivo NON DEVONO 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 Dalvik Virtual Machine [ Risorse, 10 ].

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

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 e il ciclo di vita corrispondenti che consentono 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.

3.8.3. Ricerca

Android include API [ Risorse, 15 ] che consentono agli sviluppatori di incorporare la ricerca nelle loro applicazioni ed esporre i dati della loro 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. Sfondi animati

Android definisce un tipo di componente, l'API e il ciclo di vita corrispondenti che consentono alle applicazioni di esporre uno o più "Sfondi animati" 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)
Lander lunare (incluso nell'SDK)
Le applicazioni "App per Android" [ Risorse, 18 ].
Replica Island (disponibile in Android Market; richiesta solo per le implementazioni di dispositivi che supportano OpenGL ES 2.0)

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)
ManualSmokeTest (incluso nel CTS)

Ciascun caso di test nelle applicazioni di cui sopra DEVE essere eseguito correttamente sull'implementazione del dispositivo.

5. Compatibilità dell'imballaggio dell'applicazione

Le implementazioni del dispositivo DEVONO installare ed eseguire file ".apk" Android generati dallo strumento "aapt" incluso nell'SDK Android ufficiale [ 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 dei dispositivi DEVONO implementare completamente tutte le API multimediali. Le implementazioni del dispositivo DEVONO includere il supporto per tutti i codec multimediali descritti di seguito e DOVREBBERO soddisfare le linee guida per l'elaborazione del suono descritte di seguito.

6.1. Codec multimediali

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.

Audio
	Nome	Codificatore	Decodificatore	Dettagli	Formato file/contenitore
	AACLC/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à campionate da 6,60 kbit/s a 23,85 kbit/s a 16kHz	3GPP (.3gp)
	MP3		X	Mono/stereo 8-320 Kbps costante (CBR) o bit rate variabile (VBR)	MP3 (.mp3)
	MIDI		X	Tipo MIDI 0 e 1. Versione DLS 1 e 2. XMF e Mobile XMF. Supporto per i formati suoneria RTTTL/RTX, OTA e iMelody	Digitare 0 e 1 (.mid, .xmf, .mxmf). Anche RTTTL/RTX (.rtttl, .rtx), OTA (.ota) e iMelody (.imy)
	Ogg Vorbis		X		Ogg (.ogg)
	PCM		X	PCM lineare a 8 e 16 bit (velocità fino al limite dell'hardware)	ONDA (.wav)
Immagine
	JPEG	X	X	base+progressivo
	GIF		X
	PNG	X	X
	BMP		X
video
	H.263	X	X		File 3GPP (.3gp).
	H.264		X		File 3GPP (.3gp) e MPEG-4 (.mp4).
	Profilo semplice MPEG4		X		File 3GPP (.3gp).

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

6.2. Registrazione audio

Quando un'applicazione ha utilizzato l'API android.media.AudioRecord per avviare la registrazione di un flusso audio, le implementazioni del dispositivo DOVREBBERO campionare e registrare l'audio con ciascuno di questi comportamenti:

L'elaborazione della riduzione del rumore, se presente, DOVREBBE essere disabilitata.
Il controllo automatico del guadagno, se presente, DOVREBBE essere disabilitato.
Il dispositivo DOVREBBE presentare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte; nello specifico, ±3 dB, da 100 Hz a 4000 Hz
La sensibilità dell'ingresso audio DOVREBBE essere impostata in modo tale che una sorgente con livello di potenza sonora (SPL) di 90 dB a 1000 Hz produca RMS di 5000 per campioni a 16 bit.
I livelli di ampiezza PCM DOVREBBERO tracciare linearmente le variazioni SPL in ingresso su un intervallo di almeno 30 dB da -18 dB a +12 dB rispetto a 90 dB SPL al microfono.
La distorsione armonica totale DOVREBBE essere inferiore all'1% da 100 Hz a 4000 Hz con un livello di ingresso di 90 dB SPL.

Nota: mentre i requisiti sopra delineati sono indicati come "DOVREBBERO" per Android 2.2, la definizione di compatibilità per una versione futura prevede di cambiarli in "MUST". Cioè, questi requisiti sono facoltativi in Android 2.2 ma saranno richiesti da una versione futura. I dispositivi esistenti e nuovi che eseguono Android 2.2 Android sono fortemente incoraggiati a soddisfare questi requisiti in Android 2.2 , altrimenti non saranno in grado di ottenere la compatibilità con Android una volta aggiornati alla versione futura.

6.3. Latenza audio

La latenza audio è definita in generale come l'intervallo tra il momento in cui un'applicazione richiede un'operazione di riproduzione o registrazione audio e il momento in cui l'implementazione del dispositivo inizia effettivamente l'operazione. Molte classi di applicazioni si basano su latenze brevi, per ottenere effetti in tempo reale come effetti sonori o comunicazioni VOIP. Le implementazioni del dispositivo DOVREBBERO soddisfare tutti i requisiti di latenza audio delineati in questa sezione.

Ai fini di questa sezione:

Per "latenza di output a freddo" si intende l'intervallo tra il momento in cui un'applicazione richiede la riproduzione audio e il momento in cui inizia la riproduzione del suono, quando il sistema audio è stato inattivo e spento prima della richiesta
Per "latenza di output caldo" si intende l'intervallo tra il momento in cui un'applicazione richiede la riproduzione audio e il momento in cui inizia la riproduzione del suono, quando il sistema audio è stato utilizzato di recente ma è attualmente inattivo (ovvero silenzioso)
Per "latenza di output continua" si intende l'intervallo tra il momento in cui un'applicazione emette un campione da riprodurre e il momento in cui l'altoparlante riproduce fisicamente il suono corrispondente, mentre il dispositivo sta attualmente riproducendo l'audio
Per "latenza di input freddo" si intende l'intervallo tra il momento in cui un'applicazione richiede la registrazione audio e il momento in cui il primo campione viene consegnato all'applicazione tramite la sua richiamata, quando il sistema audio e il microfono sono rimasti inattivi e spenti prima della richiesta
Per "latenza di input continua" si intende quando si verifica un suono ambientale e quando il campione corrispondente a quel suono viene inviato a un'applicazione di registrazione tramite la sua richiamata, mentre il dispositivo è in modalità di registrazione

Utilizzando le definizioni di cui sopra, le implementazioni del dispositivo DOVREBBERO mostrare ciascuna di queste proprietà:

latenza di uscita fredda di 100 millisecondi o meno
latenza di uscita calda di 10 millisecondi o meno
latenza di output continua di 45 millisecondi o meno
latenza di input a freddo pari o inferiore a 100 millisecondi
latenza di input continua di 50 millisecondi o meno

7. Compatibilità dello strumento di sviluppo

Le implementazioni del dispositivo DEVONO supportare gli strumenti per sviluppatori Android forniti nell'SDK Android. Nello specifico, 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 documentato nell'SDK di Android. Il demone adb lato dispositivo DOVREBBE essere inattivo per impostazione predefinita, ma DEVE esserci un meccanismo accessibile all'utente per attivare Android Debug Bridge.
Dalvik Debug Monitor Service (noto come ddms) [ Risorse, 19 ]
Le implementazioni del dispositivo DEVONO supportare tutte le funzionalità ddms come documentato nell'SDK di 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 Android Debug Bridge, come sopra.
Scimmia [ Risorse, 22 ]
Le implementazioni del dispositivo DEVONO includere il framework Monkey e renderlo disponibile per l'utilizzo da parte delle applicazioni.

8. Compatibilità hardware

Android è destinato a supportare gli implementatori di dispositivi che creano fattori di forma e configurazioni innovativi. Allo stesso tempo, gli sviluppatori Android si aspettano determinati hardware, sensori e API su tutti i dispositivi Android. Questa sezione elenca le funzionalità hardware che tutti i dispositivi compatibili con Android 2.2 devono supportare.

Se un dispositivo include un particolare componente hardware che dispone di un'API corrispondente per sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare tale API come definito nella documentazione dell'SDK Android. Se un'API nell'SDK interagisce con un componente hardware dichiarato facoltativo e l'implementazione del dispositivo non possiede tale componente:

le definizioni delle classi per le API del componente DEVONO essere presenti
i comportamenti dell'API DEVONO essere implementati come no-op in modo ragionevole
I metodi API DEVONO restituire valori nulli ove consentito dalla documentazione dell'SDK
I metodi API DEVONO restituire implementazioni no-op di classi in cui i valori null non sono consentiti dalla documentazione dell'SDK

Un tipico esempio di scenario in cui si applicano questi requisiti è l'API di telefonia: anche su dispositivi non telefonici, queste API devono essere implementate come no-op ragionevoli.

Le implementazioni del dispositivo DEVONO riportare accuratamente informazioni precise sulla configurazione hardware tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) sulla classe android.content.pm.PackageManager . [ Risorse, 23 ]

8.1. Schermo

Android 2.2 include funzionalità 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, 24 ]. I dispositivi DEVONO implementare correttamente questi comportamenti, come dettagliato in questa sezione.

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

Tipo di schermo	Larghezza (pixel)	Altezza (pixel)	Intervallo di lunghezza diagonale (pollici)	Gruppo dimensioni schermo	Gruppo densità schermo
QVGA	240	320	2.6 - 3.0	Piccolo	Basso
WQVGA	240	400	3.2 - 3.5	Normale	Basso
FWQVGA	240	432	3.5 - 3.8	Normale	Basso
HVGA	320	480	3.0 - 3.5	Normale	medio
WVGA	480	800	3.3 - 4.0	Normale	Alto
FWVGA	480	854	3,5 - 4,0	Normale	Alto
WVGA	480	800	4.8 - 5.5	Grande	medio
FWVGA	480	854	5.0 - 5.8	Grande	medio

Le implementazioni del dispositivo corrispondenti a una delle configurazioni standard di cui sopra DEVONO essere configurate per segnalare la dimensione dello schermo indicata alle applicazioni tramite la classe android.content.res.Configuration [ Resources, 24 ].

Alcuni pacchetti .apk hanno manifest che non li identificano come supportati da 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 file .apk prive di un qualificatore di densità come predefinite su "medio" (noto come "mdpi" nella documentazione dell'SDK).
Quando si opera su uno schermo a densità "bassa", le implementazioni del dispositivo DEVONO ridimensionare le risorse medie/mdpi di un fattore pari a 0,75.
Quando si opera su uno schermo ad "alta" densità, le implementazioni del dispositivo DEVONO aumentare le risorse medie/mdpi di un fattore pari a 1,5.
Le implementazioni dei dispositivi NON DEVONO ridimensionare le risorse all'interno di un intervallo di densità e DEVONO ridimensionare le risorse esattamente in base a questi fattori tra gli intervalli di densità.

8.1.2. Configurazioni di visualizzazione non standard

Le configurazioni di visualizzazione che non corrispondono a una delle configurazioni standard elencate nella Sezione 8.1.1 richiedono ulteriore considerazione e lavoro per essere compatibili. Gli implementatori del dispositivo DEVONO contattare il team di compatibilità Android come descritto nella sezione 13 per ottenere classificazioni per dimensioni dello schermo, densità e fattore di scala. Quando vengono fornite queste informazioni, le implementazioni del dispositivo DEVONO implementarle come specificato.

Tieni presente che alcune configurazioni di visualizzazione (come schermi molto grandi o molto piccoli e alcune proporzioni) sono fondamentalmente incompatibili con Android 2.2; pertanto gli implementatori dei dispositivi sono incoraggiati a contattare il team di compatibilità Android il prima possibile nel processo di sviluppo.

8.1.3. Visualizza metriche

Le implementazioni del dispositivo DEVONO riportare i valori corretti per tutte le metriche di visualizzazione definite in android.util.DisplayMetrics [ Risorse, 26 ].

8.1.4. Supporto schermo dichiarato

Le applicazioni possono indicare quali dimensioni dello schermo supportano tramite l'attributo <supports-screens> nel file AndroidManifest.xml. Le implementazioni dei dispositivi DEVONO rispettare correttamente il supporto dichiarato delle applicazioni per schermi piccoli, medi e grandi, come descritto nella documentazione dell'SDK Android.

8.2. Tastiera

Implementazioni del dispositivo:

DEVE includere il supporto per Input Management Framework (che consente agli sviluppatori di terze parti di creare motori di gestione dell'input, ad esempio tastiera virtuale) come dettagliato su Developer.android.com
DEVE fornire almeno un'implementazione della tastiera virtuale (indipendentemente dal fatto che sia presente una tastiera fisica)
PUÒ includere implementazioni aggiuntive della tastiera virtuale
PUÒ 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, 25 ] (ovvero QWERTY o 12 tasti)

Implementazioni del dispositivo:

PUÒ omettere opzioni di navigazione senza tocco (ovvero, può omettere trackball, croce direzionale o rotellina)
DEVE riportare il valore corretto per android.content.res.Configuration.navigation [ Risorse, 25 ]

8.4. Orientamento schermo

I dispositivi compatibili DEVONO supportare l'orientamento dinamico delle applicazioni con orientamento dello schermo verticale o orizzontale. Cioè, il dispositivo deve rispettare la richiesta dell'applicazione per uno specifico orientamento dello schermo. Le implementazioni del dispositivo POSSONO selezionare l'orientamento verticale o orizzontale come predefinito.

I dispositivi DEVONO riportare il valore corretto per l'orientamento corrente del dispositivo, ogni volta richiesto tramite android.content.res.Configuration.orientation, android.view.Display.getOrientation() o altre API.

8.5. Ingresso sul touchscreen

Implementazioni del dispositivo:

DEVE avere un touchscreen
PUÒ avere un touchscreen capacitivo o resistivo
DEVE riportare il valore di android.content.res.Configuration [ Resources, 25 ] che riflette il tipo di touchscreen specifico sul dispositivo
DOVREBBE supportare puntatori tracciati in modo completamente indipendente, se il touchscreen supporta più puntatori

8.6. USB

Implementazioni del dispositivo:

DEVE implementare un client USB, collegabile a un host USB con una porta USB-A standard
DEVE implementare Android Debug Bridge su USB (come descritto nella Sezione 7)
DEVE implementare la specifica di archiviazione di massa USB, per consentire a un host connesso al dispositivo di 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 fornito con un cavo in grado di collegare la piedinatura personalizzata alla porta USB-A standard
DOVREBBE implementare il supporto per la specifica USB Mass Storage (in modo che sia possibile accedere allo spazio di archiviazione rimovibile o fisso sul dispositivo da un PC host)

Le funzioni Home, Menu e Indietro sono essenziali per il paradigma di navigazione Android. Le implementazioni del dispositivo DEVONO rendere queste funzioni disponibili all'utente in ogni momento, indipendentemente dallo stato dell'applicazione. Queste funzioni DOVREBBERO essere implementate tramite pulsanti dedicati. POSSONO essere implementati utilizzando software, gesti, pannello a sfioramento, ecc., ma in tal caso DEVONO essere sempre accessibili e non oscurare o interferire con l'area di visualizzazione dell'applicazione disponibile.

Gli implementatori del dispositivo DOVREBBERO fornire anche una chiave di ricerca dedicata. Gli implementatori del dispositivo POSSONO anche fornire tasti di invio e fine per le chiamate telefoniche.

8.8. Rete dati wireless

Le implementazioni dei dispositivi DEVONO includere il supporto per la rete dati wireless ad alta velocità. Nello specifico, le implementazioni del dispositivo DEVONO includere il supporto per almeno uno standard di dati wireless capace di 200 Kbit/sec o superiore. Esempi di tecnologie che soddisfano questo requisito includono EDGE, HSPA, EV-DO, 802.11g, ecc.

Se l'implementazione di un dispositivo include una modalità particolare per la quale l'SDK Android include un'API (ovvero WiFi, GSM o CDMA), l'implementazione DEVE supportare l'API.

I dispositivi POSSONO implementare più di una forma di connettività dati wireless. I dispositivi POSSONO implementare la connettività dati cablata (come Ethernet), ma DEVONO comunque includere almeno una forma di connettività wireless, come sopra.

8.9. Telecamera

Le implementazioni del dispositivo DEVONO includere una fotocamera posteriore. La fotocamera posteriore inclusa:

DEVE avere una risoluzione di almeno 2 megapixel
DOVREBBE avere la messa a fuoco automatica hardware o quella software implementata nel driver della fotocamera (trasparente al software applicativo)
PUÒ avere hardware a fuoco fisso o EDOF (profondità di campo estesa).
PUÒ includere un flash. Se la fotocamera include un flash, la spia del flash NON DEVE essere accesa mentre un'istanza android.hardware.Camera.PreviewCallback è stata registrata su una superficie di anteprima della fotocamera, a meno che l'applicazione non abbia abilitato esplicitamente il flash abilitando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON di un Oggetto Camera.Parameters . Tieni presente che questo vincolo non si applica all'applicazione della fotocamera di sistema integrata nel dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback .

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

Se un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int), il dispositivo DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione.
Se un'applicazione registra un'istanza android.hardware.Camera.PreviewCallback e il sistema chiama il metodo onPreviewFrame() quando il formato di anteprima è YCbCr_420_SP, i dati nel byte[] passati a onPreviewFrame() devono inoltre essere nel formato di codifica NV21. (Questo è il formato utilizzato nativamente dalla famiglia hardware 7k.) Cioè, NV21 DEVE essere quello predefinito.

Le implementazioni del dispositivo DEVONO implementare l'API completa della fotocamera inclusa nella documentazione dell'SDK di Android 2.2 [ Risorse, 27 ]), indipendentemente dal fatto che il dispositivo includa la messa a fuoco automatica hardware o altre funzionalità. Ad esempio, le fotocamere prive di messa a fuoco automatica DEVONO comunque chiamare qualsiasi istanza android.hardware.Camera.AutoFocusCallback registrata (anche se ciò non ha rilevanza per una fotocamera senza messa a fuoco automatica).

Le implementazioni del dispositivo DEVONO riconoscere e rispettare ciascun nome di parametro definito come costante nella classe android.hardware.Camera.Parameters , se l'hardware sottostante supporta la funzionalità. Se l'hardware del dispositivo non supporta una funzionalità, l'API deve comportarsi come documentato. Al contrario, le implementazioni del dispositivo NON DEVONO onorare o riconoscere le costanti di stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti su android.hardware.Camera.Parameters . Cioè, le implementazioni del dispositivo DEVONO supportare tutti i parametri standard della fotocamera se l'hardware lo consente, e NON DEVONO supportare tipi di parametri della fotocamera personalizzati.

Le implementazioni del dispositivo POSSONO includere una fotocamera frontale. Tuttavia, se l'implementazione di un dispositivo include una fotocamera frontale, l'API della fotocamera implementata sul dispositivo NON DEVE utilizzare la fotocamera frontale per impostazione predefinita. Cioè, l'API della fotocamera in Android 2.2 è solo per le fotocamere posteriori e le implementazioni del dispositivo NON DEVONO riutilizzare o sovraccaricare l'API per agire su una fotocamera anteriore, se presente. Tieni presente che qualsiasi API personalizzata aggiunta dagli implementatori del dispositivo per supportare le fotocamere frontali DEVE rispettare le sezioni 3.5 e 3.6; ad esempio, se viene fornita una sottoclasse personalizzata android.hardware.Camera o Camera.Parameters per supportare le fotocamere frontali, NON DEVE essere posizionata in uno spazio dei nomi esistente, come descritto nelle sezioni 3.5 e 3.6. Tieni presente che l'inclusione di una fotocamera frontale non soddisfa il requisito secondo cui i dispositivi includono una fotocamera posteriore.

8.10. Accelerometro

Le implementazioni del dispositivo DEVONO includere un accelerometro a 3 assi e DEVONO essere in grado di fornire eventi a 50 Hz o superiori. Il sistema di coordinate utilizzato dall'accelerometro DEVE essere conforme al sistema di coordinate del sensore Android come dettagliato nelle API Android (vedi [ Risorse, 28 ]).

8.11. Bussola

Le implementazioni del dispositivo DEVONO includere una bussola a 3 assi e DEVE essere in grado di fornire eventi a 10 Hz o superiori. Il sistema di coordinate utilizzato dalla bussola DEVE essere conforme al sistema di coordinate del sensore Android come definito nell'API Android (vedi [ Risorse, 28 ]).

8.12. GPS

Le implementazioni del dispositivo DEVONO includere un ricevitore GPS e DOVREBBERO includere una qualche forma di tecnica di "GPS assistito" per ridurre al minimo il tempo di aggancio del GPS.

8.13. Telefonia

Android 2.2 PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. Cioè, Android 2.2 è compatibile con dispositivi che non sono telefoni. Tuttavia, se l'implementazione di un dispositivo include la telefonia GSM o CDMA, DEVE implementare il pieno supporto dell'API per quella tecnologia. Le implementazioni dei dispositivi che non includono l'hardware di telefonia DEVONO implementare le API complete come no-ops.

Vedere anche Sezione 8.8, Rete dati wireless.

8.14. Memoria e archiviazione

Le implementazioni del dispositivo DEVONO avere almeno 92 MB di memoria disponibile per il kernel e lo spazio utente. I 92 MB DEVONO essere in aggiunta a qualsiasi memoria dedicata a componenti hardware come radio, memoria e così via che non sono sotto il controllo del kernel.

Le implementazioni del dispositivo DEVONO avere almeno 150 MB di spazio di archiviazione non volatile disponibile per i dati utente. Cioè, la partizione /data DEVE essere almeno 150 MB.

Oltre ai requisiti di cui sopra, le implementazioni del dispositivo DOVREBBERO avere almeno 128 MB di memoria disponibile per kernel e spazio utente, oltre a qualsiasi memoria dedicata ai componenti hardware che non è sotto il controllo del kernel. Le implementazioni del dispositivo DOVREBBERO avere almeno 1 GB di spazio di archiviazione non volatile disponibile per i dati utente. Tieni presente che questi requisiti più elevati diventeranno minimi rigidi in una futura versione di Android. Si consiglia vivamente di implementare i dispositivi per soddisfare subito questi requisiti, altrimenti potrebbero non essere idonei per la compatibilità con una versione futura di Android.

8.15. Archiviazione condivisa dell'applicazione

Le implementazioni dei dispositivi DEVONO offrire spazio di archiviazione condiviso per le applicazioni. Lo spazio di archiviazione condiviso fornito DEVE avere una dimensione di almeno 2 GB.

Le implementazioni del dispositivo DEVONO essere configurate con l'archiviazione condivisa montata per impostazione predefinita, "pronta all'uso". Se l'archiviazione condivisa non è montata sul percorso Linux /sdcard , il dispositivo DEVE includere un collegamento simbolico Linux da /sdcard al punto di montaggio effettivo.

Le implementazioni del dispositivo DEVONO applicare come documentato l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE su questo archivio condiviso. In caso contrario, lo spazio di archiviazione condiviso DEVE essere scrivibile da qualsiasi applicazione che ottiene tale autorizzazione.

Le implementazioni del dispositivo POSSONO avere hardware per l'archiviazione rimovibile accessibile all'utente, come una scheda Secure Digital. In alternativa, le implementazioni del dispositivo POSSONO allocare spazio di archiviazione interno (non rimovibile) come spazio di archiviazione condiviso 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. Al momento della spedizione, lo spazio di archiviazione condiviso DEVE essere montato con il file system FAT.

È illustrativo considerare due esempi comuni. Se l'implementazione di un dispositivo include uno slot per scheda SD per soddisfare i requisiti di archiviazione condivisa, una scheda SD formattata FAT da 2 GB o superiore 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, formattata come grasso e montata su /sdcard (o /sdcard deve essere un collegamento simbolico alla posizione fisica se lo è montato altrove.)

Le implementazioni del dispositivo che includono più percorsi di archiviazione condivisa (come uno slot per schede SD e l'archiviazione interna condivisa) dovrebbero modificare le applicazioni core come lo scanner multimediale e il fornitore di content per supportare trasparente i file inseriti in entrambe le posizioni.

8.16. Bluetooth

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

La suite di test di compatibilità include casi che coprono il funzionamento di base dell'API Bluetooth Android RFCOMM. Tuttavia, poiché Bluetooth è un protocollo di comunicazione tra i dispositivi, non può essere completamente testato dai test unitari in esecuzione su un singolo dispositivo. Di conseguenza, le implementazioni del dispositivo devono anche passare la procedura di test Bluetooth guidata dall'uomo descritta nell'Appendice A.

9. Compatibilità delle prestazioni

Uno degli obiettivi del programma di compatibilità Android è 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 Android 2.2 definito nella tabella seguente:

Metrico	Soglia di performance	Commenti
Tempo di lancio dell'applicazione	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 il tempo totale per completare il caricamento dell'attività predefinita per l'applicazione, incluso il tempo necessario per avviare il processo Linux, caricare il pacchetto Android nella VM Dalvik e chiamare OnCreate.
Applicazioni simultanee	Quando sono state lanciate più applicazioni, riaccendere un'applicazione già running dopo che è stata lanciata, deve richiedere meno del tempo di lancio originale.

10. Compatibilità del modello di sicurezza

Le implementazioni del dispositivo 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, 29 ] 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. Autorizzazioni

Le implementazioni del dispositivo devono supportare il modello di autorizzazioni Android come definito nella documentazione di Sviluppatore Android [ Risorse, 29 ]. 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. UID e isolamento del processo

Le implementazioni del dispositivo 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, 29 ].

10.3. Autorizzazioni del file system

Le implementazioni del dispositivo devono supportare il modello di autorizzazioni di accesso ai file Android come definito come definito nel riferimento di sicurezza e autorizzazioni [ Risorse, 29 ].

10.4. Ambienti di esecuzione alternativi

Le implementazioni del dispositivo possono includere ambienti di runtime che eseguono applicazioni utilizzando altri software o tecnologia rispetto alla macchina virtuale Dalvik o al codice nativo. Tuttavia, tali ambienti di esecuzione alternativi non devono compromettere il modello di sicurezza Android o la sicurezza delle applicazioni Android installate, come descritto in questa sezione.

I tempi di funzionamento alternativi devono essere essi stessi applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella Sezione 10.

Il funzionamento alternativo non deve essere concesso l'accesso alle risorse protette dalle autorizzazioni non richieste nel file AndroidManifest.xml del runtime tramite il meccanismo <uses-permission> .

Il funzionamento alternativo non deve consentire alle applicazioni di utilizzare le funzionalità protette dalle autorizzazioni Android limitate alle applicazioni di sistema.

I tempi di punta alternativi devono rispettare il modello sandbox Android. Nello specifico:

Runtimes alternativi dovrebbe installare app tramite PackageManager in sandbox Android separati (ovvero ID utente Linux, ecc.)
Runtimes alternativo può fornire un singolo sandbox Android condiviso da tutte le applicazioni utilizzando il runtime alternativo.
Runtimes alternati e applicazioni installate che utilizzano un runtime alternativo non devono riutilizzare la sandbox di qualsiasi altra app installata sul dispositivo, tranne attraverso i meccanismi Android standard dell'ID utente condiviso e del certificato di firma
I pompari alternativi non devono essere lanciati, concedere o concedere l'accesso ai sandbox corrispondenti ad altre applicazioni Android.

Non è necessario lanciare, o concedere i punti di funzionamento alternativi o concedere ad altre domande eventuali privilegi del superutente (root) o di qualsiasi altro ID utente.

I file .APK di fasi di esecuzione alternativi possono essere inclusi nell'immagine di sistema di un'implementazione di un dispositivo, ma devono essere firmati con una chiave distinta dalla chiave utilizzata per firmare altre applicazioni incluse nell'implementazione del dispositivo.

Durante l'installazione di applicazioni, i punti di esecuzione alternativi devono ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione. Cioè, se un'applicazione deve utilizzare una risorsa del dispositivo per la quale esiste un'autorizzazione Android corrispondente (come fotocamera, GPS, ecc.), Il runtime alternativo deve informare l'utente che l'applicazione sarà in grado di accedere a tale risorsa . Se l'ambiente di runtime non registra le funzionalità dell'applicazione in questo modo, l'ambiente di runtime deve elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione utilizzando tale runtime.

11. Suite di test di compatibilità

Le implementazioni del dispositivo 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.2. Le implementazioni del dispositivo devono passare l'ultima versione CTS disponibile al momento del completamento del software del dispositivo.

12. Software aggiornabile

Le implementazioni del dispositivo 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 dei seguenti approcci soddisferà questo requisito:

Download over-the-air (OTA) con aggiornamento offline tramite riavvio
Aggiornamenti "Tethered" su USB da un PC host
Aggiornamenti "offline" tramite un riavvio e aggiornamento da un file su 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.

Appendice A - Procedura di test Bluetooth

La procedura di prova si basa sull'app di esempio BluetoothChat inclusa nell'albero di progetto Open-Source Android. La procedura richiede due dispositivi:

Un'implementazione del dispositivo candidato che esegue la build del software da testare
Un'implementazione del dispositivo separata già noto per essere compatibile e di un modello dall'implementazione del dispositivo in fase di test, ovvero un'implementazione del dispositivo "noto"

La procedura di prova seguente si riferisce a questi dispositivi come dispositivi "candidati" e "noti bene", rispettivamente.

Installazione e installazione

Crea bluetoothchat.apk tramite 'crea campioni' da un albero di codice sorgente Android.
Installare Bluetoothchat.Apk sul dispositivo noto.
Installare Bluetoothchat.APK sul dispositivo candidato.

Test Bluetooth Control da parte delle app

Avvia BluetoothChat sul dispositivo candidato, mentre Bluetooth è disabilitato.
Verificare che il dispositivo candidato attivi Bluetooth o che richieda all'utente una finestra di dialogo per attivare Bluetooth.

Test di accoppiamento e comunicazione

Avvia l'app di chat Bluetooth su entrambi i dispositivi.
Rendi rilevibile il dispositivo di buon bene dall'interno di Bluetoothchat (usando il menu).
Sul dispositivo candidato, scansiona i dispositivi Bluetooth dall'interno di BluetoothChat (utilizzando il menu) e abbina il dispositivo noto.
Invia 10 o più messaggi da ciascun dispositivo e verifica che l'altro dispositivo li riceva correttamente.
Chiudi l'app BluetoothChat su entrambi i dispositivi premendo a casa .
Scara ogni dispositivo dall'altro, utilizzando l'app Impostazioni del dispositivo.

Test di accoppiamento e comunicazione in direzione inversa

Avvia l'app di chat Bluetooth su entrambi i dispositivi.
Rendi rilevibile il dispositivo candidato dall'interno di BluetoothChat (utilizzando il menu).
Sul dispositivo noto, scansiona i dispositivi Bluetooth dall'interno di BluetoothChat (utilizzando il menu) e abbina il dispositivo candidato.
Invia 10 o messaggi da ciascun dispositivo e verifica che l'altro dispositivo li riceva correttamente.
Chiudi l'app di chat Bluetooth su entrambi i dispositivi premendo ripetutamente indietro per arrivare al lanciatore.

Test riaccendi

Rilanciare l'app di chat Bluetooth su entrambi i dispositivi.
Invia 10 o messaggi da ciascun dispositivo e verifica che l'altro dispositivo li riceva correttamente.

NOTA: i test di cui sopra hanno alcuni casi che terminano una sezione di test utilizzando Home e altri che utilizzano. Questi test non sono ridondanti e non sono facoltativi: l'obiettivo è verificare che l'API e lo stack Bluetooth funzionino correttamente sia quando le attività sono esplicitamente terminate (tramite l'utente che preme indietro, che chiama finitura ()) e implicitamente inviate allo sfondo (tramite l'utente che preme Home.) Ogni sequenza di test deve essere eseguita come descritto.