Questa pagina è stata tradotta dall'API Cloud Translation.

Definizione di compatibilità con Android 1.6

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

1. Introduzione
Questo documento elenca i requisiti che devono essere soddisfatti affinché i telefoni cellulari possano esserlo
compatibile con Android 1.6. Questa definizione presuppone la familiarità con il Programma di compatibilità Android
[Risorse, 1].
L'uso di "deve", "non deve", "richiesto", "deve", "non deve", "dovrebbe", "non dovrebbe", "raccomandato",
"può" e "facoltativo" sono conformi allo standard IETF definito in RFC2119 [ Risorse , 2].
Come utilizzato in questo documento, un "implementatore del dispositivo" o "implementatore" è una persona o un'organizzazione in via di sviluppo
una soluzione hardware/software con Android 1.6. Una "implementazione del dispositivo" o "implementazione" è il file
soluzione hardware/software così sviluppata.
Per essere considerato compatibile con Android 1.6, implementazioni del dispositivo:
1. DEVE soddisfare i requisiti presentati nella presente Definizione di compatibilità, inclusi eventuali documenti
incorporato tramite riferimento.
2. DEVE superare l'Android Compatibility Test Suite (CTS) disponibile come parte di Android Open
Progetto sorgente [ Risorse , 3]. Il CTS testa la maggior parte, ma non tutti , i componenti descritti in questo documento
documento.
Laddove questa definizione o il CTS siano silenziosi, ambigui o incompleti, la responsabilità è del dispositivo
implementatore per 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. Dispositivo
gli implementatori sono fortemente incoraggiati a basare le loro implementazioni sul codice sorgente "upstream".
disponibile dal progetto Android Open Source. Mentre alcuni componenti ipoteticamente potrebbero essere sostituiti
con implementazioni alternative questa pratica è fortemente sconsigliata, in quanto lo diventerà il superamento dei test CTS
sostanzialmente più difficile. È responsabilità dell'implementatore garantire la piena compatibilità comportamentale con
l'implementazione Android standard, inclusa e oltre la 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/
come funziona
2. Livelli dei requisiti IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
3. Suite di test di compatibilità: http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite--ct
4. Progetto open source Android: http://source.android.com/
5. Definizioni e documentazione API: http://developer.android.com/reference/packages.html
6. Fornitori di contenuti: http://code.google.com/android/reference/android/provider/package-
riepilogo.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. Riferimento per le autorizzazioni Android: http://developer.android.com/reference/android/
Manifest.permission.html
10. Costruisci costanti: http://developer.android.com/reference/android/os/Build.html
11. Visualizzazione Web: http://developer.android.com/reference/android/webkit/WebView.html
12. Estensioni del browser Gears: http://code.google.com/apis/gears/

13. Specifica della Dalvik Virtual Machine, trovata nella directory dalvik/docs di un codice sorgente
guardare; disponibile anche su http://android.git.kernel.org/?p=platform/
dalvik.git;a=albero;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 allo stile delle icone della barra di stato: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Gestione ricerche: 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 di Android: http://developer.android.com/guide/topics/fundamentals.html
21. Android Debug Bridge (adb): http://code.google.com/android/reference/adb.html
22. Servizio Dalvik Debug Monitor (ddms): http://code.google.com/android/reference/ddms.html
23. Scimmia: 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/
Configurazione.html
26. Metriche di visualizzazione: 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. Riferimento per la sicurezza e le autorizzazioni Android: http://developer.android.com/guide/topics/security/
sicurezza.html
Molte di queste risorse derivano direttamente o indirettamente dall'SDK di Android 1.6 e lo saranno
funzionalmente identico alle informazioni contenute nella documentazione dell'SDK. In tutti i casi in cui questo
La definizione di compatibilità non è d'accordo con la documentazione dell'SDK, viene presa in considerazione la documentazione dell'SDK
autorevole. Eventuali dettagli tecnici forniti nei riferimenti sopra riportati sono considerati per inclusione
far parte di questa definizione di compatibilità.
3. Software
La piattaforma Android include sia un set di API gestite ("hard"), sia un corpo di cosiddette API "soft".
come il sistema di intenti, le API del codice nativo e le API delle applicazioni Web. Questa sezione descrive in dettaglio il difficile e
API soft che sono parte integrante della compatibilità, nonché alcune altre interfacce tecniche e utente pertinenti
comportamenti. Le implementazioni del dispositivo DEVONO essere conformi a tutti i requisiti di questa sezione.
3.1. Compatibilità API gestita
L'ambiente di esecuzione gestito (basato su Dalvik) è il veicolo principale per le applicazioni Android. IL
L'API (Application Programming Interface) Android è l'insieme di interfacce della piattaforma Android a cui sono esposte
applicazioni in esecuzione nell'ambiente VM gestito. Le implementazioni del dispositivo DEVONO essere complete
implementazioni, inclusi tutti i comportamenti documentati, di qualsiasi API documentata esposta da Android
1.6 SDK, come ad esempio:
1. API principali del linguaggio Java Android [Risorse, 5].
2. Fornitori di contenuti [Risorse , 6].
3. Risorse [Risorse, 7].
4. Attributi ed elementi AndroidManifest.xml [Risorse, 8].

Le implementazioni dei dispositivi NON DEVONO omettere alcuna API gestita, alterare le interfacce API o le firme, deviare
dal comportamento documentato o includere no-op, tranne dove specificamente consentito da questa compatibilità
Definizione.
3.2. Compatibilità API soft
Oltre alle API gestite della Sezione 3.1, Android include anche un significativo "soft" solo runtime
API, sotto forma di cose come intenti, autorizzazioni e aspetti simili delle applicazioni Android
che non può essere applicato in fase di compilazione dell'applicazione. Questa sezione descrive in dettaglio le API e il sistema "soft".
comportamenti richiesti per la compatibilità con Android 1.6. Le implementazioni del dispositivo DEVONO soddisfare tutti i requisiti
requisiti presentati in questa sezione.
3.2.1. Autorizzazioni
Gli implementatori del dispositivo DEVONO supportare e applicare tutte le costanti di autorizzazione come documentato dal
Pagina di riferimento delle autorizzazioni [ Risorse , 9]. Si noti che la Sezione 10 elenca requisiti aggiuntivi relativi a
il modello di sicurezza Android.
3.2.2. Costruisci parametri
Le API Android includono una serie di costanti nella classe android.os.Build [Resources, 10] che sono
destinato a descrivere il dispositivo attuale. Per fornire valori coerenti e significativi su tutto il dispositivo
implementazioni, la tabella seguente include ulteriori restrizioni sui formati di questi valori a cui
le implementazioni del dispositivo DEVONO essere conformi.
Parametro
Commenti
La versione del sistema Android attualmente in esecuzione, in formato umano
android.os.Build.VERSION.RELEASE
formato leggibile. Per Android 1.6, questo campo DEVE avere il valore stringa
"1.6".
La versione del sistema Android attualmente in esecuzione, in 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 dall'uomo.
Questo valore NON DEVE essere riutilizzato per diverse build spedite alla fine
utenti android.os.Build.VERSION.INCREMENTAL. Un uso tipico di questo campo è indicare quale numero di build o
l'identificatore di modifica del controllo del codice sorgente è stato utilizzato per generare il file build. Là
non ci sono requisiti sul formato specifico di questo campo, tranne che esso
NON DEVE essere null o una stringa vuota ("").
Un valore scelto dall'implementatore del dispositivo che identifica lo specifico interno
hardware utilizzato dal dispositivo, in formato leggibile dall'uomo. Un possibile utilizzo
android.os.Build.BOARD
di questo campo sta ad indicare la revisione specifica della scheda che alimenta il
dispositivo. Non ci sono requisiti sul formato specifico di questo campo,
tranne che NON DEVE essere null o una stringa vuota ("").
Un valore scelto dall'implementatore del dispositivo che identifica il nome del file
android.os.Build.BRAND
azienda, organizzazione, individuo, ecc. che ha prodotto il dispositivo, in
formato leggibile dall'uomo. Un possibile utilizzo di questo campo è indicare l'OEM

