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 4.1
Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Definizione della compatibilità di Android 4.1
Revisione 3
Ultimo aggiornamento: 24 giugno 2013
Copyright © 2012, Google Inc. Tutti i diritti riservati.
[email protected]
Indice
1. Introduzione
2. Risorse
3. Software
3.1. Compatibilità API gestita
3.2. Compatibilità API morbida
3.2.1. Autorizzazioni
3.2.2. Parametri di build
3.2.3. Compatibilità con gli intent
3.2.3.1. Intent dell'applicazione di base 3.2.3.2.
Sostituzione intent
3.2.3.3. Spazi dei nomi intent
3.2.3.4. Intent di trasmissione
3.3. Compatibilità con le API native
Interfacce binarie dell'applicazione
3.4. Compatibilità con il web
3.4.1. Compatibilità WebView
3.4.2. Compatibilità del browser
3.5. API Behavioral Compatibility
3.6. Spazi dei nomi dell'API
3.7. Compatibilità delle macchine virtuali
3.8. Compatibilità dell'interfaccia utente
3.8.1. Widget
3.8.2. Notifiche
3.8.3. Ricerca
3.8.4. Toast
3.8.5. Temi
3.8.6. Documenti Wal live
3.8.7. Visualizzazione delleapp recenti
3.8.8. Impostazioni di gestione dell'input
3.8.9. Controllo da dispositivo a distanza della schermata di blocco
3.9 Amministrazione del dispositivo
3.10 Accessibilità
3.11 Trascrizione di testo
4. Compatibilità del packaging delle applicazioni
5. Compatibilità multimedia
5.1. Codec multimediali
5.2. Codifica video
5.3. Registrazione audio
5.4. Latenza audio
5.5. Protocolli di rete
6. Compatibilità con gli strumenti per sviluppatori
7. Compatibilità hardware
7.1. Display e grafica
7.1.1. Schermata Configuratisu
7.1.2. Display Metrics
7.1.3. Orientamento schermo
7.1.4.Accelerazione delle grafica 2D e 3D
7.1.5. Modalità di compatibilità delle app legacy
7.1.6. Tipi di schermata
7.1.7. Tecnologia schermo
7.2. InDispositivi di input
7.2.1. Tastiera
7.2.2. Navigazione senza tocco
7.2.3. Tasti di navigazione
7.2.4. Input touchscreen
7.2.5. Input tocco simulato
7.2.6. Microfono
7.3. Sensori
7.3.1. Accelerometro

7.3.1. Accelerometro
7.3.2. Magnetometro
7.3.3. GPS
7.3.4. Giroscopio
7.3.5. Barometro
7.3.6. Termometro
7.3.7. Fotometro
7.3.8. Sensore di prossimità
7.4. Connettività dei dati
7.4.1. Telefonia
7.4.2. IEEE 802.11 (Wi-Fi)
7.4.2.1. Wi-Fi Direct
7.4.3. Bluetooth
7.4.4. Near-Field Communications
7.4.5. Capacità di rete minima
7.5. Camera
7.5.1. Fotocamera posteriore
7.5.2. Fotocamera anteriore
7.5.3. Comportamento dell'API Camera
7.5.4. Orientamento della fotocamera
7.6. Memoria e spazio di archiviazione
7.6.1. Memoria e spazio di archiviazione
7.6.2. Spazio di archiviazione condiviso dell'applicazione
7.7. USB
8. Compatibilità prestazioni
9. Compatibilità del modello di sicurezza
9.1. Autorizzazioni
9.2. UID e isolamento del procedimento
9.3. Autorizzazioni del filesystem
9.4. Ambienti di esecuzione alternativi
10. Test di compatibilità del software
10.1. Compatibility Test Suite
10.2. CTS Verifier
10.3. Applicazioni di riferimento
11. Software aggiornabile
12. Contattaci
Appendice A - Procedura di test Bluetooth

1. Introduzione
Questo documento elenca i requisiti che devono essere soddisfatti per consentire ai dispositivi di
essere compatibili con Android 4.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, 1].
Come utilizzato in questo documento, un "implementatore di dispositivi" o "implementatore" è una persona o
un'organizzazione che sviluppa una soluzione hardware/software che esegue Android 4.1. Un'"implementazione
del dispositivo" o "implementazione" è la soluzione hardware/software così sviluppata.
Per essere considerate compatibili con Android 4.1, le implementazioni del dispositivo DEVONO soddisfare
i requisiti presentati in questa definizione di compatibilità, inclusi eventuali documenti
incorporati tramite riferimento.
Se questa definizione o i test software descritti nella Sezione 10 non sono espliciti,
ambigui o incompleti, è responsabilità del costruttore del dispositivo assicurarsi della
compatibilità con le implementazioni esistenti.
Per questo motivo, l'Android Open Source Project [Risorse, 3] è sia il riferimento
che l'implementazione preferito di Android. Gliimplementatori di dispositivi sono fortemente
incoraggiati a basare le loro implementazioni il più possibile sul codice sorgente "upstream" disponibile dall'Android Open Source Project.
Anche se alcuni
componenti possono essere ipoteticamente sostituirsi con implementazioni alternative, questa
pratica è fortemente sconsigliata, poiché superare i test software diventerà
molto più difficile. È responsabilità dell'implementatore garantire la piena
compatibilità comportamentale con l'implementazione standard di Android, inclusi e oltre i test di
compatibilità del CTS. Infine, tieni presente che alcune sostituzioni e
modifiche di componenti sono esplicitamente vietate da questo documento.
2. Risorse
1.  Livelli di Requisito RFC2119 di IETF: http://www.ietf.org/rfc/rfc2119.txt
2. Panoramica del Programma di compatibilità Android:
https://source.android.com/compatibility/index.html
3.  Android Open Source Project: https://source.android.com/
4.  Definizioni e documentazione dell'API:
http://developer.android.com/reference/packages.html
5.  Documentazione di riferimento per le autorizzazioni Android:
http://developer.android.com/reference/android/Manifest.permission.html
6.  Documentazione di android.os.Build:
http://developer.android.com/reference/android/os/Build.html
7.  Stringhe di versione consentite per Android 4.1:
https://source.android.com/compatibility/4.1/versions.html
8.  Renderscript:
http://developer.android.com/guide/topics/graphics/renderscript.html
9.  Accelerazione hardware:
http://developer.android.com/guide/topics/graphics/hardware-accel.html
10.  Classe android.webkit.WebView:
http://developer.android.com/reference/android/webkit/WebView.html
11.  HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12.  Funzionalità offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13.  Tag video HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14.  API geolocalizzazione HTML5/W3C: http://www.w3.org/TR/geolocation-API/
15.  Database web HTML5/W3C API: http://www.w3.org/TR/webdatabase/
16.  API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
17.  Dalvik Virtual Machine specification: available in the Android source code, at
dalvik/docs
18.  AppWidgets:
http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19.  Notifiche:
http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20.  Risorse per le applicazioni: http://code.google.com/android/reference/available-
resources.html
21.  Guida stile per le icone della barra di stato:
http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22.  Search Manager:
http://developer.android.com/reference/android/app/SearchManager.html
23.  Toast: http://developer.android.com/reference/android/widget/Toast.html
24.  Temi: http://developer.android.com/guide/topics/ui/themes.html

25.  Classe R.style: http://developer.android.com/reference/android/R.style.html
26.  Live Wal papers: http://developer.android.com/resources/articles/live-
wal papers.html
27.  Amministrazione dispositivo Android:
http://developer.android.com/guide/topics/admin/device-admin.html
28.  Classe android.app.admin.DevicePolicyManager:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29.  API Accessibility Service Android:
http://developer.android.com/reference/android/accessibilityservice/package-
summary.html
30. API Android per l'accessibilità:
http://developer.android.com/reference/android/view/accessibility/package-
summary.html
31.  Progetto Eyes Free: http://code.google.com/p/eyes-free
32. API Text-to-Speech:
http://developer.android.com/reference/android/speech/tts/package-
summary.html
33.  Documentazione degli strumenti di riferimento (per adb, aapt, ddms):
http://developer.android.com/guide/developing/tools/index.html
34.  Descrizione del file APK Android:
http://developer.android.com/guide/topics/fundamentals.html
35.  File manifest: http://developer.android.com/guide/topics/manifest/manifest-
intro.html
36.  Strumento di test Monkey:
https://developer.android.com/studio/test/other-testing-tools/monkey
37.  Lista delle funzionalità dell'hardware e della classe android.content.pm.PackageManager

  Supporto di più schermi:
http://developer.android.com/guide/practices/screens_support.html
39.  android.util.DisplayMetrics:
http://developer.android.com/reference/android/util/DisplayMetrics.html
40.  android.content.res.Configuration:
http://developer.android.com/reference/android/content/res/Configuration.html
41.  android.hardware.SensorEvent:
http://developer.android.com/reference/android/hardware/SensorEvent.html
42.  API Bluetooth:
http://developer.android.com/reference/android/bluetooth/package-summary.html
43.  Protocollo push NDEF: https://source.android.com/compatibility/ndef-push-
protocol.pdf
44.  MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45.  MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46.  MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47.  MIFARE MF0ICU2:
http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48.  MIFARE AN130511:
http://www.nxp.com/documents/application_note/AN130511.pdf
49.  MIFARE AN130411:
http://www.nxp.com/documents/application_note/AN130411.pdf
50.  API orientamento fotocamera:
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51.  android.hardware.Camera:
http://developer.android.com/reference/android/hardware/Camera.html
52.  Android Open Accessories:
http://developer.android.com/guide/topics/usb/accessory.html
53.  API host USB: http://developer.android.com/guide/topics/usb/host.html
54.  Documentazione di riferimento per la sicurezza e le autorizzazioni di Android:
http://developer.android.com/guide/topics/security/security.html
55.  App per Android: http://code.google.com/p/apps-for-android
56.  Classe android.app.DownloadManager:
http://developer.android.com/reference/android/app/DownloadManager.html
57.  Trasferimento file Android: http://www.android.com/filetransfer
58.  Formati multimediali Android: http://developer.android.com/guide/appendix/media-
formats.html
59.  HTTP Live Streaming Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-
live-streaming-03
60.  Trasferimento della connessione NFC: http://www.nfc-
forum.org/specs/spec_list/#conn_handover
61.  Accoppiamento Bluetooth sicurezza semplice con NFC: http://www.nfc-
forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62.  API Multicast Wi-Fi:
http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

63.  Assistente azioni:
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64.  Specifiche di ricarica USB:
http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65.  Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66.  Audio USB Android:
http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67.  Impostazioni di condivisione NFC di Android:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68.  Wifi Direct (Wifi P2P):
http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69.  Client di controllo da dispositivo media:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70.  API Motion Event:
http://developer.android.com/reference/android/view/MotionEvent.html
71.  Configurazione input touch: https://source.android.com/tech/input/touch-
devices.html
Molte di queste risorse sono derivate direttamente o indirettamente dall'SDK Android 4.1,
e saranno funzionali e identiche alle informazioni nella documentazione dell'SDK. In qualsiasi
caso in cui questa definizione di compatibilità o la suite di test di compatibilità non è d'accordo con
la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Eventuali
dettagli tecnici forniti nei documenti di riferimento inclusi sopra sono considerati da
inclusione come parte di questa definizione di compatibilità.
3. Software
3.1. Compatibilità con le API gestite
L'ambiente di esecuzione gestito (basato su Dalvik) è il principale strumento per le app
Android. L'interfaccia di programmazione di un'applicazione (API) Android è l'insieme di interfacce della piattaforma Android esposte alle applicazioni in esecuzione nell'ambiente della VM gestita.

Le implementazioni del dispositivo DEVONO fornire implementazioni complete,
inclusi tutti i comportamenti documentati, di qualsiasi API documentata esposta dall'SDK Android
4.1 [Risorse, 4].
Le implementazioni del dispositivo NON DEVONO omettere API gestite, modificare interfacce o
firme dell'API, deviare dal comportamento documentato o includere no-op, tranne nei casi
espressamente previsti da questa definizione di compatibilità.
Questa definizione di compatibilità consente di omettere dall'implementazione del dispositivo alcune API per alcuni tipi di hardware per i quali Android
le include. In questi casi, le API DEVONO
essere ancora presenti e comportarsi in modo ragionevole. Consulta la sezione 7 per i requisiti
specifici per questo scenario.
3.2. Compatibilità con API soft
Oltre alle API gestite della sezione 3.1, Android include anche una significativa
API "soft" solo in fase di esecuzione, sotto forma di elementi come Intent, autorizzazioni e
aspetti simili delle applicazioni Android che non possono essere applicati al momento della compilazione dell'applicazione
.
3.2.1. Autorizzazioni
Gli implementatori del dispositivo DEVONO supportare e applicare tutte le costanti di autorizzazione come
documentato nella pagina di riferimento Autorizzazioni [Risorse, 5]. Tieni presente che la sezione 10
elenca requisiti aggiuntivi relativi al modello di sicurezza di Android.
3.2.2. Parametri di compilazione
Le API Android includono una serie di costanti nella classe android.os.Build
[Resources, 6] che hanno lo scopo di descrivere il dispositivo corrente. Per fornire valori coerenti
e significativi nelle implementazioni dei dispositivi, la tabella di seguito include ulteriori
limitazioni ai formati di questi valori a cui le implementazioni dei dispositivi DEVONO
conformarsi.
Parametro
Commenti
La versione del sistema Android in esecuzione, in formato leggibile. Questo campo DEVE avere uno
android.os.Build.VERSION.RELEASE
dei valori di stringa definiti in [Resources, 7].
La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti.
android.os.Build.VERSION.SDK
Per Android 4.1, questo campo DEVE avere il valore intero 16.

La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti.
android.os.Build.VERSION.SDK_INT
Per Android 4.1, questo campo DEVE avere il valore intero 16.
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 messe a disposizione degli utenti finali
android.os.Build.VERSION.INCREMENTAL
. Un uso tipico di questo campo è indicare quale numero di build o identificatore di modifica del controllo delle origini è
stato utilizzato per generare la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE
essere null o la stringa vuota ("").
Un valore scelto dall'implementatore del dispositivo che identifica l'hardware interno specifico utilizzato dal dispositivo, in
formato leggibile dall'uomo. Un possibile utilizzo di questo campo è indicare la revisione specifica della scheda che alimenta
android.os.Build.BOARD
il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCI a 7 bit e corrispondere all'espressione regolare
"^[a-zA-Z0-9.,_-]+$".
Un valore scelto dall'implementatore del dispositivo che identifica il nome dell'azienda, dell'organizzazione, della persona e così via
che ha prodotto il dispositivo, in formato leggibile dall'uomo. Un possibile utilizzo di questo campo è indicare l'OEM
android.os.Build.BRAND
e/o l'operatore che ha venduto il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCI a 7 bit e corrispondere all'
espressione regolare "^[a-zA-Z0-9.,_-]+$".
Il nome dell'insieme di istruzioni (tipo CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3: API nativa
android.os.Build.CPU_ABI
Incompatibilità.
Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3: Compatibilità
android.os.Build.CPU_ABI2
API nativa.
Un valore scelto dall'implementatore del dispositivo che identifica la configurazione o la revisione specifica della scocca
android.os.Build.DEVICE
(a volte chiamato anche "design industriale") del dispositivo. Il valore di questo campo DEVE essere codificabile come
ASCI a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9.,_-]+$".
Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile da una persona. DEVE seguire questo
modello:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Ad esempio:
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys
L'impronta NON DEVE includere spazi. Se altri campi inclusi nel modello sopra contengono
caratteri spazio vuoto, devono essere sostituiti nella impronta della build con un altro carattere, ad esempio il carattere
trattino basso ("_"). Il valore di questo campo DEVE essere codificabile come ASCI a 7 bit.
Il nome dell'hardware (dalla riga di comando del kernel o da /proc). DEVE essere ragionevolmente leggibile da una persona
android.os.Build.HARDWARE
. Il valore di questo campo DEVE essere codificabile come ASCI a 7 bit e corrispondere all'espressione regolare "^[a-
zA-Z0-9.,_-]+$".
Una stringa che identifica in modo univoco l'host su cui è stata generata la build, in formato leggibile dall'uomo. Non sono previsti requisiti
android.os.Build.HOST
per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere null o la stringa vuota ("").
Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in formato leggibile dall'uomo. Questo

