1. Introduzione

Questo documento elenca i requisiti che devono essere soddisfatti affinché i dispositivi siano compatibili con Android 6.0.

L'uso di "DEVE", "NON DEVE", "OBBLIGATORIO", "DEVE", "NON DEVE", "DEVE", "NON DEVE", "CONSIGLIATO", "PUÒ" e "FACOLTATIVO" è conforme allo standard IETF definito in RFC2119 [Risorse, 1].

Come utilizzato in questo documento, un "implementatore di dispositivi" o "implementatore" è una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 6.0. Un'"implementazione del dispositivo" o "implementazione" è la soluzione hardware/software così sviluppata.

Per essere considerate compatibili con Android 6.0, le implementazioni dei dispositivi DEVONO soddisfare i requisiti presentati in questa definizione di compatibilità, inclusi eventuali documenti incorporati tramite riferimento.

Se questa definizione o i test software descritti nella sezione 10 non sono chiari, ambigui o incompleti, è responsabilità dell'implementatore del dispositivo garantire la compatibilità con le implementazioni esistenti.

Per questo motivo, Android Open Source Project [Risorse, 2] è sia l'implementazione di riferimento sia quella preferita di Android. È FORTEMENTE CONSIGLIATO agli implementatori di dispositivi di basare le proprie implementazioni, nella misura del possibile, sul codice sorgente "upstream" disponibile nell'Android Open Source Project. Anche se alcuni componenti possono essere sostituiti con implementazioni alternative, è FORTEMENTE CONSIGLIATO di non seguire questa pratica, poiché superare i test software diventerà notevolmente più difficile. È responsabilità dell'implementatore garantire la piena compatibilità comportamentale con l'implementazione standard di Android, inclusa e non limitata alla Compatibility Test Suite. Infine, tieni presente che alcune sostituzioni e modifiche dei componenti sono esplicitamente vietate da questo documento.

Molte delle risorse elencate nella sezione 14 sono ricavate direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni riportate nella documentazione dell'SDK. In tutti i casi in cui questa definizione di compatibilità o la suite di test di compatibilità non è in accordo con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Eventuali dettagli tecnici forniti nei riferimenti inclusi nella sezione 14 sono considerati parte di questa definizione di compatibilità.

2. Tipi di dispositivi

Sebbene il progetto open source Android sia stato utilizzato per l'implementazione di una varietà di tipi di dispositivi e fattori di forma, molti aspetti dell'architettura e dei requisiti di compatibilità sono stati ottimizzati per i dispositivi portatili. A partire da Android 5.0, l'Android Open Source Project mira a supportare una gamma più ampia di tipi di dispositivi, come descritto in questa sezione.

Per Dispositivo Android portatile si intende un'implementazione di un dispositivo Android che in genere viene utilizzato tenendolo in mano, ad esempio lettori MP3, telefoni e tablet. Implementazioni di dispositivi Android portatili:

• DEVE avere un touchscreen integrato nel dispositivo.
• DEVE avere una fonte di alimentazione che offra mobilità, ad esempio una batteria.