e/o l'operatore che ha venduto il dispositivo. Non ci sono requisiti per il
formato specifico di questo campo, tranne che NON DEVE essere nullo o vuoto
corda ("").
Un valore scelto dall'implementatore del dispositivo che identifica lo specifico
configurazione o revisione della carrozzeria (a volte chiamata "industriale
android.os.Build.DEVICE
design") del dispositivo. Non ci sono requisiti sul formato specifico
di questo campo, tranne che NON DEVE essere null o una stringa vuota ("").
Una stringa che identifica in modo univoco questa build. DOVREBBE essere ragionevolmente
leggibile dagli umani. 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/miodispositivo/generic/generic:Donut/ERC77/
3359:debugutente/chiavi-test
L'impronta digitale NON DEVE contenere spazi. Se altri campi inclusi nel file
il modello sopra ha spazi, DOVREBBERO essere sostituiti con ASCII
carattere di sottolineatura ("_") nell'impronta digitale.
Una stringa che identifica in modo univoco l'host su cui è stata creata la build, in formato umano
android.os.Build.HOST
formato leggibile. Non ci sono requisiti sul formato specifico di questo
campo, tranne che NON DEVE essere null o una stringa vuota ("").
Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a uno specifico
rilascio, in formato leggibile dall'uomo. Questo campo può essere uguale a
android.os.Build.VERSION.INCREMENTAL, ma DOVREBBE essere un valore
android.os.Build.ID
destinato ad essere in qualche modo significativo per gli utenti finali. Non ci sono
requisiti sul formato specifico di questo campo, tranne che NON DEVE
essere null o una stringa vuota ("").
Un valore scelto dall'implementatore del dispositivo contenente il nome del file
dispositivo noto all'utente finale. Questo DOVREBBE essere lo stesso nome
android.os.Build.MODEL
in base al quale il dispositivo viene commercializzato e venduto agli utenti finali. Non ci sono
requisiti sul formato specifico di questo campo, tranne che NON DEVE
essere null o una stringa vuota ("").
Un valore scelto dall'implementatore del dispositivo contenente lo sviluppo
nome o nome in codice del dispositivo. DEVE essere leggibile dall'uomo, ma non lo è
android.os.Build.PRODUCT
necessariamente destinati alla visualizzazione da parte degli utenti finali. Non ci sono requisiti
sul formato specifico di questo campo, tranne che NON DEVE essere null o the
stringa vuota ("").
Un elenco di tag separati da virgole scelti dall'implementatore del dispositivo che
distinguere ulteriormente la build. Ad esempio, "unsigned,debug". Questo campo
android.os.Build.TAGS
NON DEVE essere null o una stringa vuota (""), ma un singolo tag (come
"rilascio") va bene.
android.os.Build.TIME
Un valore che rappresenta il timestamp di quando si è verificata la compilazione.
Un valore scelto dall'implementatore del dispositivo che specifica il runtime
configurazione della build. Questo campo DOVREBBE avere uno dei valori
android.os.Build.TYPE
corrispondenti alle tre tipiche configurazioni runtime di Android: "utente",
"userdebug" o "eng".
Un nome o un ID utente dell'utente (o utente automatizzato) che ha generato il file
android.os.Build.USER
costruire. Non ci sono requisiti sul formato specifico di questo campo,
tranne che NON DEVE essere null o una stringa vuota ("").

3.2.3. Compatibilità degli intenti
Android utilizza gli intenti per ottenere un'integrazione liberamente accoppiata tra le applicazioni. Questa sezione descrive
requisiti relativi ai modelli di intenti che DEVONO essere rispettati dalle implementazioni del dispositivo. Di
"onorato", significa che l'implementatore del dispositivo DEVE fornire un'attività, un servizio o altro Android
componente che specifica un filtro di intento corrispondente e si associa e implementa il comportamento corretto per ciascuno
modello di intento specificato.
3.2.3.1. Intenti dell'applicazione principale
Il progetto upstream Android definisce una serie di applicazioni principali, come un combinatore telefonico, un calendario,
rubrica, lettore musicale e così via. Gli implementatori del dispositivo POSSONO sostituire queste applicazioni con
versioni alternative.
Tuttavia, qualsiasi versione alternativa di questo tipo DEVE rispettare gli stessi modelli di intenti forniti dall'upstream
progetto. (Ad esempio, se un dispositivo contiene un lettore musicale alternativo, deve comunque rispettare il modello di intento
rilasciato da applicazioni di terze parti per scegliere un brano.) Le implementazioni del dispositivo DEVONO supportare tutti i modelli di intenti
elencati nell'Appendice A.
3.2.3.2. Override dell'intento
Poiché Android è una piattaforma estensibile, gli implementatori del dispositivo DEVONO consentire ogni modello di intent descritto in
L'Appendice A deve essere sovrascritta da applicazioni di terze parti. Il progetto open source Android originale
lo consente per impostazione predefinita; gli implementatori del dispositivo NON DEVONO attribuire privilegi speciali alle applicazioni di sistema'
l'utilizzo di questi modelli di intenti o impedire che applicazioni di terze parti si leghino e ne assumano il controllo
questi modelli. Questo divieto include specificamente la disabilitazione dell'interfaccia utente "Scelta" che consente
all'utente di scegliere tra più applicazioni che gestiscono tutte lo stesso modello di intento.
3.2.3.3. Spazi dei nomi di intenti
Gli implementatori del dispositivo NON DEVONO includere alcun componente Android che rispetti qualsiasi nuovo Intent o
Modelli di intenti di trasmissione che utilizzano un'AZIONE, una CATEGORIA o un'altra stringa chiave nello spazio dei nomi android.*.
Gli implementatori del dispositivo NON DEVONO includere componenti Android che rispettino qualsiasi nuovo Intent o
Modelli di intenti di trasmissione che utilizzano un'AZIONE, una CATEGORIA o un'altra stringa chiave in uno spazio del pacchetto
appartenente ad un'altra organizzazione. Gli implementatori del dispositivo NON DEVONO alterare o estendere nessuno degli Intenti
modelli elencati nelle Appendici A o B.
Questo divieto è analogo a quello specificato per le classi del linguaggio Java nella Sezione 3.6.

3.2.3.4. Intenti di trasmissione
Le applicazioni di terze parti si affidano alla piattaforma per trasmettere determinati intenti per notificare loro le modifiche al file
ambiente hardware o software. I dispositivi compatibili con Android DEVONO trasmettere la trasmissione pubblica
Intenti in risposta a eventi di sistema appropriati. Un elenco degli intenti di trasmissione richiesti è fornito in
Appendice B; tuttavia, tieni presente che l'SDK può definire ulteriori intenti di trasmissione, che DEVONO esserlo
onorato.
3.3. Compatibilità API nativa
Il codice gestito in esecuzione in Dalvik può richiamare il codice nativo fornito nel file .apk dell'applicazione come ELF
File .so compilato per l'architettura hardware del dispositivo appropriata. Le implementazioni del dispositivo DEVONO includere
supporto per il codice in esecuzione nell'ambiente gestito per richiamare il codice nativo, utilizzando lo standard Java
Semantica dell'interfaccia nativa (JNI). Le seguenti API devono essere disponibili per il codice nativo:
• libc (libreria C)
• libm (libreria matematica)
• Interfaccia JNI
• libz (compressione Zlib)
• liblog (registrazione Android)
• Supporto minimo per C++
• OpenGL ES 1.1
Queste librerie DEVONO essere compatibili con il codice sorgente (ovvero compatibili con l'intestazione) e compatibili con il binario (per un dato file
architettura del processore) con le versioni fornite in Bionic dal progetto Android Open Source. Da
le implementazioni Bionic non sono completamente compatibili con altre implementazioni come GNU C
libreria, gli implementatori del dispositivo DOVREBBERO utilizzare l'implementazione Android. Se gli implementatori del dispositivo utilizzano a
diverse implementazioni di queste librerie, devono garantire la compatibilità di header e binari.
La compatibilità del codice nativo è impegnativa. Per questo motivo, vogliamo ribadire che gli implementatori dei dispositivi lo sono
MOLTO fortemente incoraggiato a utilizzare le implementazioni upstream delle librerie sopra elencate, per aiutare
garantire la compatibilità.
3.4. Compatibilità API Web
Molti sviluppatori e applicazioni si affidano al comportamento della classe android.webkit.WebView [ Risorse ,
11] per le loro interfacce utente, quindi l'implementazione WebView deve essere compatibile su Android
implementazioni. L'implementazione Android Open Source utilizza la versione del motore di rendering WebKit
implementare la WebView.
Poiché non è possibile sviluppare una suite di test completa per un browser web, gli implementatori del dispositivo
DEVE utilizzare la specifica build upstream di WebKit nell'implementazione WebView. Nello specifico:
• WebView DEVE utilizzare la build 528.5+ WebKit dall'albero Android Open Source upstream per
Android 1.6. Questa build include un insieme specifico di funzionalità e correzioni di sicurezza per WebView.
• La stringa dell'agente utente riportata da WebView DEVE essere in questo formato:
Mozilla/5.0 (Linux; U; Android 1.6; <lingua>-<paese>; <dispositivo
nome>; Build/<ID build>) AppleWebKit/528.5+ (KHTML, come Gecko)
Versione/3.1.2 Safari mobile/525.20.1

◦ La stringa "<nome dispositivo>" 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 "<lingua>" e "<paese>" DOVREBBERO seguire le solite convenzioni per
codice paese e lingua e DOVREBBE fare riferimento alle impostazioni locali correnti del dispositivo in
momento della richiesta.
Le implementazioni POSSONO fornire una stringa dell'agente utente personalizzata nell'applicazione browser autonoma. Cosa c'è
inoltre, il browser autonomo PUÒ essere basato su una tecnologia browser alternativa (come Firefox,
Opera, ecc.) Tuttavia, anche se viene fornita un'applicazione browser alternativa, il componente WebView
fornito ad applicazioni di terze parti DEVE essere basato su WebKit, come sopra.
L'applicazione browser autonoma DOVREBBE includere il supporto per Gears [ Risorse, 12] e MAGGIO
includere il supporto per alcuni o tutti HTML5.
3.5. Compatibilità comportamentale dell'API
I comportamenti di ciascuno dei tipi di API (gestita, soft, nativa e web) devono essere coerenti con
implementazione preferita di Android disponibile dal progetto Android Open Source.
Alcune aree specifiche di compatibilità sono:
• I dispositivi NON DEVONO modificare il comportamento o il significato di un intento standard
• I dispositivi NON DEVONO alterare il ciclo di vita o la semantica del ciclo di vita di un particolare tipo di sistema
componente (come Servizio, Attività, ContentProvider, ecc.)
• I dispositivi NON DEVONO modificare la semantica di un particolare permesso
L'elenco riportato sopra non è completo e spetta agli implementatori del dispositivo garantire il comportamento corretto
Compatibilità. Per questo motivo, gli implementatori del dispositivo DOVREBBERO utilizzare il codice sorgente disponibile tramite il file
Progetto Android Open Source ove possibile, piuttosto che reimplementare parti significative del sistema.
La Compatibility Test Suite (CTS) verifica la compatibilità comportamentale di porzioni significative della piattaforma,
ma non tutto. È responsabilità dell'implementatore garantire la compatibilità comportamentale con Android
Progetto Open Source.
3.6. Spazi dei nomi API
Android segue le convenzioni dello spazio dei nomi dei pacchetti e delle classi definite dalla programmazione Java
lingua. Per garantire la compatibilità con applicazioni di terze parti, gli implementatori del dispositivo NON DEVONO realizzare
qualsiasi modifica proibita (vedi sotto) a questi spazi dei nomi del pacchetto:
• java.*
• javax.*
• sole.*
• androide.*
• com.android.*
Le modifiche vietate includono:
• Le implementazioni dei dispositivi NON DEVONO modificare le API esposte pubblicamente sulla piattaforma Android
modificando qualsiasi metodo o firma di classe oppure rimuovendo classi o campi di classe.

• Gli implementatori del dispositivo POSSONO modificare l'implementazione sottostante delle API, ma tale
le modifiche NON DEVONO avere alcun impatto sul comportamento dichiarato e sulla firma del linguaggio Java di alcuno
API esposte pubblicamente.
• Gli implementatori del dispositivo NON DEVONO aggiungere alcun elemento esposto pubblicamente (come classi o
interfacce, o campi o metodi a classi o interfacce esistenti) alle API di cui sopra.
Un "elemento pubblicamente esposto" è qualsiasi costrutto che non è decorato con il marcatore "@hide" nel file
codice sorgente Android upstream. In altre parole, gli implementatori del dispositivo NON DEVONO esporre nuove API o
alterare le API esistenti negli spazi dei nomi sopra indicati. Gli implementatori del dispositivo POSSONO effettuare solo operazioni interne
modifiche, ma tali modifiche NON DEVONO essere pubblicizzate o altrimenti esposte agli sviluppatori.
Gli implementatori del dispositivo POSSONO aggiungere API personalizzate, ma tali API NON DEVONO trovarsi in uno spazio dei nomi di proprietà
da o riferito ad un'altra organizzazione. Ad esempio, gli implementatori del dispositivo NON DEVONO aggiungere API al file
com.google.* o spazio dei nomi simile; solo Google può farlo. Allo stesso modo, Google NON DEVE aggiungere API a
spazi dei nomi di altre società.
Se l'implementatore di un dispositivo propone di migliorare uno degli spazi dei nomi dei pacchetti di cui sopra (ad esempio aggiungendo
nuova funzionalità utile a un'API esistente o aggiungendo una nuova API), l'implementatore DOVREBBE visitare
source.android.com e iniziare il processo per contribuire con modifiche e codice, secondo il
informazioni su quel sito.
Tieni presente che le restrizioni di cui sopra corrispondono alle convenzioni standard per la denominazione delle API in Java
linguaggio di programmazione; questa sezione mira semplicemente a rafforzare tali convenzioni e a renderle vincolanti
attraverso l'inclusione in questa definizione di compatibilità.
3.7. Compatibilità della macchina virtuale
Un dispositivo Android compatibile deve supportare la specifica completa del bytecode Dalvik Executable (DEX) e
Semantica della Dalvik Virtual Machine [Risorse, 13].
3.8. Compatibilità dell'interfaccia utente
La piattaforma Android include alcune API per sviluppatori che consentono agli sviluppatori di connettersi all'utente del sistema
interfaccia. Le implementazioni dei dispositivi DEVONO incorporare queste API dell'interfaccia utente standard in interfacce utente personalizzate
si sviluppano, come spiegato di seguito.
3.8.1. Widget
Android definisce un tipo di componente, l'API e il ciclo di vita corrispondenti che consentono l'esposizione delle applicazioni
un "AppWidget" per l'utente finale [Risorse , 14] . La versione di riferimento Android Open Source include a
Applicazione di avvio che include elementi dell'interfaccia utente che consentono all'utente di aggiungere, visualizzare e rimuovere
AppWidgets dalla schermata principale.
Gli implementatori del dispositivo POSSONO sostituire un'alternativa al Launcher di riferimento (ad esempio la schermata iniziale).
I launcher alternativi DOVREBBERO includere il supporto integrato per AppWidget ed esporre l'interfaccia utente
elementi per aggiungere, visualizzare e rimuovere AppWidget direttamente nel Launcher. Lanciatori alternativi MAGGIO
omettere questi elementi dell'interfaccia utente; tuttavia, se vengono omessi, l'implementatore del dispositivo DEVE fornire a
applicazione separata accessibile dal Launcher che consente agli utenti di aggiungere, visualizzare e rimuovere
AppWidget.

3.8.2. Notifiche
Android include API che consentono agli sviluppatori di avvisare gli utenti di eventi importanti [Risorse, 15]. Dispositivo
gli implementatori DEVONO fornire supporto per ciascuna classe di notifica così definita; nello specifico: suoni,
vibrazione, luce e barra di stato.
Inoltre, l'implementazione DEVE eseguire il rendering correttamente e tutte le risorse (icone, file audio, ecc.)
previsto nelle API [Risorse, 7] o nella guida allo stile delle icone della barra di stato [Risorse , 16]. Dispositivo
gli implementatori POSSONO fornire un'esperienza utente alternativa per le notifiche rispetto a quella fornita da
riferimento all'implementazione Android Open Source; tuttavia, tali 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,
ed esporre i dati della loro applicazione nella ricerca del sistema globale. In generale, questa funzionalità
è costituito da un'unica interfaccia utente a livello di sistema che consente agli utenti di inserire query e visualizzare suggerimenti
mentre gli utenti digitano e visualizza i risultati. Le API Android consentono agli sviluppatori di riutilizzare questa interfaccia per fornire
effettuare ricerche all'interno delle proprie app e consentire agli sviluppatori di fornire risultati all'utente comune della ricerca globale
interfaccia.
Le implementazioni del dispositivo DEVONO includere un'unica interfaccia utente di ricerca condivisa a livello di sistema in grado di
suggerimenti in tempo reale in risposta all'input dell'utente. Le implementazioni del dispositivo DEVONO implementare le API that
consentire 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
nella casella di ricerca quando viene eseguito in modalità di ricerca globale. Se non sono installate applicazioni di terze parti
fare uso di questa funzionalità, il comportamento predefinito DOVREBBE essere quello di visualizzare i risultati del motore di ricerca web e
suggerimenti.
Le implementazioni del dispositivo POSSONO fornire interfacce utente di ricerca alternative, ma DOVREBBERO includere un'interfaccia hard o soft
pulsante di ricerca dedicato, che può essere utilizzato in qualsiasi momento all'interno di qualsiasi app per richiamare il framework di ricerca,
con il comportamento previsto nella documentazione API.
3.8.4. Toast
Le applicazioni possono utilizzare l'API "Toast" (definita in [ Risorse, 18]) per visualizzare brevi stringhe non modali
utente finale, che scompaiono dopo un breve periodo di tempo. Le implementazioni del dispositivo DEVONO visualizzare i toast da
applicazioni agli utenti finali in modo ad alta visibilità.
4. Compatibilità del software di riferimento
Gli implementatori del dispositivo DEVONO testare la compatibilità dell'implementazione utilizzando il seguente open source
applicazioni:
• Calcolatrice (inclusa nell'SDK)
• Lander lunare (incluso nell'SDK)
• ApiDemos (incluso nell'SDK)
• Le applicazioni "App per Android" [ Risorse, 19]
Ciascuna app sopra DEVE essere avviata e comportarsi correttamente durante l'implementazione, affinché l'implementazione sia valida

considerati compatibili.
5. Compatibilità dell'imballaggio dell'applicazione
Le implementazioni del dispositivo DEVONO installare ed eseguire file ".apk" Android generati dallo strumento "aapt".
incluso nell'SDK ufficiale di Android [ Risorse , 20].
Le implementazioni dei dispositivi NON DEVONO estendere il bytecode .apk, Android Manifest o Dalvik
formati in modo tale da impedire l'installazione e il corretto funzionamento di tali file su altri
dispositivi compatibili. Gli implementatori del dispositivo DOVREBBERO utilizzare l'implementazione upstream di riferimento di Dalvik,
e il sistema di gestione dei pacchetti dell'implementazione di riferimento.
6. Compatibilità multimediale
Un dispositivo Android compatibile deve supportare i seguenti codec multimediali. Tutti questi codec lo sono
forniti come implementazioni software nell'implementazione Android preferita da Android Open
Progetto sorgente [ Risorse , 4].
Tieni presente che né Google né Open Handset Alliance rilasciano alcuna dichiarazione in merito
i codec non sono gravati da brevetti di terze parti. Coloro che intendono utilizzare questo codice sorgente in hardware o
Si informano i prodotti software che le implementazioni di questo codice, anche nel software open source o
shareware, può richiedere licenze di brevetto dai relativi titolari dei brevetti.
Audio
Nome
Dettagli del decodificatore codificatore
File supportati
Contenuti mono/stereo in qualsiasi formato
3GPP (.3gp) e
combinazione di bit rate standard
MPEG-4 (.mp4, .m4a)
AACLC/LTP
X
file fino a 160 kbps e frequenze di campionamento. Nessun supporto per raw
tra 8 e 48kHz
AAC (.aac)
Contenuti mono/stereo in qualsiasi formato
3GPP (.3gp) e
HE-AACv1
combinazione di bit rate standard
MPEG-4 (.mp4, .m4a)
X
(CAA+)
file con velocità di campionamento fino a 96 kbps. Nessun supporto per raw
tra 8 e 48kHz
AAC (.aac)
Contenuti mono/stereo in qualsiasi formato
HE-AACv2
3GPP (.3gp) e
combinazione di bit rate standard
(migliorato
MPEG-4 (.mp4, .m4a)
X
fino a 96 kbps e frequenze di campionamento
CAA+)
File. Nessun supporto per raw
tra 8 e 48kHz
AAC (.aac)
AMR-NB
Da 4,75 a 12,2 kbps campionati @
File 3GPP (.3gp).
X
X
8kHz
AMR-WB
9 velocità da 6,60 kbit/s a 23,85
-File 3GPP (.3gp).
X
kbit/s campionato a 16kHz
MP3
File MP3 (.mp3) costanti mono/stereo da 8-320 Kbps
X
(CBR) o bit-rate variabile (VBR)
Digitare 0 e 1 (.mid, .xmf,
Tipo MIDI 0 e 1. Versione DLS 1
MIDI
X
.mxmf). Anche RTTTL/RTX
e 2. XMF e XMF mobile.
(.rtttl, .rtx), OTA (.ota),

Supporto per i formati delle suonerie
e iMelody (.imy)
RTTTL/RTX, OTA e iMelody
Ogg Vorbis
.ogg
X
PCM lineare a 8 e 16 bit (velocità in aumento
PCM
X
ONDA
al limite dell'hardware)
Immagine
File
Nome
Dettagli del decodificatore codificatore
Supportato
JPEG
X
X
base+progressivo
GIF
X
PNG
X
X
BMP
X
video
File
Nome
Dettagli del decodificatore codificatore
Supportato
3GPP (.3gp)
H.263
X
X
File
3GPP (.3gp)
H.264
X
e MPEG-4
(.mp4).
MPEG4
X
File 3GPP (.3gp).
SP
7. Compatibilità dello strumento di sviluppo
Le implementazioni del dispositivo 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 del dispositivo devono supportare tutte le funzioni ADB come documentate in Android
SDK. Il demone ADB lato dispositivo deve essere inattivo per impostazione predefinita, ma deve esserci un utente
Meccanismo accessibile per accendere il ponte di debug Android.
• Dalvik Debug Monitor Service o DDMS [Risorse , 22]
Le implementazioni del dispositivo devono supportare tutte le funzionalità DDMS come documentato nell'SDK Android.
Poiché DDMS utilizza ADB, il supporto per DDM dovrebbe essere inattivo per impostazione predefinita, ma deve essere supportato
Ogni volta che l'utente ha attivato il ponte di debug Android, come sopra.

• Monkey [Risorse, 23]
Le implementazioni del dispositivo devono includere il framework scimmia e renderlo disponibile per
applicazioni da utilizzare.
8. Compatibilità hardware
Android ha lo scopo di supportare gli implementatori di dispositivi che creano fattori e configurazioni innovativi in forma.
Allo stesso tempo gli sviluppatori Android si aspettano determinati hardware, sensori e API in tutto Android
dispositivo. Questa sezione elenca le funzionalità hardware che tutti i dispositivi compatibili Android 1.6 devono supportare. In
Sono richiesti Android 1.6, la maggior parte delle funzionalità hardware (come WiFi, bussola e accelerometro).
Se un dispositivo include un particolare componente hardware che ha un'API corrispondente per terze parti
Sviluppatori, l'implementazione del dispositivo deve implementare tale API come definita nell'SDK Android
documentazione.
8.1. Schermo
Android 1.6 include strutture che eseguono determinate operazioni di ridimensionamento e trasformazione automatiche sotto
Alcune circostanze, per garantire che le applicazioni di terze parti funzionino ragionevolmente bene su hardware
Configurazioni per le quali non sono state necessariamente progettate esplicitamente [Risorse, 24] . I dispositivi devono
Implementa correttamente questi comportamenti, come dettagliato in questa sezione.
8.1.1. Configurazioni di visualizzazione standard
Questa tabella elenca le configurazioni dello schermo standard considerate compatibili con Android:
Diagonale
Dimensione 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 del dispositivo corrispondenti a una delle configurazioni standard sopra devono essere configurate
Per segnalare le dimensioni dello schermo indicato alle applicazioni tramite Android.Content.res.Configuration [ Risorse,
25] classe.
Alcuni pacchetti. APK hanno manifesti che non li identificano come supportando un intervallo di densità specifico.
Quando si eseguono tali applicazioni, si applicano i seguenti vincoli:

• Le implementazioni del dispositivo devono interpretare tutte le risorse presenti come inadempienti per
"Medium" (noto come "MDPI" nella documentazione SDK.)
• Quando si opera su una schermata di densità "bassa", le implementazioni del dispositivo devono ridimensionare il mezzo/
Attività MDPI di un fattore di 0,75.
• Quando si opera su una schermata di densità "alta", le implementazioni del dispositivo devono aumentare la media/
Attività MDPI di un fattore di 1,5.
• Le implementazioni del dispositivo non devono ridimensionare le risorse all'interno di un intervallo di densità e devono ridimensionare
Asset da questi fattori esattamente tra intervalli di densità.
8.1.2. Configurazioni di visualizzazione non standard
Visualizza configurazioni che non corrispondono a una delle configurazioni standard elencate nella Sezione 8.2.1 richiedono
Ulteriore considerazione e lavoro per essere compatibili. Gli implementari del dispositivo devono contattare Android
Team di compatibilità come previsto nella Sezione 12 per ottenere classificazioni per il secchio delle dimensioni dello schermo, la densità,
e fattore di ridimensionamento. Quando fornite con queste informazioni, le implementazioni del dispositivo devono implementarle
come specificato.
Si noti che alcune configurazioni di visualizzazione (come schermate molto grandi o molto piccole e alcuni rapporti di aspetto)
sono fondamentalmente incompatibili con Android 1.6; Pertanto gli implementatori di dispositivi sono incoraggiati a farlo
Contatta il team di compatibilità Android il più presto possibile nel processo di sviluppo.
8.1.3. Visualizza metriche
Le implementazioni del dispositivo devono segnalare i valori corretti per tutte le metriche di visualizzazione definite in
Android.util.displaymetrics [Risorse , 26].
8.2. Tastiera
Implementazioni del dispositivo:
• Deve includere il supporto per il framework di gestione delle input (che consente di terze parti
sviluppatori per creare motori di gestione input - cioè tastiera soft) come dettagliato a
sviluppatore.android.com
• Deve fornire almeno un'implementazione della tastiera morbida (indipendentemente dal fatto che un duro
La tastiera è presente)
• Può includere implementazioni di tastiera morbida aggiuntive
• Può includere una tastiera hardware
• Non deve includere una tastiera hardware che non corrisponde a uno dei formati specificati
In Android.Content.res.Configuration [ Risorse, 25] (cioè Qwerty o 12-key)
8.3. Navigazione non touch
Implementazioni del dispositivo:
• Può omettere le opzioni di navigazione non touch (ovvero può omettere un trackball, un cuscinetto direzionale a 5 vie o
ruota)
• Deve segnalare via Android.Content.res.Configuration [Risorse , 25] il valore corretto per il
hardware del dispositivo

8.4. Orientamento schermo
I dispositivi compatibili devono supportare l'orientamento dinamico per applicazioni a ritratto o paesaggio
orientamento schermo. Cioè, il dispositivo deve rispettare la richiesta dell'applicazione per uno schermo specifico
orientamento. Le implementazioni del dispositivo possono selezionare l'orientamento del ritratto o del paesaggio come predefinito.
I dispositivi devono segnalare il valore corretto per l'orientamento corrente del dispositivo, ogni volta che interrogato tramite il
Android.content.res.configuration.orientation, android.view.display.getorientation () o altre API.
8.5. Ingresso touchscreen
Implementazioni del dispositivo:
• Deve avere un touchscreen
• Può avere touchscreen capacativo o resistivo
• Deve segnalare il valore di Android.Content.res.Configuration [ Risorse, 25] Riflettendo
corrispondente al tipo di touchscreen specifico sul dispositivo
8.6. USB
Implementazioni del dispositivo:
• Deve implementare un client USB, collegato a un host USB con una porta USB-A standard
• Deve implementare il ponte di debug Android su USB (come descritto nella Sezione 7)
• Deve implementare un client di archiviazione di massa USB per l'archiviazione rimovibile/multimediale è presente nel
dispositivo
• dovrebbe utilizzare il fattore di forma USB micro sul lato del dispositivo
• dovrebbe implementare il supporto per le specifiche di archiviazione di massa USB (in modo che sia rimovibile
oppure è possibile accedere all'archiviazione fissa sul dispositivo da un PC host)
• Può includere una porta non standard sul lato del dispositivo, ma in tal caso deve essere spedito con un cavo in grado di
Collegamento del pinout personalizzato alla porta USB-A standard
8.7. Chiavi di navigazione
Le funzioni di casa, menu e schiena sono essenziali per il paradigma di navigazione Android. Dispositivo
Le implementazioni devono rendere queste funzioni disponibili per l'utente in ogni momento, indipendentemente dall'applicazione
stato. Queste funzioni dovrebbero essere implementate tramite pulsanti dedicati. Possono essere implementati
Utilizzo di software, gesti, pannello tocco, ecc., Ma in tal caso devono essere sempre accessibili e non oscuri o
interferire con l'area di visualizzazione dell'applicazione disponibile.
Gli implementari del dispositivo dovrebbero anche fornire una chiave di ricerca dedicata. Gli implementatori di dispositivi possono anche
Fornire chiavi di invio e fine per le telefonate.
8.8. Wifi
Le implementazioni del dispositivo devono supportare 802.11b e 802.11g e possono supportare 802.11a.

8.9. Telecamera
Le implementazioni del dispositivo devono includere una fotocamera. La fotocamera inclusa:
• Deve avere una risoluzione di almeno 2 megapixel
• Dovrebbe avere un focus automatico hardware o un software automatico implementato nella fotocamera
Driver (trasparente al software applicativo)
• Può avere hardware a fuoco fisso o edof (profondità di campo estesa)
• Può includere un flash. Se la fotocamera include un flash, la lampada flash non deve essere accesa mentre un
Android.hardware.camera.previewCallback Istance è stato registrato su un'anteprima della fotocamera
superficie.
Le implementazioni del dispositivo 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),
quindi il dispositivo deve utilizzare Android.hardware.pixelMort.ycbcr_420_sp per i dati di anteprima
fornito ai callback di applicazione.
2. Se un'applicazione registra un'istanza Android.hardware.camera.previewcallback e la
Sistema chiama il metodo OnPreviewFrame () quando il formato di anteprima è ycbcr_420_sp, il
I dati nel byte [] trasmessi in OnPreviewFrame () devono essere ulteriormente nel formato di codifica NV21.
(Questo è il formato usato in modo nativo dalla famiglia hardware 7K.) Cioè, NV21 deve essere il valore predefinito.
8.9.1. Telecamere non autofocus
Se un dispositivo manca di una fotocamera autofocus, l'implementatore del dispositivo deve soddisfare i requisiti aggiuntivi in
questa sezione. Le implementazioni del dispositivo devono implementare l'API della fotocamera completa inclusa in Android 1.6
Documentazione SDK in qualche modo ragionevole, indipendentemente dalle capacità di hardware della fotocamera.
Per Android 1.6, se la fotocamera manca di focus automatico, l'implementazione del dispositivo deve aderire a quanto segue:
1. Il sistema deve includere una proprietà del sistema di sola lettura denominata "ro.workaround.noautofocus"
con il valore di "1". Questo valore dovrebbe essere utilizzato da applicazioni come Android Market
identificare selettivamente le funzionalità del dispositivo e verrà sostituito in una versione futura di Android con un
API robusta.
2. Se un'applicazione chiama Android.hardware.camera.autofocus (), il sistema deve chiamare il
Metodo di richiamata Onautofocus () su qualsiasi registrazione
Android.hardware.camera.autofocuscallback istanze, anche se non si concentrano effettivamente
accaduto. Questo per evitare che le applicazioni esistenti si pavino aspettando per sempre un autofocus
callback che non verrà mai.
3. La chiamata al metodo AutofocusCallback.onautofocus () deve essere attivata dal conducente o
Framework in un nuovo evento sul thread di Framework Looper principale. Cioè, fotocamera.autofocus ()
Non deve chiamare direttamente AutoFocusllBack.onautofocus () poiché questo viola l'androide
Modello di threading Framework e romperà le app.
8.10. Accelerometro
Le implementazioni del dispositivo devono includere un accelerometro a 3 assi e devono essere in grado di consegnare eventi presso
almeno 50 Hz. Il sistema di coordinate utilizzato dall'accelerometro deve rispettare il sensore Android
Sistema di coordinate come dettagliato nelle API Android [Risorse , 28].

8.11. Bussola
Le implementazioni del dispositivo devono includere una bussola a 3 assi e devono essere in grado di consegnare eventi almeno
10 Hz. Il sistema di coordinate utilizzato dalla bussola deve essere conforme alla coordinata del sensore Android
Sistema 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 "GPS assistito"
Tecnica per ridurre al minimo il tempo di blocco GPS.
8.13. Telefonia
Implementazioni del dispositivo:
• Deve includere la telefonia GSM o CDMA
• Deve implementare le API appropriate come dettagliato nella documentazione SDK Android presso
sviluppatore.android.com
Si noti che questo requisito implica che i dispositivi non telefonici non sono compatibili con Android 1.6; Androide
1.6 I dispositivi devono includere hardware di telefonia. Si prega di consultare l'Appendice C per informazioni sul non telefono
dispositivi.
8.14. Controlli del volume
I dispositivi compatibili con Android devono includere un meccanismo per consentire all'utente di aumentare e ridurre il
Volume audio. Le implementazioni del dispositivo devono rendere sempre disponibili queste funzioni all'utente,
indipendentemente dallo stato di applicazione. Queste funzioni possono essere implementate utilizzando tasti hardware fisici,
software, gesti, pannelli touch, ecc., Ma devono essere sempre accessibili e non oscuri o interferire
Con l'area di visualizzazione dell'applicazione disponibile (vedere il display sopra).
Quando vengono utilizzati questi pulsanti, gli eventi chiave corrispondenti devono essere generati e inviati al
Applicazione in primo piano. Se l'evento non viene intercettato e affondato dall'applicazione, il dispositivo
L'implementazione deve gestire l'evento come controllo del volume del sistema.
9. Compatibilità delle prestazioni
Uno degli obiettivi del programma di compatibilità Android è garantire un'esperienza di applicazione coerente per
consumatori. Le implementazioni compatibili devono garantire non solo le applicazioni semplicemente eseguite correttamente
Il dispositivo, ma lo fanno con prestazioni ragionevoli e una buona esperienza utente nel complesso.
Le implementazioni del dispositivo devono soddisfare le metriche delle prestazioni chiave di un dispositivo compatibile Android 1.6,
Come nella tabella seguente:
Metrico
Soglia di performance
Commenti

Questo è testato da CTS.
Le seguenti applicazioni
Il tempo di lancio è misurato come il tempo totale per
dovrebbe essere lanciato all'interno del
Completare il caricamento dell'attività predefinita per il
Applicazione
tempo specificato.
applicazione, incluso il tempo necessario per avviare il
Ora di pranzo
Browser: meno di 1300 ms
Processo Linux, caricare il pacchetto Android in
MMS/SMS: meno di 700 ms
Dalvik VM e chiama OnCreate.
AlarmClock: meno di 650 ms
Sarà più applicazioni
Questo è testato da CTS.
lanciato. Rilanciare il
La prima applicazione simultanea dovrebbe
Applicazioni
Completare l'assunzione inferiore al
Tempo di lancio originale.
10. Compatibilità del modello di sicurezza
Le implementazioni del dispositivo devono implementare un modello di sicurezza coerente con la sicurezza della piattaforma Android
modello come definito nel documento di riferimento di sicurezza e autorizzazioni nelle API [Risorse, 29] nel
Documentazione per sviluppatori Android. Le implementazioni del dispositivo devono supportare l'installazione di autofirmati
Applicazioni senza richiedere autorizzazioni/certificati aggiuntivi da terzi/autorità.
In particolare, i dispositivi compatibili devono supportare i seguenti meccanismi di sicurezza:
10.1. Autorizzazioni
Le implementazioni del dispositivo devono supportare il modello di autorizzazioni Android come definito nell'androide
Documentazione degli sviluppatori [ Risorse , 9]. In particolare, le implementazioni devono far rispettare ogni autorizzazione
definito come descritto nella documentazione SDK; Nessuna autorizzazione può essere omessa, modificata o ignorata.
Le implementazioni possono aggiungere ulteriori autorizzazioni, a condizione che le nuove stringhe ID autorizzazione non siano in
Android.* Spazio dei nomi.
10.2. Isolamento dell'utente e del processo
Le implementazioni del dispositivo devono supportare il modello Sandbox dell'applicazione Android, in cui ogni applicazione
Funziona come un unico UID in stile UNIX e in un processo separato.
Le implementazioni del dispositivo devono supportare l'esecuzione di più applicazioni come ID utente Linux, fornito
che le applicazioni siano adeguatamente firmate e costruite, come definito nella sicurezza e nelle autorizzazioni
Riferimento [ Risorse , 29].

10.3. Autorizzazioni del filesystem
Le implementazioni del dispositivo devono supportare il modello di autorizzazioni di accesso ai file Android come definito in AS
definito nel riferimento di sicurezza e autorizzazioni [risorse , 29].
11. Suite di test di compatibilità
Le implementazioni del dispositivo devono passare la suite di test di compatibilità Android (CTS) [ Risorse, 3] Disponibile
Dal progetto open source Android, utilizzando il software di spedizione finale sul dispositivo. Inoltre,
Gli implementari del dispositivo dovrebbero utilizzare l'implementazione di riferimento nell'albero open source Android come
il più possibile e deve garantire la compatibilità in caso di ambiguità in CTS e per qualsiasi
Reimplementazioni di parti del codice sorgente di riferimento.
Il CTS è progettato per essere eseguito su un dispositivo reale. Come ogni software, il CTS può contenere di sé bug.
Il CTS sarà versione indipendentemente da questa definizione di compatibilità e revisioni multiple del
CTS può essere rilasciato per Android 1.6. Tuttavia, tali versioni fissano solo bug comportamentali nel CTS
Test e non imporranno nuovi test, comportamenti o API per un determinato rilascio della piattaforma.
12. Contattaci
È possibile contattare il team di compatibilità Android all'indirizzo compatibilità@android.com per chiarimenti relativi a
Questa definizione di compatibitiy e per fornire feedback su questa definizione.

Appendice A: intenti applicazioni richieste
Nota: questo elenco è provvisorio e verrà aggiornato in futuro.
Azioni dell'applicazione
Schemi tipi mime
(nessuno)
testo/semplice
http
testo/html
Navigatore
Android.intent.action.View
https
Applicazione/XHTML+XML
applicazione/
vnd.wap.xhtml+xml
(nessuno)
Android.intent.action.web_search
http
(nessuno)
https
Android.media.act.image_capture
Android.media.action.still_image_camera
Telecamera
Android.media.act.Video_Camera
Android.media.act.Video_Capture
vnd.android.cursor.dir/
Android.intent.action.View
Immagine
Android.intent.act.get_content
vnd.android.cursor.dir/
Android.intent.action.pick
video
Android.intent.act.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.act.get_content
telefono
vnd.android.cursor.item/
indirizzo postale
testo/semplice
E-mail
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
mm
mmsto
Audio/*
Applicazione/Ogg
Musica
Android.intent.action.View
file
Applicazione/X-OGG
applicazione/iTunes
audio/mp3
audio/x-mp3
Android.intent.action.View
http
audio/mpeg
audio/mp4
audio/mp4a-latm
vnd.android.cursor.dir/
Artistalbum
vnd.android.cursor.dir/
album
vnd.android.cursor.dir/
Android.intent.action.pick
ora playing
vnd.android.cursor.dir/
traccia
nd.android.cursor.dir/
elenco di riproduzione
vnd.android.cursor.dir/
video
media/*
Audio/*
Android.intent.act.get_content
Applicazione/Ogg
Applicazione/X-OGG
video/*

contenuto
Pacchetto
Android.intent.action.View
file
Installatore
pacchetto
file
Android.intent.act.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.act.set_wallpaper
Ricerca
Android.intent.action.search
domanda
Android.intent.action.search_long_press
Voce
Android.intent.action.voice_command
Gestione dei contatti
Azione intenzionale
Descrizione
Avvia un'attività che consente all'utente di scegliere
Allegato_image
Un contatto per allegare un'immagine a.
Usato
Extra_create_description
con show_or_create_contact to
Specificare una descrizione esatta da essere

mostrato quando spinge l'utente a proposito
Creazione di un nuovo contatto.
Usato
con show_or_create_contact to
Extra_force_create
forzare la creazione di un nuovo contatto se no
contatto corrispondente trovato.
Questo è l'intento che viene licenziato quando a
Search_suggestion_Clicked
Il suggerimento di ricerca viene fatto clic su.
Questo è l'intento che viene licenziato quando a
Search_suggestion_create_contact_Clicked Search Suggerimento per la creazione di a
Il contatto viene fatto clic su.
Questo è l'intento che viene licenziato quando a
Search_suggestion_dial_number_clicked
Suggerimento di ricerca per la composizione di un numero
viene fatto clic su.
Prende come inserimento un URI di dati con un mailto:
Show_or_create_contact
o Tel: schema.

APPENDICE B: intenzione di trasmissione richiesta Nota: questo elenco è provvisorio e sarà
Aggiornato in futuro.
Azione intenzionale
Descrizione
Azione trasmessa: questa viene trasmessa una volta, dopo il
Action_boot_completed
Il sistema ha finito l'avvio.
Azione di trasmissione: questo viene trasmesso una volta, quando a
Action_Call_Button
la chiamata viene ricevuta.
Azione di trasmissione: il "pulsante della fotocamera" era
Action_camera_button
premuto.
Azione di trasmissione: la corrente
Action_configuration_changed
La configurazione del dispositivo (orientamento, locale, ecc.) Ha
cambiato.
Action_date_changed
Azione di trasmissione: la data è cambiata.
Azione di trasmissione: indica una bassa condizione di memoria
Action_device_storage_low
sul dispositivo
Azione di trasmissione: indica una bassa condizione di memoria
Action_device_storage_ok
sul dispositivo non esiste più
Azione di trasmissione: cuffia cablata collegata o
Action_headset_plug
scollegato.
Azione di trasmissione: un metodo di input è stato
Action_input_method_changed
cambiato.
Azione di trasmissione: i media esterni sono stati rimossi
Action_media_bad_removal
Dallo slot della scheda SD, ma il punto di montaggio non lo era
non montato.
Azione di trasmissione: il "pulsante multimediale" era
Action_media_Button
premuto.
Azione di trasmissione: i media esterni sono presenti e
essendo il disco controllato il percorso verso il punto di montaggio per
Action_media_checking
i media di controllo sono contenuti
Intent.mdata Field.
Azione di trasmissione: l'utente ha espresso il desiderio di
Action_media_Eject
Rimuovere il supporto di archiviazione esterno.
Azione di trasmissione: i media esterni sono presenti e
Action_Media_Mounted
montato nel suo punto di montaggio.
Azione di trasmissione: i media esterni sono presenti, ma lo è
Usando un FS incompatibile (o è vuoto) il percorso di
Action_media_nofs
Il punto di montaggio per i media di controllo è
contenuto nel campo intento.mdata.
Azione di trasmissione: i media esterni sono stati
Action_Media_removed
RIMOSSO.
Azione di trasmissione: lo scanner multimediale è finito
Action_media_Scanner_Finished
scansionare una directory.
Azione di trasmissione: richiedere lo scanner multimediale a
Action_media_scanner_scan_file
Scansiona un file e aggiungilo al database multimediale.

Azione di trasmissione: lo scanner multimediale è iniziato
Action_media_scanner_started
scansionare una directory.
Azione di trasmissione: i media esterni sono non montati
Action_Media_Shared
Perché viene condiviso tramite l'archiviazione di massa USB.
Azione di trasmissione: i media esterni sono presenti ma
Action_Media_unmountable
non può essere montato.
Azione di trasmissione: i media esterni sono presenti, ma
Action_media_unmounted
non montato nel suo punto di montaggio.
Azione di trasmissione: una chiamata in uscita sta per essere
Action_New_OutGade_Call
posizionato.
Azione di trasmissione: un nuovo pacchetto di applicazioni ha
Action_package_added
stato installato sul dispositivo.
Azione di trasmissione: un pacchetto applicativo esistente
Action_package_changed
è stato cambiato (ad esempio un componente è stato
abilitato o disabilitato.
Azione di trasmissione: l'utente ha cancellato i dati di
un pacco. Questo dovrebbe essere preceduto
di action_package_restarted, dopo di che
Action_package_data_cleared
Tutti i suoi dati persistenti vengono cancellati e questo
trasmissione inviata. Si noti che il pacchetto cancellato
non riceve questa trasmissione. I dati contengono
Il nome del pacchetto.
Azione di trasmissione: un pacchetto applicativo esistente
è stato rimosso dal dispositivo. I dati
Action_package_removed
contiene il nome del pacchetto. Il pacchetto
che viene installato non riceve questo intento.
Azione di trasmissione: una nuova versione di un'applicazione
Action_package_replaced
Il pacchetto è stato installato, sostituendo un esistente
versione precedentemente installata.
Azione di trasmissione: l'utente ha riavviato a
pacchetto e tutti i suoi processi sono stati uccisi.
Tutto lo stato di runtime associato ad esso (processi,
Action_package_restarted
Gli allarmi, le notifiche, ecc.) Dovrebbero essere rimossi. Nota
che il pacchetto riavviato non lo riceve
trasmissione. I dati contengono il nome del
pacchetto.
Azione di trasmissione: alcuni fornitori di contenuti hanno
parti del loro spazio dei nomi in cui pubblicano nuovi
Action_provider_changed
eventi o elementi che l'utente può essere particolarmente
interessato a.
Action_screen_off
Azione di trasmissione: inviato dopo che lo schermo si spegne.
Action_screen_on
Azione di trasmissione: inviato dopo lo schermo.
Azione di trasmissione: un ID utente è stato rimosso
Action_uid_removed
dal sistema.
Azione di trasmissione: il dispositivo è entrato in USB
Action_ums_connected
Modalità di archiviazione di massa.

Azione di trasmissione: il dispositivo è uscito da USB
Action_ums_disconnected
Modalità di archiviazione di massa.
Azione di trasmissione: inviato quando l'utente è presente
Action_user_present
Dopo che il dispositivo si sveglia (ad esempio quando la guardia del tastie
andato).
Azione di trasmissione: l'attuale sfondo del sistema
Action_wallpaper_changed
è cambiato.
Action_time_changed
Azione di trasmissione: il tempo è stato impostato.
Action_time_tick
Azione di trasmissione: il tempo corrente è cambiato.
Action_timezone_changed
Azione di trasmissione: il fuso orario è cambiato.
Azione di trasmissione: lo stato di ricarica o addebito
Action_battery_Changed
Il livello della batteria è cambiato.
Azione di trasmissione: indica una bassa condizione della batteria
Action_battery_low
sul dispositivo. Questa trasmissione corrisponde a
Finestra di dialogo di sistema "Avviso a bassa batteria".
Azione di trasmissione: indica che la batteria ora va bene
Dopo essere stato basso. Questo verrà inviato
Action_battery_okay
dopo action_battery_low una volta la batteria
è tornato a uno stato ok.
Stato di rete
Azione intenzionale
Descrizione
Azione intenzionale trasmessa indicando che il
Network_state_changed_action
Lo stato di connettività Wi-Fi è cambiato.
Azione intenzionale trasmessa indicando che il
Rssi_changed_action
RSSI (resistenza al segnale) è cambiato.
Azione intenzionale trasmessa indicando che a
Supplicant_state_changed_action
La connessione al supplicante è stata
stabilito o perso.
Azione intenzionale trasmessa che indica che Wi-Fi
Wifi_state_changed_action
è stato abilitato, disabilitato, abilitante,
disabilitazione o sconosciuto.
Gli ID di rete delle reti configurate
Network_ids_changed_action
avrebbe potuto cambiare.
Azione intenzionale trasmessa indicando che il
Action_background_data_setting_changed impostazione per l'utilizzo dei dati in background ha
valori modificati.
Intenzione di trasmissione che indica che un cambiamento in
Connettività_action
Si è verificata connettività di rete.
Azione di trasmissione: l'utente ha cambiato il
Action_airplane_mode_changed
Telefono in o fuori dalla modalità aereo.

Appendice C: Considerazioni future Questa appendice chiarisce alcune parti di questo Android
1.6 Definizione di compatibilità e in alcuni casi discute le modifiche previste o pianificate destinate a un
versione futura della piattaforma Android. Questa appendice è solo a scopo informativo e di pianificazione
non fa parte della definizione di compatibilità per Android 1.6.
1. Dispositivi non telefoni
Android 1.6 è destinato esclusivamente ai telefoni; La funzionalità di telefonia non è facoltativa. Versioni future
della piattaforma Android dovrebbe rendere opzionale la telefonia (e quindi consentire Android non per telefono
Dispositivi), ma solo i telefoni sono compatibili con Android 1.6.
2. Compatibilità Bluetooth
La versione Android 1.6 di Android non supporta le API Bluetooth, quindi dal punto di vista della compatibilità
Bluetooth non impone alcuna considerazione per questa versione della piattaforma. Tuttavia, una versione futura
di Android introdurrà API Bluetooth. A quel punto, il supporto di Bluetooth diventerà obbligatorio per
Compatibilità.
Di conseguenza, raccomandiamo vivamente che i dispositivi Android 1.6 includano Bluetooth, in modo che lo siano
Compatibile con le versioni future di Android che richiedono Bluetooth.
3. Componenti hardware richiesti
Tutti i componenti hardware nella Sezione 8 (inclusi WiFi, magnetometro/bussola, accelerometro, ecc.)
richiesto e non può essere omesso. Si prevede che le versioni future di Android ne facciano alcune (ma non tutte)
Questi componenti opzionali, in tandem con strumenti corrispondenti per gli sviluppatori di terze parti per gestirli
i cambiamenti.
4. Applicazioni di esempio
Il documento di definizione della compatibilità per una versione futura di Android includerà un più esteso e
Elenco rappresentativo di applicazioni rispetto a quelle elencate nella sezione 4, sopra. Per Android 1.6, il
Le applicazioni elencate nella sezione 4 devono essere testate.
5. Touch Screen
Le versioni future della definizione di compatibilità possono o meno consentire ai dispositivi di omettere i touchscreen.
Tuttavia, attualmente gran parte dell'implementazione del framework Android presuppone l'esistenza di a
touch screen; omettere un touchscreen romperebbe sostanzialmente tutte le attuali applicazioni Android di terze parti,
Quindi in Android 1.6 è necessario un touchscreen per la compatibilità.

6. Performance
Le versioni future di CTS misureranno anche l'utilizzo e le prestazioni della CPU di quanto segue
Componenti di un'implementazione:
• Grafica 2D
• Grafica 3D
• Riproduzione video
• Riproduzione audio
• Riproduzione Bluetooth A2DP

Definizione di compatibilità con Android 1.6

Schema del documento