Definizione di compatibilità di Android 2.3

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

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

Indice

1. Introduzione

Questo documento elenca i requisiti che devono essere soddisfatti affinché gli smartphone siano compatibili con Android 2.3.

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 di dispositivi" o "implementatore" è una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 2.3. Un'"implementazione del dispositivo" o "implementazione" è la soluzione hardware/software così sviluppata.

Per essere considerate compatibili con Android 2.3, 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.

Tieni presente che questa definizione di compatibilità è stata rilasciata in corrispondenza dell'aggiornamento 2.3.3 di Android, ovvero del livello API 10. Questa definizione rende obsoleta e sostituisce la definizione di compatibilità per le versioni di Android 2.3 precedenti alla versione 2.3.3. Ciò significa che le versioni 2.3.1 e 2.3.2 sono obsolete. I futuri dispositivi compatibili con Android che utilizzano Android 2.3 DEVONO essere forniti con la versione 2.3.3 o successive.

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 2.3: http://source.android.com/docs/compatibility/2.3/versions.html
8. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. Funzionalità offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
11. Tag video HTML5: http://dev.w3.org/html5/spec/Overview.html#video
12. API Geolocation HTML5/W3C: http://www.w3.org/TR/geolocation-API/
13. API webdatabase HTML5/W3C: http://www.w3.org/TR/webdatabase/
14. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
15. Specifiche della macchina virtuale Dalvik: disponibili nel codice sorgente di Android, in dalvik/docs
16. AppWidget: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
17. Notifiche: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
18. Risorse per le applicazioni: http://code.google.com/android/reference/available-resources.html
19. Guida di stile per le icone della barra di stato: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
20. Gestione ricerche: http://developer.android.com/reference/android/app/SearchManager.html
21. Messaggi popup: http://developer.android.com/reference/android/widget/Toast.html
22. Sfondi animati: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
23. Documentazione dello strumento di riferimento (per adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
24. Descrizione del file APK Android: http://developer.android.com/guide/topics/fundamentals.html
25. File manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html
26. Strumento di test Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
27. Elenco delle funzionalità hardware di Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
28. Supporto di più schermi: http://developer.android.com/guide/practices/screens_support.html
29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
31. Spazio delle coordinate del sensore: http://developer.android.com/reference/android/hardware/SensorEvent.html
32. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html
33. Protocollo NDEF Push: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
40. API di orientamento della fotocamera: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
42. Documentazione di riferimento per la sicurezza e le autorizzazioni di Android: http://developer.android.com/guide/topics/security/security.html
43. App per Android: http://code.google.com/p/apps-for-android

Molte di queste risorse sono ricavate direttamente o indirettamente dall'SDK Android 2.3 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

La piattaforma Android include un insieme di API gestite, un insieme di API native e un insieme di API cosiddette "soft" come il sistema Intent e le API per le applicazioni web. Questa sezione descrive in dettaglio le API hard e soft fondamentali per la compatibilità, nonché alcuni altri comportamenti tecnici e dell'interfaccia utente pertinenti. Le implementazioni dei dispositivi DEVONO essere conformi a tutti i requisiti di questa sezione.

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 2.3 [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. Questa sezione descrive in dettaglio le API "soft" e i comportamenti di sistema richiesti per la compatibilità con Android 2.3. Le implementazioni dei dispositivi DEVONO soddisfare tutti i requisiti presentati in questa sezione.

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 2.3, questo campo DEVE avere il valore intero 9.
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.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/generic:2.3/ERC77/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.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.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 dispositivo. 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.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

Android utilizza gli intent per realizzare un'integrazione con accoppiamento lasco tra le applicazioni. Questa sezione descrive i requisiti relativi ai pattern di Intent che DEVONO essere rispettati dalle implementazioni dei dispositivi. 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 Android upstream definisce una serie di applicazioni di base, come un tastierino telefonico, un calendario, un elenco contatti, un lettore musicale 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
• Calcolatrice
• Contatti
• Email
• 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, gli implementatori dei dispositivi DEVONO consentire a ogni schema di intent a cui si fa riferimento nella Sezione 3.2.3.1 di essere sostituito da applicazioni di terze parti. Il progetto open source Android upstream lo consente per impostazione predefinita. Gli implementatori dei dispositivi NON DEVONO assegnare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema o impedire alle applicazioni di terze parti di associarsi e assumere il controllo di questi pattern. Questo divieto include nello specifico, 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

Gli implementatori 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.*. Gli implementatori di dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando una stringa ACTION, CATEGORY o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione. Gli implementatori dei dispositivi NON DEVONO modificare o estendere nessuno dei pattern di intent utilizzati dalle app di base elencate nella sezione 3.2.3.1.

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

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 upstream

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

• libc (libreria C)
• libm (libreria matematica)
• Supporto minimo per C++
• Interfaccia JNI
• liblog (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 Open Sound Library)
• 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

Molti sviluppatori e applicazioni si basano sul comportamento della classe android.webkit.WebView [Resources, 8] per le loro interfacce utente, pertanto l'implementazione di WebView deve essere compatibile con tutte le implementazioni di Android. Analogamente, un browser web completo e moderno è fondamentale per l'esperienza utente di Android. Le implementazioni dei dispositivi DEVONO includere una versione di android.webkit.WebView coerente con il software Android a monte e DEVONO includere un browser moderno compatibile con HTML5, come descritto di seguito.

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 533.1 dell'albero Android Open Source per Android 2.3. 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/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
  • Il valore della stringa $(VERSION) DEVE essere uguale al valore di android.os.Build.VERSION.RELEASE
  • Il valore della stringa $(LOCALE) 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, 9]. Come minimo, le implementazioni dei dispositivi DEVONO supportare ciascuna di queste API associate a HTML5 in WebView:

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

Inoltre, le implementazioni dei dispositivi DEVONO supportare l'API webstorage HTML5/W3C [Risorse, 13] e DOVREBBERO supportare l'API IndexedDB HTML5/W3C [Risorse, 14]. 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, 9]. Come minimo, le implementazioni dei dispositivi DEVONO supportare ciascuna di queste API associate a HTML5:

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

