Compatibility Definition Document di Android 4.0

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Revisione 4
Ultimo aggiornamento: 21 aprile 2013

Copyright © 2012, Google Inc. Tutti i diritti riservati.
compatibility@android.com

Indice

1. Introduzione

Questo documento elenca i requisiti che devono essere soddisfatti affinché i dispositivi siano compatibili con Android 4.0.

L'uso di "deve", "non deve", "obbligatorio", "deve", "non deve", "deve", "non deve", "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 sistema operativo Android 4.0. Un'"implementazione del dispositivo" o "implementazione" è la soluzione hardware/software così sviluppata.

Per essere considerate compatibili con Android 4.0, le implementazioni dei dispositivi devono soddisfare i requisiti presentati in questa definizione di compatibilità, inclusi eventuali documenti incorporati tramite riferimento.

Se questa definizione o i test software descritti nella Sezione 10 non sono chiari, ambigui o incompleti, è compito dell'implementatore del dispositivo garantire la compatibilità con le implementazioni esistenti.

Per questo motivo, Android Open Source Project [Risorse, 3] è sia l'implementazione di riferimento sia quella preferita di Android. Gli implementatori di dispositivi sono vivamente incoraggiati a basare le proprie implementazioni, nella misura del possibile, sul codice sorgente "upstream" disponibile nell'Android Open Source Project. Sebbene alcuni componenti possano essere ipotetticamente sostituiti con implementazioni alternative, questa pratica è fortemente sconsigliata, in quanto superare i test software diventerà notevolmente più difficile. È responsabilità dell'implementatore garantire la piena compatibilità di comportamento con l'implementazione standard di Android, inclusa e oltre la Compatibility Test Suite. Infine, tieni presente che alcune sostituzione e modifiche dei componenti sono esplicitamente vietate da questo documento.

2. Risorse

1. Livelli di requisiti RFC2119 IETF: http://www.ietf.org/rfc/rfc2119.txt
2. Panoramica del Programma di compatibilità Android: http://source.android.com/docs/compatibility/index.html
3. Android Open Source Project: http://source.android.com/
4. Definizioni e documentazione dell'API: http://developer.android.com/reference/packages.html
5. Documentazione di riferimento per le autorizzazioni Android: http://developer.android.com/reference/android/Manifest.permission.html
6. Riferimento android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. Stringhe di versione consentite per Android 4.0: http://source.android.com/docs/compatibility/4.0/versions.html
8. Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html
9. Accelerazione hardware: http://developer.android.com/guide/topics/graphics/hardware-accel.html
10. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12. Funzionalità offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13. Tag video HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14. API Geolocation HTML5/W3C: http://www.w3.org/TR/geolocation-API/
15. API webdatabase HTML5/W3C: http://www.w3.org/TR/webdatabase/
16. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
17. Specifiche della macchina virtuale Dalvik: disponibili nel codice sorgente di Android, in dalvik/docs
18. AppWidget: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19. Notifiche: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20. Risorse per le applicazioni: http://code.google.com/android/reference/available-resources.html
21. Guida di stile per le icone della barra di stato: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
22. Gestione ricerche: http://developer.android.com/reference/android/app/SearchManager.html
23. Messaggi popup: http://developer.android.com/reference/android/widget/Toast.html
24. Temi: http://developer.android.com/guide/topics/ui/themes.html
25. Classe R.style: http://developer.android.com/reference/android/R.style.html
26. Sfondi animati: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
27. Amministrazione dispositivo Android: http://developer.android.com/guide/topics/admin/device-admin.html
28. Classe android.app.admin.DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29. API Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/package-summary.html
30. API Android Accessibility: http://developer.android.com/reference/android/view/accessibility/package-summary.html
31. Progetto Eyes Free: http://code.google.com/p/eyes-free
32. API Text-to-Speech: http://developer.android.com/reference/android/speech/tts/package-summary.html
33. Documentazione dello strumento di riferimento (per adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
34. Descrizione del file APK Android: http://developer.android.com/guide/topics/fundamentals.html
35. File manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html
36. Strumento di test Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
37. Classe android.content.pm.PackageManager di Android e elenco delle funzionalità hardware: http://developer.android.com/reference/android/content/pm/PackageManager.html
38. Supporto di più schermi: http://developer.android.com/guide/practices/screens_support.html
39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
40. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
41. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
42. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html
43. Protocollo NDEF Push: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
49. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
50. API di orientamento della fotocamera: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
52. Android Open Accessories: http://developer.android.com/guide/topics/usb/accessory.html
53. API host USB: http://developer.android.com/guide/topics/usb/host.html
54. Documentazione di riferimento per la sicurezza e le autorizzazioni di Android: http://developer.android.com/guide/topics/security/security.html
55. App per Android: http://code.google.com/p/apps-for-android
56. Classe android.app.DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html
57. Android File Transfer: http://www.android.com/filetransfer
58. Formati multimediali Android: http://developer.android.com/guide/appendix/media-formats.html
59. Protocollo HTTP Live Streaming in versione preliminare: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
60. API Motion Event: http://developer.android.com/reference/android/view/MotionEvent.html
61. Configurazione dell'input tocco: http://source.android.com/tech/input/touch-devices.html

Molte di queste risorse sono ricavate direttamente o indirettamente dall'SDK Android 4.0 e saranno funzionalmente identiche alle informazioni riportate nella documentazione dell'SDK. In tutti i casi in cui questa definizione di compatibilità o la Compatibility Test Suite non è in accordo con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Eventuali dettagli tecnici forniti nei riferimenti inclusi sopra sono considerati parte di questa Definizione di compatibilità.

3. Software

3.1. Compatibilità con le API gestite

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

Le implementazioni dei dispositivi NON DEVONO omettere API gestite, alterare le interfacce o le firme delle API, discostarsi dal comportamento documentato o includere no-op, tranne dove specificamente consentito da questa definizione di compatibilità.

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

3.2. Compatibilità API soft

Oltre alle API gestite della sezione 3.1, Android include anche un'API "soft" significativa solo in fase di runtime, sotto forma di elementi quali Intent, autorizzazioni e aspetti simili delle applicazioni Android che non possono essere applicati al momento della compilazione dell'applicazione.

3.2.1. Autorizzazioni

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

3.2.2. Parametri di compilazione

Le API Android includono una serie di costanti nella classe android.os.Build [Resources, 6] destinate a descrivere il dispositivo corrente. Per fornire valori coerenti e significativi per tutte le implementazioni dei dispositivi, la tabella seguente include ulteriori limitazioni relative ai formati di questi valori a cui le implementazioni dei dispositivi DEVONO essere conformi.

Parametro	Commenti
android.os.Build.VERSION.RELEASE	La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE avere uno dei valori di 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.0.1 - 4.0.2, questo campo DEVE avere il valore intero 14. Per Android 4.0.3 o versioni successive, questo campo deve avere il valore intero 15.
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.0.1 - 4.0.2, questo campo DEVE avere il valore intero 14. Per Android 4.0.3 o versioni successive, questo campo deve avere il valore intero 15.
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. Questo valore NON DEVE essere riutilizzato per build diverse rese disponibili agli utenti finali. Un utilizzo tipico di questo campo è indicare il numero di build o l'identificatore della modifica del controllo del codice sorgente utilizzato per generare la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la 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. Un possibile utilizzo di questo campo è 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 della società, dell'organizzazione, della persona fisica e così via che ha prodotto il dispositivo in formato leggibile. Un possibile utilizzo di questo campo è indicare l'OEM e/o l'operatore 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 dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3: Compatibilità con le API native.
android.os.Build.CPU_ABI2	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3: Compatibilità con le API native.
android.os.Build.DEVICE	Un valore scelto dall'implementatore del dispositivo che identifica la configurazione o la revisione specifica della cassa (a volte chiamata "design industriale") del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e deve corrispondere all'espressione regolare "^[a-zA-Z0-9.,_-]+$".
android.os.Build.FINGERPRINT	Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile da una persona. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ad esempio: acme/mydevice/generic:4.0/IRK77/3359:userdebug/test-keys L'impronta NON DEVE includere caratteri di spazio. Se altri campi inclusi nel templato riportato sopra contengono spazi vuoti, DEVONO essere sostituiti nel fingerprinting della build con un altro carattere, ad esempio il trattino basso ("_"). 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 da /proc). DOVREBBE essere ragionevolmente leggibile da una persona. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e deve corrispondere all'espressione regolare "^[a-zA-Z0-9.,_-]+$".
android.os.Build.HOST	Una stringa che identifica in modo univoco l'host su cui è stata eseguita la compilazione, in formato leggibile da persone. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
android.os.Build.ID	Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in un formato leggibile da una persona. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere le build 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	La ragione sociale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
android.os.Build.MODEL	Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo come noto all'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo 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, ma non necessariamente pensato per essere visualizzato dagli 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 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 separato da virgole di tag scelti dall'implementatore del dispositivo che contraddistinguono 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 della compilazione.
android.os.Build.TYPE	Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondente alle tre configurazioni di runtime Android standard: "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 automatico) che ha generato la compilazione. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON DEVE essere nullo o la stringa vuota ("").

3.2.3. Compatibilità con gli intent

Le implementazioni dei dispositivi DEVONO rispettare il sistema di intent a disaccoppiamento flessibile di Android, come descritto nelle sezioni seguenti. Per "rispettato" si intende che l'implementatore del dispositivo DEVE fornire un'attività o un servizio Android che specifichi un filtro per intent corrispondente e che si leghi e implementi il comportamento corretto per ogni pattern di intent specificato.

3.2.3.1. Intent di applicazione principali

Il progetto upstream di Android definisce una serie di applicazioni di base, come i contatti, il calendario, la galleria fotografica, il music player e così via. Gli implementatori dei dispositivi POSSONO sostituire queste applicazioni con versioni alternative.

Tuttavia, queste versioni alternative DEVONO rispettare gli stessi pattern di intenti forniti dal progetto a monte. Ad esempio, se un dispositivo contiene un lettore musicale alternativo, deve comunque rispettare il pattern Intent emesso da app di terze parti per scegliere un brano.

Le seguenti applicazioni sono considerate applicazioni di sistema Android di base:

• Orologio da scrivania
• Browser
• Calendar
• Contatti
• Galleria
• GlobalSearch
• Avvio app
• Musica
• Impostazioni

Le applicazioni di sistema Android di base includono vari componenti Activity o Service considerati "pubblici". In altre parole, l'attributo "android:exported" può essere assente o avere il valore "true".

Per ogni attività o servizio definito in una delle app di sistema Android di base che non è contrassegnata come non pubblica tramite un attributo android:exported con il valore "false", le implementazioni del dispositivo DEVONO includere un componente dello stesso tipo che implementa gli stessi pattern di filtro per intent dell'app di sistema Android di base.

In altre parole, un'implementazione del dispositivo PUÒ sostituire le app di sistema Android di base. Tuttavia, in questo caso, l'implementazione del dispositivo DEVE supportare tutti i pattern Intent definiti da ogni app di sistema Android di base sostituita.

3.2.3.2. Sostituzioni di intent

Poiché Android è una piattaforma estensibile, le implementazioni dei dispositivi DEVONO consentire a ogni pattern di intent a cui si fa riferimento nella Sezione 3.2.3.2 di essere sostituito da applicazioni di terze parti. L'implementazione open source di Android upstream lo consente per impostazione predefinita. Gli implementatori dei dispositivi NON DEVONO associare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema o impedire alle applicazioni di terze parti di associarsi a questi pattern e assumerne il controllo. Questo divieto include, a titolo esemplificativo, la disattivazione dell'interfaccia utente "Chooser" che consente all'utente di scegliere tra più applicazioni che gestiscono tutte lo stesso pattern di intent.

3.2.3.3. Spazi dei nomi degli intent

Le implementazioni dei dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando una stringa ACTION, CATEGORY o di altro tipo nello spazio dei nomi android.* o com.android.*. Gli implementatori di dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione che utilizzano ACTION, CATEGORY o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione. Gli implementatori dei dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent utilizzati dalle app di base elencate nella sezione 3.2.3.1. Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano spazi dei nomi chiaramente e inequivocabilmente associati alla propria organizzazione.

Questo divieto è analogo a quello specificato per le classi di lingua Java nella Sezione 3.6.

3.2.3.4. Intent di trasmissione

Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent per informarle delle modifiche nell'ambiente hardware o software. I dispositivi compatibili con Android DEVONO trasmettere gli intent di trasmissione pubblica in risposta a eventi di sistema appropriati. Gli intent di trasmissione sono descritti nella documentazione dell'SDK.

3.3. Compatibilità con le API native

3.3.1 Interfacce a livello di codice dell'applicazione

Il codice gestito in esecuzione in Dalvik può chiamare il codice nativo fornito nel file .apk dell'applicazione come file .so ELF compilato per l'architettura hardware del dispositivo appropriata. Poiché il codice nativo è altamente dipendente dalla tecnologia del processore di base, Android definisce una serie di interfacce ABI (Application Binary Interface) nell'NDK di Android, nel filedocs/CPU-ARCH-ABIS.txt. Se un'implementazione del dispositivo è compatibile con uno o più ABI definiti, DEVE implementare la compatibilità con Android NDK, come indicato di seguito.

Se un'implementazione del dispositivo include il supporto di un'ABI Android:

• DEVE includere il supporto per il codice in esecuzione nell'ambiente gestito per chiamare il codice nativo utilizzando la semantica standard dell'interfaccia nativa Java (JNI).
• DEVE essere compatibile con il codice sorgente (ovvero con le intestazioni) e con i file binari (per l'ABI) di ogni libreria richiesta nell'elenco di seguito
• DEVE segnalare con precisione l'ABI (Application Binary Interface) nativa supportata dal dispositivo tramite l'API android.os.Build.CPU_ABI.
• DEVE segnalare solo le ABI documentate nell'ultima versione di Android NDK, nel file docs/CPU-ARCH-ABIS.txt
• DEVE essere compilato utilizzando il codice sorgente e i file di intestazione disponibili nel progetto open source Android di origine

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 (logging Android)
• libz (compressione Zlib)
• libdl (linker dinamico)
• libGLESv1_CM.so (OpenGL ES 1.0)
• libGLESv2.so (OpenGL ES 2.0)
• libEGL.so (gestione delle superfici OpenGL native)
• libjnigraphics.so
• libOpenSLES.so (supporto audio OpenSL ES 1.0.1)
• libOpenMAXAL.so (supporto di OpenMAX AL 1.0.1)
• libandroid.so (supporto delle attività native di Android)
• Supporto di OpenGL, come descritto di seguito

Tieni presente che le release future dell'Android NDK potrebbero introdurre il supporto di ABI aggiuntive. Se un'implementazione del dispositivo non è compatibile con un ABI predefinito esistente, NON DEVE segnalare il supporto per alcun ABI.

La compatibilità con il codice nativo è complessa. Per questo motivo, è necessario ripetere che gli implementatori di dispositivi sono MOLTO vivamente incoraggiati a utilizzare le implementazioni a monte delle librerie sopra elencate per contribuire a garantire la compatibilità.

3.4. Compatibilità web

3.4.1. Compatibilità con WebView

L'implementazione di 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 dei dispositivi DEVONO utilizzare la build upstream specifica di WebKit nell'implementazione di WebView. Nello specifico:

• Le implementazioni android.webkit.WebView del dispositivo DEVONO essere basate sulla build WebKit 534.30 del tree Android Open Source di upstream per Android 4.0. Questa build include un insieme specifico di funzionalità e correzioni di sicurezza per WebView. Gli implementatori dei dispositivi POSSONO includere personalizzazioni nell'implementazione di WebKit. Tuttavia, queste personalizzazioni NON DEVONO alterare il comportamento di WebView, incluso il comportamento di rendering.
• La stringa dello user agent segnalata da WebView DEVE essere nel seguente formato:
  Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 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) DEVE seguire le convenzioni ISO per il codice paese e la lingua e DEVE fare riferimento alle impostazioni internazionali attualmente configurate 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

Il componente WebView DEVE includere il supporto per il maggior numero possibile di funzionalità HTML5 [Risorse, 11]. Come minimo, le implementazioni dei dispositivi DEVONO supportare ciascuna di queste API associate a HTML5 in WebView:

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

Inoltre, le implementazioni dei dispositivi DEVONO supportare l'API webstorage HTML5/W3C [Risorse, 15] e DOVREBBERO supportare l'API IndexedDB HTML5/W3C [Risorse, 16]. Tieni conto che, poiché gli enti normativi per lo sviluppo web stanno adottando IndexedDB al posto di webstorage, IndexedDB dovrebbe diventare un componente obbligatorio in una versione futura di Android.

Le API HTML5, come tutte le API JavaScript, DEVONO essere disattivate per impostazione predefinita in un WebView, a meno che lo sviluppatore non le attivi esplicitamente tramite le consuete API Android.

3.4.2. Compatibilità del browser

Le implementazioni dei dispositivi DEVONO includere un'applicazione browser autonoma per la navigazione web degli utenti in generale. Il browser autonomo PUÒ essere basato su una tecnologia di 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 includere una stringa user agent personalizzata nell'applicazione browser autonoma.

L'applicazione Browser autonoma (in base all'applicazione Browser WebKit a monte o a una sostituzione di terze parti) DEVE includere il supporto per il maggior numero possibile di funzionalità HTML5 [Risorse, 11]. Come minimo, le implementazioni dei dispositivi DEVONO supportare ciascuna di queste API associate a HTML5:

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

