Definizione di compatibilità di Android 2.2

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

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

Per essere considerate compatibili con Android 2.2, le implementazioni dei dispositivi:

• DEVONO soddisfare i requisiti presentati in questa definizione di compatibilità, inclusi eventuali documenti incorporati tramite riferimento.
• 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.

Se questa definizione o la CTS non sono chiare, ambigue o incomplete, è 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 sul codice sorgente "upstream" disponibile nel progetto open source Android. Sebbene alcuni componenti possano essere ipocritamente sostituiti con implementazioni alternative, questa pratica è vivamente sconsigliata, in quanto superare i test CTS diventerà notevolmente più difficile. È responsabilità dell'implementatore garantire la piena compatibilità comportamentale con l'implementazione Android standard, incluso e oltre il Compatibility Test Suite. Infine, tieni presente che alcune sostituzioni e modifiche dei componenti sono vietate esplicitamente da questo documento.

2. Risorse

1. Livelli di requisiti RFC2119 IETF: http://www.ietf.org/rfc/rfc2119.txt
2. Panoramica del Programma di compatibilità Android: http://source.android.com/docs/compatibility/index.html
3. Android Open Source Project: http://source.android.com/
4. Definizioni e documentazione dell'API: http://developer.android.com/reference/packages.html
5. Documentazione di riferimento per le autorizzazioni Android: http://developer.android.com/reference/android/Manifest.permission.html
6. Riferimento android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. Stringhe di versione consentite per Android 2.2: http://source.android.com/docs/compatibility/2.2/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. Specifiche della macchina virtuale Dalvik: disponibili nel codice sorgente di Android, in dalvik/docs
11. AppWidget: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
12. Notifiche: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
13. Risorse per le applicazioni: http://code.google.com/android/reference/available-resources.html
14. Guida di stile per le icone della barra di stato: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
15. Gestione ricerche: http://developer.android.com/reference/android/app/SearchManager.html
16. Messaggi popup: http://developer.android.com/reference/android/widget/Toast.html
17. Sfondi animati: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
18. App per Android: http://code.google.com/p/apps-for-android
19. Documentazione dello strumento di riferimento (per adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
20. Descrizione del file APK Android: http://developer.android.com/guide/topics/fundamentals.html
21. File manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html
22. Strumento di test Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
23. Elenco delle funzionalità hardware di Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
24. Supporto di più schermi: http://developer.android.com/guide/practices/screens_support.html
25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
28. Spazio delle coordinate del sensore: http://developer.android.com/reference/android/hardware/SensorEvent.html
29. Documentazione di riferimento per la sicurezza e le autorizzazioni di Android: http://developer.android.com/guide/topics/security/security.html
30. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

Molte di queste risorse sono ricavate direttamente o indirettamente dall'SDK Android 2.2 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.2 [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à.

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.2. 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.2, questo campo DEVE avere il valore intero 8.
android.os.Build.VERSION.INCREMENTAL	Un valore scelto dall'implementatore del dispositivo che designa la build specifica del sistema Android attualmente in esecuzione, in formato leggibile. 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. 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.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. 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.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. 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.FINGERPRINT	Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile da una persona. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ad esempio: acme/mydevice/generic/generic:2.2/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 ("_").
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. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
android.os.Build.MODEL	Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo come noto all'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o una stringa vuota ("").
android.os.Build.PRODUCT	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice del dispositivo. DEVE essere leggibile, ma non necessariamente pensato per essere visualizzato dagli 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.TAGS	Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che contraddistinguono ulteriormente la build. Ad esempio, "unsigned,debug". Questo campo NON deve essere nullo o una stringa vuota (""), ma è accettabile un singolo tag (ad es. "release").
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".
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
• Fotocamera
• Contatti
• Email
• Galleria
• GlobalSearch
• Avvio app
• LivePicker (ovvero l'applicazione di selezione degli sfondi animati; PUÒ essere omessa se il dispositivo non supporta gli sfondi animati, come indicato nella Sezione 3.8.5).
• Messaggistica (noto anche come "MMS")
• Musica
• Telefono
• Impostazioni
• SoundRecorder

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. Le implementazioni dei dispositivi DEVONO includere il supporto per il codice eseguito nell'ambiente gestito per chiamare il codice nativo, utilizzando la semantica standard di Java Native Interface (JNI). Le seguenti API DEVONO essere disponibili per il codice nativo:

• libc (libreria C)
• libm (libreria matematica)
• Interfaccia JNI
• libz (compressione Zlib)
• liblog (logging Android)
• Supporto minimo per C++
• Supporto di OpenGL, come descritto di seguito

Le implementazioni dei dispositivi DEVONO supportare OpenGL ES 1.0. I dispositivi che non dispongono dell'accelerazione hardware DEVONO implementare OpenGL ES 1.0 utilizzando un renderer software. Le implementazioni dei dispositivi DOVREBBERO implementare la maggior parte delle funzionalità di OpenGL ES 1.1 supportate dall'hardware del dispositivo. Le implementazioni dei dispositivi DOVREBBERO fornire un'implementazione per OpenGL ES 2.0, se l'hardware è in grado di offrire prestazioni ragionevoli su queste API.

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

Le implementazioni dei dispositivi DEVONO segnalare con precisione l'interfaccia ABI (Application Binary) nativa supportata dal dispositivo tramite l'APIandroid.os.Build.CPU_ABI. L'ABI DEVE essere una delle voci documentate nell'ultima versione dell'NDK di Android, nel filedocs/CPU-ARCH-ABIS.txt. Tieni presente che le release aggiuntive dell'Android NDK potrebbero introdurre il supporto di ABI aggiuntivi.

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'esperienza web completa è al centro dell'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 delle implementazioni dei dispositivi DEVONO essere basate sulla build WebKit 533.1 del tree Android Open Source di upstream per Android 2.2. 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

La configurazione di WebView DEVE includere il supporto per il database HTML5, la cache dell'applicazione e le API di geolocalizzazione [Risorse, 9]. WebView DEVE includere il supporto per il tag HTML5 <video>. Le API HTML5, come tutte le API JavaScript, DEVONO essere disabilitate per impostazione predefinita in un WebView, a meno che lo sviluppatore non le abiliti 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 fornita un'applicazione browser alternativa, il componente android.webkit.WebView fornito alle applicazioni di terze parti DEVE essere basato su WebKit, come descritto nella Sezione 3.4.1.

Le implementazioni POSSONO 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 la geolocalizzazione HTML5, la cache dell'applicazione e le API di database e il tag <video> nell'applicazione browser autonoma.

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 il significato di un Intent 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 una determinata autorizzazione

L'elenco riportato sopra non è esaustivo e la responsabilità di garantire la compatibilità del comportamento è degli implementatori dei dispositivi. 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.

La Compatibility Test Suite (CTS) testa porzioni significative della piattaforma per verificarne la compatibilità di comportamento, ma non tutte. È responsabilità dell'implementatore garantire la compatibilità del comportamento con il progetto Android Open Source.

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" nel codice sorgente di Android upstream. In altre parole, gli implementatori di dispositivi NON DEVONO esporre nuove API o modificare quelle esistenti negli spazi dei nomi indicati sopra. Gli implementatori di dispositivi POSSONO apportare modifiche solo per uso interno, ma queste modifiche NON DEVONO essere pubblicizzate o esposte in altro modo 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.

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

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à DEVONO configurare Dalvik per allocare almeno 24 MB di memoria a ogni applicazione. Tieni presente che le implementazioni dei dispositivi POTREBBERO allocare più memoria rispetto a questi valori.

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, 11]. 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, 12]. 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, 13] o nella guida di stile delle icone della barra di stato [Risorse, 14]. 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, 15] 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, 16]) 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 [Risorse, 17]. 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à del software di riferimento

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

