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

Per essere considerate compatibili con Android 4.2, le implementazioni del dispositivo DEVONO soddisfare i requisiti presentati nella presente Definizione di compatibilità, inclusi eventuali documenti incorporati tramite riferimento.

Laddove questa definizione o i test software descritti nella Sezione 10 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 nella massima misura possibile 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 del software 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 4.2: http://source.android.com/docs/compatibility/4.2/versions.html

Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html

Accelerazione hardware: http://developer.android.com/guide/topics/graphics/hardware-accel.html

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

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

Funzionalità offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline

Tag video HTML5: http://dev.w3.org/html5/spec/Overview.html#video

API di geolocalizzazione HTML5/W3C: http://www.w3.org/TR/geolocation-API/

API del database web HTML5/W3C: http://www.w3.org/TR/webdatabase/

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

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_guidelines/icon_design_status_bar.html

Gestione ricerche: http://developer.android.com/reference/android/app/SearchManager.html

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

Temi: http://developer.android.com/guide/topics/ui/themes.html

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

Sfondi animati: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

Amministrazione dispositivo Android: http://developer.android.com/guide/topics/admin/device-admin.html

Riferimento DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

API del servizio di accessibilità Android: http://developer.android.com/reference/android/accessibilityservice/package-summary.html

API di accessibilità Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html

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

API di sintesi vocale: http://developer.android.com/reference/android/speech/tts/package-summary.html

Documentazione dello strumento di riferimento (per adb, aapt, ddms, systrace): 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

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

Supporto di più schermi: http://developer.android.com/guide/practices/screens_support.html

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

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

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

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

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

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

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

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

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

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

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

API di orientamento della fotocamera: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

Fotocamera: http://developer.android.com/reference/android/hardware/Camera.html

Accessori aperti Android: http://developer.android.com/guide/topics/usb/accessory.html

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

Riferimento alla sicurezza e alle autorizzazioni Android: http://developer.android.com/guide/topics/security/security.html

App per Android: http://code.google.com/p/apps-for-android

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

Trasferimento file Android: http://www.android.com/filetransfer

Formati multimediali Android: http://developer.android.com/guide/appendix/media-formats.html

Bozza di protocollo per lo streaming live HTTP: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

Trasferimento della connessione NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover

Associazione semplice e sicura Bluetooth tramite NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

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

Azione assistita: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

Specifiche di ricarica USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

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

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

Impostazioni di condivisione NFC Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