Inoltre, le implementazioni dei dispositivi DEVONO supportare l'API webstorage HTML5/W3C [Risorse, 15] e DOVREBBERO supportare l'API IndexedDB HTML5/W3C [Risorse, 16]. Tieni conto che, poiché gli enti normativi per lo sviluppo web stanno adottando IndexedDB al posto di webstorage, IndexedDB dovrebbe diventare un componente obbligatorio in una versione futura di Android.

3.5. Compatibilità comportamentale dell'API

Il comportamento di ciascuno dei tipi di API (gestite, soft, native e web) deve essere coerente 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 uno scopo standard
• I dispositivi NON DEVONO alterare il ciclo di vita o la semantica del ciclo di vita di un determinato tipo di componente di sistema (ad esempio Service, Activity, ContentProvider e così via).
• I dispositivi NON DEVONO modificare la semantica di un'autorizzazione standard

L'elenco riportato sopra non è esaustivo. La Compatibility Test Suite (CTS) esamina parti significative della piattaforma per verificarne la compatibilità di comportamento, ma non tutte. È responsabilità dell'implementatore garantire la compatibilità di comportamento con il progetto open source Android. Per questo motivo, gli implementatori di dispositivi DEVONO utilizzare il codice sorgente disponibile tramite l'Android Open Source Project, ove possibile, anziché implementare nuovamente parti significative del sistema.

3.6. Spazi dei nomi API

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

• java.*
• javax.*
• sole.*
• android.*
• com.android.*

Le modifiche vietate includono:

• Le implementazioni dei dispositivi NON DEVONO modificare le API esposte pubblicamente sulla piattaforma Android modificando le firme di metodi o classi o rimuovendo classi o campi di classe.
• Gli implementatori dei dispositivi POSSONO modificare l'implementazione sottostante delle API, ma queste modifiche NON DEVONO influire sul comportamento dichiarato e sulla firma in linguaggio Java di qualsiasi API esposta pubblicamente.
• Gli implementatori dei dispositivi NON DEVONO aggiungere elementi esposti pubblicamente (ad esempio classi o interfacce oppure campi o metodi a classi o interfacce esistenti) alle API sopra indicate.

Un "elemento esposto pubblicamente" è qualsiasi costrutto non decorato con il marcatore "@hide" come utilizzato nel codice sorgente di Android upstream. In altre parole, gli implementatori dei dispositivi NON DEVONO esporre nuove API o modificare quelle esistenti nei spazi dei nomi sopra indicati. Gli implementatori dei dispositivi POSSONO apportare modifiche solo per uso interno, ma queste modifiche NON DEVONO essere pubblicizzate o comunque esposte agli sviluppatori.

Gli implementatori dei dispositivi POSSONO aggiungere API personalizzate, ma queste API NON DEVONO trovarsi in un ambito di nomi di proprietà di un'altra organizzazione o che fanno riferimento a un'altra organizzazione. Ad esempio, gli implementatori di dispositivi NON DEVONO aggiungere API al namespace com.google.* o a un namespace simile; solo Google può farlo. Analogamente, Google NON DEVE aggiungere API ai namespace di altre aziende. Inoltre, se un'implementazione del dispositivo include API personalizzate al di fuori del namespace Android standard, queste API DEVONO essere pacchettizzate in una libreria condivisa di 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 queste API.

Se un implementatore di dispositivi propone di migliorare uno dei namespace del pacchetto elencati sopra (ad esempio aggiungendo nuove funzionalità utili a un'API esistente o aggiungendo una nuova API), l'implementatore DEVE visitare il sito source.android.com e avviare la procedura per contribuire con modifiche e codice, in base alle informazioni riportate su quel sito.

Tieni presente che le limitazioni riportate sopra corrispondono alle convenzioni standard per la denominazione delle API nel linguaggio di programmazione Java. Lo scopo di questa sezione è semplicemente rafforzare queste convenzioni e renderle vincolanti tramite l'inclusione in questa definizione di compatibilità.

3.7. Compatibilità con le macchine virtuali

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

Le implementazioni dei dispositivi DEVONO configurare Dalvik per allocare la memoria in base alla piattaforma Android a monte e come specificato dalla tabella seguente. (consulta la Sezione 7.1.1 per le definizioni di dimensioni e densità dello schermo).

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

Dimensioni schermo	Densità dello schermo	Memoria dell'applicazione
small / normal / large	ldpi / mdpi	16MB
small / normal / large	tvdpi / hdpi	32MB
small / normal / large	xhdpi	64MB
xlarge	mdpi	32MB
xlarge	tvdpi / hdpi	64MB
xlarge	xhdpi	128MB

3.8. Compatibilità dell'interfaccia utente

3.8.1. Widget

Android definisce un tipo di componente e l'API e il ciclo di vita corrispondenti che consentono alle applicazioni di esporre un "AppWidget" all'utente finale [Resources, 18]. La release di riferimento di Android Open Source include un'applicazione Avvio app che include funzionalità dell'interfaccia utente che consentono all'utente di aggiungere, visualizzare e rimuovere AppWidget dalla schermata Home.

Le implementazioni del dispositivo POSSONO sostituire un'alternativa al launcher di riferimento (ovvero la schermata Home). I lanciatori alternativi DEVONO includere il supporto integrato per gli AppWidget e mettere a disposizione funzionalità dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere gli AppWidget direttamente all'interno del lanciatore. 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 lanciatore che consenta agli utenti di aggiungere, configurare, visualizzare e rimuovere gli AppWidget.

Le implementazioni dei dispositivi DEVONO essere in grado di eseguire il rendering di widget di dimensioni 4 x 4 nella dimensione della griglia standard. Per maggiori dettagli, consulta le linee guida per la progettazione di widget per app nella documentazione dell'SDK Android [Risorse, 18].

3.8.2. Notifiche

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

Alcune API consentono alle applicazioni di inviare notifiche o attirare l'attenzione utilizzando l'hardware, in particolare suono, vibrazione e luce. Le implementazioni dei dispositivi devono supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK e, nella misura del possibile, con l'hardware di implementazione del dispositivo. Ad esempio, se un'implementazione del dispositivo include un vibratore, deve implementare correttamente le API di vibrazione. Se l'implementazione di un dispositivo è priva di hardware, le API corrispondenti DEVONO essere implementate come no-op. Tieni presente che questo comportamento è descritto in modo più dettagliato nella sezione 7.

Inoltre, l'implementazione DEVE eseguire il rendering corretto di tutte le risorse (icone, file audio e così via) previste nelle API [Risorse, 20] o nella guida di stile delle icone della barra di stato/del sistema [Risorse, 21]. Gli implementatori dei dispositivi POSSONO fornire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'implementazione di riferimento di Android Open Source. Tuttavia, questi sistemi di notifica alternativi DEVONO supportare le risorse di notifica esistenti, come sopra indicato.

Android 4.0 include il supporto delle notifiche avanzate, ad esempio le visualizzazioni interattive per le notifiche in corso. Le implementazioni dei dispositivi DEVONO mostrare e eseguire correttamente le notifiche avanzate, come descritto nelle API Android.

3.8.3. Cerca

Android include API [Risorse, 22] che consentono agli sviluppatori di incorporare la ricerca nelle loro applicazioni ed esporre i dati delle applicazioni nella ricerca di sistema globale. In generale, questa funzionalità consiste in un'unica interfaccia utente a livello di sistema che consente agli utenti di inserire query, visualizzare suggerimenti man mano che digitano 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 della ricerca globale comune.

Le implementazioni dei dispositivi 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 dei dispositivi 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 mostrare i risultati e i suggerimenti del motore di ricerca web.

3.8.4. Auguri

Le applicazioni possono utilizzare l'API "Toast" (definita in [Risorse, 23]) per mostrare all'utente finale brevi stringhe non modali che scompaiono dopo un breve periodo di tempo. Le implementazioni dei dispositivi DEVONO mostrare le notifiche popup provenienti dalle applicazioni agli utenti finali in modo molto visibile.

3.8.5. Temi

Android fornisce i "temi" come meccanismo per consentire alle applicazioni di applicare stili a un'intera attività o applicazione. Android 3.0 ha introdotto un nuovo tema "Holo" o "olografico" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono avere lo stesso aspetto del tema Holo come definito dall'SDK Android [Risorse, 24]. Le implementazioni dei dispositivi NON DEVONO alterare nessuno degli attributi del tema Holo esposti alle applicazioni [Risorse, 25].

Android 4.0 introduce un nuovo tema "Predefinito del dispositivo" come insieme di stili definiti da utilizzare per gli sviluppatori di applicazioni che vogliono abbinare l'aspetto del tema del dispositivo come definito dall'implementatore del dispositivo. Le implementazioni dei dispositivi POSSONO modificare gli attributi del tema DeviceDefault esposti alle applicazioni [Resources, 25].

3.8.6. Sfondi animati

Android definisce un tipo di componente e 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 funzionalità di input limitate che vengono visualizzate come sfondo dietro altre applicazioni.

L'hardware è considerato in grado di eseguire in modo affidabile gli sfondi animati se può eseguire tutti gli sfondi animati, senza limitazioni alla funzionalità, a una frequenza frame ragionevole senza effetti negativi su altre applicazioni. Se le limitazioni dell'hardware causano arresti anomali di sfondi e/o applicazioni, malfunzionamenti, consumo eccessivo di CPU o batteria o funzionamento a frequenze fotogrammi inaccettabilmente basse, l'hardware è considerato incapace di eseguire lo sfondo animato. Ad esempio, alcuni sfondi animati potrebbero utilizzare un contesto Open GL 1.0 o 2.0 per eseguire il rendering dei contenuti. La funzionalità Sfondo animato non funziona in modo affidabile su hardware che non supporta più contesti OpenGL perché l'utilizzo di un contesto OpenGL da parte della funzionalità Sfondo animato potrebbe entrare in conflitto con altre applicazioni che utilizzano anche un contesto OpenGL.

Le implementazioni dei dispositivi in grado di eseguire in modo affidabile gli sfondi animati come descritto sopra DOVREBBERO implementare gli sfondi animati. Le implementazioni dei dispositivi che non eseguono gli sfondi animati in modo affidabile come descritto sopra NON DEVONO implementare gli sfondi animati.

3.8.7. Visualizzazione delle app recenti

Il codice sorgente upstream di Android 4.0 include un'interfaccia utente per la visualizzazione delle applicazioni recenti utilizzando un'immagine in miniatura dello stato grafico dell'applicazione al momento dell'ultima uscita dell'utente dall'applicazione. Le implementazioni dei dispositivi POTREBBERO modificare o eliminare questa interfaccia utente. Tuttavia, è prevista una versione futura di Android che farà un uso più esteso di questa funzionalità. Le implementazioni dei dispositivi sono vivamente incoraggiate a utilizzare l'interfaccia utente di Android 4.0 upstream (o un'interfaccia basata su miniature simile) per le applicazioni recenti, altrimenti potrebbero non essere compatibili con una futura versione di Android.