Per dispositivo Android TV si intende un'implementazione di un dispositivo Android che è un'interfaccia di intrattenimento per la fruizione di contenuti multimediali digitali, film, giochi, app e/o TV in diretta per gli utenti seduti a circa tre metri di distanza (un'interfaccia utente "lean back" o "10-foot"). Dispositivi Android TV:

• DEVE avere uno schermo incorporato OPPURE includere una porta di uscita video, ad esempio VGA, HDMI o una porta wireless per il display.
• DEVE dichiarare le funzionalità android.software.leanback e android.hardware.type.television [Risorse, 3].

Per dispositivo Android Watch si intende un'implementazione di un dispositivo Android progettata per essere indossata sul corpo, possibly sul polso, e:

• DEVE avere uno schermo con una diagonale fisica compresa tra 28 e 64 mm.
• DEVE dichiarare la funzionalità android.hardware.type.watch.
• DEVE supportare uiMode = UI_MODE_TYPE_WATCH [Risorse, 4].

L'implementazione di Android Automotive si riferisce a un'unità di controllo del veicolo che utilizza Android come sistema operativo per parte o per la totalità del sistema e/o delle funzionalità di infotainment. Implementazioni di Android Automotive:

• DEVE dichiarare la funzionalità android.hardware.type.automotive.
• DEVE supportare uiMode = UI_MODE_TYPE_CAR [Risorse, 5].

Tutte le implementazioni di dispositivi Android che non rientrano in nessuno dei tipi di dispositivi sopra indicati DEVONO comunque soddisfare tutti i requisiti di questo documento per essere compatibili con Android 6.0, a meno che il requisito non sia descritto esplicitamente come applicabile solo a un tipo di dispositivo Android specifico tra quelli sopra indicati.

2.1 Configurazioni del dispositivo

Questo è un riepilogo delle principali differenze nella configurazione hardware in base al tipo di dispositivo. (Le celle vuote indicano un valore "POTREBBE"). Non tutte le configurazioni sono coperte da questa tabella. Per maggiori dettagli, consulta le sezioni hardware pertinenti.

Categoria	Funzionalità	Sezione	A mano	Televisione	Guarda contenuti	Automotive	Altro
Input	D-pad	7.2.2. Navigazione non tocco		MUST
	Touchscreen	7.2.4. Input touchscreen	MUST		MUST		DOVREBBE
	Microfono	7.8.1. Microfono	MUST	DOVREBBE	MUST	MUST	DOVREBBE
Sensori	Accelerometro	7.3.1 Accelerometro	DOVREBBE		DOVREBBE		DOVREBBE
	GPS	7.3.3. GPS	DOVREBBE			DOVREBBE
Connettività	Wi-Fi	7.4.2. IEEE 802.11	DOVREBBE	MUST		DOVREBBE	DOVREBBE
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	DOVREBBE	DOVREBBE			DOVREBBE
	Bluetooth	7.4.3. Bluetooth	DOVREBBE	MUST	MUST	MUST	DOVREBBE
	Bluetooth Low Energy	7.4.3. Bluetooth	DOVREBBE	MUST	DOVREBBE	DOVREBBE	DOVREBBE
	Modalità periferica/host USB	7.7. USB	DOVREBBE			DOVREBBE	DOVREBBE
Output	Porte di uscita audio e/o altoparlanti	7.8.2. Uscita audio	MUST	MUST		MUST	MUST

3. Software

3.1. Compatibilità con le API gestite

L'ambiente di esecuzione del bytecode Dalvik gestito è il veicolo principale per le applicazioni Android. L'API (interfaccia di programmazione di un'applicazione) Android è l'insieme di interfacce della piattaforma Android esposte alle applicazioni in esecuzione nell'ambiente di runtime gestito. Le implementazioni dei dispositivi DEVONO fornire implementazioni complete, inclusi tutti i comportamenti documentati, di qualsiasi API documentata esposta dall'SDK Android [Risorse, 6] o di qualsiasi API decorata con l'indicatore "@SystemApi" nel codice sorgente Android upstream.

Le implementazioni dei dispositivi NON DEVONO omettere API gestite, modificare interfacce o firme dell'API, discostarsi dal comportamento documentato o includere no-op, tranne dove specificamente consentito da questa definizione di compatibilità.

Questa definizione di compatibilità consente di omettere alcune implementazioni di dispositivi per alcuni tipi di hardware per i quali Android include API. In questi casi, le API devono essere ancora presenti e comportarsi in modo ragionevole. Consulta la sezione 7 per i requisiti specifici di questo scenario.

3.2. Compatibilità API soft

Oltre alle API gestite della sezione 3.1, Android include anche un'API "soft" significativa solo per il runtime, 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 dei dispositivi DEVONO supportare e applicare tutte le costanti di autorizzazione come documentato nella pagina di riferimento delle autorizzazioni [Risorse, 7]. Tieni presente che la sezione 9 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, 8] che hanno lo scopo di descrivere il dispositivo corrente. Per fornire valori coerenti e significativi per tutte le implementazioni dei dispositivi, la tabella seguente include ulteriori limitazioni relative ai formati di questi valori a cui le implementazioni dei dispositivi DEVONO essere conformi.

Parametro	Dettagli
VERSION.RELEASE	La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE avere uno dei valori di stringa definiti in [Risorse, 9].
VERSION.SDK	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 6.0, questo campo DEVE avere il valore intero 23.
VERSION.SDK_INT	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 6.0, questo campo DEVE avere il valore intero 23.
VERSION.INCREMENTAL	Un valore scelto dall'implementatore del dispositivo che designa la build specifica del sistema Android attualmente in esecuzione, in formato leggibile. Questo valore NON deve essere riutilizzato per build diverse rese disponibili agli utenti finali. Un utilizzo tipico di questo campo è indicare il numero di build o l'identificatore della modifica del controllo del codice sorgente utilizzato per generare la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
DA TAVOLO	Un valore scelto dall'implementatore del dispositivo che identifica l'hardware interno specifico utilizzato dal dispositivo, in formato leggibile. Un possibile utilizzo di questo campo è indicare la revisione specifica della scheda che alimenta il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
BRAND	Un valore che riflette il nome del brand associato al dispositivo, come noto agli utenti finali. DEVE essere in un formato leggibile e DEVE rappresentare il produttore del dispositivo o il brand dell'azienda con cui viene commercializzato il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
SUPPORTED_32_BIT_ABIS	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
SUPPORTED_64_BIT_ABIS	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
CPU_ABI	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
CPU_ABI2	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
DISPOSITIVO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice che identifica la configurazione delle funzionalità hardware e il design industriale del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
FINGERPRINT	Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile da una persona. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ad esempio: acme/myproduct/     mydevice:6.0/LMYXX/3359:userdebug/test-keys L'impronta NON DEVE includere caratteri di spazio vuoto. Se altri campi inclusi nel modello riportato sopra contengono caratteri di spazi vuoti, DEVONO essere sostituiti nell'impronta della build con un altro carattere, ad esempio l'underscore ("_"). Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit.
HARDWARE	Il nome dell'hardware (dalla riga di comando del kernel o da /proc). DOVREBBE essere ragionevolmente leggibile da una persona. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
ORGANIZZATORE	Una stringa che identifica in modo univoco l'host su cui è stata eseguita la compilazione, in formato leggibile da un essere umano. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
ID	Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in formato leggibile da una persona. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere le build software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
PRODUTTORE	La ragione sociale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
MODELLO	Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo come conosciuto dall'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o una stringa vuota ("").
PRODOTTO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice del prodotto specifico (SKU) che DEVE essere univoco all'interno dello stesso marchio. DEVE essere leggibile, ma non necessariamente destinato alla visualizzazione da parte degli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
SERIALE	Un numero di serie hardware, che DEVE essere disponibile e univoco su tutti i dispositivi con lo stesso MODELLO e PRODUTTORE. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^([a-zA-Z0-9]{6,20})$".
TAG	Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che distingue ulteriormente la build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni di firma della piattaforma Android: release-keys, dev-keys, test-keys.
DURATA	Un valore che rappresenta il timestamp della compilazione.
MACCHINA	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 configurazioni di runtime Android: user, userdebug o eng.
UTENTE	Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
SECURITY_PATCH	Un valore che indica il livello della patch di sicurezza di una build. DEBBA indicare che la compilazione include tutte le patch di sicurezza rilasciate tramite il bollettino sulla sicurezza pubblico Android designato. DEVE essere nel formato [AAAA-MM-GG] e corrispondere a una delle stringhe del livello patch di sicurezza Android dei bollettini di sicurezza pubblici, ad esempio "01-11-2015".
BASE_OS	Un valore che rappresenta il parametro FINGERPRINT della build, che è altrimenti identico a questa build, ad eccezione delle patch fornite nel bollettino di sicurezza pubblico Android. DEVE riportare il valore corretto e, se una build di questo tipo non esiste, deve riportare una stringa vuota ("").

3.2.3. Compatibilità con gli intent

Le implementazioni dei dispositivi DEVONO rispettare il sistema di intent a disaccoppiamento flessibile 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 che si leghi e implementi il comportamento corretto per ogni pattern di intent specificato.

3.2.3.1. Intent di applicazione principali

Gli intent Android consentono ai componenti dell'applicazione di richiedere funzionalità da altri componenti Android. Il progetto upstream di Android include un elenco di applicazioni considerate applicazioni Android di base, che implementano diversi pattern di intent per eseguire azioni comuni. Le applicazioni Android di base sono:

• Orologio da scrivania
• Browser
• Calendar
• Contatti
• Galleria
• GlobalSearch
• Avvio app
• Musica
• Impostazioni

Le implementazioni dei dispositivi DOVREBBERO includere le applicazioni Android di base come appropriato, ma DEVONO includere un componente che implementi gli stessi pattern di intent definiti da tutti i componenti di attività o servizio "pubblici" di queste applicazioni Android di base. Tieni presente che i componenti Activity o Service sono considerati "pubblici" quando l'attributo android:exported è assente o ha il valore true.

3.2.3.2. Risoluzione dell'intent

Poiché Android è una piattaforma estensibile, le implementazioni dei dispositivi DEVONO consentire a ogni schema di intent a cui si fa riferimento nella sezione 3.2.3.1 di essere sostituito da applicazioni di terze parti. L'implementazione open source di Android upstream lo consente per impostazione predefinita; gli implementatori dei dispositivi NON DEVONO associare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema o impedire alle applicazioni di terze parti di associarsi a questi pattern e assumerne il controllo. Questo divieto include, in particolare, ma non è limitato a, la disattivazione dell'interfaccia utente "Chooser" che consente all'utente di scegliere tra più applicazioni che gestiscono tutte lo stesso pattern di intent.

Le implementazioni dei dispositivi DEVONO fornire un'interfaccia utente che consenta agli utenti di modificare l'attività predefinita per gli intent.

Tuttavia, le implementazioni dei dispositivi POSSONO fornire attività predefinite per pattern URI specifici (ad es. http://play.google.com) quando l'attività predefinita fornisce un attributo più specifico per l'URI dati. Ad esempio, un pattern del filtro per intent che specifica l'URI di dati "http://www.android.com" è più specifico del pattern di intent di base del browser per "http://".

Android include anche un meccanismo per consentire alle app di terze parti di dichiarare un comportamento autorevole per il collegamento delle app predefinite per determinati tipi di intent URI web [Risorse, 140]. Quando queste dichiarazioni autorevoli sono definite nei pattern dei filtri per intent di un'app, le implementazioni dei dispositivi:

• DEVE tentare di convalidare tutti i filtri intent eseguendo i passaggi di convalida definiti nella specifica Digital Asset Links [Risorse, 141] come implementati dal gestore pacchetti nel progetto open source Android upstream.
• DEVE tentare la convalida dei filtri per intent durante l'installazione dell'applicazione e impostare tutti i filtri per intent UIR convalidati correttamente come gestori di app predefiniti per le relative UIR.
• PUO' impostare filtri di intent URI specifici come gestori di app predefiniti per i propri URI, se vengono verificati correttamente, ma altri filtri URI candidati non superano la verifica. Se un'implementazione del dispositivo lo fa, DEVE fornire all'utente le sostituzioni dei pattern per URI appropriate nel menu delle impostazioni.
• DEVE fornire all'utente i controlli dei link dell'app per app nelle Impostazioni come segue:
  • L'utente DEVE essere in grado di sostituire in modo olistico il comportamento predefinito dei link alle app per un'app: sempre aperta, sempre chiedi o mai aperta, che deve essere applicata a tutti i candidati filtri intent URI in modo uguale.
  • L'utente DEVE essere in grado di visualizzare un elenco dei filtri di intent URI candidati.
  • L'implementazione del dispositivo PUÒ fornire all'utente la possibilità di ignorare filtri di intent URI candidati specifici che sono stati verificati correttamente, in base al filtro di intent.
  • L'implementazione del dispositivo DEVE fornire agli utenti la possibilità di visualizzare e ignorare filtri di intent URI candidati specifici se l'implementazione del dispositivo consente ad alcuni filtri di intent URI candidati di superare la verifica, mentre altri possono non riuscirci.

3.2.3.3. Spazi dei nomi degli intent

Le implementazioni dei dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o di trasmissione di intent utilizzando una stringa ACTION, CATEGORY o di altro tipo nell'ambito dello spazio dei nomi android.* o com.android.*. Gli implementatori di dispositivi NON devono includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando ACTION, CATEGORY o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione. Gli implementatori dei dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent utilizzati dalle app di base elencate nella sezione 3.2.3.1. Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano spazi dei nomi associati chiaramente e in modo evidente alla propria organizzazione. Questo divieto è analogo a quello specificato per le classi di lingua Java nella sezione 3.6.

3.2.3.4. Intent di trasmissione

Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent per informarle delle modifiche nell'ambiente hardware o software. I dispositivi compatibili con Android DEVONO trasmettere gli intent di trasmissione pubblica in risposta a eventi di sistema appropriati. Gli intent di trasmissione sono descritti nella documentazione dell'SDK.

3.2.3.5. Impostazioni app predefinite

Android include impostazioni che offrono agli utenti un modo semplice per selezionare le applicazioni predefinite, ad esempio per la schermata Home o gli SMS. Ove opportuno, le implementazioni dei dispositivi DEVONO fornire un menu Impostazioni simile ed essere compatibili con il pattern di filtro degli intent e i metodi API descritti nella documentazione dell'SDK come indicato di seguito.

Implementazioni dei dispositivi:

• DEVE rispettare l'intent android.settings.HOME_SETTINGS per mostrare un menu delle impostazioni predefinite dell'app per la schermata Home, se l'implementazione del dispositivo segnala android.software.home_screen [Risorse, 10]
• DEVE fornire un menu delle impostazioni che chiamerà l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT per mostrare una finestra di dialogo per cambiare l'applicazione SMS predefinita, se l'implementazione del dispositivo segnala android.hardware.telephony [Risorse, 11]
• DEVE rispettare l'intent android.settings.NFC_PAYMENT_SETTINGS per mostrare un menu predefinito delle impostazioni dell'app per il pagamento contactless, se l'implementazione del dispositivo segnala android.hardware.nfc.hce [Risorse, 10]

3.3. Compatibilità con le API native

3.3.1. Application Binary Interface

Il bytecode Dalvik gestito può chiamare il codice nativo fornito nel file .apk dell'applicazione come file .so ELF compilato per l'architettura hardware del dispositivo appropriata. Poiché il codice nativo è altamente dipendente dalla tecnologia del processore sottostante, Android definisce una serie di interfacce a livello di codice macchina (ABI) nell'NDK di Android. Le implementazioni dei dispositivi DEVONO essere compatibili con uno o più ABI definiti e DEVONO implementare la compatibilità con Android NDK, come indicato di seguito.

Se un'implementazione del dispositivo include il supporto di un'ABI Android:

• DEVE includere il supporto per il codice in esecuzione nell'ambiente gestito per chiamare il codice nativo utilizzando la semantica standard di Java Native Interface (JNI)
• DEVE essere compatibile con il codice sorgente (ovvero con l'intestazione) e con il codice binario (per l'ABI) con ogni libreria richiesta nell'elenco di seguito
• DEVE supportare l'ABI a 32 bit equivalente se è supportata un'ABI a 64 bit
• DEVE segnalare con precisione l'interfaccia a bit di applicazione (ABI) nativa supportata dal dispositivo tramite i parametri android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, ciascuno costituito da un elenco di ABI separati da virgola ordinati dal più preferito al meno preferito
• DEVE segnalare, tramite i parametri sopra indicati, solo le ABI documentate e descritte nell'ultima versione della documentazione di gestione ABI di Android NDK [Risorse, 12] e DEVE includere il supporto dell'estensione Advanced SIMD (noto anche come NEON) [Risorse, 13].
• DEVE essere compilato utilizzando il codice sorgente e i file di intestazione disponibili nell'upstream Android Open Source Project

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

• libc (libreria C)
• libm (libreria matematica)
• Supporto minimo per C++
• Interfaccia JNI
• liblog (logging Android)
• libz (compressione Zlib)
• libdl (linker dinamico)
• libGLESv1_CM.so (OpenGL ES 1.x)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.x)
• libEGL.so (gestione delle superfici OpenGL native)
• libjnigraphics.so
• libOpenSLES.so (supporto audio OpenSL ES 1.0.1)
• libOpenMAXAL.so (supporto di OpenMAX AL 1.0.1)
• libandroid.so (supporto delle attività native di Android)
• libmediandk.so (supporto delle API multimediali native)
• Supporto di OpenGL, come descritto di seguito

Tieni presente che le release future dell'Android NDK potrebbero introdurre il supporto di ABI aggiuntive. Se un'implementazione del dispositivo non è compatibile con un ABI predefinito esistente, NON DEVE segnalare il supporto di alcun ABI.

Tieni presente che le implementazioni del dispositivo DEVONO includere libGLESv3.so e DEVONO avere un link simbolico (symlink) a libGLESv2.so. A loro volta, DEVONO esportare tutti i simboli delle funzioni OpenGL ES 3.1 e Android Extension Pack [Risorse, 14] come definito nella release NDK android-21. Anche se tutti i simboli devono essere presenti, devono essere implementate completamente solo le funzioni corrispondenti per le versioni e le estensioni OpenGL ES effettivamente supportate dal dispositivo.

Le implementazioni dei dispositivi, se includono una libreria nativa con il nome libvulkan.so, devono esportare i simboli delle funzioni e fornire un'implementazione dell'API Vulkan 1.0 e delle estensioni VK_KHR_surface, VK_KHR_swapchain e VK_KHR_android_surface come definito dal Khronos Group e superare i test di conformità Khronos.

La compatibilità con il codice nativo è complessa. Per questo motivo, agli implementatori di dispositivi è FORTEMENTE CONSIGLIATO di utilizzare le implementazioni delle librerie sopra elencate del progetto Android Open Source upstream.

3.3.2. Compatibilità con il codice nativo ARM a 32 bit

L'architettura ARMv8 ritira diverse operazioni della CPU, tra cui alcune operazioni utilizzate nel codice nativo esistente. Sui dispositivi ARM a 64 bit, le seguenti operazioni ritirate DEVONO rimanere disponibili per il codice ARM nativo a 32 bit, tramite il supporto della CPU nativa o tramite l'emulazione software:

• Istruzioni per SWP e SWPB
• Istruzione SETEND
• Operazioni di barriere CP15ISB, CP15DSB e CP15DMB

Le versioni precedenti dell'Android NDK utilizzavano /proc/cpuinfo per scoprire le funzionalità della CPU da codice nativo ARM a 32 bit. Per la compatibilità con le applicazioni create utilizzando questo NDK, i dispositivi DEVONO includere le seguenti righe in /proc/cpuinfo quando vengono lette dalle applicazioni ARM a 32 bit:

• "Funzionalità: ", seguito da un elenco di eventuali funzionalità facoltative della CPU ARMv7 supportate dal dispositivo
• "Architettura CPU: ", seguito da un numero intero che descrive l'architettura ARM massima supportata del dispositivo (ad es. "8" per i dispositivi ARMv8)

Questi requisiti si applicano solo quando /proc/cpuinfo viene letto da applicazioni ARM a 32 bit. I dispositivi NON DEVONO modificare /proc/cpuinfo quando vengono letti da applicazioni ARM o non ARM a 64 bit.

3.4. Compatibilità web

3.4.1. Compatibilità con WebView

La funzionalità della piattaforma android.software.webview DEVE essere segnalata su qualsiasi dispositivo che fornisce un'implementazione completa dell'API android.webkit.WebView e NON DEVE essere segnalata sui dispositivi senza un'implementazione completa dell'API. L'implementazione di Android Open Source utilizza il codice del progetto Chromium per implementare android.webkit.WebView [Risorse, 15]. Poiché non è possibile sviluppare una suite di test completa per un sistema di rendering web, gli implementatori dei dispositivi DEVONO utilizzare la build upstream specifica di Chromium nell'implementazione di WebView. Nello specifico:

• Le implementazioni di android.webkit.WebView del dispositivo DEVONO essere basate sulla compilazione di Chromium proveniente dal progetto open source Android upstream per Android 6.0. Questa build include un insieme specifico di funzionalità e correzioni di sicurezza per WebView [Risorse, 16].
• La stringa dello user agent segnalata da WebView DEVE avere il seguente formato:

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, come Gecko) Versione/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • Il valore della stringa $(VERSION) DEVE essere uguale al valore di android.os.Build.VERSION.RELEASE.
  • Il valore della stringa $(MODEL) DEVE essere uguale al valore di android.os.Build.MODEL.
  • Il valore della stringa $(BUILD) DEVE essere uguale al valore di android.os.Build.ID.
  • Il valore della stringa $(CHROMIUM_VER) DEVE essere la versione di Chromium nel progetto open source Android di origine.
  • Le implementazioni dei dispositivi POSSONO omettere Mobile nella stringa dello user agent.

Il componente WebView DEVE includere il supporto del maggior numero possibile di funzionalità HTML5 e, se supporta la funzionalità, DEVE essere conforme alla specifica HTML5 [Risorse, 17].

3.4.2. Compatibilità del browser

Il browser autonomo POTREBBE 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 (in base all'applicazione Browser WebKit upstream o a una sostituzione di terze parti) DEVE includere il supporto per il maggior numero possibile di elementi HTML5 [Risorse, 17]. Come minimo, le implementazioni dei dispositivi DEVONO supportare ciascuna di queste API associate a HTML5:

• cache dell'applicazione/operazione offline [Resources, 18]
• il tag <video> [Risorse, 19]
• geolocalizzazione [Risorse, 20]

Inoltre, le implementazioni dei dispositivi DEVONO supportare l'API webstorage HTML5/W3C [Risorse, 21] e DOVREBBERO supportare l'API IndexedDB HTML5/W3C [Risorse, 22]. Tieni presente che, poiché gli enti di standardizzazione per lo sviluppo web stanno adottando IndexedDB al posto di webstorage, IndexedDB dovrebbe diventare un componente obbligatorio in una versione futura di Android.

3.5. Compatibilità comportamentale dell'API

Il comportamento di ciascuno dei tipi di API (gestite, soft, native e web) deve essere coerente con l'implementazione preferita del progetto Android Open Source upstream [Risorse, 2]. Ecco alcune aree specifiche di compatibilità:

• I dispositivi NON DEVONO modificare il comportamento o la semantica di uno scopo standard.
• I dispositivi NON DEVONO alterare il ciclo di vita o la semantica del ciclo di vita di un determinato tipo di componente di sistema (ad esempio Service, Activity, ContentProvider e così via).
• I dispositivi NON DEVONO modificare la semantica di un'autorizzazione standard.

L'elenco riportato sopra non è esaustivo. La Compatibility Test Suite (CTS) testa alcune parti significative della piattaforma per verificarne la compatibilità di comportamento, ma non tutte. È responsabilità dell'implementatore garantire la compatibilità del comportamento con Android Open Source Project. Per questo motivo, gli implementatori di dispositivi DEVONO utilizzare il codice sorgente disponibile tramite l'Android Open Source Project, ove possibile, anziché implementare nuovamente parti significative del sistema.

3.6. Spazi dei nomi API

Android segue le convenzioni relative allo spazio dei nomi dei pacchetti e delle classi definite dal linguaggio di programmazione Java. Per garantire la compatibilità con le applicazioni di terze parti, gli implementatori dei dispositivi NON DEVONO apportare modifiche vietate (vedi di seguito) a questi spazi dei nomi del pacchetto:

• java.*
• javax.*
• sole.*
• android.*
• com.android.*

Le modifiche vietate includono:

• Le implementazioni dei dispositivi NON DEVONO modificare le API esposte pubblicamente sulla piattaforma Android modificando le firme di metodi o classi o rimuovendo classi o campi di classi.
• Gli implementatori dei dispositivi POSSONO modificare l'implementazione sottostante delle API, ma queste modifiche NON DEVONO influire sul comportamento dichiarato e sulla firma in linguaggio Java di qualsiasi API esposta pubblicamente.
• Gli implementatori dei dispositivi NON DEVONO aggiungere elementi esposti pubblicamente (ad esempio classi o interfacce oppure campi o metodi a classi o interfacce esistenti) alle API sopra indicate.

Un "elemento esposto pubblicamente" è qualsiasi costrutto non decorato con l'indicatore "@hide" come utilizzato nel codice sorgente di Android upstream. In altre parole, gli implementatori dei dispositivi NON DEVONO esporre nuove API o modificare quelle esistenti nei spazi dei nomi sopra indicati. Gli implementatori dei dispositivi POSSONO apportare modifiche solo per uso interno, ma queste modifiche NON DEVONO essere pubblicizzate o comunque esposte agli sviluppatori.

Gli implementatori dei dispositivi POSSONO aggiungere API personalizzate, ma queste API NON DEVONO trovarsi in un ambito di nomi di proprietà di un'altra organizzazione o che fanno riferimento a un'altra organizzazione. Ad esempio, gli implementatori di dispositivi NON DEVONO aggiungere API al namespace com.google.* o a un namespace simile: solo Google può farlo. Analogamente, Google NON DEVE aggiungere API ai namespace di altre aziende. Inoltre, se un'implementazione del dispositivo include API personalizzate al di fuori dello spazio dei nomi Android standard, queste API DEVONO essere pacchettizzate in una libreria condivisa Android in modo che solo le app che le utilizzano esplicitamente (tramite il meccanismo <uses-librarygt;) siano interessate dall'aumento dell'utilizzo della memoria di queste API.

Se un implementatore di dispositivi propone di migliorare uno degli spazi dei nomi del pacchetto sopra indicati (ad esempio aggiungendo nuove funzionalità utili a un'API esistente o aggiungendo una nuova API), l'implementatore DEVE visitare source.android.com e avviare la procedura per contribuire con modifiche e codice, in base alle informazioni su quel sito.

Tieni presente che le limitazioni riportate sopra corrispondono alle convenzioni standard per la denominazione delle API nel linguaggio di programmazione Java. Lo scopo di questa sezione è semplicemente rafforzare queste convenzioni e renderle vincolanti tramite l'inclusione in questa definizione di compatibilità.

3.7. Compatibilità di runtime

Le implementazioni dei dispositivi DEVONO supportare il formato Dalvik Executable (DEX) completo e la specifica e la semantica del bytecode Dalvik [Risorse, 23]. Gli implementatori di dispositivi DEVONO utilizzare ART, l'implementazione upstream di riferimento del formato eseguibile Dalvik e il sistema di gestione dei pacchetti dell'implementazione di riferimento.

Le implementazioni dei dispositivi DEVONO configurare gli ambienti di runtime Dalvik per allocare la memoria in conformità con la piattaforma Android a monte e come specificato dalla tabella seguente. (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 valori minimi e le implementazioni dei dispositivi POSSONO allocare più memoria per applicazione.

Layout dello schermo	Densità schermo	Memoria minima dell'applicazione
Orologio Android	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36MB
	280 dpi (280dpi)
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
piccolo/normale	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
grande	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi (xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512MB
xlarge	120 dpi (ldpi)	48MB
	160 dpi (mdpi)	80MB
	213 dpi (tvdpi)	96MB
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

Android include un'applicazione Avvio app (schermata Home) e il supporto per applicazioni di terze parti che sostituiscono l'Avvio app del dispositivo (schermata Home). Le implementazioni del dispositivo che consentono ad applicazioni di terze parti di sostituire la schermata Home del dispositivo DEVONO dichiarare la funzionalità della piattaforma android.software.home_screen.

3.8.2. Widget

Android definisce un tipo di componente e l'API e il ciclo di vita corrispondente che consente alle applicazioni di esporre un "AppWidget" all'utente finale [Risorse, 24], una funzionalità che è FORTEMENTE CONSIGLIATA per essere supportata nelle implementazioni dei dispositivi palmari. Le implementazioni dei dispositivi che supportano l'inserimento di widget nella schermata Home DEVONO soddisfare i seguenti requisiti e dichiarare il supporto della funzionalità della piattaforma android.software.app_widgets.

• Gli Avvio app dei dispositivi DEVONO includere il supporto integrato per gli AppWidget e mettere a disposizione dell'utente funzionalità di interfaccia per aggiungere, configurare, visualizzare e rimuovere gli AppWidget direttamente dall'Avvio app.
• Le implementazioni dei dispositivi 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 la progettazione di widget per app nella documentazione dell'SDK Android [Risorse, 24].
• Le implementazioni dei dispositivi che includono il supporto della schermata di blocco POTREBBERO supportare i widget delle applicazioni nella schermata di blocco.

3.8.3. Notifiche

Android include API che consentono agli sviluppatori di notificare agli utenti eventi importanti [Risorse, 25] utilizzando le funzionalità hardware e software del dispositivo.

Alcune API consentono alle applicazioni di eseguire notifiche o attirare l'attenzione utilizzando l'hardware, in particolare suono, vibrazione e luce. Le implementazioni dei dispositivi 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 è priva di hardware, le API corrispondenti DEVONO essere implementate come no-op. Questo comportamento è descritto in modo più dettagliato nella sezione 7.

Inoltre, l'implementazione DEVE eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) previste dalle API [Risorse, 26] o nella guida di stile delle icone della barra di stato/sistema [Risorse, 27], che nel caso di un dispositivo Android TV include la possibilità di non visualizzare le notifiche. Gli implementatori dei dispositivi POSSONO fornire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'implementazione di riferimento di Android Open Source. Tuttavia, questi sistemi di notifica alternativi DEVONO supportare le risorse di notifica esistenti, come sopra indicato.

Android include il supporto di varie notifiche, ad esempio:

• Notifiche avanzate. Visualizzazioni interattive per le notifiche in corso.
• Notifiche in primo piano. Le visualizzazioni interattive possono essere gestite o ignorate dagli utenti senza uscire dall'app corrente.
• Notifiche nella schermata di blocco. Notifiche visualizzate su una schermata di blocco con controllo granulare sulla visibilità.

Le implementazioni dei dispositivi Android, quando queste notifiche vengono rese visibili, DEVONO eseguire correttamente le notifiche avanzate e in primo piano e includere il titolo/nome, l'icona e il testo come descritto nelle API Android [Risorse, 28].

Android include le API Notification Listener Service che consentono alle app (se attivate esplicitamente dall'utente) di ricevere una copia di tutte le notifiche man mano che vengono pubblicate o aggiornate. Le implementazioni dei dispositivi DEVONO inviare correttamente e tempestivamente le notifiche nella loro interezza a tutti i servizi di listener installati e abilitati dall'utente, inclusi tutti i metadati associati all'oggetto Notification.

3.8.4. Cerca

Android include API [Risorse, 29] che consentono agli sviluppatori di integrare la ricerca nelle loro applicazioni e di mostrare i dati delle loro applicazioni nella ricerca di sistema globale. In generale, questa funzionalità consiste in un'unica interfaccia utente a livello di sistema che consente agli utenti di inserire query, visualizzare suggerimenti man mano che digitano e visualizzare i risultati. Le API Android consentono agli sviluppatori di riutilizzare questa interfaccia per fornire la ricerca all'interno delle proprie app e di fornire risultati all'interfaccia utente della ricerca globale comune.

Le implementazioni dei dispositivi Android DOVREBBERO includere la ricerca globale, un'interfaccia utente di ricerca singola, condivisa e di sistema in grado di fornire suggerimenti in tempo reale in risposta all'input dell'utente. Le implementazioni dei dispositivi DOVREBBERO implementare le API che consentono agli sviluppatori di riutilizzare questa interfaccia utente per fornire la ricerca all'interno delle proprie applicazioni. Le implementazioni dei dispositivi che implementano l'interfaccia di ricerca globale devono implementare le API che consentono alle applicazioni di terze parti di aggiungere suggerimenti alla casella di ricerca quando viene eseguita in modalità di ricerca globale. Se non sono installate applicazioni di terze parti che utilizzano questa funzionalità, il comportamento predefinito DOVREBBE essere la visualizzazione di risultati e suggerimenti del motore di ricerca web.

Le implementazioni dei dispositivi Android DEVONO implementare un assistente sul dispositivo per gestire l'azione di assistenza [Risorse, 30].

Android include anche le API Assist per consentire alle applicazioni di scegliere quante informazioni del contesto corrente devono essere condivise con l'assistente sul dispositivo [Risorse, 31]. Le implementazioni dei dispositivi che supportano l'azione di assistenza DEVONO indicare chiaramente all'utente finale quando il contesto viene condiviso mostrando una luce bianca intorno ai bordi dello schermo. Per garantire una visibilità chiara all'utente finale, l'indicazione DEVE soddisfare o superare la durata e la luminosità dell'implementazione del progetto Android Open Source.

3.8.5. Auguri

Le applicazioni possono utilizzare l'API "Toast" per mostrare all'utente finale brevi stringhe non modali che scompaiono dopo un breve periodo di tempo [Risorse, 32]. Le implementazioni dei dispositivi DEVONO mostrare i popup dalle applicazioni agli utenti finali in modo molto visibile.

3.8.6. Temi

Android fornisce i "temi" come meccanismo per consentire alle applicazioni di applicare stili a un'intera attività o applicazione.

Android include una famiglia di temi "Holo" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare l'aspetto e il feeling del tema Holo come definito dall'SDK Android [Risorse, 33]. Le implementazioni dei dispositivi NON DEVONO alterare nessuno degli attributi del tema Holo esposti alle applicazioni [Risorse, 34].

Android include una famiglia di temi "Material" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare l'aspetto del tema di design all'ampia gamma di diversi tipi di dispositivi Android. Le implementazioni dei dispositivi DEVONO supportare la famiglia di temi "Material" e NON DEVONO alterare nessuno degli attributi del tema Material o le relative risorse esposte alle applicazioni [Risorse, 35].

Android include anche una famiglia di temi "Predefinito del dispositivo" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare l'aspetto del tema del dispositivo come definito dall'implementatore del dispositivo. Le implementazioni del dispositivo POSSONO modificare gli attributi del tema Predefinito dispositivo esposti alle applicazioni [Risorse, 34].

Android supporta un tema con barre di sistema traslucide, che consente agli sviluppatori di app di riempire l'area dietro la barra di stato e la barra di navigazione con i contenuti delle app. Per consentire un'esperienza omogenea per gli sviluppatori in questa configurazione, è importante che lo stile delle icone della barra di stato venga mantenuto nelle implementazioni di dispositivi diversi. Pertanto, le implementazioni dei dispositivi Android devono utilizzare il bianco per le icone di stato di sistema (ad esempio l'intensità del segnale e il livello della batteria) e le notifiche emesse dal sistema, a meno che l'icona non indichi uno stato problematico o un'app richieda una barra di stato chiara utilizzando il flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Quando un'app richiede una barra di stato chiara, le implementazioni dei dispositivi Android DEVONO cambiare il colore delle icone di stato di sistema in nero [Risorse, 34].

3.8.7. 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, 36]. Gli sfondi animati sono animazioni, motivi o immagini simili con funzionalità di input limitate che vengono visualizzate come sfondo dietro altre applicazioni.

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

Le implementazioni dei dispositivi in grado di eseguire sfondi animati in modo affidabile come descritto sopra DEVONO implementare gli sfondi animati e, una volta implementati, DEVONO segnalare il flag della funzionalità della piattaforma android.software.live_wallpaper.

3.8.8. Cambio attività

Il codice sorgente di Android upstream include la schermata Panoramica [Risorse, 37], un'interfaccia utente a livello di sistema per il passaggio da un'attività all'altra e la visualizzazione delle attività e delle attività a cui è stato eseguito l'accesso di recente utilizzando un'immagine in miniatura dello stato grafico dell'applicazione al momento in cui l'utente ha chiuso l'applicazione per l'ultima volta. Le implementazioni del dispositivo, inclusa la chiave di navigazione della funzione Recenti descritta nella sezione 7.2.3, POSSONO modificare l'interfaccia, ma DEVONO soddisfare i seguenti requisiti:

• DEVE mostrare i contenuti recenti affiliati come un gruppo che si sposta insieme.
• DEVE supportare almeno 6 attività visualizzate.
• DEVE mostrare almeno il titolo di quattro attività alla volta.
• DOVREBBE mostrare il colore di evidenziazione, l'icona e il titolo della schermata tra le app recenti.
• DEVE implementare il comportamento di blocco dello schermo [Risorse, 38] e fornire all'utente un menu delle impostazioni per attivare/disattivare la funzionalità.
• DOVREBBE mostrare un'affordance di chiusura ("x"), ma PUÒ ritardare questa azione finché l'utente non interagisce con le schermate.

Per le implementazioni dei dispositivi è FORTEMENTE CONSIGLIATO utilizzare l'interfaccia utente Android upstream (o un'interfaccia basata su miniature simile) per la schermata Panoramica.

3.8.9. Gestione dell'input

Android include il supporto per la gestione dell'input e per gli editor di metodi di input di terze parti [Risorse, 39]. Le implementazioni dei dispositivi che consentono agli utenti di utilizzare metodi di inserimento di terze parti sul dispositivo DEVONO dichiarare la funzionalità della piattaforma android.software.input_methods e supportare le API IME come definito nella documentazione dell'SDK Android.

Le implementazioni dei dispositivi che dichiarano la funzionalità android.software.input_methods devono fornire un meccanismo accessibile agli utenti per aggiungere e configurare metodi di input di terze parti. Le implementazioni del dispositivo DEVONO mostrare l'interfaccia delle impostazioni in risposta all'intent android.settings.INPUT_METHOD_SETTINGS.

3.8.10. Controllo dei contenuti multimediali nella schermata di blocco

L'API Remote Control Client è deprecata da Android 5.0 a favore del Modello di notifica multimediale che consente alle applicazioni multimediali di integrarsi con i controlli di riproduzione visualizzati nella schermata di blocco [Risorse, 40] come notifiche nella schermata di blocco. Le implementazioni dei dispositivi DEVONO visualizzare correttamente il modello di notifica multimediale nell'ambito delle notifiche della schermata di blocco descritte nella sezione 3.8.3.

3.8.11. Sogni

Android include il supporto per schermate di blocco interattive chiamate Sogni [Risorse, 41]. Dreams consente agli utenti di interagire con le applicazioni quando un dispositivo collegato a un'alimentazione è inattivo o agganciato alla base di ricarica. I dispositivi Android Watch POSSONO implementare Dreams, ma altri tipi di implementazioni dei dispositivi DEVONO includere il supporto di Dreams e fornire un'opzione di impostazioni per consentire agli utenti di configurare Dreams in risposta all'intent android.settings.DREAM_SETTINGS.

3.8.12. Posizione

Quando un dispositivo è dotato di un sensore hardware (ad es. GPS) in grado di fornire le coordinate geografiche, le modalità di geolocalizzazione DEVONO essere visualizzate nel menu Posizione all'interno di Impostazioni [Risorse, 42].

3.8.13. Unicode e carattere

Android include il supporto dei caratteri emoji a colori. Quando le implementazioni dei dispositivi Android includono un IME, i dispositivi DEVONO fornire all'utente un metodo di inserimento per i caratteri emoji definiti in Unicode 6.1 [Risorse, 43]. Tutti i dispositivi DEVONO essere in grado di eseguire il rendering di questi caratteri emoji in un glifo a colori.

Android include il supporto del carattere Roboto 2 con diversi spessori: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light, che DEVONO essere inclusi per tutte le lingue disponibili sul dispositivo e per una copertura completa di Unicode 7.0 per latino, greco e cirillico, inclusi gli intervalli A, B, C e D del latino esteso e tutti i glifi nel blocco dei simboli di valuta di Unicode 7.0.

3.9. Amministrazione dispositivo

Android include funzionalità che consentono alle applicazioni sensibili alla 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 una cancellazione dei dati da remoto, tramite l'API Android Device Administration [Risorse, 44]. Le implementazioni dei dispositivi DEVONO fornire un'implementazione della classe DevicePolicyManager [Resources, 45]. Le implementazioni dei dispositivi che includono il supporto di schermate di blocco basate su PIN (numerico) o PASSWORD (alfanumerico) DEVONO supportare l'intera gamma di criteri di amministrazione del dispositivo definiti nella documentazione dell'SDK Android [Risorse, 44] e segnalare la funzionalità della piattaforma android.software.device_admin.

3.9.1 Provisioning del dispositivo

3.9.1.1 Provisioning del proprietario del dispositivo

Se l'implementazione di un dispositivo dichiara la funzionalità android.software.device_admin, il flusso di configurazione pronta all'uso DEVE consentire di registrare un'applicazione controller dei criteri dei dispositivi (DPC) come app del proprietario del dispositivo. [ Risorse, 46]. Le implementazioni dei dispositivi POSSONO avere un'applicazione preinstallata che esegue funzioni di amministrazione del dispositivo, ma questa applicazione NON DEVE essere impostata come app Proprietario dispositivo senza il consenso esplicito o l'azione dell'utente o dell'amministratore del dispositivo.

L'esperienza utente della procedura di provisioning del proprietario del dispositivo (il flusso avviato da android.app.action.PROVISION_MANAGED_DEVICE [ Risorse, 47]) DEVE essere in linea con l'implementazione AOSP

Se l'implementazione del dispositivo segnala android.hardware.nfc, è OBBLIGATORIO attivare il protocollo NFC, anche durante il flusso di configurazione out-of-box, per consentire il provisioning NFC dei proprietari di dispositivi [Risorse, 48].

3.9.1.2 Provisioning dei profili gestiti

Se un'implementazione del dispositivo dichiara android.software.managed_users, deve essere possibile registrare un'applicazione Device Policy Controller (DPC) come proprietario di un nuovo profilo gestito. [ Risorse, 49]

L'esperienza utente della procedura di provisioning del profilo gestito (il flusso avviato da android.app.action.PROVISION_MANAGED_PROFILE [ Risorse, 50]) DEVE essere in linea con l'implementazione AOSP

3.9.2 Assistenza per i profili gestiti

I dispositivi compatibili con i profili gestiti sono quelli che:

• Dichiara android.software.device_admin (vedi sezione 3.9 Amministrazione dispositivo)
• Non sono dispositivi con poca RAM (vedi sezione 7.6.1
• Alloca lo spazio di archiviazione interno (non rimovibile) come spazio di archiviazione condiviso (vedi sezione 7.6.2)

I dispositivi compatibili con il profilo gestito DEVONO:

• Dichiara il flag della funzionalità della piattaforma android.software.managed_users.
• Supportare i profili gestiti tramite le API android.app.admin.DevicePolicyManager
• Consentire la creazione di un solo profilo gestito [Risorse, 50]
• Utilizza un badge icona (simile al badge di lavoro in upstream AOSP) per rappresentare le applicazioni e i widget gestiti e altri elementi dell'interfaccia utente con badge come Recenti e Notifiche
• Mostrare un'icona di notifica (simile al badge di lavoro in upstream AOSP) per indicare quando l'utente si trova in un'applicazione con profilo gestito
• Mostrare una notifica che indica che l'utente è nel profilo gestito se e quando il dispositivo si riattiva (ACTION_USER_PRESENT) e l'applicazione in primo piano si trova nel profilo gestito
• Se esiste un profilo gestito, mostra un'affordance visiva nel "Selettore" di intent per consentire all'utente di inoltrare l'intent dal profilo gestito all'utente principale o viceversa, se abilitato dal Controller dei criteri del dispositivo
• Se esiste un profilo gestito, esponi le seguenti funzionalità utente sia per l'utente principale sia per il profilo gestito:
  • Contabilità separata per batteria, posizione, dati mobili e utilizzo dello spazio di archiviazione per l'utente principale e il profilo gestito.
  • Gestione indipendente delle applicazioni VPN installate nell'utente primario o nel profilo gestito.
  • Gestione indipendente delle applicazioni installate nell'utente principale o nel profilo gestito.
  • Gestione indipendente degli account all'interno del profilo utente principale o gestito.
• Assicurati che il tastierino predefinito possa cercare le informazioni sull'autore della chiamata dal profilo gestito (se esistente) insieme a quelle del profilo principale, se il Controller Device Policy lo consente.
• DEVE garantire che soddisfi tutti i requisiti di sicurezza applicabili a un dispositivo con più utenti abilitati (vedi sezione 9.5), anche se il profilo gestito non viene conteggiato come un altro utente oltre all'utente principale.

3.10. Accessibilità

Android fornisce un livello di accessibilità che aiuta gli utenti con disabilità a navigare più facilmente sui loro dispositivi. Inoltre, Android fornisce API di piattaforma che consentono alle implementazioni dei servizi di accessibilità di ricevere callback per gli eventi dell'utente e del sistema e di generare meccanismi di feedback alternativi, come text-to-speech, feedback aptico e navigazione con trackball/d-pad [Risorse, 51].

Le implementazioni dei dispositivi includono i seguenti requisiti:

• Le implementazioni di Android Automotive DOVREBBERO fornire un'implementazione del framework di accessibilità di Android coerente con l'implementazione predefinita di Android.
• Le implementazioni dei dispositivi (escluso Android Automotive) DEVONO fornire un'implementazione del framework di accessibilità di Android coerente con l'implementazione predefinita di Android.
• Le implementazioni dei dispositivi (escluso Android Automotive) DEVONO supportare le implementazioni di servizi di accessibilità di terze parti tramite le API android.accessibilityservice. [Risorse, 52]
• Le implementazioni dei dispositivi (escluso Android Automotive) DEVONO generare AccessibilityEvents e inviarli a tutte le implementazioni di AccessibilityService registrate in modo coerente con l'implementazione predefinita di Android
• Le implementazioni dei dispositivi (dispositivi Android Automotive e Android Watch con esclusione dell'uscita audio) 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 dei dispositivi DEVONO fornire un'implementazione di un servizio di accessibilità sul dispositivo e DEVONO fornire un meccanismo per consentire agli utenti di attivare il servizio di accessibilità durante la configurazione del dispositivo. Un'implementazione open source di un servizio di accessibilità è disponibile nel progetto Eyes Free [Risorse, 53].

3.11. Sintesi vocale

Android include API che consentono alle applicazioni di utilizzare i servizi di sintesi vocale (TTS) e ai fornitori di servizi di fornire implementazioni di questi servizi [Risorse, 54]. Le implementazioni dei dispositivi che segnalano la funzionalità android.hardware.audio.output devono soddisfare questi requisiti relativi al framework TTS di Android.

Implementazioni di Android Automotive:

• DEVE supportare le API del framework TTS di Android.
• POTREBBE supportare l'installazione di motori TTS di terze parti. Se supportato, i partner devono fornire un'interfaccia accessibile all'utente che consenta di selezionare un motore TTS da utilizzare a livello di sistema.

Tutte le altre implementazioni dei dispositivi:

• DEVE supportare le API del framework TTS di Android e DOVREBBE includere un motore TTS supportante le lingue disponibili sul dispositivo. Tieni presente che il software open source Android di upstream include un'implementazione del motore TTS con funzionalità complete.
• DEVE supportare l'installazione di motori TTS di terze parti
• DEVE fornire un'interfaccia accessibile agli utenti che consenta loro di selezionare un motore TTS da utilizzare a livello di sistema

3.12. TV Input Framework

Android Television Input Framework (TIF) semplifica la pubblicazione di contenuti dal vivo su dispositivi Android TV. TIF fornisce un'API standard per creare moduli di input che controllano i dispositivi Android TV. Le implementazioni dei dispositivi Android TV DEVONO supportare TV Input Framework [Risorse, 55].

Le implementazioni dei dispositivi che supportano TIF DEVONO dichiarare la funzionalità della piattaforma android.software.live_tv.

3.12.1. App TV

Qualsiasi implementazione del dispositivo che dichiara il supporto della TV in diretta DEVE avere un'app TV installata. Android Open Source Project fornisce un'implementazione dell'app TV.

L'app TV predefinita deve fornire l'accesso ai canali dagli ingressi installati e da quelli di terze parti. Tieni presente che gli input installati comprendono tutti gli input forniti per impostazione predefinita, indipendentemente dal fatto che siano basati su TIF o meno.

L'app TV DEVE fornire strumenti per installare e utilizzare i canali TV [Risorse, 56] e soddisfare i seguenti requisiti:

• Le implementazioni dei dispositivi DEVONO consentire l'installazione e la gestione di input di terze parti basati su TIF (input di terze parti) [Risorse, 57] .
• Le implementazioni dei dispositivi POSSONO prevedere una separazione visiva tra gli input basati su TIF preinstallati (input installati) [Risorse, 58] e gli input di terze parti.
• Le implementazioni del dispositivo NON DEVONO mostrare gli input di terze parti a più di una singola azione di navigazione dall'app TV (ad es. l'espansione di un elenco di input di terze parti dall'app TV).

3.12.1.1. Guida elettronica ai programmi

Le implementazioni dei dispositivi Android TV DEVONO mostrare un overlay informativo e interattivo, che DEVE includere una guida elettronica dei programmi (EPG) generata dai valori nei campi TvContract.Programs [Risorse, 59]. L'EPG DEVE soddisfare i seguenti requisiti:

• L'EPG DEVE mostrare le informazioni di tutti gli ingressi installati e di quelli di terze parti.
• L'EPG PUÒ fornire una separazione visiva tra gli ingressi installati e quelli di terze parti.
• È FORTEMENTE CONSIGLIATO che l'EPG mostri gli input installati e quelli di terze parti con la stessa evidenza. L'EPG NON DEVE mostrare gli ingressi di terze parti più di una singola azione di navigazione dagli ingressi installati nell'EPG.
• Al cambio di canale, le implementazioni dei dispositivi DEVONO mostrare i dati EPG per il programma attualmente in riproduzione.

3.12.1.2. Navigazione

I dispositivi di input del dispositivo Android TV (ad es. telecomando, applicazione di telecomando o controller per videogiochi) DEVONO consentire la navigazione in tutte le sezioni dello schermo attive tramite il D-pad. I tasti direzionali SU e GIU DEVONO essere utilizzati per cambiare i canali TV in diretta quando sullo schermo non è presente una sezione attiva.

L'app TV DEVE trasmettere gli eventi chiave agli ingressi HDMI tramite CEC.

3.12.1.3. Collegamento delle app all'ingresso TV

Le implementazioni dei dispositivi Android TV DEVONO supportare il collegamento delle app all'ingresso TV, che consente a tutti gli ingressi di fornire link di attività dall'attività corrente a un'altra attività (ad es. un link dalla programmazione in diretta ai contenuti correlati) [Risorse, 60]. L'app TV DEVE mostrare il collegamento dell'app di input TV quando viene fornito.

4. Compatibilità con il pacchettizzazione delle applicazioni

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

Le implementazioni dei dispositivi NON DEVONO estendere i file .apk [Risorse, 62], Android Manifest [Risorse, 49], il bytecode Dalvik [Risorse, 23] o i formati bytecode di RenderScript in modo da impedire l'installazione e l'esecuzione corretta di questi file su altri dispositivi compatibili.

5. Compatibilità multimediale

5.1. Codec multimediali

Le implementazioni dei dispositivi DEVONO supportare i formati multimediali di base specificati nella documentazione dell'SDK Android [Risorse, 64], tranne nei casi in cui sia esplicitamente consentito in questo documento. Nello specifico, le implementazioni dei dispositivi DEVONO supportare i formati multimediali, gli encoder, i decodificatori, i tipi di file e i formati dei contenitori definiti nelle tabelle seguenti e segnalati tramite MediaCodecList [Risorse, 65]. Le implementazioni dei dispositivi DEVONO anche essere in grado di decodificare tutti i profili registrati in CamcorderProfile [Risorse, 66] e DEVONO essere in grado di decodificare tutti i formati che possono essere codificati. Tutti questi codec sono forniti come implementazioni software nell'implementazione Android preferita dell'Android Open Source Project.

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

5.1.1. Codec audio

Formato/codec	Codificatore	Decoder	Dettagli	Tipi di file/formati contenitore supportati
Profilo MPEG-4 AAC (AAC LC)	OBBLIGATORIO1	OBBLIGATORIO	Supporto per contenuti mono/stereo/5.0/5.12 con frequenze di campionamento standard da 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC non compresso ADTS (.aac, decodifica in Android 3.1 e versioni successive, codifica in Android 4.0 e versioni successive, ADIF non supportato) MPEG-TS (.ts, non cercabile, Android 3.0 e versioni successive)
Profilo MPEG-4 HE AAC (AAC+)	OBBLIGATORIO1 (Android 4.1 e versioni successive)	OBBLIGATORIO	Supporto per contenuti mono/stereo/5.0/5.12 con frequenze di campionamento standard da 16 a 48 kHz.
Profilo MPEG-4 HE AACv2 (AAC+ migliorato)		OBBLIGATORIO	Supporto per contenuti mono/stereo/5.0/5.12 con frequenze di campionamento standard da 16 a 48 kHz.
AAC ELD (AAC a bassa latenza migliorata)	OBBLIGATORIO1 (Android 4.1 e versioni successive)	OBBLIGATORI (Android 4.1 e versioni successive)	Supporto per contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.
AMR-NB	OBBLIGATORIO3	OBBLIGATORIO3	Da 4,75 a 12,2 Kbps campionati a 8 kHz	3GPP (.3gp)
AMR-WB	OBBLIGATORIO3	OBBLIGATORIO3	9 velocità da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz
FLAC		OBBLIGATORI (Android 3.1 e versioni successive)	Mono/stereo (nessun multicanale). Frequenze di campionamento fino a 48 kHz (ma fino a 44,1 kHz è consigliata su dispositivi con uscita a 44,1 kHz, in quanto il downsampler da 48 a 44,1 kHz non include un filtro passa basso). CONSIGLIATO 16 bit; nessun dither applicato per 24 bit.	Solo FLAC (.flac)
MP3		OBBLIGATORIO	Mono/stereo 8-320 Kbps costante (CBR) o con velocità in bit variabile (VBR)	MP3 (.mp3)
MIDI		OBBLIGATORIO	Tipo MIDI 0 e 1. Versioni 1 e 2 di DLS. XMF e Mobile XMF. Supporto per i formati di suoneria RTTTL/RTX, OTA e iMelody	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		OBBLIGATORIO		Ogg (.ogg) Matroska (.mkv, Android 4.0 e versioni successive)
PCM/WAVE	OBBLIGATORIO4 (Android 4.1 e versioni successive)	OBBLIGATORIO	PCM lineare a 16 bit (frequenze fino al limite dell'hardware). I dispositivi DEVONO supportare le frequenze di campionamento per la registrazione PCM non compressa a 8000, 11025, 16000 e 44100 Hz.	WAVE (.wav)
Opus		OBBLIGATORI (Android 5.0 e versioni successive)		Matroska (.mkv)

1 Obbligatorio per le implementazioni dei dispositivi che definiscono android.hardware.microphone, ma facoltativo per le implementazioni dei dispositivi Android Watch.

2 È richiesto solo il downmix dei contenuti 5.0/5.1; la registrazione o il rendering di più di 2 canali è facoltativo.

3 Obbligatorio per le implementazioni dei dispositivi Android portatili.

4 Obbligatorio per le implementazioni dei dispositivi che definiscono android.hardware.microphone, incluse le implementazioni dei dispositivi Android Watch.

5.1.2. Codec immagine

Formato/codec	Codificatore	Decoder	Dettagli	Tipi di file/formati contenitore supportati
JPEG	OBBLIGATORIO	OBBLIGATORIO	Base+progressiva	JPEG (.jpg)
GIF		OBBLIGATORIO		GIF (.gif)
PNG	OBBLIGATORIO	OBBLIGATORIO		PNG (.png)
BMP		OBBLIGATORIO		BMP (.bmp)
WebP	OBBLIGATORIO	OBBLIGATORIO		WebP (.webp)

5.1.3. Codec video

Formato/codec	Codificatore	Decoder	Dettagli	Tipi di file/ formati contenitore supportati
H.263	OBBLIGATORIO1	OBBLIGATORIO2		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	OBBLIGATORIO2	OBBLIGATORIO2	Per maggiori dettagli, consulta le sezioni 5.2 e 5.3	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, solo audio AAC, non cercabile, Android 3.0 e versioni successive)
H.265 HEVC		OBBLIGATORIO5	Per informazioni dettagliate, consulta la sezione 5.3	MPEG-4 (.mp4)
MPEG-2		FORTEMENTE CONSIGLIATO6	Profilo principale	MPEG2-TS
MPEG-4 SP		OBBLIGATORIO2		3GPP (.3gp)
VP83	OBBLIGATORIO2 (Android 4.3 e versioni successive)	OBBLIGATORIO2 (Android 2.3.3 e versioni successive)	Per maggiori dettagli, consulta le sezioni 5.2 e 5.3	WebM (.webm) [Risorse, 67 Matroska (.mkv, Android 4.0 e versioni successive)4
VP9		OBBLIGATORIO2 (Android 4.4 e versioni successive)	Per informazioni dettagliate, consulta la sezione 5.3	WebM (.webm) [Risorse, 67] Matroska (.mkv, Android 4.0 e versioni successive)4

1 Obbligatorio per le implementazioni dei dispositivi che includono l'hardware della fotocamera e definiscono android.hardware.camera o android.hardware.camera.front.

2 Obbligatorio per le implementazioni dei dispositivi, ad eccezione dei dispositivi Android Watch.

3 Per una qualità accettabile dei servizi di streaming video web e di videoconferenza, le implementazioni dei dispositivi DEVONO utilizzare un codec VP8 hardware che soddisfi i requisiti riportati in [Risorse, 68].

4 Le implementazioni dei dispositivi DEVONO supportare la scrittura di file Matroska WebM.

5 MOLTO CONSIGLIATO per Android Automotive, facoltativo per Android Watch e obbligatorio per tutti gli altri tipi di dispositivi.

6 Si applica solo alle implementazioni dei dispositivi Android TV.

5.2. Codifica video

Le implementazioni dei dispositivi Android con codificatori H.263 DEVONO supportare il livello del profilo di base 45.

Le implementazioni dei dispositivi Android con supporto del codec H.264 DEVONO supportare il profilo di base di livello 3 e i seguenti profili di codifica video SD (definizione standard) e DOVREBBERO supportare il profilo principale di livello 4 e i seguenti profili di codifica video HD (alta definizione). È MOLTO CONSIGLIATO codificare i video HD 1080p a 30 f/s su dispositivi Android TV.

	SD (bassa qualità)	SD (alta qualità)	HD 720p1	HD 1080p1
Risoluzione video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	20 f/s	30 fps	30 fps	30 fps
Velocità in bit video	384 kbps	2 Mbps	4 Mbps	10 Mbps

1 Se supportato dall'hardware, ma FORTEMENTE CONSIGLIATO per i dispositivi Android TV.

Le implementazioni di dispositivi Android con supporto del codec VP8 DEVONO supportare i profili di codifica video SD e DOVREBBERO supportare i seguenti profili di codifica video HD (alta definizione).

	SD (bassa qualità)	SD (alta qualità)	HD 720p1	HD 1080p1
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps
Velocità in bit video	800 kbps	2 Mbps	4 Mbps	10 Mbps

1 Se supportato dall'hardware.

5.3. Decodifica video

Le implementazioni dei dispositivi DEVONO supportare il passaggio dinamico della risoluzione video e della frequenza frame tramite le API Android standard all'interno dello stesso stream per tutti i codec VP8, VP9, H.264 e H.265 in tempo reale e fino alla risoluzione massima supportata da ciascun codec sul dispositivo.

Le implementazioni dei dispositivi Android con decodificatori H.263 DEVONO supportare il livello del profilo di base 30.

Le implementazioni dei dispositivi Android con decodificatori MPEG-4 DEVONO supportare il livello 3 del profilo semplice.

Le implementazioni dei dispositivi Android con decodificatori H.264 DEVONO supportare il profilo principale Livello 3.1 e i seguenti profili di decodifica video SD e DOVREBBERO supportare i profili di decodifica HD. I dispositivi Android TV DEVONO supportare il livello 4.2 del profilo High e il profilo di decodifica HD 1080p.

	SD (bassa qualità)	SD (alta qualità)	HD 720p1	HD 1080p1
Risoluzione video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	60 FPS	30 fps / 60 fps2
Velocità in bit video	800 kbps	2 Mbps	8 Mbps	20 Mbps

1 OBBLIGATORI quando l'altezza indicata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video.

2 OBBLIGATORI per le implementazioni dei dispositivi Android TV.

Le implementazioni dei dispositivi Android che supportano il codec VP8, come descritto nella sezione 5.1.3, DEVONO supportare i seguenti profili di decodifica SD e DOVREBBERO supportare i profili di decodifica HD. I dispositivi Android TV DEVONO supportare il profilo di decodifica HD 1080p.

	SD (bassa qualità)	SD (alta qualità)	HD 720p1	HD 1080p1
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps / 60 fps2	30/60 f/s2
Velocità in bit video	800 kbps	2 Mbps	8 Mbps	20 Mbps

1 OBBLIGATORI quando l'altezza indicata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video.

2 OBBLIGATORI per le implementazioni dei dispositivi Android TV.

Le implementazioni dei dispositivi Android, se supportano il codec VP9 come descritto nella sezione 5.1.3, DEVONO supportare i seguenti profili di decodifica video SD e DOVREBBERO supportare i profili di decodifica HD. È FORTEMENTE CONSIGLIATO che i dispositivi Android TV supportino il profilo di decodifica HD 1080p e DEBBANO supportare il profilo di decodifica UHD. Quando il profilo di decodifica video UHD è supportato, DEVE supportare la profondità di colore a 8 bit e DOVREBBE supportare VP9 Profile 2 (10 bit).

	SD (bassa qualità)	SD (alta qualità)	HD 720p1	HD 1080p2	UHD2
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	60 FPS	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 Obbligatorio per le implementazioni dei dispositivi Android TV, ma per altri tipi di dispositivi solo se supportato dall'hardware.

2 FORTEMENTE CONSIGLIATO per le implementazioni esistenti dei dispositivi Android TV se supportate dall'hardware.

Le implementazioni dei dispositivi Android, se supportano il codec H.265 come descritto nella sezione 5.1.3, DEVONO supportare il livello principale del profilo principale di Livello 3 e i seguenti profili di decodifica video SD e DEVONO supportare i profili di decodifica HD. È FORTEMENTE CONSIGLIATO che i dispositivi Android TV supportino il profilo di decodifica UHD e il profilo di decodifica HD 1080p. Se il profilo di decodifica HD 1080p è supportato, DEVE supportare il livello principale del profilo principale di livello 4.1. Se la decodifica UHD è supportata, DEVE supportare il profilo Main10 di livello 5 del livello principale.

	SD (bassa qualità)	SD (alta qualità)	HD 720p1	HD 1080p2	UHD2
Risoluzione video	352 x 288 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	60 fps2	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	10 Mbps	20 Mbps

1 Obbligatorio per le implementazioni dei dispositivi Android TV, ma per altri tipi di dispositivi solo se supportato dall'hardware.

2 FORTEMENTE CONSIGLIATO per le implementazioni esistenti dei dispositivi Android TV, se supportate dall'hardware.

5.4. Registrazione audio

Sebbene alcuni dei requisiti descritti in questa sezione siano indicati come DOVREBBE da Android 4.3, è previsto di modificare la definizione di compatibilità per una versione futura in modo che diventino OBBLIGATORIO. Per i dispositivi Android esistenti e nuovi è FORTEMENTE CONSIGLIATO soddisfare questi requisiti indicati come DOVREBBE, altrimenti non potranno ottenere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

5.4.1. Acquisizione audio non compresso

Le implementazioni dei dispositivi che dichiarano android.hardware.microphone DEVONO consentire la registrazione di contenuti audio non elaborati con le seguenti caratteristiche:

• Formato: PCM lineare, 16 bit
• Frequenze di campionamento: 8000, 11025, 16000, 44100
• Canali: mono

L'acquisizione per le frequenze di campionamento sopra indicate DEVE essere eseguita senza upsampling e qualsiasi downsampling DEVE includere un filtro anti-aliasing appropriato.

Le implementazioni del dispositivo che dichiarano android.hardware.microphone DEVONO consentire l'acquisizione di contenuti audio non elaborati con le seguenti caratteristiche:

• Formato: PCM lineare, 16 bit
• Frequenze di campionamento: 22050, 48000
• Canali: stereo

Se l'acquisizione per le frequenze di campionamento sopra indicate è supportata, l'acquisizione DEVE essere eseguita senza upsampling a un rapporto superiore a 16000:22050 o 44100:48000. Qualsiasi upsampling o downsampling DEVE includere un filtro anti-aliasing appropriato.

5.4.2. Acquisisci per il riconoscimento vocale

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:

• Il dispositivo DEVE presentare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte: in particolare, ±3 dB, da 100 Hz a 4000 Hz.
• La sensibilità dell'ingresso audio DEVE essere impostata in modo che una sorgente con un livello di potenza sonora (SPL) di 90 dB a 1000 Hz generi un RMS di 2500 per i campioni a 16 bit.
• I livelli di ampiezza PCM DEVONO seguire in modo lineare le variazioni di SPL in ingresso in un intervallo di almeno 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 un livello di input di 90 dB SPL sul microfono.
• L'elaborazione di riduzione del rumore, se presente, DEVE essere disattivata.
• Il controllo automatico del guadagno, se presente, DEVE essere disattivato

Se la piattaforma supporta tecnologie di soppressione del rumore ottimizzate per il riconoscimento vocale, l'effetto DEVE essere controllabile dall'API android.media.audiofx.NoiseSuppressor. Inoltre, il campo UUID per il descrittore dell'effetto del rimuovi rumore DEVE identificare in modo univoco ogni implementazione della tecnologia di soppressione del rumore.

5.4.3. Acquisisci per il reindirizzamento della riproduzione

La classe android.media.MediaRecorder.AudioSource include l'origine audio REMOTE_SUBMIX. I dispositivi che dichiarano android.hardware.audio.output DEVONO implementare correttamente l'origine audio REMOTE_SUBMIX in modo che, quando un'applicazione utilizza l'API android.media.AudioRecord per registrare da questa origine audio, possa acquisire un mix di tutti gli stream audio, ad eccezione di quanto segue:

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

5.5. Riproduzione audio

Le implementazioni dei dispositivi che dichiarano android.hardware.audio.output DEVONO essere conformi ai requisiti di questa sezione.

5.5.1. Riproduzione audio non elaborata

Il dispositivo DEVE consentire la riproduzione di contenuti audio non elaborati con le seguenti caratteristiche:

• Formato: PCM lineare, 16 bit
• Frequenze di campionamento: 8000, 11025, 16000, 22050, 32000, 44100
• Canali: mono, stereo

Il dispositivo DEVE consentire la riproduzione di contenuti audio non elaborati con le seguenti caratteristiche:

• Frequenze di campionamento: 24000, 48000

5.5.2. Effetti audio

Android fornisce un'API per gli effetti audio per le implementazioni dei dispositivi [Risorse, 69]. Implementazioni del dispositivo che dichiarano la funzionalità android.hardware.audio.output:

• DEVE supportare le implementazioni EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controllabili tramite le sottoclassi AudioEffect Equalizer e LoudnessEnhancer.
• DEVE supportare l'implementazione dell'API di visualizzazione, controllabile tramite la classe Visualizer.
• DEVE supportare le implementazioni di EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB ed EFFECT_TYPE_VIRTUALIZER controllabili tramite i sottoclassi AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.

5.5.3. Volume uscita audio

Le implementazioni dei dispositivi Android TV DEVONO includere il supporto del volume master di sistema e dell'attenuazione del volume dell'uscita audio digitale sulle uscite supportate, tranne per l'uscita passthrough audio compresso (in cui non viene eseguita la decodifica audio sul dispositivo).

5.6. Latenza audio

La latenza audio è il ritardo temporale che si verifica quando un segnale audio passa attraverso un sistema. Molte classi di applicazioni si basano su latenze brevi per ottenere effetti sonori in tempo reale.

Ai fini di questa sezione, utilizza le seguenti definizioni:

• Latenza in uscita. L'intervallo tra il momento in cui un'applicazione scrive un frame di dati codificati in PCM e il momento in cui il suono corrispondente può essere ascoltato da un ascoltatore esterno o osservato da un trasduttore.
• Latenza di output a freddo. La latenza di uscita per il primo frame, quando il sistema di uscita audio è stato inattivo e spento prima della richiesta.
• Latenza di output continua. La latenza di uscita per i frame successivi, dopo che il dispositivo ha iniziato a riprodurre l'audio.
• Latenza di input. L'intervallo tra il momento in cui un suono esterno viene presentato al dispositivo e il momento in cui un'applicazione legge il frame corrispondente di dati codificati in PCM.
• Latenza di input a freddo. La somma del tempo di inserimento perso e della latenza di inserimento per il primo frame, quando il sistema di inserimento audio è inattivo e spento prima della richiesta.
• Latenza di input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.
• Jitter in uscita a freddo. La varianza tra misurazioni separate dei valori di latenza di output a freddo.
• Jitter di input a freddo. La varianza tra misurazioni separate dei valori della latenza di input a freddo.
• latenza di viaggio avanti e indietro continua. La somma della latenza di input continua più la latenza di output continua più un periodo di buffer. Il termine del periodo di buffer consente all'app di elaborare i dati e di attenuare la differenza di fase tra gli stream di input e di output.
• API OpenSL ES PCM buffer queue. L'insieme di API OpenSL ES correlate a PCM in Android NDK; consulta NDK_root/docs/opensles/index.html.

È FORTEMENTE CONSIGLIATO che le implementazioni dei dispositivi che dichiarano android.hardware.audio.output soddisfino o superino questi requisiti di uscita audio:

• latenza di output a freddo di massimo 100 millisecondi
• latenza di uscita continua di massimo 45 millisecondi
• ridurre al minimo il jitter dell'output a freddo

Se l'implementazione di un dispositivo soddisfa i requisiti di questa sezione dopo qualsiasi calibratura iniziale quando si utilizza l'API OpenSL ES PCM buffer queue, per la latenza di uscita continua e la latenza di uscita a freddo su almeno un dispositivo di uscita audio supportato, è MOLTO CONSIGLIATO segnalare il supporto dell'audio a bassa latenza, segnalando la funzionalità android.hardware.audio.low_latency tramite la classe android.content.pm.PackageManager [Risorse, 70]. Al contrario, se l'implementazione del dispositivo non soddisfa questi requisiti, NON deve segnalare il supporto dell'audio a bassa latenza.

È FORTEMENTE CONSIGLIATO che le implementazioni dei dispositivi che includono android.hardware.microphone soddisfino questi requisiti relativi all'audio di input:

• latenza di input a freddo di massimo 100 millisecondi
• latenza di input continua di massimo 30 millisecondi
• latenza nel tempo di round trip continua pari o inferiore a 50 millisecondi
• ridurre al minimo il jitter dell'input a freddo

5.7. Protocolli di rete

I dispositivi DEVONO supportare i protocolli della rete multimediale per la riproduzione audio e video come specificato nella documentazione dell'SDK Android [Risorse, 64]. In particolare, i dispositivi DEVONO supportare i seguenti protocolli di rete multimediale:

• RTSP (RTP, SDP)
• Streaming progressivo HTTP(S)
• HTTP(S) Live Streaming draft protocol, Version 3 [Resources, 71]

5.8. Contenuti multimediali sicuri

Le implementazioni dei dispositivi che supportano l'uscita video sicura e sono in grado di supportare le piattaforme sicure DEVONO dichiarare il supporto di Display.FLAG_SECURE. Le implementazioni dei dispositivi che dichiarano il supporto di Display.FLAG_SECURE, se supportano un protocollo di visualizzazione wireless, DEVONO proteggere il collegamento con un meccanismo di crittografia efficace, come HDCP 2.x o versioni successive per i display wireless Miracast. Analogamente, se supportano un display esterno con cavo, le implementazioni dei dispositivi DEVONO supportare HDCP 1.2 o versioni successive. Le implementazioni dei dispositivi Android TV DEVONO supportare HDCP 2.2 per i dispositivi che supportano la risoluzione 4K e HDCP 1.4 o versioni successive per le risoluzioni inferiori. L'implementazione open source di Android upstream include il supporto per i display wireless (Miracast) e cablati (HDMI) che soddisfano questo requisito.

5.9. Musical Instrument Digital Interface (MIDI)

Se un'implementazione del dispositivo supporta il trasporto software MIDI inter-app (dispositivi MIDI virtuali) e supporta MIDI su tutti i seguenti trasporti hardware compatibili con MIDI per i quali fornisce connettività generica non MIDI, è FORTEMENTE CONSIGLIATO segnalare il supporto della funzionalità android.software.midi tramite la classe android.content.pm.PackageManager [Risorse, 70].

I trasporti hardware compatibili con MIDI sono:

• Modalità host USB (sezione 7.7 USB)
• Modalità periferica USB (sezione 7.7 USB)

Al contrario, se l'implementazione del dispositivo fornisce connettività non MIDI generica tramite un determinato trasporto hardware compatibile con MIDI elencato sopra, ma non supporta MIDI tramite questo trasporto hardware, NON DEVE segnalare il supporto della funzionalità android.software.midi.

MIDI over Bluetooth LE che agisce nel ruolo centrale (sezione 7.4.3 Bluetooth) è in stato di utilizzo di prova. Un'implementazione del dispositivo che segnala la funzionalità android.software.midi e che fornisce connettività generica non MIDI tramite Bluetooth LE DEVE supportare MIDI tramite Bluetooth LE.

5.10. Audio professionale

Se l'implementazione di un dispositivo soddisfa tutti i seguenti requisiti, è FORTEMENTE CONSIGLIATO segnalare il supporto della funzionalità android.hardware.audio.pro tramite la classe android.content.pm.PackageManager [Risorse, 70].

• L'implementazione del dispositivo DEVE segnalare il supporto della funzionalità android.hardware.audio.low_latency.
• La latenza audio in tempo di round trip continuo, come definita nella sezione 5.6 Latenza audio, deve essere inferiore o uguale a 20 millisecondi e deve essere inferiore o uguale a 10 millisecondi su almeno un percorso supportato.
• Se il dispositivo include un jack audio da 3,5 mm a 4 conduttori, la latenza audio in tempo di round trip continuativa DEVE essere pari o inferiore a 20 millisecondi sul percorso del jack audio e DEVE essere pari o inferiore a 10 millisecondi sul percorso del jack audio.
• L'implementazione del dispositivo DEVE includere una o più porte USB che supportano la modalità host USB e la modalità periferica USB.
• La modalità host USB DEVE implementare la classe audio USB.
• Se il dispositivo include una porta HDMI, l'implementazione del dispositivo deve supportare l'uscita in stereo e a otto canali a una profondità di 20 o 24 bit e 192 kHz senza perdita di profondità di bit o ricampionamento.
• L'implementazione del dispositivo DEVE segnalare il supporto della funzionalità android.software.midi.
• Se il dispositivo include un jack audio da 3,5 mm a 4 conduttori, è FORTEMENTE CONSIGLIATO di rispettare la sezione Specifiche del dispositivo mobile (jack) della Specifiche delle cuffie audio con cavo (v1.1).

6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori

6.1. Strumenti per sviluppatori

Le implementazioni dei dispositivi DEVONO supportare gli Android Developer Tools forniti nell'SDK Android. I dispositivi Android compatibili DEVONO essere compatibili con:

• Android Debug Bridge (ADB) [Risorse, 72]

Le implementazioni dei dispositivi DEVONO supportare tutte le funzioni adb come documentato nell'SDK Android, incluso dumpsys [Risorse, 73]. Il daemon adb lato dispositivo DEVE essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivare Android Debug Bridge. Se l'implementazione di un dispositivo omette la modalità periferica USB, DEVE implementare il bridge di debug Android tramite una rete locale (ad esempio Ethernet o 802.11).

Android include il supporto per adb sicuro. adb sicuro attiva adb su host autenticati noti. Le implementazioni dei dispositivi DEVONO supportare adb sicuro.

• Dalvik Debug Monitor Service (ddms) [Risorse, 74]

Le implementazioni dei dispositivi DEVONO supportare tutte le funzionalità ddms come documentato nell'SDK Android. Poiché ddms utilizza adb, il supporto di ddms DOVREBBE essere inattivo per impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato Android Debug Bridge, come sopra.

• Monkey [Risorse, 75]

Le implementazioni dei dispositivi DEVONO includere il framework Monkey e renderlo disponibile per l'utilizzo da parte delle applicazioni.

• SysTrace [Risorse, 76]

Le implementazioni dei dispositivi DEVONO supportare lo strumento systrace come descritto nell'SDK Android. Systrace deve essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivarlo.

La maggior parte dei sistemi basati su Linux e dei sistemi Apple Macintosh riconosce i dispositivi Android utilizzando gli strumenti Android SDK standard, senza ulteriore supporto. Tuttavia, i sistemi Microsoft Windows in genere richiedono un driver per i nuovi dispositivi Android. Ad esempio, i nuovi ID fornitore e, a volte, i nuovi ID dispositivo richiedono driver USB personalizzati per i sistemi Windows. Se un'implementazione del dispositivo non è riconosciuta dallo strumento adb fornito nell'SDK Android standard, gli implementatori del dispositivo DEVONO fornire i driver Windows che consentono agli sviluppatori di connettersi al dispositivo utilizzando il protocollo adb. Questi driver DEVONO essere forniti per Windows XP, Windows Vista, Windows 7, Windows 8 e Windows 10 sia nelle versioni a 32 bit che a 64 bit.

6.2. Opzioni sviluppatore

Android include il supporto per la configurazione da parte degli sviluppatori delle impostazioni relative allo sviluppo delle applicazioni. Le implementazioni dei dispositivi DEVONO rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo dell'applicazione [Risorse, 77]. L'implementazione di Android a monte nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avviare le Opzioni sviluppatore dopo aver premuto sette volte la voce di menu Impostazioni > Informazioni sul dispositivo > Numero build. Le implementazioni dei dispositivi DEVONO fornire un'esperienza coerente per le Opzioni sviluppatore. Nello specifico, le implementazioni dei dispositivi DEVONO nascondere le Opzioni sviluppatore per impostazione predefinita e DEVONO fornire un meccanismo per attivarle in modo coerente con l'implementazione di Android a monte.

7. Compatibilità hardware

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

• Le definizioni complete delle classi (come documentato dall'SDK) per le API dei componenti devono essere ancora presentate.
• I comportamenti dell'API DEVONO essere implementati come no-op in modo ragionevole.
• I metodi dell'API DEVONO restituire valori null se consentito dalla documentazione dell'SDK.
• I metodi API DEVONO restituire implementazioni no-op delle classi in cui i valori null non sono consentiti dalla documentazione dell'SDK.
• I metodi API NON DEVONO generare eccezioni non documentate dalla documentazione dell'SDK.

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

Le implementazioni dei dispositivi DEVONO segnalare in modo coerente informazioni accurate sulla configurazione hardware tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) della classe android.content.pm.PackageManager per la stessa impronta di compilazione. [Resources, 70]

7.1. Display e grafica

Android include funzionalità che regolano automaticamente gli asset dell'applicazione e i layout dell'interfaccia utente in base al dispositivo, per garantire il corretto funzionamento delle applicazioni di terze parti su una serie di configurazioni hardware [Risorse, 78]. I dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

Le unità a cui fanno riferimento i requisiti in questa sezione sono definite come segue:

• Dimensioni diagonali fisiche. La distanza in pollici tra due angoli opposti della parte illuminata del display.
• Punti per pollice (DPI). Il numero di pixel inclusi in un intervallo lineare orizzontale o verticale di 1". Se sono elencati i valori dpi, sia quelli orizzontali che quelli verticali devono rientrare nell'intervallo.
• proporzioni. Il rapporto tra i pixel della dimensione più lunga e la dimensione più corta dello schermo. Ad esempio, un display di 480 x 854 pixel equivale a 854/480 = 1,779, ovvero approssimativamente "16:9".
• pixel indipendente dalla densità (dp) L'unità di pixel virtuale normalizzata a uno schermo di 160 dpi, calcolata come segue: pixel = dps * (densità/160).

7.1.1. Configurazione schermo

7.1.1.1. Dimensioni schermo

Il framework UI di Android supporta una serie di dimensioni dello schermo diverse e consente alle applicazioni di eseguire query sulle dimensioni dello schermo del dispositivo (ovvero "layout dello schermo") tramite android.content.res.Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK. Le implementazioni dei dispositivi DEVONO segnalare le dimensioni dello schermo corrette come definite nella documentazione dell'SDK Android [Risorse, 78] e determinate dalla piattaforma Android a monte. Nello specifico, le implementazioni dei dispositivi DEVONO segnalare le dimensioni dello schermo corrette in base alle seguenti dimensioni dello schermo in pixel indipendenti dalla densità (dp) logici.

• I dispositivi DEVONO avere dimensioni dello schermo di almeno 426 dp x 320 dp ("piccolo"), a meno che non si tratti di un dispositivo Android Watch.
• I dispositivi che segnalano una dimensione dello schermo "normale" DEVONO avere dimensioni dello schermo di almeno 480 dp x 320 dp.
• I dispositivi che segnalano dimensioni dello schermo "grandi" DEVONO avere dimensioni dello schermo di almeno 640 dp x 480 dp.
• I dispositivi che segnalano dimensioni dello schermo "Molto grande" DEVONO avere dimensioni dello schermo di almeno 960 dp x 720 dp.

Inoltre, queste

• I dispositivi Android Watch DEVONO avere uno schermo con diagonale fisica compresa tra 28 e 64 mm.
• Altri tipi di implementazioni di dispositivi Android, con uno schermo integrato fisicamente, DEVONO avere uno schermo con una diagonale fisica di almeno 6,35 cm.

I dispositivi NON DEVONO modificare le dimensioni dello schermo registrate in nessun momento.

Le applicazioni possono indicare facoltativamente le dimensioni dello schermo supportate tramite l'attributo <supports-screens> nel file AndroidManifest.xml. Le implementazioni dei dispositivi DEVONO rispettare correttamente il supporto dichiarato dalle applicazioni per schermi piccoli, normali, grandi e molto grandi, come descritto nella documentazione dell'SDK Android.

7.1.1.2. Proporzioni dello schermo

Il formato dello schermo DEVE essere un valore compreso tra 1,3333 (4:3) e 1,86 (circa 16:9), ma i dispositivi Android Watch POSSONO avere un formato 1,0 (1:1) perché l'implementazione di un dispositivo di questo tipo utilizzerà un valore UI_MODE_TYPE_WATCH come android.content.res.Configuration.uiMode.

7.1.1.3. Densità schermo

Il framework UI di Android definisce un insieme di densità logiche standard per aiutare gli sviluppatori di applicazioni a scegliere come target le risorse dell'applicazione. Le implementazioni dei dispositivi devono segnalare solo una delle seguenti densità logiche del framework Android tramite le API android.util.DisplayMetrics, devono eseguire le applicazioni a questa densità standard e non devono modificare il valore in nessun momento per la visualizzazione predefinita.

• 120 dpi (ldpi)
• 160 dpi (mdpi)
• 213 dpi (tvdpi)
• 240 dpi (hdpi)
• 280 dpi (280dpi)
• 320 dpi (xhdpi)
• 360 dpi (360dpi)
• 400 dpi (400dpi)
• 420 dpi (420dpi)
• 480 dpi (xxhdpi)
• 560 dpi (560dpi)
• 640 dpi (xxxhdpi)

Le implementazioni dei dispositivi DOVREBBERO definire la densità del framework Android standard che è numericamente più vicina alla densità fisica dello schermo, a meno che la densità logica non riduca le dimensioni dello schermo registrate al di sotto del minimo supportato. Se la densità del framework Android standard più vicina numericamente alla densità fisica genera dimensioni dello schermo inferiori alle dimensioni dello schermo compatibile più piccole supportate (larghezza di 320 dp), le implementazioni del dispositivo DEVONO registrare la densità del framework Android standard successiva più bassa.

7.1.2. Metriche relative alla visualizzazione

Le implementazioni dei dispositivi DEVONO riportare valori corretti per tutte le metriche del display definite in android.util.DisplayMetrics [Resources, 79] e DEVONO riportare gli stessi valori indipendentemente dall'utilizzo dello schermo integrato o esterno come display predefinito.

7.1.3. Orientamento schermo

I dispositivi DEVONO indicare gli orientamenti dello 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, come una TV o un laptop, DOVREBBE registrare solo android.hardware.screen.landscape.

I dispositivi che segnalano entrambi gli orientamenti dello schermo DEVONO supportare l'orientamento dinamico da parte delle applicazioni sia in orientamento verticale che orizzontale. In altre parole, il dispositivo deve rispettare la richiesta dell'applicazione di un orientamento specifico dello schermo. Le implementazioni dei dispositivi POSSONO selezionare l'orientamento verticale o orizzontale come predefinito.

I dispositivi DEVONO segnalare il valore corretto per l'orientamento corrente del dispositivo, ogni volta che viene eseguito una query tramite android.content.res.Configuration.orientation, android.view.Display.getOrientation() o altre API.

I dispositivi NON DEVONO modificare le dimensioni o la densità dello schermo registrate quando si cambia orientamento.

7.1.4. Accelerazione grafica 2D e 3D

Le implementazioni dei dispositivi DEVONO supportare sia OpenGL ES 1.0 sia 2.0, come descritto e dettagliato nella documentazione dell'SDK Android. Le implementazioni dei dispositivi DEVONO supportare OpenGL ES 3.0 o 3.1 sui dispositivi in grado di supportarlo. Le implementazioni dei dispositivi DEVONO supportare anche Android RenderScript, come descritto nella documentazione dell'SDK Android [Risorse, 80].

Le implementazioni dei dispositivi DEVONO anche identificarsi correttamente come supportanti OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 o OpenGL 3.1. ovvero:

• Le API gestite (ad esempio tramite il metodo GLES10.getString()) DEVONO segnalare il supporto per OpenGL ES 1.0 e OpenGL ES 2.0.
• Le API OpenGL native C/C++ (API disponibili per le app tramite libGLES_v1CM.so, libGLES_v2.so o libEGL.so) DEVONO segnalare il supporto per OpenGL ES 1.0 e OpenGL ES 2.0.
• Le implementazioni dei dispositivi che dichiarano il supporto di OpenGL ES 3.0 o 3.1 DEVONO supportare le API gestite corrispondenti e includere il supporto per le API C/C++ native. Nelle implementazioni del dispositivo che dichiarano il supporto di OpenGL ES 3.0 o 3.1, libGLESv2.so DEVE esportare i simboli di funzione corrispondenti oltre ai simboli di funzione di OpenGL ES 2.0.

Oltre a OpenGL ES 3.1, Android fornisce un pacchetto di estensioni con interfacce Java [Risorse, 81] e il supporto nativo per funzionalità grafiche avanzate come la tessellation e il formato di compressione delle texture ASTC. Le implementazioni dei dispositivi Android POSSONO supportare questo pacchetto di estensioni e, solo se completamente implementate, DEVONO identificare il supporto tramite il flag della funzionalità android.hardware.opengles.aep.

Inoltre, le implementazioni dei dispositivi POSSONO implementare le estensioni OpenGL ES desiderate. Tuttavia, le implementazioni dei dispositivi DEVONO segnalare tramite le API native e gestite di OpenGL ES tutte le stringhe di estensione supportate e, al contrario, NON DEVONO segnalare le stringhe di estensione non supportate.

Tieni presente che Android include il supporto per le applicazioni che possono specificare facoltativamente che richiedono formati di compressione delle texture OpenGL specifici. Questi formati sono tipicamente specifici del fornitore. Le implementazioni dei dispositivi non sono richieste da Android per implementare un formato di compressione delle texture specifico. Tuttavia, DOVREBBERO segnalare con precisione tutti i formati di compressione delle texture supportati tramite il metodo getString() nell'API OpenGL.

Android include un meccanismo per consentire alle applicazioni di dichiarare di voler attivare l'accelerazione hardware per la grafica 2D a livello di applicazione, attività, finestra o visualizzazione tramite l'utilizzo di un tag manifest android:hardwareAccelerated o chiamate API dirette [Risorse, 82].

Le implementazioni dei dispositivi DEVONO attivare l'accelerazione hardware per impostazione predefinita e DEVONO disattivarla se lo sviluppatore lo richiede impostando android:hardwareAccelerated="false" o disattivando l'accelerazione hardware direttamente tramite le API View di Android.

Inoltre, le implementazioni dei dispositivi DEVONO mostrare un comportamento coerente con la documentazione dell'SDK Android sull'accelerazione hardware [Risorse, 82].

Android 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 dell'interfaccia utente. Le implementazioni dei dispositivi DEVONO supportare l'API TextureView e DEVONO avere un comportamento coerente con l'implementazione di Android a monte.

Android include il supporto di EGL_ANDROID_RECORDABLE, un attributo EGLConfig che indica se EGLConfig supporta il rendering in un ANativeWindow che registra le immagini in un video. Le implementazioni dei dispositivi DEVONO supportare l'estensione EGL_ANDROID_RECORDABLE [Risorse, 83].

7.1.5. Modalità di compatibilità delle applicazioni precedenti

Android specifica una "modalità di compatibilità" in cui il framework opera in una modalità equivalente alle dimensioni dello schermo "normali" (larghezza di 320 dp) a vantaggio delle applicazioni precedenti non sviluppate per le versioni precedenti di Android che risalgono a prima dell'indipendenza dalle dimensioni dello schermo.

• Android Automotive non supporta la modalità di compatibilità precedente.
• Tutte le altre implementazioni dei dispositivi DEVONO includere il supporto della modalità di compatibilità delle applicazioni legacy come implementata dal codice open source di Android upstream. In altre parole, le implementazioni dei dispositivi NON DEVONO alterare gli attivatori o le soglie a cui viene attivata la modalità di compatibilità e NON DEVONO alterare il comportamento della stessa modalità di compatibilità.

7.1.6. Tecnologia dello schermo

La piattaforma Android include API che consentono alle applicazioni di eseguire il rendering di grafica avanzata sul display. I dispositivi DEVONO supportare tutte queste API come definite dall'SDK Android, a meno che non sia specificamente consentito in questo documento.

• I dispositivi DEVONO supportare display in grado di eseguire il rendering di grafica a colori a 16 bit e DEVONO 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 delle animazioni.
• La tecnologia di visualizzazione utilizzata DEVE avere un rapporto di aspetto dei pixel (PAR) compreso tra 0,9 e 1,15. In altre parole, le proporzioni dei pixel DEVONO essere quasi quadrate (1,0) con una tolleranza del 10-15%.

7.1.7. Display secondari

Android include il supporto per il display secondario per abilitare le funzionalità di condivisione dei contenuti multimediali e le API per sviluppatori per accedere ai display esterni. Se un dispositivo supporta un display esterno tramite una connessione con cavo, wireless o un display aggiuntivo integrato, l'implementazione del dispositivo DEVE implementare l'API Display Manager come descritto nella documentazione dell'SDK Android [Risorse, 84].

7.2. Dispositivi di immissione

I dispositivi DEVONO supportare un touchscreen o soddisfare i requisiti elencati in 7.2.2 per la navigazione non tocco.

7.2.1. Tastiera

Implementazioni dei dispositivi:

• DEVE includere il supporto per il framework di gestione dell'input (che consente agli sviluppatori di terze parti di creare editor di metodi di inserimento, ovvero tastiere virtuali) come descritto all'indirizzo http://developer.android.com.
• DEVE fornire almeno un'implementazione di tastiera software (indipendentemente dal fatto che sia presente una tastiera hardware), ad eccezione dei dispositivi Android Watch in cui le dimensioni dello schermo rendono meno ragionevole avere una tastiera software.
• POTREBBE includere implementazioni aggiuntive della tastiera su schermo.
• POTREBBE includere una tastiera hardware.
• NON DEVE includere una tastiera hardware che non corrisponde a uno dei formati specificati in android.content.res.Configuration.keyboard [Resources, 85] (QWERTY o 12 tasti).

7.2.2. Navigazione non tocco

Implementazioni dei dispositivi:

• È POSSIBILE omettere un'opzione di navigazione non tocco (trackball, d-pad o rotella) se l'implementazione del dispositivo non è un dispositivo Android TV.
• DEVE riportare il valore corretto per android.content.res.Configuration.navigation [Resources, 85].
• DEVE fornire un meccanismo di interfaccia utente alternativo ragionevole per la selezione e la modifica del testo, compatibile con i motori di gestione dell'input. L'implementazione open source di Android upstream include un meccanismo di selezione adatto per l'utilizzo con dispositivi che non dispongono di input di navigazione non touch.

7.2.3. Tasti di navigazione

Le funzioni Home, Recenti e Indietro (rispettivamente mappate agli eventi chiave KEYCODE_HOME, KEYCODE_APP_SWITCH, KEYCODE_BACK) sono essenziali per il paradigma di navigazione di Android e, pertanto:

• Le implementazioni dei dispositivi Android portatili DEVONO fornire le funzioni Home, Recenti e Indietro.
• Le implementazioni dei dispositivi Android TV DEVONO fornire le funzioni Home e Indietro.
• Le implementazioni dei dispositivi Android Watch DEVONO avere la funzione Home disponibile per l'utente e la funzione Indietro, tranne quando è in UI_MODE_TYPE_WATCH.
• Le implementazioni di Android Automotive DEVONO fornire la funzione Home e POSSONO fornire le funzioni Indietro e Recenti.
• Tutti gli altri tipi di implementazioni dei dispositivi DEVONO fornire le funzioni Home e Indietro.

Queste funzioni POSSONO essere implementate tramite pulsanti fisici dedicati (ad esempio pulsanti touch meccanici o capacitivi) o POSSONO essere implementate utilizzando tasti software dedicati su una parte distinta dello schermo, gesti, pannello touch e così via. Android supporta entrambe le implementazioni. Tutte queste funzioni DEVONO essere accessibili con una singola azione (ad es. tocco, doppio clic o gesto) quando sono visibili.

La funzione Recenti, se fornita, DEVE avere un pulsante o un'icona visibile, a meno che non sia nascosta insieme ad altre funzioni di navigazione in modalità a schermo intero. Questo non si applica ai dispositivi su cui viene eseguito l'upgrade da versioni precedenti di Android che dispongono di pulsanti fisici per la navigazione e non hanno il tasto Recenti.

Le funzioni Home e Indietro, se fornite, DEVONO avere ciascuna un pulsante o un'icona visibili, a meno che non siano nascoste insieme ad altre funzioni di navigazione in modalità a schermo intero o quando uiMode UI_MODE_TYPE_MASK è impostato su UI_MODE_TYPE_WATCH.

La funzione Menu è stata ritirata a favore della barra delle app da Android 4.0. Pertanto, le implementazioni dei nuovi dispositivi con Android 6.0 e versioni successive NON DEVONO implementare un pulsante fisico dedicato per la funzione Menu. Le implementazioni dei dispositivi meno recenti NON DEVONO implementare un pulsante fisico dedicato per la funzione Menu, ma se il pulsante Menu fisico è implementato e il dispositivo esegue applicazioni con targetSdkVersion > 10, l'implementazione del dispositivo:

• DEVE mostrare il pulsante del menu extra delle azioni nella barra delle azioni quando è visibile e il menu popup del menu extra delle azioni risultante non è vuoto. Per un'implementazione di un dispositivo lanciata prima di Android 4.4, ma con upgrade ad Android 6.0, questa è la soluzione CONSIGLIATA.
• NON DEVE modificare la posizione del popup del menu extra delle azioni visualizzato selezionando il pulsante del menu extra nella barra delle azioni.
• POTREBBE visualizzare il popup extra delle azioni in una posizione modificata sullo schermo quando viene visualizzato selezionando il pulsante del menu fisico.

Per la compatibilità con le versioni precedenti, le implementazioni dei dispositivi DEVONO rendere disponibile la funzione Menu per le applicazioni quando targetSdkVersion è inferiore a 10, tramite un pulsante fisico, una chiave software o gesti. Questa funzione Menu deve essere presentata se non nascosta insieme ad altre funzioni di navigazione.

Le implementazioni dei dispositivi Android con il supporto dell'azione di assistenza [Risorse, 30] DEVONO rendere questa opzione accessibile con una singola azione (ad es. tocco, doppio clic o gesto) quando sono visibili altri tasti di navigazione ed è FORTEMENTE CONSIGLIATO di usare la pressione prolungata sul tasto Home o sul tasto software come singola azione.

Le implementazioni dei dispositivi 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 per l'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 dei dispositivi DEVONO rendere disponibile una parte del display per le applicazioni che soddisfano i requisiti definiti nella sezione 7.1.1.
• Le implementazioni dei dispositivi DEVONO mostrare 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 invadente quando le applicazioni specificano SYSTEM_UI_FLAG_LOW_PROFILE.
• Le implementazioni dei dispositivi DEVONO nascondere i tasti di navigazione quando le applicazioni specificano SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Input touchscreen

Le implementazioni dei dispositivi DEVONO avere un sistema di input del cursore di qualche tipo (simile a un mouse o tocco). Tuttavia, se l'implementazione di un dispositivo non supporta un sistema di input del cursore, NON DEVE segnalare la costante della funzionalità android.hardware.touchscreen o android.hardware.faketouch. Implementazioni di dispositivi che includono un sistema di input del cursore:

• DOVREBBE supportare cursori monitorati in modo completamente indipendente, se il sistema di input del dispositivo supporta più cursori.
• DEVE riportare il valore di android.content.res.Configuration.touchscreen [Risorse, 85] corrispondente al tipo di touchscreen specifico sul dispositivo.

Android include il supporto di una serie di touchscreen, touchpad e dispositivi di input touch simulati. Le implementazioni dei dispositivi basati su touchscreen sono associate a un display [Risorse, 86] 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'altra funzionalità per indicare gli oggetti manipolati. Al contrario, un'interfaccia tocco falsa fornisce un sistema di input utente che approssima un sottoinsieme di funzionalità del touchscreen. Ad esempio, un mouse o un controllino remoto che gestisce un cursore sullo schermo si avvicina al tocco, ma richiede all'utente di prima selezionare o mettere a fuoco un elemento e poi fare clic. Numerosi dispositivi di input come mouse, trackpad, mouse aereo basato su giroscopio, cursore a giroscopio, joystick e trackpad multi-touch possono supportare interazioni touch false. Android include la costante di funzionalità android.hardware.faketouch, che corrisponde a un dispositivo di input non touch (basato su cursore) ad alta fedeltà, come un mouse o un trackpad, che può emulare adeguatamente l'input basato sul tocco (incluso il supporto di gesti di base) e indica che il dispositivo supporta un sottoinsieme emulato delle funzionalità del touchscreen. Le implementazioni dei dispositivi che dichiarano la funzionalità di tocco falso DEVONO soddisfare i requisiti relativi al tocco falso descritti nella sezione 7.2.5.

Le implementazioni dei dispositivi DEVONO segnalare la funzionalità corretta corrispondente al tipo di input utilizzato. Le implementazioni dei dispositivi che includono un touchscreen (single-touch o superiore) DEVONO segnalare la costante della funzionalità della piattaforma android.hardware.touchscreen. Le implementazioni dei dispositivi 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 dei dispositivi che non includono un touchscreen (e si basano solo su un dispositivo di puntamento) NON DEVONO segnalare alcuna funzionalità del touchscreen e DEVONO segnalare solo android.hardware.faketouch se soddisfano i requisiti di tocco falso descritti nella sezione 7.2.5.

7.2.5. Input tocco simulato

Implementazioni del dispositivo che dichiarano il supporto di android.hardware.faketouch:

• DEVE segnalare le posizioni X e Y assolute dello schermo della posizione del cursore e mostrare un cursore visivo sullo schermo [Risorse, 87].
• DEVE segnalare l'evento tocco con il codice di azione che specifica la variazione di stato che si verifica quando il cursore si sposta verso il basso o verso l'alto sullo schermo [Risorse, 87].
• DEVE supportare il movimento del cursore verso il basso e verso l'alto su un oggetto sullo schermo, il che consente agli utenti di simulare il tocco di un oggetto sullo schermo.
• DEVE supportare il cursore verso il basso, il cursore verso l'alto, il cursore verso il basso e poi il cursore verso l'alto nello stesso luogo su un oggetto sullo schermo entro una soglia di tempo, che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo [Risorse, 87].
• DEVE supportare il cursore verso il basso in un punto arbitrario dello schermo, il cursore si sposta in qualsiasi altro punto arbitrario dello schermo, seguito da un cursore verso l'alto, che consente agli utenti di emulare un trascinamento con tocco.
• DEVE supportare il cursore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in un'altra posizione sullo schermo e poi verso l'alto sullo schermo, il che consente agli utenti di lanciare un oggetto sullo schermo.

I dispositivi che dichiarano il supporto di android.hardware.faketouch.multitouch.distinct devono soddisfare i requisiti per il faketouch sopra indicati e devono anche supportare il monitoraggio distinto di due o più input del cursore indipendenti.

7.2.6. Supporto del controller di gioco

Le implementazioni dei dispositivi Android TV DEVONO supportare le mappature dei pulsanti per i controller per giochi come elencato di seguito. L'implementazione di Android a monte include l'implementazione per i controller di gioco che soddisfano questo requisito.

7.2.6.1. Mappature dei pulsanti

Le implementazioni dei dispositivi Android TV DEVONO supportare le seguenti mappature delle chiavi:

Pulsante	Utilizzo HID2	Pulsante Android
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Pulsante direzionale su1 Pulsante direzionale giù1	0x01 0x00393	AXIS_HAT_Y4
D-pad sinistra1 D-pad destra1	0x01 0x00393	AXIS_HAT_X4
Pulsante del tasto sinistro1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Pulsante del tasto funzione destro1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic con la levetta sinistra1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic con il tasto destro della levetta1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Home1	0x0c 0x0223	KEYCODE_HOME (3)
Indietro1	0x0c 0x0224	KEYCODE_BACK (4)

1 [Risorse, 88]

2 Gli utilizzi HID sopra indicati devono essere dichiarati all'interno di una CA per gamepad (0x01 0x0005).

3 Questo utilizzo deve avere un valore minimo logico di 0, un valore massimo logico di 7, un valore minimo fisico di 0, un valore massimo fisico di 315, unità in gradi e una dimensione del report di 4. Il valore logico è definito come la rotazione in senso orario allontanata dall'asse verticale; ad esempio, un valore logico pari a 0 rappresenta nessuna rotazione e il pulsante su premuto, mentre un valore logico pari a 1 rappresenta una rotazione di 45 gradi e i tasti su e sinistra premuti.

4 [Risorse, 87]

Controlli analogici1	Utilizzo HID	Pulsante Android
Triangolo sinistro	0x02 0x00C5	AXIS_LTRIGGER
Trigger destro	0x02 0x00C4	AXIS_RTRIGGER
Joystick sinistro	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick destro	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 [Risorse, 87]

7.2.7. Telecomando

Le implementazioni dei dispositivi Android TV DEVONO fornire un telecomando per consentire agli utenti di accedere all'interfaccia TV. Il telecomando PUÒ essere un telecomando fisico o un telecomando basato su software accessibile da un cellulare o un tablet. Il telecomando DEVE soddisfare i requisiti definiti di seguito.

• Affordance di ricerca. Le implementazioni del dispositivo DEVONO attivare KEYCODE_SEARCH (o KEYCODE_ASSIST se il dispositivo supporta un assistente) quando l'utente richiama la ricerca vocale sul telecomando fisico o basato su software.
• Navigazione. Tutti i telecomandi di Android TV DEVONO includere i pulsanti Indietro, Home e Seleziona e supportare gli eventi del D-pad [Risorse, 88].

7.3. Sensori

Android include API per accedere a diversi tipi di sensori. Le implementazioni dei dispositivi in genere POSSONO omettere questi sensori, come previsto nelle seguenti sezioni. Se un dispositivo include un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android e nella documentazione Android Open Source sui sensori [Risorse, 89]. Ad esempio, le implementazioni dei dispositivi:

• DEVE segnalare con precisione la presenza o l'assenza di sensori in base alla classe android.content.pm.PackageManager [Resources, 70].
• DEVE restituire un elenco accurato dei sensori supportati tramite SensorManager.getSensorList() e metodi simili.
• DEVE comportarsi in modo ragionevole per tutte le altre API di sensori (ad esempio, restituendo true o false a seconda dei casi quando le applicazioni tentano di registrare gli ascoltatori, non chiamando gli ascoltatori dei sensori quando i sensori corrispondenti non sono presenti e così via).
• DEVE segnalare tutte le misurazioni del sensore utilizzando i valori pertinenti del Sistema internazionale di misura (metrico) per ciascun tipo di sensore come definito nella documentazione dell'SDK Android [Risorse, 90].
• DOVREBBE registrare la data e l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta la data e l'ora in cui si è verificato l'evento e sincronizzata con il sistema SystemClock.elapsedRealtimeNano(). È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle future release della piattaforma, in cui questo potrebbe diventare un componente OBBLIGATORIO. L'errore di sincronizzazione DEVE essere inferiore a 100 millisecondi [Risorse, 91].
• DEVE segnalare i dati del sensore con una latenza massima di 100 millisecondi + 2 * sample_time per il caso di un sensore in streaming con una latenza minima richiesta di 5 ms + 2 * sample_time quando il processore dell'applicazione è attivo. Questo ritardo non include i ritardi dovuti ai filtri.
• DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time dall'attivazione del sensore. È accettabile che questo campione abbia una precisione pari a 0.

L'elenco riportato sopra non è esaustivo; il comportamento documentato dell'SDK Android e le documentazioni Android Open Source sui sensori [Risorse, 89] devono essere considerati autorevoli.

Alcuni tipi di sensori sono composti, il che significa che possono essere ricavati dai dati forniti da uno o più altri sensori. Alcuni esempi sono il sensore di orientamento e il sensore di accelerazione lineare. Le implementazioni dei dispositivi DOVREBBERO implementare questi tipi di sensori, se includono i sensori fisici prerequisiti come descritto in [Risorse, 92]. Se l'implementazione di un dispositivo include un sensore composito, DEVE implementare il sensore come descritto nella documentazione Android Open Source sui sensori compositi [Risorse, 92].

Alcuni sensori Android supportano una modalità di attivazione "continua", che restituisce i dati continuamente [Risorse, 93]. Affinché qualsiasi API indicata dalla documentazione dell'SDK Android sia un sensore continuo, le implementazioni del dispositivo DEVONO fornire continuamente campioni di dati periodici che DOVREBBERO avere un jitter inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori timestamp registrati tra gli eventi consecutivi.

Tieni presente che le implementazioni del dispositivo DEVONO garantire che lo stream di eventi del sensore NON DEVE impedire alla CPU del dispositivo di entrare in uno stato di sospensione o di risvegliarsi da uno stato di sospensione.

Infine, quando sono attivati più sensori, il consumo di energia NON DEVE superare la somma del consumo di energia registrato dal singolo sensore.

7.3.1. Accelerometro

Le implementazioni dei dispositivi DEVONO includere un accelerometro a 3 assi. È FORTEMENTE CONSIGLIATO includere questo sensore nei dispositivi Android e Android Watch. Se l'implementazione di un dispositivo include un accelerometro a 3 assi:

• DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER [Risorse, 94].
• DEVE essere in grado di registrare eventi fino a una frequenza di almeno 50 Hz per i dispositivi Android Watch, in quanto questi dispositivi hanno un vincolo di potenza più rigoroso, e di 100 Hz per tutti gli altri tipi di dispositivi.
• DEVE registrare eventi fino ad almeno 200 Hz.
• DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nelle API Android [Risorse, 90].
• DEVE essere in grado di misurare dalla caduta libera fino a quattro volte la gravità (4 g) o più su qualsiasi asse.
• DEVE avere una risoluzione minima di 12 bit e DOVREBBE avere una risoluzione minima di almeno 16 bit.
• DEVE essere calibrato durante l'uso se le caratteristiche cambiano nel ciclo di vita e vengono compensate e deve conservare i parametri di compensazione tra i riavvii del dispositivo.
• DEVE essere compensato in base alla temperatura.
• DEVE avere una deviazione standard non superiore a 0,05 m/s^, dove la deviazione standard deve essere calcolata in base all'asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più elevata.
• DEVE implementare i sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento SDK Android. Per i dispositivi Android esistenti e nuovi è FORTEMENTE CONSIGLIATO implementare il sensore composito TYPE_SIGNIFICANT_MOTION. Se uno di questi sensori è implementato, la somma del loro consumo di energia DEVE essere sempre inferiore a 4 mW e OGNI sensore DEVE essere inferiore a 2 mW e 0,5 mW quando il dispositivo è in una condizione dinamica o statica.
• Se è incluso un sensore giroscopico, DEVE implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION e DOVREBBE implementare il sensore composito TYPE_GAME_ROTATION_VECTOR. Per i dispositivi Android esistenti e nuovi è FORTEMENTE CONSIGLIATO implementare il sensore TYPE_GAME_ROTATION_VECTOR.
• DEVE implementare un sensore composito TYPE_ROTATION_VECTOR, se sono inclusi anche un sensore giroscopico e un sensore magnetometrico.

7.3.2. Magnetometro

Le implementazioni dei dispositivi DEVONO includere un magnetometro a 3 assi (bussola). Se un dispositivo include un magnetometro a 3 assi:

• DEVE implementare il sensore TYPE_MAGNETIC_FIELD e DEVE anche implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED. È MOLTO CONSIGLIATO implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED sui dispositivi Android esistenti e nuovi.
• DEVE essere in grado di registrare eventi fino a una frequenza di almeno 10 Hz e DEVE registrare eventi fino ad almeno 50 Hz.
• DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nelle API Android [Risorse, 90].
• DEVE essere in grado di misurare tra -900 µT e +900 µT su ogni asse prima di saturare.
• DEVE avere un valore di offset del ferro duro inferiore a 700 µT e DOVREBBE avere un valore inferiore a 200 µT, posizionando il magnetometro lontano da campi magnetici dinamici (indotti dalla corrente) e statici (indotti dal magnete).
• DEVE avere una risoluzione uguale o superiore a 0,6 µT e DEVE avere una risoluzione uguale o superiore a 0,2 µ.
• DEVE essere compensato in base alla temperatura.
• DEVE supportare la calibrazione e la compensazione online dell'errore di hard iron e conservare i parametri di compensazione tra i riavvii del dispositivo.
• DEVE essere applicata la compensazione del ferro dolce. La calibrazione può essere eseguita durante l'uso o durante la produzione del dispositivo.
• DEVE avere una deviazione standard, calcolata in base all'asse, sui campioni raccolti su un periodo di almeno 3 secondi alla frequenza di campionamento più elevata, non superiore a 0,5 µT.
• DEVE implementare un sensore composito TYPE_ROTATION_VECTOR, se sono inclusi anche un sensore di accelerazione e un sensore di giroscopio.
• PUO' implementare il sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR se è implementato anche un sensore di accelerazione. Tuttavia, se implementato, DEVE consumare meno di 10 mW e DOVREBBE consumare meno di 3 mW quando il sensore è registrato per la modalità batch a 10 Hz.

7.3.3. GPS

Le implementazioni dei dispositivi DEVONO includere un ricevitore GPS. Se l'implementazione di un dispositivo include un ricevitore GPS, DEVE includere una qualche forma di tecnica "GPS assistito" per ridurre al minimo il tempo di accoppiamento del GPS.

7.3.4. Giroscopio

Le implementazioni dei dispositivi DEVONO includere un giroscopio (sensore di variazione angolare). I dispositivi NON DEVONO includere un sensore giroscopio, a meno che non sia incluso anche un accelerometro a 3 assi. Se l'implementazione di un dispositivo include un giroscopio:

• DEVE implementare il sensore TYPE_GYROSCOPE e DEVE anche implementare il sensore TYPE_GYROSCOPE_UNCALIBRATED. Per i dispositivi Android esistenti e nuovi è MOLTO CONSIGLIATO implementare il sensore SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
• DEVE essere in grado di misurare le variazioni di orientamento fino a 1000 gradi al secondo.
• DEVE essere in grado di registrare eventi fino a una frequenza di almeno 50 Hz per i dispositivi Android Watch, in quanto questi dispositivi hanno un vincolo di potenza più rigoroso, e di 100 Hz per tutti gli altri tipi di dispositivi.
• DEVE registrare eventi fino ad almeno 200 Hz.
• DEVE avere una risoluzione di almeno 12 bit e DOVREBBE avere una risoluzione di almeno 16 bit.
• DEVE essere compensato in base alla temperatura.
• DEVE essere calibrato e compensato durante l'uso e deve conservare i parametri di compensazione tra i riavvii del dispositivo.
• DEVE avere una varianza non superiore a 1e-7 rad^2 / s^2 per Hz (varianza per Hz o rad^2 / s). La varianza può variare con la frequenza di campionamento, ma deve essere limitata da questo valore. In altre parole, se misuri la varianza del giroscopio a una frequenza di campionamento di 1 Hz, non deve essere superiore a 1e-7 rad^2/s^2.
• DEVE implementare un sensore composito TYPE_ROTATION_VECTOR, se sono inclusi anche un sensore di accelerazione e un sensore magnetometrico.
• Se è incluso un sensore di accelerazione, DEVE implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION e DOVREBBE implementare il sensore composito TYPE_GAME_ROTATION_VECTOR. Per i dispositivi Android esistenti e nuovi è FORTEMENTE CONSIGLIATO implementare il sensore TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometro

Le implementazioni dei dispositivi DEVONO includere un barometro (sensore di pressione dell'aria ambiente). Se un'implementazione del dispositivo include un barometro:

• È NECESSARIO implementare e segnalare il sensore TYPE_PRESSURE.
• DEVE essere in grado di inviare eventi a una frequenza di almeno 5 Hz.
• DEVE avere una precisione adeguata per consentire la stima dell'altitudine.
• DEVE essere compensato in base alla temperatura.

7.3.6. Termometro

Le implementazioni del dispositivo POSSONO includere un termometro ambiente (sensore di temperatura). Se presente, DEVE essere definito come SENSOR_TYPE_AMBIENT_TEMPERATURE e DEVE misurare la temperatura ambiente (della stanza) in gradi Celsius.

Le implementazioni dei dispositivi POSSONO, ma NON DEVONO, includere un sensore di temperatura della CPU. Se presente, DEVE essere definito come SENSOR_TYPE_TEMPERATURE, DEVE misurare la temperatura della CPU del dispositivo e NON DEVE misurare altre temperature. Tieni presente che il tipo di sensore SENSOR_TYPE_TEMPERATURE è stato ritirato in Android 4.0.

7.3.7. Fotometro

Le implementazioni del dispositivo POSSONO includere un fotometro (sensore di luce ambientale).

7.3.8. Sensore di prossimità

Le implementazioni del dispositivo POSSONO includere un sensore di prossimità. I dispositivi in grado di effettuare una chiamata vocale e di indicare un valore diverso da PHONE_TYPE_NONE in getPhoneType DEVONO includere un sensore di prossimità. Se un'implementazione del dispositivo include un sensore di prossimità, deve:

• DEVE misurare la vicinanza di un oggetto nella stessa direzione dello schermo. In altre parole, il sensore di prossimità DEVE essere orientato in modo da rilevare gli oggetti vicini allo schermo, poiché lo scopo principale di questo tipo di sensore è rilevare uno smartphone in uso dall'utente. Se l'implementazione di un dispositivo include un sensore di prossimità con un altro orientamento, NON DEVE essere accessibile tramite questa API.
• DEVE avere un'accuratezza di almeno 1 bit.

7.3.9. Sensori ad alta fedeltà

Le implementazioni dei dispositivi che supportano un insieme di sensori di qualità superiore in grado di soddisfare tutti i requisiti elencati in questa sezione DEVONO identificare il supporto tramite il android.hardware.sensor.hifi_sensors flag della funzionalità.

Un dispositivo che dichiara android.hardware.sensor.hifi_sensors DEVE supportare tutti i seguenti tipi di sensori che soddisfano i requisiti di qualità riportati di seguito:

• SENSOR_TYPE_ACCELEROMETER
  • DEVE avere un intervallo di misurazione compreso tra almeno -8 g e +8 g
  • DEVE avere una risoluzione di misurazione di almeno 1024 LSB/G
  • DEVE avere una frequenza di misurazione minima pari o inferiore a 12,5 Hz
  • DEVE avere una frequenza di misurazione massima di almeno 200 Hz
  • DEVE avere un rumore di misurazione non superiore a 400 μG/√Hz
  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore
  • DEVE avere un consumo energetico per l'aggregazione non peggiore di 3 mW
• SENSOR_TYPE_GYROSCOPE
  • DEVE avere un intervallo di misurazione compreso tra almeno -1000 e +1000 dps
  • DEVE avere una risoluzione di misurazione di almeno 16 LSB/dps
  • DEVE avere una frequenza di misurazione minima pari o inferiore a 12,5 Hz
  • DEVE avere una frequenza di misurazione massima di almeno 200 Hz
  • DEVE avere un rumore di misurazione non superiore a 0,014°/s/√Hz
• SENSOR_TYPE_GYROSCOPE_UNCALIBRATED con gli stessi requisiti di qualità di SENSOR_TYPE_GYROSCOPE
• SENSOR_TYPE_GEOMAGNETIC_FIELD
  • DEVE avere un intervallo di misurazione compreso tra almeno -900 e +900 uT
  • DEVE avere una risoluzione di misurazione di almeno 5 LSB/uT
  • DEVE avere una frequenza di misurazione minima pari o inferiore a 5 Hz
  • DEVE avere una frequenza di misurazione massima di 50 Hz o superiore
  • DEVE avere un rumore di misurazione non superiore a 0,5 uT
• SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED con gli stessi requisiti di qualità di SENSOR_TYPE_GEOMAGNETIC_FIELD e, in aggiunta:
  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 600 eventi del sensore
• SENSOR_TYPE_PRESSURE
  • DEVE avere un intervallo di misurazione compreso tra almeno 300 e 1100 hPa
  • DEVE avere una risoluzione di misurazione di almeno 80 LSB/hPa
  • DEVE avere una frequenza di misurazione minima pari o inferiore a 1 Hz
  • DEVE avere una frequenza di misurazione massima di almeno 10 Hz
  • DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz
  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 300 eventi del sensore
  • DEVE avere un consumo energetico per il raggruppamento non peggiore di 2 mW
• TYPE_GAME_ROTATION_VECTOR
  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
  • DEVE avere un consumo energetico per l'aggregazione non superiore a 4 mW.
• SENSOR_TYPE_SIGNIFICANT_MOTION
  • DEVE avere un consumo di corrente non superiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento
• SENSOR_TYPE_STEP_DETECTOR
  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 100 eventi del sensore
  • DEVE avere un consumo di corrente non superiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento
  • DEVE avere un consumo energetico per l'aggregazione non peggiore di 4 mW
• SENSOR_TYPE_STEP_COUNTER
  • DEVE avere un consumo di corrente non superiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento
• SENSOR_TILT_DETECTOR
  • DEVE avere un consumo di corrente non superiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento

Inoltre, un dispositivo del genere DEVE soddisfare i seguenti requisiti del sottosistema di sensori:

• Il timestamp dell'evento dello stesso evento fisico registrato dal sensore di accelerometro, giroscopio e magnetometro DEVE essere compreso tra 2,5 millisecondi.
• I timestamp degli eventi del sensore giroscopico DEVONO avere la stessa base di tempo del sottosistema della videocamera e un errore massimo di 1 millisecondo.
• La latenza di invio dei campioni all'HAL DEVE essere inferiore a 5 millisecondi dall'istante in cui i dati sono disponibili sull'hardware del sensore fisico.
• Il consumo di energia NON deve essere superiore a 0,5 mW quando il dispositivo è statico e a 2,0 mW quando il dispositivo è in movimento se è attiva qualsiasi combinazione dei seguenti sensori:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

Tieni presente che tutti i requisiti di consumo energetico in questa sezione non includono il consumo di energia del processore dell'applicazione. Sono incluse le potenze assorbite dall'intera catena di sensori: il sensore, eventuali circuiti di supporto, eventuali sistemi di elaborazione dei sensori dedicati e così via.

I seguenti tipi di sensori POSSONO essere supportati anche in un'implementazione del dispositivo che dichiara android.hardware.sensor.hifi_sensors, ma se questi tipi di sensori sono presenti, DEVONO soddisfare il seguente requisito minimo di capacità di buffering:

• SENSOR_TYPE_PROXIMITY: 100 eventi del sensore

7.3.10. Sensore di impronte digitali

Le implementazioni dei dispositivi con una schermata di blocco sicura DEVONO includere un sensore di impronte. Se l'implementazione di un dispositivo include un sensore di impronte digitali e dispone di un'API corrispondente per gli sviluppatori di terze parti, deve:

• DEVE dichiarare il supporto della funzionalità android.hardware.fingerprint.
• DEVE implementare completamente l'API corrispondente come descritto nella documentazione dell'SDK Android [Risorse, 95].
• DEVE avere un tasso di accettazione di falsi non superiore allo 0,002%.
• È FORTEMENTE CONSIGLIATO avere un tasso di falsi rifiuti inferiore al 10%, misurato sul dispositivo
• È FORTEMENTE CONSIGLIATO avere una latenza inferiore a 1 secondo, misurata dal momento in cui viene toccato il sensore di impronte digitali fino allo sblocco dello schermo, per un dito registrato.
• DEVE applicare un limite di frequenza dei tentativi per almeno 30 secondi dopo cinque tentativi falsi per la verifica dell'impronta.
• DEVE avere un'implementazione del keystore basata su hardware ed eseguire la corrispondenza delle impronte in un Trusted Execution Environment (TEE) o su un chip con un canale sicuro per il TEE.
• DEVONO avere tutti i dati delle impronte identificabili criptati e autenticati tramite crittografia in modo che non possano essere acquisiti, letti o alterati al di fuori del Trusted Execution Environment (TEE), come documentato nelle linee guida per l'implementazione sul sito del progetto Android Open Source [Risorse, 96].
• DEVE impedire l'aggiunta di un'impronta senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare una credenziale del dispositivo esistente o di aggiungerne una nuova (PIN/sequenza/password) protetta dal TEE. L'implementazione del progetto open source Android fornisce il meccanismo necessario nel framework.
• NON DEVE consentire alle applicazioni di terze parti di distinguere le singole impronte.
• DEVE rispettare il flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• DOVREBBE, se l'upgrade viene eseguito da una versione precedente ad Android 6.0, essere stata eseguita la migrazione sicura dei dati delle impronte per soddisfare i requisiti sopra indicati o i dati essere stati rimossi.
• DEBBA utilizzare l'icona Impronta Android fornita nell'Android Open Source Project.

7.4. Connettività dei dati

7.4.1. Telefonia

"Telefonia", come utilizzato dalle API Android e in questo documento, si riferisce specificamente all'hardware relativo all'effettuazione di chiamate vocali e all'invio di messaggi SMS tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano o meno essere con commutazione di pacchetti, ai fini di Android sono considerate indipendenti da qualsiasi connettività di dati che possa essere implementata utilizzando la stessa rete. In altre parole, le API e le funzionalità di "telefonia" di Android si riferiscono specificamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni dei dispositivi che non possono effettuare chiamate o inviare/ricevere messaggi SMS NON DEVONO segnalare la funzionalità android.hardware.telephony o eventuali sottofunzionalità, indipendentemente dal fatto che utilizzino una rete cellulare per la connettività dati.

Android PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. In altre parole, Android è compatibile con dispositivi diversi dagli smartphone. Tuttavia, se l'implementazione di un dispositivo include la telefonia GSM o CDMA, DEVE implementare il supporto completo dell'API per quella tecnologia. Le implementazioni dei 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 TV DEVONO includere il supporto di una o più forme di 802.11 (b/g/a/n e così via) e altri tipi di implementazioni dei dispositivi Android DOVREBBERO includere il supporto di una o più forme di 802.11. Se un'implementazione del dispositivo include il supporto per 802.11 ed espone la funzionalità a un'applicazione di terze parti, DEVE implementare l'API Android corrispondente e:

• DEVE segnalare il flag della funzionalità hardware android.hardware.wifi.
• DEVE implementare l'API multicast come descritto nella documentazione dell'SDK [Risorse, 97].
• DEVE supportare il DNS multicast (mDNS) e NON DEVE filtrare i pacchetti mDNS (224.0.0.251) in qualsiasi momento di funzionamento, ad esempio:
  • Anche quando lo schermo non è attivo.
  • Per le implementazioni dei dispositivi Android TV, anche in stato di alimentazione in standby.

7.4.2.1. Wi-Fi Direct

Le implementazioni dei dispositivi DEVONO includere il supporto di Wi-Fi Direct (Wi-Fi peer-to-peer). Se l'implementazione di un dispositivo include il supporto di Wi-Fi Direct, DEVE implementare l'API Android corrispondente come descritto nella documentazione dell'SDK [Risorse, 98]. Se l'implementazione di un dispositivo include il supporto di Wi-Fi Direct, il dispositivo:

• DEVE segnalare la funzionalità hardware android.hardware.wifi.direct.
• DEVE supportare il normale funzionamento del Wi-Fi.
• DEVE supportare il funzionamento simultaneo del Wi-Fi e di Wi-Fi Direct.

7.4.2.2. Configurazione del link diretto con tunnel Wi-Fi

Le implementazioni dei dispositivi Android TV DEVONO includere il supporto per la configurazione del link diretto in tunnel (TDLS) Wi-Fi e le implementazioni di altri tipi di dispositivi Android DOVREBBERO includere il supporto per il TDLS Wi-Fi come descritto nella documentazione dell'SDK Android [Risorse, 99]. Se l'implementazione di un dispositivo include il supporto di TDLS e TDLS è attivato dall'API WiFiManager, il dispositivo:

• DEVI utilizzare TDLS solo quando è possibile E utile.
• DOVREBBE avere qualche euristica e NON utilizzare TDLS quando le prestazioni potrebbero essere peggiori rispetto al passaggio tramite il punto di accesso Wi-Fi.

7.4.3. Bluetooth

Android include il supporto per Bluetooth e Bluetooth Low Energy [Risorse, 100]. Le implementazioni dei dispositivi che includono il supporto di Bluetooth e Bluetooth Low Energy DEVONO dichiarare le funzionalità della piattaforma pertinenti (rispettivamente android.hardware.bluetooth e android.hardware.bluetooth_le) e implementare le API della piattaforma. Le implementazioni dei dispositivi DOVREBBERO implementare profili Bluetooth pertinenti come A2DP, AVCP, OBEX e così via, a seconda del dispositivo. Le implementazioni dei dispositivi Android TV DEVONO supportare Bluetooth e Bluetooth LE.

Implementazioni dei dispositivi, incluso il supporto di Bluetooth Low Energy:

• DEVE dichiarare la funzionalità hardware android.hardware.bluetooth_le.
• È NECESSARIO attivare le API Bluetooth basate su GATT (Generic Attribute Profile) come descritto nella documentazione dell'SDK e in [Risorse, 100].
• È FORTEMENTE CONSIGLIATO implementare un timeout per gli indirizzi privati risolvibili (RPA) non superiore a 15 minuti e ruotare l'indirizzo al termine del timeout per proteggere la privacy dell'utente.
• DEVE supportare lo sgravamento della logica di filtro sul chipset Bluetooth quando viene implementata l'API ScanFilter [Risorse, 101] e DEVE segnalare il valore corretto della posizione in cui è implementata la logica di filtro ogni volta che viene eseguita una query tramite il metodo android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported()
• DOVREBBE supportare lo sgravio della scansione collettiva sul chipset Bluetooth, ma se non è supportato, DEVE segnalare "false" ogni volta che viene eseguito un query tramite il metodo android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported()
• DOVREBBE supportare la pubblicità multipla con almeno 4 slot, ma se non è supportata, deve segnalare "false" ogni volta che viene eseguita una query tramite il metodo android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported().

7.4.4. Near Field Communication

Le implementazioni dei dispositivi DEVONO includere un transceiver e hardware correlato per la tecnologia Near Field Communication (NFC). Se l'implementazione di un dispositivo include hardware NFC e prevede di renderlo disponibile per le app di terze parti, deve:

• DEVE segnalare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature() [Risorse, 70].
• DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC:
  • DEVE essere in grado di agire come lettore/scrittore NFC Forum (come definito dalla specifica tecnica NFC Forum NFCForum-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Tipi di tag NFC Forum 1, 2, 3, 4 (definiti dal NFC Forum)
  • È FORTEMENTE CONSIGLIATO che il dispositivo sia in grado di leggere e scrivere messaggi NDEF nonché dati non elaborati tramite i seguenti standard NFC. Tieni presente che, sebbene gli standard NFC riportati di seguito siano indicati come FORTEMENTE CONSIGLIATI, è previsto che la definizione di compatibilità per una versione futura li modifichi in OBBLIGATORI. Questi standard sono facoltativi in questa versione, ma saranno obbligatori nelle versioni future. I dispositivi esistenti e nuovi che eseguono questa versione di Android sono vivamente invitati a soddisfare questi requisiti ora per poter eseguire l'upgrade alle release future della piattaforma.
    • NfcV (ISO 15693)
  • DEVE essere in grado di leggere il codice a barre e l'URL (se codificato) dei prodotti con codice a barre NFC Thinfilm [Risorse, 102].
  • DEVE essere in grado di trasmettere e ricevere dati tramite i seguenti standard e protocolli peer-to-peer:
    • ISO 18092
    • LLCP 1.2 (definito dal NFC Forum)
    • SDP 1.0 (definito dal NFC Forum)
    • Protocollo push NDEF [Risorse, 103]
    • SNEP 1.0 (definito dal NFC Forum)
  • DEVE includere il supporto di Android Beam [Risorse, 104]:
    • 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 arrivo.
    • DEVE rispettare l'intent android.settings.NFCSHARING_SETTINGS per mostrare le impostazioni di condivisione NFC [Risorse, 105].
    • DEVE implementare il server NPP. I messaggi ricevuti dal server NPP DEVONO essere elaborate nello stesso modo del server SNEP predefinito.
    • DEVE implementare un client SNEP e tentare di inviare NDEF P2P in uscita al server SNEP predefinito quando Android Beam è attivo. Se non viene trovato un 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, android.nfc.NfcAdapter.setNdefPushMessageCallback e android.nfc.NfcAdapter.enableForegroundNdefPush.
    • DOVREBBE utilizzare un gesto o una conferma sullo schermo, ad esempio "Tocca per trasmettere", prima di inviare messaggi NDEF P2P in uscita.
    • DOVREBBE attivare Android Beam per impostazione predefinita e DEVE essere in grado di inviare e ricevere utilizzando Android Beam, anche quando è attiva un'altra modalità P2P NFC proprietaria.
    • DEVE supportare il trasferimento della connessione NFC al Bluetooth quando il dispositivo supporta il profilo Bluetooth Object Push. Le implementazioni dei dispositivi DEVONO supportare il trasferimento della connessione al Bluetooth quando si utilizza android.nfc.NfcAdapter.setBeamPushUris, implementando le specifiche "Connection Handover version 1.2" [Risorse, 106] e "Bluetooth Secure Simple Pairing Using NFC version 1.0" [Risorse, 107] del NFC Forum. Una simile implementazione DEVE implementare il servizio LLCP di trasferimento con il nome di servizio "urn:nfc:sn:handover" per lo scambio dei record di selezione/richiesta di trasferimento tramite NFC e DEVE utilizzare il profilo Push di oggetti Bluetooth per il trasferimento effettivo dei dati Bluetooth. Per motivi di compatibilità con i dispositivi Android 4.1, l'implementazione DOVREBBE comunque accettare le richieste GET SNEP per lo scambio della richiesta di trasferimento/seleziona i record tramite NFC. Tuttavia, un'implementazione stessa NON DEVE inviare richieste GET SNEP per eseguire il trasferimento della connessione.
  • DEVE eseguire il polling per tutte le tecnologie supportate in modalità di rilevamento NFC.
  • DOVREBBE essere in modalità di rilevamento NFC quando 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.

Android include il supporto per la modalità NFC Host Card Emulation (HCE). Se un'implementazione del dispositivo include un chipset del controller NFC in grado di gestire il routing HCE e AID (Application ID), deve:

• DEVE segnalare la costante della funzionalità android.hardware.nfc.hce.
• DEVE supportare le API NFC HCE come definite nell'SDK Android [Risorse, 108].

Inoltre, le implementazioni dei dispositivi POSSONO includere il supporto di lettori/scrittori per le seguenti tecnologie MIFARE.

• MIFARE Classic
• MIFARE Ultralight
• NDEF su MIFARE Classic

Tieni presente che Android include le API per questi tipi di MIFARE. Se un'implementazione del dispositivo supporta MIFARE nel ruolo di lettore/scrittore:

• DEVE implementare le API Android corrispondenti come documentato dall'SDK Android.
• DEVE segnalare la funzionalità com.nxp.mifare dal metodo android.content.pm.PackageManager.hasSystemFeature() [Risorse, 70]. Tieni presente che questa non è una funzionalità standard di Android e, pertanto, non viene visualizzata come costante nella classe android.content.pm.PackageManager.
• NON DEVE implementare le API Android corrispondenti né segnalare la funzionalità com.nxp.mifare, a meno che non implementi anche il supporto NFC generale come descritto in questa sezione.

Se l'implementazione di un dispositivo non include hardware NFC, NON DEVE dichiarare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature() [Risorse, 70] e DEVE implementare l'API NFC di Android come no-op.

Poiché le classi android.nfc.NdefMessage e android.nfc.NdefRecord rappresentano un formato di rappresentazione dei dati indipendente dal protocollo, le implementazioni dei dispositivi DEVONO implementare queste API anche se non includono il supporto per NFC o dichiarano la funzionalità android.hardware.nfc.

7.4.5. Capacità di rete minima

Le implementazioni dei dispositivi DEVONO includere il supporto di una o più forme di reti di dati. Nello specifico, le implementazioni dei dispositivi DEVONO includere il supporto di almeno un protocollo di dati in grado di supportare una velocità di 200 Kbit/s o superiore. Alcuni esempi di tecnologie che soddisfano questo requisito sono EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN e così via.

Le implementazioni dei dispositivi in cui uno standard di rete fisica (ad esempio Ethernet) è la connessione dati principale DEVONO includere anche il supporto di almeno uno standard di dati wireless comune, ad esempio 802.11 (Wi-Fi).

I dispositivi POSSONO implementare più di una forma di connettività dati.

I dispositivi DEVONO includere uno stack di rete IPv6 e supportare la comunicazione IPv6 utilizzando le API gestite, come java.net.Socket e java.net.URLConnection, nonché le API native, come AF_INET6 socket. Il livello di supporto IPv6 richiesto dipende dal tipo di rete, come segue:

• I dispositivi che supportano le reti Wi-Fi DEVONO supportare il funzionamento su Wi-Fi con IPv6 e con il doppio stack.
• I dispositivi che supportano le reti Ethernet DEVONO supportare il funzionamento dual-stack su Ethernet.
• I dispositivi che supportano la rete dati DOVREBBERO supportare il funzionamento IPv6 (solo IPv6 e possibilmente dual-stack) sulla rete dati.
• Quando un dispositivo è connesso contemporaneamente a più reti (ad es. Wi-Fi e dati mobili), DEVE soddisfare contemporaneamente questi requisiti su ogni rete a cui è connesso.

IPv6 DEVE essere attivato per impostazione predefinita.

Per garantire che la comunicazione IPv6 sia affidabile quanto quella IPv4, i pacchetti IPv6 unicast inviati al dispositivo NON DEVONO essere persi, anche quando lo schermo non è attivo. I pacchetti IPv6 multicast ridondanti, ad esempio annunci router ripetuti e identici, POTREBBERO essere limitati in termini di velocità in hardware o firmware se ciò è necessario per risparmiare energia. In questi casi, la limitazione della frequenza NON DEVE causare la perdita della connettività IPv6 sul dispositivo su qualsiasi rete IPv6 conforme che utilizza durate RA di almeno 180 secondi.

La connettività IPv6 DEVE essere mantenuta in modalità Sospensione.

7.4.6. Impostazioni sincronizzazione

Le implementazioni dei dispositivi DEVONO avere l'impostazione di sincronizzazione automatica principale attiva per impostazione predefinita in modo che il metodo getMasterSyncAutomatically() restituisca "true" [Risorse, 109].

7.5. Fotocamere

Le implementazioni dei dispositivi DOVREBBERO includere una fotocamera posteriore e POTREBBERO includere una fotocamera anteriore. Una fotocamera posteriore è una fotocamera situata sul lato opposto al display del dispositivo, ovvero acquisisce le immagini sul lato opposto del dispositivo, come una fotocamera tradizionale. Una fotocamera anteriore è una fotocamera collocata sullo stesso lato del dispositivo del display, ovvero una fotocamera in genere utilizzata per acquisire immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.

Se l'implementazione di un dispositivo include almeno una fotocamera, DOVREBBE essere possibile per un'applicazione allocare contemporaneamente 3 bitmap uguali alle dimensioni delle immagini prodotte dal sensore della fotocamera con la risoluzione più alta sul dispositivo.

7.5.1. Fotocamera posteriore

Le implementazioni dei dispositivi DEVONO includere una fotocamera posteriore. Se l'implementazione di un dispositivo include almeno una fotocamera posteriore, deve:

• DEVE segnalare il flag della funzionalità android.hardware.camera e android.hardware.camera.any.
• DEVE avere una risoluzione di almeno 2 megapixel.
• DEVE avere l'autofocus hardware o l'autofocus software implementato nel driver della fotocamera (trasparente al software dell'applicazione).
• POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
• PUO' includere un flash. Se la fotocamera include un flash, la lampada del flash NON DEVE essere accesa mentre è stata registrata un'istanza di android.hardware.Camera.PreviewCallback su una superficie di anteprima della fotocamera, a meno che l'applicazione non abbia attivato esplicitamente il flash attivando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON di un oggetto Camera.Parameters. Tieni presente che questo vincolo non si applica all'applicazione della fotocamera di sistema integrata del dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

Le implementazioni dei dispositivi POSSONO includere una fotocamera anteriore. Se l'implementazione di un dispositivo include almeno una fotocamera anteriore:

• DEVE segnalare il flag della funzionalità android.hardware.camera.any e android.hardware.camera.front.
• DEVE avere una risoluzione di almeno VGA (640 x 480 pixel).
• NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Camera. L'API Camera in Android ha un supporto specifico per le fotocamere anteriori e le implementazioni dei dispositivi NON DEVONO configurare l'API in modo da trattare una fotocamera anteriore come la fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
• PUO' includere funzionalità (come messa a fuoco automatica, flash e così via) disponibili per le fotocamere rivolte all'indietro come descritto nella sezione 7.5.1.
• DEVE riflettere orizzontalmente (ovvero rispecchiare) lo stream visualizzato da un'app in CameraPreview, come segue:
  • Se l'implementazione del dispositivo può essere ruotata dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente), l'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto all'orientamento corrente del dispositivo.
  • Se l'applicazione corrente ha richiesto esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation()[Resources, 110], l'anteprima della fotocamera DEVE essere ribaltata orizzontalmente rispetto all'orientamento specificato dall'applicazione.
  • In caso contrario, l'anteprima DEVE essere speculare rispetto all'asse orizzontale predefinito del dispositivo.
• DEVE rispecchiare l'immagine visualizzata dalla visualizzazione post nello stesso modo dello stream di immagini di anteprima della videocamera. Se l'implementazione del dispositivo non supporta postview, questo requisito ovviamente non si applica.
• NON DEVE rispecchiare gli stream di video o immagini acquisiti finali restituiti ai callback dell'applicazione o sottoposti a commit nello spazio di archiviazione multimediale.

7.5.3. Videocamera esterna

Le implementazioni dei dispositivi con modalità host USB POTREBBERO includere il supporto di una videocamera esterna collegata alla porta USB. Se un dispositivo include il supporto di una videocamera esterna:

• DEVE dichiarare la funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any.
• DEVE supportare la classe video USB (UVC 1.0 o versioni successive).
• POTREBBE supportare più videocamere.

È CONSIGLIATO supportare la compressione video (ad esempio MJPEG) per consentire il trasferimento di stream non codificati di alta qualità (ad es. stream di immagini non compressi o compressi in modo indipendente). La codifica video basata sulla fotocamera POTREBBE essere supportata. In questo caso, un simultaneo stream non codificato/ MJPEG (risoluzione QVGA o superiore) DEVE essere accessibile all'implementazione del dispositivo.

7.5.4. Comportamento dell'API Camera

Android include due pacchetti API per accedere alla fotocamera. La più recente API android.hardware.camera2 espone all'app il controllo della fotocamera a livello inferiore, inclusi flussi di scatti/streaming efficienti a copia zero e controlli per fotogramma di esposizione, guadagno, guadagni del bilanciamento del bianco, conversione del colore, riduzione del rumore, nitidezza e altro ancora.

Il pacchetto API precedente, android.hardware.Camera, è contrassegnato come deprecato in Android 5.0, ma poiché dovrebbe essere ancora disponibile per le app che utilizzano le implementazioni dei dispositivi Android, È NECESSARIO garantire il supporto continuo dell'API come descritto in questa sezione e nell'SDK Android.

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

• Se un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int), il dispositivo DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione.
• Se un'applicazione registra un'istanza di android.hardware.Camera.PreviewCallback e il sistema chiama il metodo onPreviewFrame() quando il formato di anteprima è YCbCr_420_SP, i dati in byte[] passati a onPreviewFrame() devono essere inoltre nel formato di codifica NV21. In altre parole, NV21 DEVE essere il valore predefinito.
• Per android.hardware.Camera, le implementazioni del dispositivo DEVONO supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia anteriore che posteriore. L'encoder video hardware e la videocamera possono utilizzare qualsiasi formato pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione in YV12.
• Per android.hardware.camera2, le implementazioni del dispositivo devono supportare i formati android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG come output tramite l'API android.media.ImageReader.

Le implementazioni dei dispositivi DEVONO comunque implementare l'API Camera completa inclusa nella documentazione dell'SDK Android [Risorse, 111], indipendentemente dal fatto che il dispositivo includa l'autofocus hardware o altre funzionalità. Ad esempio, le fotocamere prive di messa a fuoco automatica DEVONO comunque chiamare eventuali istanze di android.hardware.Camera.AutoFocusCallback registrate (anche se questo non ha alcuna rilevanza per una fotocamera senza messa a fuoco automatica). Tieni presente che questo vale per le fotocamere anteriori. Ad esempio, anche se la maggior parte delle fotocamere anteriori non supporta l'autofocus, i callback dell'API devono comunque essere "falsi" come descritto.

Le implementazioni del dispositivo DEVONO riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters, se l'hardware di base supporta la funzionalità. Se l'hardware del dispositivo non supporta una funzionalità, l'API deve comportarsi come descritto nella documentazione. Al contrario, le implementazioni dei dispositivi NON DEVONO rispettare o riconoscere costanti di stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. In altre parole, le implementazioni del dispositivo DEVONO supportare tutti i parametri della videocamera standard, se l'hardware lo consente, e NON DEVONO supportare i tipi di parametri della videocamera personalizzati. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini utilizzando tecniche di imaging HDR (High Dynamic Range) DEVONO supportare il parametro della fotocamera Camera.SCENE_MODE_HDR [Risorse, 112].

Poiché non tutte le implementazioni dei dispositivi possono supportare completamente tutte le funzionalità dell'API android.hardware.camera2, le implementazioni dei dispositivi DEVONO segnalare il livello di supporto appropriato con la proprietà android.info.supportedHardwareLevel come descritto nell'SDK Android [Risorse, 113] e segnalare gli indicatori di funzionalità del framework appropriati [Risorse, 114].

Le implementazioni dei dispositivi DEVONO anche dichiarare le funzionalità delle singole videocamere di android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare gli indicatori di funzionalità appropriati [Risorse, 114]; un dispositivo deve definire l'indicatore di funzionalità se uno dei suoi dispositivi videocamera collegati supporta la funzionalità.

Le implementazioni dei dispositivi DEVONO trasmettere l'intent Camera.ACTION_NEW_PICTURE ogni volta che la fotocamera scatta una nuova foto 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 la videocamera registra un nuovo video e l'elemento dell'immagine è stato aggiunto al media store.

7.5.5. Orientamento della fotocamera

Entrambe le fotocamere anteriori e posteriori, se presenti, DEVONO essere orientate in modo che la dimensione lunga della fotocamera sia allineata alla dimensione lunga dello schermo. In altre parole, quando il dispositivo è tenuto in orizzontale, le fotocamere DEVONO acquisire immagini in orizzontale. Questo vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica sia ai dispositivi con orientamento principale orizzontale sia a quelli con orientamento principale verticale.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

La memoria disponibile per il kernel e lo spazio utente nelle implementazioni del dispositivo DEVE essere almeno uguale o superiore ai valori minimi specificati dalla tabella seguente. (consulta la sezione 7.1.1 per le definizioni delle dimensioni e della densità dello schermo).

Densità e dimensioni dello schermo	Dispositivo a 32 bit	Dispositivo a 64 bit
Dispositivi Android Watch (a causa di schermi più piccoli)	416MB	Non applicabile
280 dpi o meno su schermi piccoli/normali mdpi o inferiore su schermi di grandi dimensioni ldpi o inferiore su schermi extra large	424MB	704MB
xhdpi o superiore su schermi piccoli/normali hdpi o superiore su schermi di grandi dimensioni mdpi o superiore su schermi extra large	512MB	832MB
400 dpi o superiore su schermi piccoli/normali xhdpi o superiore su schermi di grandi dimensioni tvdpi o superiore su schermi extra large	896MB	1280MB
560 dpi o superiore su schermi piccoli/normali 400 dpi o superiore su schermi di grandi dimensioni xhdpi o superiore su schermi extra large	1344MB	1824MB

I valori di memoria minima DEVONO essere aggiuntivi allo spazio di memoria già dedicato a componenti hardware come radio, video e così via che non sono sotto il controllo del kernel.

Le implementazioni di dispositivi con meno di 512 MB di memoria a disposizione del kernel e dello spazio utente, a meno che non si tratti di un Android Watch, DEVONO restituire il valore "true" per ActivityManager.isLowRamDevice().

I dispositivi Android TV DEVONO avere almeno 5 GB e altre implementazioni di dispositivi DEVONO avere almeno 1,5 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione. In altre parole, la partizione /data DEVE essere di almeno 5 GB per i dispositivi Android TV e di almeno 1,5 GB per le altre implementazioni dei dispositivi. Per le implementazioni dei dispositivi che eseguono Android è FORTEMENTE CONSIGLIATO disporre di almeno 3 GB di spazio di archiviazione non volatile per i dati privati dell'applicazione, in modo che possano eseguire l'upgrade alle release future della piattaforma.

Le API Android includono un gestore dei download che le applicazioni POSSONO utilizzare per scaricare file di dati [Risorse, 115]. L'implementazione del gestore dei download sul dispositivo DEVE essere in grado di scaricare singoli file di dimensioni almeno pari a 100 MB nella posizione "cache" predefinita.

7.6.2. Spazio di archiviazione condiviso dell'applicazione

Le implementazioni dei dispositivi DEVONO offrire spazio di archiviazione condiviso per le applicazioni, spesso anche chiamato "spazio di archiviazione esterno condiviso".

Le implementazioni dei dispositivi DEVONO essere configurate con lo spazio di archiviazione condiviso montato per impostazione predefinita "out of the box". Se lo spazio di archiviazione condiviso non è montato sul percorso /sdcard di Linux, il dispositivo DEVE includere un link simbolico Linux da /sdcard al punto di montaggio effettivo.

Le implementazioni dei dispositivi POSSONO avere hardware per lo spazio di archiviazione rimovibile accessibile all'utente, come uno slot per schede Secure Digital (SD). Se questo slot viene utilizzato per soddisfare il requisito di archiviazione condivisa, l'implementazione del dispositivo:

• DEVE implementare un'interfaccia utente di tipo popup o messaggio temporaneo che avvisa l'utente quando non è presente alcuna scheda SD.
• DEVE includere una scheda SD formattata FAT di almeno 1 GB OPPURE deve essere indicato sulla confezione e su altro materiale disponibile al momento dell'acquisto che la scheda SD deve essere acquistata separatamente.
• DEVE montare la scheda SD per impostazione predefinita.

In alternativa, le implementazioni del dispositivo POSSONO allocare lo spazio di archiviazione interno (non rimovibile) come spazio di archiviazione condiviso per le app come incluso nel progetto Android Open Source upstream; le implementazioni del dispositivo DOVREBBERO utilizzare questa configurazione e l'implementazione del software. Se un'implementazione del dispositivo utilizza lo spazio di archiviazione interno (non rimovibile) per soddisfare il requisito di spazio di archiviazione condiviso, anche se lo spazio di archiviazione PUÒ condividere lo spazio con i dati privati dell'applicazione, DEVE avere una dimensione minima di 1 GB e essere montato su /sdcard (o /sdcard DEVE essere un link simbolico alla posizione fisica se è montato altrove).

Le implementazioni dei dispositivi DEVONO applicare l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE su questo spazio di archiviazione condiviso come descritto nella documentazione. In caso contrario, lo spazio di archiviazione condiviso DEVE essere scrivibile da qualsiasi applicazione che ottenga questa permission.

Le implementazioni dei dispositivi che includono più percorsi di archiviazione condivisi (ad esempio un attacco per schede SD e uno spazio di archiviazione interno condiviso) DEVONO consentire di scrivere nello spazio di archiviazione esterno secondario solo alle applicazioni Android predefinite e privilegiate con l'autorizzazione WRITE_EXTERNAL_STORAGE, tranne quando si scrive nelle directory specifiche del pacchetto o all'interno del URI restituito dall'attivazione dell'intent ACTION_OPEN_DOCUMENT_TREE.

Tuttavia, le implementazioni dei dispositivi DOVREBBERO esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione multimediale di Android e android.provider.MediaStore.

Indipendentemente dalla forma di archiviazione condivisa utilizzata, se l'implementazione del dispositivo ha una porta USB con supporto della modalità periferica USB, DEVE fornire un qualche meccanismo per accedere ai contenuti dell'archiviazione condivisa da un computer host. Le implementazioni dei dispositivi POSSONO utilizzare la memoria di massa USB, ma DEVONO utilizzare il protocollo Media Transfer per soddisfare questo requisito. Se l'implementazione del dispositivo supporta Media Transfer Protocol:

• DEVE essere compatibile con l'host MTP di Android di riferimento, Android File Transfer [Risorse, 116].
• DOVREBBE segnalare una classe di dispositivo USB pari a 0x00.
• DOVREBBE riportare il nome dell'interfaccia USB "MTP".

7.6.3. Spazio di archiviazione utilizzabile

È FORTEMENTE CONSIGLIATO implementare lo spazio di archiviazione adottabile nelle implementazioni dei dispositivi se la porta del dispositivo di archiviazione rimovibile si trova in una posizione stabile a lungo termine, ad esempio all'interno del vano batteria o di un'altra copertura protettiva [Risorse, 117].

Le implementazioni di dispositivi come una TV POTREBBERO consentire l'adozione tramite porte USB poiché il dispositivo dovrebbe essere statico e non mobile. Tuttavia, per altre implementazioni di dispositivi di natura mobile, è FORTEMENTE CONSIGLIATO implementare lo spazio di archiviazione adottabile in una posizione stabile a lungo termine, poiché la disconnessione accidentale può causare perdita/corruzione dei dati.

7.7. USB

Le implementazioni dei dispositivi DEVONO supportare la modalità periferica USB e la modalità host USB.

Se l'implementazione di un dispositivo include una porta USB che supporta la modalità periferica:

• La porta DEVE essere connettibile a un host USB con una porta USB di tipo A o C standard.
• La porta DEVE utilizzare il fattore di forma USB micro-B, micro-AB o Type-C. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti in modo da poter eseguire l'upgrade alle release future della piattaforma.
• La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o attivare la rotazione dello schermo software per tutte le app (inclusa la schermata iniziale), in modo che il display venga visualizzato correttamente quando il dispositivo è orientato con la porta in basso. È FORTEMENTE CONSIGLIATO ai dispositivi Android esistenti e nuovi di soddisfare questi requisiti in modo da poter eseguire l'upgrade alle release future della piattaforma.
• DEVE implementare l'API e la specifica Android Open Accessory (AOA) come documentato nella documentazione dell'SDK Android e, se si tratta di un dispositivo Android per uso palmare, DEVE implementare l'API AOA. Implementazioni dei dispositivi che implementano la specifica AOA:
  • DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.accessory [Risorse, 118].
  • DEVE supportare l'impostazione di una comunicazione basata sul protocollo AOA al primo collegamento con un computer host USB che funge da accessorio, senza che l' utente debba modificare la modalità USB predefinita.
  • DEVE implementare la classe audio USB come descritto nella documentazione dell'SDK Android [Risorse, 119].
  • Inoltre, la classe di archiviazione di massa USB DEVE includere la stringa "android" alla fine della stringa iInterface della descrizione dell'interfaccia dell'archiviazione di massa USB
• DOVREBBE implementare il supporto per assorbire una corrente di 1,5 A durante il chirp e il traffico HS come specificato nella specifica di ricarica della batteria USB, revisione 1.2 [Risorse, 120]. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
lo standard di resistenza di tipo C.
• Il valore di iSerialNumber nel descrittore del dispositivo standard USB DEVE essere uguale al valore di android.os.Build.SERIAL.

Se l'implementazione di un dispositivo include una porta USB che supporta la modalità host:

• DEVE utilizzare una porta USB Type-C, se l'implementazione del dispositivo supporta USB 3.1.
• PUO' utilizzare un fattore di forma della porta non standard, ma in questo caso DEVE essere fornito con un cavo o più cavi che adattano la porta a una porta USB di tipo A o C standard.
• PUO' utilizzare una porta USB micro-AB, ma in questo caso DEVE essere fornita con un cavo o cavi per adattare la porta a una porta USB di tipo A o C standard.
• È FORTEMENTE CONSIGLIATO implementare la classe audio USB come descritto nella documentazione dell'SDK Android [Risorse, 119].
• DEVE implementare l'API host USB Android come descritto nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host [Risorse, 121].
• DEVE supportare la ricarica del dispositivo in modalità host; deve pubblicizzare una corrente di alimentazione di almeno 1,5 A come specificato nella sezione Parametri di terminazione della specifica del cavo e del connettore USB Type-C, revisione 1.2 [] per i connettori USB Type-C o utilizzare l'intervallo di corrente di uscita della porta di ricarica a valle(CDP) come specificato nella specifica di ricarica della batteria USB, revisione 1.2 [Risorse, 120] per i connettori Micro-AB.

7.8. Audio

7.8.1. Microfono

Le implementazioni dei dispositivi POSSONO omettere un microfono. Tuttavia, se l'implementazione di un dispositivo omette un microfono, NON DEVE segnalare la costante della funzionalità android.hardware.microphone e DEVE implementare l'API di registrazione audio almeno come no-op, come indicato nella sezione 7. Al contrario, le implementazioni dei dispositivi che dispongono di un microfono:

• DEVE segnalare la costante della funzionalità android.hardware.microphone
• DEVONO soddisfare i requisiti per le registrazioni audio descritti nella sezione 5.4
• DEVONO soddisfare i requisiti di latenza audio descritti nella sezione 5.6
• È FORTEMENTE CONSIGLIATO supportare la registrazione in modalità quasi ultrasuoni come descritto nella sezione 7.8.3

7.8.2. Uscita audio

Implementazioni di dispositivi che includono uno speaker o una porta di uscita audio/multimedia per una periferica di uscita audio come cuffie o altoparlanti esterni:

• DEVE segnalare la costante della funzionalità android.hardware.audio.output.
• DEVONO soddisfare i requisiti di riproduzione audio descritti nella sezione 5.5.
• DEVE soddisfare i requisiti di latenza audio descritti nella sezione 5.6.
• È FORTEMENTE CONSIGLIATO supportare la riproduzione a frequenza quasi ultrasonica come descritto nella sezione 7.8.3

Al contrario, se l'implementazione di un dispositivo non include uno speaker o una porta di uscita audio, NON DEVE segnalare la funzionalità di uscita audio android.hardware.audio e DEVE implementare le API relative all'uscita audio almeno come no-op.

L'implementazione del dispositivo Android Watch PUÒ, ma NON DEVE, avere un'uscita audio, ma altri tipi di implementazioni di dispositivi Android DEVONO avere un'uscita audio e dichiarare android.hardware.audio.output.

7.8.2.1. Porte audio analogiche

Per essere compatibile con le cuffie e altri accessori audio che utilizzano il connettore audio da 3,5 mm nell'ecosistema Android [Risorse, 122], se l'implementazione di un dispositivo include una o più porte audio analogiche, almeno una delle porte audio DEVE essere un jack audio da 3,5 mm a 4 conduttori. Se l'implementazione di un dispositivo ha un jack audio da 3, 5 mm a 4 conduttori:

• DEVE supportare la riproduzione audio su cuffie stereo e cuffie stereo con microfono e DOVREBBE supportare la registrazione audio da cuffie stereo con microfono.
• DEVE supportare i connettori audio TRRS con l'ordine di pinout CTIA e DEVE supportare i connettori audio con l'ordine di pinout OMTP.
• DEVE supportare il rilevamento del microfono sull'accessorio audio collegato, se l'implementazione del dispositivo supporta un microfono, e trasmettere android.intent.action.HEADSET_PLUG con il valore extra microfono impostato su 1.
• DOVREBBE supportare il rilevamento e la mappatura ai codici a chiave per i seguenti 3 intervalli di impedenza equivalente tra i conduttori del microfono e di messa a terra sul connettore audio:
  • Massimo 70 ohm: KEYCODE_HEADSETHOOK
  • 210-290 Ohm: KEYCODE_VOLUME_UP
  • 360-680 Ohm: KEYCODE_VOLUME_DOWN
• DOVREBBE supportare il rilevamento e la mappatura al codice a chiave per il seguente intervallo di impedenza equivalente tra i conduttori del microfono e di messa a terra sul collegato audio:
  • 110-180 Ohm: KEYCODE_VOICE_ASSIST
• DEVE attivare ACTION_HEADSET_PLUG quando viene inserito il connettore, ma solo dopo che tutti i contatti sul connettore toccano i relativi segmenti sul jack.
• DEVE essere in grado di alimentare almeno 150 mV ± 10% di tensione di uscita su un'impedenza dello speaker di 32 Ohm.
• DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V e 2,9 V.

7.8.3. Near-Ultrasound

L'audio quasi a ultrasuoni è la banda da 18,5 kHz a 20 kHz. Le implementazioni dei dispositivi DEVONO segnalare correttamente il supporto della funzionalità audio a ultrasuoni vicini tramite l'API AudioManager.getProperty come segue:

• Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND è "true", then
  • La risposta di potenza media del microfono nella banda da 18,5 kHz a 20 kHz NON DEVE essere superiore a 15 dB al di sotto della risposta a 2 kHz.
  • Il rapporto segnale/rumore (SNR) non pesato del microfono in un intervallo di frequenza compreso tra 18,5 kHz e 20 kHz per un tono di 19 kHz a -26 dBFS NON DEVE essere inferiore a 50 dB.
• Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND è "true", la risposta media dell'altoparlante in 18,5 kHz - 20 kHz NON DEVE essere inferiore a 40 dB rispetto alla risposta a 2 kHz.

8. Prestazioni e potenza

Alcuni criteri minimi di prestazioni e potenza sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di riferimento che gli sviluppatori fanno durante lo sviluppo di un'app. I dispositivi Android Watch DOVREBBERO e le implementazioni di altri tipi di dispositivi DEVONO soddisfare i seguenti criteri:

8.1. Coerenza dell'esperienza utente

Le implementazioni dei dispositivi DEVONO fornire un'interfaccia utente fluida garantendo una frequenza frame e tempi di risposta coerenti per applicazioni e giochi. Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti:

• Latenza dei frame coerente. La latenza dei frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più spesso di 5 frame al secondo e DEVE essere inferiore a 1 frame al secondo.
• Latenza dell'interfaccia utente. Le implementazioni dei dispositivi DEVONO garantire un'esperienza utente a bassa latenza scorrendo un elenco di 10.000 voci come definito dal Compatibility Test Suite (CTS) di Android in meno di 36 secondi.
• Passaggio da un'attività all'altra. Quando sono state avviate più applicazioni, il riavvio di un'applicazione già in esecuzione DOVESSE richiedere meno di 1 secondo.

8.2. Prestazioni di accesso all'I/O di file

Le implementazioni dei dispositivi DEVONO garantire la coerenza delle prestazioni di accesso ai file dell'archiviazione interna per le operazioni di lettura e scrittura.

• Scrittura sequenziale. Le implementazioni dei dispositivi DEVONO garantire prestazioni di scrittura sequenziale di almeno 5 MB/s per un file di 256 MB che utilizza un buffer di scrittura di 10 MB.
• Scrittura casuale. Le implementazioni dei dispositivi DEVONO garantire prestazioni di scrittura casuale di almeno 0,5 MB/s per un file di 256 MB che utilizza un buffer di scrittura di 4 KB.
• Lettura sequenziale. Le implementazioni dei dispositivi DEVONO garantire un rendimento di lettura sequenziale di almeno 15 MB/s per un file di 256 MB che utilizza un buffer di scrittura di 10 MB.
• Lettura casuale. Le implementazioni dei dispositivi DEVONO garantire prestazioni di lettura casuale di almeno 3,5 MB/s per un file di 256 MB utilizzando un buffer di scrittura di 4 KB.

8.3. Modalità di risparmio energetico

Tutte le app esenti dalla modalità App Standby e/o Sospensione DEVONO essere rese visibili all'utente finale. Inoltre, gli algoritmi di attivazione, manutenzione e risveglio e l'uso delle impostazioni di sistema globali di queste modalità di risparmio energetico NON DEVONO discostarsi dal progetto open source Android.

8.4. Contabilità del consumo energetico

Una contabilità e una generazione di report più accurati del consumo di energia forniscono allo sviluppatore di app sia gli incentivi sia gli strumenti per ottimizzare il pattern di utilizzo dell'energia dell'applicazione. Di conseguenza, le implementazioni dei dispositivi:

• DEVE essere in grado di monitorare l'utilizzo di energia dei componenti hardware e attribuirlo a applicazioni specifiche. Nello specifico, le implementazioni:
  • DEVE fornire un profilo di alimentazione per componente che definisce il valore del consumo di corrente per ciascun componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android [Risorse, 123].
  • DEBBONO essere riportati tutti i valori di consumo di energia in milliampere ora (mAh)
  • DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.
  • DEVE segnalare il consumo di energia della CPU per l'UID di ogni processo. Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
• DEVE rendere disponibile questo consumo di energia tramite il comando shell adb shell dumpsys batterystats per lo sviluppatore dell'app [Risorse, 124].
• DEVE rispettare l'intent android.intent.action.POWER_USAGE_SUMMARY e mostrare un menu delle impostazioni che mostri questo utilizzo di energia [Risorse, 125].

9. Compatibilità del modello di sicurezza

Le implementazioni dei dispositivi DEVONO implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API [Risorse, 126] nella documentazione per sviluppatori Android. Le implementazioni dei dispositivi DEVONO supportare l'installazione di applicazioni con firma autografa senza richiedere autorizzazioni/certificati aggiuntivi da parte di terze parti/autorità. Nello specifico, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle subsezioni che seguono.

9.1. Autorizzazioni

Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android [Risorse, 126]. Nello specifico, le implementazioni DEVONO applicare ogni autorizzazione definita come описано в документации SDK; nessuna autorizzazione può essere omessa, modificata o ignorata. Le implementazioni POSSONO aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe di ID autorizzazione non siano nello spazio dei nomi android.*.

Le autorizzazioni con un livello di protezione pericoloso sono autorizzazioni di runtime. Le applicazioni con targetSdkVersion > 22 li richiedono in fase di esecuzione. Implementazioni dei dispositivi:

• DEVE mostrare un'interfaccia dedicata che consenta all'utente di decidere se concedere le autorizzazioni di runtime richieste e fornire un'interfaccia per gestire le autorizzazioni di runtime.
• DEVE avere una sola implementazione di entrambe le interfacce utente.
• NON DEVE concedere autorizzazioni di runtime alle app preinstallate, a meno che:
  • il consenso dell'utente può essere ottenuto prima che l'applicazione lo utilizzi
  • le autorizzazioni di runtime sono associate a un pattern di intent per il quale l'applicazione preinstallata è impostata come gestore predefinito

9.2. Isolamento UID e dei processi

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

9.3. Autorizzazioni del file system

Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni di accesso ai file di Android come definito nella documentazione di riferimento Sicurezza e autorizzazioni [Risorse, 126].

9.4. Ambienti di esecuzione alternativi

Le implementazioni dei dispositivi POSSONO includere ambienti di runtime che eseguono applicazioni utilizzando un altro software o un'altra tecnologia rispetto al formato eseguibile Dalvik o al codice nativo. Tuttavia, questi ambienti di esecuzione alternativi NON DEVONO compromettere il modello di sicurezza di Android o la sicurezza delle applicazioni Android installate, come descritto in questa sezione.

I runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella sezione 9.

Ai runtime alternativi NON DEVE essere concesso l'accesso alle risorse protette da autorizzazioni non richieste nel file AndroidManifest.xml del runtime tramite il meccanismo <uses-permission>.

I runtime alternativi NON DEVONO consentire alle applicazioni di utilizzare funzionalità protette dalle autorizzazioni Android limitate alle applicazioni di sistema.

I runtime alternativi DEVONO rispettare il modello di sandbox di Android. Nello specifico, i runtime alternativi:

• DEVE installare le app tramite PackageManager in sandbox Android separate (ID utente Linux e così via).
• PUO' fornire una singola sandbox Android condivisa da tutte le applicazioni che utilizzano il runtime alternativo.
• e le applicazioni installate utilizzando un runtime alternativo NON DEVONO riutilizzare la sandbox di qualsiasi altra app installata sul dispositivo, tranne tramite i meccanismi Android standard di ID utente e certificato di firma condivisi.
• NON DEVE essere avviata con, concedere o ricevere l'accesso alle sandbox corrispondente ad altre applicazioni Android.
• NON DEVONO essere lanciate con, essere concesse o concedere ad altre applicazioni i privilegi del superutente (root) o di qualsiasi altro ID utente.

I file APK dei runtime alternativi POSSONO essere inclusi nell'immagine di sistema di un'implementazione del dispositivo, ma DEVONO essere firmati con una chiave diversa da quella utilizzata per firmare altre applicazioni incluse nell'implementazione del dispositivo.

Quando installi applicazioni, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione. Se un'applicazione deve utilizzare una risorsa del dispositivo per la quale è disponibile un'autorizzazione Android corrispondente (ad esempio Fotocamera, GPS e così via), il runtime alternativo DEVE informare l'utente che l'applicazione potrà accedere a quella risorsa. Se l'ambiente di runtime non registra le funzionalità dell'applicazione in questo modo, l'ambiente di runtime DEVE elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che lo utilizza.

9.5. Supporto di più utenti

Android include il supporto per più utenti e per l'isolamento completo degli utenti [Risorse, 127]. Le implementazioni dei dispositivi POSSONO consentire più utenti, ma se abilitati DEVONO soddisfare i seguenti requisiti relativi al supporto multiutente [Risorse, 128]:

• Le implementazioni dei dispositivi che non dichiarano il flag della funzionalità android.hardware.telephony DEVONO supportare i profili con limitazioni, una funzionalità che consente ai proprietari di dispositivi di gestire utenti aggiuntivi e le relative funzionalità sul dispositivo. Con i profili con limitazioni, i proprietari di dispositivi possono configurare rapidamente ambienti separati in cui lavorare per altri utenti, con la possibilità di gestire limitazioni più granulari nelle app disponibili in questi ambienti.
• Al contrario, le implementazioni dei dispositivi che dichiarano il flag della funzionalità android.hardware.telephony NON DEVONO supportare i profili con limitazioni, ma DEVONO essere in linea con l'implementazione dei controlli AOSP per attivare /disattivare l'accesso di altri utenti alle chiamate vocali e agli SMS.
• Le implementazioni dei dispositivi DEVONO, per ogni utente, 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, 126].
• Ogni istanza utente su un dispositivo Android DEVE avere directory di archiviazione esterna separate e isolate. Le implementazioni dei dispositivi POSSONO archiviare i dati di più utenti sullo stesso volume o file system. Tuttavia, l'implementazione del dispositivo DEVE garantire che le applicazioni di proprietà di un determinato utente e in esecuzione per suo conto non possano elencare, leggere o scrivere dati di proprietà di altri utenti. Tieni presente che i supporti rimovibili, come gli slot per schede SD, possono consentire a un utente di accedere ai dati di un altro tramite un PC host. Per questo motivo, le implementazioni dei dispositivi che utilizzano supporti rimovibili per le API di archiviazione esterna principale DEVONO criptare i contenuti della scheda SD se è abilitato il multiutente utilizzando una chiave memorizzata solo su supporti non rimovibili accessibili solo al sistema. Poiché i contenuti multimediali non saranno più leggibili da un PC host, le implementazioni dei dispositivi dovranno passare a MTP o a un sistema simile per fornire ai PC host l'accesso ai dati dell'utente corrente. Di conseguenza, le implementazioni dei dispositivi POSSONO, ma NON DEVONO, attivare il multiutente se utilizzano supporti rimovibili [Risorse, 129] per lo spazio di archiviazione esterno principale.

9.6. Avviso SMS premium

Android include il supporto per avvisare gli utenti di qualsiasi messaggio SMS premium in uscita [Risorse, 130]. Gli SMS premium sono messaggi inviati a un servizio registrato con un operatore che potrebbe comportare un addebito per l'utente. Le implementazioni dei dispositivi che dichiarano il supporto di android.hardware.telephony DEVONO avvisare gli utenti prima di inviare un messaggio SMS ai numeri identificati dalle espressioni regolari definite nel file /data/misc/sms/codes.xml del dispositivo. Il progetto Android Open Source Project upstream fornisce un'implementazione che soddisfa questo requisito.

9.7. Funzionalità di sicurezza del kernel

La sandbox di Android include funzionalità che utilizzano il sistema di controllo dell'accesso obbligatorio (MAC) di Security-Enhanced Linux (SELinux) e altre funzionalità di sicurezza nel kernel di Linux. SELinux o qualsiasi altra funzionalità di sicurezza implementata al di sotto del framework Android:

• DEVE mantenere la compatibilità con le applicazioni esistenti.
• NON DEVE avere un'interfaccia utente visibile quando viene rilevata e bloccata correttamente una violazione della sicurezza, ma PUÒ avere un'interfaccia utente visibile quando si verifica una violazione della sicurezza non bloccata che genera uno sfruttamento riuscito.
• NON DEVE essere configurabile dall'utente o dallo sviluppatore.

Se un'API per la configurazione dei criteri è esposta a un'applicazione che può colpire un'altra applicazione (ad esempio un'API di amministrazione del dispositivo), l'API NON DEVE consentire configurazioni che compromettono la compatibilità.

I dispositivi DEVONO implementare SELinux o, se si utilizza un kernel diverso da Linux, un sistema di controllo dell'accesso obbligatorio equivalente. I dispositivi DEVONO soddisfare anche i seguenti requisiti, soddisfatti dall'implementazione di riferimento nel progetto open source Android upstream.

Implementazioni dei dispositivi:

• DEVI impostare SELinux sulla modalità di applicazione globale.
• È NECESSARIO configurare tutti i domini in modalità di applicazione. Non sono consentiti domini in modalità permissiva, inclusi i domini specifici per un dispositivo/fornitore.
• NON DEVE modificare, omettere o sostituire le regole neverallow presenti nella cartella external/sepolicy fornita nell'Android Open Source Project (AOSP) in upstream e il criterio DEVE essere compilato con tutte le regole neverallow presenti, sia per i domini AOSP SELinux che per i domini specifici del dispositivo/del fornitore.

Le implementazioni dei dispositivi DOVREBBERO mantenere il criterio SELinux predefinito fornito nella directory external/sepolicy del progetto Android Open Source upstream e solo aggiungere ulteriori elementi a questo criterio per la propria configurazione specifica del dispositivo. Le implementazioni dei dispositivi DEVONO essere compatibili con l'Android Open Source Project a monte.

9.8. Privacy

Se il dispositivo implementa nel sistema una funzionalità che acquisisce i contenuti visualizzati sullo schermo e/o registra lo stream audio riprodotto sul dispositivo, deve avvisare continuamente l'utente ogni volta che questa funzionalità è attivata e acquisisce/registra attivamente.

Se un'implementazione del dispositivo ha un meccanismo che instrada il traffico di dati di rete tramite un server proxy o un gateway VPN per impostazione predefinita (ad esempio, il precaricamento di un servizio VPN con android.permission.CONTROL_VPN concesso), l'implementazione del dispositivo DEVE chiedere il consenso dell'utente prima di attivare il meccanismo.

Se l'implementazione di un dispositivo ha una porta USB con supporto della modalità periferica USB, deve presentare un'interfaccia utente che richieda il consenso dell'utente prima di consentire l'accesso ai contenuti dello spazio di archiviazione condiviso tramite la porta USB.

9.9. Crittografia completa del disco

Se l'implementazione del dispositivo supporta una schermata di blocco sicura che segnala "true" per KeyguardManager.isDeviceSecure() [Resources, 131], e non è un dispositivo con memoria limitata come indicato tramite il metodo ActivityManager.isLowRamDevice(), il dispositivo DEVE supportare la crittografia completa del disco [Resources, 132] dei dati privati dell'applicazione (partizione /data), nonché la partizione dello spazio di archiviazione condiviso dell'applicazione (partizione /sdcard) se si tratta di una parte permanente e non rimovibile del dispositivo.

Per le implementazioni dei dispositivi che supportano la crittografia completa del disco e con prestazioni di crittografia Advanced Encryption Standard (AES) superiori a 50 MiB/sec, la crittografia completa del disco DEVE essere abilitata per impostazione predefinita al momento in cui l'utente ha completato l'esperienza di configurazione iniziale. Se l'implementazione di un dispositivo è già stata avviata su una versione precedente di Android con la crittografia completa del disco disattivata per impostazione predefinita, questo dispositivo non può soddisfare il requisito tramite un aggiornamento del software di sistema e pertanto PUÒ essere esente.

La crittografia DEVE utilizzare AES con una chiave di 128 bit (o superiore) e una modalità progettata per l'archiviazione (ad esempio AES-XTS, AES-CBC-ESSIV). La chiave di crittografia NON DEVE essere scritta nello spazio di archiviazione in nessun momento senza essere criptata. A parte quando è in uso attivo, la chiave di crittografia DEVE essere criptata con AES con il passcode della schermata di blocco allungato utilizzando un algoritmo di allungamento lento (ad es. PBKDF2 o scrypt). Se l'utente non ha specificato un passcode per la schermata di blocco o ha disattivato l'utilizzo del passcode per la crittografia, il sistema DEVE utilizzare un passcode predefinito per avvolgere la chiave di crittografia. Se il dispositivo fornisce un keystore basato su hardware, l'algoritmo di stretching della password DEVE essere legato in modo crittografico a quel keystore. La chiave di crittografia NON DEVE essere inviata dal dispositivo (anche se protetta con il passcode dell'utente e/o la chiave legata all'hardware). Il progetto Android Open Source upstream fornisce un'implementazione preferita di questa funzionalità in base alla funzionalità dm-crypt del kernel Linux.

9.10. Avvio verificato

L'Avvio verificato è una funzionalità che garantisce l'integrità del software del dispositivo. Se un'implementazione del dispositivo supporta la funzionalità, DEVE:

• Dichiara il flag della funzionalità della piattaforma android.software.verified_boot
• Esegui la verifica in ogni sequenza di avvio
• Avvia la verifica da una chiave hardware immutabile che è la radice della attendibilità e vai fino alla partizione di sistema
• Implementa ogni fase di verifica per controllare l'integrità e l'autenticità di tutti i byte nella fase successiva prima di eseguire il codice nella fase successiva
• Utilizza algoritmi di verifica efficaci come quelli consigliati attualmente dal NIST per gli algoritmi di hashing (SHA-256) e le dimensioni delle chiavi pubbliche (RSA-2048).

Il progetto Android Open Source upstream fornisce un'implementazione preferita di questa funzionalità basata sulla funzionalità dm-verity del kernel Linux.

A partire da Android 6.0, le implementazioni dei dispositivi con prestazioni di crittografia Advanced Encryption Standard (AES) superiori a 50 MiB/secondo DEVONO supportare l'Avvio verificato per l'integrità del dispositivo. Se l'implementazione di un dispositivo è già stata lanciata senza supportare l'avvio verificato su una versione precedente di Android, questo dispositivo non può aggiungere il supporto di questa funzionalità con un aggiornamento del software di sistema ed è quindi esente dal requisito.

9.11. Chiavi e credenziali

Il sistema Android Keystore [Risorse, 133] consente agli sviluppatori di app di archiviare le chiavi crittografiche in un contenitore e di utilizzarle nelle operazioni di crittografia tramite l'API KeyChain [Risorse, 134] o l'API Keystore [Risorse, 135].

Tutte le implementazioni dei dispositivi Android DEVONO soddisfare i seguenti requisiti:

• NON deve limitare il numero di chiavi che possono essere generate e DEVE consentire almeno l'importazione di più di 8192 chiavi.
• L'autenticazione nella schermata di blocco DEVE limitare la frequenza dei tentativi e DEVE avere un algoritmo di backoff esponenziale come implementato in Android Open Source Project.
• Quando l'implementazione del dispositivo supporta una schermata di blocco sicura e dispone di hardware sicuro, come un Secure Element (SE) in cui è possibile implementare un Trusted Execution Environment (TEE),
  • È MOLTO CONSIGLIATO eseguire il backup dell'implementazione del keystore con l'hardware sicuro. Il progetto open source Android upstream fornisce l'implementazione del livello di astrazione hardware (HAL) di Keymaster che può essere utilizzato per soddisfare questo requisito.
  • DEVE eseguire l'autenticazione della schermata di blocco nell'hardware sicuro se il dispositivo ha un'implementazione del keystore basata su hardware e solo se l'autenticazione è andata a buon fine consente l'utilizzo delle chiavi legate all'autenticazione. Il progetto open source Android upstream fornisce il livello di astrazione hardware (HAL) Gatekeeper che può essere utilizzato per soddisfare questo requisito [Risorse, 136].

Tieni presente che, sebbene i requisiti relativi al TEE sopra indicati siano indicati come FORTEMENTE CONSIGLIATI, la definizione di compatibilità per la prossima versione dell'API prevede di modificarli in REQUISITO. Se un'implementazione di un dispositivo è già stata lanciata su una versione precedente di Android e non è stato implementato un sistema operativo attendibile sull'hardware sicuro, questo dispositivo potrebbe non essere in grado di soddisfare i requisiti tramite un aggiornamento del software di sistema, pertanto è FORTEMENTE CONSIGLIATO implementare un TEE.

9.12. Eliminazione dei dati

I dispositivi DEVONO fornire agli utenti un meccanismo per eseguire un "ripristino dei dati di fabbrica" che consenta l'eliminazione logica e fisica di tutti i dati, ad eccezione dell'immagine di sistema e dei dati in altre partizioni che possono essere considerate parte dell'immagine di sistema. Questo DEVE soddisfare gli standard di settore pertinenti per l'eliminazione dei dati, come NIST SP800-88. Questo valore DEVE essere utilizzato per l'implementazione dell'API wipeData() (parte dell'API Android Device Administration) descritta nella sezione 3.9 Amministrazione dei dispositivi.

I dispositivi POSSONO fornire una cancellazione rapida dei dati che esegue un'eliminazione logica dei dati.

10. Test di compatibilità del software

Le implementazioni dei dispositivi DEVONO superare tutti i test descritti in questa sezione.

Tuttavia, tieni presente che nessun pacchetto di test software è completamente completo. Per questo motivo, agli implementatori di dispositivi è FORTEMENTE CONSIGLIATO di apportare il minor numero possibile di modifiche all'implementazione di riferimento e preferita di Android disponibile nell'Android Open Source Project. In questo modo ridurrai al minimo il rischio di introdurre bug che creano incompatibilità che richiedono il rifacimento e potenziali aggiornamenti del dispositivo.

10.1. Compatibility Test Suite (CTS)

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

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

10.2. Verificatore CTS

Le implementazioni dei dispositivi DEVONO eseguire correttamente tutti i casi applicabili nel Verificatore CTS. CTS Verifier è incluso nella Compatibility Test Suite ed è pensato per essere eseguito da un operatore umano per testare le funzionalità che non possono essere testate da un sistema automatico, ad esempio il corretto funzionamento di una fotocamera e dei sensori.

CTS Verifier include test per molti tipi di hardware, incluso hardware facoltativo. Le implementazioni dei dispositivi DEVONO superare tutti i test per l'hardware di cui sono dotati. Ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente lo scenario di test dell'accelerometro in CTS Verifier. Gli scenari di test per le funzionalità indicate come facoltative da questo Compatibility Definition Document POSSONO essere saltati o omessi.

Ogni dispositivo e ogni build DEVONO eseguire correttamente CTS Verifier, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori dei dispositivi eseguano esplicitamente il verificatore CTS su build che differiscono solo in modo banale. Nello specifico, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato lo strumento di verifica CTS solo per l'insieme di lingue, branding e così via inclusi POSSONO omettere il test dello strumento di verifica CTS.

11. Software aggiornabile

Le implementazioni dei dispositivi DEVONO includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire upgrade "in tempo reale", ovvero potrebbe essere necessario riavviare il dispositivo.

È possibile utilizzare qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, qualsiasi dei seguenti approccisoddisfa questo requisito:

• Download "over-the-air (OTA)" con aggiornamento offline tramite riavvio
• Aggiornamenti "in tethering" tramite USB da un PC host
• Aggiornamenti "offline" tramite riavvio e aggiornamento da un file su archiviazione rimovibile

Tuttavia, se l'implementazione del dispositivo include il supporto di una connessione dati non misurata come il profilo 802.11 o PAN (Personal Area Network) Bluetooth:

• Le implementazioni di Android Automotive DOVREBBERO supportare i download OTA con aggiornamento offline tramite riavvio.
• Tutte le altre implementazioni dei dispositivi DEVONO supportare i download OTA con aggiornamento offline tramite riavvio.

Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. ovvero, il meccanismo di aggiornamento DEVE preservare i dati privati e condivisi dell'applicazione. Tieni presente che il software Android upstream include un meccanismo di aggiornamento che soddisfa questo requisito.

Per le implementazioni dei dispositivi che vengono lanciate con Android 6.0 e versioni successive, il meccanismo di aggiornamento DEVE supportare la verifica che l'immagine di sistema sia identica al risultato previsto dopo un aggiornamento OTA. L'implementazione OTA basata su blocchi nell'Android Open Source Project upstream, aggiunta da Android 5.1, soddisfa questo requisito.

Se viene rilevato un errore nell'implementazione di un dispositivo dopo il rilascio, ma entro la durata ragionevole del prodotto, che viene stabilita in collaborazione con il team di compatibilità di Android, che influisce sulla compatibilità delle applicazioni di terze parti, l'implementatore del dispositivo DEVE correggere l'errore tramite un aggiornamento software disponibile che può essere applicato in base al meccanismo appena descritto.

Android include funzionalità che consentono all'app Proprietario dispositivo (se presente) di controllare l'installazione degli aggiornamenti di sistema. Per semplificare questa operazione, il sottosistema di aggiornamento di sistema per i dispositivi che segnalano android.software.device_admin DEVE implementare il comportamento descritto nella classe SystemUpdatePolicy [ Resources, 138].

12. Log delle modifiche del documento

La tabella seguente contiene un riepilogo delle modifiche alla definizione di compatibilità in questa release.

Sezione	Riepilogo delle modifiche
Vari	Le istanze del termine "incoraggiato" sono state sostituite con "CONSIGLIATO"
2. Tipi di dispositivi	Aggiornamento per le implementazioni di Android Automotive
3.2.2. Parametri di compilazione	Aggiunte per il numero di serie dell'hardware e per il livello della patch di sicurezza di una build
3.2.3.2. Risoluzione dell'intent	La sezione è stata rinominata da "Sostituzione intent" in "Risoluzione intent", con nuovi requisiti relativi al collegamento delle app predefinite autorevoli
3.3.1. Application Binary Interface	Aggiunta per il supporto dell'ABI Android; modifica relativa al nome della libreria Vulkan
3.4.1. Compatibilità con WebView	Modifica della stringa dello user agent segnalata da WebView
3.7. Compatibilità di runtime	Aggiornamenti alla tabella di allocazione della memoria
3.8.4. Cerca	Aggiornamenti relativi ai requisiti dell'assistente
3.8.6. Temi	È stato aggiunto il requisito di supporto delle icone di sistema nere quando richiesto dal flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR
3.8.8. Cambio attività	È stato allentato il requisito relativo al numero di titoli della scheda Panoramica.
3.8.10. Controllo dei contenuti multimediali nella schermata di blocco	Controllo dei contenuti multimediali dalla schermata di blocco per consultare la sezione 3.8.3 in dettaglio.
3.9.1. Provisioning del dispositivo	Contiene nuove sezioni per il provisioning del proprietario del dispositivo e il provisioning del profilo gestito
3.9.2. Assistenza per i profili gestiti	Nuova sezione con i requisiti per il supporto della funzionalità del profilo gestito da parte del dispositivo
3.12.1. App TV	È stata aggiunta una sezione per chiarire i requisiti delle app per TV per i dispositivi Android TV
3.12.1.1. Guida elettronica ai programmi	È stata aggiunta una sezione per chiarire i requisiti EPG per i dispositivi Android TV
3.12.1.2. Navigazione	È stata aggiunta una sezione per chiarire i requisiti di navigazione delle app TV per i dispositivi Android TV
3.12.1.3. Collegamento delle app all'ingresso TV	È stata aggiunta una sezione per chiarire i requisiti di supporto per il collegamento delle app di input TV per i dispositivi Android TV
5.1. Codec multimediali	Aggiornamenti relativi al supporto della decodifica e dei formati multimediali di base.
5.1.3. Codec video	Modifiche e aggiunte relative alle TV Android
5.2. Codifica video	Modifiche per gli encoder
5.3. Decodifica video	Modifiche ai decoder, tra cui il supporto della risoluzione video dinamica, il passaggio della frequenza fotogrammi e altro ancora
5.4. Registrazione audio	Aggiunta di funzionalità relative all'acquisizione audio
5.6. Latenza audio	Aggiornamento relativo alla segnalazione del supporto per l'audio a bassa latenza
5.10. Audio professionale	Aggiornamenti generali per il supporto audio professionale; aggiornamenti per le specifiche dei dispositivi mobili (jack), la modalità host audio USB e altri aggiornamenti
5.9. Musical Instrument Digital Interface (MIDI)	È stata aggiunta una nuova sezione sul supporto facoltativo dell'interfaccia MIDI (Musical Instrument Digital Interface)
6.1. Strumenti per sviluppatori	Aggiornamento per i driver che supportano Windows 10
7.1.1.3. Densità schermo	Aggiornamenti per la densità dello schermo, ad esempio relativi a uno smartwatch Android
7.2.3. Tasti di navigazione	Requisiti aggiornati per le implementazioni dei dispositivi che includono l'azione Assist
7.3. Sensori (e sottosezioni)	Nuovi requisiti per alcuni tipi di sensori
7.3.9. Sensori ad alta fedeltà	Nuova sezione con i requisiti per i dispositivi che supportano sensori ad alta fedeltà
7.3.10. Sensore di impronte digitali	Nuova sezione sui requisiti relativi ai sensori di impronte digitali
7.4.2. IEEE 802.11 (Wi-Fi)	Aggiornamenti relativi al supporto del multicast DNS (mDNS)
7.4.3. Bluetooth	Aggiunta relativa all'indirizzo privato risolvibile (RPA) per Bluetooth Low Energy (BLE)
7.4.4. Near Field Communication	Aggiunta di requisiti per la tecnologia Near Field Communication (NFC)
7.4.5. Capacità di rete minima	Requisiti aggiunti per il supporto IPv6
7.6.3. Spazio di archiviazione utilizzabile	Nuova sezione per l'implementazione dello spazio di archiviazione utilizzabile
7.7. USB	Requisito relativo all'implementazione della specifica AOA
7.8.3. Near-Ultrasound	Aggiunta di funzionalità relative a registrazione, riproduzione e audio in prossimità di ultrasuoni	Allentamento del requisito SNR del microfono a ultrasuoni.
8.3. Modalità di risparmio energetico	Nuova sezione con i requisiti relativi alle modalità App Standby e Sospensione
8.4. Contabilità del consumo energetico	Nuova sezione con i requisiti per monitorare il consumo di energia dei componenti hardware e attribuirlo ad applicazioni specifiche
9.1. Autorizzazioni	Aggiunta ai requisiti relativi alle autorizzazioni
9.7. Funzionalità di sicurezza del kernel	Aggiornamenti SE Linux
9.8. Privacy	Aggiunta relativa al consenso dell'utente per l'accesso allo spazio di archiviazione condiviso tramite una porta USB
9.9. Crittografia completa del disco	Requisiti relativi alla crittografia completa del disco
9.10. Avvio verificato	Requisito aggiuntivo per l'avvio verificato
9.11. Chiavi e credenziali	Nuova sezione dei requisiti relativi a chiavi e credenziali
9.12. Eliminazione dei dati	Nuova sezione per "Ripristino dei dati di fabbrica"
11. Software aggiornabile	Requisito relativo ai criteri di aggiornamento del sistema impostati dal proprietario del dispositivo

13. Contattaci

Puoi partecipare al forum Android Compatibility [Risorse, 139] e chiedere chiarimenti o segnalare eventuali problemi che ritieni non trattati nel documento.

14. Risorse

1. Livelli di requisiti RFC2119 IETF: http://www.ietf.org/rfc/rfc2119.txt

2. Android Open Source Project: http://source.android.com/

3. Funzionalità di Android TV: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Funzionalità di Android Watch: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. API Android UI_MODE_TYPE_CAR: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

6. Definizioni e documentazione dell'API: http://developer.android.com/reference/packages.html

7. Documentazione di riferimento per le autorizzazioni Android: http://developer.android.com/reference/android/Manifest.permission.html

8. Riferimento android.os.Build: http://developer.android.com/reference/android/os/Build.html

9. Stringhe di versione consentite per Android 6.0: http://source.android.com/docs/compatibility/6.0/versions.html

10. Impostazioni per gli sviluppatori Android: http://developer.android.com/reference/android/provider/Settings.html

11. Fornitore di servizi di telefonia: http://developer.android.com/reference/android/provider/Telephony.html

12. Gestione ABI Android NDK: https://developer.android.com/ndk/guides/abis.html

13. Architettura SIMD avanzata: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html

14. Android Extension Pack: http://developer.android.com/guide/topics/graphics/opengl.html#aep

15. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

16. Compatibilità di WebView: http://www.chromium.org/

17. HTML5: http://html.spec.whatwg.org/multipage/

18. Funzionalità offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline

19. Tag video HTML5: http://dev.w3.org/html5/spec/Overview.html#video

20. API Geolocation HTML5/W3C: http://www.w3.org/TR/geolocation-API/

21. API webstorage HTML5/W3C: http://www.w3.org/TR/webstorage/

22. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/

23. Formato eseguibile Dalvik e specifica del bytecode: disponibile nel codice sorgente di Android, in dalvik/docs

24. AppWidget: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

25. Notifiche: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

26. Risorse per le applicazioni: https://developer.android.com/guide/topics/resources/available-resources.html

27. Style guide per le icone della barra di stato: http://developer.android.com/design/style/iconography.html

28. Risorse per le notifiche: https://developer.android.com/design/patterns/notifications.html

29. Gestione ricerche: http://developer.android.com/reference/android/app/SearchManager.html

30. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

31. API Android Assist: https://developer.android.com/reference/android/app/assist/package-summary.html

32. Messaggi popup: http://developer.android.com/reference/android/widget/Toast.html

33. Temi: http://developer.android.com/guide/topics/ui/themes.html

34. Classe R.style: http://developer.android.com/reference/android/R.style.html

35. Material Design: http://developer.android.com/reference/android/R.style.html#Theme_Material

36. Sfondi animati: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

37. Risorse per la schermata Panoramica: http://developer.android.com/guide/components/recents.html

38. Blocco su schermo: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

39. Metodi di inserimento: http://developer.android.com/guide/topics/text/creating-input-method.html

40. Notifica multimediale: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

41. Sogni: http://developer.android.com/reference/android/service/dreams/DreamService.html

42. LOCATION_MODE di Settings.Secure: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

43. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

44. Amministrazione dispositivo Android: http://developer.android.com/guide/topics/admin/device-admin.html

45. Documentazione di riferimento di DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

46. App del proprietario del dispositivo: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

47. Flusso di provisioning del proprietario dispositivo Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE

48. Provisioning del proprietario del dispositivo tramite NFC: /devices/tech/admin/provision.html#device_owner_provisioning_via_nfc

49. App Android per il proprietario del profilo:http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)

50. Flusso di provisioning del profilo gestito Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE

51. API Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

52. API Android Accessibility: http://developer.android.com/reference/android/view/accessibility/package-summary.html

53. Progetto Eyes Free: http://code.google.com/p/eyes-free

54. API Text-to-Speech: http://developer.android.com/reference/android/speech/tts/package-summary.html

55. Television Input Framework: /devices/tv/index.html

56. Canali dell'app TV: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html

57. Ingressi TV di terze parti: /devices/tv/index.html#third-party_input_example

58. Ingressi TV: /devices/tv/index.html#tv_inputs

59. Campi EPG dei canali TV: https://developer.android.com/reference/android/media/tv/TvContract.Programs.html

60. Collegamento delle app di input TV: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI

61. Documentazione dello strumento di riferimento (per adb, aapt, ddms, systrace): http://developer.android.com/tools/help/index.html

62. Descrizione del file APK Android: http://developer.android.com/guide/components/fundamentals.html

63. File manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html

64. Formati multimediali Android: http://developer.android.com/guide/appendix/media-formats.html

65. API Android MediaCodecList: http://developer.android.com/reference/android/media/MediaCodecList.html

66. API Android CamcorderProfile: http://developer.android.com/reference/android/media/CamcorderProfile.html

67. Progetto WebM: http://www.webmproject.org/

68. Requisiti di codifica hardware RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/

69. API AudioEffect: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

70. Classe android.content.pm.PackageManager di Android e elenco delle funzionalità hardware: http://developer.android.com/reference/android/content/pm/PackageManager.html

71. Protocollo HTTP Live Streaming in versione preliminare: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

72. ADB: http://developer.android.com/tools/help/adb.html

73. Dumpsys: /devices/input/diagnostics.html

74. DDMS: http://developer.android.com/tools/debugging/ddms.html

75. Strumento di test Monkey: http://developer.android.com/tools/help/monkey.html

76. Strumento Systrace: http://developer.android.com/tools/help/systrace.html

77. Impostazioni relative allo sviluppo di app per Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

78. Supporto di più schermi: http://developer.android.com/guide/practices/screens_support.html

79. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

80. RenderScript: http://developer.android.com/guide/topics/renderscript/

81. Pacchetto di estensioni Android per OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

82. Accelerazione hardware: http://developer.android.com/guide/topics/graphics/hardware-accel.html

83. Estensione EGL-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

84. Display Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

85. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

86. Configurazione dell'input tocco: http://source.android.com/docs/core/interaction/input/touch-devices

87. API Motion Event: http://developer.android.com/reference/android/view/MotionEvent.html

88. API Key Event: http://developer.android.com/reference/android/view/KeyEvent.html

89. Sensori Android Open Source: http://source.android.com/docs/core/interaction/sensors

90. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

91. Timestamp sensor event: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

92. Sensori compositi di Android Open Source: /docs/core/interaction/sensors/sensor-types#composite_sensor_type_summary

93. Modalità di attivazione continua: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

95. API Android Fingerprint: https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html

96. HAL Android Fingerprint: /devices/tech/security/authentication/fingerprint-hal.html

97. API multicast Wi-Fi: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

98. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

99. API WifiManager: http://developer.android.com/reference/android/net/wifi/WifiManager.html

100. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

101. API ScanFilter Bluetooth: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

102. NFC Barcode: http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html

103. Protocollo NDEF Push: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

104. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

105. Impostazioni di condivisione NFC di Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

106. NFC Connection Handover: http://members.nfc-forum.org/specs/spec_list/#conn_handover

107. Accoppiamento sicuro semplice Bluetooth tramite NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

108. Emulazione di carte basata su host: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

109. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html

110. API di orientamento della fotocamera: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

111. Fotocamera: http://developer.android.com/reference/android/hardware/Camera.html

112. Fotocamera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

113. Livello hardware della fotocamera: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

114. Supporto della versione della fotocamera: http://source.android.com/docs/core/camera/versioning

115. DownloadManager di Android: http://developer.android.com/reference/android/app/DownloadManager.html

116. Android File Transfer: http://www.android.com/filetransfer

117. Spazio di archiviazione adottabile: http://source.android.com/docs/core/storage/adoptable

118. Android Open Accessories: http://developer.android.com/guide/topics/connectivity/usb/accessory.html

119. Audio USB Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

120. Specifiche per la ricarica della batteria USB, revisione 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

121. API host USB: http://developer.android.com/guide/topics/connectivity/usb/host.html

122. Cuffie audio con cavo: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec

123. Componenti del profilo di alimentazione: http://source.android.com/docs/core/power/values

124. Batterystats: https://developer.android.com/tools/dumpsys#battery

125. Riepilogo dell'utilizzo di energia: http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY

126. Documentazione di riferimento per la sicurezza e le autorizzazioni di Android: http://developer.android.com/guide/topics/security/permissions.html

127. Riferimento a UserManager: http://developer.android.com/reference/android/os/UserManager.html

128. Riferimento all'archiviazione esterna: http://source.android.com/docs/core/storage/traditional

129. API di archiviazione esterna: http://developer.android.com/reference/android/os/Environment.html

130. Short code SMS: http://it.wikipedia.org/wiki/Short_code

131. Report sulla schermata di blocco sicura: http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()

132. Crittografia open source di Android: http://source.android.com/docs/security/features/encryption

133. Sistema Android Keystore: https://developer.android.com/training/articles/keystore.html

134. API KeyChain: https://developer.android.com/reference/android/security/KeyChain.html

135. API Keystore: https://developer.android.com/reference/java/security/KeyStore.html

136. HAL Gatekeeper: http://source.android.com/docs/security/features/authentication/gatekeeper

137. Panoramica del Programma di compatibilità Android: http://source.android.com/docs/compatibility

138. Classe SystemUpdatePolicy: http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html

139. Forum sulla compatibilità Android: https://groups.google.com/forum/#!forum/android-compatibility

140. Gestione dei link per app: https://developer.android.com/training/app-links/index.html

141. Google Digital Asset Links: https://developers.google.com/digital-asset-links

Molte di queste risorse sono ricavate direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni riportate nella documentazione dell'SDK. In tutti i casi in cui questa definizione di compatibilità o la Compatibility Test Suite non è in accordo con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Eventuali dettagli tecnici forniti nei riferimenti inclusi sopra sono considerati parte di questa Definizione di compatibilità.