Il valore di questo campo DEVE essere codificabile
come ASCI a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9.,_-]+$".
Il nome commerciale del produttore dell'apparecchiatura originale (OEM) del prodotto. Non sono previsti requisiti per
android.os.Build.MANUFACTURER
il formato specifico di questo campo, tranne per il fatto che NON DEVE essere null o la stringa vuota ("").
Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo come noto all'utente finale. Questo
android.os.Build.MODEL
DEVE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti
requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere null o la stringa vuota ("").
Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice del prodotto
android.os.Build.PRODUCT
(SKU). DEVE essere leggibile dall'uomo, ma non è necessariamente destinato alla visualizzazione da parte degli utenti finali. Il valore di questo
campo DEVE essere codificabile come ASCI a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9.,_-]+$".
Un numero di serie hardware, se disponibile. Il valore di questo campo DEVE essere codificabile come ASCI a 7 bit e corrispondere
android.os.Build.SERIAL
all'espressione regolare "^([a-zA-Z0-9]{0,20})$".
Un elenco di tag separati da virgola scelti dall'implementatore del dispositivo che distinguono ulteriormente la build. Ad
esempio,
"unsigned,debug" per
android.os.Build.TAGS. Il valore di questo campo DEVE essere codificabile come ASCI a 7 bit e corrispondere all'espressione
regolare "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TIME
Un valore che rappresenta il timestamp della data e dell'ora 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 corrispondenti alle tre tipiche configurazioni di runtime Android: "user",
android.os.Build.TYPE
"userdebug" o "eng". Il valore di questo campo DEVE essere codificabile come ASCI a 7 bit e corrispondere all'espressione
regolare "^[a-zA-Z0-9.,_-]+$".
Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la build. Non sono previsti requisiti per
android.os.Build.USER
il formato specifico di questo campo, tranne per il fatto che NON DEVE essere null o la stringa vuota ("").
3.2.3. Compatibilità con Intent
Le implementazioni del dispositivo DEVONO rispettare il sistema Intent a coppiaggio rilassato di Android, come

descritto nelle sezioni di seguito. Per "rispettato", si intende che l'implementatore del dispositivo
DEVE fornire un'attività o un servizio Android che specifichi un filtro per intent corrispondente e
si leghi e implementi il comportamento corretto per ogni pattern di intent specificato.
3.2.3.1. Intent delle app di base
Il progetto upstream Android definisce una serie di app di base, ad esempio contatti,
calendario, galleria di foto, lettore di musica e così via. Gli implementatori di dispositivi POSSONO sostituire
queste applicazioni con versioni alternative.
Tuttavia, qualsiasi di queste versioni alternative DEVE rispettare gli stessi pattern di intent forniti
dal progetto upstream. Ad esempio, se un dispositivo contiene un player musicale alternativo,
deve comunque rispettare il pattern Intent rilasciato da applicazioni di terze parti per scegliere un brano.
Le seguenti applicazioni sono considerate applicazioni di sistema Android di base:
Orologio
Browser
Calendario
Contatti
Galleria
Ricerca globale
Avvio
Musica
Impostazioni
Le applicazioni di sistema Android di base includono vari componenti di attività o servizio
che sono considerati "pubblici". In altre parole, l'attributo "android:exported" potrebbe non essere presente o
avere il valore "true".
Per ogni Attività o Servizio definito in una delle app di sistema Android di base che non è
contrassegnato come non pubblico tramite un attributo android:exported con il valore "false", le implementazioni del dispositivo DEVONO includere un componente dello stesso tipo che implementi gli stesse pattern di filtro per intent dell'app di sistema Android di base.
In altre parole, un'implementazione del dispositivo PUÒ sostituire le app di sistema Android di base;
tuttavia, se lo fa, l'implementazione del dispositivo DEVE supportare tutti i pattern per intent definiti
da ogni app di sistema Android di base che viene sostituito.

3.2.3.2. Sostituzioni di intent
Poiché Android è una piattaforma estendibile, le implementazioni del dispositivo DEVONO consentire a ogni pattern di intent
a cui si fa riferimento nella Sezione 3.2.3.2 di essere sostituito da applicazioni di terze parti. L'
implementazione open source di Android upstream lo consente per impostazione predefinita; gli
implementatori del dispositivo NON DEVONO associare privilegi speciali all'uso di
questi pattern Intent da parte delle applicazioni di sistema o impedire alle applicazioni di terze parti di associarsi e assumere il
controllo di questi pattern. Questo divieto include specificamente, a titolo esemplificativo, la
disattivazione dell'interfaccia utente "Chooser" che consente all'utente di scegliere tra più
applicazioni che gestiscono lo stesso pattern Intent.
Tuttavia, le implementazioni del dispositivo POSSONO fornire attività predefinite per pattern URI
specifici (ad es. http://play.google.com) se l'attività predefinita fornisce un filtro più specifico
per l'URI dei dati. Ad esempio, un filtro intent che specifica l'URI di dati
"http://www.android.com" è più specifico del filtro del browser per "http://". Le implementazioni del dispositivo DEVONO fornire un'interfaccia utente per consentire agli utenti di modificare l'attività predefinita
per gli intent.

3.2.3.3. Spazi nomi intent
Le implementazioni del dispositivo NON DEVONO includere componenti Android che rispettano qualsiasi
nuovo pattern intent o intent di broadcast che utilizza una stringa
ACTION, CATEGORY o altra chiave nello spazio nomi android.* o com.android.*. Gli implementatori di dispositivi NON DEVONO
includere componenti Android che rispettano qualsiasi nuovo pattern Intent o Intent di broadcast
utilizzando una stringa chiave ACTION, CATEGORY o altra in uno spazio del pacchetto appartenente a
un'altra organizzazione. Gli implementatori del dispositivo NON DEVONO modificare o estendere nessuno dei pattern
Intent utilizzati dalle app di base elencate nella sezione 3.2.3.1. Le implementazioni del dispositivo POSSONO
includere pattern Intent che utilizzano spazi nomi chiaramente e ovviamente associati alla propria
organizzazione.
Questo divieto è analogo a quello specificato per le classi di lingua Java nella Sezione
3.6.
3.2.3.4. Trasmissione di intent
Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent per avvisarle

di modifiche nell'ambiente hardware o software. I dispositivi compatibili con Android
DEVONO trasmettere gli intent di trasmissione pubblica in risposta a eventi
di sistema appropriati. Gli intent di pubblicazione sono descritti nella documentazione dell'SDK.
3.3. Compatibilità API native
3.3.1 Interfacce binarie dell'applicazione
Il codice gestito in esecuzione 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.
Poiché il codice nativo è molto dipendente dalla tecnologia del processore di base, Android
definisce una serie di interfacce binarie dell'applicazione (ABI) in Android NDK, nel file
docs/CPU-ARCH-ABIS.html. Se un'implementazione del dispositivo è compatibile con uno o più

Se un'implementazione del dispositivo include il supporto per un'ABI Android, deve:
DEVE includere il supporto per il codice in esecuzione nell'ambiente gestito per eseguire il codice
nativo, utilizzando la semantica standard dell'interfaccia Java Native (JNI).
DEVE essere compatibile con il codice sorgente (ovvero compatibile con l'intestazione) e con il codice eseguibile (per
l'ABI) con ogni libreria obbligatoria nell'elenco di seguito
DEVE segnalare con precisione l'interfaccia Application Binary (ABI) nativa supportata
dal dispositivo, tramite l'API android.os.Build.CPU_ABI
DEVE segnalare solo le ABI documentate nell'ultima versione del NDK Android, nel file docs/CPU-ARCH-ABIS.txt
DEVE essere compilato utilizzando i file di codice sorgente e di intestazione disponibili nel
progetto open source Android upstream
Le seguenti API di codice nativo DEVONO essere disponibili per le app che includono codice nativo:
libc (libreria C)
libm (libreria matematiche)
Supporto minim per C++
Interfaccia JNI
liblog (logging Android)
libz (compressione Zlib)
libdl (linker dinamico)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (gestione delle superfici OpenGL native)
libjnigraphics.so
libOpenSLES.so (supporto audio OpenSL ES 1.0.1)
libOpenMAXAL.so (supporto OpenMAX AL 1.0.1)
libandroid.so (supporto attività Android native)
Supporto per OpenGL, come descritto di seguito
Tieni presente che le release future del NDK Android potrebbero introdurre il supporto per altre
ABI.
Se un'implementazione del dispositivo non è compatibile con un ABI predefinito esistente,
NON DEVE segnalare il supporto per nessun ABI al momento .
La compatibilità del codice nativo è una sfida. Per questo motivo, è molto fortemente consigliato agli
implementatori di dispositivi di utilizzare le implementazioni upstream
delle librerie elencate sopra per contribuire a garantire la compatibilità.
3.4. Compatibilità con il web
3.4.1. Compatibilità con WebView
L'implementazione di Android Open Source utilizza il motore di rendering WebKit per
implementare android.webkit.WebView. Poiché non è possibile sviluppare una
suite di test completa per un sistema di rendering web, gli implementatori di dispositivi DEVONO utilizzare
la specifica build upstream di WebKit nell'implementazione di WebView. Nello specifico:
le implementazioni di android.webkit.WebView delle implementazioni del dispositivo DEVONO essere
basate sulla build WebKit 534.30 dell'albero Android Open Source upstream
per Android 4.1. Questa build include un insieme specifico di funzionalità e
correzioni di sicurezza per WebView. Gli implementatori del dispositivo POSSONO includere personalizzazioni all'implementazione di
WebKit; tuttavia, queste personalizzazioni NON DEVONO modificare il comportamento di WebView, incluso il comportamento di rendering.
La stringa user agent riferita da WebView DEVE avere questo formato:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)
Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.1
Mobile Safari/534.30
Il valore della stringa $(VERSION) DEVE essere uguale al valore per

Il valore della stringa $(VERSION) DEVE essere uguale al valore per
android.os.Build.VERSION.RELEASE
Il valore della stringa $(LOCALE) DEVE essere conforme alle convenzioni ISO per

� In ogni caso, le implementazioni del dispositivo DEVONO supportare ciascuna di
queste API associate a HTML5 in WebView:
cache dell'applicazione/operazione offline [Risorse, 12]
il tag <video> [Risorse, 13]
geolocalizzazione [Risource, 14]
Inoltre, le implementazioni del dispositivo DEVONO supportare l'API webstorage HTML5/W3C
[Risorse, 15] e DOVREBBERO supportare l'API IndexedDB HTML5/W3C [Risorse,
16]. Tieni presente che gli organismi degli standard per lo sviluppo web stanno eseguendo la transizione per favorire
IndexedDB rispetto a webstorage, IndexedDB dovrebbe diventare un componente obbligatorio
in una versione futura di Android.
Le API HTML5, come le API JavaScript, DEVONO essere disattivate per impostazione predefinita in un WebView,
a meno che lo sviluppatore non le attivi esplicitamente tramite le normali API Android.
3.4.2. Compatibilità del browser
Le implementazioni del dispositivo DEVONO includere un'applicazione browser autonoma per la navigazione web dell'utente
generico. Il browser autonomo PUÒ essere basato su una tecnologia di browser
diversa da WebKit. Tuttavia, anche se viene utilizzata un'applicazione di browser alternativa, il componente
android.webkit.WebView fornito alle applicazioni di terze parti DEVE essere
basato su WebKit, come descritto nella Sezione 3.4.1.
Le implementazioni POSSONO includere una stringa user agent personalizzata nell'applicazione Browser
autonoma.
L'applicazione browser autonoma (indipendentemente dal fatto che sia basata sull'applicazione browser WebKit
upstream o su un sostituzione di terze parti) DEVE includere il supporto per il maggior numero di funzionalità di
HTML5 [Risorse, 11] possibile.In ogni caso, le implementazioni del dispositivo DEVONO supportare
ognuna di queste API associate a HTML5:
cache dell'applicazione/operazione offline [Risorse, 12]
il tag <video> [Risorse, 13]
geolocalizzazione [Risorse, 14]
Inoltre, le implementazioni del dispositivo DEVONO supportare l'API webstorage HTML5/W3C
[Risorse, 15], e DOVREBBERO supportare l'API IndexedDB HTML5/W3C [Risorse,
16]. Tieni presente che, man mano che gli enti standard per lo sviluppo web eseguono la transizione in favore di
IndexedDB rispetto a webstorage, si prevede che IndexedDB diventi un componente obbligatorio
in una versione futura di Android.
3.5. Compatibilità comportamentale dell'API
I comportamenti di ciascuno dei tipi di API (gestite, soft, native e web) devono essere
coerenti con l'implementazione preferita del progetto open source Android upstream
[Risorse, 3]. Alcune aree di compatibilità specifiche sono:
I dispositivi NON DEVONO modificare il comportamento o la semantica di un Intent standard
I dispositivi NON DEVONO modificare il ciclo di vita o la semantica del ciclo di vita di un particolare tipo
di componente di sistema (ad esempio Service, Activity, ContentProvider e così via)
I dispositivi NON DEVONO modificare la semantica di un'autorizzazione standard
L'elenco sopra non è esaustivo. La suite di test di compatibilità (CTS) esegue test
su parti significative della piattaforma per verificare la compatibilità del comportamento, ma non su tutte le parti . È responsabilità dell'
implementatore garantire la compatibilità del comportamento con il
progetto open source Android. Per questo motivo, gli implementatori di dispositivi DEVONO utilizzare il codice
sorgente disponibile tramite il progetto open source Android ove possibile, anziché
implementare di nuovo parti significative del sistema.
3.6. Spazi dei nomi API
Android segue le convenzioni relative allo spazio dei nomi di pacchetti e classi definite dal linguaggio di programmazione Java