3.8.8. Impostazioni di gestione dell'input

Android 4.0 include il supporto per gli Input Management Engine. Le API Android 4.0 consentono agli IME delle app personalizzate di specificare impostazioni regolabili dall'utente. Le implementazioni del dispositivo DEVONO includere un modo per consentire all'utente di accedere alle impostazioni dell'IME in qualsiasi momento quando viene visualizzato un IME che fornisce queste impostazioni utente.

3.9 Amministrazione dispositivo

Android 4.0 include funzionalità che consentono alle applicazioni sensibili alla sicurezza di eseguire funzioni di amministrazione del dispositivo a livello di sistema, ad esempio l'applicazione di criteri per le password o l'esecuzione di un reset dei dati di fabbrica remoto, tramite l'API Android Device Administration [Risorse, 27]. Le implementazioni dei dispositivi DEVONO fornire un'implementazione della classe DevicePolicyManager [Resources, 28] e DOVREBBERO supportare l'intera gamma di criteri di amministrazione dei dispositivi definiti nella documentazione dell'SDK Android [Resources, 27].

Se le implementazioni dei dispositivi non supportano l'intera gamma di criteri di amministrazione del dispositivo, NON DEVONO consentire l'abilitazione delle applicazioni di amministrazione del dispositivo. Nello specifico, se un dispositivo non supporta tutti i criteri di amministrazione del dispositivo, l'implementazione del dispositivo DEVE rispondere all'intent android.app.admin.DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN, ma DEVE mostrare un messaggio che avvisa l'utente che il dispositivo non supporta l'amministrazione del dispositivo.

3.10 Accessibilità

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

• Le implementazioni dei dispositivi DEVONO supportare le implementazioni di servizi di accessibilità di terze parti tramite le API android.accessibilityservice [Risorse, 30].
• Le implementazioni dei dispositivi DEVONO generare AccessibilityEvent e inviare questi eventi a tutte le implementazioni di AccessibilityService registrate in modo coerente con l'implementazione predefinita di Android.
• Le implementazioni dei dispositivi DEVONO fornire un meccanismo accessibile all'utente per attivare e disattivare i servizi di accessibilità e DEVONO mostrare questa interfaccia in risposta all'intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

Inoltre, le implementazioni dei dispositivi DEVONO fornire un'implementazione di un servizio di accessibilità sul dispositivo e DEVONO fornire un meccanismo per consentire agli utenti di attivare il servizio di accessibilità durante la configurazione del dispositivo. Un'implementazione open source di un servizio di accessibilità è disponibile nel progetto EyesFree [Risorse, 31].

3.11 Sintesi vocale

Android 4.0 include API che consentono alle applicazioni di utilizzare i servizi di sintesi vocale (TTS) e ai fornitori di servizi di fornire implementazioni di questi servizi [Risorse, 32]. Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti relativi al framework Android TTS:

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

4. Compatibilità con il pacchettizzazione delle applicazioni

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

Le implementazioni dei dispositivi NON DEVONO estendere i file .apk [Risorse, 34], Android Manifest [Risorse, 35], bytecode Dalvik [Risorse, 17] o i formati bytecode di RenderScript in modo da impedire l'installazione e l'esecuzione corretta di questi file su altri dispositivi compatibili. Gli implementatori di dispositivi DEVONO utilizzare l'implementazione upstream di riferimento di Dalvik e il sistema di gestione dei pacchetti dell'implementazione di riferimento.

5. Compatibilità multimediale

Le implementazioni dei dispositivi DEVONO includere almeno una forma di uscita audio, ad esempio altoparlanti, jack per cuffie, connessione di altoparlanti esterni e così via.

5.1. Codec multimediali

Le implementazioni dei dispositivi DEVONO supportare i formati multimediali di base specificati nella documentazione dell'SDK Android [Risorse, 58], tranne ove consentito esplicitamente in questo documento. Nello specifico, le implementazioni dei dispositivi devono supportare i formati multimediali, gli encoder, i decodificatori, i tipi di file e i formati dei contenitori definiti nelle tabelle riportate di seguito. Tutti questi codec sono forniti come implementazioni software nell'implementazione Android preferita dell'Android Open Source Project.

Tieni presente che né Google né l'Open Handset Alliance dichiarano che questi codec sono esenti da brevetti di terze parti. Gli utenti che intendono utilizzare questo codice sorgente in prodotti hardware o software devono essere informati che le implementazioni di questo codice, incluso in software open source o shareware, potrebbero richiedere licenze di brevetto da parte dei relativi titolari.

Tieni presente che queste tabelle non elencano requisiti specifici per le larghezza di banda della maggior parte dei codec video perché l'hardware attuale dei dispositivi non supporta necessariamente larghezza di banda che corrispondono esattamente a quelle richieste specificate dagli standard pertinenti. Le implementazioni dei dispositivi DOVREBBERO supportare la massima velocità in bit possibile sull'hardware, fino ai limiti definiti dalle specifiche.