• Calcolatrice (inclusa nell'SDK)
• Lunar Lander (incluso nell'SDK)
• Le applicazioni "App per Android" [Risorse, 18].
• 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.

Inoltre, le implementazioni dei dispositivi DEVONO testare ogni voce di menu (inclusi tutti i sottomenu) di ciascuna di queste applicazioni di test di fumosità:

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

Ogni scenario di test nelle applicazioni sopra indicate DEVE essere eseguito correttamente nell'implementazione del dispositivo.

5. Compatibilità con il pacchettizzazione delle applicazioni

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

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

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

6.1. Codec multimediali

Le implementazioni dei dispositivi DEVONO supportare i seguenti codec multimediali. Tutti questi codec sono forniti come implementazioni software nell'implementazione Android preferita dell'Android Open Source Project.

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

Audio
	Nome	Codificatore	Decodificatore	Dettagli	Formato file/container
	AAC LC/LTP		X	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+)		X
	HE-AACv2 (AAC+ migliorato)		X
	AMR-NB	X	X	4,75-12,2 Kbps campionati a 8 kHz	3GPP (.3gp)
	AMR-WB		X	9 frequenze da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz	3GPP (.3gp)
	MP3		X	Mono/stereo 8-320 Kbps a velocità in bit costante (CBR) o variabile (VBR)	MP3 (.mp3)
	MIDI		X	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		X		Ogg (.ogg)
	PCM		X	PCM lineare a 8 e 16 bit (frequenze fino al limite dell'hardware)	WAVE (.wav)
Immagine
	JPEG	X	X	base+progressive
	GIF		X
	PNG	X	X
	BMP		X
Video
	H.263	X	X		File 3GPP (.3gp)
	H.264		X		File 3GPP (.3gp) e MPEG-4 (.mp4)
	Profilo semplice MPEG4		X		File 3GPP (.3gp)

Tieni presente che la tabella sopra non elenca 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.

6.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.2, è previsto di modificarli in "DEVE" nella definizione di compatibilità per una versione futura. In altre parole, questi requisiti sono facoltativi in Android 2.2, ma saranno obbligatori in una versione futura. I dispositivi esistenti e nuovi che utilizzano Android 2.2 sono vivamente invitati a soddisfare questi requisiti in Android 2.2, altrimenti non potranno ottenere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

6.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 DEVONO soddisfare tutti i requisiti di latenza audio descritti in questa sezione.

Ai fini di questa sezione:

• Per "latenza di output a freddo" si intende l'intervallo tra il momento in cui un'applicazione richiede la riproduzione audio e il momento in cui inizia la riproduzione 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.2, è previsto di modificarli in "DEVE" nella definizione di compatibilità per una versione futura. In altre parole, questi requisiti sono facoltativi in Android 2.2, ma saranno obbligatori in una versione futura. I dispositivi esistenti e nuovi che utilizzano Android 2.2 sono vivamente invitati a soddisfare questi requisiti in Android 2.2, altrimenti non potranno ottenere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

7. 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, 19]
  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, 19]
  Le implementazioni del dispositivo 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, 22]
  Le implementazioni del dispositivo DEVONO includere il framework Monkey e metterlo a disposizione delle applicazioni.

