A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.

Questa pagina è stata tradotta dall'API Cloud Translation.

Definizione di compatibilità di Android 1.6
Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Definizione di compatibilità Android: Android 1.6
Android 1.6 r2
Google Inc.
compatibility@android.com

1. Introduzione
Questo documento elenca i requisiti che devono essere soddisfatti affinché gli smartphone siano
compatibili con Android 1.6. Questa definizione presuppone la conoscenza del Programma di compatibilità Android
[Risorse, 1].
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, 2].
Nell'ambito di questo documento, un "implementatore di dispositivi" o "implementatore" è una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 1.6.
Un'"implementazione del dispositivo" o "implementazione" è la
soluzione hardware/software così sviluppata.
Per essere considerate compatibili con Android 1.6, le implementazioni dei dispositivi:
1. DEVE soddisfare i requisiti presentati in questa definizione di compatibilità, inclusi eventuali documenti
incorporati tramite riferimento.
2. DEVE superare la suite di test di compatibilità Android (CTS) disponibile nell'Android Open
Source Project [Risorse, 3]. Il CTS testa la maggior parte, ma non tutti, i componenti descritti in questo
documento.
Se questa definizione o la CTS non sono chiare, ambigue o incomplete, è responsabilità dell'implementatore del dispositivo
garantire la compatibilità con le implementazioni esistenti. Per questo motivo, Android Open
Source Project [Risorse, 4] è sia l'implementazione di riferimento che quella preferita di Android. Gli
implementatori dei dispositivi sono vivamente invitati a basare le proprie implementazioni sul codice sorgente "upstream"
disponibile nell'Android Open Source Project. Sebbene alcuni componenti possano essere ipotetticamente sostituiti
con implementazioni alternative, questa pratica è vivamente sconsigliata, in quanto superare i test CTS diventerà
molto più difficile. È responsabilità dell'implementatore garantire la piena compatibilità comportamentale con l'
implementazione standard di Android, incluso e oltre il Compatibility Test Suite.
2. Risorse
Questa definizione di compatibilità fa riferimento a una serie di risorse che possono essere ottenute qui.
1. Panoramica del Programma di compatibilità Android: https://sites.google.com/a/android.com/compatibility/
how-it-works
2. Livelli di requisiti RFC2119 dell'IETF: http://www.ietf.org/rfc/rfc2119.txt
3. Suite di test di compatibilità: http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite--cts
4. Android Open Source Project: http://source.android.com/
5. Definizioni e documentazione dell'API: http://developer.android.com/reference/packages.html
6. Provider di contenuti: http://code.google.com/android/reference/android/provider/package-
summary.html
7. Risorse disponibili: http://code.google.com/android/reference/available-resources.html
8. File manifest Android: http://code.google.com/android/devel/bblocks-manifest.html
9. Documentazione di riferimento per le autorizzazioni Android: http://developer.android.com/reference/android/
Manifest.permission.html
10. Costanti di compilazione: http://developer.android.com/reference/android/os/Build.html
11. WebView: http://developer.android.com/reference/android/webkit/WebView.html
12. Estensioni del browser Gears: http://code.google.com/apis/gears/

13. Specifiche della macchina virtuale Dalvik, disponibili nella directory dalvik/docs di un
checkout del codice sorgente; disponibili anche all'indirizzo http://android.git.kernel.org/?p=platform/
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
14. AppWidget: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. Notifiche: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. Guida di stile per le icone della barra di stato: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
18. Toast: http://developer.android.com/reference/android/widget/Toast.html
19. App per Android: http://code.google.com/p/apps-for-android
20. Descrizione del file APK Android: http://developer.android.com/guide/topics/fundamentals.html
21. Android Debug Bridge (adb): http://code.google.com/android/reference/adb.html
22. Dalvik Debug Monitor Service (ddms): http://code.google.com/android/reference/ddms.html
23. Monkey: http://developer.android.com/guide/developing/tools/monkey.html
24. Documentazione sull'indipendenza dal display:
25. Costanti di configurazione: http://developer.android.com/reference/android/content/res/
Configuration.html
26. Metriche del display: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. Fotocamera: 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
Molte di queste risorse sono ricavate direttamente o indirettamente dall'SDK Android 1.6 e saranno
funzionalmente identiche alle informazioni riportate nella documentazione dell'SDK. In tutti i casi in cui questa
definizione di compatibilità 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 sia un insieme di API gestite ("hard") sia un insieme di cosiddette API "soft"
, come il sistema Intent, le API di codice nativo e le API di 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 (interfaccia di programmazione di un'applicazione) Android è l'insieme di interfacce della piattaforma Android esposte alle
app 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 1.6, ad esempio:
1.

API di base in lingua Java per Android [Resources, 5].
2. Fornitori di contenuti [Risorse, 6].
3. Risorse [Resources, 7].
4. Elementi e attributi AndroidManifest.xml [Risorse, 8].

Le implementazioni dei dispositivi NON DEVONO omettere API gestite, modificare interfacce o firme delle API, discostarsi
dal comportamento documentato o includere no-op, tranne nei casi specificamente consentiti da questa definizione
di compatibilità.
3.2. Compatibilità con le 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 1.6. Le implementazioni dei dispositivi DEVONO soddisfare tutti i
requisiti presentati in questa sezione.
3.2.1. Autorizzazioni
Gli implementatori dei dispositivi DEVONO supportare e applicare tutte le costanti di autorizzazione come documentato nella
pagina di riferimento delle autorizzazioni [Risorse, 9]. 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, 10] che sono
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
La versione del sistema Android attualmente in esecuzione, in formato leggibile
android.os.Build.VERSION.RELEASE
dall'utente. Per Android 1.6, questo campo DEVE avere il valore di stringa
"1.6".
La versione del sistema Android attualmente in esecuzione, in un formato
android.os.Build.VERSION.SDK
accessibile al codice dell'applicazione di terze parti. Per Android 1.6, questo campo
DEVE avere il valore intero 4.
Un valore scelto dall'implementatore del dispositivo che designa la build specifica
del sistema Android attualmente in esecuzione, in formato leggibile da un utente.
Questo valore NON DEVE essere riutilizzato per build diverse inviate agli utenti finali
android.os.Build.VERSION.INCREMENTAL. 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 ("").
Un valore scelto dall'implementatore del dispositivo che identifica l'hardware interno specifico
utilizzato dal dispositivo, in formato leggibile da una persona. Un possibile utilizzo
android.os.Build.BOARD
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 ("").
Un valore scelto dall'implementatore del dispositivo che identifica il nome della