Digitazione	Formato / codec	Codificatore	Decoder	Dettagli	Tipi di file/formati contenitore
Audio	AAC LC/LTP	OBBLIGATORI Obbligatorio per le implementazioni dei dispositivi che includono hardware per microfono e definiscono android.hardware.microphone.	OBBLIGATORIO	Contenuti mono/stereo in qualsiasi combinazione di velocità in bit standard fino a 160 Kbps e frequenze di campionamento da 8 a 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC non compresso ADTS (.aac, decodifica in Android 3.1 e versioni successive, codifica in Android 4.0 e versioni successive, ADIF non supportato) MPEG-TS (.ts, non cercabile, Android 3.0 e versioni successive)
	HE-AACv1 (AAC+)		OBBLIGATORIO
	HE-AACv2 (AAC+ migliorato)		OBBLIGATORIO
	AMR-NB	OBBLIGATORI Obbligatorio per le implementazioni dei dispositivi che includono hardware per microfono e definiscono android.hardware.microphone.	OBBLIGATORIO	4,75-12,2 Kbps campionati a 8 kHz	3GPP (.3gp)
	AMR-WB	OBBLIGATORI Obbligatorio per le implementazioni dei dispositivi che includono hardware per microfono e definiscono android.hardware.microphone.	OBBLIGATORIO	9 frequenze da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz	3GPP (.3gp)
	FLAC		OBBLIGATORI (Android 3.1 e versioni successive)	Mono/stereo (nessun multicanale). Frequenze di campionamento fino a 48 kHz (ma fino a 44,1 kHz è consigliata sui dispositivi con uscita a 44,1 kHz, poiché il campionatore giù da 48 a 44,1 kHz non include un filtro passa basso). Consigliati 16 bit; non viene applicato il dither per 24 bit.	Solo FLAC (.flac)
	MP3		OBBLIGATORIO	Mono/stereo 8-320 Kbps a velocità in bit costante (CBR) o variabile (VBR)	MP3 (.mp3)
	MIDI		OBBLIGATORIO	Tipo MIDI 0 e 1. Versioni 1 e 2 di DLS. XMF e Mobile XMF. Supporto per i formati delle sveglie RTTTL/RTX, OTA e iMelody	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
	Vorbis		OBBLIGATORIO		Ogg (.ogg) Matroska (.mkv)
	PCM/WAVE		OBBLIGATORIO	PCM lineare a 8 e 16 bit (frequenze fino al limite dell'hardware)	WAVE (.wav)
Immagine	JPEG	OBBLIGATORIO	OBBLIGATORIO	Base+progressiva	JPEG (.jpg)
	GIF		OBBLIGATORIO		GIF (.gif)
	PNG	OBBLIGATORIO	OBBLIGATORIO		PNG (.png)
	BMP		OBBLIGATORIO		BMP (.bmp)
	WebP	OBBLIGATORIO	OBBLIGATORIO		WebP (.webp)
Video	H.263	OBBLIGATORI Obbligatorio per le implementazioni dei dispositivi che includono l'hardware della videocamera e definiscono android.hardware.camera o android.hardware.camera.front.	OBBLIGATORIO		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	OBBLIGATORI Obbligatorio per le implementazioni dei dispositivi che includono l'hardware della videocamera e definiscono android.hardware.camera o android.hardware.camera.front.	OBBLIGATORIO	Profilo di riferimento (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, solo audio AAC, non cercabile, Android 3.0 e versioni successive)
	MPEG-4 SP		OBBLIGATORIO		3GPP (.3gp)
	VP8		OBBLIGATORI (Android 2.3.3 e versioni successive)		WebM (.webm) e Matroska (.mkv, Android 4.0 e versioni successive)

5.2 Codifica video

Le implementazioni dei dispositivi Android che includono una fotocamera posteriore e dichiaranoandroid.hardware.camera DEVONO supportare i seguenti profili di codifica video.

	SD (bassa qualità)	SD (alta qualità)	HD (se supportato dall'hardware)
Codec video	Profilo Baseline H.264	Profilo Baseline H.264	Profilo Baseline H.264
Risoluzione video	176 x 144 px	480 x 360 px	1280 x 720 px
Frequenza fotogrammi video	12 f/s	30 fps	30 fps
Velocità in bit video	56 Kbps	500 Kbps o superiore	2 Mbps o superiore
Codec audio	AAC-LC	AAC-LC	AAC-LC
Canali audio	1 (mono)	2 (stereo)	2 (stereo)
Velocità in bit audio	24 kbps	128 Kbps	192 kbps

5.3. Registrazione audio

Quando un'applicazione ha utilizzato l'API android.media.AudioRecord per avviare la registrazione di uno stream audio, le implementazioni dei dispositivi che includono hardware per microfoni e dichiarano android.hardware.microphone DEVONO campionare e registrare l'audio con ciascuno di questi comportamenti:

• Il dispositivo DEVE presentare caratteristiche di ampiezza approssimativamente piatte rispetto alla frequenza; in particolare, ±3 dB, da 100 Hz a 4000 Hz
• La sensibilità di ingresso audio DEVE essere impostata in modo che una sorgente con un livello di potenza sonora (SPL) di 90 dB a 1000 Hz generi un valore RMS di 2500 per i campioni a 16 bit.
• I livelli di ampiezza PCM DEVONO seguire in modo lineare le variazioni di SPL in ingresso su almeno un intervallo di 30 dB da -18 dB a +12 dB rispetto a 90 dB SPL al microfono.
• La distorsione armonica totale DEVE essere inferiore all'1% da 100 Hz a 4000 Hz a un livello di ingresso di 90 dB SPL.

Oltre alle specifiche di registrazione riportate sopra, quando un'applicazione ha iniziato a registrare uno stream audio utilizzando l'origine audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

• L'elaborazione di riduzione del rumore, se presente, DEVE essere disattivata.
• Il controllo automatico del guadagno, se presente, DEVE essere disattivato.

Nota: anche se alcuni dei requisiti descritti sopra sono indicati come "DA" per Android 4.0, è previsto di modificare la definizione di compatibilità per una versione futura in "DEVE". In altre parole, questi requisiti sono facoltativi in Android 4.0, ma saranno obbligatori in una versione futura. I dispositivi esistenti e nuovi con Android 4.0 sono vivamente invitati a soddisfare questi requisiti in Android 4.0, altrimenti non potranno raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

5.4. Latenza audio

La latenza audio è generalmente definita come l'intervallo tra il momento in cui un'applicazione richiede un'operazione di riproduzione o registrazione audio e il momento in cui l'implementazione del dispositivo avvia effettivamente l'operazione. Molte classi di applicazioni si basano su latenze brevi per ottenere effetti in tempo reale, come effetti sonori o comunicazione VoIP. Le implementazioni dei dispositivi che includono hardware per microfoni e dichiarano android.hardware.microphone DEVONO soddisfare tutti i requisiti di latenza audio descritti in questa sezione. Consulta la sezione 7 per informazioni dettagliate sulle condizioni in cui l'hardware del microfono può essere omesso dalle implementazioni del dispositivo.

Ai fini di questa sezione:

• Per "latenza di output a freddo" si intende l'intervallo tra il momento in cui un'applicazione richiede la riproduzione audio e il momento in cui inizia la riproduzione dell'audio, quando il sistema audio è inattivo e spento prima della richiesta
• Per "latenza di uscita a caldo" si intende l'intervallo tra il momento in cui un'applicazione richiede la riproduzione audio e il momento in cui inizia la riproduzione dell'audio, quando il sistema audio è stato utilizzato di recente, ma è attualmente inattivo (ovvero in silenzio)
• Per "latenza di output continua" si intende l'intervallo tra il momento in cui un'applicazione emette un sample da riprodurre e il momento in cui lo speaker riproduce fisicamente il suono corrispondente, mentre il dispositivo è in riproduzione audio
• Per "latenza di input a freddo" si intende l'intervallo di tempo che intercorre tra il momento in cui un'applicazione richiede la registrazione audio e il momento in cui il primo sample viene inviato all'applicazione tramite il relativo callback, quando il sistema audio e il microfono sono inattivi e spenti prima della richiesta
• Per "latenza di input continua" si intende quando si verifica un suono ambientale e quando il sample corrispondente a quel suono viene inviato a un'applicazione di registrazione tramite il relativo callback, mentre il dispositivo è in modalità di registrazione.

Utilizzando le definizioni riportate sopra, le implementazioni dei dispositivi DEVONO mostrare ciascuna di queste proprietà:

• latenza di output a freddo di massimo 100 millisecondi
• latenza di output a caldo di massimo 10 millisecondi
• latenza di uscita continua di massimo 45 millisecondi
• latenza di input a freddo di massimo 100 millisecondi
• latenza di input continua di massimo 50 millisecondi

Nota: sebbene i requisiti descritti sopra siano indicati come "DA" per Android 4.0, è previsto di modificarli in "DEVE" nella definizione di compatibilità per una versione futura. In altre parole, questi requisiti sono facoltativi in Android 4.0, ma saranno obbligatori in una versione futura. I dispositivi esistenti e nuovi con Android 4.0 sono vivamente invitati a soddisfare questi requisiti in Android 4.0, altrimenti non potranno raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

Se l'implementazione di un dispositivo soddisfa i requisiti di questa sezione, PUÒ indicare il supporto dell'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 dell'audio a bassa latenza.

5.5. Protocolli di rete

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

• RTSP (RTP, SDP)
• Streaming progressivo HTTP(S)
• HTTP(S) Live Streaming draft protocol, Version 3 [Resources, 59]

6. Compatibilità degli strumenti per sviluppatori

Le implementazioni dei dispositivi DEVONO supportare gli Android Developer Tools 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 dei dispositivi DEVONO supportare tutte le funzioni adb come documentato nell'SDK Android. Il daemon adb lato dispositivo DEVE essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivare Android Debug Bridge.
• Dalvik Debug Monitor Service (noto come ddms) [Risorse, 33]
  Le implementazioni dei dispositivi DEVONO supportare tutte le funzionalità ddms come descritte nell'SDK Android. Poiché ddms utilizza adb, il supporto di ddms DOVREBBE essere inattivo per impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato Android Debug Bridge, come sopra.
• Monkey [Risorse, 36]
  Le implementazioni del dispositivo DEVONO includere il framework Monkey e metterlo a disposizione delle applicazioni.

La maggior parte dei sistemi basati su Linux e dei sistemi Apple Macintosh riconosce i dispositivi Android utilizzando gli strumenti SDK Android standard, senza ulteriore supporto. Tuttavia, i sistemi Microsoft Windows in genere richiedono un driver per i nuovi dispositivi Android. Ad esempio, i nuovi ID fornitore e a volte i nuovi ID dispositivo richiedono driver USB personalizzati per i sistemi Windows. Se un'implementazione del dispositivo non è riconosciuta dallo strumento adb fornito nell'SDK Android standard, gli implementatori del dispositivo DEVONO fornire i driver Windows che consentono agli sviluppatori di connettersi al dispositivo utilizzando il protocollo adb. Questi driver DEVONO essere forniti per Windows XP, Windows Vista e Windows 7, sia nelle versioni a 32 bit sia in quelle a 64 bit.

7. Compatibilità hardware

Se un dispositivo include un determinato componente hardware con un'API corrispondente per gli sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'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 dispone di questo componente:

• le definizioni di classi complete (come documentato 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 dell'API DEVONO restituire valori null se consentito dalla documentazione dell'SDK
• I metodi API DEVONO restituire implementazioni no-op delle classi in cui i valori null non sono consentiti dalla documentazione dell'SDK
• I metodi dell'API NON DEVONO generare eccezioni non documentate dalla documentazione dell'SDK.

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

Le implementazioni dei dispositivi DEVONO segnalare con precisione informazioni sulla configurazione hardware tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) della classe android.content.pm.PackageManager. [Resources, 37]

7.1. Display e grafica

Android 4.0 include funzionalità che regolano automaticamente gli asset e i layout dell'interfaccia utente dell'applicazione in base al dispositivo, per garantire il corretto funzionamento delle applicazioni di terze parti su una serie di configurazioni hardware [Risorse, 38]. I dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

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

• Per "dimensioni diagonali fisiche" si intende la distanza in pollici tra due angoli opposti della parte illuminata del display.
• "DPI" (che significa "punti per pollice") indica il numero di pixel inclusi in un intervallo lineare orizzontale o verticale di 1". Se sono elencati i valori dpi, sia il dpi orizzontale sia quello verticale devono rientrare nell'intervallo.
• "Proporzioni" indica il rapporto tra la dimensione più lunga dello schermo e la dimensione più corta. Ad esempio, un display di 480 x 854 pixel corrisponde a 854 / 480 = 1,779, ovvero circa "16:9".
• Un "pixel indipendente dalla densità" ("dp") è l'unità di pixel virtuale normalizzata a un schermo di 160 dpi, calcolata come: pixels = dps * (density / 160).

7.1.1. Configurazione schermo

Dimensioni schermo

Il framework UI di Android supporta una serie di dimensioni dello schermo diverse e consente alle applicazioni di eseguire query sulle dimensioni dello schermo del dispositivo (ovvero "layout dello schermo") tramite android.content.res.Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK. Le implementazioni dei dispositivi DEVONO segnalare le dimensioni dello schermo corrette come definite nella documentazione dell'SDK Android [Risorse, 38] e determinate dalla piattaforma Android a monte. Nello specifico, le implementazioni dei dispositivi devono segnalare le dimensioni dello schermo corrette in base alle seguenti dimensioni dello schermo in pixel indipendenti dalla densità (dp) logiche.

• I dispositivi DEVONO avere dimensioni dello schermo di almeno 426 dp x 320 dp ("piccolo")
• I dispositivi che segnalano dimensioni dello schermo "normali" DEVONO avere dimensioni dello schermo di almeno 470 dp x 320 dp
• I dispositivi che segnalano dimensioni dello schermo "grandi" DEVONO avere dimensioni dello schermo di almeno 640 dp x 480 dp
• I dispositivi che segnalano dimensioni dello schermo "Molto grande" DEVONO avere dimensioni dello schermo di almeno 960 dp x 720 dp

Inoltre, i dispositivi DEVONO avere dimensioni dello schermo di almeno 6,35 cm di diagonale fisica.

I dispositivi NON DEVONO modificare le dimensioni dello schermo registrate in nessun momento.

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

Proporzioni dello schermo

Le proporzioni DEVONO essere comprese tra 1,3333 (4:3) e 1,85 (16:9).

Densità schermo

Il framework dell'interfaccia utente di Android definisce un insieme di densità logiche standard per aiutare gli sviluppatori di applicazioni a scegliere come target le risorse dell'applicazione. Le implementazioni dei dispositivi DEVONO segnalare una delle seguenti densità del framework Android logico tramite le API android.util.DisplayMetrics e DEVONO eseguire le applicazioni a questa densità standard.

• 120 dpi, noto come "ldpi"
• 160 dpi, noti come "mdpi"
• 213 dpi, noto come "tvdpi"
• 240 dpi, noto come "hdpi"
• 320 dpi, noto come "xhdpi"

Le implementazioni dei dispositivi DEVONO definire la densità del framework Android standard più vicina numericamente alla densità fisica dello schermo, a meno che questa densità logica non riduca le dimensioni dello schermo registrate al di sotto del minimo supportato. Se la densità del framework Android standard più vicina numericamente alla densità fisica genera dimensioni dello schermo inferiori alle dimensioni dello schermo compatibili supportate più piccole (larghezza di 320 dp), le implementazioni del dispositivo DEVONO registrare la densità del framework Android standard successiva più bassa.

7.1.2. Metriche relative alla visualizzazione

Le implementazioni dei dispositivi DEVONO riportare 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 delle applicazioni per l'orientamento dello schermo in verticale o in orizzontale. In altre parole, il dispositivo deve violare la richiesta dell'applicazione di un orientamento dello schermo specifico. Le implementazioni dei dispositivi POSSONO selezionare l'orientamento verticale o orizzontale come valore predefinito.

I dispositivi DEVONO riportare il valore corretto per l'orientamento corrente del dispositivo, ogni volta che viene eseguito una query 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 registrate quando si cambia orientamento.

I dispositivi DEVONO indicare gli orientamenti dello schermo supportati (android.hardware.screen.portrait e/oandroid.hardware.screen.landscape) e DEVONO indicare almeno un orientamento supportato. Ad esempio, un dispositivo con uno schermo in orientamento orizzontale fisso, come una televisione o un laptop, DEVE segnalare solo android.hardware.screen.landscape.

7.1.4. Accelerazione grafica 2D e 3D

Le implementazioni dei dispositivi DEVONO supportare sia OpenGL ES 1.0 sia 2.0, come descritto e dettagliato nella documentazione dell'SDK Android. Le implementazioni dei dispositivi DEVONO supportare anche Android Renderscript, come descritto nella documentazione dell'SDK Android [Risorse, 8].

Le implementazioni dei dispositivi DEVONO anche identificarsi correttamente come supportanti OpenGL ES 1.0 e 2.0. ovvero:

• Le API gestite (ad esempio tramite il metodo GLES10.getString()) DEVONO segnalare il supporto di OpenGL ES 1.0 e 2.0
• Le API OpenGL native C/C++ (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 dei dispositivi POSSONO implementare le estensioni OpenGL ES desiderate. Tuttavia, le implementazioni dei dispositivi DEVONO segnalare tramite le API native e gestite OpenGL ES tutte le stringhe di estensione supportate e, al contrario, NON DEVONO segnalare le stringhe di estensione non supportate.

Tieni presente che Android 4.0 include il supporto per le applicazioni che possono optionally specificare che richiedono formati di compressione delle texture OpenGL specifici. Questi formati sono in genere specifici del fornitore. Android 4.0 non richiede implementazioni di dispositivi per implementare un formato di compressione delle texture specifico. Tuttavia, devono segnalare con precisione tutti i formati di compressione delle texture supportati tramite il metodo getString() nell'API OpenGL.

Android 3.0 ha introdotto un meccanismo per consentire alle applicazioni di dichiarare di voler attivare l'accelerazione hardware per la grafica 2D a livello di applicazione, attività, finestra o visualizzazione tramite l'utilizzo di un tag manifestandroid:hardwareAccelerated o di chiamate API dirette [Risorse, 9].

In Android 4.0, le implementazioni dei dispositivi DEVONO attivare l'accelerazione hardware per impostazione predefinita e DEVONO disattivarla se lo richiede lo sviluppatore impostando android:hardwareAccelerated="false" o disattivando l'accelerazione hardware direttamente tramite le API Android View.

Inoltre, le implementazioni dei dispositivi DEVONO avere un comportamento coerente con la documentazione dell'SDK Android sull'accelerazione hardware [Risorse, 9].

Android 4.0 include un oggetto TextureView che consente agli sviluppatori di integrare direttamente le texture OpenGL ES con accelerazione hardware come target di rendering in una gerarchia dell'interfaccia utente. Le implementazioni dei dispositivi DEVONO supportare l'API TextureView e DEVONO avere un comportamento coerente con l'implementazione di Android di upstream.

7.1.5. Modalità di compatibilità delle applicazioni precedenti

Android 4.0 specifica una "modalità di compatibilità" in cui il framework opera in una modalità equivalente a una dimensione dello schermo "normale" (larghezza di 320 dp) a vantaggio delle applicazioni precedenti non sviluppate per le versioni precedenti di Android che risalgono a prima dell'indipendenza dalle dimensioni dello schermo. Le implementazioni dei dispositivi DEVONO includere il supporto della modalità di compatibilità delle applicazioni legacy come implementata dal codice open source Android upstream. In altre parole, le implementazioni dei dispositivi NON DEVONO modificare gli attivatori o le soglie a cui viene attivata la modalità di compatibilità e NON DEVONO modificare il comportamento della modalità di compatibilità stessa.

7.1.6. Tipi di schermo

Le schermate di implementazione del dispositivo sono classificate in due tipi:

• Implementazioni di display con pixel fissi: lo schermo è un singolo pannello che supporta solo una larghezza e un'altezza di un singolo pixel. In genere, lo schermo è integrato fisicamente con il dispositivo. Alcuni esempi sono cellulari, tablet e così via.
• Implementazioni di display con pixel variabili: l'implementazione del dispositivo non ha uno schermo integrato e include una porta di uscita video come VGA o HDMI per il display oppure ha uno schermo integrato che può modificare le dimensioni dei pixel. Alcuni esempi sono televisioni, decoder e così via.

Implementazioni di dispositivi con pixel fissi

Le implementazioni di dispositivi con pixel fissi POSSONO utilizzare schermi di qualsiasi dimensione di pixel, a condizione che soddisfino i requisiti definiti in questa definizione di compatibilità.

Le implementazioni con pixel fissi POTREBBERO includere una porta di uscita video da utilizzare con un display esterno. Tuttavia, se il display viene utilizzato per eseguire app, il dispositivo DEVE soddisfare i seguenti requisiti:

• Il dispositivo DEVE riportare le stesse metriche di configurazione e visualizzazione dello schermo, come descritto nelle sezioni 7.1.1 e 7.1.2, del display a pixel fissi.
• Il dispositivo DEVE riportare la stessa densità logica del display a pixel fissi.
• Il dispositivo DEVE segnalare dimensioni dello schermo uguali o molto simili a quelle del display a pixel fissi.

Ad esempio, un tablet con una diagonale di 7" e una risoluzione di 1024 x 600 pixel è considerato un'implementazione di display mdpi di grandi dimensioni con pixel fissi. Se contiene una porta di output video che viene visualizzata a 720p o 1080p, l'implementazione del dispositivo DEVE scalare l'output in modo che le applicazioni vengano eseguite solo in una finestra mdpi di grandi dimensioni, indipendentemente dal fatto che sia in uso il display con pixel fissi o la porta di output video.

Implementazioni di dispositivi con pixel variabili

Le implementazioni dei dispositivi con pixel variabili DEVONO supportare una o entrambe le risoluzioni 1280x720 o 1920x1080 (ovvero 720p o 1080p). Le implementazioni dei dispositivi con display a pixel variabili NON DEVONO supportare altre configurazioni o modalità dello schermo. Le implementazioni dei dispositivi con schermi a pixel variabili POTREBBERO modificare la configurazione o la modalità dello schermo in fase di esecuzione o di avvio. Ad esempio, un utente di un set-top box potrebbe sostituire un display a 720p con uno a 1080p e l'implementazione del dispositivo potrebbe essere modificata di conseguenza.

Inoltre, le implementazioni dei dispositivi con pixel variabili DEVONO registrare i seguenti bucket di configurazione per queste dimensioni dei pixel:

• 1280 x 720 (noto anche come 720p): dimensioni dello schermo "grandi", densità "tvdpi" (213 dpi)
• 1920 x 1080 (noto anche come 1080p): dimensioni dello schermo "grandi", intensità "xhdpi" (320 dpi)

Per chiarezza, le implementazioni dei dispositivi con dimensioni dei pixel variabili sono limitate a 720p o 1080p in Android 4.0 e DEVONO essere configurate per segnalare i bucket delle dimensioni e della densità dello schermo come indicato sopra.

7.1.7. Tecnologia dello schermo

La piattaforma Android include API che consentono alle applicazioni di eseguire il rendering di grafica avanzata sul display. I dispositivi DEVONO supportare tutte queste API come definite dall'SDK Android, a meno che non sia specificamente consentito in questo documento. Nello specifico:

• I dispositivi DEVONO supportare display in grado di eseguire il rendering di grafica a colori a 16 bit e DEVONO supportare display in grado di eseguire il rendering di grafica a colori a 24 bit.
• I dispositivi DEVONO supportare display in grado di eseguire il rendering delle animazioni.
• La tecnologia di visualizzazione utilizzata DEVE avere un rapporto di aspetto dei pixel (PAR) compreso tra 0,9 e 1,1. In altre parole, le proporzioni dei pixel DEVONO essere quasi quadrate (1,0) con una tolleranza del 10%.

7.2. Dispositivi di immissione

7.2.1. Tastiera

Implementazioni dei dispositivi:

• DEVE includere il supporto per il framework di gestione dell'input (che consente agli sviluppatori di terze parti di creare motori di gestione dell'input, ad esempio la tastiera virtuale) come descritto all'indirizzo http://developer.android.com
• DEVE fornire almeno un'implementazione di tastiera virtuale (indipendentemente dal fatto che sia presente o meno una tastiera fisica)
• POTREBBE includere implementazioni aggiuntive della tastiera su schermo
• POTREBBE 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] (ovvero QWERTY o 12 tasti)

7.2.2. Navigazione non tocco

Implementazioni dei dispositivi:

• PUO' omettere un'opzione di navigazione non tocco (ad es. un trackball, un d-pad o un cursore)
• DEVE riportare il valore corretto per android.content.res.Configuration.navigation [Resources, 40]
• DEVE fornire un meccanismo di interfaccia utente alternativo ragionevole per la selezione e la modifica del testo, compatibile con i motori di gestione dell'input. Il software open source Android di upstream include un meccanismo di selezione adatto per l'utilizzo con dispositivi che non dispongono di input di navigazione non touch.

7.2.3. Tasti di navigazione

Le funzioni Home, Menu e Indietro sono essenziali per il paradigma di navigazione di Android. Le implementazioni dei dispositivi DEVONO rendere queste funzioni disponibili all'utente in qualsiasi momento durante l'esecuzione delle applicazioni. Queste funzioni POSSONO essere implementate tramite pulsanti fisici dedicati (ad esempio pulsanti touch meccanici o capacitivi) o tramite tasti software, gesti, pannelli touch e così via dedicati. Android 4.0 supporta entrambe le implementazioni.

Le implementazioni dei dispositivi POSSONO utilizzare una parte distinta dello schermo per visualizzare i tasti di navigazione, ma in questo caso DEVONO soddisfare i seguenti requisiti:

• I tasti di navigazione per l'implementazione del dispositivo DEVONO utilizzare una parte distinta dello schermo, non disponibile per le applicazioni, e NON DEVONO coprire o interferire in altro modo con la parte dello schermo disponibile per le applicazioni.
• Le implementazioni dei dispositivi DEVONO rendere disponibile una parte del display per le applicazioni che soddisfano i requisiti definiti nella sezione 7.1.1.
• Le implementazioni dei dispositivi DEVONO mostrare i tasti di navigazione quando le applicazioni non specificano una modalità dell'interfaccia utente di sistema o specificano SYSTEM_UI_FLAG_VISIBLE.
• Le implementazioni dei dispositivi DEVONO presentare i tasti di navigazione in una modalità "a basso profilo" (ad es. attenuata) non invadente quando le applicazioni specificano SYSTEM_UI_FLAG_LOW_PROFILE.
• Le implementazioni dei dispositivi DEVONO nascondere i tasti di navigazione quando le applicazioni specificano SYSTEM_UI_FLAG_HIDE_NAVIGATION.
• L'implementazione del dispositivo DEVE presentare una chiave Menu alle applicazioni quando targetSdkVersion <= 10 e NON DEVE presentare una chiave Menu quando targetSdkVersion > 10.

7.2.4. Input touchscreen

Implementazioni dei dispositivi:

• DEVE avere un sistema di input del cursore di qualche tipo (simile a un mouse o tocco)
• PUO' avere un touchscreen di qualsiasi tipo (ad esempio capacitivo o resistivo)
• DOVREBBE supportare cursori monitorati in modo completamente indipendente, se un touchscreen supporta più cursori
• DEVE riportare il valore di android.content.res.Configuration.touchscreen [Resources, 40] corrispondente al tipo di touchscreen specifico sul dispositivo

Android 4.0 include il supporto di una serie di touch screen, touchpad e dispositivi di input touch simulati. Le implementazioni dei dispositivi basati su touchscreen sono associate a un display [Risorse, 61] in modo che l'utente abbia l'impressione di manipolare direttamente gli elementi sullo schermo. Poiché l'utente tocca direttamente lo schermo, il sistema non richiede funzionalità aggiuntive per indicare gli oggetti manipolati. Al contrario, un'interfaccia tocco falsa fornisce un sistema di input utente che approssima un sottoinsieme di funzionalità del touchscreen. Ad esempio, un mouse o un telecomando che gestisce un cursore sullo schermo si avvicina al tocco, ma richiede all'utente di prima selezionare o mettere a fuoco un elemento e poi fare clic. Numerosi dispositivi di input come mouse, trackpad, mouse aereo basato su giroscopio, cursore a giroscopio, joystick e trackpad multi-touch possono supportare interazioni touch false. Android 4.0 include la costante di funzionalità android.hardware.faketouch, che corrisponde a un dispositivo di input non touch (ovvero basato su cursore) ad alta fedeltà, come un mouse o un trackpad, che può emulare adeguatamente l'input basato su tocco (incluso il supporto di gesti di base) e indica che il dispositivo supporta un sottoinsieme emulato delle funzionalità del touchscreen. Le implementazioni dei dispositivi che dichiarano la funzionalità di tocco falso DEVONO soddisfare i requisiti di tocco falso descritti nella sezione 7.2.5.

Le implementazioni dei dispositivi DEVONO segnalare la funzionalità corretta corrispondente al tipo di input utilizzato. Le implementazioni dei dispositivi che includono un touchscreen (monotocco o superiore) DEVONO anche segnalare la costante della funzionalità della piattaforma android.hardware.faketouch. Le implementazioni dei dispositivi che non includono un touchscreen (e si basano solo su un dispositivo di puntamento) NON DEVONO segnalare alcuna funzionalità del touchscreen e DEVONO segnalare solo android.hardware.faketouch se soddisfano i requisiti relativi ai tocchi falsi descritti nella Sezione 7.2.5.

7.2.5. Input tocco simulato

Implementazioni dei dispositivi che dichiarano il supporto di android.hardware.faketouch

• DEVE segnalare le posizioni X e Y assolute dello schermo della posizione del cursore e mostrare un cursore visivo sullo schermo[Risorse, 60]
• DEVE segnalare l'evento tocco con il codice azione [Risorse, 60] che specifica la modifica dello stato che si verifica quando il cursore diventa down o up sullo schermo [Risorse, 60]
• DEVE supportare i cursori down e up su un oggetto sullo schermo, il che consente agli utenti di emulare il tocco di un oggetto sullo schermo
• DEVE supportare il cursore down, il cursore up, il cursore down e poi il cursore up nello stesso punto su un oggetto sullo schermo entro una soglia di tempo, che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo [Risorse, 60]
• DEVE supportare il cursore down su un punto arbitrario dello schermo, il cursore si sposta in un altro punto arbitrario dello schermo, seguito da un cursore up, che consente agli utenti di emulare un trascinamento con tocco
• DEVE supportare il cursore down, quindi consentire agli utenti di spostare rapidamente l'oggetto in un'altra posizione sullo schermo e poi il cursore up sullo schermo, che consente agli utenti di lanciare un oggetto sullo schermo

I dispositivi che dichiarano il supporto di android.hardware.faketouch.multitouch.distinct DEVONO soddisfare i requisiti per il controllo simulato sopra indicati e DEVONO anche supportare il monitoraggio distinto di due o più input del cursore indipendenti.

7.2.6. Microfono

Le implementazioni dei dispositivi POSSONO omettere un microfono. Tuttavia, se l'implementazione di un dispositivo omette un microfono, NON DEVE segnalare la costante della funzionalità android.hardware.microphone e deve implementare l'API di registrazione audio come no-op, come indicato nella Sezione 7. Al contrario, le implementazioni dei dispositivi che dispongono di un microfono:

• DEVE segnalare la costante della funzionalità android.hardware.microphone
• DEVONO soddisfare i requisiti di qualità audio descritti nella sezione 5.3
• DEVE soddisfare i requisiti di latenza audio descritti nella sezione 5.4

7.3. Sensori

Android 4.0 include API per accedere a vari tipi di sensori. Le implementazioni dei dispositivi in genere POSSONO omettere questi sensori, come previsto nelle seguenti sezioni. Se un dispositivo include un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android. Ad esempio, implementazioni dei dispositivi:

• DEVE segnalare con precisione la presenza o l'assenza di sensori in base alla classe android.content.pm.PackageManager. [Resources, 37]
• DEVE restituire un elenco accurato dei sensori supportati tramite metodiSensorManager.getSensorList() e simili
• DEVE comportarsi in modo ragionevole per tutte le altre API di sensori (ad esempio, deve restituire true o false a seconda dei casi quando le applicazioni tentano di registrare gli ascoltatori, non deve chiamare gli ascoltatori dei sensori quando i sensori corrispondenti non sono presenti e così via).
• DEVE segnalare tutte le misurazioni dei sensori utilizzando i valori pertinenti del Sistema internazionale di unità di misura (ovvero metrico) per ogni tipo di sensore come definito nella documentazione dell'SDK Android [Risorse, 41]

L'elenco riportato sopra non è esaustivo; il comportamento documentato dell'SDK Android deve essere considerato autorevole.

Alcuni tipi di sensori sono sintetici, il che significa che possono essere ricavati dai dati forniti da uno o più altri sensori. Alcuni esempi sono il sensore di orientamento e il sensore di accelerazione lineare. Le implementazioni dei dispositivi DEVONO implementare questi tipi di sensori, se includono i sensori fisici prerequisiti.

Le API Android 4.0 introducono il concetto di sensore "in streaming", ovvero un sensore che restituisce dati continuamente, anziché solo quando i dati cambiano. Le implementazioni dei dispositivi DEVONO fornire continuamente campioni di dati periodici per qualsiasi API indicata dalla documentazione dell'SDK Android 4.0 come sensore in streaming.

7.3.1. Accelerometro

Le implementazioni dei dispositivi DEVONO includere un accelerometro a 3 assi. Se l'implementazione di un dispositivo include un accelerometro a 3 assi:

• DEVE essere in grado di inviare eventi a una frequenza di almeno 50 Hz
• DEVE essere conforme al sistema di coordinate del sensore Android come descritto nelle API Android (vedi [Risorse, 41])
• DEVE essere in grado di misurare dalla caduta libera fino al doppio della gravità (2 g) o più su qualsiasi vettore tridimensionale
• DEVE avere un'accuratezza di almeno 8 bit
• DEVE avere una deviazione standard non superiore a 0,05 m/s^2

7.3.2. Magnetometro

Le implementazioni dei dispositivi DEVONO includere un magnetometro a 3 assi (ad es. una bussola). Se un dispositivo include un magnetometro a 3 assi:

• DEVE essere in grado di inviare eventi a una frequenza di almeno 10 Hz
• DEVE essere conforme al sistema di coordinate del sensore Android come descritto nelle API Android (vedi [Risorse, 41]).
• DEVE essere in grado di campionare un intervallo di intensitù di campo adeguato per coprire il campo geomagnetico
• DEVE avere un'accuratezza di almeno 8 bit
• DEVE avere una deviazione standard non superiore a 0,5 µT

7.3.3. GPS

Le implementazioni dei dispositivi DEVONO includere un ricevitore GPS. Se l'implementazione di un dispositivo include un ricevitore GPS, DEVE includere qualche forma di tecnica "GPS assistito" per ridurre al minimo il tempo di accoppiamento del GPS.

7.3.4. Giroscopio

Le implementazioni dei dispositivi DEVONO includere un giroscopio (ovvero un sensore di variazione angolare). I dispositivi NON DEVONO includere un sensore giroscopio, a meno che non sia incluso anche un accelerometro a 3 assi. Se l'implementazione di un dispositivo include un giroscopio:

• DEVE essere compensato in base alla temperatura
• DEVE essere in grado di misurare le variazioni di orientamento fino a 5,5*Pi radianti/secondo (ovvero circa 1000 gradi al secondo)
• DEVE essere in grado di inviare eventi a una frequenza di almeno 100 Hz
• DEVE avere una precisione di 12 bit o superiore
• 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 misuri la varianza del giroscopio a una frequenza di campionamento di 1 Hz, non deve essere superiore a 1e-7 rad^2/s^2.
• DEVONO avere timestamp il più vicino possibile al momento in cui si è verificato l'evento hardware. La latenza costante deve essere rimossa.

7.3.5. Barometro

Le implementazioni dei dispositivi POSSONO includere un barometro (ovvero un sensore di pressione dell'aria ambiente). Se un'implementazione del dispositivo include un barometro:

• DEVE essere in grado di inviare eventi a una frequenza di almeno 5 Hz
• DEVE avere una precisione adeguata per consentire la stima dell'altitudine

7.3.7. Termometro

Le implementazioni dei dispositivi POSSONO, ma NON DEVONO, includere un termometro (ovvero un sensore di temperatura). Se l'implementazione di un dispositivo include un termometro, deve misurare la temperatura della CPU del dispositivo. NON DEVE misurare nessun'altra temperatura. Tieni presente che questo tipo di sensore è deprecato nelle API Android 4.0.

7.3.7. Fotometro

Le implementazioni dei dispositivi POSSONO includere un fotometro (ovvero un sensore di luce ambientale).

7.3.8. Sensore di prossimità

Le implementazioni del dispositivo POSSONO includere un sensore di prossimità. Se l'implementazione di un dispositivo include un sensore di prossimità, DEVE misurare la vicinanza di un oggetto nella stessa direzione dello schermo. In altre parole, il sensore di prossimità DEVE essere orientato in modo da rilevare gli oggetti vicini allo schermo, poiché lo scopo principale di questo tipo di sensore è rilevare uno smartphone in uso dall'utente. Se l'implementazione di un dispositivo include un sensore di prossimità con un altro orientamento, NON DEVE essere accessibile tramite questa API. Se un'implementazione del dispositivo ha un sensore di prossimità, DEVE avere una precisione di almeno 1 bit.

7.4. Connettività dei dati

7.4.1. Telefonia

"Telefonia" come utilizzato dalle API Android 4.0 e da questo documento fa riferimento specificamente all'hardware relativo all'invio di chiamate vocali e di messaggi SMS tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano o meno essere basate su protocollo di commutazione di pacchetti, ai fini di Android 4.0 sono considerate indipendenti da qualsiasi connettività dati che possa essere implementata utilizzando la stessa rete. In altre parole, le API e la funzionalità "telefonia" di Android fanno riferimento specificamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni dei dispositivi che non possono effettuare chiamate o inviare/ricevere messaggi SMS NON DEVONO segnalare la funzionalità "android.hardware.telephony" o eventuali sottofunzionalità, indipendentemente dal fatto che utilizzino una rete cellulare per la connettività dati.

Android 4.0 PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. In altre parole, Android 4.0 è compatibile con dispositivi diversi dagli smartphone. Tuttavia, se l'implementazione di un dispositivo include la telefonia GSM o CDMA, deve implementare il supporto completo dell'API per quella tecnologia. Le implementazioni di dispositivi che non includono hardware di telefonia DEVONO implementare le API complete come no-op.

7.4.2. IEEE 802.11 (Wi-Fi)

Le implementazioni dei dispositivi Android 4.0 DEVONO includere il supporto di una o più forme di 802.11 (b/g/a/n e così via). Se l'implementazione di un dispositivo include il supporto per 802.11, DEVE implementare l'API Android corrispondente.

7.4.3. Bluetooth

Le implementazioni dei dispositivi DEVONO includere un trasmettitore Bluetooth. Le implementazioni dei dispositivi che includono un transceiver Bluetooth DEVONO attivare l'API Bluetooth basata su RFCOMM come descritto nella documentazione dell'SDK [Risorse, 42]. Le implementazioni dei dispositivi DEVONO implementare profili Bluetooth pertinenti, come A2DP, AVRCP, OBEX e così via, in base alle esigenze del dispositivo.

La suite di test di compatibilità include casi che coprono il funzionamento di base dell'API Bluetooth RFCOMM di Android. Tuttavia, poiché il Bluetooth è un protocollo di comunicazione tra dispositivi, non può essere testato completamente tramite test di unità eseguiti su un singolo dispositivo. Di conseguenza, le implementazioni dei dispositivi DEVONO superare anche la procedura di test Bluetooth eseguita da persone descritta nell'Appendice A.

7.4.4. Near Field Communication

Le implementazioni dei dispositivi DEVONO includere un transceiver e hardware correlato per le comunicazioni NFC (Near Field Communication). Se l'implementazione di un dispositivo include hardware NFC, deve:

• DEVE segnalare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature(). [Resources, 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 NFC Forum (come definito dalla specifica tecnica del NFC Forum 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 NFC Forum 1, 2, 3, 4 (definiti dal NFC Forum)
• DOVREBBE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC. Tieni presente che, sebbene gli standard NFC riportati di seguito siano indicati come "DA" per Android 4.0, è previsto che la definizione di compatibilità per una versione futura li modifichi in "DEVE". In altre parole, questi standard sono facoltativi in Android 4.0, ma saranno obbligatori nelle versioni future. I dispositivi esistenti e nuovi con Android 4.0 sono molto fortemente invitati a soddisfare questi requisiti in Android 4.0 in modo da poter eseguire l'upgrade alle release future 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 NFC Forum)
  • SDP 1.0 (definito dal NFC Forum)
  • Protocollo NDEF Push [Risorse, 43]
  • SNEP 1.0 (definito dal NFC Forum)
• DEVE includere il supporto di Android Beam:
  • DEVE implementare il server SNEP predefinito. I messaggi NDEF validi ricevuti dal server SNEP predefinito DEVONO essere inviati alle applicazioni che utilizzano l'intent android.nfc.ACTION_NDEF_DISCOVERED. La disattivazione di Android Beam nelle impostazioni NON DEVE disattivare l'invio del messaggio NDEF in arrivo.
  • DEVE implementare il server NPP. I messaggi ricevuti dal server NPP DEVONO essere elaborati allo stesso modo del server SNEP predefinito.
  • DEVE implementare un client SNEP e tentare di inviare NDEF P2P in uscita al server SNEP predefinito quando Android Beam è abilitato. Se non viene trovato alcun server SNEP predefinito, il client DEVE tentare di inviare a un server NPP.
  • DEVE consentire alle attività in primo piano di impostare il messaggio NDEF P2P in uscita utilizzando android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback e android.nfc.NfcAdapter.enableForegroundNdefPush.
  • DOVREBBE utilizzare un gesto o una conferma sullo schermo, ad esempio "Tocca per trasmettere", prima di inviare messaggi NDEF P2P in uscita.
  • DOVREBBE attivare Android Beam per impostazione predefinita
• DEVE eseguire il polling per tutte le tecnologie supportate in modalità di rilevamento NFC.
• DOVREBBE essere in modalità di rilevamento NFC quando il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.

Tieni presente che i link disponibili pubblicamente non sono disponibili per le specifiche JIS, ISO e NFC Forum citate sopra.

Inoltre, le implementazioni dei dispositivi POSSONO includere il supporto di lettori/scrittori 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])

Tieni presente che Android 4.0 include le API per questi tipi di MIFARE. Se un'implementazione del dispositivo supporta MIFARE nel ruolo di lettore/scrittore:

• DEVE implementare le API Android corrispondenti come documentato dall'SDK Android
• DEVE segnalare la funzionalità com.nxp.mifare dal metodo android.content.pm.PackageManager.hasSystemFeature(). [Risorse, 37] Tieni presente che questa non è una funzionalità Android standard e, pertanto, non viene visualizzata come costante nella classe PackageManager.
• NON DEVE implementare le API Android corrispondenti né segnalare la funzionalità com.nxp.mifare, a meno che non implementi anche il supporto NFC generale come descritto in questa sezione

Se l'implementazione di un dispositivo non include hardware NFC, NON deve dichiarare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature() [Resources, 37] e DEVE implementare l'API NFC di Android 4.0 come no-op.

Poiché le classi android.nfc.NdefMessage e android.nfc.NdefRecord rappresentano un formato di rappresentazione dei dati indipendente dal protocollo, le implementazioni dei dispositivi DEVONO implementare queste API anche se non includono il supporto per NFC o dichiarano la funzionalità android.hardware.nfc.

7.4.5. Capacità di rete minima

Le implementazioni dei dispositivi DEVONO includere il supporto di una o più forme di reti di dati. Nello specifico, le implementazioni dei dispositivi DEVONO includere il supporto di almeno un protocollo di dati in grado di supportare una velocità di 200 Kbit/s o superiore. Alcuni esempi di tecnologie che soddisfano questo requisito sono EDGE, HSPA, EV-DO, 802.11g, Ethernet e così via.

Le implementazioni dei dispositivi in cui uno standard di rete fisica (ad esempio Ethernet) è la connessione dati principale DEVONO includere anche il supporto di almeno uno standard di dati wireless comune, ad esempio 802.11 (Wi-Fi).

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

7.5. Fotocamere

Le implementazioni dei dispositivi DOVREBBERO includere una fotocamera posteriore e POTREBBERO includere una fotocamera anteriore. Una fotocamera posteriore è una fotocamera situata sul lato opposto al display del dispositivo, ovvero acquisisce le immagini sul lato opposto del dispositivo, come una fotocamera tradizionale. Una fotocamera anteriore è una fotocamera collocata sullo stesso lato del dispositivo del display, ovvero una fotocamera in genere utilizzata per acquisire immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.

7.5.1. Fotocamera posteriore

Le implementazioni dei dispositivi DEVONO includere una fotocamera posteriore. Se l'implementazione di un dispositivo include una fotocamera posteriore, deve:

• DEVE avere una risoluzione di almeno 2 megapixel
• DEVE avere l'autofocus hardware o l'autofocus software implementato nel driver della fotocamera (trasparente al software dell'applicazione)
• POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa)
• PUO' includere un flash. Se la fotocamera include un flash, la spia del flash NON deve essere accesa mentre è stata registrata un'istanza di android.hardware.Camera.PreviewCallback su una superficie di anteprima della fotocamera, a meno che l'applicazione non abbia attivato esplicitamente il flash attivando 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 del dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

Le implementazioni dei dispositivi POSSONO includere una fotocamera anteriore. Se l'implementazione di un dispositivo include una fotocamera anteriore:

• DEVE avere una risoluzione di almeno VGA (ovvero 640 x 480 pixel)
• NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Camera. In altre parole, l'API della fotocamera in Android 4.0 supporta in modo specifico le fotocamere anteriori e le implementazioni dei dispositivi NON DEVONO configurare l'API in modo da trattare una fotocamera anteriore come fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
• PUO' includere funzionalità (come messa a fuoco automatica, flash e così via) disponibili per le fotocamere posteriori come descritto nella Sezione 7.5.1.
• DEVE riflettere orizzontalmente (ovvero rispecchiare) lo stream visualizzato da un'app in CameraPreview, come segue:
• Se l'implementazione del dispositivo può essere ruotata dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente), l'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto all'orientamento corrente del dispositivo.
• Se l'applicazione corrente ha richiesto esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation() [Resources, 50], l'anteprima della fotocamera DEVE essere specchiata orizzontalmente rispetto all'orientamento specificato dall'applicazione.
• In caso contrario, l'anteprima DEVE essere speculare rispetto all'asse orizzontale predefinito del dispositivo.
• DEVE rispecchiare l'immagine visualizzata dalla visualizzazione post nello stesso modo dello stream di immagini dell'anteprima della fotocamera. Se l'implementazione del dispositivo non supporta la postview, questo requisito ovviamente non si applica.
• NON DEVE rispecchiare gli stream di video o immagini acquisiti finali restituiti ai callback dell'applicazione o sottoposti a commit nello spazio di archiviazione multimediale

7.5.3. Comportamento dell'API Camera

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API relative alla fotocamera, sia per le fotocamere anteriori che posteriori:

1. Se un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int), il dispositivo DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione.
2. 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 in byte[] passati a onPreviewFrame() devono essere inoltre nel formato di codifica NV21. In altre parole, NV21 DEVE essere il valore predefinito.
3. Le implementazioni dei dispositivi DEVONO supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia per le fotocamere anteriori che posteriori. Il decodificatore video hardware e la fotocamera possono utilizzare qualsiasi formato di pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione in YV12.

Le implementazioni dei dispositivi DEVONO implementare l'API Camera completa inclusa nella documentazione dell'SDK Android 4.0 [Risorse, 51], indipendentemente dal fatto che il dispositivo includa l'autofocus hardware o altre funzionalità. Ad esempio, le videocamere prive di messa a fuoco automatica DEVONO comunque chiamare eventuali istanze android.hardware.Camera.AutoFocusCallback registrate (anche se questo non ha alcuna rilevanza per una videocamera senza messa a fuoco automatica). Tieni presente che questo vale anche per le fotocamere anteriori. Ad esempio, anche se la maggior parte delle fotocamere anteriori non supporta la messa a fuoco automatica, i callback dell'API devono comunque essere "falsi" come descritto.

Le implementazioni dei dispositivi DEVONO riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters, se l'hardware di base supporta la funzionalità. Se l'hardware del dispositivo non supporta una funzionalità, l'API deve comportarsi come descritto nella documentazione. Al contrario, le implementazioni del dispositivo NON DEVONO rispettare o riconoscere le costanti di stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. In altre parole, le implementazioni dei dispositivi DEVONO supportare tutti i parametri della fotocamera standard se il hardware lo consente e NON DEVONO supportare i tipi di parametri della fotocamera personalizzati.

Le implementazioni dei dispositivi DEVONO trasmettere l'intent Camera.ACTION_NEW_PICTURE ogni volta che la fotocamera scatta una nuova foto e la voce della foto è stata aggiunta al media store.

Le implementazioni dei dispositivi DEVONO trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e l'elemento della foto è stato aggiunto al media store.

7.5.4. Orientamento della fotocamera

Entrambe le fotocamere anteriori e posteriori, se presenti, DEVONO essere orientate in modo che la dimensione lunga della fotocamera sia allineata alla dimensione lunga dello schermo. ovvero, quando il dispositivo è tenuto in orizzontale, le fotocamere DEVONO acquisire le immagini in orizzontale. Questo vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica ai dispositivi con orientamento principale orizzontale e verticale.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

Le implementazioni dei dispositivi DEVONO avere almeno 340 MB di memoria a disposizione per il kernel e lo spazio utente. I 340 MB DEVONO essere aggiuntivi rispetto alla memoria dedicata ai componenti hardware come radio, video e così via che non sono sotto il controllo del kernel.

Le implementazioni dei dispositivi DEVONO avere almeno 350 MB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione. In altre parole, la partizione /data DEVE essere di almeno 350 MB.

Le API Android includono un gestore dei download che le applicazioni possono utilizzare per scaricare file di dati [Risorse, 56]. L'implementazione del gestore dei download sul dispositivo DEVE essere in grado di scaricare singoli file di dimensioni pari o superiori a 100 MB nella posizione predefinita "cache".

7.6.2. Spazio di archiviazione condiviso dell'applicazione

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

Le implementazioni dei dispositivi DEVONO essere configurate con lo spazio di archiviazione condiviso montato per impostazione predefinita, "out of the box". Se lo spazio di archiviazione condiviso non è montato sul percorso /sdcard di Linux, il dispositivo DEVE includere un link simbolico Linux da /sdcard al punto di montaggio effettivo.

Le implementazioni dei dispositivi DEVONO applicare l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE su questo spazio di archiviazione condiviso come descritto nella documentazione. In caso contrario, lo spazio di archiviazione condiviso DEVE essere scrivibile da qualsiasi applicazione che ottiene l'autorizzazione.

Le implementazioni dei dispositivi POSSONO avere hardware per lo spazio di archiviazione rimovibile accessibile all'utente, ad esempio una scheda Secure Digital. In alternativa, le implementazioni dei dispositivi possono allocare lo spazio di archiviazione interno (non rimovibile) come spazio di archiviazione condiviso per le app.

Indipendentemente dalla forma di archiviazione condivisa utilizzata, le implementazioni dei dispositivi DEVONO fornire un qualche meccanismo per accedere ai contenuti dell'archiviazione condivisa da un computer host, ad esempio archiviazione di massa USB (UMS) o Media Transfer Protocol (MTP). Le implementazioni dei dispositivi POSSONO utilizzare l'archiviazione di massa USB, ma DEVONO utilizzare il protocollo Media Transfer. Se l'implementazione del dispositivo supporta il Media Transfer Protocol:

• L'implementazione del dispositivo DEVE essere compatibile con l'host MTP Android di riferimento, Android File Transfer [Risorse, 57].
• L'implementazione del dispositivo DEVE segnalare una classe di dispositivo USB pari a 0x00.
• L'implementazione del dispositivo DEVE riportare un nome dell'interfaccia USB di "MTP".

Se l'implementazione del dispositivo non dispone di porte USB, DEVE fornire a un computer host l'accesso ai contenuti dello spazio di archiviazione condiviso con altri mezzi, ad esempio un file system di rete.

È utile considerare due esempi comuni. Se l'implementazione di un dispositivo include uno slot per schede SD per soddisfare il requisito di archiviazione condivisa, È OBBLIGATORIO includere una scheda SD formattata FAT di almeno 1 GB con il dispositivo venduto agli utenti e deve essere montata per impostazione predefinita. In alternativa, se l'implementazione di un dispositivo utilizza spazio di archiviazione interno fisso per soddisfare questo requisito, lo spazio di archiviazione DEVE avere una dimensione minima di 1 GB e essere montato su /sdcard (o /sdcard DEVE essere un link simbolico alla posizione fisica se è montato altrove).

Le implementazioni dei dispositivi che includono più percorsi di archiviazione condivisi (ad esempio un attacco per schede SD e una memoria interna condivisa) DEVONO modificare le applicazioni di base come lo scanner multimediale e ContentProvider per supportare in modo trasparente i file posizionati in entrambe le posizioni.

7.7. USB

Le implementazioni dei dispositivi DEVONO includere una porta client USB e DEVONO includere una porta host USB.

Se l'implementazione di un dispositivo include una porta client USB:

• La porta DEVE essere connettibile a un host USB con una porta USB-A standard
• la porta DEVE utilizzare il fattore di forma micro USB sul lato del dispositivo
• DEVE consentire a un host connesso al dispositivo di accedere ai contenuti del volume dello spazio di archiviazione condiviso utilizzando l'archiviazione di massa USB o il protocollo Media Transfer
• DEVE implementare l'API e le specifiche Android Open Accessory come descritto nella documentazione dell'SDK Android e DEVE dichiarare il supporto della funzionalità hardwareandroid.hardware.usb.accessory [Risorse, 51]

Se l'implementazione di un dispositivo include una porta host USB:

• Può utilizzare un fattore di forma della porta non standard, ma in questo caso DEVE essere fornito con un cavo o cavi che adattano la porta a USB-A standard
• DEVE implementare l'API host USB Android come descritto nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardwareandroid.hardware.usb.host [Risorse, 52]

Le implementazioni dei dispositivi DEVONO implementare Android Debug Bridge. Se l'implementazione di un dispositivo omette una porta client USB, DEVE implementare il ponte di debug Android tramite una rete locale (ad esempio Ethernet o 802.11).

8. Compatibilità con il rendimento

Le implementazioni dei dispositivi DEVONO soddisfare le metriche di prestazioni chiave di un dispositivo compatibile con Android 4.0 definite nella tabella seguente:

Metrica	Soglia di rendimento	Commenti
Ora di lancio dell'applicazione	Le seguenti applicazioni devono essere lanciate entro il periodo di tempo specificato. Browser: meno di 1300 ms Contatti: meno di 700 ms Impostazioni: meno di 700 ms	Il tempo di lancio viene misurato come tempo totale necessario 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 avviate più applicazioni, il riavvio di un'applicazione già in esecuzione dopo l'avvio deve richiedere meno tempo rispetto al tempo di avvio originale.

9. Compatibilità del modello di sicurezza

Le implementazioni dei dispositivi DEVONO implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API [Risorse, 54] della documentazione per gli sviluppatori Android. Le implementazioni dei dispositivi DEVONO supportare l'installazione di applicazioni con firma autografa senza richiedere autorizzazioni/certificati aggiuntivi da parte di terze parti/autorità. Nello specifico, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle seguenti sottosezioni.

9.1. Autorizzazioni

Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android [Risorse, 54]. Nello specifico, le implementazioni DEVONO applicare ogni autorizzazione definita come descritto nella documentazione dell'SDK. Nessuna autorizzazione può essere omessa, modificata o ignorata. Le implementazioni POSSONO aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe ID autorizzazione non siano nello spazio dei nomi android.*.

9.2. Isolamento UID e dei processi

Le implementazioni dei dispositivi DEVONO supportare il modello di sandbox delle applicazioni Android, in cui ogni applicazione viene eseguita come UID di tipo Unix univoco e in un processo distinto. Le implementazioni dei dispositivi DEVONO supportare l'esecuzione di più applicazioni come lo stesso ID utente Linux, a condizione che le applicazioni siano correttamente firmate e costruite, come definito nella documentazione di riferimento Sicurezza e autorizzazioni [Risorse, 54].

9.3. Autorizzazioni del file system

Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni di accesso ai file di Android come definito nella documentazione di riferimento Sicurezza e autorizzazioni [Risorse, 54].

9.4. Ambienti di esecuzione alternativi

Le implementazioni dei dispositivi POSSONO includere ambienti di runtime che eseguono applicazioni utilizzando un altro software o tecnologia rispetto alla macchina virtuale Dalvik o al codice nativo. Tuttavia, questi ambienti di esecuzione alternativi NON DEVONO compromettere il modello di sicurezza di Android o la sicurezza delle applicazioni Android installate, come descritto in questa sezione.

I runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella Sezione 9.

Ai runtime alternativi NON DEVE essere concesso l'accesso alle risorse protette da autorizzazioni non richieste nel file AndroidManifest.xml del runtime tramite il meccanismo <uses-permission>.

I runtime alternativi NON DEVONO consentire alle applicazioni di utilizzare funzionalità protette dalle autorizzazioni Android limitate alle applicazioni di sistema.

I runtime alternativi DEVONO rispettare il modello di sandbox di Android. Nello specifico:

• I runtime alternativi DOVREBBERO installare le app tramite PackageManager in sandbox Android separate (ovvero ID utente Linux e così via).
• I runtime alternativi POSSONO fornire una singola sandbox Android condivisa da tutte le applicazioni che li utilizzano.
• I runtime alternativi e le applicazioni installate che utilizzano un runtime alternativo NON DEVONO riutilizzare la sandbox di qualsiasi altra app installata sul dispositivo, tranne che tramite i meccanismi standard di Android per l'ID utente e il certificato di firma condivisi
• I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere accesso alle sandbox corrispondenti ad altre applicazioni Android.

I runtime alternativi NON DEVONO essere avviati con, concessi o concessi ad altre applicazioni eventuali privilegi del superutente (root) o di qualsiasi altro ID utente.

I file APK dei runtime alternativi POSSONO essere inclusi nell'immagine di sistema di un'implementazione del dispositivo, ma DEVONO essere firmati con una chiave diversa da quella utilizzata per firmare altre applicazioni incluse nell'implementazione del dispositivo.

Quando installi le applicazioni, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione. In altre parole, se un'applicazione deve utilizzare una risorsa del dispositivo per la quale esiste un'autorizzazione Android corrispondente (ad esempio Fotocamera, GPS e così via), il runtime alternativo DEVE informare l'utente che l'applicazione potrà accedere a quella risorsa. Se l'ambiente di runtime non registra le funzionalità dell'applicazione in questo modo, deve elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che utilizza il runtime.

10. Test di compatibilità del software

Le implementazioni dei dispositivi DEVONO superare tutti i test descritti in questa sezione.

Tuttavia, tieni presente che nessun pacchetto di test software è completamente completo. Per questo motivo, gli implementatori dei dispositivi sono vivamente incoraggiati a apportare il numero minimo di modifiche possibili all'implementazione di riferimento e preferita di Android 4.0 disponibile nell'Android Open Source Project. In questo modo, ridurrai al minimo il rischio di introdurre bug che creano incompatibilità che richiedono il rifacimento e potenziali aggiornamenti dei dispositivi.

10.1. Compatibility Test Suite (CTS)

Le implementazioni dei dispositivi DEVONO superare la suite di test di compatibilità Android (CTS) [Risorse, 2] disponibile nell'Android Open Source Project, utilizzando il software di spedizione finale sul dispositivo. Inoltre, gli implementatori dei dispositivi DEVONO utilizzare il più possibile l'implementazione di riferimento nella struttura di Android Open Source e DEVONO garantire la compatibilità in caso di ambiguità nel CTS e per eventuali reimplementazioni di parti del codice sorgente di riferimento.

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi software, anche il CTS potrebbe contenere bug. La CTS verrà numerata indipendentemente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni della CTS per Android 4.0. Le implementazioni dei dispositivi DEVONO superare la versione CTS più recente disponibile al momento del completamento del software del dispositivo.

10.2. Verificatore CTS

Le implementazioni dei dispositivi DEVONO eseguire correttamente tutti i casi applicabili in CTS Verifier. CTS Verifier è incluso nella Compatibility Test Suite e deve essere eseguito da un operatore umano per testare le funzionalità che non possono essere testate da un sistema automatico, ad esempio il funzionamento corretto di una fotocamera e dei sensori.

CTS Verifier include test per molti tipi di hardware, incluso hardware facoltativo. Le implementazioni dei dispositivi DEVONO superare tutti i test per l'hardware di cui sono dotati. Ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente il caso di test dell'accelerometro in CTS Verifier. I casi di test per le funzionalità indicate come facoltative da questo Documento di definizione della compatibilità POSSONO essere saltati o omessi.

Ogni dispositivo e ogni build DEVONO eseguire correttamente CTS Verifier, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori dei dispositivi eseguano esplicitamente il CTS Verifier su build che differiscono solo in modo banale. Nello specifico, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato lo strumento di verifica CTS solo per l'insieme di lingue, branding e così via inclusi POSSONO omettere il test dello strumento di verifica CTS.

10.3. Applicazioni di riferimento

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

• Le applicazioni "App per Android" [Risorse, 55].
• Isola di Replica (disponibile in Android Market)

Affinché l'implementazione sia considerata compatibile, ogni app sopra indicata DEVE essere avviata e comportarsi correttamente nell'implementazione.

11. Software aggiornabile

Le implementazioni dei dispositivi DEVONO includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire upgrade "in tempo reale", ovvero potrebbe essere necessario riavviare il dispositivo.

È possibile utilizzare qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, qualsiasi dei seguenti approccisoddisfa questo requisito:

• Download OTA (over-the-air) con aggiornamento offline tramite riavvio
• Aggiornamenti "in tethering" tramite USB da un PC host
• Aggiornamenti "offline" tramite riavvio e aggiornamento da un file su archiviazione rimovibile

Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. In altre parole, il meccanismo di aggiornamento DEVE preservare i dati privati e condivisi dell'applicazione. Tieni presente che il software Android a monte include un meccanismo di aggiornamento che soddisfa questo requisito.

Se viene rilevato un errore nell'implementazione di un dispositivo dopo il rilascio, ma entro la durata ragionevole del prodotto, stabilita in consultazione con il team di compatibilità di Android, che influisce sulla compatibilità delle applicazioni di terze parti, l'implementatore del dispositivo DEVE correggere l'errore tramite un aggiornamento software disponibile che può essere applicato in base al meccanismo appena descritto.

12. Contattaci

Puoi contattare gli autori del documento all'indirizzo compatibility@android.com per chiedere chiarimenti e segnalare eventuali problemi che ritieni non trattati nel documento.

Appendice A - Procedura di test Bluetooth

La suite di test di compatibilità include casi che coprono il funzionamento di base dell'API Bluetooth RFCOMM di Android. Tuttavia, poiché il Bluetooth è un protocollo di comunicazione tra dispositivi, non può essere testato completamente tramite test di unità eseguiti su un singolo dispositivo. Di conseguenza, le implementazioni dei dispositivi DEVONO superare anche la procedura di test Bluetooth eseguita da persone descritta di seguito.

La procedura di test si basa sull'app di esempio BluetoothChat inclusa nella struttura ad albero del progetto open source Android. La procedura richiede due dispositivi:

• un'implementazione del dispositivo candidato che esegue la build software da testare
• un'implementazione del dispositivo separata già nota per essere compatibile e di un modello diverso dall'implementazione del dispositivo in prova, ovvero un'implementazione del dispositivo "buona"

La procedura di test riportata di seguito fa riferimento a questi dispositivi rispettivamente come "candidato" e "noto come buono".

Configurazione e installazione

1. Crea BluetoothChat.apk tramite "make samples" da una struttura di codice sorgente Android.
2. Installa BluetoothChat.apk sul dispositivo funzionante.
3. Installa BluetoothChat.apk sul dispositivo candidato.

Testare il controllo Bluetooth tramite app

1. Avvia BluetoothChat sul dispositivo candidato, mentre il Bluetooth è disattivato.
2. Verifica che il dispositivo candidato attivi il Bluetooth o chieda all'utente di attivarlo tramite una finestra di dialogo.

Verificare l'accoppiamento e la comunicazione

1. Avvia l'app Chat Bluetooth su entrambi i dispositivi.
2. Rendi rilevabile il dispositivo di cui è nota la funzionalità da BluetoothChat (utilizzando il menu).
3. Sul dispositivo candidato, cerca i dispositivi Bluetooth da BluetoothChat (utilizzando il menu) e accoppialo con il dispositivo di cui è nota la funzionalità.
4. Invia almeno 10 messaggi da ciascun dispositivo e verifica che l'altro dispositivo li riceva correttamente.
5. Chiudi l'app BluetoothChat su entrambi i dispositivi premendo Home.
6. Disaccoppia ciascun dispositivo dall'altro utilizzando l'app Impostazioni del dispositivo.

Testare l'accoppiamento e la comunicazione nella direzione opposta

1. Avvia l'app Chat Bluetooth su entrambi i dispositivi.
2. Rendi rilevabile il dispositivo candidato da BluetoothChat (utilizzando il menu).
3. Sul dispositivo funzionante, cerca i dispositivi Bluetooth da BluetoothChat (utilizzando il menu) e accoppiati con il dispositivo candidato.
4. Invia 10 messaggi da ciascun dispositivo e verifica che l'altro dispositivo li riceva correttamente.
5. Chiudi l'app Chat Bluetooth su entrambi i dispositivi premendo Indietro ripetutamente per accedere all'Avvio applicazioni.

Testare i nuovi lanci

1. Riavvia l'app Chat Bluetooth su entrambi i dispositivi.
2. Invia 10 messaggi da ciascun dispositivo e verifica che l'altro dispositivo li riceva correttamente.

Nota: i test precedenti hanno alcuni casi in cui una sezione di test termina utilizzando Altre app e altri utilizzando Indietro. Questi test non sono ridondanti e non sono facoltativi: lo scopo è verificare che l'API e lo stack Bluetooth funzionino correttamente sia quando le attività vengono terminate esplicitamente (tramite il pulsante Indietro dell'utente, che chiama finish()), sia quando vengono inviate implicitamente in background (tramite il pulsante Casa dell'utente). Ogni sequenza di test DEVE essere eseguita come descritto.