Inoltre, le implementazioni dei dispositivi DEVONO supportare l'API webstorage HTML5/W3C [Risorse, 13] e DOVREBBERO supportare l'API IndexedDB HTML5/W3C [Risorse, 14]. 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, 15].

Le implementazioni dei dispositivi con schermi classificati come a densità media o bassa devono configurare Dalvik in modo da allocare almeno 16 MB di memoria a ogni applicazione. Le implementazioni dei dispositivi con schermi classificati come ad alta densità o extra-alta densità DEVONO configurare Dalvik per allocare almeno 24 MB di memoria a ogni applicazione. Tieni presente che le implementazioni dei dispositivi POTREBBERO allocare più memoria di queste cifre.

3.8. Compatibilità dell'interfaccia utente

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

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, 16]. La release di riferimento di Android Open Source include un'applicazione Avvio app che include elementi dell'interfaccia utente che consentono all'utente di aggiungere, visualizzare e rimuovere AppWidget dalla schermata Home.

Gli implementatori 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 ed esporre elementi 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'implementatore del dispositivo DEVE fornire un'applicazione separata accessibile dal lanciatore che consenta agli utenti di aggiungere, configurare, visualizzare e rimuovere gli AppWidget.

3.8.2. Notifiche

Android include API che consentono agli sviluppatori di notificare agli utenti eventi importanti [Risorse, 17]. Gli implementatori di dispositivi DEVONO fornire supporto per ogni classe di notifica così definita; nello specifico: suoni, vibrazione, luce e barra di stato.

Inoltre, l'implementazione DEVE eseguire il rendering corretto di tutte le risorse (icone, file audio e così via) previste nelle API [Risorse, 18] o nella guida di stile delle icone della barra di stato [Risorse, 19]. 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 indicato sopra.