. Per garantire la compatibilità con le applicazioni di terze parti, gli
implementatori del dispositivo NON DEVONO apportare modifiche proibite (vedi di seguito) a questi
spazi nomi del pacchetto:
java.*
javax.*
sun.*
android.*
com.android.*
Le modifiche proibite includono:
Le implementazioni del dispositivo NON DEVONO modificare le API esposte pubblicamente sulla
piattaforma Android modificando le firme di metodi o classi o rimuovendo
classi o campi di classi.
Gli implementatori del dispositivo POSSONO modificare l'implementazione di base delle API, ma
queste modifiche NON DEVONO influire sul comportamento dichiarato e sulla firma in linguaggio Java
di qualsiasi API esposta pubblicamente.
Gli implementatori del dispositivo NON DEVONO aggiungere elementi esposti pubblicamente (ad esempio
classi o interfacce o campi o metodi a classi o interfacce esistenti) alle
API sopra.
Un "elemento esposto pubblicamente" è qualsiasi costruzione che non è decorata con l'indicatore "@hide"
come utilizzato nel codice sorgente Android upstream. In altre parole, gli implementatori
dei dispositivi NON DEVONO esporre nuove API o modificare quelle esistenti nei spazi nomi
indicati sopra. Gli implementatori di dispositivi POSSONO apportare modifiche solo per uso interno, ma queste
modifiche NON DEVONO essere pubblicizzate o altrimenti esposte agli sviluppatori.
Gli implementatori di dispositivi POSSONO aggiungere API personalizzate, ma queste API NON DEVONO trovarsi in un
spazio di nomi di proprietà di un'altra organizzazione o che rimandano a un'altra organizzazione. Ad esempio, gli
implementatori di dispositivi NON DEVONO aggiungere API al nome spazio com.google.* o a uno spazio simile; solo
Google può eseguire questa operazione. Analogamente, Google NON DEVE aggiungere API ai nomi spazio
di altre aziende. Inoltre, se un'implementazione del dispositivo include API personalizzate al di fuori
del nome spazio standard di Android, queste API DEVONO essere pacchettizzate in una libreria condivisa
di Android in modo che solo le app che le utilizzano esplicitamente (tramite il meccanismo <uses-library>
) siano interessate dall'aumento dell'utilizzo della memoria di queste API.
Se un implementatore del dispositivo propone di migliorare uno dei nomi spazio del pacchetto sopra
(ad esempio aggiungendo nuove funzionalità utili a un'API esistente o aggiungendo una nuova API), l'
implementatore DEVE visitare source.android.com e iniziare la procedura per contribuire con
modifiche e codice, in base alle informazioni su questo 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
Le implementazioni del dispositivo DEVONO supportare la specifica del bytecode eseguibile Dalvik (DEX)
e la semantica della macchina virtuale Dalvik [Risorse, 17].
Le implementazioni del dispositivo DEVONO configurare Dalvik per allocare memoria in conformità
con la piattaforma Android upstream e come specificato nellaseguente tavola. (consulta la
sezione 7.1.1 per le definizioni delle dimensioni e della densità dello schermo).
Tieni presente che i valori di memoria specificati di seguito sono considerati minimi e l'implementazione del dispositivo potrebbe allocare più memoria per applicazione.

Dimensioni schermo
Densità schermo
Memoria dell'applicazione
piccolo  / normale / grande
ldpi / mdpi
16 MB
piccolo  / normale / grande
tvdpi / hdpi
32 MB
piccolo  / normale / grande
xhdpi
64 MB
grande
mdpi
32 MB
grande
tvdpi / hdpi
64 MB
grande
xhdpi
128 MB
3.8. Compatibilità dell'interfaccia utente
3.8.1. Widget
Android definisce un tipo di componente e l'API e il ciclo di vita corrispondenti che consentono

alle applicazioni di esporre un "AppWidget" all'utente finale [Resources, 18]. La release di riferimento open source di Android
include un'applicazione Avvio app che include funzionalità dell'interfaccia utente che consentono all'utente di aggiungere, visualizzare e rimuovere AppWidget dalla schermata
Home.

Le implementazioni del dispositivo POSSONO sostituire un'alternativa al Lanciatore di riferimento (ad es.
schermata Home). I lanciatori alternativi DEVONO includere il supporto integrato per gli AppWidget,
e offrire funzionalità dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere
gli AppWidget direttamente all'interno del lanciatore. I lanciatori alternativi POSSONO omettere questi elementi dell'
interfaccia utente; tuttavia, se vengono omessi, l'implementazione del dispositivo DEVE
fornire un'applicazione separata accessibile dal lanciatore che consenta agli utenti di aggiungere,
configurare, visualizzare e rimuovere AppWidget.
Le implementazioni del dispositivo DEVONO essere in grado di eseguire il rendering di widget di 4 x 4 nelle
dimensioni della griglia standard. Per maggiori dettagli, consulta le linee guida per il design dei widget dell'app nella documentazione dell'SDK Android
[Risorse, 18].
3.8.2. Notifiche
Android include API che consentono agli sviluppatori di inviare notifiche agli utenti su eventi significativi
[Risorse, 19], utilizzando funzionalità hardware e software del dispositivo.
Alcune API consentono alle applicazioni di inviare notifiche o attirare l'attenzione utilizzando l'hardware, in particolare suoni, vibrazioni e luce.
Le implementazioni del dispositivo DEVONO
supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK
, e nella misura del possibile con l'hardware di implementazione del dispositivo.
Ad esempio, se un'implementazione del dispositivo include un vibratore, DEVE implementare correttamente
le API di vibrazione. Se l'implementazione di un dispositivo non include l'hardware, le
API corrispondenti DEVONO essere implementate come no-op. Tieni presente che questo comportamento è
descritto in maggiori dettagli nella Sezione 7.
Inoltre, l'implementazione DEVE riprodurre correttamente tutte le risorse (icone, file
audio e così via) previste nelle API [Risorse, 20] o nella guida stile delle icone della barra di stato/sistema
[Risorse, 21]. Gli implementatori di dispositivi POSSONO fornire un'
esperienza utente alternativa per le notifiche rispetto a quella fornita da Android Open Source di riferimento
implementato; tuttavia, questi sistemi di notifica alternativi DEVONO supportare le risorse di notifica esistenti, come sopra.

Android 4.1 include il supporto per le notifiche avanzate, ad esempio le visualizzazioni interattive per
le notifiche in corso. Le implementazioni del dispositivo DEVONO visualizzare e eseguire correttamente le notifiche
rich, come documentato nelle API Android.
3.8.3.Ricerca
Android include API [Risorse, 22] 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à è composta da un'unica interfaccia utente di sistema
che consente agli utenti di inserire query, di visualizzare suggerimenti man mano che digitano e di 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 del dispositivo 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 del dispositivo DEVONO implementare le API che consentono agli sviluppatori di riutilizzare questa interfaccia utente per fornire la ricerca all'interno delle proprie applicazioni.

Le implementazioni del dispositivo
DEVONO implementare le API che consentono alle applicazioni di terze parti di aggiungere suggerimenti alla
casella di ricerca quando viene eseguito in modalità di ricerca globale. Se non sono
installate applicazioni di terze parti che utilizzano questa funzionalità, il comportamento predefinito DOVREA essere la visualizzazione di risultati e suggerimenti del motore di ricerca web.

3.8.4. Toast
Le applicazioni possono utilizzare l'API "Toast" (definita in [Risorse, 23]) per mostrare all'utente finale brevi stringhe non
modali che scompaiono dopo un breve periodo di tempo. Le implementazioni
del dispositivo DEVONO mostrare notifiche popup dalle app agli utenti finali in un modo
molto visibile.
3.8.5. Temi
Android fornisce i "temi" come meccanismo per le applicazioni per applicare gli stili a
un'intera attività o applicazione. Android 3.0 ha introdotto un nuovo tema "Holo" o "olografico"
come un insieme di stili definiti che gli sviluppatori di app possono utilizzare se vogliono adattarsi al look e al feel del tema Holo come definito dall'SDK Android [Risorse, 24].
Le implementazioni
del dispositivo NON DEVONO modificare nessuno degli attributi del tema Holo esposti alle

applicazioni [Risorse, 25].
Android 4.0 ha introdotto un nuovo tema "Predefinito del dispositivo" come un insieme di stili definiti per
gli sviluppatori di app da utilizzare se vogliono adattare l'aspetto del tema del dispositivo
come definito dall'implementatore del dispositivo. Le implementazioni del dispositivo POSSONO modificare gli attributi del tema
DeviceDefault esposti alle applicazioni [Resources, 25].
3.8.6. Sfondi animati
Android definisce un tipo di componente e l'API e il ciclo di vita corrispondenti che consentono alle applicazioni di esporre uno o più "sfondi animati" all'utente finale [Risorse, 26].
Gli sfondi animati sono animazioni, pattern o immagini simili con funzionalità di input limitate
che vengono visualizzate come sfondo dietro ad altre applicazioni.

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

Le implementazioni del dispositivo in grado di eseguire sfondi dinamici in modo affidabile come descritto
sopra DOVREBBERO implementare gli sfondi dinamici. Le implementazioni del dispositivo che non
eseguono in modo affidabile i live wal papers come descritto sopra NON DEVONO implementare i live wal papers.
3.8.7. Visualizzazione delle app di riferimento
Il codice sorgente di Android 4.1 upstream include un'interfaccia utente per la visualizzazione delle app
di riferimento utilizzando un'immagine in miniatura dello stato grafico dell'app al
momento in cui l'utente ha ultimamente lasciato l'app. Le implementazioni del dispositivo POSSONO modificare o
eliminare questa interfaccia utente; tuttavia, è in programma una versione futura di Android che farà
un uso più ampio di questa funzionalità. Le implementazioni di dispositivi sono fortemente
incoraggiate a utilizzare l'interfaccia utente di Android 4.1 upstream (o un'interfaccia simile basata su miniature) per le applicazioni recenti, altrimenti potrebbero non essere compatibili con una
versione futura di Android.

3.8.8. Impostazioni di gestione dell'input
Android 4.1 include il supporto per gli engine di gestione dell'input. Le API Android 4.1
consentono agli IME delle app personalizzate di specificare impostazioni personalizzabili dall'utente. Le implementazioni del dispositivo
DEVONO includere un modo per l'utente di accedere alle impostazioni dell'IME ogni volta che viene visualizzato un IME che
fornisce queste impostazioni dell'utente.
3.8.9. Telecomando sulla schermata di blocco
Android 4.0 ha introdotto il supporto per l'API Remote Control che consente alle app multimediali
di integrarsi con i controlli di riproduzione che vengono visualizzati in una visualizzazione da remoto, ad esempio la schermata di blocco
del dispositivo [Risorse, 69]. Le implementazioni del dispositivo DEVONO includere il supporto per
l'inserimento di controlli remoti nella schermata di blocco del dispositivo.
3.9 Amministrazione del dispositivo
Android 4.1 include funzionalità che consentono alle applicazioni consapevoli della sicurezza di eseguire funzioni di
amministrazione del dispositivo a livello di sistema, ad esempio l'applicazione di criteri per le password o l'
esecuzione di un reset da remoto, tramite l'API Android Device Administration [Risorse,
27]. Le implementazioni del dispositivo DEVONO fornire un'implementazione della classe
DevicePolicyManager [Risorse, 28] e DEVONO supportare l'intera gamma di
criteri di amministrazione del dispositivo definiti nella documentazione dell'SDK Android [Risorse,
27].
Nota: anche se alcuni dei requisiti descritti sopra sono indicati come "DEVE" per
Android 4.1, è in programma di modificare questi requisiti nella definizione di compatibilità per una versione futura in "DEVE".
In altre parole, questi requisiti sono facoltative in Android 4.1, ma saranno
obbligatori in una versione futura. È molto
consigliato ai dispositivi esistenti e nuovi che eseguono Android 4.1 di soddisfare questi requisiti in Android 4.1, altrimenti non potranno raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

3.10 Accessibilità
Android 4.1 fornisce un livello di accessibilità che aiuta gli utenti con disabilità a navigare più facilmente sui propri dispositivi.
In oltre, Android 4.1 fornisce API di piattaforma che consentono

alle implementazioni di servizi di accessibilità di ricevere chiamate indietro per eventi dell'utente e del sistema
e di generare meccanismi di feedback alternativi, come trasformazione di testo in voce, feedback
aptico e navigazione con trackball /d-pad [Resources, 29]. Leimplementazioni del dispositivo
DEVONO fornire un'implementazione del framework di accessibilità di Android coerente
con l'implementazione predefinita di Android. In particolare, le implementazioni dei dispositivi DEVONO
soddisfare i seguenti requisiti.
Le implementazioni del dispositivo DEVONO supportare le implementazioni di servizi di accessibilità di terze parti tramite le API android.accessibilityservice [Risorse,
30].
Le implementazioni del dispositivo DEVONO generare eventi di accessibilità e inviare questi eventi a tutte le implementazioni di AccessibilityService registrate in modo coerente con l'implementazione predefinita di Android.
Le implementazioni del dispositivo DEVONO fornire un meccanismo accessibile all'utente per attivare e disattivare i servizi di accessibilità e DEVONO mostrare questa interfaccia in risposta all'intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

Inoltre, le implementazioni del dispositivo DEVONO fornire un'implementazione di un
servizio di accessibilità sul dispositivo e DEVONO fornire un meccanismo per gli utenti per
attivare il servizio di accessibilità durante la configurazione del dispositivo. È disponibile un'implementazione open source
di un servizio di accessibilità dal progetto Eyes Free [Risorse, 31].
3.11 Sintesi vocale
Android 4.1 include API che consentono alle applicazioni di utilizzare i servizi di sintesi vocale (TTS)
e consentono ai fornitori di servizi di fornire implementazioni di servizi TTS
[Risorse, 32]. Le implementazioni del dispositivo DEVONO soddisfare questi requisiti relativi al
framework TTS di Android :
Le implementazioni del dispositivo DEVONO supportare le API del framework TTS di Android e
DEVONO includere un motore TTS che supporti le lingue disponibili sul
dispositivo. Tieni presente che il software open source Android upstream include un'implementazione del motore TTS con tutte le funzionalità.
Le implementazioni del dispositivo DEVONO supportare l'installazione di motori TTS di terze parti.
Le implementazioni del dispositivo DEVONO fornire un'interfaccia accessibile all'utente che consenta agli utenti di selezionare un motore TTS da utilizzare a livello di sistema.

4. Compatibilità del pacchettizzamento delle app
Le implementazioni del dispositivo DEVONO installare e eseguire i file Android ".apk" come generati dall'
strumento "aapt" incluso nell'SDK Android ufficiale [Risorse, 33].
Le implementazioni dei dispositivi NON DEVONO estendere i formati .apk [Risorse, 34], Manifest di Android [Risorse, 35], bytecode di Dalvik [Risorse, 17] o bytecode di Renderscript
in modo da impedire l'installazione e l'esecuzione corretta di questi file su altri dispositivi compatibili.

Gli implementatori di dispositivi DOVROBBERO utilizzare l'implementazione
upstream di riferimento di Dalvik e il sistema di gestione del pacchetto
dell'implementazione di riferimento.
5. Compatibilità multimediale
Le implementazioni del dispositivo DEVONO includere almeno una forma di uscita audio, ad esempio
altoparlanti, jack per cuffie, connessione altoparlanti esterni e così via.
5.1. Codici codec media
Le implementazioni del dispositivo DEVONO supportare i formati media di base specificati nella documentazione dell'SDK Android [Risorse, 58] tranne dove esplicitamente consentito in questo
documento.
In particolare, le implementazioni del dispositivo DEVONO supportare i formati multimediali,
gli encoder, i decoder, i tipi di file e i formati di contenitore definiti nelle tabelle di seguito. Al di
questi codici di compressione sono forniti come implementazioni di software nell'implementazione
Android preferita dall'Android Open Source Project.
Tieni presente che né Google né l'Open Handset Alliance affermano
che questi codec sono esenti da brevetti di terze parti.
A coloro che intenzionano utilizzare questo codice sorgente in prodotti hardware o software viene
consigliato di tener presente che le implementazioni di questo codice, incluse quelle in software open source
o shareware, potrebbero richiedere licenze di brevetto dai proprietari di brevetti pertinenti.
Tieni presente che queste tabelle non elencano requisiti di velocità in bit specifici per la maggior parte dei codec video
perché l'hardware dei dispositivi attuali non supporta necessariamente velocità in bit che corrispondono
esattamente alle velocità in bit richieste specificate dagli standard pertinenti. Invece, le implementazioni
del dispositivo DEVONO supportare la velocità in bit massima praticabile sull'hardware, fino a

i limiti definiti dalle specifiche.

Tipo/i di file /
Formato /
Tipo
Codificatore
Decodificatore
Dettagli
Contenitore
Codec
Formati
Supporto per
OBBLIGATORIO
mono/stereo/5.0/5.1*
MPEG-4
Obbligatorio per le implementazioni del dispositivo
contenuti con
Profilo AAC
che includono hardware per microfoni
OBBLIGATORIO
campionamento standard
(AAC LC)
e definiscono
3GPP
frequenze da 8 a 48
android.hardware.microphone.
(.3gp)
kHz.
MPEG-4
Supporto
per
(.mp4,
MPEG-4
mono/stereo/5.0/5.1*
.m4a)
contenuti
HE AAC
con
ADTS
raw