Wifi diretto (Wifi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

Blocco e widget della schermata iniziale: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

Riferimento UserManager: http://developer.android.com/reference/android/os/UserManager.html

Riferimento per l'archiviazione esterna: https://source.android.com/docs/core/storage

API di archiviazione esterna: http://developer.android.com/reference/android/os/Environment.html

Codice breve SMS: http://en.wikipedia.org/wiki/Short_code

Client di controllo remoto multimediale: http://developer.android.com/reference/android/media/RemoteControlClient.html

Gestione visualizzazione: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

Sogni: http://developer.android.com/reference/android/service/dreams/DreamService.html

Impostazioni relative allo sviluppo di applicazioni Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

Fotocamera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

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

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 4.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à.

Questa definizione di compatibilità consente di omettere dalle implementazioni del dispositivo alcuni tipi di hardware per i quali Android include API. In questi casi, le API DEVONO essere ancora presenti e comportarsi in modo ragionevole. Vedere la Sezione 7 per i requisiti specifici per questo scenario.

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.

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 4.2, questo campo DEVE avere il valore intero 17.
android.os.Build.VERSION.SDK_INT	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 4.2, questo campo DEVE avere il valore intero 17.
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. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `"^[a-zA-Z0-9.,_-]+$"` .
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. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.CPU_ABI	Il nome del set di istruzioni (tipo CPU + convenzione ABI) del codice nativo. Vedere la Sezione 3.3: Compatibilità API nativa .
android.os.Build.CPU_ABI2	Il nome del secondo set di istruzioni (tipo CPU + convenzione ABI) del codice nativo. Vedere la Sezione 3.3: Compatibilità API nativa .
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. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `"^[a-zA-Z0-9.,_-]+$"` .
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):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Per esempio: `acme/mydevice/generic:4.2/JRN53/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 ("_"). Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit.
android.os.Build.HARDWARE	Il nome dell'hardware (dalla riga di comando del kernel o /proc). DOVREBBE essere ragionevolmente leggibile dall'uomo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `"^[a-zA-Z0-9.,_-]+$"` .
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. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.MANUFACTURER	Il nome commerciale del produttore dell'attrezzatura originale (OEM) del prodotto. 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 prodotto (SKU). DEVE essere leggibile dall'uomo, ma non è necessariamente destinato alla visualizzazione da parte degli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.SERIAL	Un numero di serie dell'hardware, se disponibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `"^([a-zA-Z0-9]{0,20})$"` .
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". Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `"^[a-zA-Z0-9.,_-]+$"` .
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". Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `"^[a-zA-Z0-9.,_-]+$"` .
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

Le implementazioni del dispositivo DEVONO rispettare il sistema di intenti ad accoppiamento lento di Android, come descritto nelle sezioni seguenti. 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 contatti, calendario, galleria fotografica, 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
Contatti
Galleria
Ricerca globale
Lanciatore
Musica
Impostazioni

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, le implementazioni del dispositivo DEVONO consentire a ciascun modello di intento a cui si fa riferimento nella Sezione 3.2.3.2 di essere sovrascritto da applicazioni di terze parti. L'implementazione 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.

Tuttavia, le implementazioni del dispositivo POSSONO fornire attività predefinite per modelli URI specifici (ad esempio http://play.google.com) se l'attività predefinita fornisce un filtro più specifico per l'URI dei dati. Ad esempio, un filtro di intent che specifica l'URI dei dati "http://www.android.com" è più specifico del filtro del browser per "http://". Le implementazioni del dispositivo DEVONO fornire un'interfaccia utente affinché gli utenti possano modificare l'attività predefinita per gli intenti.

3.2.3.3. Spazi dei nomi di intenti

Le implementazioni 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.* o com.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. Le implementazioni dei dispositivi POSSONO includere modelli di intenti che utilizzano spazi dei nomi chiaramente e ovviamente associati alla propria organizzazione.

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

3.3.1 Interfacce binarie dell'applicazione

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. Poiché il codice nativo dipende fortemente dalla tecnologia del processore sottostante, Android definisce una serie di interfacce binarie applicative (ABI) nell'NDK di Android, nel file docs/CPU-ARCH-ABIS.html . Se l'implementazione di un dispositivo è compatibile con uno o più ABI definiti, DOVREBBE implementare la compatibilità con Android NDK, come di seguito.

Se l'implementazione di un dispositivo include il supporto per un'ABI Android, essa:

DEVE includere il supporto per il codice in esecuzione nell'ambiente gestito per richiamare il codice nativo, utilizzando la semantica JNI (Java Native Interface) standard.
DEVE essere compatibile con il codice sorgente (ovvero compatibile con l'intestazione) e compatibile con il codice binario (per ABI) con ciascuna libreria richiesta nell'elenco seguente
DEVE riportare accuratamente l'Application Binary Interface (ABI) nativa supportata dal dispositivo, tramite l'API android.os.Build.CPU_ABI
DEVE riportare solo gli ABI documentati nell'ultima versione di Android NDK, nel file docs/CPU-ARCH-ABIS.txt
DOVREBBE essere creato utilizzando il codice sorgente e i file di intestazione disponibili nel progetto open source Android upstream

Le seguenti API di codice nativo DEVONO essere disponibili per le app che includono codice nativo:

libc (libreria C)
libm (libreria matematica)
Supporto minimo per C++
Interfaccia JNI
liblog (registrazione Android)
libz (compressione Zlib)
libdl (linker dinamico)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (gestione superficie OpenGL nativa)
libjnigraphics.so
libOpenSLES.so (supporto audio OpenSL ES 1.0.1)
libOpenMAXAL.so (supporto OpenMAX AL 1.0.1)
libandroid.so (supporto attività Android nativo)
Supporto per OpenGL, come descritto di seguito

Tieni presente che le versioni future di Android NDK potrebbero introdurre il supporto per ABI aggiuntivi. Se l'implementazione di un dispositivo non è compatibile con un'ABI predefinita esistente, NON DEVE segnalare il supporto per alcuna ABI.

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

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 534.30 dall'albero Android Open Source upstream per Android 4.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/534.30 (KHTML, like Gecko) Version/4.2 Mobile Safari/534.30
- 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
- Le implementazioni del dispositivo POSSONO omettere Mobile nella stringa dell'agente utente

Il componente WebView DOVREBBE includere il supporto per la maggior parte possibile di HTML5 [ Risorse, 11 ]. Come minimo, le implementazioni del dispositivo DEVONO supportare ciascuna di queste API associate a HTML5 in WebView:

cache dell'applicazione/operazione offline [ Risorse, 12 ]
il tag <video> [ Risorse, 13 ]
geolocalizzazione [ Risorse, 14 ]

Inoltre, le implementazioni del dispositivo DEVONO supportare l'API di archiviazione web HTML5/W3C [ Risorse, 15 ] e DOVREBBERO supportare l'API IndexedDB HTML5/W3C [ Risorse, 16 ]. Tieni presente che poiché gli organismi di standardizzazione dello sviluppo web stanno passando a favorire IndexedDB rispetto al webstorage, si prevede che IndexedDB diventi un componente richiesto in una futura versione di Android.

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 utilizzata 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, 11 ]. Come minimo, le implementazioni del dispositivo DEVONO supportare ciascuna di queste API associate a HTML5:

cache dell'applicazione/operazione offline [ Risorse, 12 ]
il tag <video> [ Risorse, 13 ]
geolocalizzazione [ Risorse, 14 ]

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 la semantica 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 permesso standard

L'elenco di cui sopra non è completo. 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. 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.

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" come utilizzato 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à. Inoltre, se l'implementazione di un dispositivo include API personalizzate al di fuori dello spazio dei nomi Android standard, tali API DEVONO essere incluse in una libreria condivisa Android in modo che solo le app che le utilizzano esplicitamente (tramite il meccanismo <uses-library> ) siano interessate dall'aumento dell'utilizzo della memoria di tali API.

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

Le implementazioni del dispositivo DEVONO configurare Dalvik per allocare memoria in conformità con la piattaforma Android upstream e come specificato nella tabella seguente. (Vedere la Sezione 7.1.1 per le definizioni delle dimensioni e della densità dello schermo.)

Tieni presente che i valori di memoria specificati di seguito sono considerati valori minimi e le implementazioni del dispositivo POSSONO allocare più memoria per applicazione.

Dimensione dello schermo	Densità dello schermo	Memoria dell'applicazione
piccolo/normale/grande	ldpi/mdpi	16 MB
piccolo/normale/grande	tvdpi/hdpi	32 MB
piccolo/normale/grande	xhdpi	64 MB
xlarge	mdpi	32 MB
xlarge	tvdpi/hdpi	64 MB
xlarge	xhdpi	128 MB

3.8. Compatibilità dell'interfaccia utente

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, 18 ]. La versione di riferimento Android Open Source include un'applicazione Launcher che include funzionalità dell'interfaccia utente che consentono all'utente di aggiungere, visualizzare e rimuovere AppWidget dalla schermata principale.

Le implementazioni 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 le funzionalità 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'implementazione del dispositivo DEVE fornire un'applicazione separata accessibile dal Launcher che consenta agli utenti di aggiungere, configurare, visualizzare e rimuovere AppWidget.

Le implementazioni del dispositivo DEVONO essere in grado di eseguire il rendering di widget di 4 x 4 nella dimensione della griglia standard. (Vedi le Linee guida per la progettazione dei widget dell'app nella documentazione dell'SDK Android [ Risorse, 18 ] per i dettagli.

3.8.2. Notifiche

Android include API che consentono agli sviluppatori di avvisare gli utenti di eventi importanti [ Risorse, 19 ], utilizzando le funzionalità hardware e software del dispositivo.

Alcune API consentono alle applicazioni di eseguire notifiche o attirare l'attenzione utilizzando l'hardware, in particolare suono, vibrazione e luce. Le implementazioni del dispositivo DEVONO supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK e, nella misura possibile, con l'hardware di implementazione del dispositivo. Ad esempio, se l'implementazione di un dispositivo include un vibratore, DEVE implementare correttamente le API di vibrazione. Se l'implementazione di un dispositivo non dispone di hardware, le API corrispondenti DEVONO essere implementate come no-ops. Si noti che questo comportamento è ulteriormente dettagliato nella Sezione 7.

Inoltre, l'implementazione DEVE eseguire correttamente il rendering di tutte le risorse (icone, file audio, ecc.) fornite nelle API [ Risorse, 20 ] o nella guida allo stile delle icone della barra di stato/sistema [ Risorse, 21 ]. 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 4.2 include il supporto per notifiche avanzate, come visualizzazioni interattive per le notifiche in corso. Le implementazioni dei dispositivi DEVONO visualizzare ed eseguire correttamente le notifiche avanzate, come documentato nelle API Android.

3.8.3. Ricerca

Android include API [ Risorse, 22 ] 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.

3.8.4. Toast

Le applicazioni possono utilizzare l'API "Toast" (definita in [ Risorse, 23 ]) 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. Temi

Android fornisce "temi" come meccanismo per consentire alle applicazioni di applicare stili a un'intera attività o applicazione. Android 4.2 include un tema "Holo" o "olografico" come un insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se desiderano abbinare l'aspetto del tema Holo come definito dall'SDK di Android [ Risorse, 24 ]. Le implementazioni dei dispositivi NON DEVONO alterare nessuno degli attributi del tema Holo esposti alle applicazioni [ Risorse, 25 ].

Android 4.2 include un nuovo tema "Device Default" come un insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se desiderano abbinare l'aspetto del tema del dispositivo come definito dall'implementatore del dispositivo. Le implementazioni del dispositivo POSSONO modificare gli attributi del tema DeviceDefault esposti alle applicazioni [ Risorse, 25 ].

3.8.6. 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, 26 ]. 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.

3.8.7. Visualizzazione dell'applicazione recente

Il codice sorgente upstream di Android 4.2 include un'interfaccia utente per la visualizzazione delle applicazioni recenti utilizzando un'immagine in miniatura dello stato grafico dell'applicazione nel momento in cui l'utente ha lasciato l'applicazione per l'ultima volta. Le implementazioni del dispositivo POSSONO alterare o eliminare questa interfaccia utente; tuttavia, è prevista una futura versione di Android per fare un uso più ampio di questa funzionalità. Si consiglia vivamente alle implementazioni dei dispositivi di utilizzare l'interfaccia utente Android 4.2 upstream (o un'interfaccia simile basata su miniature) per le applicazioni recenti, altrimenti potrebbero non essere compatibili con una versione futura di Android.

3.8.8. Impostazioni di gestione degli ingressi

Android 4.2 include il supporto per i motori di gestione dell'input. Le API di Android 4.2 consentono agli IME delle app personalizzate di specificare impostazioni configurabili dall'utente. Le implementazioni del dispositivo DEVONO includere un modo per consentire all'utente di accedere alle impostazioni IME in qualsiasi momento quando viene visualizzato un IME che fornisce tali impostazioni utente.

3.8.9. Widget di blocco e schermata iniziale

Android 4.2 include il supporto per i widget dell'applicazione che gli utenti possono incorporare nella schermata iniziale o nella schermata di blocco (vedere le linee guida per la progettazione dei widget dell'app nella documentazione dell'SDK di Android [ Risorse, 69 ] per i dettagli). I widget dell'applicazione consentono un accesso rapido ai dati e ai servizi dell'applicazione senza avviare una nuova attività. I widget dichiarano il supporto per l'utilizzo nella schermata iniziale o nella schermata di blocco dichiarando il tag manifest android:widgetCategory che indica al sistema dove può essere posizionato il widget. Nello specifico, le implementazioni del dispositivo DEVONO soddisfare i seguenti requisiti.

Le implementazioni del dispositivo DEVONO supportare i widget dell'applicazione sulla schermata principale.
Le implementazioni del dispositivo DOVREBBERO supportare la schermata di blocco. Se le implementazioni del dispositivo includono il supporto per la schermata di blocco, le implementazioni del dispositivo DEVONO supportare i widget dell'applicazione sulla schermata di blocco.

3.8.10. Blocco schermo multimediale Controllo remoto

Android 4.2 include il supporto per l'API di controllo remoto che consente alle applicazioni multimediali di integrarsi con i controlli di riproduzione visualizzati in una visualizzazione remota come la schermata di blocco del dispositivo[ Risorse, 74 ]. Le implementazioni del dispositivo DEVONO includere il supporto per incorporare i controlli remoti nella schermata di blocco del dispositivo.

3.8.11. Sogni

Android 4.2 include il supporto per screensaver interattivi chiamati Dreams [ Risorse, 76 ]. Dreams consente agli utenti di interagire con le applicazioni quando un dispositivo di ricarica è inattivo o inserito in una base da scrivania. Le implementazioni del dispositivo DEVONO includere il supporto per Dreams e fornire un'opzione di impostazione per consentire agli utenti di configurare Dreams.

3.9 Amministrazione del dispositivo

Android 4.2 include funzionalità che consentono alle applicazioni sensibili alla sicurezza di eseguire funzioni di amministrazione del dispositivo a livello di sistema, come l'applicazione di criteri relativi alle password o l'esecuzione della cancellazione remota, tramite l'API di amministrazione del dispositivo Android [ Risorse, 27 ]. Le implementazioni del dispositivo DEVONO fornire un'implementazione della classe DevicePolicyManager [ Risorse, 28 ] e DOVREBBERO supportare l'intera gamma di policy di amministrazione del dispositivo definite nella documentazione dell'SDK di Android [ Risorse, 27 ].

Nota: sebbene alcuni dei requisiti sopra descritti siano indicati come "DOVREBBERO" per Android 4.2, le implementazioni del dispositivo che supportano la schermata di blocco DEVONO supportare i criteri del dispositivo per gestire i widget sulla schermata di blocco come definito nella documentazione dell'SDK di Android [ Risorse, 27 ].

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

3.10 Accessibilità

Android 4.2 fornisce un livello di accessibilità che aiuta gli utenti con disabilità a navigare più facilmente nei propri dispositivi. Inoltre, Android 4.2 fornisce API della piattaforma che consentono alle implementazioni dei servizi di accessibilità di ricevere callback per eventi utente e di sistema e generare meccanismi di feedback alternativi, come sintesi vocale, feedback tattile e navigazione con trackball/d-pad [ Risorse, 29 ] . Le implementazioni dei dispositivi DEVONO fornire un'implementazione del framework di accessibilità Android coerente con l'implementazione Android predefinita. Nello specifico, le implementazioni del dispositivo DEVONO soddisfare i seguenti requisiti.

Le implementazioni del dispositivo DEVONO supportare implementazioni di servizi di accessibilità di terze parti tramite le API android.accessibilityservice [ Risorse, 30 ].
Le implementazioni del dispositivo DEVONO generare AccessibilityEvents e fornire questi eventi a tutte le implementazioni AccessibilityService registrate in modo coerente con l'implementazione Android predefinita.
Le implementazioni del dispositivo DEVONO fornire un meccanismo accessibile all'utente per abilitare e disabilitare i servizi di accessibilità e DEVONO visualizzare questa interfaccia in risposta all'intento android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS .

Inoltre, le implementazioni del dispositivo DOVREBBERO fornire un'implementazione di un servizio di accessibilità sul dispositivo e DOVREBBERO fornire un meccanismo che consenta agli utenti di abilitare il servizio di accessibilità durante la configurazione del dispositivo. Un'implementazione open source di un servizio di accessibilità è disponibile dal progetto Eyes Free [ Risorse, 31 ].

3.11 Sintesi vocale

Android 4.2 include API che consentono alle applicazioni di utilizzare servizi di sintesi vocale (TTS) e consente ai fornitori di servizi di fornire implementazioni di servizi TTS [ Risorse, 32 ]. Le implementazioni del dispositivo DEVONO soddisfare questi requisiti relativi al framework Android TTS:

Le implementazioni del dispositivo DEVONO supportare le API del framework Android TTS e DOVREBBERO includere un motore TTS che supporti le lingue disponibili sul dispositivo. Tieni presente che il software open source Android originale include un'implementazione completa del motore TTS.
Le implementazioni del dispositivo DEVONO supportare l'installazione di motori TTS di terze parti.
Le implementazioni del dispositivo DEVONO fornire un'interfaccia accessibile all'utente che consenta agli utenti di selezionare un motore TTS da utilizzare a livello di sistema.

4. 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, 33 ].

Le implementazioni dei dispositivi NON DEVONO estendere i formati .apk [ Risorse, 34 ], Android Manifest [ Risorse, 35 ], bytecode Dalvik [ Risorse, 17 ] o renderscript bytecode 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.

5. Compatibilità multimediale

Le implementazioni del dispositivo DEVONO includere almeno una forma di uscita audio, come altoparlanti, jack per cuffie, connessione per altoparlanti esterni, ecc.

5.1. Codec multimediali

Le implementazioni del dispositivo DEVONO supportare i formati multimediali principali specificati nella documentazione dell'SDK Android [ Risorse, 58 ], tranne dove esplicitamente consentito in questo documento. Nello specifico, le implementazioni del dispositivo DEVONO supportare i formati multimediali, i codificatori, i decodificatori, i tipi di file e i formati contenitore definiti nelle tabelle seguenti. 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.

Tieni presente che queste tabelle non elencano i requisiti specifici di bitrate per la maggior parte dei codec video poiché l'hardware del dispositivo attuale 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.

Tipo	Formato/Codice	Codificatore	Decodificatore	Dettagli	Tipi di file/formati contenitore
Audio	Profilo MPEG-4 AAC (AAC LC)	NECESSARIO Obbligatorio per le implementazioni del dispositivo che includono l'hardware del microfono e definiscono `android.hardware.microphone` .	NECESSARIO	Supporto per contenuti mono/stereo/5.0/5.1* con frequenze di campionamento standard da 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS RAW AAC (.aac, decodifica in Android 3.1+, codifica in Android 4.0+, ADIF non supportato) MPEG-TS (.ts, non ricercabile, Android 3.0+)
	Profilo MPEG-4 HE AAC (AAC+)	OBBLIGATORIO per le implementazioni del dispositivo che includono l'hardware del microfono e definiscono android.hardware.microphone	NECESSARIO	Supporto per contenuti mono/stereo/5.0/5.1* con frequenze di campionamento standard da 16 a 48 kHz.
	Profilo MPEG-4 HE AAC v2 (AAC+ avanzato)		NECESSARIO	Supporto per contenuti mono/stereo/5.0/5.1* con frequenze di campionamento standard da 16 a 48 kHz.
	Tipo di oggetto audio MPEG-4 ER AAC ELD (AAC a basso ritardo avanzato)	OBBLIGATORIO per le implementazioni del dispositivo che includono l'hardware del microfono e definiscono android.hardware.microphone	NECESSARIO	Supporto per contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.
	AMR-NB	NECESSARIO Obbligatorio per le implementazioni del dispositivo che includono l'hardware del microfono e definiscono `android.hardware.microphone` .	NECESSARIO	Da 4,75 a 12,2 kbps campionati a 8kHz	3GPP (.3gp)
	AMR-WB	NECESSARIO Obbligatorio per le implementazioni del dispositivo che includono l'hardware del microfono e definiscono `android.hardware.microphone` .	NECESSARIO	9 velocità campionate da 6,60 kbit/s a 23,85 kbit/s a 16kHz	3GPP (.3gp)
	FLAC		NECESSARIO (Android 3.1+)	Mono/stereo (no multicanale). Frequenze di campionamento fino a 48 kHz (ma fino a 44,1 kHz è consigliata su dispositivi con uscita a 44,1 kHz, poiché il downsampler da 48 a 44,1 kHz non include un filtro passa-basso). consigliato 16 bit; nessun dithering applicato per 24 bit.	Solo FLAC (.flac).
	MP3		NECESSARIO	Mono/stereo 8-320 Kbps costante (CBR) o bit rate variabile (VBR)	MP3 (.mp3)
	MIDI		NECESSARIO	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) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelodia (.imy)
	Vorbis		NECESSARIO		Ogg (.ogg) Matroska (.mkv)
	PCM/ONDA	NECESSARIO	NECESSARIO	PCM lineare a 8 bit e 16 bit** (velocità fino al limite dell'hardware). I dispositivi DEVONO supportare frequenze di campionamento per la registrazione PCM grezza a frequenze di 8000, 16000 e 44100 Hz	ONDA (.wav)
Immagine	JPEG	NECESSARIO	NECESSARIO	Base+progressivo	JPEG (.jpg)
	GIF		NECESSARIO		GIF (.gif)
	PNG	NECESSARIO	NECESSARIO		PNG (.png)
	BMP		NECESSARIO		BMP (.bmp)
	WEBP	NECESSARIO	NECESSARIO		WebP (.webp)
video	H.263	NECESSARIO Obbligatorio per le implementazioni dei dispositivi che includono l'hardware della fotocamera e definiscono `android.hardware.camera` o `android.hardware.camera.front` .	NECESSARIO		3GPP (.3gp) MPEG-4 (.mp4)
	H.264AV	NECESSARIO Obbligatorio per le implementazioni dei dispositivi che includono l'hardware della fotocamera e definiscono `android.hardware.camera` o `android.hardware.camera.front` .	NECESSARIO	Profilo basale (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, solo audio AAC, non ricercabile, Android 3.0+)
	MPEG-4SP		NECESSARIO		3GPP (.3gp)
	VP8		NECESSARIO (Android 2.3.3+)		WebM (.webm) e Matroska (.mkv, Android 4.0+)

*Nota: è richiesto solo il downmix del contenuto 5.0/5.1; la registrazione o il rendering di più di 2 canali è facoltativa. **Nota: l'acquisizione PCM lineare a 16 bit è obbligatoria. L'acquisizione PCM lineare a 8 bit non è obbligatoria.

5.2 Codifica video

Le implementazioni di dispositivi Android che includono una fotocamera posteriore e dichiarano android.hardware.camera DOVREBBERO supportare i seguenti profili di codifica video.

	SD (bassa qualità)	SD (alta qualità)	HD (se supportato dall'hardware)
Video codec	Profilo di base H.264	Profilo di base H.264	Profilo di base H.264
Risoluzione video	176 x 144 pixel	480 x 360 pixel	1280 x 720 pixel
Frequenza fotogrammi video	12 fps	30 fps	30 fps
Bitrate video	56 Kbps	500 Kbps o superiore	2Mbps o superiore
Codec audio	AAC-LC	AAC-LC	AAC-LC
Canali audio	1 (mono)	2 (stereo)	2 (stereo)
Bitrate audio	24 Kbps	128 Kbps	192 Kbps

5.3 Decodifica video

Le implementazioni dei dispositivi Android DOVREBBERO supportare i seguenti profili di decodifica video VP8.

	SD (bassa qualità)	SD (alta qualità)	HD720p (Se supportato dall'hardware)	HD1080p (Se supportato dall'hardware)
Risoluzione video	320x180px	640 x 360 pixel	1280 x 720 pixel	1920 x 1080 pixel
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps
Bitrate video	800 Kbps	2Mbps	8Mbps	20Mbps

5.4. Registrazione audio

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

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 di livello di potenza sonora (SPL) di 90 dB a 1000 Hz produca RMS di 2500 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% per 1 Khz con un livello di ingresso di 90 dB SPL.

Oltre alle specifiche di registrazione di cui sopra, quando un'applicazione ha iniziato a registrare un flusso audio utilizzando la sorgente audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION :

L'elaborazione della riduzione del rumore, se presente, DEVE essere disabilitata.
Il controllo automatico del guadagno, se presente, DEVE essere disabilitato.

5.5. Latenza audio

La latenza audio è il ritardo temporale durante il quale un segnale audio passa attraverso un sistema. Molte classi di applicazioni si basano su latenze brevi, per ottenere effetti in tempo reale come effetti sonori o comunicazioni VOIP.

Ai fini di questa sezione:

La "latenza di output" è definita come l'intervallo tra il momento in cui un'applicazione scrive un frame di dati codificati PCM e il momento in cui il suono corrispondente può essere ascoltato da un ascoltatore esterno o osservato da un trasduttore
La "latenza di uscita a freddo" è definita come la latenza di uscita per il primo frame, quando il sistema di uscita audio è stato inattivo e spento prima della richiesta
La "latenza di output continua" è definita come la latenza di output per i fotogrammi successivi, dopo che il dispositivo ha già riprodotto l'audio
La "latenza di input" è l'intervallo tra il momento in cui un suono esterno viene presentato al dispositivo e il momento in cui un'applicazione legge il frame corrispondente di dati codificati PCM
La "latenza di input a freddo" è definita come la somma del tempo di input perso e della latenza di input per il primo frame, quando il sistema di input audio è stato inattivo e spento prima della richiesta
La "latenza di input continua" è definita come la latenza di input per i fotogrammi successivi, mentre il dispositivo sta già catturando l'audio
"API della coda buffer OpenSL ES PCM" è l'insieme di API OpenSL ES relative a PCM all'interno di Android NDK; vedere NDK_root /docs/opensles/index.html

Secondo la Sezione 5 , tutte le implementazioni di dispositivi compatibili DEVONO includere almeno una forma di uscita audio. Le implementazioni del dispositivo DOVREBBERO soddisfare o superare questi requisiti di latenza di output:

latenza di uscita fredda di 100 millisecondi o meno
latenza di output continua di 45 millisecondi o meno

Se un'implementazione del dispositivo soddisfa i requisiti di questa sezione dopo qualsiasi calibrazione iniziale quando si utilizza l'API della coda buffer PCM OpenSL ES, per la latenza di output continua e latenza di output a freddo su almeno un dispositivo di output audio supportato, PUO' segnalare il supporto per l'audio a bassa latenza , segnalando la funzionalità "android.hardware.audio.low-latency" tramite la classe android.content.pm.PackageManager . [ Risorse, 37 ] Al contrario, se l'implementazione del dispositivo non soddisfa questi requisiti NON DEVE segnalare il supporto per l'audio a bassa latenza.

Secondo la Sezione 7.2.5 , l'hardware del microfono può essere omesso dalle implementazioni del dispositivo.

Le implementazioni del dispositivo che includono l'hardware del microfono e dichiarano android.hardware.microphone DOVREBBERO soddisfare questi requisiti di latenza audio in ingresso:

latenza di input a freddo pari o inferiore a 100 millisecondi
latenza di input continua di 50 millisecondi o meno

5.6. Protocolli di rete

I dispositivi DEVONO supportare i protocolli di rete multimediale per la riproduzione audio e video come specificato nella documentazione dell'SDK di Android [ Risorse, 58 ]. Nello specifico, i dispositivi DEVONO supportare i seguenti protocolli di rete multimediale:

RTSP (RTP, SDP)
Streaming progressivo HTTP(S).
Bozza di protocollo HTTP(S) per lo streaming live, versione 3 [ Risorse, 59 ]

6. Compatibilità degli strumenti e delle opzioni per sviluppatori

6.1 Strumenti per sviluppatori

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, 33 ]
Le implementazioni del dispositivo DEVONO supportare tutte le funzioni adb come documentato nell'SDK di Android. Il demone adb lato dispositivo DEVE essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivare Android Debug Bridge.

Android 4.2.2 include il supporto per adb sicuro. Adb sicuro abilita adb su host autenticati noti. I dispositivi esistenti e nuovi che eseguono Android 4.2.2 sono fortemente incoraggiati a soddisfare questo requisito in Android 4.2 , altrimenti non saranno in grado di ottenere la compatibilità con Android una volta aggiornati alla versione futura.

Dalvik Debug Monitor Service (noto come ddms) [ Risorse, 33 ]
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, 36 ]
Le implementazioni del dispositivo DEVONO includere il framework Monkey e renderlo disponibile per l'utilizzo da parte delle applicazioni.
SysTrace [ Risorse, 33 ]
Le implementazioni del dispositivo DEVONO supportare lo strumento systrace come documentato nell'SDK di Android. Systrace deve essere inattivo per impostazione predefinita e DEVE esserci un meccanismo accessibile all'utente per attivare Systrace.

La maggior parte dei sistemi basati su Linux e Apple Macintosh riconoscono i dispositivi Android utilizzando gli strumenti Android SDK standard, senza supporto aggiuntivo; tuttavia i sistemi Microsoft Windows in genere richiedono un driver per i nuovi dispositivi Android. (Ad esempio, i nuovi ID fornitore e talvolta i nuovi ID dispositivo richiedono driver USB personalizzati per i sistemi Windows.) Se l'implementazione di un dispositivo non viene riconosciuta dallo strumento adb come fornito nell'SDK Android standard, gli implementatori del dispositivo DEVONO fornire driver Windows che consentano agli sviluppatori di connettersi a il dispositivo utilizzando il protocollo adb . Questi driver DEVONO essere forniti per Windows XP, Windows Vista, Windows 7 e Windows 8, sia nella versione a 32 bit che a 64 bit.

6.2 Opzioni sviluppatore

Android 4.2 include il supporto per gli sviluppatori per configurare le impostazioni relative allo sviluppo dell'applicazione. Le implementazioni del dispositivo DEVONO rispettare l'intento android.settings.APPLICATION_DEVELOPMENT_SETTINGS di mostrare le impostazioni relative allo sviluppo dell'applicazione [ Risorse, 77 ]. L'implementazione Android upstream nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avviare Opzioni sviluppatore dopo aver premuto sette (7) volte sulla voce di menu Impostazioni > Informazioni sul dispositivo > Numero build. Le implementazioni del dispositivo DEVONO fornire un'esperienza coerente per le Opzioni sviluppatore. Nello specifico, le implementazioni del dispositivo DEVONO nascondere le Opzioni sviluppatore per impostazione predefinita e DEVONO fornire un meccanismo per abilitare le Opzioni sviluppatore che sia coerente con l'implementazione Android upstream.

7. Compatibilità hardware

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 descritto 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 di classe complete (come documentate dall'SDK) per le API del componente DEVONO essere ancora 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
I metodi API NON DEVONO generare eccezioni non documentate 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, 37 ]

7.1. Visualizzazione e grafica

Android 4.2 include funzionalità che regolano automaticamente le risorse dell'applicazione e i layout dell'interfaccia utente in modo appropriato per il dispositivo, per garantire che le applicazioni di terze parti funzionino correttamente su una varietà di configurazioni hardware [ Risorse, 38 ]. I dispositivi DEVONO implementare correttamente queste API e comportamenti, come dettagliato in questa sezione.

Le unità a cui fanno riferimento i requisiti di questa sezione sono definite come segue:

La "dimensione diagonale fisica" è la distanza in pollici tra due angoli opposti della parte illuminata del display.
"dpi" (che significa "punti per pollice") è il numero di pixel racchiusi in un intervallo lineare orizzontale o verticale di 1". Laddove sono elencati i valori dpi, sia il dpi orizzontale che quello verticale devono rientrare nell'intervallo.
"Rapporto d'aspetto" è il rapporto tra la dimensione più lunga dello schermo e quella più corta. Ad esempio, uno schermo da 480x854 pixel sarebbe 854 / 480 = 1.779, ovvero più o meno "16:9".
Un "pixel indipendente dalla densità" o ("dp") è l'unità pixel virtuale normalizzata a uno schermo da 160 dpi, calcolato come: pixels = dps * (density / 160) .

7.1.1. Configurazione dello schermo

Dimensione dello schermo

Il framework dell'interfaccia utente Android supporta una varietà di dimensioni dello schermo diverse e consente alle applicazioni di interrogare la dimensione dello schermo del dispositivo (noto anche come "layout dello schermo") tramite android.content.res.Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK . Le implementazioni del dispositivo devono segnalare le dimensioni della schermata corrette come definite nella documentazione SDK Android [ Risorse, 38 ] e determinate dalla piattaforma Android a monte. In particolare, le implementazioni del dispositivo devono segnalare la dimensione della schermata corretta in base alle seguenti dimensioni dello schermo di pixel indipendenti dalla densità logica (DP).

I dispositivi devono avere dimensioni dello schermo di almeno 426 dp x 320 dp ('piccolo')
I dispositivi che riportano le dimensioni dello schermo "normali" devono avere dimensioni dello schermo di almeno 480 dp x 320 dp
I dispositivi che riportano le dimensioni dello schermo "grandi" devono avere dimensioni dello schermo di almeno 640 dp x 480 dp
I dispositivi che riportano la dimensione dello schermo 'xlarge' devono avere dimensioni dello schermo di almeno 960 dp x 720 dp

Inoltre, i dispositivi devono avere dimensioni dello schermo di almeno 2,5 pollici di dimensioni diagonali fisiche.

I dispositivi non devono modificare le dimensioni dello schermo segnalate in qualsiasi momento.

Le applicazioni indicano facoltativamente quali dimensioni dello schermo supportano tramite l'attributo <supports-screens> nel file AndroidManifest.xml. Le implementazioni del dispositivo devono onorare correttamente il supporto dichiarato delle applicazioni per schermi piccoli, normali, grandi e xlarge, come descritto nella documentazione SDK Android.

Proporzioni dello schermo

Il rapporto di aspetto deve essere compreso tra 1,3333 (4: 3) e 1,85 (16: 9).

Densità dello schermo

Il framework dell'interfaccia utente Android definisce una serie di densità logiche standard per aiutare gli sviluppatori di applicazioni a indirizzare le risorse dell'applicazione. Le implementazioni del dispositivo devono segnalare una delle seguenti densità logiche del framework Android tramite le API android.util.DisplayMetrics e devono eseguire applicazioni a questa densità standard.

120 dpi, noto come "LDPI"
160 dpi, noto come "MDPI"
213 dpi, noto come "TVDPI"
240 dpi, noto come "HDPI"
320 dpi, noto come 'xhdpi'
480 dpi, noto come 'xxhdpi'

Le implementazioni del dispositivo dovrebbero definire la densità del framework Android standard che è numericamente più vicina alla densità fisica dello schermo, a meno che tale densità logica non spinga la dimensione dello schermo riportata al di sotto del minimo supportato. Se la densità del framework Android standard che è numericamente più vicina alla densità fisica si traduce in una dimensione dello schermo inferiore alla più piccola dimensione dello schermo compatibile supportata (larghezza 320 dp), le implementazioni del dispositivo dovrebbero segnalare la successiva densità di framework Android standard più bassa.

7.1.2. Visualizza metriche

Le implementazioni del dispositivo devono segnalare i valori corretti per tutte le metriche di visualizzazione definite in android.util.DisplayMetrics [ Risorse, 39 ].

7.1.3. Orientamento schermo

I dispositivi 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 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.

I dispositivi non devono modificare le dimensioni o la densità dello schermo riportate quando si modificano l'orientamento.

I dispositivi devono segnalare quali orientamenti dello schermo supportano ( android.hardware.screen.portrait e/o android.hardware.screen.landscape ) e devono segnalare almeno un orientamento supportato. Ad esempio, un dispositivo con uno schermo paesaggistico a orientamento fisso, come un televisore o un laptop, deve solo segnalare android.hardware.screen.landscape .

7.1.4. Accelerazione grafica 2D e 3D

Le implementazioni del dispositivo devono supportare sia OpenGL ES 1.0 che 2.0, come incorporati e dettagliati nelle documentazioni SDK Android. Le implementazioni del dispositivo devono inoltre supportare Android Renderscript, come dettagliato nella documentazione Android SDK [ Risorse, 8 ].

Le implementazioni del dispositivo devono inoltre identificarsi correttamente come supportare OpenGL ES 1.0 e 2.0. Questo è:

Le API gestite (come tramite il metodo GLES10.getString() ) devono segnalare il supporto per OpenGL ES 1.0 e 2.0
Le API OpenGL C/C ++ native (ovvero quelle disponibili per le app tramite libgles_v1cm.so, libgles_v2.so o libegl.so) devono segnalare il supporto per OpenGL ES 1.0 e 2.0.

Le implementazioni del dispositivo possono implementare eventuali estensioni OpenGL ES desiderate. Tuttavia, le implementazioni del dispositivo devono segnalare tramite le API gestite e native di OpenGL e tutte le stringhe di estensione che supportano e al contrario non devono segnalare le stringhe di estensione che non supportano.

Si noti che Android 4.2 include il supporto per le applicazioni per specificare facoltativamente che richiedono specifici formati di compressione della trama OpenGL. Questi formati sono in genere specifici del fornitore. Le implementazioni del dispositivo non sono richieste da Android 4.2 per implementare qualsiasi formato specifico di compressione della trama. Tuttavia, dovrebbero segnalare accuratamente eventuali formati di compressione della trama che supportano, tramite il metodo getString() nell'API OpenGL.

Android 4.2 include un meccanismo per le applicazioni per dichiarare che volevano abilitare l'accelerazione hardware per la grafica 2D a livello di applicazione, attività, finestra o vista attraverso l'uso di un tag manifest android:hardwareAccelerated o dirette [ risorse, 9 ].

In Android 4.2, le implementazioni del dispositivo devono abilitare l'accelerazione dell'hardware per impostazione predefinita e devono disabilitare l'accelerazione hardware se lo sviluppatore richiede quindi impostando android:hardwareAccelerated="false" o disabilitazione dell'accelerazione hardware direttamente tramite le API di visione Android.

Inoltre, le implementazioni del dispositivo devono mostrare un comportamento coerente con la documentazione SDK Android sull'accelerazione hardware [ Risorse, 9 ].

Android 4.2 include un oggetto TextureView che consente agli sviluppatori di integrare direttamente le trame aperte con accelerazione hardware come obiettivi di rendering in una gerarchia dell'interfaccia utente. Le implementazioni del dispositivo devono supportare l'API TextureView e devono esibire un comportamento coerente con l'implementazione Android a monte.

7.1.5. Modalità compatibilità dell'applicazione legacy

Android 4.2 Specifica una "modalità di compatibilità" in cui il framework opera in una modalità equivalente alla schermata "normale" (larghezza 320dp) a beneficio delle applicazioni legacy non sviluppate per le vecchie versioni di Android che precedono l'indipendenza della dimensione dello schermo. Le implementazioni del dispositivo devono includere il supporto per la modalità di compatibilità dell'applicazione legacy come implementata dal codice open source Android a monte. Cioè, le implementazioni del dispositivo NON DEVONO alterare i trigger o le soglie alle quali viene attivata la modalità di compatibilità e NON DEVONO alterare il comportamento della modalità di compatibilità stessa.

7.1.6. Tipi di schermo

Le schermate di implementazione del dispositivo sono classificate come uno dei due tipi:

Implementazioni di visualizzazione dei pixel fissi: lo schermo è un singolo pannello che supporta solo una singola larghezza e altezza dei pixel. In genere lo schermo è integrato fisicamente con il dispositivo. Esempi includono telefoni cellulari, tablet e così via.
Implementazioni di visualizzazione di pixel variabili: l'implementazione del dispositivo non ha una schermata incorporata e include una porta di uscita video come VGA, HDMI o una porta wireless per la visualizzazione o ha una schermata incorporata che può cambiare le dimensioni dei pixel. Esempi includono televisori, caselle di set e così via.

Implementazioni del dispositivo pixel fisso

Le implementazioni del dispositivo pixel fisso possono utilizzare schermate di qualsiasi dimensione dei pixel, a condizione che soddisfino i requisiti definiti questa definizione di compatibilità.

Le implementazioni di pixel fisse possono includere una porta di output video da utilizzare con un display esterno. Tuttavia, se quel display viene mai utilizzato per l'esecuzione di app, il dispositivo deve soddisfare i seguenti requisiti:

Il dispositivo deve segnalare la stessa configurazione dello schermo e visualizzare le metriche, come dettagliato nelle sezioni 7.1.1 e 7.1.2, come visualizzato il pixel fisso.
Il dispositivo deve segnalare la stessa densità logica del display a pixel fisso.
Il dispositivo deve segnalare le dimensioni dello schermo uguali o molto vicine al display a pixel fisso.

Ad esempio, un tablet di dimensioni diagonali di 7 "con una risoluzione di 1024x600 pixel è considerata un'implementazione di display MDPI di grandi dimensioni fisse. Le applicazioni vengono eseguite solo in una finestra MDPI di grandi dimensioni, indipendentemente dal fatto che il display fisso o la porta di uscita video sia in uso.

Implementazioni del dispositivo a pixel variabili

Le implementazioni del dispositivo a pixel variabili devono supportare uno o entrambi di 1280x720 o 1920x1080 (cioè 720p o 1080p). Le implementazioni del dispositivo con display a pixel variabili non devono supportare alcuna altra configurazione o modalità dello schermo. Le implementazioni del dispositivo con schermate a pixel variabili possono modificare la configurazione o la modalità schermo in fase di esecuzione o tempo di avvio. Ad esempio, un utente di una casella set-top può sostituire un display 720p con un display 1080p e l'implementazione del dispositivo può regolare di conseguenza.

Inoltre, le implementazioni del dispositivo a pixel variabili devono segnalare i seguenti secchi di configurazione per queste dimensioni dei pixel:

1280x720 (noto anche come 720p): dimensioni "grandi" dello schermo, "TVDPI" (213 dpi) densità
1920x1080 (noto anche come 1080p): dimensione dello schermo "grande", densità "xhdpi" (320 dpi)

Per la chiarezza, le implementazioni del dispositivo con dimensioni di pixel variabili sono limitate a 720p o 1080p in Android 4.2 e devono essere configurate per segnalare i secchi delle dimensioni dello schermo e della densità come notato sopra.

7.1.7. Tecnologia dello schermo

La piattaforma Android include API che consentono alle applicazioni di renderla grafica ricca al display. I dispositivi devono supportare tutte queste API come definite dall'SDK Android se non specificamente consentito in questo documento. Nello specifico:

I dispositivi devono supportare i display in grado di renderla grafica a colori a 16 bit e dovrebbero supportare display in grado di grafica a colori a 24 bit.
I dispositivi devono supportare display in grado di rendere animazioni.
La tecnologia di visualizzazione utilizzata deve avere un proporzione pixel (PAR) tra 0,9 e 1,1. Cioè, il rapporto pixel deve essere vicino a quadrati (1,0) con una tolleranza del 10%.

7.1.8. Display esterni

Android 4.2 include il supporto per la visualizzazione secondaria per abilitare le funzionalità di condivisione dei media e le API degli sviluppatori per l'accesso ai display esterni. Se un dispositivo supporta un display esterno tramite una connessione di visualizzazione aggiuntiva cablata, wireless o incorporata, l'implementazione del dispositivo deve implementare l'API Display Manager come descritto nella documentazione SDK Android [ Risorse, 75 ]. Le implementazioni del dispositivo che supportano l'output video sicuro e sono in grado di supportare le superfici sicure devono dichiarare il supporto per Display.SECURE_FLAG . In particolare, le implementazioni del dispositivo che dichiarano il supporto per Display.SECURE_FLAG , devono supportare HDCP 2.x o superiore per i display wireless Miracast o HDCP 1.2 o superiore per i display cablati. L'implementazione open source Android a monte include il supporto per i display wireless (Miracast) e Wired (HDMI) che soddisfano questo requisito.

7.2. Dispositivi di input

7.2.1. Tastiera

Implementazioni del dispositivo:

Deve 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 http://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, 40 ] (cioè Qwerty o 12 key)

Implementazioni del dispositivo:

Può omettere un'opzione 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, 40 ]
Deve fornire un ragionevole meccanismo di interfaccia utente alternativa per la selezione e la modifica del testo, compatibile con i motori di gestione input. L'implementazione open source Android a monte include un meccanismo di selezione adatto per l'uso con dispositivi privi di input di navigazione non touch.

Le funzioni Home, Menu e Indietro sono essenziali per il paradigma di navigazione Android. Le implementazioni del dispositivo devono rendere queste funzioni disponibili per l'utente in ogni momento durante l'esecuzione delle applicazioni. Queste funzioni possono essere implementate tramite pulsanti fisici dedicati (come pulsanti touch meccanici o capacitivi) o possono essere implementate utilizzando chiavi software, gesti, pannelli touch dedicati, ecc. Android 4.2 supporta entrambe le implementazioni.

Android 4.2 include il supporto per Assist Action [ Risorse, 63 ]. Le implementazioni del dispositivo devono rendere l'azione di assistenza disponibile per l'utente in ogni momento durante l'esecuzione delle applicazioni. Questa funzione può essere implementata tramite chiavi hardware o software.

Le implementazioni del dispositivo possono utilizzare una parte distinta dello schermo per visualizzare i tasti di navigazione, ma in tal caso, devono soddisfare questi requisiti:

I tasti di navigazione dell'implementazione del dispositivo devono utilizzare una parte distinta dello schermo, non disponibile per le applicazioni, e non devono oscurare o altrimenti interferire con la parte dello schermo disponibile per le applicazioni.
Le implementazioni del dispositivo devono rendere disponibile una parte del display alle applicazioni che soddisfano i requisiti definiti nella Sezione 7.1.1 .
Le implementazioni del dispositivo devono visualizzare i tasti di navigazione quando le applicazioni non specificano una modalità UI di sistema o specificano SYSTEM_UI_FLAG_VISIBLE .
Le implementazioni del dispositivo devono presentare le chiavi di navigazione in una modalità discreta "a basso profilo" (ad es. Dimmed) quando le applicazioni specificano SYSTEM_UI_FLAG_LOW_PROFILE .
Le implementazioni del dispositivo devono nascondere i tasti di navigazione quando le applicazioni specificano SYSTEM_UI_FLAG_HIDE_NAVIGATION .
L'implementazione del dispositivo deve presentare un tasto di menu alle applicazioni quando TargetSdkVersion <= 10 e non deve presentare una chiave di menu quando TargetSdkVersion> 10.

7.2.4. Ingresso sul touchscreen

Implementazioni del dispositivo:

Deve avere un sistema di input puntatore di qualche tipo (simile al mouse o al tocco)
Può avere un touchscreen di qualsiasi modalità (come capacitivo o resistivo)
Dovrebbe supportare puntatori tracciati completamente indipendentemente, se un touchscreen supporta più puntatori
Deve segnalare il valore di android.content.res.Configuration [ Risorse, 39 ] che riflettono corrispondente al tipo di touchscreen specifico sul dispositivo

Le implementazioni del dispositivo devono segnalare la funzione corretta corrispondente al tipo di input utilizzato. Si noti che Android 4.2 include la funzione android.hardware.faketouch , che corrisponde a un dispositivo di input non touch (cioè basato su punta) come un mouse o trackpad che può emulare adeguatamente input basato sul tocco (incluso Basic Supporto gesticole) e indica che il dispositivo supporta un sottoinsieme emulato di funzionalità touchscreen. Le implementazioni del dispositivo che includono un touchscreen (a touch singolo o migliore) devono anche segnalare Android.hardware.fakeTouch. Le implementazioni del dispositivo che non includono un touchscreen (e si basano solo su un dispositivo puntatore) non devono segnalare alcuna funzionalità touchscreen e devono segnalare solo android.hardware.faketouch .

7.2.5. Microfono

Le implementazioni del dispositivo possono omettere un microfono. Tuttavia, se un'implementazione del dispositivo omette un microfono, non deve segnalare costante la funzionalità android.hardware.microphone e deve implementare l'API di registrazione audio come no-op, per sezione 7 . Al contrario, le implementazioni del dispositivo che possiedono un microfono:

Deve segnalare la costante di funzionalità android.hardware.microphone
Dovrebbe soddisfare i requisiti di qualità audio nella sezione 5.4
Dovrebbe soddisfare i requisiti di latenza audio nella sezione 5.5

7.3. Sensori

Android 4.2 include API per l'accesso a una varietà di tipi di sensori. Le implementazioni dei dispositivi possono generalmente omettere questi sensori, come previsto dalle seguenti sottosezioni. Se un dispositivo include un particolare tipo di sensore che ha un'API corrispondente per sviluppatori di terze parti, l'implementazione del dispositivo deve implementare tale API come descritto nella documentazione SDK Android. Ad esempio, implementazioni del dispositivo:

Deve segnalare accuratamente la presenza o l'assenza di sensori secondo la classe android.content.pm.PackageManager . [ Risorse, 37 ]
Deve restituire un elenco accurato di sensori supportati tramite SensorManager.getSensorList() e metodi simili
Deve comportarsi ragionevolmente per tutte le altre API del sensore (ad esempio, restituendo true o false come appropriato quando le applicazioni tentano di registrare gli ascoltatori, non chiamando gli ascoltatori di sensori quando i sensori corrispondenti non sono presenti; ecc.)
Deve segnalare tutte le misurazioni del sensore utilizzando i valori internazionali di unità internazionali (IE metrica) per ciascun tipo di sensore definito nella documentazione SDK Android [ Risorse, 41 ]

L'elenco sopra non è completo; Il comportamento documentato dell'SDK Android deve essere considerato autorevole.

Alcuni tipi di sensori sono sintetici, il che significa che possono essere derivati dai dati forniti da uno o più altri sensori. (Esempi includono il sensore di orientamento e il sensore di accelerazione lineare.) Le implementazioni del dispositivo dovrebbero implementare questi tipi di sensori, quando includono i sensori fisici prerequisiti.

L'android 4.2 include la nozione di un sensore di "streaming", che è quello che restituisce i dati continuamente, piuttosto che solo quando i dati cambiano. Le implementazioni del dispositivo devono fornire continuamente campioni di dati periodici per qualsiasi API indicata dalla documentazione SDK Android 4.2 per essere un sensore di streaming. Si noti che le implementazioni del dispositivo devono garantire che il flusso del sensore non debba impedire alla CPU del dispositivo di inserire uno stato di sospensione o svegliarsi da uno stato di sospensione.

7.3.1. Accelerometro

Le implementazioni del dispositivo dovrebbero includere un accelerometro a 3 assi. Se un'implementazione del dispositivo include un accelerometro a 3 assi, IT:

Dovrebbe essere in grado di consegnare eventi a 120 Hz o più. Si noti che mentre la frequenza dell'accelerometro sopra è indicata come "dovrebbe" per Android 4.2, è prevista la definizione di compatibilità per una versione futura per cambiarli in "must". Cioè, questi standard sono opzionali in Android 4.2 ma saranno richiesti nelle versioni future. I dispositivi esistenti e nuovi che gestiscono Android 4.2 sono fortemente incoraggiati a soddisfare questi requisiti in Android 4.2 in modo che siano in grado di aggiornare le versioni future della piattaforma
Deve rispettare il sistema di coordinate del sensore Android, come dettagliato nelle API Android (vedi [ Risorse, 41 ])
Deve essere in grado di misurare dalla caduta libera fino a due volte gravità (2G) o più su qualsiasi vettore tridimensionale
Deve avere 8 bit di precisione o più
Deve avere una deviazione standard non superiore a 0,05 m/s^2

7.3.2. Magnetometro

Le implementazioni del dispositivo dovrebbero includere un magnetometro a 3 assi (cuscinetto a cioè.) Se un dispositivo include un magnetometro a 3 assi, IT:

Deve essere in grado di consegnare eventi a 10 Hz o superiore
Deve rispettare il sistema di coordinate del sensore Android come dettagliato nelle API Android (vedi [ Risorse, 41 ]).
Deve essere in grado di campionare una gamma di punti di forza del campo adeguati per coprire il campo geomagnetico
Deve avere 8 bit di precisione o più
Deve avere una deviazione standard non superiore a 0,5 µt

7.3.3. GPS

Le implementazioni del dispositivo dovrebbero includere un ricevitore GPS. Se un'implementazione del dispositivo include un ricevitore GPS, dovrebbe includere una qualche forma di tecnica "GPS assistita" per ridurre al minimo il tempo di blocco GPS.

7.3.4. Giroscopio

Le implementazioni del dispositivo dovrebbero includere un sensore di cambio angolare (cioè il sensore di cambiamento angolare.) Non dovrebbero includere un sensore di giroscopio a meno che non sia incluso un accelerometro a 3 assi. Se un'implementazione del dispositivo include un giroscopio, IT:

Deve essere compensato dalla temperatura
Deve essere in grado di misurare le variazioni di orientamento fino a 5,5*Pi radianti/secondo (cioè circa 1.000 gradi al secondo)
Dovrebbe essere in grado di consegnare eventi a 200 Hz o superiore. Si noti che mentre la frequenza del giroscopio sopra è indicata come "dovrebbe" per Android 4.2, la definizione di compatibilità per una versione futura è prevista per cambiarli in "must". Cioè, questi standard sono opzionali in Android 4.2 ma saranno richiesti nelle versioni future. I dispositivi esistenti e nuovi che gestiscono Android 4.2 sono fortemente incoraggiati a soddisfare questi requisiti in Android 4.2 in modo che siano in grado di aggiornare le versioni future della piattaforma
Deve avere 12 bit di precisione o più
Deve avere una varianza non superiore a 1e-7 rad^2 / s^2 per hz (varianza per hz o rad^2 / s). La varianza può variare con la frequenza di campionamento, ma deve essere vincolata da questo valore. In altre parole, se si misura la varianza del giroscopio a velocità di campionamento di 1 Hz, non dovrebbe essere maggiore di 1e-7 rad^2/s^2.
Deve avere i timestamp il più vicino possibile all'evento hardware. La latenza costante deve essere rimossa.

7.3.5. Barometro

Le implementazioni del dispositivo possono includere un barometro (cioè sensore di pressione dell'aria ambiente.) Se un'implementazione del dispositivo include un barometro, IT:

Deve essere in grado di consegnare eventi a 5 Hz o superiore
Deve avere una precisione adeguata per consentire la stima dell'altitudine
Deve essere compensato dalla temperatura

7.3.7. Termometro

Le implementazioni del dispositivo possono ma non dovrebbero includere un termometro (cioè sensore di temperatura.) Se un'implementazione del dispositivo include un termometro, deve misurare la temperatura della CPU del dispositivo. Non deve misurare nessun'altra temperatura. (Si noti che questo tipo di sensore è deprecato nelle API Android 4.2.)

7.3.7. Fotometro

Le implementazioni del dispositivo possono includere un fotometro (cioè sensore di luce ambientale.)

7.3.8. Sensore di prossimità

Le implementazioni del dispositivo possono includere un sensore di prossimità. Se un'implementazione del dispositivo include un sensore di prossimità, deve misurare la vicinanza di un oggetto nella stessa direzione dello schermo. Cioè, il sensore di prossimità deve essere orientato a rilevare oggetti vicino allo schermo, poiché l'intento principale di questo tipo di sensore è rilevare un telefono in uso dall'utente. Se un'implementazione del dispositivo include un sensore di prossimità con qualsiasi altro orientamento, non deve essere accessibile tramite questa API. Se un'implementazione del dispositivo ha un sensore di prossimità, deve avere 1 bit di precisione o più.

7.4. Connettività dati

7.4.1. Telefonia

"Telefonia" utilizzata dalle API Android 4.2 e questo documento si riferisce specificamente all'hardware relativo alla posizione delle chiamate vocali e all'invio di messaggi SMS tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano essere o meno a commutazione dei pacchetti, sono ai fini di Android 4.2 considerati indipendenti da qualsiasi connettività di dati che può essere implementata utilizzando la stessa rete. In altre parole, la funzionalità di "telefonia" Android e le API si riferiscono specificamente a chiamate vocali e SMS; Ad esempio, le implementazioni del dispositivo che non possono effettuare chiamate o inviare/ricevere i messaggi SMS non devono segnalare la funzione "Android.hardware.telephony" o eventuali sotto-feature, indipendentemente dal fatto che utilizzino una rete cellulare per la connettività dei dati.

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

7.4.2. IEEE 802.11 (Wi-Fi)

Le implementazioni di dispositivi Android 4.2 dovrebbero includere il supporto per una o più forme di 802.11 (B/G/A/N, ecc.) Se un'implementazione del dispositivo include il supporto per 802.11, deve implementare l'API Android corrispondente.

Le implementazioni del dispositivo devono implementare l'API multicast come descritto nella documentazione SDK [ Risorse, 62 ]. Le implementazioni del dispositivo che includono il supporto WiFi devono supportare DNS multicast (MDN). Le implementazioni del dispositivo non devono filtrare i pacchetti MDNS (224.0.0.251) in qualsiasi momento dell'operazione, incluso quando lo schermo non è in uno stato attivo.

7.4.2.1. Wi-Fi diretto

Le implementazioni del dispositivo dovrebbero includere il supporto per WiFi Direct (WiFi peer-to-peer). Se un'implementazione del dispositivo include il supporto per WiFi Direct, deve implementare l'API Android corrispondente come descritto nella documentazione SDK [ risorse, 68 ]. Se un'implementazione di un dispositivo include il supporto per WiFi Direct, allora:

Deve supportare il normale funzionamento WiFi
Dovrebbe supportare operazioni dirette WiFi e WiFi simultanee

7.4.3. Bluetooth

Le implementazioni del dispositivo dovrebbero includere un ricetrasmettitore Bluetooth. Le implementazioni del dispositivo che includono un ricetrasmettitore Bluetooth devono abilitare l'API Bluetooth basata su RFCOMM come descritto nella documentazione SDK [ Risorse, 42 ]. 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.

7.4.4. Comunicazioni a campo vicino

Le implementazioni del dispositivo dovrebbero includere un ricetrasmettitore e un hardware correlato per le comunicazioni a campo vicino (NFC). Se un'implementazione del dispositivo include hardware NFC, allora:

Deve segnalare la funzione Android.hardware.nfc da android.content.pm.PackageManager.hasSystemFeature() . [ Risorse, 37 ]
Deve essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC:
- Deve essere in grado di agire come lettore/scrittore del forum NFC (come definito dalla specifica tecnica del forum NFC NFCFORUM-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
  - NFCA (ISO14443-3A)
  - NFCB (ISO14443-3B)
  - NFCF (JIS 6319-4)
  - ISODEP (ISO 14443-4)
  - Tipi di tag del forum NFC 1, 2, 3, 4 (definito dal forum NFC)
Dovrebbe essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC. Si noti che mentre gli standard NFC di seguito sono indicati come "dovrebbero" per Android 4.2, è prevista la definizione di compatibilità per una versione futura per modificarli in "must". Cioè, questi standard sono opzionali in Android 4.2 ma saranno richiesti nelle versioni future. I dispositivi esistenti e nuovi che gestiscono Android 4.2 sono fortemente incoraggiati a soddisfare questi requisiti in Android 4.2 in modo da poter passare alle future versioni della piattaforma.
- NFCV (ISO 15693)
Deve essere in grado di trasmettere e ricevere dati tramite i seguenti standard e protocolli peer-to-peer:
- ISO 18092
- LLCP 1.0 (definito dal forum NFC)
- SDP 1.0 (definito dal forum NFC)
- NDEF Push Protocol [ Risorse, 43 ]
- SNEP 1.0 (definito dal forum NFC)
Deve includere il supporto per Android Beam [ Risorse, 65 ]:
- Deve implementare il server predefinito SNEP. I messaggi NDEF validi ricevuti dal server SNEP predefinito devono essere inviati alle applicazioni utilizzando Android.nfc.action_ndef_discover Intent. La disabilitazione del raggio Android nelle impostazioni non deve disabilitare la spedizione del messaggio NDEF in arrivo.
- Le implementazioni del dispositivo devono onorare Android.settings.nfcsharing_settings intenzione di mostrare le impostazioni di condivisione NFC [ risorse, 67 ].
- Deve implementare il server NPP. I messaggi ricevuti dal server NPP devono essere elaborati allo stesso modo del server predefinito SNEP.
- Deve implementare un client SNEP e tentare di inviare P2P NDEF in uscita al server SNEP predefinito quando il raggio Android è abilitato. Se non viene trovato alcun server SNEP predefinito, il client deve tentare di inviare a un server NPP.
- Devono consentire alle attività in primo piano di impostare il messaggio P2P NDEF in uscita utilizzando Android.nfc.nfcadapter.setndefpushmessage e Android.nfc.nfcadapter.setNdefpushmessagallback e Android.nfc.nfcadapter.enableforegroundnefpush.
- Dovrebbe utilizzare un gesto o una conferma sullo schermo, come "Touch to Beam", prima di inviare messaggi NDEF P2P in uscita.
- Dovrebbe abilitare il raggio Android per impostazione predefinita
- È necessario supportare la consegna della connessione NFC a Bluetooth quando il dispositivo supporta il profilo di spinta dell'oggetto Bluetooth. Le implementazioni del dispositivo devono supportare la consegna di connessioni a Bluetooth quando si utilizza Android.nfc.nfcadapter.setbeampushuris, implementando le specifiche di consegna "[ risorse, 60 ] e" Bluetooth Secure utilizzando NFC versione 1.0 "[ risorse, 61 ] da specifiche da Il forum NFC. Tale implementazione dovrebbe utilizzare le richieste SNEP GET per lo scambio della richiesta di consegna / selezionare i record su NFC e deve utilizzare il profilo di spinta dell'oggetto Bluetooth per il trasferimento di dati Bluetooth effettivo.
Deve sondaggio per tutte le tecnologie supportate durante la modalità di scoperta NFC.
Dovrebbe essere in modalità NFC Discovery mentre il dispositivo è sveglio con lo schermo attivo e lo schermo di blocco sbloccato.

(Si noti che i collegamenti disponibili al pubblico non sono disponibili per le specifiche del forum JIS, ISO e NFC citate sopra.)

Inoltre, le implementazioni del dispositivo possono includere il supporto del lettore/scrittore per le seguenti tecnologie Mifare.

Mifare Classic (NXP MF1S503X [ Risorse, 44 ], MF1S703X [ Risorse, 44 ])
Mifare UltraLight (NXP MF0ICU1 [ Risorse, 46 ], MF0ICU2 [ Risorse, 46 ])
NDEF su Mifare Classic (NXP AN130511 [ Risorse, 48 ], AN130411 [ Risorse, 49 ])

Si noti che Android 4.2 include API per questi tipi di mifare. Se un'implementazione del dispositivo supporta Mifare nel ruolo del lettore/scrittore, IT:

Deve implementare le API Android corrispondenti come documentato dall'SDK Android
Deve segnalare il metodo com.nxp.mifare da android.content.pm.PackageManager.hasSystemFeature() . [ Resources, 37 ] Notare che questa non è una funzione Android standard e come tale non appare come una costante nella classe PackageManager .
Non deve implementare le API Android corrispondenti né segnalare la funzione com.nxp.mifare a meno che non implementa anche il supporto NFC generale come descritto in questa sezione

Se un'implementazione del dispositivo non include hardware NFC, non deve dichiarare la funzione Android.hardware.nfc da android.content.pm.PackageManager.hasSystemFeature() metodo [ Risorse, 37 ] e deve implementare l'API Android 4.2 NFC come una no-op.

Mentre le classi android.nfc.NdefMessage e android.nfc.NdefRecord rappresentano un formato di rappresentazione dei dati indipendente dal protocollo, le implementazioni del dispositivo devono implementare queste API anche se non includono il supporto per NFC o dichiarare la funzione Android.hardware.nfc.

7.4.5. Capacità di rete minima

Le implementazioni del dispositivo devono includere il supporto per una o più forme di reti di dati. In particolare, le implementazioni del dispositivo devono includere il supporto per almeno uno standard di dati in grado di 200 kbit/sec o superiore. Esempi di tecnologie che soddisfano questo requisito includono Edge, HSPA, EV-DO, 802.11g, Ethernet, ecc.

Le implementazioni del dispositivo in cui uno standard di networking fisico (come Ethernet) è la connessione dati primaria dovrebbe includere anche il supporto per almeno uno standard di dati wireless comune, come 802.11 (WIFI).

I dispositivi possono implementare più di una forma di connettività dei dati.

7.5. Macchine fotografiche

Le implementazioni del dispositivo dovrebbero includere una fotocamera posteriore e possono includere una fotocamera frontale. Una fotocamera posteriore è una fotocamera situata sul lato del dispositivo di fronte al display; Cioè, immagini scene sul lato opposto del dispositivo, come una fotocamera tradizionale. Una fotocamera frontale è una fotocamera situata sullo stesso lato del dispositivo del display; Cioè, una fotocamera in genere utilizzata per immaginare l'utente, ad esempio per le videoconferenze e applicazioni simili.

7.5.1. Fotocamera posteriore

Le implementazioni del dispositivo dovrebbero includere una fotocamera posteriore. Se un'implementazione del dispositivo include una fotocamera posteriore, IT:

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 .

7.5.2. Fotocamera frontale

Le implementazioni del dispositivo POSSONO includere una fotocamera frontale. Se un'implementazione del dispositivo include una fotocamera frontale, IT:

Deve avere una risoluzione di almeno VGA (cioè 640x480 pixel)
Non deve utilizzare una fotocamera frontale come impostazione predefinita per l'API della fotocamera. Cioè, l'API della fotocamera in Android 4.2 ha un supporto specifico per le telecamere frontali e le implementazioni del dispositivo non devono configurare l'API per trattare una fotocamera frontale come fotocamera posteriore predefinita, anche se è l'unica fotocamera accesa il dispositivo.
Possono includere funzionalità (come auto-focus, flash, ecc.) Disponibili per le telecamere posteriori come descritto nella Sezione 7.5.1.
Deve riflettere orizzontalmente (cioè mirror) il flusso visualizzato da un'app in una CameraPreview, come segue:

Se l'implementazione del dispositivo è in grado di essere ruotata dall'utente (come automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente), l'anteprima della fotocamera deve essere specchiata in orizzontale rispetto all'orientamento corrente del dispositivo.
Se l'applicazione corrente ha esplicitamente richiesto che il display della fotocamera venga ruotato tramite una chiamata a android.hardware.Camera.setDisplayOrientation() [ Risorse, 50 ], l'anteprima della fotocamera deve essere rispecchiata in orizzontale rispetto all'orientamento specificato dall'applicazione.
Altrimenti, l'anteprima deve essere rispecchiata lungo l'asse orizzontale predefinito del dispositivo.

Deve rispecchiare l'immagine visualizzata dal postview allo stesso modo del flusso di immagini di anteprima della fotocamera. (Se l'implementazione del dispositivo non supporta PostView, questo requisito ovviamente non si applica.)
Non deve rispecchiare i flussi di immagini fisse o video catturate finali restituite ai callback dell'applicazione o impegnati per l'archiviazione multimediale

7.5.3. Comportamento dell'API della fotocamera

Le implementazioni del dispositivo devono implementare i seguenti comportamenti per le API relative alla fotocamera, per le telecamere sia frontali che posteriori:

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. Cioè, Nv21 deve essere l'impostazione predefinita.
Le implementazioni del dispositivo devono supportare il formato YV12 (come indicato da android.graphics.ImageFormat.YV12 COSTANT) per le anteprime della fotocamera per le telecamere frontali e posteriori. (L'encoder e la fotocamera video hardware possono utilizzare qualsiasi formato pixel nativo, ma l'implementazione del dispositivo deve supportare la conversione in YV12.)

Le implementazioni del dispositivo devono implementare l'API della fotocamera completa inclusa nella documentazione SDK Android 4.2 [ Risorse, 51 ]), 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.) Si noti che ciò si applica alle telecamere frontali; Ad esempio, anche se la maggior parte delle telecamere frontali non supporta l'autofocus, i callback API devono comunque essere "falsi" come descritto.

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. Ad esempio, le implementazioni del dispositivo che supportano l'acquisizione di immagini utilizzando le tecniche di imaging ad alta gamma dinamica (HDR) devono supportare la fotocamera dei parametri Camera.SCENE_MODE_HDR [ Resources, 78 ]).

Le implementazioni del dispositivo devono trasmettere la Camera.ACTION_NEW_PICTURE intenti ogni volta che viene scattata una nuova immagine dalla fotocamera e l'ingresso dell'immagine è stata aggiunta al negozio di media.

Le implementazioni del dispositivo devono trasmettere la Camera.ACTION_NEW_VIDEO intenti ogni volta che un nuovo video viene registrato dalla fotocamera e l'ingresso dell'immagine è stato aggiunto al negozio di media.

7.5.4. Orientamento della fotocamera

Entrambe le telecamere frontali e posteriori, se presenti, devono essere orientate in modo che la lunga dimensione della fotocamera si allinei con la lunga dimensione dello schermo. Cioè, quando il dispositivo viene tenuto nell'orientamento del paesaggio, le telecamere devono catturare immagini nell'orientamento del paesaggio. Questo vale indipendentemente dall'orientamento naturale del dispositivo; Cioè, si applica ai dispositivi del paesaggio-primario e ai dispositivi di pre-ritratto.

7.6. Memoria e archiviazione

7.6.1. Memoria e archiviazione minime

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

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

Le API Android includono un gestore del download che le applicazioni possono utilizzare per scaricare file di dati [ risorse, 56 ]. L'implementazione del dispositivo di Download Manager deve essere in grado di scaricare singoli file di almeno 100 MB nella posizione predefinita "cache".

7.6.2. Archiviazione condivisa dell'applicazione

Le implementazioni dei dispositivi DEVONO offrire spazio di archiviazione condiviso per le applicazioni. L'archiviazione condivisa fornita deve avere dimensioni di almeno 1 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, le implementazioni del dispositivo devono fornire alcuni meccanismi per accedere ai contenuti di archiviazione condivisa da un computer host, come l'archiviazione di massa USB (UMS) o il protocollo di trasferimento multimediale (MTP). Le implementazioni del dispositivo possono utilizzare l'archiviazione di massa USB, ma dovrebbero utilizzare il protocollo di trasferimento multimediale. Se l'implementazione del dispositivo supporta il protocollo di trasferimento multimediale:

L'implementazione del dispositivo dovrebbe essere compatibile con l'host Android MTP di riferimento, il trasferimento di file Android [ risorse, 57 ].
L'implementazione del dispositivo dovrebbe segnalare una classe di dispositivi USB di 0x00 .
L'implementazione del dispositivo dovrebbe segnalare un nome di interfaccia USB di "MTP".

Se l'implementazione del dispositivo manca di porte USB, deve fornire un computer host l'accesso al contenuto di archiviazione condivisa con alcuni altri mezzi, come un file system di rete.

È 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 1 GB di dimensioni o più grande 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 1 GB o più grande e montata su /sdcard (o /sdcard deve essere un collegamento simbolico alla posizione fisica se è montata 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.

7.7. USB

Le implementazioni del dispositivo dovrebbero includere una porta client USB e dovrebbero includere una porta host USB.

Se un'implementazione del dispositivo include una porta client USB:

La porta deve essere collegabile a un host USB con una porta USB-A standard
La porta dovrebbe utilizzare il fattore di forma Micro USB sul lato del dispositivo. I dispositivi esistenti e nuovi che gestiscono Android 4.2 sono fortemente incoraggiati a soddisfare questi requisiti in Android 4.2 in modo che siano in grado di aggiornare le versioni future della piattaforma
La porta dovrebbe essere centrata nel mezzo di un bordo. Le implementazioni del dispositivo dovrebbero individuare la porta nella parte inferiore del dispositivo (secondo l'orientamento naturale) o abilitare la rotazione della schermata del software per tutte le app (inclusa la schermata principale), in modo che il display si disegna correttamente quando il dispositivo è orientato con la porta in basso. I dispositivi esistenti e nuovi che gestiscono Android 4.2 sono fortemente incoraggiati a soddisfare questi requisiti in Android 4.2 in modo da poter passare a future versioni della piattaforma.
Se il dispositivo ha altre porte (come una porta di ricarica non USB), dovrebbe essere sullo stesso bordo della porta micro-USB
Deve consentire a un host collegato al dispositivo di accedere ai contenuti del volume di archiviazione condiviso utilizzando l'archiviazione di massa USB o il protocollo di trasferimento multimediale
Deve implementare l'API Accessorio aperto Android e le specifiche come documentato nella documentazione SDK Android e deve dichiarare il supporto alla funzione hardware android.hardware.usb.accessory [ Risorse, 52 ]
Deve implementare la classe audio USB come documentato nella documentazione SDK Android [ Risorse, 66 ]
Dovrebbe implementare il supporto per le specifiche di ricarica della batteria USB [ risorse, 64 ] dispositivi esistenti e nuovi che gestiscono Android 4.2 sono fortemente incoraggiati a soddisfare questi requisiti in Android 4.2 in modo che possano passare alle versioni future della piattaforma

Se un'implementazione del dispositivo include una porta host USB:

Può utilizzare un fattore di forma di porta non standard, ma in tal caso deve essere spedito con un cavo o cavi che adattano la porta alla USB-A standard
Deve implementare l'API host USB Android come documentato nell'SDK Android e deve dichiarare il supporto alla funzione hardware android.hardware.usb.host [ Risorse, 53 ]

Le implementazioni del dispositivo devono implementare Android Debug Bridge. If a device implementation omits a USB client port, it MUST implement the Android Debug Bridge via local-area network (such as Ethernet or 802.11)

8. Compatibilità delle prestazioni

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

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 Contacts: less than 700ms Settings: less than 700ms	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.

9. Compatibilità del modello di sicurezza

Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 54 ] in the Android developer documentation. 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.

9.1. Autorizzazioni

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 54 ]. 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.

9.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. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 54 ].

9.3. Autorizzazioni del file system

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

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

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

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.)
Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
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
Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

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.

9.5. Supporto multiutente

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

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

As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]

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

9.6. Premium SMS Warning

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

10. Test di compatibilità del software

Device implementations MUST pass all tests described in this section.

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

10.1. Suite 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. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.2. Le implementazioni del dispositivo devono passare l'ultima versione CTS disponibile al momento del completamento del software del dispositivo.

10.2. Verificatore CTS

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

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

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

10.3. Applicazioni di riferimento

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

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

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

11. Software aggiornabile

Le implementazioni del dispositivo devono includere un meccanismo per sostituire l'intero software di sistema. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

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. That is, the update mechanism MUST preserve application private data and application shared data. Si noti che il software Android a monte include un meccanismo di aggiornamento che soddisfa questo requisito.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software Aggiornamento disponibile che può essere applicato per il meccanismo appena descritto.

12. 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 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. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

The test procedure is based on the BluetoothChat sample app included in the Android open source project tree. La procedura richiede due dispositivi:

Un'implementazione del dispositivo candidato che esegue la build del software da testare
a separate device implementation already known to be compatible, and of a model from the device implementation being tested - that is, a "known good" device implementation

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

Installazione e installazione

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

Test Bluetooth Control da parte delle app

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

Test di accoppiamento e comunicazione

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

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.