android.os.Build.BRAND
società, organizzazione, persona fisica e così via che ha prodotto il dispositivo, in
formato leggibile da una persona. 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 ("").
Un valore scelto dall'implementatore del dispositivo che identifica la configurazione o la revisione specifica del corpo (a volte chiamata "design industriale") del dispositivo.
android.os.Build.DEVICE

Non sono previsti requisiti per il formato specifico
di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
Una stringa che identifica in modo univoco questa build. DOVREBBE essere ragionevolmente
leggibile da una persona. DEVE seguire questo modello:
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
Ad esempio: acme/mydevicel/generic/generic:Donut/ERC77/
3359:userdebug/test-keys
L'impronta NON DEVE includere spazi. Se altri campi inclusi nel
modello sopra riportato contengono spazi, DEBBONO essere sostituiti con il carattere ASCII
underscore ("_") nell'impronta.
Una stringa che identifica in modo univoco l'host su cui è stata eseguita la compilazione, in un formato leggibile
android.os.Build.HOST
dall'uomo. Non sono previsti requisiti per il formato specifico di questo
campo, tranne per il fatto che NON DEVE essere nullo o una stringa vuota ("").
Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release
specifica, in formato leggibile. Questo campo può essere uguale a
android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore
android.os.Build.ID
destinato a essere significativo per gli utenti finali. Non sono previsti
requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE
essere nullo o la stringa vuota ("").
Un valore scelto dall'implementatore del dispositivo contenente il nome del
dispositivo noto all'utente finale. DOVREBBE essere lo stesso nome
android.os.Build.MODEL
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 la stringa vuota ("").
Un valore scelto dall'implementatore del dispositivo contenente il nome
o il nome in codice di sviluppo del dispositivo. DEVE essere leggibile, ma non
android.os.Build.PRODUCT
necessariamente destinato alla visualizzazione da parte degli utenti finali. Non sono previsti requisiti
per il formato specifico di questo campo, tranne per il fatto che NON deve essere nullo o la
stringa vuota ("").
Un elenco di tag separati da virgola scelti dall'implementatore del dispositivo che
distinguono ulteriormente la build. Ad esempio, "unsigned,debug". Questo campo
android.os.Build.TAGS
NON DEVE essere nullo o la stringa vuota (""), ma è accettabile un singolo tag (ad esempio
"release").
android.os.Build.TIME
Un valore che rappresenta il timestamp del momento in cui è avvenuta la compilazione.
Un valore scelto dall'implementatore del dispositivo che specifica la configurazione

di runtime della build. Questo campo DEVE avere uno dei valori
android.os.Build.TYPE
corrispondenti alle tre configurazioni di runtime Android tipiche: "user",
"userdebug" o "eng".
Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la build
android.os.Build.USER
. Non sono previsti requisiti per il formato specifico di questo campo,
tranne per il fatto che NON DEVE essere nullo o una stringa vuota ("").

3.2.3. Compatibilità con gli intent
Android utilizza gli intent per realizzare un'integrazione non stretta 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à, un servizio o un altro componente
Android che specifichi un filtro per intent corrispondente e si leghi e implementi il comportamento corretto per ogni
pattern di intent specificato.
3.2.3.1. Intent di applicazioni di base
Il progetto Android upstream definisce una serie di applicazioni di base, come il tastierino del telefono, il calendario,
il libro dei contatti, il music player e così via. Gli implementatori dei dispositivi POSSONO sostituire queste applicazioni con
versioni alternative.
Tuttavia, queste versioni alternative DEVONO rispettare gli stessi pattern di intent forniti dal progetto
a monte. Ad esempio, se un dispositivo contiene un player musicale alternativo, deve comunque rispettare il pattern Intent
emesso da applicazioni di terze parti per scegliere un brano. Le implementazioni dei dispositivi DEVONO supportare tutti i pattern di intent
elencati nell'appendice A.
3.2.3.2. Sostituzioni intent
Poiché Android è una piattaforma estensibile, gli implementatori dei dispositivi DEVONO consentire la sostituzione di ogni pattern intent descritto nell'
Appendice A da parte di 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'uso di questi pattern di intent da parte delle applicazioni di sistema o impedire alle applicazioni di terze parti di associarsi a questi pattern e assumerne il controllo.

Questo divieto include in modo specifico 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 intent
Gli implementatori del dispositivo NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione che utilizzano ACTION, CATEGORY o un'altra stringa chiave nello spazio dei nomi android.*.
Gli implementatori del dispositivo NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione che utilizzano ACTION, CATEGORY o un'altra stringa chiave in uno spazio del pacchetto
appartenente a un'altra organizzazione.

Gli implementatori dei dispositivi NON DEVONO modificare o estendere nessuno dei pattern
di Intent elencati negli allegati A o B.
Questo divieto è analogo a quello specificato per i corsi di lingua Java nella Sezione 3.6.

3.2.3.4. Intent trasmessi
Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent al fine di essere avvisate 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. Un elenco di intent di trasmissione obbligatori è fornito nell'
Appendice B; tuttavia, tieni presente che l'SDK potrebbe definire intent di trasmissione aggiuntivi, che DEVONO essere rispettati.