OBBLIGATORI
Profilo
campionamento
standard
AAC (.aac,
(AAC+)
frequenze
da
16
a
48
decodifica
in
kHz.
Android
3.1+,
Supporto
per
MPEG-4
OBBLIGATORIO
per
l'encoding
del
dispositivo
in
mono/stereo/5.0/5.1*
implementazioni
HE AAC v2
che
includono
contenuti

MPEG-TS
MPEG-4
(.ts, not
Audio
OBBLIGATORI
per il dispositivo
Supporto
per le implementazioni
spostabili
di tipo
Oggetto
che includono
contenuti
mono/stereo
Android
ER AAC
hardware
del microfono
OBBLIGATORI
con
standard
3.0+)
ELD
definire
frequenze
di campionamento
da
(Ottimizzato
android.hardware.microphone
16
a
48
kHz.
Low Delay
AAC)
OBBLIGATORI
Obbligatorio per le implementazioni del dispositivo
4,75 a 12,2 kbps
AMR-NB
che include l'hardware del microfono
OBBLIGATORI
3GPP (.3gp)
campionato a 8 kHz
e definiscono
android.hardware.microphone.
OBBLIGATORIO
Obbligatorio per le implementazioni del dispositivo
9 rate da 6,60
AMR-WB
che includono l'hardware del microfono
OBBLIGATORIO
kbit/s a 23,85 kbit/s
3GPP (.3gp)
e definiscono
campionati a 16 kHz
android.hardware.microphone.
Mono/stereo (no
multicanale).
Audio
Frequenze di campionamento fino a
48 kHz (ma fino a
44,1 kHz è
consigliato sui
dispositivi con
OUTPUT
FLAC

obbligatorio
a
44,1
kHz,
poiché
il
downsampler
da
48
a
44,1
kHz
non
include
un
filtro
passa-basso). Consigliato
16 bit; nessun
dither
applicato per 24 bit.
Mono/Stereo 8-
320Kbps
MP3

OBBLIGATORI
MP3 (.mp3)
(CBR) o

1 (.mid,
DLS Version 1 and
.xmf, .mxmf)
2. XMF e mobile
RTTTL/RTX
MIDI

OBBLIGATORIO
XMF. Supporto per
(.rtttl, .rtx)
formati di suoneria
OTA (.ota)
RTTTL/RTX, OTA,
iMelody
e iMelody
(.imy)

Ogg (.ogg)
Vorbis

OBBLIGATORI

Matroska
(.mkv)
8-bit e 16-bit
lineare PCM** (frequenze
fino al limite di
hardware).Dispositivi
DEVONO supportare
PCM/WAVE
OBBLIGATORI
OBBLIGATORI
WAVE (.wav)
frequenze di campionamento per
registrazione PCM non codificata
a 8000,16000 e
44100 Hz
frequenze
JPEG
OBBLIGATORI
OBBLIGATORI
Base+progressive
JPEG (.jpg)
GIF

OBBLIGATORI

GIF (.gif)
Immagine
PNG
OBBLIGATORI
OBBLIGATORI

PNG (.png)
BMP

OBBLIGATORI

BMP (.bmp)
WEBP
OBBLIGATORI
OBBLIGATORI

WebP (.webp)
OBBLIGATORI
Obbligatorio per le implementazioni del dispositivo
3GPP
che includono l'hardware della fotocamera e
(.3gp)
H.263
OBBLIGATORI

definisci android.hardware.camera
MPEG-4
o
(.mp4)
android.hardware.camera.front.
3GPP
(.3gp)
OBBLIGATORIO
MPEG-4
(.mp4)
Obbligatorio per le implementazioni del dispositivo
MPEG-TS
che include l'hardware della fotocamera e
Profilo di base
Video
H.264 AVC
OBBLIGATORIO
(.ts, AAC
definisci android.hardware.camera
(BP)
solo audio,
o
non
android.hardware.camera.front.
seekable,
Android
3.0+)
MPEG-4

OBBLIGATORIO

3GPP (.3gp)
SP
WebM (.webm)
OBBLIGATORIO
e Matroska
VP8

(Android

(.mkv, Android
2.3.3+)
4.0+)
*Nota: è obbligatorio solo il downmix dei contenuti 5.0/5.1; la registrazione o il rendering di più di 2

� **Nota: è obbligatoria la acquisizione in formato PCM lineare a 16 bit. La acquisizione in formato PCM
lineare a 8 bit non è obbligatoria.
5.2 Codifica video
Le implementazioni di dispositivi Android che includono una fotocamera posteriore e dichiarano
android.hardware.camera DEVONO supportare i seguenti profili di codifica video.
HD (se supportato da

SD (bassa qualità) SD (alta qualità)
hardware)
H.264 Baseline
H.264 Baseline
Codec video
Profilo Baseline H.264
Profilo
Profilo
Video
176 x 144 px
480 x 360 px
1280 x 720 px
risoluzione
Frame video 12 fps
30 fps
30 fps
rate
500 Kbps o
Velocità in bit video 56 Kbps
2 Mbps o superiore
superiore
Codec audio AAC-LC
AAC-LC
AAC-LC

Audio
1 (mono)
2 (stereo)
2 (stereo)
canali
Velocità in bit audio 24 Kbps
128 Kbps
192 Kbps
5.3. Registrazione audio
Quando un'applicazione ha utilizzato l'API android.media.AudioRecord per iniziare a registrare
uno stream audio, le implementazioni del dispositivo che includono l'hardware del microfono e
dichiarano android.hardware.microphone DEVONO campionare e registrare l'audio con ciascuno di
questi comportamenti:
Il dispositivo DEVE mostrare caratteristiche di ampiezza approssimativamente uniformi rispetto alla frequenza
; in particolare, ±3 dB, da 100 Hz a 4000 Hz
La sensibilità dell'ingresso audio DEVE essere impostata in modo che una sorgente di livello di potenza audio di 90 dB
(SPL) a 1000 Hz produca un valore RMS di 2500 per campioni a 16 bit.
I livelli di ampiezza PCM DEVONO seguire in modo lineare le variazioni del livello SPL di ingresso su almeno un
intervallo di 30 dB da -18 dB a +12 dB rispetto a 90 dB SPL al microfono.
La distorsione armonica totale DEVE essere inferiore all'1% per 1 kHz a 90 dB SPL di livello
di ingresso.
Oltre alle specifiche di registrazione riportate sopra, quando un'applicazione ha iniziato a registrare uno stream audio utilizzando la sorgente audio
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:
L'elaborazione di riduzione del rumore, se presente, DEVE essere disattivata.
Il controllo automatico del guadagno, se presente, DEVE essere disattivato.

Nota: anche se alcuni dei requisiti descritti sopra sono indicati come "DA" per
Android 4.1, è in programma di modificare questi requisiti nella definizione di compatibilità per una versione futura in "DEVE".
In altre parole, questi requisiti sono facoltative in Android 4.1, ma saranno
obbligatori in una versione futura. È molto
consigliato ai dispositivi esistenti e nuovi che eseguono Android 4.1 di soddisfare questi requisiti in Android 4.1, altrimenti non potranno raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

5.4. Latenza audio
La latenza audio è in genere definita come l'intervallo tra il momento in cui un'applicazione richiede
un'operazione di riproduzione o registrazione audio e il momento in cui l'implementazione del dispositivo effettiva inizia l'operazione.
Molte classi di applicazioni si basano su latenze brevi per ottenere
effetti in tempo reale come effetti sonori o comunicazioni VOIP. Le implementazioni del dispositivo
che includono hardware per microfoni e dichiarano android.hardware.microphone
DEVONO soddisfare tutti i requisiti di latenza audio descritti in questa sezione. Consulta la sezione 7
per i dettagli sulle condizioni in cui l'hardware del microfono può essere omesso dalle implementazioni del dispositivo.

Ai fini di questa sezione:
"latenza in uscita a freddo" è definita come l'intervallo tra il momento in cui un'applicazione
richiede la riproduzione audio e il momento in cui l'audio inizia a essere riprodotto, quando il sistema audio
è stato inattivo e spento prima della richiesta
"latenza in uscita a caldo" è definita come l'intervallo tra il momento in cui un'applicazione
richiede la riproduzione audio e il momento in cui il primo sample viene inviato all'applicazione tramite il call back, quando il sistema audio e il microfono sono stati
inattivi e spenti prima della richiesta
"latenza in input a freddo" è definita come l'intervallo tra il momento in cui un'applicazione
richiede la registrazione audio e il momento in cui il primo sample viene inviato all'applicazione tramite il call back, quando il sistema audio e il microfono sono stati
inattivi e spenti prima della richiesta
"latenza in input continua" è definita come il momento in cui si verifica un suono ambientale e
il momento in cui il sample corrispondente a quel suono viene inviato a un'applicazione di registrazione tramite il call back, quando il dispositivo è in modalità di registrazione
Utilizzando le definizioni di sopra, le implementazioni del dispositivo DEVONO mostrare ciascuna di queste
proprietà:
latenza in uscita a freddo di non più di 100 millisecondi
latenza in uscita a caldo di non più di 10 millisecondi
latenza in uscita continua di non più di 45 millisecondi
latenza in input a freddo di non più di 100 millisecondi
latenza in input continua di non più di 50 millisecondi
Nota: anche se i requisiti descritti sopra sono indicati come "DEVONO" per Android 4.1,

è in programma di modificare la definizione di compatibilità per una versione futura in modo che divengano "DEVONO".
In altre parole, questi requisiti sono facoltative in Android 4.1, ma saranno obbligatori in una versione futura
.

È vivamente
invitante a soddisfare questi requisiti in Android 4.1 ai dispositivi esistenti e nuovi che eseguono Android 4.1, altrimenti non potranno
raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.
Se un'implementazione del dispositivo soddisfa i requisiti di questa sezione, potrebbe segnalare
il supporto per l'audio a bassa latenza, segnalando la funzionalità "android.hardware.audio.low-
latency" tramite la classe android.content.pm.PackageManager. [Resources, 37]
Al contrario, se l'implementazione del dispositivo non soddisfa questi requisiti, NON DEVE
segnalare il supporto per l'audio a bassa latenza.
5.5. Protocolli di rete
I dispositivi DEVONO supportare i protocolli di rete multimediale per la riproduzione di audio e video come
specificato nella documentazione dell'SDK Android [Risorse, 58]. In particolare, i dispositivi
DEVONO supportare i seguenti protocolli di network media:
RTSP (RTP, SDP)
Streaming progressivo HTTP(S)
Protocollo di bozza di streaming live HTTP(S), versione 3 [Risorse, 59]
6. Compatibilità con gli strumenti per sviluppatori
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 (noto come adb) [Risorse, 33]
Le implementazioni del dispositivo DEVONO supportare tutte le funzioni adb come documentate nell'
SDK Android. Il demone adb sul dispositivo DEVE essere inattivo per impostazione predefinita e
DEVE essere presente un meccanismo accessibile all'utente per attivare il
Bridge per il debug di Android.
Dalvik Debug Monitor Service (noto come ddms) [Risorse, 33]
Le implementazioni del dispositivo DEVONO supportare tutte le funzionalità ddms come documentato nell'
SDK Android.Poiché ddms utilizza adb, il supporto per ddms DEVE essere inattivo per
impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato il
Debug Bridge Android, come sopra.
Monkey [Risorse, 36]
Le implementazioni del dispositivo DEVONO includere il framework Monkey e renderlo
disponibile per le applicazioni da utilizzare.
La maggior parte dei sistemi basati su Linux e dei sistemi Apple Macintosh riconosce i dispositivi Android
utilizzando gli strumenti SDK Android standard, senza ulteriore supporto; tuttavia, i sistemi Microsoft
Windows in genere richiedono un driver per i nuovi dispositivi Android. Ad esempio,
i nuovi ID fornitore e, a volte, i nuovi ID dispositivo richiedono driver USB personalizzati per i sistemi
Windows. Se un'implementazione del dispositivo non è riconosciuta dallo strumento adb come
fornito nell'SDK Android standard, gli implementatori del dispositivo DEVONO fornire i driver
Windows per consentire agli sviluppatori di connettersi al dispositivo utilizzando il protocollo adb. Questi
driver DEVONO essere forniti per Windows XP, Windows Vista e Windows 7, sia nelle
versioni a 32 bit che a 64 bit.
7. Compatibilità dell'hardware
Se un dispositivo include un particolare componente hardware che ha un'API corrispondente per
sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come
descritto nella documentazione dell'SDK Android. Se un'API nell'SDK interagisce con un
componente hardware che è dichiarato facoltativo e l'implementazione del dispositivo non
possiede quel componente:
le definizioni di classe complete (come documentato dall'SDK) per le API del componente
DEVONO essere ancora presenti
i comportamenti dell'API DEVONO essere implementati come no-op in qualche modo ragionevole

i metodi dell'API DEVONO restituire valori null dove consentito dalla documentazione dell'SDK

i metodi dell'API DEVONO restituire implementazioni no-op di classi dove i valori null
non sono consentiti dalla documentazione dell'SDK
i metodi dell'API NON DEVONO generare eccezioni non documentate dalla documentazione dell'SDK

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

Le implementazioni del dispositivo DEVONO segnalare informazioni accurate sulla configurazione dell'hardware
tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String)
nella classe android.content.pm.PackageManager. [Resources, 37]
7.1. Display e grafica
Android 4.1 include funzionalità che modificano automaticamente gli asset dell'applicazione e i layout dell'interfaccia utente
in base al dispositivo, per garantire che le applicazioni di terze parti siano sempre funzionanti su una
varietà di configurazioni hardware [Risorse, 38]. I dispositivi DEVONO implementare correttamente
queste API e questi comportamenti, come descritto in questa sezione.
Le unità di misura a cui si fa riferimento nei requisiti di questa sezione sono definite come segue:
"Dimensioni diagonali fisiche" è la distanza in pollici tra due angoli opposti
della porzione illuminata del display.
"dpi" (che significa "punti per pollice") è il numero di pixel coperti da un intervallo lineare
orizzontale o verticale di 1". Se sono elencati valori in dpi, sia quelli orizzontali che
quelli verticali devono rientrare nell'intervallo.
"Proporzioni" è il rapporto tra la dimensione più lunga della schermata e quella più corta
. Ad esempio, un display di 480x854 pixel avrebbe 854 / 480 =
1,779, ovvero circa "16:9".
Un "pixel indipendente dalla densità" o ("dp") è l'unità di pixel virtuale normalizzata a uno schermo di 160
dpi, calcolata come: pixel = dps * (densità / 160).
7.1.1. Configurazione schermo
Dimensioni schermo
Il framework UI di Android supporta una varietà di dimensioni schermo diverse e consente alle
applicazioni di eseguire query sulle dimensioni schermo del dispositivo (ovvero "layout schermo") tramite
android.content.res.Configuration.screenLayout con
SCREENLAYOUT_SIZE_MASK. Le implementazioni del dispositivo DEVONO segnalare la dimensione
dell'apposita
area come definita nella documentazione dell'SDK Android [Risorse, 38] e determinata dalla

piattaforma Android a monte. In particolare, le implementazioni del dispositivo devono segnalare le
dimensioni dello schermo corrette in base alle seguenti dimensioni dello schermo di pixel (dp)indipendenti dalla densità.

I dispositivi DEVONO avere dimensioni dello schermo di almeno 426 dp x 320 dp ('piccolo ')
I dispositivi che riportano la dimensione dello schermo 'normale' DEVONO avere dimensioni dello schermo di almeno 480
dp x 320 dp
I dispositivi che riportano la dimensione dello schermo 'grande' DEVONO avere dimensioni dello schermo di almeno 640
dp x 480 dp
I dispositivi che riportano la dimensione dello schermo 'molto grande' DEVONO avere dimensioni dello schermo di almeno 960
dp x 720 dp
In oltre, i dispositivi DEVONO avere dimensioni dello schermo di almeno 6,35 cm di diagonale fisica
.
I dispositivi NON DEVONO modificare in nessun momento le dimensioni dello schermo registrate.
Le app possono indicare le dimensioni dello schermo supportate tramite l'attributo <supports-
screens> nel file AndroidManifest.xml. Le implementazioni del dispositivo DEVONO
rispettare correttamente il supporto dichiarato dalle app per gli schermi piccoli, normali, grandi e molto grandi
, come descritto nella documentazione dell'SDK Android.
Proporzioni schermo
Le proporzioni DEVONO essere comprese tra 1,3333 (4:3) e 1,85 (16:9).
Densità dello schermo
Il framework dell'interfaccia utente di Android definisce un insieme di densità logiche standard per aiutare
gli sviluppatori di app a scegliere come target le risorse dell'app. Le implementazioni del dispositivo DEVONO
indicare una delle seguenti densità del framework Android logico tramite le
API android.util.DisplayMetrics e DEVONO eseguire le applicazioni a questa
densità standard.
120 dpi, noto come 'ldpi'
160 dpi, noto come 'mdpi'
213 dpi, noto come 'tvdpi'
240 dpi, noto come 'hdpi'
320 dpi, noto come 'xhdpi'
480 dpi, noto come 'xxhdpi'
Le implementazioni del dispositivo DEVONO definire la densità del framework Android standard che
è numericamente più simile alla densità fisica della schermata, a meno che questa densità logica

non sia numericamente più simile alla densità fisica della schermata, a meno che questa densità logica
non sposti le dimensioni dello schermo registrate al di sotto del valore minimo supportato. Se la
densità del framework Android standard che è numericamente più vicina alla densità fisica determina una
dimensione schermo più piccola rispetto alla dimensione schermo compatibile più piccola supportata (larghezza 320 dp),le implementazioni del dispositivo DEVONO segnalare la densità del framework Android standard successiva più bassa.

7.1.2. Metriche di visualizzazione
Le implementazioni del dispositivo DEVONO segnalare valori corretti per tutte le metriche di visualizzazione definite in
android.util.DisplayMetrics [Resources, 39].
7.1.3. Orientamento schermo
I dispositivi DEVONO supportare l'orientamento dinamico da parte delle app per l'orientamento schermo verticale o
orizzontale. In altre parole, il dispositivo deve rispettare la
richiesta dell'applicazione per un orientamento dello schermo specifico. Le implementazioni del dispositivo POSSONO selezionare l'orientamento
verticale o orizzontale come predefinito.
I dispositivi DEVONO segnalare il valore corretto per l'orientamento attuale del dispositivo, ogni volta che viene effettuata una query tramite android.content.res.Configuration.orientation,
android.view.Display.getOrientation() o altre API.

I dispositivi NON DEVONO modificare le dimensioni o la densità dello schermo quando si modifica
l'orientamento.
I dispositivi DEVONO indicare gli orientamenti schermo supportati (
android.hardware.screen.portrait e/o android.hardware.screen.landscape)
e DEVONO indicare almeno un orientamento supportato. Ad esempio, un dispositivo con uno
schermo orizzontale con orientamento fisso, ad esempio una televisione o un laptop, DEVE segnalare solo
android.hardware.screen.landscape.
7.1.4. Accelerazione grafica 2D e 3D
Le implementazioni del dispositivo DEVONO supportare sia OpenGL ES 1.0 che 2.0, come descritto
e descritto nella documentazione dell'SDK Android. Le implementazioni del dispositivo DEVONO anche
supportare Android Renderscript, come descritto nella documentazione dell'SDK Android
[Risorse, 8].
Le implementazioni del dispositivo DEVONO anche identificarsi correttamente come supportanti
OpenGL ES 1.0 e 2.0. ovvero:
Le API gestite (ad esempio tramite il metodo GLES10.getString()) DEVONO segnalare il supporto per OpenGL ES 1.0 e 2.0
Le API OpenGL C/C++ native (ovvero quelle disponibili per le app tramite
libGLES_v1CM.so, libGLES_v2.so o libEGL.so) DEVONO segnalare il supporto per
OpenGL ES 1.0 e 2.0.

Le implementazioni dei dispositivi POSSONO implementare qualsiasi estensione OpenGL ES.
Tuttavia, le implementazioni dei dispositivi DEVONO segnalare tramite le API native e gestite di OpenGL ES le stringhe di estensione che supportano e, al contrario, NON DEVONO segnalare le stringhe di estensione che non supportano.

Tieni presente che Android 4.1 include il supporto per le applicazioni facoltative che specificano di richiedere formati di compressione delle texture OpenGL specifici.
Questi formati sono tipici e
specifici del fornitore. Le implementazioni del dispositivo non sono obbligatorie per Android 4.1 per implementare
qualsiasi formato di compressione delle texture specifico. Tuttavia, DEVONO segnalare con precisione qualsiasi
formato di compressione delle texture che supportano, tramite il metodo getString() nell'
API OpenGL.
Android 4.1 include un meccanismo per le applicazioni per dichiarare che vogliono
abilitare l'accelerazione hardware per le grafica 2D a livello di applicazione, attività, finestra o
visualizzazione tramite l'uso di un tag manifest android:hardwareAccelerated o di chiamate all'
API diretta [Risorse, 9].
In Android 4.1, le implementazioni del dispositivo DEVONO attivare l'accelerazione hardware per
impostazione predefinita e DEVONO disattivare l'accelerazione hardware se lo sviluppatore lo richiede impostando android:hardwareAccelerated="false" o disattivando l'accelerazione hardware
direttamente tramite le API Android View.

Inoltre, le implementazioni dei dispositivi DEVONO mostrare un comportamento coerente con la documentazione dell'SDK
Android sull'accelerazione hardware [Risorse, 9].
Android 4.1 include un oggetto TextureView che consente agli sviluppatori di integrare direttamente
le texture OpenGL ES con accelerazione hardware come target di rendering in una gerarchia UI.
Le implementazioni del dispositivo DEVONO supportare l'API TextureView e DEVONO mostrare

un comportamento coerente con l'implementazione Android a monte.
7.1.5. Modalità di compatibilità delle app legacy
Android 4.1 specifica una "modalità di compatibilità" in cui il framework opera in una
modalità equivalente a dimensioni dello schermo "normali" (larghezza 320 dp) a vantaggio delle app
legacy non sviluppate per vecchie versioni di Android precedenti all'indipendenza
dalle dimensioni dello schermo. Le implementazioni del dispositivo DEVONO includere il supporto per la modalità di compatibilità
delle app legacy come implementata dal codice open source di Android upstream. In altre parole, le implementazioni dei dispositivi NON DEVONO modificare gli attivatori o le soglie a cui viene attivata la modalità di compatibilità e NON DEVONO modificare il comportamento della modalità di compatibilità stessa.

7.1.6. Tipi di schermo
Le schermate di implementazione del dispositivo sono classificate in uno di due tipi:
Implementazioni di display a pixel fissi: lo schermo è un unico pannello che supporta
solo una larghezza e un'altezza di pixel. In generale lo schermo è fisico e integrato
con il dispositivo. Esempi includono smartphone, tablet e così via.
Implementazioni di display a pixel variabili: l'implementazione del dispositivo non ha uno
schermo incorporato e include una porta di uscita video come VGA, HDMI o una
porta wireless per il display o ha uno schermo incorporato che può modificare le dimensioni dei pixel
. Esempi includono televisori, decoder e così via.
Implementazioni di dispositivi con pixel fissi
Le implementazioni di dispositivi con pixel fissi POSSONO utilizzare schermi di qualsiasi dimensione in pixel,
a condizione che soddisfino i requisiti definiti in questa definizione di compatibilità.
Le implementazioni con pixel fissi POSSONO includere una porta di uscita video per l'utilizzo con un display
esterno. Tuttavia, se il display viene utilizzato per l'esecuzione di app, il dispositivo DEVE soddisfare
i seguenti requisiti:
Il dispositivo DEVE registrare le stesse metriche di configurazione e di visualizzazione dello schermo, come
descritto nelle sezioni 7.1.1 e 7.1.2, come il display a pixel fissi.
Il dispositivo DEVE registrare la stessa densità logica del display a pixel fissi.
Il dispositivo DEVE registrare le dimensioni dello schermo uguali o molto vicine
a quelle del display a pixel fissi.
Ad esempio, un tablet con diagonale di 7" e risoluzione di 1024 x 600 pixel è
considerato un'implementazione di display mdpi di grandi dimensioni con pixel fissi. Se contiene una porta di
uscita video che visualizza a 720p o 1080p, l'implementazione del dispositivo DEVE scalare l'
uscita in modo che le applicazioni siano eseguite solo in una finestra mdpi di grandi dimensioni, indipendentemente da
che sia in uso il display a pixel fissi o la porta di uscita video.
Implementazioni di dispositivi con pixel variabili
Le implementazioni di dispositivi con pixel variabili DEVONO supportare una o entrambe le risoluzioni 1280x720 o
1920x1080 (ovvero 720p o 1080p). Le implementazioni di dispositivi con display
a pixel variabili NON DEVONO supportare alcune altre configurazioni o modalità schermo. Le
implementazioni di dispositivi con schermi a pixel variabili POSSONO modificare la configurazione o la
modalità dello schermo in tempo di esecuzione o al momento dell'avvio. Ad esempio, un utente di una console per l'accesso a internet potrebbe sostituire un
display a 720p con un display a 1080p e l'implementazione del dispositivo potrebbe adattarsi
di conseguenza.
Ulteriori implementazioni di dispositivi con pixel variabili DEVONO registrare i seguenti bucket di configurazione per queste dimensioni di pixel:
1280x720 (noto anche come 720p): dimensioni schermo "grandi", densità "tvdpi" (213 dpi)
1920x1080 (noto anche come 1080p): dimensioni schermo "grandi", densità "xhdpi" (320 dpi)
Per chiarezza, le implementazioni di dispositivi con pixel variabili sono limitate a
720p o 1080p in Android 4.1 e DEVONO essere configurate per registrare le dimensioni schermo e i bucket di densità come notato sopra.

7.1.7. Tecnologia schermo
La piattaforma Android include API che consentono alle applicazioni di eseguire il rendering di grafica complessa sul
display. I dispositivi DEVONO supportare tutte queste API come definito dall'SDK Android
, a meno che non sia specificato diversamente in questo documento. Nello specifico:
I dispositivi DEVONO supportare display in grado di eseguire il rendering di grafica a colori a 16 bit e
DOVREBBERO supportare display in grado di eseguire il rendering di grafica a colori a 24 bit.
I dispositivi DEVONO supportare display in grado di eseguire il rendering di animazioni.
La tecnologia di visualizzazione utilizzata DEVE avere un rapporto di aspetto (PAR) in pixel compreso tra 0,9

e 1,1. In altre parole, le proporzioni dei pixel DEVONO essere quasi quadrate (1,0) con una tolleranza del 10%
.
7.2. Dispositivi di input
7.2.1. Tastiera
Implementazioni del dispositivo:
DEVE includere il supporto per il Framework di gestione dell'input (che consente a sviluppatori di terze parti di creare motori di gestione dell'input, ovvero la tastiera software) come
descritto su http://developer.android.com
DEVE fornire almeno un'implementazione della tastiera software (indipendentemente dal fatto che sia presente una tastiera hardware)
PUÒ includere implementazioni aggiuntive della tastiera software
PUÒ includere una tastiera hardware
NON DEVE includere una tastiera hardware che non corrisponde a uno dei formati
specificati in android.content.res.Configuration.keyboard [Resources, 40]
(ovvero QWERTY o 12 tasti)
7.2.2.