3.8.3. Cerca

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

Le implementazioni dei dispositivi POSSONO includere interfacce utente di ricerca alternative, ma DEVONO includere un pulsante di ricerca dedicato, hard o soft, che può essere utilizzato in qualsiasi momento in qualsiasi app per richiamare il framework di ricerca, con il comportamento previsto nella documentazione dell'API.

3.8.4. Auguri

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

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

Le implementazioni dei dispositivi NON DEVONO estendere i formati .apk [Risorse, 24], Android Manifest [Risorse, 25] o bytecode di Dalvik [Risorse, 15] 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 implementare completamente tutte le API multimediali. Le implementazioni dei dispositivi DEVONO includere il supporto di tutti i codec multimediali descritti di seguito e DEVONO soddisfare le linee guida per l'elaborazione dell'audio descritte di seguito. 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 codec multimediali come descritto nelle seguenti sezioni. Tutti questi codec sono forniti come implementazioni software nell'implementazione Android preferita del progetto Android Open Source.

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 titolari di brevetti pertinenti.

Le tabelle riportate di seguito non elencano requisiti specifici per la velocità in bit per la maggior parte dei codec video. Il motivo è che, in pratica, l'hardware dei dispositivi attuali non supporta necessariamente le velocità in bit che corrispondono esattamente alle velocità in bit richieste specificate dagli standard pertinenti. Le implementazioni dei dispositivi DEVONO supportare la massima velocità in bit possibile sull'hardware, fino ai limiti definiti dalle specifiche.

5.1.1. Decoder multimediali

Le implementazioni dei dispositivi DEVONO includere un'implementazione di un decodificatore per ogni codec e formato descritto nella tabella seguente. Tieni presente che i decodificatori per ciascuno di questi tipi di contenuti multimediali sono forniti dall'Android Open Source Project.