3.3. Compatibilità con le API native
Il codice gestito in Dalvik può chiamare il codice nativo fornito nel file APK dell'applicazione come file ELF
.so compilato per l'architettura hardware del dispositivo appropriata. Le implementazioni dei dispositivi DEVONO includere
il supporto del codice in esecuzione nell'ambiente gestito per chiamare il codice nativo, utilizzando la semantica standard dell'interfaccia nativa Java (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++
• OpenGL ES 1.1
Queste librerie DEVONO essere compatibili con il codice sorgente (ovvero con gli header) e con i 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 DOVREBBERO utilizzare l'implementazione di Android. Se gli implementatori dei dispositivi utilizzano un'
implementazione diversa di queste librerie, devono garantire la compatibilità con le intestazioni e i file binari.
La compatibilità con il codice nativo è complessa. Per questo motivo, ribadiamo che gli implementatori dei dispositivi sono
MOLTO vivamente incoraggiati a utilizzare le implementazioni a monte delle librerie sopra elencate, per contribuire a
garantire la compatibilità.
3.4. Compatibilità con le API web
Molti sviluppatori e applicazioni si basano sul comportamento della classe android.webkit.WebView [Risorse,
11] per le loro interfacce utente, pertanto l'implementazione di WebView deve essere compatibile con tutte le implementazioni di Android.
L'implementazione di Android Open Source utilizza la versione del motore di rendering WebKit per
implementare WebView.
Poiché non è possibile sviluppare una suite di test completa per un browser web, gli implementatori dei dispositivi
DEVONO utilizzare la build upstream specifica di WebKit nell'implementazione di WebView. Nello specifico:
• WebView DEVE utilizzare la build WebKit 528.5 e versioni successive dell'albero Android Open Source upstream per
Android 1.6. Questa build include un insieme specifico di correzioni di funzionalità e sicurezza per WebView.
• La stringa dello user agent segnalata dalla WebView DEVE avere questo formato:
Mozilla/5.0 (Linux; U; Android 1.6; <language>-<country>; <device
name>; Build/<build ID>) AppleWebKit/528.5+ (KHTML, come Gecko)
Versione/3.1.2 Mobile Safari/525.20.1

◦ La stringa "<device name>" DEVE essere uguale al valore di
android.os.Build.MODEL
◦ La stringa "<build ID>" DEVE essere uguale al valore di android.os.Build.ID.
◦ Le stringhe "<language>" e "<country>" DEVONO seguire le convenzioni consuete per
codice paese e lingua e DEVONO fare riferimento alle impostazioni internazionali correnti del dispositivo al
momento della richiesta.
Le implementazioni POSSONO includere una stringa user agent personalizzata nell'applicazione Browser autonoma. Inoltre, il browser autonomo PUÒ essere basato su una tecnologia di browser alternativa (ad esempio Firefox, Opera e così via).

Tuttavia, anche se viene fornita un'applicazione di browser alternativa, il componente WebView
fornito alle applicazioni di terze parti DEVE essere basato su WebKit, come sopra.
L'applicazione del browser autonoma DEVE includere il supporto di Gears [Risorse, 12] e PUÒ
includere il supporto di parte o di tutto HTML5.
3.5. Compatibilità del comportamento dell'API
I comportamenti di ciascuno dei tipi di API (gestite, soft, native e web) devono essere coerenti con l'implementazione preferita di Android disponibile nell'Android Open Source Project.

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 (come Service, Activity, ContentProvider e così via)
• I dispositivi NON DEVONO modificare la semantica di una determinata autorizzazione
L'elenco riportato sopra non è esaustivo e incombe sugli implementatori dei dispositivi l'onere di garantire la compatibilità
del comportamento. Per questo motivo, gli implementatori di dispositivi DOVREBBERO utilizzare il codice sorgente disponibile tramite l'
Android Open Source Project, se possibile, anziché implementare nuovamente parti significative del sistema.
La Compatibility Test Suite (CTS) testa porzioni significative della piattaforma per verificarne la compatibilità comportamentale,
ma non tutte. È responsabilità dell'implementatore garantire la compatibilità del comportamento con il progetto open source Android.

3.6. Spazi dei nomi API
Android segue le convenzioni relative agli spazi dei nomi di pacchetti e classi definiti 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.*
• sun.*
• 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 alcuna

API esposte 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 l'indicatore "@hide" nel codice sorgente di Android
upstream. In altre parole, gli implementatori dei dispositivi NON DEVONO esporre nuove API o
modificare le API esistenti negli spazi dei nomi sopra indicati. Gli implementatori dei 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 proprietà
di un'altra organizzazione o fare riferimento a un'altra organizzazione. Ad esempio, gli implementatori dei dispositivi NON DEVONO aggiungere API al namespace
com.google.* o a uno 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 degli spazi dei nomi del pacchetto sopra indicati (ad esempio aggiungendo
nuove funzionalità utili a un'API esistente o aggiungendo una nuova API), l'implementatore DEVE visitare
source.android.com e avviare la procedura per inviare modifiche e codice, in base alle
informazioni su quel sito.
Tieni presente che le limitazioni riportate sopra corrispondono alle convenzioni standard per la denominazione delle API nel linguaggio di programmazione Java.
Questa sezione ha semplicemente lo scopo di rafforzare queste convenzioni e renderle vincolanti
tramite l'inclusione in questa definizione di compatibilità.
3.7. Compatibilità con la macchina virtuale
Un dispositivo Android compatibile deve supportare la specifica completa del bytecode Dalvik eseguibile (DEX) e la semantica della macchina virtuale Dalvik [Risorse, 13].

3.8. Compatibilità dell'interfaccia utente
La piattaforma Android include alcune API per sviluppatori che consentono agli sviluppatori di collegarsi all'interfaccia utente
del sistema. Le implementazioni dei dispositivi DEVONO incorporare queste API di UI 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 [Risorse, 14]. 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 dei dispositivi POSSONO sostituire un'alternativa all'Avvio app di riferimento (ad es. la schermata Home).
Gli Avvio app alternativi DEVONO includere il supporto integrato per gli AppWidget ed esporre elementi dell'interfaccia utente per aggiungere, visualizzare e rimuovere gli AppWidget direttamente all'interno dell'Avvio app.
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, visualizzare e rimuovere
gli AppWidget.

3.8.2. Notifiche
Android include API che consentono agli sviluppatori di notificare agli utenti eventi importanti [Risorse, 15]. Gli
implementatori dei dispositivi DEVONO fornire supporto per ogni classe di notifica così definita; in particolare: suoni,
vibrazione, spia 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, 7] o nella guida allo stile delle icone della barra di stato [Risorse, 16]. Gli
implementatori dei dispositivi POSSONO fornire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'
implementazione di riferimento di Android Open Source; tuttavia, questi sistemi di notifica alternativi DEVONO
supportare le risorse di notifica esistenti, come sopra.
3.8.3. Ricerca
Android include API [Risorse, 17] che consentono agli sviluppatori di incorporare la ricerca nelle loro applicazioni
e di 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
mentre 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'interfaccia utente di ricerca singola, condivisa e 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 la visualizzazione dei risultati e dei
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 hardware o software che può essere utilizzato in qualsiasi momento all'interno di qualsiasi app per richiamare il framework di ricerca,
con il comportamento previsto nella documentazione dell'API.

3.8.4. Messaggi popup
Le applicazioni possono utilizzare l'API "Toast" (definita in [Risorse, 18]) 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 da
app agli utenti finali in modo molto visibile.
4. Compatibilità del software di riferimento
Gli implementatori dei dispositivi DEVONO testare la compatibilità dell'implementazione utilizzando le seguenti applicazioni open source:
• Calcolatrice (inclusa nell'SDK)
• Lunar Lander (inclusa nell'SDK)
• ApiDemos (inclusa nell'SDK)
• Le applicazioni "App per Android" [Risorse, 19]
Ogni app sopra indicata DEVE essere avviata e funzionare correttamente nell'implementazione affinché l'implementazione sia

considerata compatibile.

5. Compatibilità del pacchettizzazione delle applicazioni
Le implementazioni dei dispositivi DEVONO installare ed eseguire i file ".apk" Android generati dallo strumento "aapt"
incluso nell'SDK Android ufficiale [Risorse, 20].
Le implementazioni dei dispositivi NON DEVONO estendere i formati .apk, Android Manifest o bytecode Dalvik
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
Un dispositivo Android compatibile deve supportare i seguenti codec multimediali. Tutti questi codec sono
forniti come implementazioni software nell'implementazione Android preferita dell'Android Open
Source Project [Risorse, 4].
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 tenere presente 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
Encoder Decoder Dettagli
File supportati
Contenuti mono/stereo in qualsiasi
3GPP (.3gp) e
combinazione di larghezza di banda standard
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
fino a 160 Kbps e frequenze di campionamento. Nessun supporto per contenuti raw
tra 8 e 48 kHz
AAC (.aac)
Mono/Stereo in qualsiasi
3GPP (.3gp) e
HE-AACv1
combinazione di larghezza di banda standard
MPEG-4 (.mp4, .m4a)
X
(AAC+)
fino a 96 Kbps e frequenze di campionamento file. Nessun supporto per contenuti

Nessun supporto per file raw
tra 8 e 48 kHz
AAC (.aac)
AMR-NB
da 4,75 a 12,2 Kbps campionati a
file 3GPP (.3gp)
X
X
8 kHz
AMR-WB
9 frequenze da 6,60 kbit/s a 23,85
file 3GPP (.3gp)
X
kbit/s campionati a 16 kHz
MP3
File MP3 (.mp3) mono/stereo a velocità in bit costante di 8-320 Kbps
X
(CBR) o a velocità in bit variabile (VBR)
Tipo 0 e 1 (.mid, .xmf,
MIDI di tipo 0 e 1. DLS versione 1
MIDI
X
.mxmf). Inoltre, RTTTL/RTX
e 2. XMF e Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

Supporto per i formati di suoneria
e iMelody (.imy)
RTTTL/RTX, OTA e iMelody
Ogg Vorbis
.ogg
X
PCM lineare a 8 e 16 bit (frequenze fino a
PCM
X
WAVE
al limite dell'hardware)
File
di immagine
Nome
Dettagli codificatore/decodificatore
Supportati
JPEG
X
X
base+progressive
GIF
X
PNG
X
X
BMP
X
File
video
Nome
Dettagli codificatore/decodificatore
Supportati
File 3GPP (.3gp)
H.263
X
X

File 3GPP (.3gp)
H.264
X
e MPEG-4
(.mp4)
MPEG4
X
File 3GPP (.3gp)
SP
7. Compatibilità con gli strumenti per sviluppatori
Le implementazioni dei dispositivi DEVONO supportare gli strumenti per sviluppatori Android forniti nell'SDK Android.
In particolare, i dispositivi compatibili con Android DEVONO essere compatibili con:
• Android Debug Bridge o adb [Risorse, 21]
Le implementazioni dei dispositivi DEVONO supportare tutte le funzioni di 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 o ddms [Risorse, 22]
Le implementazioni del dispositivo DEVONO supportare tutte le funzionalità di ddms come documentato 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, 23]
Le implementazioni dei dispositivi DEVONO includere il framework Monkey e renderlo disponibile per l'uso da parte delle applicazioni.

8. Compatibilità hardware
Android è progettato per supportare gli implementatori di dispositivi che creano configurazioni e fattori di forma innovativi.
Al contempo, gli sviluppatori Android si aspettano determinati hardware, sensori e API su tutti i dispositivi
Android. Questa sezione elenca le funzionalità hardware che tutti i dispositivi compatibili con Android 1.6 devono supportare. In
Android 1.6, la maggior parte delle funzionalità hardware (come Wi-Fi, bussola e accelerometro) è obbligatoria.
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.

8.1. Display
Android 1.6 include funzionalità che eseguono determinate operazioni di ridimensionamento e trasformazione automatiche in alcune circostanze per garantire che le applicazioni di terze parti funzionino ragionevolmente bene sulle configurazioni hardware per le quali non sono state necessariamente progettate esplicitamente [Risorse, 24].

I dispositivi DEVONO
implementare correttamente questi comportamenti, come descritto in questa sezione.
8.1.1. Configurazioni standard del display
Questa tabella elenca le configurazioni dello schermo standard considerate compatibili con Android:
Diagonale
Dimensioni dello schermo
Densità dello schermo
Tipo di schermo
Larghezza (pixel)
Altezza (pixel)
Intervallo di lunghezza
Gruppo
Gruppo
(pollici)
QVGA
240
320
2,6 - 3,0
Piccolo
Basso
WQVGA
240
400
3,2 - 3,5
Normale
Basso
FWQVGA
240
432
3,5 - 3,8
Normale
Basso
HVGA
320
480
3,0 - 3,5
Normale
Medio
WVGA
480
800
3,3 - 4,0
Normale
Alto
FWVGA
480
854
3,5 - 4,0
Normale
Alto
WVGA
480
800
4,8 - 5,5
Grande
Medio
FWVGA
480
854
5,0 - 5,8
Grande
Medio
Le implementazioni dei dispositivi corrispondenti a una delle configurazioni standard sopra indicate DEVONO essere configurate
per segnalare le dimensioni dello schermo indicate alle applicazioni tramite la classe android.content.res.Configuration [Resources,
25].
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 presenti come predefinite per
"medium" (noto come "mdpi" nella documentazione dell'SDK).
• Quando operi su uno schermo a densità "bassa", le implementazioni dei dispositivi DEVONO ridurre le risorse di medio/
mdpi di un fattore 0,75.
• Quando operi su uno schermo ad alta densità, le implementazioni dei dispositivi DEVONO aumentare le dimensioni degli asset medi/
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 visualizzazione non standard
Le configurazioni di visualizzazione che non corrispondono a una delle configurazioni standard elencate nella Sezione 8.2.1 richiedono
considerazioni e interventi aggiuntivi per essere compatibili. Gli implementatori dei dispositivi DEVONO contattare il
team di compatibilità di Android come previsto nella Sezione 12 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 1.6; pertanto, gli implementatori dei dispositivi sono invitati a
contattare il team di compatibilità Android il prima possibile durante il processo di sviluppo.
8.1.3. Metriche del display
Le implementazioni del dispositivo DEVONO riportare valori corretti per tutte le metriche del display definite in
android.util.DisplayMetrics [Resources, 26].
8.2. Tastiera
Implementazioni del dispositivo:
• 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, ovvero tastiere virtuali) come descritto in
developer.android.com
• DEVE fornire almeno un'implementazione di tastiera virtuale (indipendentemente dal fatto che sia presente una tastiera fisica)
• PUÒ includere implementazioni di tastiere virtuali aggiuntive
• PUÒ includere una tastiera hardware
• NON DEVE includere una tastiera hardware che non corrisponda a uno dei formati specificati
in android.content.res.Configuration [Resources, 25] (ovvero QWERTY o 12 tasti)
8.3.

Navigazione non tocco
Implementazioni del dispositivo:
• PUÒ omettere le opzioni di navigazione non tocco (ad esempio, può omettere un trackball, un pad direzionale a 5 direzioni o un
volante)
• DEVE segnalare tramite android.content.res.Configuration [Resources, 25] il valore corretto per l'hardware
del dispositivo

8.4. Orientamento schermo
I dispositivi compatibili DEVONO supportare l'orientamento dinamico delle applicazioni in orizzontale o verticale.
In altre parole, il dispositivo deve rispettare la richiesta dell'applicazione di un orientamento
dello schermo specifico. Le implementazioni dei dispositivi POSSONO selezionare l'orientamento verticale o orizzontale come predefinito.
I dispositivi DEVONO segnalare 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 del dispositivo:
• DEVE avere un touchscreen
• PUÒ avere un touchscreen capacitivo o resistivo
• DEVE riportare il valore di android.content.res.Configuration [Resources, 25] che riflette
corrispondente al tipo di touchscreen specifico sul dispositivo
8.6. USB
Implementazioni del dispositivo:
• DEVE implementare un client USB, collegabile a un host USB con una porta USB-A standard
• DEVE implementare Android Debug Bridge tramite USB (come descritto nella Sezione 7)
• DEVE implementare un client di archiviazione di massa USB per l'archiviazione rimovibile/multimediale presente nel
dispositivo
• DEVE utilizzare il fattore di forma micro USB sul lato del dispositivo
• DEVE implementare il supporto per la specifica USB Mass Storage (in modo da poter accedere all'archiviazione
rimovibile o fissa sul dispositivo da un PC host)
• PUÒ 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.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 DOVREBBERO essere implementate tramite pulsanti dedicati. POSSONO essere implementati
utilizzando software, gesti, pannello 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 chiavi di invio e di chiusura per le chiamate.
8.8. Wi-Fi
Le implementazioni dei dispositivi DEVONO supportare 802.11b e 802.11g e POSSONO supportare 802.11a.

8.9. Fotocamera
Le implementazioni del dispositivo DEVONO includere una fotocamera. La videocamera inclusa:
• DEVE avere una risoluzione di almeno 2 megapixel
• DOVREBBE avere la messa a fuoco automatica hardware o software implementata nel driver della videocamera
(trasparente al software dell'applicazione)
• PUÒ avere hardware a fuoco fisso o EDOF (profondità di campo estesa)
• PUÒ includere un flash. Se la fotocamera include un flash, la spia del flash NON DEVE essere accesa mentre è stata registrata un'istanza di
android.hardware.Camera.PreviewCallback su una superficie di anteprima della fotocamera
.
Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API relative alla fotocamera
[Risorse, 27]:
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.
8.9.1. Videocamere senza autofocus
Se un dispositivo non dispone di una videocamera con autofocus, l'implementatore del dispositivo DEVE soddisfare i requisiti aggiuntivi riportati in
questa sezione. Le implementazioni dei dispositivi DEVONO implementare l'API Camera completa inclusa nella documentazione dell'SDK Android 1.6
in qualche modo ragionevole, indipendentemente dalle funzionalità dell'hardware della fotocamera effettiva.
Per Android 1.6, se la fotocamera non dispone dell'autofocus, l'implementazione del dispositivo DEVE rispettare quanto segue:
1. Il sistema DEVE includere una proprietà di sistema di sola lettura denominata "ro.workaround.noautofocus"
con il valore "1". Questo valore è destinato a essere utilizzato da applicazioni come Android Market per
identificare in modo selettivo le funzionalità del dispositivo e verrà sostituito in una versione futura di Android con un'
API solida.
2. Se un'applicazione chiama android.hardware.Camera.autoFocus(), il sistema DEVE chiamare il metodo di callback
onAutoFocus() su qualsiasi istanza
android.hardware.Camera.AutoFocusCallback registrata, anche se non è stata effettivamente eseguita alcuna messa a fuoco.
Questo serve ad evitare che le applicazioni esistenti si interrompano in attesa di un
callback di messa a fuoco automatica che non arriverà mai.
3. La chiamata al metodo AutoFocusCallback.onAutoFocus() DEVE essere attivata dal driver o dal
framework in un nuovo evento sul thread Looper del framework principale. In altre parole, Camera.autoFocus()
NON DEVE chiamare direttamente AutoFocusCallback.onAutoFocus() poiché ciò viola il modello di threading del framework Android
e causerà l'interruzione delle app.
8.10. Accelerometro
Le implementazioni del dispositivo DEVONO includere un accelerometro a tre assi e DEVONO essere in grado di inviare eventi a una frequenza di almeno 50 Hz. Il sistema di coordinate utilizzato dall'accelerometro DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nella sezione [Risorse, 28] dell'API Android.

8.11. Bussola
Le implementazioni del dispositivo DEVONO includere una bussola a 3 assi e DEVONO essere in grado di inviare eventi a una frequenza di almeno 10 Hz. Il sistema di coordinate utilizzato dalla bussola DEVE essere conforme al sistema di coordinate dei sensori Android
come definito nell'API Android [Risorse, 28].

8.12. GPS
Le implementazioni del dispositivo DEVONO includere un GPS e DOVREBBERO includere una qualche forma di tecnica di "GPS assistito"
per ridurre al minimo il tempo di accoppiamento del GPS.
8.13. Telefonia
Implementazioni del dispositivo:
• DEVE includere la telefonia GSM o CDMA
• DEVE implementare le API appropriate come descritto nella documentazione dell'SDK Android all'indirizzo
developer.android.com
Tieni presente che questo requisito implica che i dispositivi non smartphone non sono compatibili con Android 1.6; i dispositivi Android
1.6 DEVONO includere hardware di telefonia. Consulta l'appendice C per informazioni sui dispositivi
diversi dai telefoni.
8.14. Controlli del volume
I dispositivi compatibili con Android DEVONO includere un meccanismo che consenta all'utente di aumentare e diminuire il volume
audio. Le implementazioni dei dispositivi DEVONO rendere queste funzioni disponibili all'utente in qualsiasi momento,
indipendentemente dallo stato dell'applicazione. Queste funzioni POSSONO essere implementate utilizzando tasti hardware fisici,
software, gesti, pannello touch e così via, ma DEVONO essere sempre accessibili e non oscurare o interferire
con l'area di visualizzazione dell'applicazione disponibile (vedi Display sopra).
Quando vengono utilizzati questi pulsanti, gli eventi chiave corrispondenti DEVONO essere generati e inviati all'
applicazione in primo piano. Se l'evento non viene intercettato e ignorato dall'applicazione, l'implementazione del dispositivo
DEVE gestire l'evento come controllo del volume di sistema.
9. Compatibilità delle prestazioni
Uno degli obiettivi del Programma di compatibilità Android è garantire un'esperienza con le applicazioni coerente per i consumatori.
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 1.6,
come indicato nella tabella seguente:
Metrica
Soglia di prestazioni
Commenti

Questo test viene eseguito da CTS.
Le seguenti applicazioni
Il tempo di avvio viene misurato come tempo totale necessario per
dovrebbero essere avviate entro il
completare il caricamento dell'attività predefinita per l'
applicazione
tempo specificato.
applicazione, incluso il tempo necessario per avviare il
Tempo di avvio
Browser: meno di 1300 ms
processo Linux, caricare il pacchetto Android nella
MMS/SMS: meno di 700 ms
VM Dalvik e chiamare onCreate.
Sveglia: meno di 650 ms
Verranno lanciate più applicazioni
Questo test viene eseguito da CTS.
Il riavvio della
prima applicazione
simultanea dovrebbe
completarsi in meno tempo rispetto al
tempo di lancio 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] nella
documentazione per gli sviluppatori Android. Le implementazioni dei dispositivi DEVONO supportare l'installazione di applicazioni
con firma autografata senza richiedere autorizzazioni/certificati aggiuntivi da parte di terze parti/autorità.
In particolare, i dispositivi compatibili DEVONO supportare i seguenti meccanismi di sicurezza:
10.1. Autorizzazioni
Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori
Android [Risorse, 9]. Nello specifico, le implementazioni DEVONO applicare ogni autorizzazione
definita come descritto nella documentazione dell'SDK; nessuna autorizzazione può essere omessa, alterata 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 utente e processo
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 separato.
Le implementazioni dei dispositivi DEVONO supportare l'esecuzione di più applicazioni con lo stesso ID utente Linux, a condizione
che le applicazioni siano firmate e create correttamente, come definito nella documentazione di riferimento
Sicurezza e autorizzazioni [Risorse, 29].

10.3. Autorizzazioni del file system
Le implementazioni del dispositivo DEVONO supportare il modello di autorizzazioni di accesso ai file di Android come definito in [Risorse, 29] come definito in [Risorse, 29].

11. Compatibility Test Suite
Le implementazioni dei dispositivi DEVONO superare la suite di test di compatibilità Android (CTS) [Risorse, 3] disponibile
nell'Android Open Source Project, utilizzando il software di spedizione finale sul dispositivo. Inoltre,
gli implementatori dei dispositivi DOVREBBERO utilizzare l'implementazione di riferimento nella struttura Android Open Source il più possibile 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, 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 1.6.
Tuttavia, queste release correggeranno solo i bug di comportamento nei test CTS
e non imporranno nuovi test, comportamenti o API per una determinata release della piattaforma.
12. Contattaci
Puoi contattare il team di compatibilità di Android all'indirizzo compatibility@android.com per chiarimenti in merito a questa definizione di compatibilità e per fornire feedback.

Appendice A: Intent di applicazione richiesti
NOTA: questo elenco è provvisorio e verrà aggiornato in futuro.
Azioni applicazione
Schemi Tipi MIME
(nessuno)
text/plain
http
text/html
Browser
android.intent.action.VIEW
https
application/xhtml+xml
application/
vnd.wap.xhtml+xml
(nessuno)
android.intent.action.WEB_SEARCH
http
(nessuno)
https
android.media.action.IMAGE_CAPTURE
android.media.action.STILL_IMAGE_CAMERA
Fotocamera
android.media.action.VIDEO_CAMERA
android.media.action.VIDEO_CAPTURE
vnd.android.cursor.dir/
android.intent.action.VIEW
immagine
android.intent.action.GET_CONTENT
vnd.android.cursor.dir/
android.intent.action.PICK
video
android.intent.action.ATTACH_DATA
immagine/*
video/*
android.intent.action.VIEW
rtsp
video/mp4
video/3gp
android.intent.action.VIEW
http
video/3gpp
video/3gpp2
android.intent.action.DIAL
Telefono /
android.intent.action.VIEW
tel
Contatti
android.intent.action.CALL
android.intent.action.DIAL
vnd.android.cursor.dir/
android.intent.action.VIEW
persona

vnd.android.cursor.dir/
persona
vnd.android.cursor.dir/
android.intent.action.PICK
telefono
vnd.android.cursor.dir/
indirizzo-postale
vnd.android.cursor.item/
persona
vnd.android.cursor.item/
android.intent.action.GET_CONTENT
telefono
vnd.android.cursor.item/
indirizzo-postale
testo/semplice
Email
android.intent.action.SEND
immagine/*
video/*
android.intent.action.VIEW
mailto
android.intent.action.SENDTO
sms
android.intent.action.VIEW
smsto
SMS / MMS android.intent.action.SENDTO
mms
mmsto
audio/*
application/ogg
Musica
android.intent.action.VIEW
file
application/x-ogg
application/itunes
audio/mp3
audio/x-mp3
android.intent.action.VIEW
http
audio/mpeg
audio/mp4
audio/mp4a-latm
vnd.android.cursor.dir/
artistaalbum
vnd.android.cursor.dir/
album
vnd.android.cursor.dir/
android.intent.action.PICK
in riproduzione
vnd.android.cursor.dir/
traccia
nd.android.cursor.dir/
playlist
vnd.android.cursor.dir/
video
media/*
audio/*
android.intent.action.GET_CONTENT
applicazione/ogg
applicazione/x-ogg
video/*

contenuto
Pacchetto
android.intent.action.VIEW
file
Installer
package
file
android.intent.action.PACKAGE_INSTALL
http
https
android.intent.action.ALL_APPS
android.settings.SETTINGS
android.settings.WIRELESS_SETTINGS
android.settings.AIRPLANE_MODE_SETTINGS
android.settings.WIFI_SETTINGS
android.settings.APN_SETTINGS
android.settings.BLUETOOTH_SETTINGS
android.settings.DATE_SETTINGS
android.settings.LOCALE_SETTINGS
Impostazioni
android.settings.INPUT_METHOD_SETTINGS
com.android.settings.SOUND_SETTINGS
com.android.settings.DISPLAY_SETTINGS
android.settings.SECURITY_SETTING
android.settings.LOCATION_SOURCE_SETTINGS
android.settings.INTERNAL_STORAGE_SETTINGS
android.settings.MEMORY_CARD_SETTINGS
android.intent.action.SET_WALLPAPER
Cerca
android.intent.action.SEARCH
query
android.intent.action.SEARCH_LONG_PRESS
Voce
android.intent.action.VOICE_COMMAND
Gestione contatti
Azione intento
Descrizione
Avvia un'attività che consente all'utente di scegliere
ATTACH_IMAGE
un contatto a cui allegare un'immagine.
Utilizzato
EXTRA_CREATE_DESCRIPTION
con SHOW_OR_CREATE_CONTACT per
specificare una descrizione esatta da

mostrare quando viene chiesto all'utente di
creare un nuovo contatto.
Utilizzato
con SHOW_OR_CREATE_CONTACT per
EXTRA_FORCE_CREATE
forzare la creazione di un nuovo contatto se non viene trovato un contatto corrispondente.

Questo è l'intent attivato quando viene fatto clic su un
SUGGERIMENTO_RICERCA_SU_CLIC
suggerimento di ricerca.
Questo è l'intent attivato quando viene fatto clic su un
SUGGERIMENTO_RICERCA_CONTATTO_SU_CLIC suggerimento di ricerca per la creazione di un
contatto.
Questo è l'intent attivato quando viene fatto clic su un
SEARCH_SUGGESTION_DIAL_NUMBER_CLICKED
suggerimento di ricerca per la composizione di un numero
.
Riceve come input un URI dati con un parametro mailto:
SHOW_OR_CREATE_CONTACT
o uno schema tel: .

Appendice B: intent di trasmissione obbligatoriNOTA: questo elenco è provvisorio e verrà
aggiornato in futuro.
Azione intent
Descrizione
Azione di trasmissione: viene trasmessa una volta, al termine dell'avvio del sistema
ACTION_BOOT_COMPLETED
.
Azione di trasmissione: viene trasmessa una volta quando viene ricevuta una chiamata
ACTION_CALL_BUTTON
.
Azione di trasmissione: il "pulsante della fotocamera" è stato
ACTION_CAMERA_BUTTON
premuto.
Azione di trasmissione: l'ACTION_CONFIGURATION_CHANGED
configurazione (orientamento, impostazioni internazionali e così via) del dispositivo
è cambiata.

ACTION_DATE_CHANGED
Azione di trasmissione: la data è cambiata.
Azione di trasmissione: indica una condizione di memoria ridotta
ACTION_DEVICE_STORAGE_LOW
sul dispositivo
Azione di trasmissione: indica una condizione di memoria ridotta
ACTION_DEVICE_STORAGE_OK
sul dispositivo non esiste più
Azione di trasmissione: cuffie con cavo collegate o
ACTION_HEADSET_PLUG
scollegate.
Azione di trasmissione: un metodo di immissione è stato
ACTION_INPUT_METHOD_CHANGED
modificato.
Azione di trasmissione: i contenuti multimediali esterni sono stati rimossi
ACTION_MEDIA_BAD_REMOVAL
dallo slot della scheda SD, ma il punto di montaggio non è stato smontato.

Azione di trasmissione: il "Pulsante multimediale" è stato
ACTION_MEDIA_BUTTON
premuto.
Azione di trasmissione: sono presenti contenuti multimediali esterni e
vengono controllati sul disco. Il percorso del punto di montaggio per
ACTION_MEDIA_CHECKING
i contenuti multimediali di controllo è contenuto nel

�
Azione di trasmissione: l'utente ha espresso il desiderio di
ACTION_MEDIA_EJECT
rimuovere il supporto di archiviazione esterno.
Azione di trasmissione: sono presenti supporti esterni e
ACTION_MEDIA_MOUNTED
è montato al relativo punto di montaggio.
Azione di trasmissione: sono presenti contenuti multimediali esterni, ma utilizzano un file system incompatibile (o sono vuoti). Il percorso a
ACTION_MEDIA_NOFS
il punto di montaggio per i contenuti multimediali da controllare è
contenuto nel campo Intent.mData.

Azione di trasmissione: i contenuti multimediali esterni sono stati
ACTION_MEDIA_REMOVED
rimossi.
Azione di trasmissione: lo scanner multimediale ha terminato
ACTION_MEDIA_SCANNER_FINISHED
la scansione di una directory.
Azione di trasmissione: richiedi allo scanner multimediale di
ACTION_MEDIA_SCANNER_SCAN_FILE
eseguire la scansione di un file e aggiungerlo al database multimediale.

Azione di trasmissione: lo scanner multimediale ha iniziato
ACTION_MEDIA_SCANNER_STARTED
a eseguire la scansione di una directory.
Azione di trasmissione: il supporto multimediale esterno è smontato
ACTION_MEDIA_SHARED
perché è condiviso tramite memoria di massa USB.
Azione di trasmissione: è presente un supporto esterno, ma
ACTION_MEDIA_UNMOUNTABLE
non può essere montato.
Azione di trasmissione: è presente un supporto esterno, ma
ACTION_MEDIA_UNMOUNTED
non è montato nel relativo punto di montaggio.
Azione di trasmissione: è in procinto di essere effettuata una chiamata in uscita
ACTION_NEW_OUTGOING_CALL
.
Azione di trasmissione: è stato installato un nuovo pacchetto di applicazioni
ACTION_PACKAGE_ADDED
sul dispositivo.
Azione di trasmissione: un pacchetto dell'applicazione esistente
ACTION_PACKAGE_CHANGED
è stato modificato (ad es. un componente è stato attivato o disattivato.

Azione di trasmissione: l'utente ha cancellato i dati di un pacchetto.
Deve essere preceduto da ACTION_PACKAGE_RESTARTED, dopodiché viene inviato ACTION_PACKAGE_DATA_CLEARED e tutti i dati persistenti vengono cancellati.

Tieni presente che il pacchetto autorizzato
non riceve questa trasmissione. I dati contengono
il nome del pacchetto.
Azione di trasmissione: un pacchetto di applicazioni esistente
è stato rimosso dal dispositivo. I dati
ACTION_PACKAGE_REMOVED
contengono il nome del pacchetto. Il pacchetto
in fase di installazione non riceve questo Intent.
Azione di trasmissione: è stata installata una nuova versione del pacchetto
ACTION_PACKAGE_REPLACED
di un'applicazione, sostituendo una versione esistente
installata in precedenza.
Azione di trasmissione: l'utente ha riavviato un

Tieni presente
che il pacchetto riavviato non riceve questa
trasmissione. I dati contengono il nome del
pacchetto.
Azione di trasmissione: alcuni fornitori di contenuti hanno
parti del proprio spazio dei nomi in cui pubblicano nuovi
EVENTI_FORNITORE_AZIONI_MODIFICATI
o elementi che potrebbero interessare particolarmente all'utente.

ACTION_SCREEN_OFF
Azione di trasmissione: inviata dopo lo spegnimento dello schermo.
ACTION_SCREEN_ON
Azione di trasmissione: inviata dopo l'accensione dello schermo.
Azione di trasmissione: un ID utente è stato rimosso
ACTION_UID_REMOVED
dal sistema.
Azione di trasmissione: il dispositivo è passato alla modalità
ACTION_UMS_CONNECTED
Mass Storage USB.

Azione di trasmissione: il dispositivo è uscito dalla modalità di archiviazione di massa USB
ACTION_UMS_DISCONNECTED
.
Azione di trasmissione: inviata quando l'utente è presente
ACTION_USER_PRESENT
dopo il risveglio del dispositivo (ad es.quando la
chiave di blocco non è presente).
Azione di trasmissione: lo sfondo di sistema corrente
ACTION_WALLPAPER_CHANGED
è cambiato.
ACTION_TIME_CHANGED
Azione di trasmissione: l'ora è stata impostata.
ACTION_TIME_TICK
Azione di trasmissione: l'ora corrente è cambiata.
ACTION_TIMEZONE_CHANGED
Azione di trasmissione: il fuso orario è cambiato.
Azione di trasmissione: lo stato di ricarica o il livello
ACTION_BATTERY_CHANGED
della batteria è cambiato.
Azione di trasmissione: indica la condizione di batteria in esaurimento
ACTION_BATTERY_LOW
sul dispositivo. Questa trasmissione corrisponde alla
finestra di dialogo di sistema"Avviso batteria in esaurimento".
Azione di trasmissione: indica che la batteria è ora in ordine
dopo essere stata in esaurimento. Verrà inviato
ACTION_BATTERY_OKAY
dopo ACTION_BATTERY_LOW quando la batteria
è tornata a uno stato normale.
Stato della rete
Azione intent
Descrizione
Azione intent di trasmissione che indica che lo stato
NETWORK_STATE_CHANGED_ACTION
della connettività Wi-Fi è cambiato.
Azione di intenzione di trasmissione che indica che il valore
RSSI_CHANGED_ACTION
RSSI (intensità del segnale) è cambiato.
Azione di intent di trasmissione che indica che è stata stabilita o persa una connessione
SUPPLICANT_STATE_CHANGED_ACTION
al supplicant.

Azione di intent di trasmissione che indica che il Wi-Fi
WIFI_STATE_CHANGED_ACTION
è stato attivato, disattivato, è in fase di attivazione,
disattivazione o è sconosciuto.
Gli ID rete delle reti configurate
NETWORK_IDS_CHANGED_ACTION
potrebbero essere cambiati.
Azione di intenzione di trasmissione che indica che l'impostazione
ACTION_BACKGROUND_DATA_SETTING_CHANGED per l'utilizzo dei dati in background ha
modificato i valori.
Intent di trasmissione che indica che si è verificata una variazione della connettività di rete
CONNECTIVITY_ACTION
.
Azione di trasmissione: l'utente ha attivato o disattivato la modalità aereo
ACTION_AIRPLANE_MODE_CHANGED
sul telefono.

Appendice C: considerazioni future Questa appendice chiarisce alcune parti della definizione di compatibilità di Android
1.6 e, in alcuni casi, illustra le modifiche previste o pianificate per una
versione futura della piattaforma Android. Questo allegato è solo a scopo informativo e di pianificazione e
non fa parte della definizione di compatibilità per Android 1.6.
1. Dispositivi diversi dai telefoni
Android 1.6 è destinato esclusivamente ai telefoni; la funzionalità di telefonia non è facoltativa. Le versioni future
della piattaforma Android dovrebbero rendere facoltativa la telefonia (e quindi consentire dispositivi Android
diversi dagli smartphone), ma solo gli smartphone sono compatibili con Android 1.6.
2. Compatibilità Bluetooth
La versione Android 1.6 di Android non supporta le API Bluetooth, pertanto dal punto di vista della compatibilità
il Bluetooth non impone alcuna considerazione per questa versione della piattaforma. Tuttavia, una versione futura
di Android introdurrà le API Bluetooth. A quel punto, il supporto del Bluetooth diventerà obbligatorio per la
compatibilità.
Di conseguenza, consigliamo vivamente di includere il Bluetooth nei dispositivi con Android 1.6, in modo che siano
compatibili con le versioni future di Android che richiedono il Bluetooth.
3. Componenti hardware obbligatori
Tutti i componenti hardware indicati nella Sezione 8 (inclusi Wi-Fi, magnetometro/bussola, accelerometro e così via) sono
obbligatori e non possono essere omessi. Le versioni future di Android dovrebbero rendere facoltativi alcuni (ma non tutti) di
questi componenti, insieme agli strumenti corrispondenti per consentire agli sviluppatori di terze parti di gestire queste
modifiche.
4. App di esempio
Il documento di definizione della compatibilità per una versione futura di Android includerà un elenco di applicazioni più ampio e rappresentativo rispetto a quello elencato nella Sezione 4 sopra.
Per Android 1.6, è necessario testare le
app elencate nella Sezione 4.
5. Touchscreen
Le versioni future della definizione di compatibilità potrebbero o meno consentire ai dispositivi di omettere i touchscreen.
Tuttavia, al momento gran parte dell'implementazione del framework Android presuppone l'esistenza di un
touchscreen; l'omissione di un touchscreen potrebbe causare un malfunzionamento sostanziale di tutte le attuali applicazioni Android di terze parti,
pertanto in Android 1.6 è necessario un touchscreen per la compatibilità.

6. Prestazioni
Le versioni future del CTS misureranno anche l'utilizzo della CPU e le prestazioni dei seguenti
componenti di un'implementazione:
• Grafica 2D
• Grafica 3D
• Riproduzione video
• Riproduzione audio
• Riproduzione Bluetooth A2DP

Definizione di compatibilità di Android 1.6 Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Struttura del documento

Definizione di compatibilità di Android 1.6
Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.