Navigazione non touch
Implementazioni del dispositivo:
PUÒ omettere un'opzione di navigazione non touch (ovvero può omettere un trackball, un d-pad o
una rotella)
DEVE segnalare il valore corretto per
android.content.res.Configuration.navigation [Resources, 40]
DEVE fornire un meccanismo di interfaccia utente alternativo ragionevole per la
selezione e la modifica del testo, compatibile con gli Input Management Engine. Il
software open source Android upstream include un meccanismo di selezione
adatto all'uso con dispositivi che non dispongono di input di navigazione non touch.
7.2.3. Chiavi di navigazione
Le funzioni Home, Menu e Indietro sono essenziali per il paradigma di navigazione
di Android. Le implementazioni del dispositivo DEVONO rendere queste funzioni disponibili per l'utente
in qualsiasi momento durante l'esecuzione delle applicazioni. Queste funzioni POSSONO essere implementate tramite
tasti fisici dedicate (ad esempio tasti touch meccanici o capacitivi), o POSSONO
essere implementate utilizzando chiavi software dedicate, gesti, pannello touch e così via. Android
4.1 supporta entrambe le implementazioni.
Android 4.1 introduce il supporto per l'azione di assistenza [Risorse, 63]. Le
implementazioni del dispositivo DEVONO rendere l'azione di assistenza disponibile per l'utente in qualsiasi momento durante l'
esecuzione delle applicazioni.Questa funzione PUÒ essere implementata tramite chiavi
hardware o software.
Le implementazioni del dispositivo POSSONO utilizzare una parte distinta dello schermo per visualizzare i tasti di navigazione, ma in questo caso DEVONO soddisfare i seguenti requisiti:
I tasti di navigazione dell'implementazione del dispositivo DEVONO utilizzare una parte distinta dello schermo, non disponibile per le applicazioni, e NON DEVONO coprire o interferire con la parte dello schermo disponibile per le applicazioni.
Le implementazioni del dispositivo DEVONO mettere a disposizione una parte del display per le applicazioni che soddisfano i requisiti definiti nella Sezione 7.1.1.
Le implementazioni del dispositivo DEVONO visualizzare i tasti di navigazione quando le applicazioni non specificano una modalità dell'interfaccia utente di sistema o specificano SYSTEM_UI_FLAG_VISIBLE.
Le implementazioni del dispositivo DEVONO presentare i tasti di navigazione in una modalità "basso profilo" (ad es. attenuata) non intrusiva quando le applicazioni specificano SYSTEM_UI_FLAG_LOW_PROFILE.

Le implementazioni del dispositivo DEVONO nascondere i tasti di navigazione quando le applicazioni
specificano SYSTEM_UI_FLAG_HIDE_NAVIGATION.
L'implementazione del dispositivo DEVE presentare un tasto Menu alle applicazioni quando
targetSdkVersion <= 10 e NON DEVE presentare un tasto Menu quando il
targetSdkVersion > 10.
Le implementazioni del dispositivo DEVONO mettere a disposizione una parte del display alle
applicazioni che soddisfano i requisiti definiti nella Sezione 7.1.1.
7.2.4. Input touchscreen
Le implementazioni del dispositivo DEVONO avere un sistema di input del cursoredi qualche tipo (
simile a un mouse o touch). Tuttavia, se un'implementazione del dispositivo non supporta un sistema di input

�� Le implementazioni di dispositivi che lo fanno