Audio
	Nome	Dettagli	Formato file/container
	AAC LC/LTP	Contenuti mono/stereo in qualsiasi combinazione di velocità in bit standard fino a 160 Kbps e frequenze di campionamento comprese tra 8 e 48 kHz	3GPP (.3gp) e MPEG-4 (.mp4, .m4a). Nessun supporto per AAC non compresso (.aac)
	HE-AACv1 (AAC+)
	HE-AACv2 (AAC+ migliorato)
	AMR-NB	4,75-12,2 Kbps campionati a 8 kHz	3GPP (.3gp)
	AMR-WB	9 frequenze da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz	3GPP (.3gp)
	MP3	Mono/stereo 8-320 Kbps a velocità in bit costante (CBR) o variabile (VBR)	MP3 (.mp3)
	MIDI	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). Sono supportati anche i formati RTTTL/RTX (.rtttl, .rtx), OTA (.ota) e iMelody (.imy)
	Ogg Vorbis		Ogg (.ogg)
	PCM	PCM lineare a 8 e 16 bit (frequenze fino al limite dell'hardware)	WAVE (.wav)
Immagine
	JPEG	base+progressive
	GIF
	PNG
	BMP
Video
	H.263		File 3GPP (.3gp)
	H.264		File 3GPP (.3gp) e MPEG-4 (.mp4)
	Profilo semplice MPEG4		File 3GPP (.3gp)

5.1.2. Codificatori multimediali

Le implementazioni dei dispositivi DEVONO includere codificatori per il maggior numero possibile di formati media elencati nella Sezione 5.1.1. Tuttavia, alcuni codificatori non hanno senso per i dispositivi che non dispongono di determinati componenti hardware facoltativi. Ad esempio, un codificatore per il video H.263 non ha senso se il dispositivo non dispone di videocamere. Le implementazioni dei dispositivi DEVONO quindi implementare gli encoder multimediali in base alle condizioni descritte nella tabella seguente.

Consulta la Sezione 7 per informazioni dettagliate sulle condizioni in cui l'hardware può essere omesso dalle implementazioni dei dispositivi.

Audio
	Nome	Dettagli	Formato file/container	Condizioni
	AMR-NB	4,75-12,2 Kbps campionati a 8 kHz	3GPP (.3gp)	Le implementazioni dei dispositivi che includono hardware per microfoni e definiscono android.hardware.microphone DEVONO includere codificatori per questi formati audio.
	AMR-WB	9 frequenze da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz	3GPP (.3gp)
	AAC LC/LTP	Contenuti mono/stereo in qualsiasi combinazione di velocità in bit standard fino a 160 Kbps e frequenze di campionamento comprese tra 8 e 48 kHz	3GPP (.3gp) e MPEG-4 (.mp4, .m4a).
Immagine	JPEG	base+progressive		Tutte le implementazioni dei dispositivi DEVONO includere codificatori per questi formati di immagini, poiché Android 2.3 include API che le applicazioni possono utilizzare per generare ed eseguire codice per generare file di questi tipi.
	PNG
Video	H.263		File 3GPP (.3gp)	Le implementazioni dei dispositivi che includono l'hardware della videocamera e definiscono android.hardware.camera o android.hardware.camera.front DEVONO includere codificatori per questi formati video.

Oltre agli encoder elencati sopra, le implementazioni dei dispositivi DOVREBBERO includere un encoder H.264. Tieni presente che è previsto di modificare questo requisito in "DEVE" nella definizione di compatibilità di una versione futura. In altre parole, la codifica H.264 è facoltativa in Android 2.3, ma sarà obbligatoria in una versione futura. I dispositivi esistenti e nuovi che eseguono Android 2.3 sono vivamente invitati a soddisfare questo requisito in Android 2.3, altrimenti non potranno ottenere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

5.2. Registrazione audio

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

• L'elaborazione di riduzione del rumore, se presente, DEVE essere disattivata.
• Il controllo automatico del guadagno, se presente, DEVE essere disattivato.
• Il dispositivo DEVE presentare caratteristiche di ampiezza approssimativamente piatte rispetto alla frequenza; in particolare, ±3 dB, da 100 Hz a 4000 Hz
• La sensibilità dell'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 5000 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.

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

5.3. 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 dettagli sulle condizioni in cui l'hardware del microfono può essere omesso dalle implementazioni dei dispositivi.

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 2.3, è previsto di modificarli in "DEVE" nella definizione di compatibilità per una versione futura. In altre parole, questi requisiti sono facoltativi in Android 2.3, ma saranno obbligatori in una versione futura. I dispositivi esistenti e nuovi che eseguono Android 2.3 sono vivamente invitati a soddisfare questi requisiti in Android 2.3, altrimenti non potranno ottenere 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, 27] Al contrario, se l'implementazione del dispositivo non soddisfa questi requisiti, NON DEVE segnalare il supporto dell'audio a bassa latenza.

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, 23]
  Le implementazioni dei dispositivi DEVONO supportare tutte le funzioni adb come documentato nell'SDK Android. Il daemon adb lato dispositivo DOVREBBE essere inattivo per impostazione predefinita, ma DEVE essere presente un meccanismo accessibile all'utente per attivare Android Debug Bridge.
• Dalvik Debug Monitor Service (noto come ddms) [Risorse, 23]
  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, 26]
  Le implementazioni dei dispositivi 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

Android è progettato per consentire agli implementatori di dispositivi di creare configurazioni e fattori di forma innovativi. Allo stesso tempo, gli sviluppatori Android scrivono applicazioni innovative che si basano sul diverso hardware e sulle varie funzionalità disponibili tramite le API Android. I requisiti riportati in questa sezione trovano un equilibrio tra le innovazioni disponibili per gli implementatori dei dispositivi e le esigenze degli sviluppatori di garantire che le loro app siano disponibili solo sui dispositivi su cui funzioneranno correttamente.

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 lo possiede:

• 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 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. [Risorse, 27]

7.1. Display e grafica