8. Compatibilità hardware

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

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

• le definizioni di classi per le API del componente DEVONO essere 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

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

8.1. Display

Android 2.2 include funzionalità che eseguono determinate operazioni di ridimensionamento e trasformazione automatiche in alcune circostanze, per garantire che le applicazioni di terze parti funzionino abbastanza bene su una serie di configurazioni hardware [Risorse, 24]. I dispositivi DEVONO implementare correttamente questi comportamenti, come descritto in questa sezione.

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

Tipo di schermo	Larghezza (pixel)	Altezza (pixel)	Intervallo di lunghezza diagonale (pollici)	Gruppo di dimensioni dello schermo	Gruppo di densità dello schermo
QVGA	240	320	2,6 - 3,0	Piccolo	Bassa
WQVGA	240	400	3,2 - 3,5	Normale	Bassa
FWQVGA	240	432	3,5 - 3,8	Normale	Bassa
HVGA	320	480	3,0 - 3,5	Normale	Intermedia
WVGA	480	800	3,3 - 4,0	Normale	Alto
FWVGA	480	854	3,5 - 4,0	Normale	Alto
WVGA	480	800	4,8 - 5,5	Grande	Intermedia
FWVGA	480	854	5,0 - 5,8	Grande	Intermedia

Le implementazioni dei dispositivi corrispondenti a una delle configurazioni standard riportate sopra DEVONO essere configurate per segnalare le dimensioni dello schermo indicate alle applicazioni tramite la classe android.content.res.Configuration [Resources, 24].