includono un sistema di input del cursore:
DEVONO supportare cursori monitorati in modo completo e indipendente, se il sistema di input del dispositivo
supporta più cursori
DEVONO segnalare il valore di android.content.res.Configuration.touchscreen
[Resources, 40] ccorrispondente al tipo del touchscreen specifico sul
dispositivo
Android 4.0 include il supporto per una varietà di touch screen, touchpad e dispositivi di input con toque falsi
. Le implementazioni di dispositivi con schermo touch sono associate a un
display [Risorse, 71] in modo che l'utente abbia l'impressione di manipolare direttamente gli
elementi sullo schermo. Poiché l'utente tocca direttamente lo schermo, il sistema non
richiede alcun altro elemento per indicare gli oggetti che vengono manipolati. Al
contrario, un'interfaccia touch simulata fornisce un sistema di input dell'utente che approssima un
sottoinsieme di funzionalità del touchscreen. Ad esempio, un mouse o un telecomando che controlla
un cursore sulla schermata si avvicina al tocco, ma richiede all'utente di prima indicare o mettere a fuoco
e poi fare clic. Numerosi dispositivi di input come il mouse, il trackpad, il mouse aereo basato su giroscopio,
il cursore a giroscopio, il joystick e il trackpad multi-touch possono supportare interazioni con toccamenti falsi.
Android 4.0 include la costante della funzionalità android.hardware.faketouch, che
corrisponde a un dispositivo di input non touch ad alta fedeltà (ovvero basato su cursore) come un
mouse o un trackpad che può emulare adeguatamente l'input basato su tocco (incluso il supporto di
gesti di base), e indica che il dispositivo supporta un sottoinsieme emulato delle funzionalità del
touchscreen. Le implementazioni del dispositivo che dichiarano la funzionalità di toque falsi
DEVONO soddisfare i requisiti di toque falsi nella sezione 7.2.5.
Le implementazioni del dispositivo DEVONO segnalare la funzionalità corretta corrispondente al tipo di
input utilizzato. Le implementazioni del dispositivo che includono un touchscreen (monotocco o superiore)
DEVONO segnalare la constante della funzionalità della piattaforma android.hardware.touchscreen. Le implementazioni
del dispositivo che segnalano la costante della funzionalità della piattaforma
android.hardware.touchscreen DEVONO segnalare anche la costante della funzionalità della piattaforma
android.hardware.faketouch. Le implementazioni del dispositivo che non includono un
touchscreen (e si basano solo su un dispositivo con cursore) NON DEVONO segnalare nessuna funzionalità
del touchscreen e DEVONO segnalare solo android.hardware.faketouch se soddisfano i requisiti del
touch fake nella sezione 7.2.5.
7.2.5. Input touch fake
Implementazioni del dispositivo che dichiarano il supporto per android.hardware.faketouch
DEVONO segnalare le posizioni assolute X e Y sullo schermo della posizione del cursore e
mostrare un cursore visivo sullo schermo[Resources, 70]
DEVONO segnalare l'evento touch con il codice azione [Resources, 70] che specifica la
modifica dello stato che si verifica sul cursore going down or up on the screen
[Resources, 70]
DEVONO supportare il cursore giù e su su un oggetto sullo schermo, che consente a
users to emulate tap on an object on the screen
DEVONO supportare il cursore giù, il cursore su, il cursore giù e poi il cursore su nello stesso
luogo su un oggetto sullo schermo entro una soglia di tempo, che consente a
gli utenti di emulare un tocco doppio su un oggetto sullo schermo [Resources, 70]
DEVONO supportare il cursore giù su un punto arbitrario sullo schermo, il cursore si sposta su
qualsiasi altro punto arbitrario sullo schermo, seguito da un cursore su, che consente a
gli utenti di emulare un trascinamento touch
DEVONO supportare il cursore giù e poi consentire agli utenti di spostare rapidamente l'oggetto in una
posizione diversa sullo schermo e poi il cursore su sullo schermo, che consente a
gli utenti di spostare un oggetto sullo schermo
I dispositivi che dichiarano il supporto per android.hardware.faketouch.multitouch.distinct
DEVONO soddisfare i requisiti per il tocco fake sopra e DEVONO supportare anche il monitoraggio distinto di due o più input del cursore indipendenti.

7.2.6. Microfono
Le implementazioni del dispositivo POSSONO omettere un microfono. Tuttavia, se un'implementazione del dispositivo
omette un microfono, NON DEVE segnalare la costante della funzionalità android.hardware.microphone
, e deve implementare l'API di registrazione audio come no-op, secondo la Sezione 7.
Al contrario, le implementazioni del dispositivo che possiedono un microfono:
DEVONO segnalare la costante della funzionalità android.hardware.microphone
DEVONO soddisfare i requisiti di qualità audio nella Sezione 5.4
DEVONO soddisfare i requisiti di latenza audio nella Sezione 5.5
7.3. Sensori

Android 4.1 include API per accedere a una varietà di tipi di sensori. Le implementazioni dei dispositivi in generale POSSONO omettere questi sensori, come previsto nelle seguenti
sottosezioni.
Se un dispositivo include un particolare tipo di sensore che ha un'API corrispondente
per sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come
descritto nella documentazione dell'SDK Android. Ad esempio, le implementazioni del dispositivo:
DEVONO segnalare con precisione la presenza o l'assenza di sensori secondo la
classe android.content.pm.PackageManager. [Resources, 37]
DEVE restituire un elenco preciso di sensori supportati tramite
SensorManager.getSensorList() e metodi simili
DEVE comportarsi in modo ragionevole per tutte le altre API di sensori (ad esempio, restituire true
o false a seconda dei casi quando le applicazioni provano a registrare gli ascoltatori, non chiamare
gli ascoltatori di sensori quando i sensori corrispondenti non sono presenti; ecc.)
DEVE registrare tutte le misurazioni del sensore utilizzando i valori del Sistema internazionale di unità
(ovvero metrico) pertinenti per ogni tipo di sensore come definito nella documentazione dell'SDK Android
[Risorse, 41]
L'elenco sopra non è esauriente; il comportamento documentato dell'SDK Android è
da considerare autorevole.
Alcuni tipi di sensori sono sintetici, il che significa che possono essere derivati dai dati forniti da uno o più altri sensori.
(ad esempio il sensore di orientamento e il sensore di accelerazione lineare).
Le implementazioni del dispositivo DEVONO implementare questi tipi di sensori
, se includono i sensori fisici prerequisiti.
Le API Android 4.1 introducono il concetto di sensore "in streaming", ovvero un sensore che restituisce i dati in modo continuo, anziché solo quando i dati cambiano.
Le implementazioni del dispositivo DEVONO fornire continuamente campioni di dati periodici per qualsiasi API
indicata dalla documentazione dell'SDK Android 4.1 come sensore in streaming.

7.3.1. Accelerometro
Le implementazioni del dispositivo DEVONO includere un accelerometro a 3 assi. Se l'implementazione di un dispositivo
include un accelerometro a tre assi, deve:
DEVE essere in grado di generare eventi a 120 Hz o più. Tieni presente che, anche se la
frequenza dell'accelerometro indicata sopra è indicata come "DEVE" per Android 4.1, è in programma modificare queste informazioni nella
definizione di compatibilità per una versione futura in
"DEVE". In altre parole, questi standard sono facoltative in Android 4.1, ma saranno
obbligatori nelle versioni future. I dispositivi esistenti e nuovi che eseguono Android 4.1 sono
vivamente incoraggiati a soddisfare questi requisiti in Android 4.1 in modo da
essere in grado di eseguire l'upgrade alle versioni future della piattaforma
DEVONO essere conformi al sistema di coordinate del sensore Android come descritto nelle
API Android (vedi [Risorse, 41])
DEVONO essere in grado di misurare dall'accelerazione libera fino al doppio della gravità (2g) o più su
qualsiasi vettore tridimensionale
DEVONO avere una precisione di 8 bit o più
DEVONO avere una deviazione standard non superiore a 0,05 m/s^2
7.3.2. Magnetometro
Le implementazioni del dispositivo DEVONO includere un magnetometro a 3 assi (ad es. bussola). Se un
dispositivo include un magnetometro a tre assi, deve:
DEVE essere in grado di generare eventi a 10 Hz o più
DEVE essere conforme al sistema di coordinate del sensore Android come descritto nelle
API Android (vedi [Risorse, 41]).
DEVE essere in grado di campionare un intervallo di intensità di campo adeguato a coprire il
campo geomagnetico
DEVE avere 8 bit di precisione o piùe
DEVE avere una deviazione standard non superiore a 0,5 µT
7.3.3. GPS
Le implementazioni del dispositivo DEVONO includere un ricevitore GPS. Se l'implementazione di un dispositivo
include un ricevitore GPS, DEVE includere una forma di tecnica "GPS assistito"
per minimizzare il tempo di aggancio del GPS.
7.3.4. Giroscopio
Le implementazioni del dispositivo DEVONO includere un giroscopio (ovvero un sensore di variazione angolare).
I dispositivi NON DEVONO includere un sensore di giroscopio a meno che non sia incluso anche un accelerometro a 3 assi.
Se l'implementazione di un dispositivo include un giroscopio, deve:

ESSERE compensato in funzione della temperatura
DEVE essere in grado di misurare le variazioni dell'orientamento fino a 5,5*Pi
radianti/secondo (ovvero circa 1000 gradi al secondo)
DEVE essere in grado di generare eventi a 200 Hz o più. Tieni presente che, anche se la
frequenza del giroscopio indicata sopra è indicata come "DEVE" per Android 4.1, è in programma modificare queste informazioni nella
definizione di compatibilità per una versione futura in
"DEVE". In altre parole, questi standard sono facoltative in Android 4.1, ma saranno
obbligatori nelle versioni future. I dispositivi esistenti e nuovi che eseguono Android 4.1 sono
vivamente incoraggiati a soddisfare questi requisiti in Android 4.1 in modo da
essere in grado di eseguire l'upgrade alle future release della piattaforma
DEVONO avere una precisione di 12 bit o superiore
DEVONO avere una varianza non superiore a 1e-7 rad^2 / s^2 per Hz (varianza per Hz,
o rad^2 / s). La varianza è consentita di variare con la frequenza di campionamento, ma deve essere
limitata da questo valore. In altre parole, se misurate la varianza del giroscopio
a una frequenza di campionamento di 1 Hz, questa non deve essere superiore a 1e-7 rad^2/s^2.
DEVE avere timestamp il più possibile vicino al momento in cui è avvenuto l'evento hardware.
La latenza costante deve essere rimuovere.
7.3.5. Barometro
Le implementazioni del dispositivo POSSONO includere un barometro (ovvero un sensore di pressione dell'aria ambientale). Se
l'implementazione di un dispositivo include un barometro, deve:
DEVE essere in grado di generare eventi a 5 Hz o più
DEVE avere una precisione adeguata per consentire la stima dell'altitudine
DEVE essere compensato in funzione della temperatura
7.3.7. Termometro
Le implementazioni del dispositivo POSSONO, ma NON DEVONO includere un termometro (ovvero un sensore di temperatura).
Se l'implementazione di un dispositivo include un termometro, DEVE
misurare la temperatura della CPU del dispositivo. NON DEVE misurare alcuna
altra temperatura. (Tieni presente che questo tipo di sensore è deprecato nelle API Android 4.1).
7.3.7. Fotometro
Le implementazioni del dispositivo POSSONO includere un fotometro (ad es. sensore della luce ambientale).
7.3.8. Sensore di prossimità
Le implementazioni del dispositivo POSSONO includere un sensore di prossimità. Se un'implementazione del dispositivo
include un sensore di prossimità, DEVE misurare la prossimità di un oggetto nella
stessa direzione dello schermo. In altre parole, il sensore di prossimità DEVE essere orientato per rilevare
oggetti vicino allo schermo, poiché lo scopo principale di questo tipo di sensore è rilevare un
smartphone in uso dall'utente. Se un'implementazione del dispositivo include un sensore di prossimità con
qualsiasi altro orientamento, NON DEVE essere accessibile tramite questa API. Se un'implementazione del dispositivo
ha un sensore di prossimità, DEVE avere una precisione di 1 bit o più.
7.4. Connettività dei dati
7.4.1. Telefonia
"Telefonia" come utilizzata dalle API Android 4.1 e da questo documento si riferiscono specificamente a
hardware relativo a chiamate vocali e all'invio di messaggi SMS tramite una rete GSM o
CDMA. Sebbene queste chiamate vocali possano o meno essere a commutazione di paccheti, per Android 4.1 sono
considerate indipendenti da qualsiasi connettività di dati che
può essere implementata utilizzando la stessa rete. In altre parole, le funzionalità e le API
"telefonia" di Android si riferiscono specificamente alle chiamate vocali e agli SMS; ad esempio, le implementazioni
del dispositivo che non possono effettuare chiamate o inviare/ricevere messaggi SMS NON DEVONO
segnalare la funzionalità "android.hardware.telephony" o qualsiasi funzionalità secondaria, indipendentemente dal fatto che utilizzino o meno una rete cellulare per la connettività dei dati.

Android 4.1 PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. In altre parole,
Android 4.1 è compatibile con dispositivi che non sono smartphone. Tuttavia, se l'implementazione di un dispositivo include la telefonia GSM o CDMA, DEVE implementare un supporto completo
per l'API per questa tecnologia.
Le implementazioni di dispositivi che non includono hardware
di telefonia DEVONO implementare le API complete come no-op.
7.4.2. IEEE 802.11 (Wi-Fi)
Le implementazioni dei dispositivi Android 4.1 DEVONO includere il supporto di una o più forme
di 802.11 (b/g/a/n e così via) Se un'implementazione del dispositivo include il supporto per 802.11, deve
implementare l'API Android corrispondente.

Le implementazioni del dispositivo DEVONO implementare l'API multicast come descritto nella documentazione dell'SDK
[Risorse, 62]. Leimplementazioni di dispositivi che includono il supporto del Wi-Fi
DEVONO supportare il DNS multicast (mDNS). Le implementazioni del dispositivo NON devono filtrare i pacchetti mDNS
(224.0.0.251) in nessun momento di funzionamento, anche quando lo schermo non è in uno
stato attivo.
7.4.2.1. Wi-Fi Direct
Le implementazioni del dispositivo DEVONO includere il supporto per Wi-Fi Direct (Wi-Fi peer-to-peer). Se
un'implementazione del dispositivo include il supporto per Wi-Fi Direct, DEVE implementare l'
API Android corrispondente come descritto nella documentazione dell'SDK [Risorse, 68]. Se
l'implementazione di un dispositivo include il supporto per il Wi-Fi Direct, allora esso:
DEVE supportare il funzionamento regolare del Wi-Fi
DEVE supportare il funzionamento contemporaneo del Wi-Fi e del Wi-Fi Direct
7.4.3. Bluetooth
Le implementazioni del dispositivo DEVONO includere un trasmettitore/ricevitore Bluetooth. Le implementazioni del dispositivo che includono un trasmettitore Bluetooth DEVONO abilitare l'API Bluetooth basata su RFCOMM come descritto nella documentazione dell'SDK [Risorse, 42].

Le implementazioni
del dispositivo DEVONO implementare profili Bluetooth pertinenti, ad esempio A2DP,
AVRCP, OBEX e così via, in base alle esigenze del dispositivo.
La Compatibility Test Suite include casi che coprono il funzionamento di base dell'API Bluetooth
RFCOMM di Android. Tuttavia, poiché il Bluetooth è un protocollo di comunicazione
tra dispositivi, non può essere testato completamente da test di unità eseguiti su un singolo dispositivo.
Di conseguenza, le implementazioni del dispositivo DEVONO superare anche la procedura di test del Bluetooth
guidata dall'uomo descritta nell'appendice A.
7.4.4. Near-Field Communications
Le implementazioni del dispositivo DEVONO includere un trasmettitore e l'hardware correlato per
Near-Field Communications (NFC). Se un'implementazione del dispositivo include hardware NFC,
deve:
OBBLIGATORIAMENTE segnalare la funzionalità android.hardware.nfc dal
metodo android.content.pm.PackageManager.hasSystemFeature()
[Risorse, 37]
DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC:

Tieni presente che, anche se gli standard NFC di seguito sono indicati come
"DA" per Android 4.1, è previsto di modificarli in
"DEVE" per una versione futura. In altre parole, questi standard sono facoltative in
Android 4.1 ma saranno obbligatori nelle versioni future. È vivamente consigliato ai dispositivi esistenti e nuovi
che eseguono Android 4.1 di soddisfare questi
requisiti in Android 4.1 in modo da poter eseguire l'upgrade alle future
release della piattaforma.
NfcV (ISO 15693)
DEVE essere in grado di trasmettere e ricevere dati tramite i seguenti standard e protocolli peer-to-
peer:
ISO 18092
LLCP 1.0 (definito dal NFC Forum)
SDP 1.0 (definito dal NFC Forum)
NDEF Push Protocol [Risorse, 43]
SNEP 1.0 (definito dal NFC Forum)
DEVE includere il supporto per Android Beam [Risorse, 65]:
DEVE implementare il server SNEP predefinito. I messaggi NDEF validi
ricevuti dal server SNEP predefinito DEVONO essere inviati alle applicazioni
utilizzando l'intent android.nfc.ACTION_NDEF_DISCOVERED. La disattivazione di
Android Beam nelle impostazioni NON DEVE disattivare l'invio di messaggi NDEF
in entrata.
Le implementazioni del dispositivo DEVONO rispettare l'intent
android.settings.NFCSHARING_SETTINGS per mostrare le impostazioni di condivisione NFC

[Resources, 67].
DEVONO implementare il server NPP. I messaggi ricevuti dal server NPP
DEVONO essere elaborate nello stesso modo del server SNEP predefinito.
DEVONO implementare un client SNEP e tentare di inviare NDEF P2P in uscita
al server SNEP predefinito quando Android Beam è abilitato. Se non viene rilevato nessun server
SNEP predefinito, il client DEVE tentare di inviare a un server
NPP.
DEVE consentire alle attività in primo piano di impostare il messaggio NDEF P2P in uscita
utilizzando android.nfc.NfcAdapter.setNdefPushMessage, e
android.nfc.NfcAdapter.setNdefPushMessageCal back, e
android.nfc.NfcAdapter.enableForegroundNdefPush.
DEVE utilizzare un gesto o una conferma sulla schermata, ad esempio "Tocca per
trasferire", prima di inviare messaggi NDEF P2P in uscita.
DEVE abilitare Android Beam per impostazione predefinita
DEVE supportare il trasferimento della connessione NFC a Bluetooth quando il dispositivo
supporta il profilo Push di oggetti Bluetooth. Le implementazioni del dispositivo devono
supportare il transfertibilità della connessione al Bluetooth quando si utilizza
android.nfc.NfcAdapter.setBeamPushUris, implementando le specifiche
"Connection Handover version 1.2" [Risorse, 60] e "Bluetooth Secure
Simple Pairing Using NFC version 1.0" [Risorse, 61] del
NFC Forum. Una siffatta implementazione DOVE utilizzare richieste SNEP GET
per lo scambio della richiesta di trasferimento / selezionare record tramite NFC e DOV
E utilizzare il profilo Bluetooth Object Push per il trasferimento effettivo dei dati Bluetooth
.
DEVE cercare tutte le tecnologie supportate mentre è in modalità di ricerca NFC.
DEVE essere in modalità di ricerca NFC mentre il dispositivo è attivo con lo schermo
attivo e la schermata di blocco sbloccata.
(Tieni presente che i link disponibili pubblicamente non sono disponibili per le specifiche JIS, ISO e NFC Forum
citate sopra.)
Inoltre, le implementazioni dei dispositivi POSSONO includere il supporto di lettori/scrittori per le seguenti tecnologie MIFARE.

MIFARE Classic (NXP MF1S503x [Risorse, 44], MF1S703x [Risorse, 44])
MIFARE Ultralight (NXP MF0ICU1 [Risorse, 46], MF0ICU2 [Risorse, 46])
NDEF su MIFARE Classic (NXP AN130511 [Risorse, 48], AN130411
[Risorse, 49])
Tieni preno che Android 4.1 include API per questi tipi di MIFARE. Se l'implementazione di un dispositivo supporta MIFARE nel ruolo di lettore/scrittore, deve:
OBBLIGATORIAMENTE implementare le API Android corrispondenti come documentato dall'
SDK Android
OBBLIGATORIAMENTE segnalare la funzionalità com.nxp.mifare dal
metodo android.content.pm.PackageManager.hasSystemFeature()
.
[Resources, 37] Tieni presente che questa non è una funzionalità standard di Android e come tale
non viene mostrata come una costante nella classe PackageManager.
NON DEVI implementare le API Android corrispondenti né segnalare la funzionalità
com.nxp.mifare a meno che non implementi anche il supporto NFC generale come descritto in questa sezione
Se un'implementazione del dispositivo non include hardware NFC, NON DEVI dichiarare la funzionalità
android.hardware.nfc dal metodo
android.content.pm.PackageManager.hasSystemFeature() [Resources, 37],
e DEVI implementare l'API NFC di Android 4.1 come un'operazione non effettiva.
Poiché le classi android.nfc.NdefMessage e android.nfc.NdefRecord r epresentano un formato di rappresentazione dei dati indipendente dal protocollo, le implementazioni del dispositivo DEVONO
implementare queste API anche se non includono il supporto per NFC o non dichiarano la funzionalità
android.hardware.nfc.

7.4.5. Capacità di rete minima
Le implementazioni del dispositivo DEVONO includere il supporto per una o più forme di networking
dei dati. In particolare, le implementazioni del dispositivo DEVONO includere il supporto di almeno uno
standard di dati in grado di supportare 200 Kbit/sec o più. Esempi di tecnologiche che
soddisfano questo requisito includono EDGE, HSPA, EV-DO, 802.11g, Ethernet e così via.
Le implementazioni di dispositivi in cui uno standard di networking fisico (ad esempio Ethernet) è
la connessione di dati principale DEVONO includere anche il supporto per almeno uno standard di dati
wireless comune, ad esempio 802.11 (Wi-Fi).
I dispositivi POSSONO implementare più di una forma di connettività dei dati.

7.5. Fotocamere
Le implementazioni del dispositivo DEVONO includere una fotocamera posteriore e POSSONO includere una
fotocamera anteriore. Una fotocamera posteriore è una fotocamera posizionata sul lato del
dispositivo opposto al display; ovvero, fotografa le scene sul lato più lontano del dispositivo, come
una fotocamera tradizionale. Una fotocamera anteriore è una fotocamera posizionata sullo stesso lato del
dispositivo del display; ovvero, una fotocamera tipicamente utilizzata per fotografare l'utente, ad esempio per
videoconferenze e applicazioni simili.
7.5.1. Fotocamera posteriore
Le implementazioni del dispositivo DEVONO includere una fotocamera posteriore. Se l'implementazione di un dispositivo include una fotocamera posteriore, questo:
DEVE avere una risoluzione di almeno 2 megapixel
DEVE avere l'autofocus hardware o l'autofocus software implementato
nel driver della fotocamera (trasparente al software dell'applicazione)
PUÒ avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa)
PUÒ includere un flash.
Se la fotocamera include un flash, la lampada del flash NON DEVE essere
accesa mentre è stata registrata un'istanza android.hardware.Camera.PreviewCal di retroilluminazione su una superficie di anteprima della fotocamera, a meno che l'applicazione non abbia esplicitamente
attivato il flash attivando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON
di un oggetto Camera.Parameters.
Tieni presente che questo vincolo non si applica all'
applicazione della fotocamera di sistema incorporata del dispositivo, ma solo alle applicazioni di terze parti
che utilizzano Camera.PreviewCallback.
7.5.2. Fotocamera anteriore
Le implementazioni del dispositivo POSSONO includere una fotocamera anteriore. Se un'implementazione del dispositivo
include una fotocamera anteriore, deve:
DEVE avere una risoluzione di almeno VGA (ovvero 640x480 pixel)
NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Camera. In altre parole, l'
API camera in Android 4.1 supporta specificamente le fotocamere anteriori e le implementazioni del dispositivo NON DEVONO configurare l'API per trattare una fotocamera anteriore come la fotocamera posteriore predefinita, anche se è l'unica fotocamera sul
dispositivo.
POSSONO includere funzionalità (ad esempio autofocus, flash e così via) disponibili per le fotocamere posteriori
come descritto nella Sezione 7.5.1.
DEVONO rispecchiare orizzontalmente (ovvero riflettere) lo stream visualizzato da un'app in una
anteprima della fotocamera, come segue:
Se l'implementazione del dispositivo è in grado di essere ruotata dall'utente (ad esempio
automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente), l'anteprima della fotocamera DEVE essere riflettuta orizzontalmente rispetto all'orientamento attuale del dispositivo.
Se l'applicazione corrente ha richiesto esplicitamente di ruotare il display della fotocamera tramite una chiamata al metodo
android.hardware.Camera.setDisplayOrientation() [Risorse, 50]
, l'anteprima della fotocamera DEVE essere riflettuta orizzontalmente rispetto all'orientamento specificato dall'applicazione.
In caso contrario, l'anteprima DEVE essere riflettuta lungo l'asse orizzontale predefinito del dispositivo.

DEVE riprodurre l'immagine mostrata dal postview nello stesso modo in cui lo fa lo stream di immagini dell'anteprima della fotocamera.
(Se l'implementazione del dispositivo non supporta
postview, questo requisito ovviamente non si applica.)
NON DEVE riprodurre l'immagine stil o gli stream video finali acquisiti e restituito a
call back dell'applicazione o committati allo stoccaggio di contenuti multimediali
7.5.3. Comportamento dell'API camera
Le implementazioni del dispositivo DEVONO implementare i seguenti comportamenti per le API relative alla fotocamera, sia per le fotocamere anteriori che per quelle posteriori:
1.
  Se un'applicazione non ha mai chiamato
android.hardware.Camera.Parameters.setPreviewFormat(int), il
dispositivo DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati

��
2.  Se un'applicazione registra un'istanza android.hardware.Camera.PreviewCallback
e il sistema chiama il metodo onPreviewFrame() quando il formato
di anteprima è YCbCr_420_SP, i dati in byte[] trasmessi a onPreviewFrame()
devono essere inoltre nel formato di codifica NV21. In altre parole, NV21 DEVE essere il valore predefinito.
3.  Le implementazioni del dispositivo DEVONO supportare il formato YV12 (come indicato dalla

costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia per le
fotocamere anteriori che per quelle posteriori. (Il decoder video hardware e la videocamera possono
utilizzare qualsiasi formato di pixel nativo, ma l'implementazione del dispositivo DEVE supportare
la conversione in YV12.)
Le implementazioni del dispositivo DEVONO implementare l'API Camera completa inclusa nella documentazione dell'SDK Android
4.1 [Resources, 51]), indipendentemente dal fatto che il dispositivo includa
l'autofocus hardware o altre funzionalità. Ad esempio, le videocamere che non hanno la messa a fuoco automatica
DEVONO ancora chiamare qualsiasi istanza di android.hardware.Camera.AutoFocusCallback
registrata (anche se questo non ha rilevanza per una videocamera senza messa a fuoco automatica.) Tieni presente che
questo si applica alle fotocamere anteriori; ad esempio, anche se la maggior parte delle fotocamere
anteriori non supporta l'autofocus, le API cal back devono ancora essere "falsificate" come
descritto.
Le implementazioni del dispositivo DEVONO riconoscere e rispettare ogni nome di parametro definito come
una costante nella classe android.hardware.Camera.Parameters, se l'hardware
di base supporta la funzionalità. Se l'hardware del dispositivo non supporta una funzionalità, l'
API deve comportarsi come documentato. Al contrario, le implementazioni del dispositivo NON DEVONO
onorare o riconoscere costanti di stringa trasmesse al
metodo android.hardware.Camera.setParameters() diverso da quelle documentate come
costanti su android.hardware.Camera.Parameters. In altre parole, le implementazioni del dispositivo DEVONO supportare tutti i parametri standard della fotocamera se l'hardware lo consente e NON DEVONO supportare tipi di parametri della fotocamera personalizzati.

Le implementazioni del dispositivo DEVONO trasmettere l'intent Camera.ACTION_NEW_PICTURE
ogni volta che viene scattata una nuova foto dalla fotocamera e la voce della foto è stata
aggiunta al media store.
Le implementazioni del dispositivo DEVONO trasmettere l'intent Camera.ACTION_NEW_VIDEO
ogni volta che un nuovo video viene registrato dalla videocamera e la voce della foto è stata
aggiunta al media store.
7.5.4. Orientamento della fotocamera
Entrambe le fotocamere anteriori e posteriori, se presenti, DEVONO essere orientate in modo che la dimensione
lunga della fotocamera sia in linea con la dimensione lunga dello schermo. In altre parole, quando il
dispositivo è tenuto in orientamento orizzontale, le fotocamere DEVONO acquisire immagini in
orientamento orizzontale. Questo si applica indipendentemente dall'orientamento naturale del dispositivo; ovvero
si applica ai dispositivi con orientamento principale orizzontale e verticale.
7.6. Memoria e spazio di archiviazione
7.6.1. Memoria e spazio di archiviazione minimi
Le implementazioni del dispositivo DEVONO avere almeno 340 MB di memoria disponibile per il kernel
e lo spazio utente. I 340 MB DEVONO essere oltre a qualsiasi memoria dedicata ai
componenti hardware come radio, video e così via che non sono sotto il controllo del
kernel.
Le implementazioni del dispositivo DEVONO avere almeno 350 MB di spazio di archiviazione non volatile disponibile
per i dati privati dell'applicazione. In altri termini, la partizione /data DEVE avere almeno 350 MB.
Le API Android includono un gestore dei download che le applicazioni possono utilizzare per scaricare i file di dati [Risorse, 56].
L'implementazione del gestore download sul dispositivo
DEVE essere in grado di scaricare singoli file di almeno 100 MB nella posizione della
"cache" predefinita.
7.6.2. Spazio di archiviazione condiviso per le applicazioni
Le implementazioni dei dispositivi DEVONO offrire spazio di archiviazione condiviso per le applicazioni. Lo spazio di archiviazione
in condivisione fornito DEVE avere una dimensione di almeno 1 GB.
Le implementazioni dei dispositivi DEVONO essere configurate con lo spazio di archiviazione condiviso montato per impostazione predefinita,
"out of the box". Se lo spazio di archiviazione condiviso non è montato sul percorso Linux /sdcard, allora
il dispositivo DEVE includere un link simbolico Linux da /sdcard al punto di montaggio effettivo.
Le implementazioni del dispositivo DEVONO applicare l'autorizzazione
android.permission.WRITE_EXTERNAL_STORAGE su questo spazio di archiviazione condiviso.
In caso contrario, lo spazio di archiviazione condiviso DEVE essere scrivibile da qualsiasi applicazione che ottenga l'autorizzazione
.
Le implementazioni del dispositivo POSSONO avere hardware per lo spazio di archiviazione rimovibile accessibile all'utente,
ad esempio una scheda Secure Digital. In alternativa, le implementazioni del dispositivo POSSONO allocare la
memoria interna (non removibile) come spazio di archiviazione condiviso per le app.

Indipendentemente dalla forma di archiviazione condivisa utilizzata, le implementazioni del dispositivo DEVONO
fornire un meccanismo per accedere ai contenuti dell'archiviazione condivisa da un computer
host, ad esempio come USB mass storage (UMS) o Media Transfer Protocol (MTP).
Le implementazioni del dispositivo POSSONO utilizzare USB mass storage, ma DEVONO utilizzare Media
Transfer Protocol. Se l'implementazione del dispositivo supporta il protocollo MTP:
L'implementazione del dispositivo DEVE essere compatibile con l'host MTP Android di riferimento, Android File Transfer [Resources, 57].
L'implementazione del dispositivo DEVE indicare una classe di dispositivo USB di 0x00.
L'implementazione del dispositivo DEVE indicare un nome dell'interfaccia USB di 'MTP'.

Se l'implementazione del dispositivo non dispone di porte USB, DEVE fornire a un computer host l'
accesso ai contenuti della memoria condivisa con altri mezzi, ad esempio un sistema di file
di rete.
Per illustrare il concetto, consideriamo due esempi comuni. Se un'implementazione del dispositivo include
uno slot per schede SD per soddisfare il requisito di spazio di archiviazione condiviso, una scheda SD formattata FAT
di dimensioni pari o superiori a 1 GB DEVE essere inclusa con il dispositivo come venduto agli utenti e DEVE
essere montata per impostazione predefinita. In alternativa, se un'implementazione del dispositivo utilizza spazio di archiviazione
interno fisso per soddisfare questo requisito, questo spazio di archiviazione DEVE avere una dimensione di 1 GB o superiore e essere
montato su /sdcard (o /sdcard DEVE essere un link simbolico alla posizione fisica se è
montato altrove.)
Le implementazioni del dispositivo che includono più percorsi di archiviazione condivisa (ad esempio sia uno
slot per schede SD sia la memoria interna condivisa) DEVONO modificare le applicazioni di base come
lo scanner di contenuti multimediali e ContentProvider per supportare in modo trasparente i file posizionati in entrambe
le posizioni.
7.7. Le implementazioni di dispositivi USB
DEVONO includere una porta client USB e DEVONO includere una porta host USB.

Se l'implementazione di un dispositivo include una porta client USB:
la porta DEVE essere collegabile a un host USB con una porta USB-A standard
la porta DEVE utilizzare il fattore di forma micro USB sul lato del dispositivo. È vivamente consigliato ai dispositivi esistenti
e nuovi che eseguono Android 4.1 di soddisfare
questi requisiti in Android 4.1 in modo da poter eseguire l'upgrade alle future
release della piattaforma
la porta DEVE essere allineata al centro di un bordo. Le implementazioni del dispositivo
DEVONO posizionare la porta nella parte inferiore del dispositivo (in base all'orientamento
naturale) o attivare la rotazione sullo schermo software per tutte le app (inclusa la schermata
Home), in modo che il display venga disegnato correttamente quando il dispositivo è orientato con la
porta in basso. I dispositivi esistenti e nuovi che eseguono Android 4.1 sono vivamente
incoraggiati a soddisfare questi requisiti in Android 4.1 in modo da essere in grado
di eseguire l'upgrade alle versioni future della piattaforma.
se il dispositivo ha altre porte (ad esempio una porta di ricarica non USB) DEVE trovarsi
sulla stessa parte del dispositivo della porta micro-USB
DEVE consentire a un host collegato al dispositivo di accedere ai contenuti del
volume dell'unità di archiviazione di massa USB o del protocollo di trasferimento
di supporto
DEVE implementare l'API e la specifica Android Open Accessory come
documentato nella documentazione dell'SDK Android, e DEVE dichiarare il supporto per
la funzionalità hardware android.hardware.usb.accessory [Risorse, 52]
DEVE implementare la classe audio USB come documentato nella documentazione dell'SDK Android
[Risorse, 66]
DEVE implementare il supporto per la specifica di ricarica della batteria USB
[Risorse, 64] I dispositivi esistenti e nuovi che eseguono Android 4.1 sono vivamente
incoraggiati a soddisfare questi requisiti in Android 4.1 in modo da essere in grado
di eseguire l'upgrade alle versioni future della piattaforma
Se un'implementazione del dispositivo include una porta host USB:
PUÒ utilizzare un fattore di forma della porta non standard, ma in questo caso DEVE essere fornito con un cavo o
cavi che adattano la porta a USB-A standard
DEVE implementare l'API host USB Android come documentato nell'SDK Android, e DEVE dichiarare il supporto per la funzionalità hardware
android.hardware.usb.host [Risorse, 53]
Le implementazioni del dispositivo DEVONO implementare Android Debug Bridge.
Se l'implementazione di un dispositivo
omessa una porta client USB, DEVE implementare Android Debug Bridge
tramite una rete locale (ad esempio Ethernet o 802.11)

8. Compatibilità con le prestazioni
Le implementazioni del dispositivo DEVONO soddisfare le metriche di prestazioni chiave di un dispositivo Android 4.1
compatibile definite nella tabella che segue:
Metrica
Soglia di prestazioni
Commenti
Le seguenti applicazioni
devono essere avviate entro il tempo specificato.

Il tempo di avvio viene misurato come
tempo totale per completare il caricamento del
Browser: meno di
attività predefinita per l'applicazione,
Applicazione
1300 ms
incluso il tempo necessario per avviare il
Tempo di avvio
Contatti: meno di
processo Linux, carica il pacchetto Android
700 ms
nella VM Dalvik e cal
Impostazioni: meno di
onCreate.
700 ms
Quando sono state avviate più applicazioni, il
riavvio di un'applicazione già
in esecuzione
simultanea
dopo l'avvio

delle
applicazioni
deve
richiedere meno tempo rispetto al
tempo di avvio
originale.
9. Compatibilità del modello di sicurezza
Le implementazioni del dispositivo DEVONO implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android
come definito nel documento di riferimento Sicurezza e autorizzazioni nelle
API [Risorse, 54] 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 terze parti/autorità.
In particolare, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle
seguenti sottosezioni.
9.1. Autorizzazioni
Le implementazioni del dispositivo DEVONO supportare il modello di autorizzazioni Android come definito nella
documentazione per sviluppatori Android [Risorse, 54]. In particolare, 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 nel nome spazio android.*
.
9.2. UID e isolamento del processo
Le implementazioni del dispositivo DEVONO supportare il modello sandbox delle app Android, in
cui ogni app viene eseguito come un UID in stile Unix unico e in un processo separato.
Le implementazioni del dispositivo DEVONO supportare l'esecuzione di più app come lo stesso
ID utente Linux, a condizione che le app siano firmate e costruite correttamente, come
definito nella documentazione di riferimento sulla sicurezza e sulle autorizzazioni [Risorse, 54].
9.3. Autorizzazioni file system
Le implementazioni del dispositivo DEVONO supportare il modello di autorizzazioni di accesso ai file di Android come
definito nel come definito nel documento di riferimento Sicurezza e autorizzazioni [Risorse, 54].
9.4. Ambienti di esecuzione alternativi
Le implementazioni del dispositivo POSSONO includere ambienti di runtime che eseguono applicazioni
utilizzando qualche altro software o tecnologia diverso dalla macchina virtuale Dalvik o dal codice
nativo. Tuttavia, questi ambienti di esecuzione alternativi NON DEVONO compromettere il
modello di sicurezza di Android o la sicurezza delle applicazioni Android installate, come descritto
in questa sezione.
I runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella Sezione 9.

Non è consentito concedere accesso alle risorse protette da

autorizzazioni non richieste nel file AndroidManifest.xml del runtime tramite il meccanismo <uses-

permission>.

I runtime alternativi NON DEVONO consentire alle app di utilizzare le funzionalità protette
dall'autorizzazione Android limitata alle app di sistema.
I runtime alternativi DEVONO rispettare il modello di sandbox Android. Nello specifico:
I runtime alternativi DEVONO installare le app tramite PackageManager in sandbox Android separate (ovvero ID utente Linux e così via)
I runtime alternativi POSSONO fornire una singola sandbox Android condivisa da tutte le app che utilizzano il runtime alternativo
I runtime alternativi e le app installate che utilizzano un runtime alternativo NON DEVONO riutilizzare la sandbox di nessuna altra app installata sul dispositivo, tranne tramite i meccanismi standard di Android per ID utente condivisi e per i certificati di firma
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre app Android
I
I file .apk di runtime alternative POSSONO essere inclusi nell'immagine di sistema di un'implementazione
del dispositivo, ma DEVONO essere firmati con una chiave diversa da quella utilizzata per firmare altre
applicazioni incluse nell'implementazione del dispositivo.
Durante l'installazione delle app, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni
Android utilizzate dall'app. In altre parole, se un'applicazione ha bisogno di fare
uso di una risorsa del dispositivo per la quale esiste un'autorizzazione Android corrispondente (ad esempio
Fotocamera, GPS e così via), il runtime alternativo DEVE informare l'utente che l'applicazione
potrà accedere a questa risorsa. Se l'ambiente di runtime non registra
le funzionalità dell'applicazione in questo modo, l'ambiente di runtime DEVE elencare tutte le
autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che lo utilizza.
10. Test di compatibilità del software
Le implementazioni del dispositivo DEVONO superare i test descritti in questa sezione.
Tuttavia, tieni presente che nessun pacchetto di test del software è completo. Per questo motivo,
gli implementatori di dispositivi sono vivamente incoraggiati a apportare il minor numero possibile di
modifiche all'implementazione di riferimento e preferita di Android 4.1
disponibile dal progetto Android Open Source. In questo modo ridurrai al minimo il rischio di
introdurre bug che creano incompatibilità che richiedono la rielaborazione e potenziali aggiornamenti
del dispositivo.
10.1. Compatibility Test Suite
Le implementazioni del dispositivo DEVONO superare la suite di test di compatibilità Android (CTS)
[Risorse, 2] disponibile dal progetto open source Android, utilizzando il software di pubblicazione finale sul dispositivo.
Inoltre, gli implementatori di dispositivi DEVONO utilizzare il
codice di implementazione di riferimento nell'albero del codice open source di Android il più possibile e
DEVONO garantire la compatibilità in caso di ambiguità nel CTS e per qualsiasi
reimplementazione di parti del codice di origine di riferimento.
Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi software, il CTS potrebbe
contiene bug. Il CTS verrà versionato indipendentemente da questa definizione di compatibilità
e possono essere rilasciati più revisioni del CTS per Android 4.1. Le implementazioni del dispositivo
DEVONO superare la versione CTS più recente disponibile al momento del completamento del software del dispositivo
.
10.2. CTS Verifier
Le implementazioni del dispositivo DEVONO eseguire correttamente tutti i casi applicabili in CTS
Verifier. CTS Verifier è incluso in Compatibility Test Suite e è destinato
a essere eseguito da un operatore umano per testare funzionalità che non possono essere testate da un
sistema automatizzato, ad esempio il corretto funzionamento di una fotocamera e dei sensori.
CTS Verifier esegue test per molti tipi di hardware, incluso hardware facoltativo.
Le implementazioni del dispositivo DEVONO superare tutti i test per l'hardware di cui sono dotati.
Ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente il caso di test dell'accelerometro in CTS Verifier.
I casi di test per le funzionalità indicate
come facoltative da questo Documento di definizione della compatibilità POSSONO essere scolpiti o omessi.
Ogni dispositivo e ogni build DEVONO eseguire correttamente il CTS Verifier, come notato sopra.
Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori di dispositivi
eseguiscano esplicitamente il CTS Verifier su build che differiscono solo in modi banali. In particolare,
le implementazioni del dispositivo che si differenziano da un'implementazione che ha superato il CTS
Verifier solo per l'insieme di lingue, branding e così via inclusi POSSONO omettere il test CTS Verifier