Android 2.3 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, 28]. I dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

7.1.1. Configurazioni schermo

Le implementazioni dei dispositivi POSSONO utilizzare schermate di qualsiasi dimensione in pixel, a condizione che soddisfino i seguenti requisiti:

• Le dimensioni fisiche diagonali degli schermi DEVONO essere di almeno 6,35 cm
• La densità DEVE essere di almeno 100 dpi
• Le proporzioni DEVONO essere comprese tra 1,333 (4:3) e 1,779 (16:9)
• la tecnologia di visualizzazione utilizzata è composta da pixel quadrati

Le implementazioni dei dispositivi con uno schermo che soddisfa i requisiti sopra indicati sono considerate compatibili e non sono necessarie altre azioni. L'implementazione del framework Android calcola automaticamente le caratteristiche del display, come il bucket delle dimensioni dello schermo e il bucket della densità. Nella maggior parte dei casi, le decisioni del framework sono quelle corrette. Se vengono utilizzati i calcoli del framework predefinito, non è necessaria alcuna azione aggiuntiva. Gli implementatori di dispositivi che vogliono modificare i valori predefiniti o utilizzare uno schermo che non soddisfa i requisiti di cui sopra DEVONO contattare il team di compatibilità Android per ricevere indicazioni, come previsto dalla Sezione 12.

Le unità utilizzate dai requisiti riportati sopra 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".

Le implementazioni dei dispositivi DEVONO utilizzare solo display con una singola configurazione statica. In altre parole, le implementazioni dei dispositivi NON DEVONO attivare più configurazioni dello schermo. Ad esempio, poiché una normale televisione supporta più risoluzioni, come 1080p, 720p e così via, questa configurazione non è compatibile con Android 2.3. Tuttavia, il supporto di queste configurazioni è in fase di indagine e pianificato per una versione futura di Android.

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

7.1.3. Supporto dello schermo dichiarato

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, medi e grandi, come descritto nella documentazione dell'SDK Android.

7.1.4. Orientamento schermo

I dispositivi compatibili DEVONO supportare l'orientamento dinamico da parte 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 che non possono essere ruotati fisicamente POTREBBERO soddisfare questo requisito mediante l'applicazione di "letterboxing" alle applicazioni che richiedono la modalità Ritratto, utilizzando solo una parte del display disponibile.

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.

7.1.5. Accelerazione grafica 3D

Le implementazioni dei dispositivi DEVONO supportare OpenGL ES 1.0, come richiesto dalle API Android 2.3. Per i dispositivi che non dispongono di hardware di accelerazione 3D, il progetto open source Android fornisce un'implementazione software di OpenGL ES 1.0. Le implementazioni dei dispositivi DEVONO supportare OpenGL ES 2.0.

Le implementazioni POSSONO omettere il supporto di Open GL ES 2.0. Tuttavia, se il supporto viene omesso, le implementazioni del dispositivo NON DEVONO segnalare il supporto di OpenGL ES 2.0. Nello specifico, se le implementazioni di un dispositivo non supportano OpenGL ES 2.0:

• le API gestite (ad esempio tramite il metodo GLES10.getString()) NON DEVONO segnalare il supporto di OpenGL ES 2.0
• Le API OpenGL native C/C++ (ovvero quelle disponibili per le app tramite libGLES_v1CM.so, libGLES_v2.so o libEGL.so) NON DEVONO segnalare il supporto per OpenGL ES 2.0.

Al contrario, se un'implementazione del dispositivo supporta OpenGL ES 2.0, deve segnalare con precisione questo supporto tramite le route appena elencate.

Tieni presente che Android 2.3 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 2.3 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.

7.2. Dispositivi di immissione