Alcuni pacchetti .apk hanno manifest che non li identificano come supportanti un intervallo di densità specifico. Quando esegui queste applicazioni, si applicano i seguenti vincoli:

• Le implementazioni dei dispositivi DEVONO interpretare le risorse in un file APK che non dispongono di un qualificatore di densità come valore predefinito "medium" (noto come "mdpi" nella documentazione dell'SDK).
• Quando operi su uno schermo a densità "bassa", le implementazioni dei dispositivi DEVONO ridurre le risorse medium/mdpi di un fattore 0,75.
• Quando operi su uno schermo ad alta densità, le implementazioni dei dispositivi DEVONO aumentare le dimensioni degli asset medium/mdpi di un fattore 1,5.
• Le implementazioni dei dispositivi NON DEVONO ridimensionare gli asset all'interno di un intervallo di densità e DEVONO ridimensionare gli asset esattamente in base a questi fattori tra intervalli di densità.

8.1.2. Configurazioni di display non standard

Le configurazioni di visualizzazione che non corrispondono a una delle configurazioni standard elencate nella Sezione 8.1.1 richiedono ulteriori considerazioni e interventi per essere compatibili. Gli implementatori di dispositivi DEVONO contattare il team di compatibilità Android come descritto nella Sezione 13 per ottenere le classificazioni per il bucket delle dimensioni dello schermo, la densità e il fattore di scalabilità. Quando vengono fornite queste informazioni, le implementazioni dei dispositivi DEVONO implementarle come specificato.

Tieni presente che alcune configurazioni del display (ad esempio schermi molto grandi o molto piccoli e alcuni rapporti di aspetto) sono fondamentalmente incompatibili con Android 2.2. Pertanto, gli implementatori dei dispositivi sono invitati a contattare il team di compatibilità di Android il prima possibile durante il processo di sviluppo.

8.1.3. Metriche relative alla visualizzazione

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

8.1.4. Supporto dello schermo dichiarato

Le applicazioni possono indicare 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.

8.2. 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, 25] (ovvero QWERTY o 12 tasti)

8.3. Navigazione non tocco

Implementazioni dei dispositivi:

• POTREBBE omettere le opzioni di navigazione non touch (ad esempio, trackball, D-pad o rotella)
• DEVE riportare il valore corretto per android.content.res.Configuration.navigation [Risorse, 25]

8.4. Orientamento schermo

I dispositivi compatibili DEVONO supportare l'orientamento dinamico 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 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.

8.5. 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, 25] che corrisponde al tipo di touchscreen specifico sul dispositivo
• DOVREBBE supportare cursori monitorati in modo completamente indipendente, se il touchscreen supporta più cursori

8.6. 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
• DEVE implementare il supporto per la specifica USB Mass Storage (in modo da poter accedere allo spazio di archiviazione rimovibile o fisso sul dispositivo da un PC host)

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

8.8. Networking di dati wireless

Le implementazioni dei dispositivi DEVONO includere il supporto per la rete di dati wireless ad alta velocità. Nello specifico, le implementazioni dei dispositivi DEVONO includere il supporto di almeno un protocollo di dati wireless in grado di supportare una velocità di almeno 200 Kbit/s. Alcuni esempi di tecnologie che soddisfano questo requisito sono EDGE, HSPA, EV-DO, 802.11g e così via.

Se un'implementazione del dispositivo include una determinata modalità per la quale l'SDK Android include un'API (ad esempio Wi-Fi, GSM o CDMA), l'implementazione DEVE supportare l'API.

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

8.9. Fotocamera

Le implementazioni dei dispositivi DEVONO includere una fotocamera posteriore. La fotocamera posteriore inclusa:

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

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API relative alle videocamere:

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. Questo è il formato utilizzato in modo nativo dalla famiglia di hardware 7K. In altre parole, NV21 DEVE essere il valore predefinito.

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

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

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