.
10.3. Applicazioni di riferimento
Gli implementatori di dispositivi DEVONO testare la compatibilità dell'implementazione utilizzando le seguenti applicazioni open
source:
Le applicazioni "App per Android" [Resources, 55]
Replica Island (disponibile in Android Market)
Ogni app sopra DEVE avviarsi e comportarsi correttamente nell'implementazione per che l'
implementazione sia considerata compatibile.
11. Software aggiornabile
Le implementazioni del dispositivo DEVONO includere un meccanismo per sostituire l'intera
software di sistema. Il meccanismo non deve eseguire upgrade "in tempo reale", ovvero potrebbe essere necessario un
riavvio del dispositivo.
È possibile utilizzare qualsiasi metodo, a condizione che possa sostituire l'intero software
preinstallato sul dispositivo. Ad esempio, uno qualsiasi dei seguenti approcci soddisferà
questo requisito:
Download over-the-air (OTA) con aggiornamento offline tramite riavvio
Aggiornamenti "in modalità tethering" tramite USB da un PC host
Aggiornamenti "offline" tramite un riavvio e aggiornamento da un file su memoria rimovibile
Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza resettare i dati dell'utente. In altre parole,
il meccanismo di aggiornamento DEVE preservare i dati privati dell'applicazione e i dati
condivisi dell'applicazione. Tieni presente che il software Android upstream include un meccanismo di aggiornamento
che soddisfa questo requisito.
Se viene rilevato un errore nell'implementazione di un dispositivo dopo che è stato rilasciato, ma entro la sua
vita utile del prodotto ragionevole che viene determinata in consultazione con il team di
compatibilità di Android per influire sulla compatibilità delle applicazioni di terze parti, l'
implementatore del dispositivo DEVE correggere l'errore tramite un aggiornamento software disponibile che può essere
applicato secondo il meccanismo appena descritto.
12. Contattaci
Puoi contattare gli autori del documento all'indirizzo [email protected] per chiarimenti
e per segnalare eventuali problemi che ritieni non coperti dal documento.

Appendice A - Procedura di test Bluetooth
La Compatibility Test Suite include casi che coprono il funzionamento di base dell'API Bluetooth
RFCOMM di Android. Tuttavia, poiché il Bluetooth è un protocollo di comunicazione
tra dispositivi, non può essere testato completamente da test di unità eseguiti su un singolo dispositivo.
Di conseguenza, le implementazioni del dispositivo DEVONO superare anche la procedura di test del Bluetooth
guidata dall'utente descritta di seguito.
La procedura di test si basa sull'app di esempio BluetoothChat inclusa nell'albero del progetto open source Android.
La procedura richiede due dispositivi:
un'implementazione del dispositivo candidato che esegue la build del software da testare
un'implementazione del dispositivo separata già nota per essere compatibile e di un
modello dell'implementazione del dispositivo in test ovvero un'implementazione del dispositivo "noto
come buono"
La procedura di test che segue fa riferimento a questi dispositivi come rispettivamente dispositivi "candidato" e "noto
come buono".
Configurazione e installazione
1.  Crea BluetoothChat.apk tramite 'make samples' da un albero di codice sorgente Android
2.  Installa  BluetoothChat.apk sul dispositivo funzionante correttamente
3.  Installa  BluetoothChat.apk sul dispositivo candidato
Testa il controllo Bluetooth da parte delle app
1.  Avvia BluetoothChat sul dispositivo candidato, mentre il Bluetooth è disattivato
2.  Verifica che il dispositivo candidato attivi il Bluetooth o chieda all'utente
di attivare il Bluetooth
Testa l'accoppiamento e la comunicazione
1.  Avvia l'app Bluetooth Chat su entrambi i dispositivi
2.  Rendi rilevabile il dispositivo che funziona correttamente da BluetoothChat (utilizzando il
Menu)
3.  Sul dispositivo candidato, cerca i dispositivi Bluetooth da BluetoothChat
(utilizzando il menu) e accoppialo con il dispositivo funzionante
4.  Invia almeno 10 messaggi da ogni dispositivo e verifica che l'altro dispositivo
li riceva correttamente
5.  Chiudi l'app BluetoothChat su entrambi i dispositivi premendo Home
6.  Disaccoppia ogni dispositivo dall'altro utilizzando l'app Impostazioni del dispositivo
Testa l'accoppiamento e la comunicazione in senso contrario

1.  Avvia l'app Bluetooth Chat su entrambi i dispositivi.
2.  Rendi il dispositivo candidato rilevabile da BluetoothChat (utilizzando il
Menu).
3.  Sul dispositivo che funziona correttamente, cerca i dispositivi Bluetooth da BluetoothChat
(utilizzando il menu) e accoppia il dispositivo candidato.
4.  Invia 10 o più messaggi da ogni dispositivo e verifica che l'altro dispositivo
li riceva correttamente.
5.  Chiudi l'app Bluetooth Chat su entrambi i dispositivi premendo indietro più volte per
accedere all'avvio.
Testare i nuovi lanci
1.  Riavvia l'app Bluetooth Chat su entrambi i dispositivi.
2.  Invia 10 o più messaggi da ogni dispositivo e verifica che l'altro dispositivo
li riceva correttamente.
Nota: i test sopra presentano alcuni casi che terminano una sezione di test utilizzando Home e
alcuni utilizzando Indietro. Questi test non sono ridondanti e non sono facoltative: lo scopo è
verificare che l'API e lo stack Bluetooth funzionano correttamente sia quando le attività sono
terminate esplicitamente (tramite il tasto Indietro premuto dall'utente, che chiama finish()), sia quando vengono inviate implicitamente
in background (tramite il tasto Home premuto dall'utente). Ogni sequenza di test DEVE essere eseguito
come descritto.

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

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