Android 2.3 supporta una serie di modalità per l'input dell'utente. Le implementazioni dei dispositivi DEVONO supportare i dispositivi di input dell'utente come previsto in questa sezione.

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 tastiere virtuali) come descritto su developer.android.com
• DEVE fornire almeno un'implementazione della tastiera su schermo (indipendentemente dal fatto che sia presente 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, 30] (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 una rotella)
• DEVE riportare il valore corretto per android.content.res.Configuration.navigation [Resources, 30]
• 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 codice open source Android upstream include un meccanismo di selezione adatto all'uso con i 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, indipendentemente dallo stato dell'applicazione. Queste funzioni DEVONO essere implementate tramite pulsanti dedicati. POSSONO essere implementati utilizzando software, gesti, pannelli touch e così via, ma in questo caso DEVONO essere sempre accessibili e non oscurare o interferire con l'area di visualizzazione dell'applicazione disponibile.

Gli implementatori dei dispositivi DEVONO anche fornire una chiave di ricerca dedicata. Gli implementatori di dispositivi POSSONO anche fornire tasti di invio e di fine per le chiamate.

7.2.4. Input touchscreen

Implementazioni dei dispositivi:

• DEVE avere un touchscreen
• PUO' avere un touchscreen capacitivo o resistivo
• DEVE riportare il valore di android.content.res.Configuration [Resources, 30] che corrisponde al tipo di touchscreen specifico sul dispositivo
• DOVREBBE supportare cursori monitorati in modo completamente indipendente, se il touchscreen supporta più cursori

7.3. Sensori

Android 2.3 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. [Risorse, 27]
• 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).

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 2.3 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 2.3 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, 31])
• 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, 31]).
• DEVE essere in grado di campionare un intervallo di intensità di campo adeguato a 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 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 un'accuratezza di almeno 8 bit

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

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

La connettività di rete e l'accesso a internet sono funzionalità vitali di Android. Nel frattempo, l'interazione tra dispositivi aggiunge un valore significativo ai dispositivi e alle applicazioni Android. Le implementazioni dei dispositivi DEVONO soddisfare i requisiti di connettività dei dati riportati in questa sezione.

7.4.1. Telefonia