8.10. Accelerometro

Le implementazioni dei dispositivi DEVONO includere un accelerometro a 3 assi e DEVONO essere in grado di inviare eventi a una frequenza minima di 50 Hz. Il sistema di coordinate utilizzato dall'accelerometro DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nelle API Android (vedi [Risorse, 28]).

8.11. Bussola

Le implementazioni dei dispositivi DEVONO includere una bussola a 3 assi e DEVONO essere in grado di inviare eventi a una frequenza minima di 10 Hz. Il sistema di coordinate utilizzato dalla bussola deve essere conforme al sistema di coordinate del sensore Android come definito nell'API Android (vedi [Risorse, 28]).

8.12. GPS

Le implementazioni dei dispositivi DEVONO includere un ricevitore GPS e DOVREBBERO includere qualche forma di tecnica "GPS assistito" per ridurre al minimo il tempo di accoppiamento del GPS.

8.13. Telefonia

Android 2.2 PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. In altre parole, Android 2.2 è 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.

Consulta anche la sezione 8.8, Rete dati wireless.

8.14. Memoria e spazio di archiviazione

Le implementazioni dei dispositivi DEVONO avere almeno 92 MB di memoria a disposizione per il kernel e lo spazio utente. I 92 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 128 MB di memoria a disposizione per il kernel e lo spazio utente, oltre a qualsiasi memoria dedicata ai componenti hardware non controllati dal kernel. Le implementazioni dei dispositivi DEVONO avere almeno 1 GB di spazio di archiviazione non volatile disponibile per i dati utente. Tieni presente che questi requisiti più elevati dovrebbero diventare obbligatori in una versione futura di Android. Le implementazioni dei dispositivi sono caldamente incoraggiate a soddisfare questi requisiti ora, altrimenti potrebbero non essere idonee alla compatibilità con una versione futura di Android.

8.15. 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 minima di 2 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 spazio di archiviazione condiviso utilizzato, lo spazio di archiviazione condiviso DEVE implementare l'archiviazione di massa USB, come descritto nella Sezione 8.6. Come spedito, lo spazio di archiviazione condiviso DEVE essere montato con il file system FAT.

È 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 2 GB con il dispositivo venduto agli utenti e deve essere montata per impostazione predefinita. In alternativa, se l'implementazione di un dispositivo utilizza uno spazio di archiviazione interno fisso per soddisfare questo requisito, lo spazio di archiviazione DEVE avere una dimensione minima di 2 GB, essere formattato come FAT e 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.

8.16. Bluetooth

Le implementazioni dei dispositivi DEVONO includere un trasmettitore Bluetooth. Le implementazioni dei dispositivi DEVONO attivare l'API Bluetooth basata su RFCOMM come descritto nella documentazione dell'SDK [Risorse, 30]. Le implementazioni dei dispositivi DEVONO implementare profili Bluetooth pertinenti, come A2DP, AVRCP, OBEX e così via, a seconda dei casi.

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.

9. Compatibilità con il rendimento

Uno degli obiettivi del Programma di compatibilità Android è offrire ai consumatori un'esperienza con le applicazioni coerente. Le implementazioni compatibili devono garantire non solo che le applicazioni funzionino correttamente sul dispositivo, ma anche che lo facciano con un rendimento ragionevole e un'esperienza utente complessivamente positiva. Le implementazioni dei dispositivi DEVONO soddisfare le metriche di prestazioni chiave di un dispositivo compatibile con Android 2.2 definite nella tabella seguente:

Metrica	Soglia di rendimento	Commenti
Ora di lancio dell'applicazione	Le seguenti applicazioni devono essere lanciate entro il periodo di tempo specificato. Browser: meno di 1300 ms 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.

10. 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, 29] della documentazione per 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.

10.1. Autorizzazioni

Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android [Risorse, 29]. 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.*.

10.2. Isolamento UID e dei processi

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

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

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

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.

11. Compatibility Test Suite (CTS)

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

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

12. 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 il periodo di tempo ragionevole del prodotto stabilito 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 secondo il meccanismo appena descritto.

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