"Telefonia", come utilizzato dalle API Android 2.3 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 dei pacchetti, ai fini di Android 2.3 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 2.3 PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. In altre parole, Android 2.3 è 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 2.3 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, 32]. 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 metodoandroid.content.pm.PackageManager.hasSystemFeature(). [Risorse, 27]
• 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 NFC Forum NFCForum-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • NfcV (ISO 15693)
    • IsoDep (ISO 14443-4)
    • Tipi di tag NFC Forum 1, 2, 3, 4 (definiti dal NFC Forum)
  • 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, 33]
  • DEVE cercare tutte le tecnologie supportate in modalità di rilevamento NFC.
  • DOVREBBE essere in modalità di rilevamento NFC quando il dispositivo è attivo con lo schermo attivo.

  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 DEVONO supportare le seguenti tecnologie MIFARE ampiamente implementate.

  • MIFARE Classic (NXP MF1S503x [Risorse, 34], MF1S703x [Risorse, 35])
  • MIFARE Ultralight (NXP MF0ICU1 [Risorse, 36], MF0ICU2 [Risorse, 37])
  • NDEF su MIFARE Classic (NXP AN130511 [Risorse, 38], AN130411 [Risorse, 39])

  Tieni presente che Android 2.3.3 include le API per questi tipi di MIFARE. Se un'implementazione del dispositivo supporta MIFARE:

  • 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, 27] 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, 27] e DEVE implementare l'API NFC di Android 2.3 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 2.3 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, 40], 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 i dati delle immagini restituiti a qualsiasi gestore di callback della fotocamera "postview", nello stesso modo dello stream di immagini dell'anteprima della fotocamera. Se l'implementazione del dispositivo non supporta i callback 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 di 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. Tieni presente che nella definizione di compatibilità per una versione futura è previsto di modificare questo requisito in "DEVE". In altre parole, il supporto di YV12 è facoltativo in Android 2.3, ma verrà richiesto da una versione futura. I dispositivi esistenti e nuovi con Android 2.3 sono vivamente invitati a soddisfare questo requisito in Android 2.3, altrimenti non potranno raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

  Le implementazioni dei dispositivi DEVONO implementare l'API Camera completa inclusa nella documentazione dell'SDK Android 2.3 [Risorse, 41], 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.

  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

  La funzione fondamentale di Android 2.3 è eseguire applicazioni. Le implementazioni dei dispositivi DEVONO soddisfare i requisiti di questa sezione per garantire spazio di archiviazione e memoria adeguati per il corretto funzionamento delle applicazioni.

  7.6.1. Memoria e spazio di archiviazione minimi

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

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

  Oltre ai requisiti sopra indicati, le implementazioni dei dispositivi DEVONO avere almeno 1 GB di spazio di archiviazione non volatile disponibile per i dati utente. Tieni presente che questo requisito più elevato dovrebbe diventare obbligatorio in una versione futura di Android. Le implementazioni dei dispositivi sono vivamente incoraggiate a soddisfare subito questi requisiti, altrimenti potrebbero non essere idonee per la compatibilità con una versione futura di Android.

  Le API Android includono un gestore dei download che le applicazioni possono utilizzare per scaricare i file di dati. L'implementazione di Download Manager DEVE essere in grado di scaricare singoli file di dimensioni pari o superiori a 55 MB. L'implementazione di Download Manager DEVE essere in grado di scaricare file di dimensioni pari o superiori a 100 MB.

  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 l'archiviazione di massa USB o il Media Transfer Protocol.

  È 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

  Implementazioni dei dispositivi:

  • DEVE implementare un client USB, collegabile a un host USB con una porta USB-A standard
  • DEVE implementare Android Debug Bridge tramite USB (come descritto nella sezione 7)
  • DEVE implementare la specifica dell'archivio di massa USB per consentire a un host collegato al dispositivo di accedere ai contenuti del volume /sdcard
  • DOVREBBE utilizzare il fattore di forma micro USB sul lato del dispositivo
  • PUO' includere una porta non standard sul lato del dispositivo, ma in questo caso DEVE essere fornito con un cavo in grado di collegare il pinout personalizzato alla porta USB-A standard

  8. Compatibilità con il rendimento

  Le implementazioni compatibili devono garantire non solo che le applicazioni funzionino correttamente sul dispositivo, ma anche che lo facciano con prestazioni ragionevoli e un'esperienza utente complessivamente positiva. Le implementazioni dei dispositivi DEVONO soddisfare le metriche di prestazioni chiave di un dispositivo compatibile con Android 2.3 definite nella tabella di seguito:

  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 MMS/SMS: meno di 700 ms AlarmClock: meno di 650 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, 42] 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, 42]. 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 firmate e costruite correttamente, come definito nella documentazione di riferimento Sicurezza e autorizzazioni [Risorse, 42].

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

  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

  Android Open Source Project include vari strumenti di test per verificare che le implementazioni dei dispositivi siano compatibili. 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 2.3 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. Il CTS verrà sottoposto a versionamento indipendentemente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni del CTS per Android 2.3. Le implementazioni dei dispositivi DEVONO superare la versione CTS più recente disponibile al momento del completamento del software del dispositivo.

  DEVE superare la versione più recente del Compatibility Test Suite (CTS) di Android disponibile al momento del completamento del software di implementazione del dispositivo. Il CTS è disponibile nell'ambito dell'Android Open Source Project [Risorse, 2]. Il CTS testa molti, ma non tutti, i componenti descritti in questo documento.

  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 di dispositivi DEVONO testare la compatibilità dell'implementazione utilizzando le seguenti applicazioni open source:

  • Le applicazioni "App per Android" [Risorse, 43].
  • Replica Island (disponibile in Android Market; obbligatoria solo per le implementazioni di dispositivi con supporto OpenGL ES 2.0)

  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. Tieni presente che il software Android upstream include un meccanismo di aggiornamento chesoddisfa 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 fase di test, 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.