1. Introduzione

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

L'uso di "DEVE", "NON DEVE", "OBBLIGATORIO", "DEVE", "NON DEVE", "DEVE", "NON DEVE", "CONSIGLIATO", "PUÒ" e "FACOLTATIVO" è conforme allo standard IETF definito nella RFC2119 .

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

Per essere considerate compatibili con Android 7.1, 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, l'Android Open Source Project è sia l'implementazione di riferimento sia quella preferita di Android. È FORTEMENTE CONSIGLIATO agli implementatori di dispositivi di basare le proprie implementazioni il più possibile sul codice sorgente "upstream" disponibile nell'Android Open Source Project. Sebbene alcuni componenti possano essere teoricamente sostituiti con implementazioni alternative, è FORTEMENTE CONSIGLIATO di non seguire questa pratica, in quanto superare i test software diventerà notevolmente più difficile. È responsabilità dell'implementatore garantire la piena compatibilità comportamentale con l'implementazione standard di Android, inclusi e oltre il Compatibility Test Suite. Infine, tieni presente che alcune sostituzioni e modifiche dei componenti sono vietate esplicitamente da questo documento.

Molte delle risorse a cui si fa riferimento in questo documento derivano 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 linea con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Eventuali dettagli tecnici forniti nelle risorse collegate in questo documento 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 serie 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 l'utilizzo 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 "a tre metri di distanza"). 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.

Per dispositivo Android Watch si intende un'implementazione di un dispositivo Android progettata per essere indossata sul corpo, ad esempio 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 .

L'implementazione di Android Automotive si riferisce a un'unità principale del veicolo con Android come sistema operativo per parte o per tutte le funzionalità del sistema e/o di infotainment. Implementazioni di Android Automotive:

• DEVE avere uno schermo con una diagonale fisica pari o superiore a 15 cm.
• DEVE dichiarare la funzionalità android.hardware.type.automotive.
• DEVE supportare uiMode = UI_MODE_TYPE_CAR .
• Le implementazioni di Android Automotive DEVONO supportare tutte le API pubbliche nello spazio dei nomi android.car.*.

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 7.1, 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	DOVREBBE		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
	Segnale radio cell	7.4.5. Capacità di rete minima				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 codice 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 o di qualsiasi API decorata con l'indicatore "@SystemApi" nel codice sorgente di Android upstream.

Le implementazioni dei dispositivi DEVONO supportare/preservare tutte le classi, i metodi e gli elementi associati contrassegnati dall'annotazione TestApi (@TestApi).

Le implementazioni dei dispositivi NON DEVONO omettere API gestite, modificare interfacce o firme delle API, discostarsi dal comportamento documentato o includere no-op, salvo nei casi specificamente consentiti 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.1.1. Estensioni Android

Android include il supporto per l'estensione delle API gestite mantenendo la stessa versione del livello API. Le implementazioni dei dispositivi Android DEVONO precaricare l'implementazione AOSP sia della libreria condivisa ExtShared sia dei servizi ExtServices con versioni superiori o uguali alle versioni minime consentite per ogni livello API. Ad esempio, le implementazioni dei dispositivi Android 7.0 con livello API 24 DEVONO includere almeno la versione 1.

3.2. Compatibilità API soft

Oltre alle API gestite della sezione 3.1, Android include anche un'API "soft" significativa solo di runtime, sotto forma di 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 . 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 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 7.1 .
VERSION.SDK	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 7.1, questo campo DEVE avere il valore intero 7.1_INT.
VERSION.SDK_INT	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 7.1, questo campo DEVE avere il valore intero 7.1_INT.
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_-]+$". Il nome del dispositivo NON DEVE cambiare durante la vita utile del prodotto.
FINGERPRINT	Una stringa che identifica in modo univoco questa build. DOVREBBE 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:7.1/LMYXX/3359:userdebug/test-keys L'impronta NON DEVE includere caratteri di spazio vuoto. Se altri campi inclusi nel modello riportato sopra contengono spazi vuoti, DEVONO essere sostituiti nell'impronta della build con un altro carattere, ad esempio il trattino basso ("_"). 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. 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 versione specifica, in un formato leggibile. Questo campo può essere uguale ad 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 noto all'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la 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 brand. 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_-]+$". Il nome del prodotto NON DEVE cambiare durante il ciclo di vita del prodotto.
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 tipiche: 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 build non è in alcun modo vulnerabile a nessuno dei problemi descritti nel Bollettino pubblico sulla sicurezza di Android designato. DEVE essere nel formato [AAAA-MM-GG] e corrispondere a una stringa definita documentata nel Bollettino pubblico sulla sicurezza di Android o nell'Avviso sulla sicurezza di Android, ad esempio "2015-11-01".
BASE_OS	Un valore che rappresenta il parametro FINGERPRINT della build, che è altrimenti identico a questa build, ad eccezione delle patch fornite nel bollettino Android Public Security. 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

3.2.3.1. Intent di applicazione principali

Gli intent Android consentono ai componenti dell'applicazione di richiedere funzionalità ad 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 DEVONO includere le applicazioni Android di base, a seconda dei casi, o un componente che implementi gli stessi pattern di intent definiti da tutti i componenti Activity o Service di queste applicazioni Android di base esposti ad altre applicazioni, implicitamente o esplicitamente, tramite l'attributo android:exported.

3.2.3.2. Risoluzione dell'intent

Poiché Android è una piattaforma estensibile, le implementazioni dei dispositivi DEVONO consentire a ogni pattern 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 assegnare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema o impedire alle applicazioni di terze parti di associarsi a questi pattern e assumerne il controllo. Questo divieto include, in particolare, 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 dati "http://www.android.com" è più specifico del pattern di intent principale del browser per "http://".

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

• DEVE tentare di convalidare tutti i filtri per intent eseguendo i passaggi di convalida definiti nella specifica Digital Asset Links, come implementato 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 esegue questa operazione, 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 ignorare in modo olistico il comportamento predefinito dei link alle app per un'app: sempre aperta, sempre chiedi o mai aperta, che deve essere applicato allo stesso modo a tutti i filtri di intent URI candidati.
  • 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 a 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 intent di trasmissione utilizzando un'azione, una categoria o un'altra stringa chiave nello spazio dei nomi android. o com.android. Gli implementatori dei dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o di trasmissione di intent utilizzando una stringa ACTION, CATEGORY o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione. Gli implementatori dei dispositivi NON DEVONO modificare o estendere nessuno dei pattern di intent utilizzati dalle app di base elencate nella sezione 3.2.3.1 . Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano spazi dei nomi chiaramente e inequivocabilmente associati alla propria organizzazione. Questo divieto è analogo a quello specificato per i corsi 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 al fine di essere avvisate delle modifiche nell'ambiente hardware o software. I dispositivi compatibili con Android DEVONO trasmettere gli intent di trasmissione pubblica in risposta a eventi di sistema appropriati. 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 delle impostazioni simile ed essere compatibili con il pattern del filtro 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 dell'app predefinite per la schermata Home, se l'implementazione del dispositivo segnala android.software.home_screen.
• DEVE fornire un menu delle impostazioni che chiami l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT per mostrare una finestra di dialogo per modificare l'applicazione SMS predefinita, se l'implementazione del dispositivo segnala android.hardware.telephony.
• DEVE rispettare l'intent android.settings.NFC_PAYMENT_SETTINGS per mostrare un menu delle impostazioni dell'app predefinite per il pagamento contactless, se l'implementazione del dispositivo segnala android.hardware.nfc.hce.
• DEVE rispettare l'intent android.telecom.action.CHANGE_DEFAULT_DIALER per mostrare una finestra di dialogo che consenta all'utente di modificare l'applicazione Telefono predefinita, se l'implementazione del dispositivo segnala android.hardware.telephony .
• DEVE rispettare l'intent android.settings.ACTION_VOICE_INPUT_SETTINGS quando il dispositivo supporta VoiceInteractionService e mostrare un menu delle impostazioni dell'app predefinite per l'input vocale e l'assistente.

3.3. Compatibilità con le API native

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

3.3.1. Application Binary Interface

Il bytecode Dalvik gestito può chiamare il codice nativo fornito nel file APK dell'applicazione come file ELF .so compilato per l'architettura hardware del dispositivo appropriata. Poiché il codice nativo è altamente dipendente dalla tecnologia del processore sottostante, Android definisce una serie di interfacce a livello di codice macchina (ABI) nell'Android NDK. Le implementazioni dei dispositivi DEVONO essere compatibili con una o più ABI definite 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) di ogni libreria richiesta nell'elenco di seguito.
• DEVE supportare l'ABI a 32 bit equivalente se è supportato 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 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 e DEVE includere il supporto dell'estensione Advanced SIMD (nota anche come NEON).
• DEVE essere compilato utilizzando il codice sorgente e i file di intestazione disponibili nel progetto open source Android upstream

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

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

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

Per le librerie native elencate sopra, l'implementazione del dispositivo NON DEVE aggiungere o rimuovere le funzioni pubbliche.

Le librerie native non elencate sopra, ma implementate e fornite in AOSP come librerie di sistema, sono riservate e NON DEVONO essere esposte ad app di terze parti che hanno come target il livello API 24 o versioni successive.

Le implementazioni dei dispositivi POSSONO aggiungere librerie non AOSP ed esporle direttamente come API alle app di terze parti, ma le librerie aggiuntive DOVREBBERO trovarsi in /vendor/lib o /vendor/lib64 e DEVONO essere elencate in /vendor/etc/public.libraries.txt .

Tieni presente che le implementazioni del dispositivo DEVONO includere libGLESv3.so e, a loro volta, DEVONO esportare tutti i simboli delle funzioni OpenGL ES 3.1 e del pacchetto di estensioni Android come definito nella release NDK android-24. Sebbene tutti i simboli debbano essere presenti, devono essere implementate completamente solo le funzioni corrispondenti alle versioni e alle estensioni OpenGL ES effettivamente supportate dal dispositivo.

3.3.1.1. Librerie di immagini

Vulkan è un'API multipiattaforma a basso overhead per la grafica 3D ad alte prestazioni. Le implementazioni dei dispositivi, anche se non includono il supporto delle API Vulkan, DEVONO soddisfare i seguenti requisiti:

• DEVE sempre fornire una libreria nativa denominata libvulkan.so che esporterà i simboli di funzione per l'API Vulkan 1.0 di base , nonché le estensioni VK_KHR_surface , VK_KHR_android_surface e VK_KHR_swapchain.

Implementazioni del dispositivo, se includono il supporto delle API Vulkan:

• DEVE segnalare uno o più VkPhysicalDevices tramite la chiamata vkEnumeratePhysicalDevices.
• Ogni VkPhysicalDevices enumerato DEVE implementare completamente l'API Vulkan 1.0.
• DEBBONO segnalare i flag di funzionalità PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL e PackageManager#FEATURE_VULKAN_HARDWARE_VERSION corretti.
• DEBBONO enumerare i livelli contenuti nelle librerie native denominate libVkLayer*.so nella directory delle librerie native del pacchetto dell'applicazione tramite le funzioni vkEnumerateInstanceLayerProperties e vkEnumerateDeviceLayerProperties in libvulkan.so
• NON DEVE enumerare i livelli forniti dalle librerie al di fuori del pacchetto dell'applicazione o fornire altri modi per tracciare o intercettare l'API Vulkan, a meno che l'applicazione non abbia l'attributo android:debuggable=”true”.

Implementazioni dei dispositivi, se non includono il supporto delle API Vulkan:

• DEVE segnalare 0 VkPhysicalDevices tramite la chiamata vkEnumeratePhysicalDevices.
• NON DEVE dichiarare nessuno dei flag di funzionalità Vulkan PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL e PackageManager#FEATURE_VULKAN_HARDWARE_VERSION .

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

L'architettura ARMv8 ritira diverse operazioni della CPU, tra cui alcune utilizzate nel codice nativo esistente. Sui dispositivi ARM a 64 bit, le seguenti operazioni deprecate 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 rilevare le funzionalità della CPU dal 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 da 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 più recente supportata dal 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 viene letto 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 fornisca 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 . 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 build di Chromium del progetto open source Android upstream per Android 7.1. Questa build include un insieme specifico di correzioni di funzionalità e sicurezza per WebView.

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

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 (basata sull'applicazione Browser WebKit a monte o su un sostituto di terze parti) DEVE includere il supporto per il maggior numero possibile di funzionalità HTML5. Come minimo, le implementazioni dei dispositivi DEVONO supportare ciascuna di queste API associate ad HTML5:

• cache dell'applicazione/operazione offline
• Tag<video>
• geolocalizzazione

Inoltre, le implementazioni dei dispositivi DEVONO supportare l'API webstorage HTML5/W3C e DOVREBBERO supportare l'API IndexedDB HTML5/W3C . Tieni presente che, poiché gli enti di standardizzazione dello 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

I comportamenti di ciascuno dei tipi di API (gestite, soft, native e web) devono essere coerenti con l'implementazione preferita del progetto Android Open Source a monte . 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 porzioni significative della piattaforma per verificarne la compatibilità comportamentale, ma non tutte. È responsabilità dell'implementatore garantire la compatibilità del comportamento con il progetto open source Android. Per questo motivo, gli implementatori di dispositivi DOVREBBERO 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 classe.
• Gli implementatori dei dispositivi POSSONO modificare l'implementazione sottostante delle API, ma queste modifiche NON DEVONO influire sul comportamento dichiarato e sulla firma in linguaggio Java di eventuali API esposte pubblicamente.
• Gli implementatori dei dispositivi NON DEVONO aggiungere elementi esposti pubblicamente (ad esempio classi o interfacce oppure campi o metodi a classi o interfacce esistenti) alle API sopra indicate.

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

Gli implementatori dei dispositivi POSSONO aggiungere API personalizzate, ma queste API NON DEVONO trovarsi in uno spazio dei nomi di proprietà di un'altra organizzazione o che fanno riferimento a un'altra organizzazione. Ad esempio, gli implementatori dei dispositivi NON DEVONO aggiungere API al namespace com.google.* o a uno simile: solo Google può farlo. Analogamente, Google NON DEVE aggiungere API ai namespace di altre aziende. 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-library>) 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 il sito source.android.com e iniziare la procedura per apportare modifiche e codice, in base alle informazioni riportate sul 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 semantica e la specifica del bytecode Dalvik . 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 i 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 POTREBBERO 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 di applicazioni di terze parti per sostituire l'Avvio app del dispositivo (schermata Home). Le implementazioni dei dispositivi 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 un'API e un ciclo di vita corrispondenti che consentono alle applicazioni di esporre un "AppWidget" all'utente finale, 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.

• I lanci app dei dispositivi DEVONO includere il supporto integrato per gli AppWidget ed esporre funzionalità dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere gli AppWidget direttamente all'interno del programma di avvio.
• Le implementazioni dei dispositivi DEVONO essere in grado di eseguire il rendering di widget con dimensioni 4 x 4 nella griglia standard. Per maggiori dettagli, consulta le linee guida per la progettazione di widget per app nella documentazione dell'SDK Android.
• 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 inviare notifiche agli utenti di eventi importanti utilizzando le funzionalità hardware e software del dispositivo.

Alcune API consentono alle applicazioni di inviare notifiche o attirare l'attenzione utilizzando l'hardware, in particolare suoni, vibrazioni e luce. Le implementazioni 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 l'implementazione di un dispositivo include un vibratore, DEVE implementare correttamente le API di vibrazione. Se l'implementazione di un dispositivo non dispone di hardware, le API corrispondenti DEVONO essere implementate come no-op. Questo comportamento è descritto in maggiore dettaglio nella sezione 7 .

Inoltre, l'implementazione DEVE eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) previste nelle API o nella guida allo stile delle icone della barra di stato/del sistema, 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 documentato nelle API Android .

Android include le API Notification Listener Service che consentono alle app (una volta 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 questi servizi di ascolto installati e abilitati dall'utente, inclusi tutti i metadati associati all'oggetto Notification.

Le implementazioni dei dispositivi portatili DEVONO supportare i comportamenti di aggiornamento, rimozione, risposta e raggruppamento delle notifiche come descritto in questa sezione .

Inoltre, le implementazioni dei dispositivi palmari DEVONO fornire:

• La possibilità di controllare le notifiche direttamente nell'area notifiche.
• L'affordance visiva per attivare il pannello di controllo nell'area notifiche.
• La possibilità di BLOCCARE, DISATTIVARE L'AUDIO e RESETTARE la preferenza di notifica da un pacchetto, sia nel pannello di controllo in linea sia nell'app Impostazioni.

Tutti e sei i sottoclassi diretti di Notification.Style class DEVONO essere supportati come descritto nella documentazione dell'SDK .

Le implementazioni dei dispositivi che supportano la funzionalità Non disturbare DEVONO soddisfare i seguenti requisiti:

• DEVE implementare un'attività che risponda all'intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS , che per le implementazioni con UI_MODE_TYPE_NORMAL DEVE essere un'attività in cui l'utente può concedere o negare all'app l'accesso alle configurazioni dei criteri di modalità Non disturbare.
• OBBLIGATORIAMENTE, quando l'implementazione del dispositivo ha fornito all'utente un mezzo per concedere o negare alle app di terze parti l'accesso alla configurazione del criterio di modalità Non disturbare, devono essere visualizzate le regole automatiche della modalità Non disturbare create dalle applicazioni insieme alle regole predefinite e create dall'utente.
• DEVE rispettare i valori suppressedVisualEffects trasmessi tramite NotificationManager.Policy e, se un'app ha impostato uno degli indicatori SUPPRESSED_EFFECT_SCREEN_OFF o SUPPRESSED_EFFECT_SCREEN_ON, DEVE indicare all'utente che gli effetti visivi sono soppressi nel menu delle impostazioni della modalità Non disturbare.

3.8.4. Cerca

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

Le implementazioni dei dispositivi Android DEVONO includere la ricerca globale, un'interfaccia utente di ricerca singola, condivisa e a livello di sistema in grado di fornire suggerimenti in tempo reale in risposta all'input dell'utente. Le implementazioni dei dispositivi 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 DOVREBBERO e le implementazioni di Android Automotive DEVONO implementare un assistente sul dispositivo per gestire l'azione di assistenza .

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. 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 attorno 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 open source Android.

Questa indicazione PUÒ essere disattivata per impostazione predefinita per le app preinstallate che utilizzano l'API Assist e VoiceInteractionService, se sono soddisfatti tutti i seguenti requisiti:

• L'app preinstallata DEVE richiedere la condivisione del contesto solo quando l'utente ha richiamato l'app con uno dei seguenti metodi e l'app è in esecuzione in primo piano:

  • attivazione hotword
  • Immissione del tasto/pulsante/gesto di navigazione ASSIST

• L'implementazione del dispositivo DEVE fornire un'affordance per attivare l'indicazione, a meno di due passaggi dal menu delle impostazioni dell'app di assistenza e dell'input vocale predefinito) sezione 3.2.3.5 .

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. Le implementazioni dei dispositivi DEVONO mostrare le notifiche dagli utenti finali alle applicazioni 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 avere lo stesso aspetto del tema Holo definito dall'SDK Android. Le implementazioni dei dispositivi NON DEVONO alterare nessuno degli attributi del tema Holo esposti alle applicazioni.

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 alla vasta gamma di diversi tipi di dispositivi Android. Le implementazioni dei dispositivi DEVONO supportare la famiglia di temi "Material" e NON DEVONO modificare nessuno degli attributi del tema Material o i relativi asset esposti alle applicazioni.

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 dei dispositivi POSSONO modificare gli attributi del tema predefinito del dispositivo esposti alle applicazioni.

Android supporta un tema con barre di sistema traslucide, che consente agli sviluppatori di applicazioni di riempire l'area dietro la barra di stato e la barra di navigazione con i contenuti delle app. Per consentire un'esperienza utente coerente in questa configurazione, è importante che lo stile dell'icona della barra di stato venga mantenuto nelle diverse implementazioni del dispositivo. Pertanto, le implementazioni dei dispositivi Android DEVONO utilizzare il bianco per le icone di stato del 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 (per maggiori dettagli, consulta R.style).

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

Le implementazioni dei dispositivi in grado di eseguire sfondi animati in modo affidabile come descritto sopra DOVREBBERO 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 di panoramica , 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 dei dispositivi, inclusa la chiave di navigazione della funzionalità Recenti descritta nella sezione 7.2.3, POSSONO modificare l'interfaccia, ma DEVONO soddisfare i seguenti requisiti:

• DEVE supportare almeno 20 attività visualizzate.
• DEVE mostrare almeno il titolo di quattro attività alla volta.
• DEVE implementare il comportamento di blocco dello schermo e fornire all'utente un menu delle impostazioni per attivare/disattivare la funzionalità.
• DOVREBBE mostrare il colore di evidenziazione, l'icona e il titolo della schermata tra le app recenti.
• DOVREBBE mostrare un'affordance di chiusura ("x"), ma PUÒ ritardare questa azione finché l'utente non interagisce con le schermate.
• DOVREBBE implementare una scorciatoia per passare facilmente all'attività precedente
• POTREBBE mostrare i contenuti recenti affiliati come un gruppo che si sposta insieme.
• DOVREBBE attivare l'azione di passaggio rapido tra le due app utilizzate più di recente quando il tasto funzione Recenti viene toccato due volte.
• DOVREBBE attivare la modalità multifinestra con schermo diviso, se supportata, quando la chiave delle funzioni recenti viene premuta a lungo.

Per le implementazioni dei dispositivi è FORTEMENTE CONSIGLIATO utilizzare l'interfaccia utente Android a monte (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 immissione di terze parti. 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 immissione 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 in 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. Le implementazioni dei dispositivi che supportano una schermata di blocco, a meno che non si tratti di un'implementazione di Android Automotive o Watch, DEVONO mostrare le notifiche della schermata di blocco, incluso il modello di notifica multimediale.

3.8.11. Salvaschermo (in precedenza Sogni)

Android include il supporto per i salvaschermo interattivi , precedentemente noti come Sogni. I salvaschermo consentono agli utenti di interagire con le applicazioni quando un dispositivo collegato a una fonte di alimentazione è inattivo o agganciato alla base di ricarica. I dispositivi Android Watch POSSONO implementare i salvaschermo, ma altri tipi di implementazioni dei dispositivi DEVONO includere il supporto dei salvaschermo e fornire un'opzione di impostazioni per consentire agli utenti di configurarli 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 delle Impostazioni.

3.8.13. Unicode e carattere

Android include il supporto dei caratteri emoji definiti in Unicode 9.0 . Tutte le implementazioni dei dispositivi DEVONO essere in grado di eseguire il rendering di questi caratteri emoji in un glifo a colori e, quando le implementazioni dei dispositivi Android includono un IME, DEVONO fornire all'utente un metodo di inserimento per questi caratteri emoji.

I dispositivi mobili Android DOVREBBERO supportare il tono della pelle e le diverse emoji di famiglia come specificato nel report tecnico Unicode n. 51.

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 le lingue disponibili sul dispositivo e per una copertura completa di Unicode 7.0 per latino, greco e cirillico, inclusi gli intervalli Latin Extended A, B, C e D e tutti i glifi nel blocco dei simboli di valuta di Unicode 7.0.

3.8.14. Multi-finestra

Un'implementazione del dispositivo PUÒ scegliere di non implementare alcuna modalità multi-finestra, ma se ha la capacità di visualizzare più attività contemporaneamente DEVE implementare queste modalità multi-finestra in conformità con i comportamenti e le API dell'applicazione descritti nella documentazione di supporto della modalità multi-finestra dell'SDK Android e soddisfare i seguenti requisiti:

• Le applicazioni possono indicare se sono in grado di operare in modalità multi-finestra nel file AndroidManifest.xml, esplicitamente tramite l'attributo android:resizeableActivity o implicitamente impostando targetSdkVersion su un valore maggiore di 24. Le app che impostano esplicitamente questo attributo su false nel file manifest NON devono essere avviate in modalità multi-finestra. Le app che non impostano l'attributo nel file manifest (targetSdkVersion < 24) possono essere avviate in modalità multi-finestra, ma il sistema DEVE fornire un avviso che l'app potrebbe non funzionare come previsto in questa modalità.
• Le implementazioni dei dispositivi NON DEVONO offrire la modalità a schermo diviso o a forma libera se sia l'altezza sia la larghezza dello schermo sono inferiori a 440 dp.
• Le implementazioni dei dispositivi con dimensioni dello schermo xlarge DEVONO supportare la modalità a forma libera.
• Le implementazioni dei dispositivi Android TV DEVONO supportare la modalità Picture-in-picture (PIP) con più finestre e posizionare la modalità PIP con più finestre nell'angolo in alto a destra quando la modalità PIP è attiva.
• Le implementazioni dei dispositivi con supporto della modalità PIP a più finestre DEVONO allocare almeno 240 x 135 dp per la finestra PIP.
• Se la modalità multi-finestra PIP è supportata, la chiave KeyEvent.KEYCODE_WINDOW DEVE essere utilizzata per controllare la finestra PIP; in caso contrario, la chiave DEVE essere disponibile per l'attività in primo piano.

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. Le implementazioni del dispositivo DEVONO fornire un'implementazione della classe DevicePolicyManager. Le implementazioni dei dispositivi che supportano una schermata di blocco sicura DEVONO implementare l'intera gamma di criteri di amministrazione del dispositivo definiti nella documentazione dell'SDK Android 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 un'implementazione del dispositivo dichiara la funzionalità android.software.device_admin, DEVE implementare il provisioning dell'app Proprietario dispositivo di un'applicazione Device Policy Client (DPC) come indicato di seguito:

• Quando l'implementazione del dispositivo non ha ancora configurato i dati utente:
  • È OBBLIGATORIO segnalare true per DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) .
  • DEVE registrare l'applicazione DPC come app Proprietario dispositivo in risposta all'azione intent android.app.action.PROVISION_MANAGED_DEVICE .
  • DEVE registrare l'applicazione DPC come app Proprietario dispositivo se il dispositivo dichiara il supporto della tecnologia Near Field Communication (NFC) tramite il flag di funzionalità android.hardware.nfc e riceve un messaggio NFC contenente un record con tipo MIME MIME_TYPE_PROVISIONING_NFC .
• Quando l'implementazione del dispositivo contiene dati utente:
  • È OBBLIGATORIO segnalare false per DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) .
  • NON DEVE più registrare alcuna applicazione DPC come app di proprietà del dispositivo.

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.

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 .

L'esperienza utente del processo di provisioning del profilo gestito (il flusso avviato da android.app.action.PROVISION_MANAGED_PROFILE) DEVE essere in linea con l'implementazione AOSP.

Le implementazioni dei dispositivi DEVONO fornire le seguenti funzionalità per l'utente all'interno dell'interfaccia utente Impostazioni per indicare all'utente quando una determinata funzionalità di sistema è stata disattivata dal Device Policy Controller (DPC):

• Un'icona coerente o un'altra funzionalità per l'utente (ad esempio l'icona di informazioni AOSP a monte) per indicare quando una determinata impostazione è limitata da un amministratore dispositivo.
• Un breve messaggio esplicativo, fornito dall'amministratore dispositivo tramite setShortSupportMessage .
• L'icona dell'applicazione DPC.

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.
• Consenti la creazione di un solo profilo gestito .
• 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 del 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 l'utilizzo di batteria, posizione, dati mobili e spazio di archiviazione per l'utente principale e il profilo gestito.
  • Gestione indipendente delle applicazioni VPN installate nell'utente principale o nel profilo gestito.
  • Gestione indipendente delle applicazioni installate nell'utente principale o nel profilo gestito.
  • Gestione indipendente degli account all'interno dell'utente principale o del profilo gestito.
• Assicurati che le applicazioni di tastiera, contatti e messaggistica preinstallate possano cercare e trovare le informazioni sull'autore della chiamata dal profilo gestito (se esistente) insieme a quelle del profilo principale, se il controller Device Policy lo consente. Quando i contatti del profilo gestito vengono visualizzati nel registro chiamate preinstallato, nell'interfaccia utente durante la chiamata, nelle notifiche di chiamate in corso e perse, nelle app di contatti e messaggistica, DEVONO essere contrassegnati con lo stesso badge utilizzato per indicare le applicazioni del profilo gestito.
• 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.
• Supportare la possibilità di specificare una schermata di blocco separata che soddisfi i seguenti requisiti per concedere l'accesso alle app in esecuzione in un profilo gestito.
  • Le implementazioni del dispositivo DEVONO rispettare l'intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrare un'interfaccia per configurare una credenziale della schermata di blocco separata per il profilo gestito.
  • Le credenziali della schermata di blocco del profilo gestito DEVONO utilizzare gli stessi meccanismi di archiviazione e gestione delle credenziali del profilo principale, come descritto sul sito del progetto open source Android
  • I criteri delle password del DPC DEVONO essere applicati solo alle credenziali della schermata di blocco del profilo gestito, a meno che non vengano richiamati nell'istanza DevicePolicyManager restituita da getParentProfileInstance .

3.10. Accessibilità

Android fornisce un livello di accessibilità che aiuta gli utenti con disabilità a navigare più facilmente nei loro dispositivi. Inoltre, Android fornisce API di piattaforma che consentono alle implementazioni dei servizi di accessibilità di ricevere callback per eventi utente e di sistema e di generare meccanismi di feedback alternativi, come la sintesi vocale, il feedback aptico e la navigazione con trackball/d-pad.

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à 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 .
• 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 (sono esclusi i dispositivi Android Automotive e Android Watch senza uscita audio) DEVONO fornire un meccanismo accessibile agli utenti per attivare e disattivare i servizi di accessibilità e DEVONO mostrare questa interfaccia in risposta all'intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

• È FORTEMENTE CONSIGLIATO implementare sui dispositivi Android con uscita audio servizi di accessibilità paragonabili o superiori per funzionalità ai servizi di accessibilità TalkBack** e Switch Access (https://github.com/google/talkback).

• I dispositivi Android Watch con uscita audio DOVREBBERO fornire implementazioni di un servizio di accessibilità sul dispositivo paragonabili o superiori alla funzionalità del servizio di accessibilità TalkBack (https://github.com/google/talkback).
• Le implementazioni dei dispositivi DEVONO fornire un meccanismo nel flusso di configurazione out-of-box per consentire agli utenti di attivare i servizi di accessibilità pertinenti, nonché opzioni per regolare le dimensioni dei caratteri, le dimensioni del display e i gesti di ingrandimento.

** Per le lingue supportate dalla sintesi vocale.

Inoltre, tieni presente che se è presente un servizio di accessibilità precaricato, DEVE essere un'app {directBootAware} compatibile con il riavvio diretto se lo spazio di archiviazione del dispositivo è criptato utilizzando la crittografia basata su file (FBE).

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. 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 all'utente 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 che supporti le lingue disponibili sul dispositivo. Tieni presente che il software open source Android upstream include un'implementazione del motore TTS completa.
• 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

L'Android Television Input Framework (TIF) semplifica l'importazione di contenuti dal vivo sui 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.

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'applicazione TV (app TV) installata. Android Open Source Project fornisce un'implementazione dell'app TV.

L'app TV DEVE fornire strumenti per installare e utilizzare i canali TV 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).
• Le implementazioni dei dispositivi POSSONO prevedere una separazione visiva tra gli input basati su TIF preinstallati (input installati) e quelli di terze parti.
• Le implementazioni dei dispositivi 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. L'EPG DEVE soddisfare i seguenti requisiti:

• L'EPG DEVE mostrare le informazioni di tutti gli ingressi installati e 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 ingressi installati e quelli di terze parti con la stessa evidenza. L'EPG NON DEVE mostrare gli ingressi di terze parti a 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

L'app TV DEVE consentire la navigazione per le seguenti funzioni tramite i tasti D-pad, Indietro e Home sui dispositivi di input del dispositivo Android TV (ad es. telecomando, applicazione di controllo remoto o controller di gioco):

• Cambio dei canali TV
• Apertura EPG
• Configurazione e ottimizzazione in base a input basati su TIF di terze parti
• Apertura del menu Impostazioni

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 dall'attività corrente a un'altra attività (ad es. un link dalla programmazione in diretta ai contenuti correlati). L'app TV DEVE mostrare il collegamento dell'app di input TV quando viene fornito.

3.12.1.4. Spostamento temporale

Le implementazioni dei dispositivi Android TV DEVONO supportare il time shifting, che consente all'utente di mettere in pausa e riprendere i contenuti in diretta. Le implementazioni dei dispositivi DEVONO fornire all'utente un modo per mettere in pausa e riprendere il programma attualmente in riproduzione, se il fuso orario per quel programma è disponibile .

3.12.1.5. Registrazione TV

È MOLTO CONSIGLIATO implementare i dispositivi Android TV per supportare la registrazione TV. Se l'ingresso della TV supporta la registrazione, l'EPG POTREBBE fornire un modo per registrare un programma se la registrazione di questo programma non è vietata . Le implementazioni dei dispositivi DEVONO fornire un'interfaccia utente per riprodurre i programmi registrati.

3.13. Impostazioni rapide

Le implementazioni dei dispositivi Android DEVONO includere un componente dell'interfaccia utente Impostazioni rapide che consenta di accedere rapidamente alle azioni utilizzate di frequente o necessarie con urgenza.

Android include l'API quicksettings che consente alle app di terze parti di implementare riquadri che possono essere aggiunti dall'utente insieme a quelli forniti dal sistema nel componente dell'interfaccia utente Impostazioni rapide. Se un'implementazione del dispositivo ha un componente dell'interfaccia utente delle Impostazioni rapide:

• DEVE consentire all'utente di aggiungere o rimuovere riquadri da un'app di terze parti alle Impostazioni rapide.
• NON DEVE aggiungere automaticamente un riquadro di un'app di terze parti direttamente alle Impostazioni rapide.
• DEVE mostrare tutti i riquadri aggiunti dall'utente da app di terze parti insieme ai riquadri delle impostazioni rapide forniti dal sistema.

3.14. API di interfaccia utente del veicolo

3.14.1. UI di Contenuti veicoli

Qualsiasi implementazione del dispositivo che dichiara il supporto per i veicoli DEVE includere un framework UI per supportare le app di terze parti che utilizzano le API MediaBrowser e MediaSession.

Il framework UI che supporta le app di terze parti che dipendono da MediaBrowser e MediaSession ha i seguenti requisiti visivi:

• DEVE mostrare le icone di MediaItem e le icone di notifica invariate.
• DEVE mostrare gli elementi descritti da MediaSession, ad esempio metadati, icone e immagini.
• DEVE mostrare il titolo dell'app.
• DEVE avere un riquadro per presentare la gerarchia di MediaBrowser.

4. Compatibilità con il pacchettizzazione delle applicazioni

Le implementazioni dei dispositivi DEVONO installare ed eseguire i file ".apk" Android generati dallo strumento "aapt" incluso nell'SDK Android ufficiale . Per questo motivo, le implementazioni dei dispositivi DEVONO utilizzare il sistema di gestione dei pacchetti dell'implementazione di riferimento.

Il gestore pacchetti DEVE supportare la verifica dei file ".apk" utilizzando lo schema di firma dell'APK v2 e la firma JAR .

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

Le implementazioni dei dispositivi NON DEVONO consentire ad app diverse dall'attuale "installatore registrato" del pacchetto di disinstallare l'app in modo silenzioso senza alcuna richiesta, come documentato nell'SDK per l'autorizzazione DELETE_PACKAGE. Le uniche eccezioni sono l'app di verifica del pacchetto di sistema che gestisce l'intent PACKAGE_NEEDS_VERIFICATION e l'app di gestione dello spazio di archiviazione che gestisce l'intent ACTION_MANAGE_STORAGE.

5. Compatibilità multimediale

5.1. Codec multimediali

Implementazioni dei dispositivi:

• DEVE supportare i formati multimediali di base specificati nella documentazione dell'SDK Android, tranne dove esplicitamente consentito in questo documento.

• DEVE supportare i formati multimediali, gli encoder, i decodificatori, i tipi di file e i formati contenitore definiti nelle tabelle riportate di seguito e segnalati tramite MediaCodecList .

• DEVE anche essere in grado di decodificare tutti i profili registrati in CamcorderProfile

• DEVE essere in grado di decodificare tutti i formati che può codificare. Sono inclusi tutti i bitstream generati dai suoi codificatori.

I codec DEVONO mirare a una latenza minima, in altre parole, i codec:

• NON DEVE consumare e memorizzare i buffer di input e restituire i buffer di input solo dopo l'elaborazione
• NON DEVE conservare i buffer decodificati per più tempo di quanto specificato dallo standard (ad es. SPS).
• NON DEVE conservare i buffer codificati più a lungo di quanto richiesto dalla struttura GOP.

Tutti i codec elencati nella tabella seguente sono forniti come implementazioni software nell'implementazione Android preferita del progetto open source Android.

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)	OBBLIGATORI 1	OBBLIGATORIO	Supporto per contenuti mono/stereo/5.0/5.1 2 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+)	OBBLIGATORI 1 (Android 4.1 e versioni successive)	OBBLIGATORIO	Supporto per contenuti mono/stereo/5.0/5.1 2 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.1 2 con frequenze di campionamento standard da 16 a 48 kHz.
AAC ELD (AAC a bassa latenza migliorata)	OBBLIGATORI 1 (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	OBBLIGATORI 3	OBBLIGATORI 3	Da 4,75 a 12,2 Kbps campionati a 8 kHz	3GPP (.3gp)
AMR-WB	OBBLIGATORI 3	OBBLIGATORI 3	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 è CONSIGLIATO sui dispositivi con uscita a 44,1 kHz, poiché il downsampler da 48 a 44,1 kHz non include un filtro passa basso). CONSIGLIATO 16 bit; nessun dither applicato per 24 bit.	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 delle sveglie 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	OBBLIGATORI 4 (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), Ogg(.ogg)

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

2 La registrazione o la riproduzione PUÒ essere eseguita in mono o stereo, ma la decodifica dei buffer di input AAC degli stream multicanale (ovvero più di due canali) in PCM tramite il decodificatore audio AAC predefinito nell'API android.media.MediaCodec, il seguente DEVE essere supportato:

• la decodifica viene eseguita senza downmixing (ad es. uno stream AAC 5.0 deve essere decodificato in cinque canali PCM, uno stream AAC 5.1 deve essere decodificato in sei canali PCM),
• i metadati relativi all'intervallo dinamico, come definito in "Controllo dell'intervallo dinamico (DRC)" in ISO/IEC 14496-3, e le chiavi DRC di android.media.MediaFormat per configurare i comportamenti relativi all'intervallo dinamico del decodificatore audio. Le chiavi AAC DRC sono state introdotte nell'API 21 e sono: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_ENCODED_TARGET_LEVEL

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)
Raw - Una cruda verità		OBBLIGATORIO		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.3. Codec video

• I codec che pubblicizzano il supporto del profilo HDR DEVONO supportare l'analisi e la gestione dei metadati statici HDR.

• Se un codec multimediale pubblicizza il supporto dell'aggiornamento intra, DEVE supportare i periodi di aggiornamento nell'intervallo di 10-60 fotogrammi e funzionare con precisione entro il 20% del periodo di aggiornamento configurato.

• I codec video DEVONO supportare dimensioni dei buffer di byte di output e di input che supportino il frame compresso e non compresso più grande possibile, come stabilito dallo standard e dalla configurazione, ma che non prevedano un'allocazione eccessiva.

• I codificatori e i decodificatori video DEVONO supportare il formato di colore flessibile YUV420 (COLOR_FormatYUV420Flexible).

Formato/codec	Codificatore	Decoder	Dettagli	Tipi di file supportati/ Formati contenitore
H.263	MAG	MAG		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	OBBLIGATORI 2	OBBLIGATORI 2	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		OBBLIGATORI 5	Per informazioni dettagliate, consulta la sezione 5.3	MPEG-4 (.mp4)
MPEG-2		FORTEMENTE CONSIGLIATO 6	Profilo principale	MPEG2-TS
MPEG-4 SP		OBBLIGATORI 2		3GPP (.3gp)
VP8 3	OBBLIGATORI 2 (Android 4.3 e versioni successive)	OBBLIGATORI 2 (Android 2.3.3 e versioni successive)	Per maggiori dettagli, consulta le sezioni 5.2 e 5.3	WebM (.webm) Matroska (.mkv, Android 4.0 e versioni successive) 4
VP9		OBBLIGATORI 2 (Android 4.4 e versioni successive)	Per informazioni dettagliate, consulta la sezione 5.3	WebM (.webm) Matroska (.mkv, Android 4.0 e versioni successive) 4

1 Obbligatorio per le implementazioni del dispositivo 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 .

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

Codificatori video H.264, VP8, VP9 e HEVC:

• DEVE supportare bitrate configurabili dinamicamente.
• DEVE supportare frequenze fotogrammi variabili, in cui il codificatore video DEVE determinare la durata istantanea dei fotogrammi in base ai timestamp dei buffer di input e allocare il bucket di bit in base a questa durata.

Il codificatore video H.263 e MPEG-4 DEVE supportare velocità in bit configurabili dinamicamente.

Tutti gli encoder video DEVONO soddisfare i seguenti target di velocità in bit in due finestre scorrevoli:

• NON deve superare il 15% circa della velocità in bit tra gli intervalli intraframe (I-frame).
• NON deve superare il 100% circa della velocità in bit in un intervallo mobile di 1 secondo.

5.2.1. H.263

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

5.2.2. H-264

Implementazioni di dispositivi Android con supporto del codec H.264:

• DEVE supportare il profilo di riferimento di livello 3.
  Tuttavia, il supporto di ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) e RS (Redundant Slices) è FACOLTATIVO. Inoltre, per mantenere la compatibilità con altri dispositivi Android, è CONSIGLIATO che gli encoder non utilizzino ASO, FMO e RS per il profilo di riferimento.
• DEVE supportare i profili di codifica video SD (definizione standard) riportati nella tabella seguente.
• DEVE supportare il profilo principale di livello 4.
• DEVE supportare i profili di codifica video HD (alta definizione) come indicato nella tabella seguente.
• Inoltre, per i dispositivi Android TV è MOLTO CONSIGLIATO codificare video HD 1080p a 30 fps.

	SD (bassa qualità)	SD (alta qualità)	HD 720p 1	HD 1080p 1
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.

5.2.3. VP8

Le implementazioni dei 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 720p 1	HD 1080p 1
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

Implementazioni dei dispositivi:

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

• Implementazioni che supportano il decodificatore Dolby Vision:

• DEVI fornire un'app di estrazione compatibile con Dolby Vision.

• DEVE mostrare correttamente i contenuti Dolby Vision sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

• Le implementazioni che forniscono un'estrazione compatibile con Dolby Vision DEVONO impostare l'indice traccia dei livelli di base compatibili con le versioni precedenti (se presenti) in modo che corrisponda a quello del livello Dolby Vision combinato.

5.3.1. MPEG-2

Le implementazioni dei dispositivi Android con decodificatori MPEG-2 devono supportare il profilo principale di alto livello.

5.3.2. H.263

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

5.3.3. MPEG-4

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

5.3.4. H.264

Implementazioni di dispositivi Android con decodificatori H.264:

• DEVE supportare il profilo principale di livello 3.1 e il profilo di baseline.
  Il supporto di ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) e RS (Redundant Slices) è FACOLTATIVO.
• DEVE essere in grado di decodificare i video con i profili SD (definizione standard) elencati nella tabella seguente e codificati con il profilo di base e il profilo principale di livello 3.1 (incluso 720p30).
• DEVE essere in grado di decodificare i video con i profili HD (alta definizione) come indicato nella tabella seguente.
• Inoltre, i dispositivi Android TV:
  • DEVE supportare il profilo High Profile 4.2 e il profilo di decodifica HD 1080p60.
  • DEVE essere in grado di decodificare i video con entrambi i profili HD indicati nella tabella seguente e codificati con il profilo Base, il profilo Principale o il profilo Alto di livello 4.2

	SD (bassa qualità)	SD (alta qualità)	HD 720p 1	HD 1080p 1
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 fps 2 )
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.

5.3.5. H.265 (HEVC)

Implementazioni di dispositivi Android, se supportano il codec H.265 come descritto nella sezione 5.1.3 :

• DEVE supportare il livello principale del profilo principale di livello 3 e i profili di decodifica video SD come indicato nella tabella seguente.
• DEVE supportare i profili di decodifica HD come indicato nella tabella seguente.
• DEVE supportare i profili di decodifica HD come indicato nella tabella seguente se è presente un decodificatore hardware.
• Inoltre, i dispositivi Android TV:
• DEVE supportare il profilo di decodifica HD 720p.
• È FORTEMENTE CONSIGLIATO supportare 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.
• DEVE supportare il profilo di decodifica UHD. Se il profilo di decodifica UHD è supportato, il codec DEVE supportare il profilo Main Tier Main10 di livello 5.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p	UHD
Risoluzione video	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 f/s (60 f/s 1)	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 OBBLIGATORI per le implementazioni dei dispositivi Android TV con decodifica hardware H.265.

5.3.6. VP8

Implementazioni dei dispositivi Android, se supportano il codec VP8 come descritto nella sezione 5.1.3 :

• DEVE supportare i profili di decodifica SD riportati nella tabella seguente.
• DEVE supportare i profili di decodifica HD riportati nella tabella seguente.
• I dispositivi Android TV DEVONO supportare il profilo di decodifica HD 1080p60.

	SD (bassa qualità)	SD (alta qualità)	HD 720p 1	HD 1080p 1
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 fps 2 )	30 (60 fps 2 )
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.

5.3.7. VP9

Implementazioni dei dispositivi Android, se supportano il codec VP9 come descritto nella sezione 5.1.3 :

• DEVE supportare i profili di decodifica video SD come indicato nella tabella seguente.
• DEVE supportare i profili di decodifica HD come indicato nella tabella seguente.
• DEVE supportare i profili di decodifica HD come indicato nella tabella seguente, se è presente un decodificatore hardware.

• Inoltre, i dispositivi Android TV:

  • DEVE supportare il profilo di decodifica HD 720p.
  • È FORTEMENTE CONSIGLIATO supportare il profilo di decodifica HD 1080p.
  • DEVE supportare il profilo di decodifica UHD. Se 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 720p	HD 1080p	UHD
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	30 f/s (60 f/s 1)	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 OBBLIGATORI per le implementazioni dei dispositivi Android TV con decodifica hardware VP9.

5.4. Registrazione audio

Sebbene alcuni dei requisiti descritti in questa sezione siano indicati come DOVREBBE fin da Android 4.3, è previsto che la definizione di compatibilità per una versione futura li modifichi in DEVE. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti indicati come DOVREBBERO, altrimenti non potranno raggiungere 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 l'acquisizione 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 ed eventuali operazioni di downsampling DEVONO 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

La sorgente audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION DEVE supportare l'acquisizione a una delle frequenze di campionamento 44100 e 48000.

Oltre alle specifiche di registrazione riportate sopra, quando un'applicazione ha iniziato a registrare uno stream audio utilizzando l'origine audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

• Il dispositivo DEVE presentare caratteristiche di ampiezza approssimativamente piatte rispetto alla frequenza: in particolare, ±3 dB, da 100 Hz a 4000 Hz.
• La sensibilità dell'ingresso audio DEVE essere impostata in modo che una sorgente con livello di potenza sonora (SPL) di 90 dB a 1000 Hz generi un valore 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 ingresso di 90 dB SPL al 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 riduttore del 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. Implementazioni del dispositivo che dichiarano la funzionalità android.hardware.audio.output:

• DEVE supportare le implementazioni di EFFECT_TYPE_EQUALIZER ed 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.
• DOVREBBE 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 principale di sistema e dell'attenuazione del volume dell'uscita audio digitale sulle uscite supportate, ad eccezione dell'uscita passthrough audio compresso (in cui non viene eseguita alcuna decodifica audio sul dispositivo).

Le implementazioni dei dispositivi Android Automotive DOVREBBERO consentire di regolare il volume audio separatamente per ogni stream audio utilizzando il tipo di contenuti o l'utilizzo come definito da AudioAttributes e l'utilizzo dell'audio dell'auto come definito pubblicamente in android.car.CarAudioManager .

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 viene presentato all'ambiente da un trasduttore on-device o il segnale esce dal dispositivo tramite una porta e può essere osservato esternamente.
• Latenza di output a freddo . La latenza di uscita per il primo frame, quando il sistema di uscita audio è 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 viene presentato dall'ambiente al dispositivo su un trasduttore on-device o il segnale entra nel dispositivo tramite una porta e il momento in cui un'applicazione legge il frame corrispondente dei dati codificati PCM.
• Input perso . La parte iniziale di un segnale di input inutilizzabile o non disponibile.
• 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 variabilità tra misurazioni separate dei valori di latenza di output a freddo.
• Jitter di input a freddo . La variabilità 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 periodo di buffer consente all'app di elaborare il segnale 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 .

È 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 la calibrazione 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, è FORTEMENTE CONSIGLIATO segnalare il supporto dell'audio a bassa latenza, segnalando la funzionalità android.hardware.audio.low_latency tramite la classe android.content.pm.PackageManager. Al contrario, se l'implementazione del dispositivo non soddisfa questi requisiti, NON DEVE segnalare il supporto dell'audio a bassa latenza.

Per le implementazioni dei dispositivi che includono android.hardware.microphone, è MOLTO CONSIGLIATO soddisfare i seguenti 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 di rete multimediale per la riproduzione di audio e video come specificato nella documentazione dell'SDK Android. In particolare, i dispositivi DEVONO supportare i seguenti protocolli di rete multimediale:

• Streaming progressivo HTTP(S)
  Tutti i codec e i formati contenitore obbligatori indicati nella sezione 5.1 DEVONO essere supportati tramite HTTP(S)

• Protocollo di bozza HTTP Live Streaming, versione 7
  Devono essere supportati i seguenti formati di segmenti multimediali:

Formati dei segmenti	Riferimenti	Supporto dei codec obbligatori
Stream di trasporto MPEG-2	ISO 13818	Codec video: H264 AVC MPEG-4 SP MPEG-2 Consulta la sezione 5.1.3 per informazioni dettagliate su H264 AVC, MPEG2-4 SP e MPEG-2. Codec audio: AAC Per informazioni dettagliate sull'AAC e sulle sue varianti, consulta la sezione 5.1.1.
AAC con framing ADTS e tag ID3	ISO 13818-7	Per informazioni dettagliate sull'AAC e sulle sue varianti, consulta la sezione 5.1.1.
WebVTT	WebVTT

• RTSP (RTP, SDP)

  È OBBLIGATORIO supportare il seguente profilo video audio RTP e i codec correlati. Per le eccezioni, consulta le note a piè di pagina della tabella nella sezione 5.1 .

Nome del profilo	Riferimenti	Supporto dei codec obbligatori
H264 AVC	RFC 6184	Per informazioni dettagliate su H264 AVC, consulta la sezione 5.1.3
MP4A-LATM	RFC 6416	Per informazioni dettagliate sull'AAC e sulle sue varianti, consulta la sezione 5.1.1.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Per informazioni dettagliate su H263, consulta la sezione 5.1.3
H263-2000	RFC 4629	Per informazioni dettagliate su H263, consulta la sezione 5.1.3
AMR	RFC 4867	Per informazioni dettagliate su AMR-NB, consulta la sezione 5.1.1
AMR-WB	RFC 4867	Per informazioni dettagliate su AMR-WB, consulta la sezione 5.1.1
MP4V-ES	RFC 6416	Per informazioni dettagliate su MPEG-4 SP, consulta la sezione 5.1.3.
mpeg4-generic	RFC 3640	Per informazioni dettagliate sull'AAC e sulle sue varianti, consulta la sezione 5.1.1.
MP2T	RFC 2250	Per maggiori dettagli, consulta Flusso di trasporto MPEG-2 in HTTP Live Streaming

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 crittograficamente sicuro come HDCP 2.x o versioni successive per i display wireless Miracast. Analogamente, se supportano un display esterno con cavo, le implementazioni del dispositivo 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 risoluzioni inferiori. L'implementazione open source di Android upstream include il supporto per i display wireless (Miracast) e con cavo (HDMI) che soddisfano questo requisito.

5.9. Musical Instrument Digital Interface (MIDI)

Se l'implementazione di un 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à non MIDI generica, è FORTEMENTE CONSIGLIATO segnalare il supporto della funzionalità android.software.midi tramite la classe android.content.pm.PackageManager.

I trasporti hardware compatibili con MIDI sono:

• Modalità host USB (sezione 7.7 USB)
• Modalità periferica USB (sezione 7.7 USB)
• MIDI over Bluetooth LE nel ruolo centrale (sezione 7.4.3 Bluetooth)

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.

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.

• L'implementazione del dispositivo DEVE segnalare il supporto della funzionalità android.hardware.audio.low_latency.
• La latenza audio nel tempo di round trip continuo, come definito nella sezione 5.6 Latenza audio, DEVE essere pari o inferiore a 20 millisecondi e DOVREBBE essere pari o inferiore 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 lungo il percorso del jack audio e DOVREBBE essere pari o inferiore a 10 millisecondi lungo il 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 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, è MOLTO CONSIGLIATO che l'implementazione del dispositivo sia conforme alla sezione Specifiche del dispositivo mobile (jack) della Specifica delle cuffie audio con cavo (v1.1).

Le latenze e i requisiti audio USB DEVONO essere soddisfatti utilizzando l'API coda del buffer PCM OpenSL ES.

Inoltre, un'implementazione del dispositivo che segnala il supporto di questa funzionalità DEVE:

• Fornire un livello sostenibile di prestazioni della CPU quando l'audio è attivo.
• Riduci al minimo l'inaccuratezza e lo scostamento dell'orologio audio rispetto all'ora standard.
• Riduci al minimo lo scostamento dell'orologio audio rispetto alla CPU CLOCK_MONOTONIC quando entrambe sono attive.
• Riduci al minimo la latenza audio tramite i trasduttori sul dispositivo.
• Riduci al minimo la latenza audio tramite l'audio digitale USB.
• Documenta le misurazioni della latenza audio su tutti i percorsi.
• Riduci al minimo il jitter nei tempi di inserimento del callback di completamento del buffer audio, in quanto influisce sulla percentuale utilizzabile della larghezza di banda completa della CPU dal callback.
• Non devono verificarsi sottocarichi (uscita) o sovraccarichi (ingresso) audio durante l'uso normale con la latenza registrata.
• Non devono esserci differenze di latenza tra i canali.
• Riduci al minimo la latenza media MIDI su tutti i trasporti.
• Riduci al minimo la variabilità della latenza MIDI sotto carico (jitter) su tutti i trasporti.
• Fornisci timestamp MIDI accurati su tutti i trasporti.
• Riduci al minimo il rumore del segnale audio sui trasduttori sul dispositivo, incluso il periodo immediatamente successivo all'avvio a freddo.
• Fornisci una differenza di clock audio pari a zero tra i lati di input e di output degli endpoint corrispondenti, quando entrambi sono attivi. Alcuni esempi di endpoint corrispondenti sono il microfono e lo speaker sul dispositivo oppure l'ingresso e l'uscita del jack audio.
• Gestisci i callback di completamento del buffer audio per i lati di input e output degli endpoint corrispondenti nello stesso thread quando entrambi sono attivi e inserisci il callback di output immediatamente dopo il ritorno dal callback di input. In alternativa, se non è possibile gestire i callback nello stesso thread, inserisci il callback di output poco dopo aver inserito il callback di input per consentire all'applicazione di avere una tempistica coerente dei lati di input e output.
• Riduci al minimo la differenza di fase tra il buffering audio HAL per i lati di input e di output degli endpoint corrispondenti.
• Riduci al minimo la latenza del tocco.
• Riduci al minimo la variabilità della latenza al tocco sotto carico (jitter).

5.11. Acquisisci per non elaborato

A partire da Android 7.0, è stata aggiunta una nuova sorgente di registrazione. È possibile accedervi utilizzando l'origine audio android.media.MediaRecorder.AudioSource.UNPROCESSED. In OpenSL ES, è possibile accedervi con il preset di registrazione SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

Un dispositivo DEVE soddisfare tutti i seguenti requisiti per segnalare il supporto della sorgente audio non elaborata tramite la proprietà android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED :

• Il dispositivo DEVE presentare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte nell'intervallo di frequenza medio: in particolare ±10 dB da 100 Hz a 7000 Hz.

• Il dispositivo DEVE mostrare livelli di ampiezza nell'intervallo di frequenza basso: in particolare da ±20 dB da 5 Hz a 100 Hz rispetto all'intervallo di frequenza medio.

• Il dispositivo DEVE mostrare livelli di ampiezza nell'intervallo di frequenza elevato: in particolare da ±30 dB da 7000 Hz a 22 KHz rispetto all'intervallo di frequenza medio.

• La sensibilità dell'ingresso audio DEVE essere impostata in modo che un'origine di toni sinusoidali di 1000 Hz riprodotta a un livello di pressione sonora (SPL) di 94 dB generi una risposta con RMS di 520 per campioni a 16 bit (o -36 dB Full Scale per campioni a virgola mobile/doppia precisione).

• SNR > 60 dB (differenza tra 94 dB SPL e SPL equivalente del rumore proprio, ponderato A).

• La distorsione armonica totale DEVE essere inferiore all'1% per 1 kHz a un livello di ingresso di 90 dB SPL al microfono.

• L'unica elaborazione del segnale consentita nel percorso è un moltiplicatore di livello per portare il livello all'intervallo desiderato. Questo moltiplicatore di livello NON DEVE introdurre ritardi o latenze nel percorso del segnale.

• Nel percorso non è consentita alcuna altra elaborazione del segnale, ad esempio controllo automatico del guadagno, filtro passa alto o cancellazione dell'eco. Se per qualsiasi motivo nell'architettura è presente un'elaborazione del segnale, questa DEVE essere disattivata e deve introdurre un ritardo zero o una latenza aggiuntiva nel percorso del segnale.

Tutte le misurazioni SPL vengono effettuate direttamente accanto al microfono in prova.

Per più configurazioni del microfono, questi requisiti si applicano a ogni microfono.

È FORTEMENTE CONSIGLIATO che un dispositivo soddisfi il maggior numero possibile di requisiti per il percorso del segnale per la sorgente di registrazione non elaborata. Tuttavia, un dispositivo deve soddisfare tutti questi requisiti, elencati sopra, se dichiara di supportare la sorgente audio non elaborata.

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)
  • Le implementazioni dei dispositivi DEVONO supportare tutte le funzioni adb come documentato nell'SDK Android, inclusa dumpsys .
  • 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 Android Debug Bridge 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)
  • 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.
• Le implementazioni dei dispositivi Monkey DEVONO includere il framework Monkey e renderlo disponibile per l'utilizzo da parte delle applicazioni.
• SysTrace
  • 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 delle impostazioni relative allo sviluppo delle applicazioni. Le implementazioni del dispositivo DEVONO rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo delle applicazioni. 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 (7) volte il 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 che sia 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 comunque 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 build.

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 diverse configurazioni hardware . 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'area lineare orizzontale o verticale di 2,54 cm. 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 quelli della dimensione più corta dello schermo. Ad esempio, un display di 480 x 854 pixel corrisponde a 854/480 = 1,779, ovvero circa "16:9".
• pixel indipendenti dalla densità (dp) . L'unità di pixel virtuale normalizzata a uno schermo da 160 dpi, calcolata come: 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 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 logiche in pixel indipendenti dalla densità (dp).

• 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 dimensioni dello schermo "normali" 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:

• I dispositivi Android Watch DEVONO avere uno schermo con dimensioni diagonali fisiche comprese tra 28 e 64 mm.
• I dispositivi Android Automotive DEVONO avere uno schermo con una diagonale fisica maggiore o uguale a 15 cm.
• I dispositivi Android Automotive DEVONO avere uno schermo di almeno 750 dp x 480 dp.
• 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

Sebbene non sia prevista alcuna limitazione per il valore delle proporzioni dello schermo del display fisico, le proporzioni dello schermo della superficie su cui vengono visualizzate le app di terze parti e che possono essere ricavate dai valori registrati tramite DisplayMetrics DEVONO soddisfare i seguenti requisiti:

• Se uiMode è configurato come UI_MODE_TYPE_WATCH, il valore del formato può essere impostato su 1,0 (1:1).
• Se l'app di terze parti indica che è ridimensionabile tramite l'attributo android:resizeableActivity, non ci sono limitazioni al valore del formato.
• Per tutti gli altri casi, le proporzioni DEVONO essere comprese tra 1,3333 (4:3) e 1,86 (circa 16:9), a meno che l'app non indichi esplicitamente di supportare proporzioni dello schermo più elevate tramite il valore dei metadati maxAspectRatio.

7.1.1.3. Densità schermo

Il framework dell'interfaccia utente di Android definisce un insieme di densità logiche standard per aiutare gli sviluppatori di applicazioni a scegliere come target le risorse dell'applicazione. Per impostazione predefinita, le implementazioni dei dispositivi DEVONO segnalare solo una delle seguenti densità del framework Android logiche tramite l'API DENSITY_DEVICE_STABLE e questo valore NON DEVE cambiare in nessun momento; tuttavia, il dispositivo PUÒ segnalare una densità arbitraria diversa in base alle modifiche alla configurazione del display apportate dall'utente (ad esempio le dimensioni del display) impostate dopo l'avvio iniziale.

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

Le implementazioni del dispositivo DEVONO definire la densità del framework Android standard più vicina numericamente alla densità fisica dello schermo, a meno che questa 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 segnalare la densità del framework Android standard successiva più bassa.

Per le implementazioni dei dispositivi, è MOLTO CONSIGLIATO fornire agli utenti un'impostazione per modificare le dimensioni del display. Se è presente un'implementazione per modificare le dimensioni del display del dispositivo, DEVE essere in linea con l'implementazione AOSP come indicato di seguito:

• Le dimensioni del display NON DEVONO essere scalate più di 1,5 volte la densità nativa o produrre una dimensione dello schermo minima effettiva inferiore a 320 dp (equivalente al qualificatore della risorsa sw320dp), a seconda del caso.
• Le dimensioni del display NON DEVONO essere scalate a un valore inferiore a 0,85 volte la densità nativa.
• Per garantire una buona usabilità e dimensioni dei caratteri coerenti, è CONSIGLIATO fornire la seguente scalabilità delle opzioni di visualizzazione nativa (nel rispetto dei limiti specificati sopra):
• Piccola: 0,85x
• Valore predefinito: 1x (scala di visualizzazione nativa)
• Grande: 1,15x
• Più grande: 1,3 volte
• Più grande 1,45x

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 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 segnalare 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 verticale che in orizzontale. In altre parole, il dispositivo deve rispettare la richiesta dell'applicazione di un orientamento dello schermo specifico. Le implementazioni dei dispositivi POSSONO selezionare l'orientamento verticale o orizzontale come predefinito.

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

I dispositivi NON DEVONO modificare le dimensioni o la densità dello schermo registrate quando cambiano l'orientamento.

7.1.4. Accelerazione grafica 2D e 3D

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

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

• Le API gestite (ad esempio tramite il metodo GLES10.getString()) DEVONO segnalare il supporto di 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 di OpenGL ES 1.0 e OpenGL ES 2.0.
• Le implementazioni dei dispositivi che dichiarano il supporto di OpenGL ES 3.0, 3.1 o 3.2 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, 3.1 o 3.2, libGLESv2.so DEVE esportare i simboli di funzione corrispondenti oltre ai simboli di funzione OpenGL ES 2.0.

Android fornisce un pacchetto di estensioni OpenGL ES con interfacce Java e supporto nativo per funzionalità grafiche avanzate come la tessellation e il formato di compressione delle texture ASTC. Le implementazioni dei dispositivi Android DEVONO supportare il pacchetto di estensioni se il dispositivo supporta OpenGL ES 3.2 e POTREBBE supportarlo in caso contrario. Se il pacchetto di estensioni è supportato nella sua interezza, il dispositivo DEVE 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 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 in genere specifici del fornitore. Android non richiede alle implementazioni dei dispositivi di implementare un formato di compressione delle texture specifico. Tuttavia, DEVONO 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 di chiamate API dirette.

Le implementazioni dei dispositivi DEVONO attivare l'accelerazione hardware per impostazione predefinita e DEVONO disattivarla se lo richiede lo sviluppatore 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 .

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 del dispositivo DEVONO supportare l'estensione EGL_ANDROID_RECORDABLE.

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 precedenti all'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 precedenti, come implementata dal codice open source Android upstream. In altre parole, le implementazioni dei dispositivi NON DEVONO modificare gli attivatori o le soglie a cui viene attivata la modalità di compatibilità e NON DEVONO modificare il comportamento della modalità di compatibilità stessa.

7.1.6. 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 DOVREBBERO supportare display in grado di eseguire il rendering di grafica a colori a 24 bit.
• I dispositivi DEVONO supportare display in grado di eseguire il rendering 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 incorporato, l'implementazione del dispositivo DEVE implementare l'API Display Manager come descritto nella documentazione dell'SDK Android.

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 virtuale (indipendentemente dal fatto che sia presente una tastiera fisica), ad eccezione dei dispositivi Android Watch in cui le dimensioni dello schermo rendono meno ragionevole avere una tastiera virtuale.
• 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 (QWERTY o 12 tasti).

7.2.2. Navigazione non tocco

Implementazioni dei dispositivi:

• PUO' 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 .
• 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 all'uso 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 e 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 dei dispositivi Android Watch e nessun altro tipo di dispositivo Android POSSONO utilizzare l'evento di pressione prolungata sull'evento chiave KEYCODE_BACK e omettere l'invio all'applicazione in primo piano.
• Le implementazioni di Android Automotive DEVONO fornire la funzione Home e POTREBBE 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. Quando sono visibili, tutte queste funzioni DEVONO essere accessibili con una singola azione (ad es. tocco, doppio clic o gesto).

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 tasti 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 7.1 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 del dispositivo lanciata prima di Android 4.4, ma con upgrade ad Android 7.1, questa opzione è 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 di overflow 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 visualizzata, a meno che non sia nascosta insieme ad altre funzioni di navigazione.

Le implementazioni dei dispositivi Android che supportano l'azione di assistenza e/o VoiceInteractionService DEVONO essere in grado di avviare un'app di assistenza con una singola interazione (ad es. tocco, doppio clic o gesto) quando sono visibili altri tasti di navigazione. È FORTEMENTE CONSIGLIATO utilizzare la pressione prolungata del tasto Home come interazione. L'interazione designata DEVE avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa un VoiceInteractionService o un'attività che gestisce l'intent ACTION_ASSIST.

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 in altro modo con la parte dello schermo disponibile per le applicazioni.
• Le implementazioni dei dispositivi DEVONO rendere disponibile una parte del display alle 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 dei dispositivi DEVONO presentare i tasti di navigazione in una modalità "a 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 corrispondente al tipo di touchscreen specifico sul dispositivo.

Android include il supporto di una serie di touchscreen, touchpad e dispositivi di input touch falsi. Le implementazioni dei dispositivi basati su touchscreen sono associate a un display 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 telecomando che gestisce un cursore sullo schermo si avvicina al tocco, ma richiede all'utente di prima puntare o mettere a fuoco 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 touch (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 (monotocco 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 sullo schermo X e Y assolute della posizione del cursore e mostrare un cursore visivo sullo schermo.
• DEVE segnalare l'evento tocco con il codice di azione che specifica la modifica dello stato che si verifica quando il cursore si sposta verso il basso o verso l'alto sullo schermo .
• DEVE supportare il movimento del cursore verso il basso e verso l'alto su un oggetto sullo schermo, il che consente agli utenti di emulare 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 il cursore verso l'alto nello stesso punto su un oggetto sullo schermo entro una soglia di tempo, che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo.
• DEVE supportare il cursore verso il basso in un punto arbitrario dello schermo, il cursore si sposta in un 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 il cursore verso l'alto sullo schermo, in modo da consentire 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 videogiochi 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 HID 2	Pulsante Android
A 1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B 1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X 1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y 1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad su 1 D-pad giù 1	0x01 0x0039 3	AXIS_HAT_Y 4
D-pad sinistra 1 D-pad destra 1	0x01 0x0039 3	AXIS_HAT_X 4
Pulsante del braccio sinistro 1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Pulsante del tasto funzione destro 1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic con la leva sinistra 1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic con il tasto R3 1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Casa 1	0x0c 0x0223	KEYCODE_HOME (3)
Indietro 1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

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 dall'asse verticale; ad esempio, un valore logico pari a 0 indica che non è presente alcuna rotazione e che è stato premuto il tasto Su, mentre un valore logico pari a 1 indica una rotazione di 45 gradi e che sono stati premuti sia il tasto Su sia il tasto Sinistra.

4 MotionEvent

Controlli analogici 1	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 MotionEvent

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 tasti Indietro, Home e Seleziona e supportare gli eventi del D-pad .

7.3. Sensori

Android include API per accedere a diversi tipi di sensori. In genere, le implementazioni dei dispositivi POSSONO omettere questi sensori, come previsto nelle sottosezioni seguenti. 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 . 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.
• 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).
• DEVI segnalare tutte le misurazioni del sensore utilizzando i valori pertinenti del Sistema internazionale di unità di misura (metrico) per ogni tipo di sensore, come definito nella documentazione dell'SDK Android.
• DOVREBBE registrare l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta l'ora in cui si è verificato l'evento e sincronizzata con l'orologio SystemClock.elapsedRealtimeNano(). È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma, dove questo potrebbe diventare un componente OBBLIGATORIO. L'errore di sincronizzazione DEVE essere inferiore a 100 millisecondi.
• 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 l'elaborazione dell'applicazione è attiva. 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 della documentazione Android Open Source sui sensori deve essere considerato autorevole.

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 descritti nella sezione Tipi di sensori . Se un'implementazione del dispositivo include un sensore composito, DEVE implementare il sensore come descritto nella documentazione Android Open Source sui sensori compositi .

Alcuni sensori Android supportano una modalità di attivazione "continua" , che restituisce dati continuamente. Affinché qualsiasi API indicata dalla documentazione dell'SDK Android sia un sensore continuo, le implementazioni dei dispositivi DEVONO fornire continuamente campioni di dati periodici che DEVONO avere un jitter inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori timestamp registrati tra 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, nelle implementazioni di Android Automotive e negli smartwatch Android. Se l'implementazione di un dispositivo include un accelerometro a 3 assi:

• DEBBERO implementare e segnalare il sensore TYPE_ACCELEROMETER .
• 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. Le implementazioni di Android Automotive DEVONO essere conformi al sistema di coordinate dei sensori dell'auto di Android .
• DEVE essere in grado di misurare da caduta libera fino a quattro volte la gravità (4 g) o più su qualsiasi asse.
• DEVE avere una risoluzione di almeno 12 bit e DOVREBBE avere una risoluzione 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.
• DOVREBBE implementare i sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento dell'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 energetico DEVE essere sempre inferiore a 4 mW e 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 è MOLTO 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 DOVREBBE implementare anche il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED. Per i dispositivi Android esistenti e nuovi è FORTEMENTE CONSIGLIATO implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• DEVE essere in grado di registrare eventi fino a una frequenza di almeno 10 Hz e DOVREBBE registrare eventi fino ad almeno 50 Hz.
• DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nelle API Android.
• DEVE essere in grado di misurare tra -900 µT e +900 µT su ogni asse prima della saturazione.
• 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 DOVREBBE avere una risoluzione uguale o superiore a 0,2 µT.
• 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 per 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 giroscopico.
• 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/GNSS. Se l'implementazione di un dispositivo include un ricevitore GPS/GNSS e segnala la funzionalità alle applicazioni tramite il flag della funzionalità android.hardware.location.gps:

• È FORTEMENTE CONSIGLIATO che il dispositivo continui a fornire normali output GPS/GNSS alle applicazioni durante una chiamata di emergenza e che l'output della posizione non venga bloccato durante una chiamata di emergenza.
• DEVE supportare le uscite di posizione a una frequenza di almeno 1 Hz quando richieste tramite LocationManager#requestLocationUpdate .
• DEVE essere in grado di determinare la posizione in condizioni di cielo aperto (segnali forti, multipath trascurabile, HDOP < 2) entro 10 secondi (tempo di prima correzione rapido), quando è connesso a una connessione a internet con velocità di trasferimento dati di almeno 0,5 Mbps. Questo requisito viene generalmente soddisfatto mediante l'utilizzo di una qualche forma di tecnica GPS/GNSS assistita o prevista per ridurre al minimo il tempo di accoppiamento GPS/GNSS (i dati di assistenza includono ora di riferimento, posizione di riferimento ed effemeride/orologio satellitare).
  • Dopo aver effettuato questo calcolo della posizione, è FORTEMENTE CONSIGLIATO che il dispositivo sia in grado di determinare la propria posizione, a cielo aperto, entro 10 secondi, quando le richieste di accesso alla posizione vengono riavviate, fino a un'ora dopo il calcolo iniziale della posizione, anche quando la richiesta successiva viene effettuata senza una connessione dati e/o dopo un ciclo di alimentazione.
• In condizioni di cielo aperto dopo aver determinato la posizione, a veicolo fermo o in movimento con un'accelerazione inferiore a 1 metro al secondo quadrato:
  • DEVE essere in grado di determinare la posizione entro 20 metri e la velocità entro 0, 5 metri al secondo, almeno il 95% delle volte.
  • DEVE monitorare e segnalare contemporaneamente tramite GnssStatus.Callback almeno 8 satelliti di una costellazione.
  • DOVREBBE essere in grado di rilevare contemporaneamente almeno 24 satelliti, di più costellazioni (ad es. GPS + almeno uno di Glonass, Beidou, Galileo).
• DEVE segnalare la generazione della tecnologia GNSS tramite l'API di test "getGnssYearOfHardware".
• È MOLTO CONSIGLIATO soddisfare e DEVE soddisfare tutti i requisiti riportati di seguito se la generazione della tecnologia GNSS è segnalata come "2016" o successiva.
  • DEVE segnalare le misurazioni GPS non appena vengono rilevate, anche se una posizione calcolata dal GPS/GNSS non è ancora stata segnalata.
  • DEVE segnalare pseudorange e rate di pseudorange GPS che, in condizioni di cielo aperto dopo aver determinato la posizione, mentre è fermo o si muove con un'accelerazione inferiore a 0, 2 metri al secondo quadrato, sono sufficienti per calcolare la posizione entro 20 metri e la velocità entro 0, 2 metri al secondo, almeno il 95% delle volte.

Tieni presente che, sebbene alcuni dei requisiti GPS sopra indicati siano indicati come FORTEMENTE CONSIGLIATI, la definizione di compatibilità per la prossima versione principale dovrebbe modificarli in REQUISITO.

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 DOVREBBE implementare anche 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 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 vincolata 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 è MOLTO 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 che possono effettuare una chiamata vocale e indicare un valore diverso da PHONE_TYPE_NONE in getPhoneType DEVONO includere un sensore di prossimità. Se l'implementazione di un dispositivo include un sensore di prossimità:

• 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 flag della funzionalità android.hardware.sensor.hifi_sensors.

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 400 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 il raggruppamento non superiore a 3 mW.
  • DEVE avere una stabilità del bias del rumore stazionario inferiore a 15 μg √Hz dal set di dati statico di 24 ore.
  • DOVREBBE avere una variazione di bias rispetto alla temperatura di ≤ +/- 1 mg / °C.
  • DEVE avere una non linearità della linea di adattamento ottimale pari o inferiore allo 0,5% e una variazione di sensibilità rispetto alla temperatura pari o inferiore allo 0,03%/°C.

• 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 400 Hz.
  • DEVE avere un rumore di misurazione non superiore a 0,014°/s/√Hz.
  • DEVE avere una stabilità del bias stazionario inferiore a 0,0002 °/s √Hz dal set di dati statico di 24 ore.
  • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 0,05 °/ s / °C.
  • DOVREBBE avere una variazione di sensibilità rispetto alla temperatura di ≤ 0,02% / °C.
  • DEVE avere una non linearità della linea di miglior adattamento pari o inferiore allo 0,2%.
  • DEVE avere una densità di rumore ≤ 0,007 °/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 superiore a 2 mW.
• SENSOR_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 energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è 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 energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
  • DEVE avere un consumo energetico per l'aggregazione non superiore a 4 mW.
• SENSOR_TYPE_STEP_COUNTER
  • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
• SENSOR_TILT_DETECTOR
  • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è 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 dall'accelerometro, dal sensore giroscopico e dal 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.
• I sensori ad alta fedeltà DEVONO inviare i campioni alle applicazioni entro 5 millisecondi dal momento in cui i dati sono disponibili sul sensore fisico.
• Il consumo di energia NON deve essere superiore a 0,5 mW quando il dispositivo è fermo e a 2,0 mW quando è in movimento quando è 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 energetico dell'Application Processor. Sono incluse le potenze assorbite dall'intera catena del sensore: il sensore, eventuali circuiti di supporto, qualsiasi sistema di elaborazione del sensore dedicato 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 ha 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.
• 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 dell'impronta 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 open source Android.
• 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, quando viene eseguito l'upgrade da una versione precedente ad Android 6.0, essere stata eseguita la migrazione sicura dei dati dell'impronta per soddisfare i requisiti sopra indicati o essere stati rimossi.
• DEBBA utilizzare l'icona Impronta Android fornita nell'Android Open Source Project.

7.3.11. Sensori solo per Android Automotive

I sensori specifici per i veicoli sono definiti nel file android.car.CarSensorManager API .

7.3.11.1. Marcia attuale

Le implementazioni di Android Automotive DOVREBBERO fornire la marcia attuale come SENSOR_TYPE_GEAR.

7.3.11.2. Modalità Giorno/Notte

Le implementazioni di Android Automotive DEVONO supportare la modalità giorno/notte definita come SENSOR_TYPE_NIGHT. Il valore di questo flag DEVE essere coerente con la modalità giorno/notte della dashboard e DOVREBBE essere basato sull'input del sensore di luce ambientale. Il sensore di luce ambientale sottostante POTREBBE essere lo stesso di Fotometro .

7.3.11.3. Stato di guida

Le implementazioni di Android Automotive DEVONO supportare lo stato di guida definito come SENSOR_TYPE_DRIVING_STATUS, con un valore predefinito di DRIVE_STATUS_UNRESTRICTED quando il veicolo è completamente fermo e parcheggiato. È responsabilità dei produttori di dispositivi configurare SENSOR_TYPE_DRIVING_STATUS in conformità con tutte le leggi e normative vigenti nei mercati in cui viene spedito il prodotto.

7.3.11.4. Velocità della ruota

Le implementazioni di Android Automotive DEVONO fornire la velocità del veicolo definita come SENSOR_TYPE_CAR_SPEED.

7.3.12. Sensore di posizione

Le implementazioni dei dispositivi POSSONO supportare il sensore di posizione con 6 gradi di libertà. È CONSIGLIATO utilizzare dispositivi Android con il supporto di questo sensore. Se un'implementazione del dispositivo supporta il sensore di posizione con 6 gradi di libertà:

• È NECESSARIO implementare e segnalare il sensore TYPE_POSE_6DOF.
• DEVE essere più preciso del solo vettore di rotazione.

7.4. Connettività dei dati

7.4.1. Telefonia

Per "Telefonia", come utilizzato dalle API Android e in questo documento, si intende in modo specifico l'hardware relativo all'invio di chiamate vocali e 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à dati che possa essere implementata utilizzando la stessa rete. In altre parole, le API e la funzionalità "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.1.1. Compatibilità con il blocco dei numeri

Le implementazioni dei dispositivi Android Telephony DEVONO includere il supporto per il blocco dei numeri e:

• DEVE implementare completamente BlockedNumberContract e l'API corrispondente come descritto nella documentazione dell'SDK.
• DEVE bloccare tutte le chiamate e i messaggi da un numero di telefono in "BlockedNumberProvider" senza alcuna interazione con le app. L'unica eccezione è quando il blocco dei numeri viene rimosso temporaneamente, come descritto nella documentazione dell'SDK.
• NON DEVE scrivere al fornitore del registro chiamate della piattaforma per una chiamata bloccata.
• NON DEVE scrivere al Fornitore di telefonia per un messaggio bloccato.
• DEVE implementare un'interfaccia utente per la gestione dei numeri bloccati, che viene aperta con l'intent restituito dal metodo TelecomManager.createManageBlockedNumbersIntent().
• NON DEVE consentire agli utenti secondari di visualizzare o modificare i numeri bloccati sul dispositivo, in quanto la piattaforma Android presuppone che l'utente principale abbia il controllo completo dei servizi di telefonia, una singola istanza, sul dispositivo. Tutta l'interfaccia utente relativa al blocco DEVE essere nascosta per gli utenti secondari e l'elenco bloccato DEVE essere rispettato.
• DOVREBBE eseguire la migrazione dei numeri bloccati nel fornitore quando un dispositivo viene aggiornato ad Android 7.0.

7.4.2. IEEE 802.11 (Wi-Fi)

Tutte le implementazioni dei dispositivi Android DEVONO 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.
• DEVE supportare il DNS multicast (mDNS) e NON DEVE filtrare i pacchetti mDNS (224.0.0.251) in qualsiasi momento di funzionamento, inclusi:
  • 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. 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 DEVONO includere il supporto di Wi-Fi Tunneled Direct Link Setup (TDLS) come descritto nella documentazione dell'SDK Android. Se l'implementazione di un dispositivo include il supporto di TDLS e TDLS è abilitato dall'API WiFiManager, il dispositivo:

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

7.4.3. Bluetooth

Le implementazioni dei dispositivi che supportano la funzionalità android.hardware.vr.high_performance DEVONO supportare Bluetooth 4.2 e l'estensione della lunghezza dei dati Bluetooth LE.

Android include il supporto per Bluetooth e Bluetooth Low Energy . 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 dei casi.

Le implementazioni di Android Automotive DOVREBBERO supportare il profilo Message Access (MAP). Le implementazioni di Android Automotive DEVONO supportare i seguenti profili Bluetooth:

• Chiamate tramite il profilo Hands-Free (HFP).
• Riproduzione di contenuti multimediali tramite il profilo Audio Distribution (A2DP).
• Controllo della riproduzione multimediale tramite il profilo di controllo remoto (AVRCP).
• Condivisione dei contatti tramite il profilo Phonebook Access (PBAP).

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 android.bluetooth .
• È 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 degli utenti.
• DOVREBBE supportare lo sgravamento della logica di filtro sul chipset Bluetooth durante l'implementazione dell'API ScanFilter 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 una query tramite il metodo android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported().
• DOVREBBE supportare più annunci con almeno 4 slot, ma se non è supportato, DEVE segnalare "false" ogni volta che viene eseguito un 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 le comunicazioni NFC (Near Field Communication). 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() .
• 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, in modo da poter eseguire l'upgrade alle release future della piattaforma.
    • NfcV (ISO 15693)
  • DOVREBBE essere in grado di leggere il codice a barre e l'URL (se codificato) dei prodotti Thinfilm NFC Barcode.
  • 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
    • SNEP 1.0 (definito dal NFC Forum)
  • DEVE includere il supporto di Android Beam .
  • 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 del messaggio NDEF in arrivo.
  • DEVE rispettare l'intent android.settings.NFCSHARING_SETTINGS per mostrare le impostazioni di condivisione NFC .
  • DEVE implementare il server NPP. I messaggi ricevuti dal server NPP DEVONO essere elaborati 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 è abilitato. Se non viene trovato alcun 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.
  • DEVE 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" e "Bluetooth Secure Simple Pairing Using NFC version 1.0" 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 richiesta/selezione del trasferimento tramite NFC e DEVE utilizzare il profilo Bluetooth Object Push 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 l'implementazione di un dispositivo include un chipset del controller NFC in grado di supportare HCE (per NfcA e/o NfcB) e supporta il routing dell'ID applicazione (AID), allora:

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

Se un'implementazione del dispositivo include un chipset del controller NFC in grado di supportare HCE per NfcF e implementa la funzionalità per applicazioni di terze parti, deve:

• DEVE segnalare la costante della funzionalità android.hardware.nfc.hcef.
• DEVE implementare le API di emulazione di carte NfcF come definite nell'SDK Android.

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(). 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() 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 uno standard di dati in grado di supportare velocità di almeno 200 Kbit/s. 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 (come Ethernet) è la connessione dati principale DEVONO includere anche il supporto di almeno uno standard di dati wireless comune, come 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 le socket AF_INET6. 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 dual-stack e solo IPv6 sul Wi-Fi.
• 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, il limite di velocità 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".

7.4.7. Risparmio dati

Per le implementazioni dei dispositivi con una connessione con misuratore è MOLTO CONSIGLIATO fornire la modalità Risparmio dati.

Se un'implementazione del dispositivo fornisce la modalità Risparmio dati:

• DEVE supportare tutte le API della classe ConnectivityManager come descritto nella documentazione dell'SDK

• DEVE fornire un'interfaccia utente nelle impostazioni, che consenta agli utenti di aggiungere o rimuovere applicazioni dalla lista consentita.

Al contrario, se l'implementazione di un dispositivo non prevede la modalità Risparmio dati:

• DEVE restituire il valore RESTRICT_BACKGROUND_STATUS_DISABLED per ConnectivityManager.getRestrictBackgroundStatus()

• NON deve trasmettere ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

• DEVE avere un'attività che gestisce l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ma PUÒ implementarlo come no-op.

7.5. Fotocamere

Le implementazioni dei dispositivi DOVREBBERO includere una fotocamera posteriore e POTREBBERO includere una fotocamera anteriore. Una fotocamera posteriore è una fotocamera posizionata sul lato del dispositivo opposto al display, ovvero acquisisce le immagini delle scene sul lato opposto del dispositivo, come una fotocamera tradizionale. Una fotocamera anteriore è una fotocamera situata 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, DEVE essere possibile per un'applicazione allocare contemporaneamente tre bitmap RGBA_8888 uguali alle dimensioni delle immagini prodotte dal sensore della fotocamera con la risoluzione più alta sul dispositivo, mentre la fotocamera è aperta per l'anteprima di base e l'acquisizione di foto.

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 spia del flash NON DEVE essere accesa mentre è stata registrata un'istanza 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 offre 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 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 posteriori come descritto nella sezione 7.5.1.
• DEVE riflettere orizzontalmente (ovvero rispecchiare) lo stream visualizzato da un'app in una 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(), l'anteprima della fotocamera DEVE essere ribaltata orizzontalmente rispetto all'orientamento specificato dall'applicazione.
  • In caso contrario, l'anteprima DEVE essere speculare lungo l'asse orizzontale predefinito del dispositivo.
• DEVE rispecchiare l'immagine visualizzata dalla visualizzazione post nello stesso modo dello stream di immagini dell'anteprima della fotocamera. Se l'implementazione del dispositivo non supporta il 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 POSSONO includere il supporto di una videocamera esterna che non è necessariamente sempre connessa. Se un dispositivo supporta una fotocamera esterna:

• DEVI dichiarare i flag funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any .
• POTREBBE supportare più videocamere.
• DEVE supportare la classe video USB (UVC 1.0 o versioni successive) se la videocamera esterna si connette tramite la porta USB.
• DOVREBBE supportare compressioni video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ad es. stream di immagini non compressi o compressi in modo indipendente).
• POTREBBE supportare la codifica video basata sulla fotocamera. Se supportato, un flusso non codificato / MJPEG simultaneo (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 senza copia 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, DEVE 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 alla videocamera, 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 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 per le fotocamere anteriori che per quelle posteriori. Il codificatore video hardware e la videocamera possono utilizzare qualsiasi formato di 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 del dispositivo DEVONO comunque implementare l'API Camera completa inclusa nella documentazione dell'SDK Android, indipendentemente dal fatto che il dispositivo includa l'autofocus hardware o altre funzionalità. Ad esempio, le videocamere prive di messa a fuoco automatica DEVONO comunque chiamare eventuali istanze di android.hardware.Camera.AutoFocusCallback registrate (anche se questo non ha alcuna rilevanza per una videocamera 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 sottostante 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 dei dispositivi DEVONO supportare tutti i parametri Camera standard, se l'hardware lo consente, e NON DEVONO supportare i tipi di parametri Camera 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.

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 e segnalare i flag delle funzionalità del framework appropriati .

Le implementazioni dei dispositivi DEVONO anche dichiarare le funzionalità delle singole videocamere di android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag delle funzionalità appropriati. Un dispositivo deve definire il flag della funzionalità se uno dei dispositivi videocamera collegati supporta la funzionalità.

Le implementazioni del dispositivo 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 la voce della foto è stata aggiunta 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 le immagini in orizzontale. Questo vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica ai dispositivi con orientamento principale orizzontale e verticale.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

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	512MB	816MB
xhdpi o superiore su schermi piccoli/normali hdpi o superiore su schermi di grandi dimensioni mdpi o superiore su schermi extra large	608MB	944MB
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 disponibile per il kernel e lo 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 4 GB e le altre implementazioni di dispositivi DEVONO avere almeno 3 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione. In altre parole, la partizione /data DEVE essere di almeno 4 GB per i dispositivi Android TV e di almeno 3 GB per le implementazioni di altri dispositivi. Per le implementazioni dei dispositivi che utilizzano Android è FORTEMENTE CONSIGLIATO disporre di almeno 4 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 Download Manager che le applicazioni POSSONO utilizzare per scaricare i file di dati. L'implementazione del gestore dei download sul dispositivo DEVE essere in grado di scaricare singoli file di dimensioni di almeno 100 MB nella posizione predefinita "cache".

7.6.2. Spazio di archiviazione condiviso dell'applicazione

Le implementazioni dei dispositivi DEVONO offrire spazio di archiviazione condiviso per le applicazioni, spesso indicato anche come "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 Linux /sdcard, 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, ad esempio uno slot per schede Secure Digital (SD). Se questo slot viene utilizzato per soddisfare il requisito di spazio di archiviazione condiviso, l'implementazione del dispositivo:

• DEVE implementare un'interfaccia utente popup o di notifica che avvisi l'utente quando non è presente una 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 dei dispositivi POSSONO allocare spazio di archiviazione interno (non rimovibile) come spazio di archiviazione condiviso per le app, come incluso nel progetto open source Android upstream; le implementazioni dei dispositivi DOVREBBERO utilizzare questa configurazione e implementazione del software. Se un'implementazione del dispositivo utilizza la memoria interna (non rimovibile) per soddisfare il requisito di spazio di archiviazione condiviso, anche se questa memoria PUÒ condividere spazio con i dati privati dell'applicazione, DEVE avere una dimensione di almeno 1 GB e essere montata su /sdcard (o /sdcard DEVE essere un link simbolico alla posizione fisica se è montata 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 l'autorizzazione.

Le implementazioni dei dispositivi che includono più percorsi di archiviazione condiviso (ad esempio uno slot per schede SD e uno spazio di archiviazione interno condiviso) DEVONO consentire solo alle applicazioni Android preinstallate e con privilegi con l'autorizzazione WRITE_EXTERNAL_STORAGE di scrivere nello spazio di archiviazione esterno secondario, tranne quando scrivono 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 dispone di una porta USB con supporto della modalità periferica USB, DEVE fornire un qualche meccanismo per accedere ai contenuti dello spazio di archiviazione condiviso da un computer host. Le implementazioni dei dispositivi POSSONO utilizzare l'archiviazione di massa USB, ma DEVONO utilizzare Media Transfer Protocol per soddisfare questo requisito. Se l'implementazione del dispositivo supporta il Media Transfer Protocol:

• DEVE essere compatibile con l'host MTP Android di riferimento, Android File Transfer .
• 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

Per le implementazioni dei dispositivi è MOLTO CONSIGLIATO implementare lo spazio di archiviazione adottabile 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.

Le implementazioni di dispositivi come una televisione POTREBBERO consentire l'adozione tramite porte USB, in quanto il dispositivo dovrebbe essere statico e non mobile. Tuttavia, per le altre implementazioni dei dispositivi che sono 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.

7.7.1. Modalità periferica 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 standard di tipo A o C.
• 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 per 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 Home), in modo che il display venga visualizzato correttamente quando il dispositivo è orientato con la porta in basso. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
• DEVE consentire a un host USB collegato al dispositivo Android di accedere ai contenuti del volume di archiviazione condiviso utilizzando l'archiviazione di massa USB o il protocollo Media Transfer Protocol.
• DEVE implementare l'API e la specifica Android Open Accessory (AOA) come descritto nella documentazione dell'SDK Android e, se si tratta di un dispositivo Android portatile, DEVE implementare l'API AOA. Implementazioni dei dispositivi che implementano la specifica AOA:
  • DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.accessory .
  • DEVE implementare la classe audio USB come descritto nella documentazione dell'SDK Android.
  • 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 traffico e il chirp HS come specificato nella specifica di ricarica della batteria USB, revisione 1.2. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
• I dispositivi Type-C DEVONO rilevare i caricabatterie da 1,5 A e 3 A in base allo standard del resistore Type-C e devono rilevare le modifiche nell'annuncio.
• È FORTEMENTE CONSIGLIATO che i dispositivi Type-C che supportano anche la modalità host USB supportino Power Delivery per lo scambio di ruoli di alimentazione e dati.
• I dispositivi Type-C DEVONO supportare Power Delivery per la ricarica ad alta tensione e le modalità alternative come l'uscita display.
• Il valore di iSerialNumber nel descrittore del dispositivo standard USB DEVE essere uguale al valore di android.os.Build.SERIAL.
• È FORTEMENTE CONSIGLIATO che i dispositivi Type-C non supportino metodi di ricarica proprietari che modificano la tensione Vbus oltre i livelli predefiniti o alterano i ruoli di sink/sorgente, in quanto potrebbero verificarsi problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard USB Power Delivery. Sebbene questa opzione sia indicata come "FORTEMENTE CONSIGLIATA", nelle versioni future di Android potremmo RICHIEDERE a tutti i dispositivi Type-C di supportare la piena interoperabilità con i caricabatterie Type-C standard.

7.7.2. Modalità host USB

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 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 che adattano 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.
• DEVE implementare l'API host USB Android come descritto nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host .
• 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 [USB Type-C Cable and Connector Specification Revision 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) per i connettori USB Type-C o utilizzare l'intervallo di corrente di uscita della porta di ricarica a valle(CDP) come specificato nelle specifiche per la ricarica della batteria USB, revisione 1.2 per i connettori Micro-AB.
• È FORTEMENTE CONSIGLIATO che i dispositivi USB Type-C supportino DisplayPort, DEBBANO supportare le velocità di trasferimento dati USB SuperSpeed ed è FORTEMENTE CONSIGLIATO che supportino Power Delivery per lo scambio di ruoli di alimentazione e dati.
• I dispositivi con porte di tipo A o AB NON DEVONO essere forniti con un adattatore che converte questa porta in un connettore di tipo C.
• DEVE riconoscere tutti i dispositivi MTP (Media Transfer Protocol) connessi da remoto e rendere accessibili i relativi contenuti tramite le intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT, se è supportato Storage Access Framework (SAF).
• DEVE, se si utilizza una porta USB Type-C e si include il supporto della modalità periferica, implementare la funzionalità della porta Dual Role come definita dalla specifica USB Type-C (sezione 4.5.1.3.3).
• DOVREBBE, se la funzionalità della porta con doppio ruolo è supportata, implementare il modello Try.* più appropriato per il fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DOVREBBE implementare il modello Try.SNK.

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.
• DEVE soddisfare i requisiti di registrazione audio descritti nella sezione 5.4 .
• DEVE soddisfare i requisiti di latenza audio descritti nella sezione 5.6 .
• È MOLTO 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.
• DEVE soddisfare i requisiti di riproduzione audio descritti nella sezione 5.5 .
• DEVE soddisfare i requisiti di latenza audio descritti nella sezione 5.6 .
• È MOLTO 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, mentre 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 jack audio da 3,5 mm nell'ecosistema Android, 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 un'implementazione del 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 dei pin CTIA e DOVREBBE supportare i connettori audio con l'ordine dei pin 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 del microfono impostato su 1.
• DEVE supportare il rilevamento e la mappatura ai codici a tasti per i seguenti tre intervalli di impedenza equivalente tra i conduttori del microfono e della terra sul connettore audio:
  • Massimo 70 ohm : KEYCODE_HEADSETHOOK
  • 210-290 Ohm : KEYCODE_VOLUME_UP
  • 360-680 Ohm : KEYCODE_VOLUME_DOWN
• È MOLTO CONSIGLIATO rilevare e mappare al codice a chiave il seguente intervallo di impedenza equivalente tra i conduttori del microfono e della messa a terra sul connettore audio:
  • 110-180 Ohm: KEYCODE_VOICE_ASSIST
• DEVE attivare ACTION_HEADSET_PLUG quando viene inserito il connettore, ma solo dopo che tutti i contatti del 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", le sorgenti audio VOICE_RECOGNITION e UNPROCESSED devono soddisfare i seguenti requisiti:
  • 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 non pesato del microfono in un intervallo di frequenza compreso tra 18,5 kHz e 20 kHz per un tono a 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.

7.9. Realtà virtuale

Android include API e funzionalità per creare applicazioni di "Realtà virtuale" (VR), incluse esperienze VR mobile di alta qualità. Le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

7.9.1. Modalità realtà virtuale

Le implementazioni di dispositivi Android portatili che supportano una modalità per le applicazioni VR che gestisce il rendering stereoscopico delle notifiche e disattiva i componenti dell'interfaccia utente di sistema monoculare quando un'applicazione VR ha l'attenzione dell'utente DEVONO dichiarare la funzionalità android.software.vr.mode. I dispositivi che dichiarano questa funzionalità DEVONO includere un'applicazione che implementa android.service.vr.VrListenerService che può essere attivata dalle applicazioni VR tramite android.app.Activity#setVrModeEnabled .

7.9.2. Realtà virtuale ad alte prestazioni

Le implementazioni dei dispositivi Android portatili DEVONO identificare il supporto della realtà virtuale ad alte prestazioni per periodi di utilizzo più lunghi tramite il flag della funzionalità android.hardware.vr.high_performance e soddisfare i seguenti requisiti.

• Le implementazioni dei dispositivi DEVONO avere almeno 2 core fisici.
• Le implementazioni dei dispositivi DEVONO dichiarare la funzionalità android.software.vr.mode.
• Le implementazioni dei dispositivi POSSONO fornire un core esclusivo all'applicazione in primo piano e POSSONO supportare l'API Process.getExclusiveCores per restituire i numeri dei core della CPU esclusivi dell'applicazione in primo piano principale. Se il nucleo esclusivo è supportato, il nucleo NON DEVE consentire l'esecuzione di altri processi nello spazio utente (tranne i driver di dispositivo utilizzati dall'applicazione), ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.
• Le implementazioni dei dispositivi DEVONO supportare la modalità di prestazioni sostenute.
• Le implementazioni dei dispositivi DEVONO supportare OpenGL ES 3.2.
• Le implementazioni dei dispositivi DEVONO supportare il livello hardware Vulkan 0 e DOVREBBERO supportare il livello hardware Vulkan 1.
• Le implementazioni dei dispositivi DEVONO implementare EGL_KHR_mutable_render_buffer ed EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync ed EGL_KHR_wait_sync in modo che possano essere utilizzati per la modalità Buffer condiviso ed esporre le estensioni nell'elenco delle estensioni EGL disponibili.
• La GPU e il display DEVONO essere in grado di sincronizzare l'accesso al buffer anteriore condiviso in modo che il rendering con l'occhio alternato dei contenuti VR a 60 fps con due contesti di rendering venga visualizzato senza artefatti di tearing visibili.
• Le implementazioni dei dispositivi DEVONO implementare EGL_IMG_context_priority ed esporre l'estensione nell'elenco delle estensioni EGL disponibili.
• Le implementazioni dei dispositivi DEVONO implementare GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 e GL_OVR_multiview_multisampled_render_to_texture ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
• Le implementazioni dei dispositivi DEVONO implementare EGL_EXT_protected_content e GL_EXT_protected_textures in modo che possano essere utilizzate per la Riproduzione video di texture protette ed esporre le estensioni nell'elenco delle estensioni EGL e GL disponibili.
• Le implementazioni dei dispositivi DEVONO supportare la decodifica H.264 di almeno 3840 x 2160 a 30 fps e 40 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps e 10 Mbps o 2 istanze di 1920 x 1080 a 60 fps e 20 Mbps).
• Le implementazioni dei dispositivi DEVONO supportare HEVC e VP9, DEVONO essere in grado di decodificare almeno 1920 x 1080 a 30 fps e 10 Mbps e DOVREBBERO essere in grado di decodificare 3840 x 2160 a 30 fps e 20 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps e 5 Mbps).
• È FORTEMENTE CONSIGLIATO che le implementazioni del dispositivo supportino la funzionalità android.hardware.sensor.hifi_sensors e DEVONO soddisfare i requisiti relativi a giroscopio, accelerometro e magnetometro per android.hardware.hifi_sensors.
• Le implementazioni dei dispositivi DEVONO supportare l'API HardwarePropertiesManager.getDeviceTemperatures e restituire valori accurati per la temperatura cutanea.
• L'implementazione del dispositivo DEVE avere uno schermo integrato e la sua risoluzione DEVE essere almeno FullHD(1080p) e MOLTO CONSIGLIATO che sia QuadHD (1440p) o superiore.
• Il display DEVE misurare tra 4,7" e 6" di diagonale.
• Il display DEVE aggiornarsi ad almeno 60 Hz in modalità VR.
• Il tempo di commutazione grigio-grigio, bianco-nero e nero-bianco DEVE essere inferiore o uguale a 3 ms.
• Il display DEVE supportare una modalità a bassa persistenza con una persistenza massima di 5 ms,dove persistenza viene definita come il periodo di tempo per cui un pixel emette luce.
• Le implementazioni dei dispositivi DEVONO supportare Bluetooth 4.2 e l'estensione della lunghezza dei dati Bluetooth LE sezione 7.4.3 .

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 quando sviluppano un'app. I dispositivi Android Watch DOVREBBERO e altri tipi di implementazioni 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 fotogrammi incoerente o un ritardo nel rendering dei fotogrammi NON DEVONO verificarsi più di 5 volte al secondo e DEVONO essere inferiori a 1 fotogramma 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 utilizzando 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 utilizzando un buffer di scrittura di 4 KB.
• Lettura sequenziale . Le implementazioni dei dispositivi DEVONO garantire prestazioni di lettura sequenziale di almeno 15 MB/s per un file di 256 MB utilizzando 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

Android 6.0 ha introdotto le modalità di risparmio energetico App Standby e Sospensione per ottimizzare l'utilizzo della batteria. Tutte le app esenti da queste modalità DEVONO essere rese visibili all'utente finale. Inoltre, gli algoritmi di attivazione, manutenzione e risveglio e l'utilizzo delle impostazioni di sistema globali di queste modalità di risparmio energetico NON DEVONO discostarsi dal progetto open source Android.

Oltre alle modalità di risparmio energetico, le implementazioni dei dispositivi Android POSSONO implementare uno o tutti e quattro gli stati di alimentazione in sospensione come definiti dall'Advanced Configuration and Power Interface (ACPI), ma se implementano gli stati di alimentazione S3 e S4, possono entrare in questi stati solo quando viene chiuso un coperchio che fa parte fisicamente del dispositivo.

8.4. Contabilità del consumo energetico

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

• DEVE essere in grado di monitorare il consumo di energia dei componenti hardware e attribuirlo ad applicazioni specifiche. Nello specifico, le implementazioni:
  • DEVE fornire un profilo di alimentazione per componente che definisce il valore di consumo 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.
  • 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 a riga di comando adb shell dumpsys batterystats per lo sviluppatore dell'app.
• DEVE rispettare l'intent android.intent.action.POWER_USAGE_SUMMARY e mostrare un menu delle impostazioni che mostri questo consumo di energia.

8.5. Prestazioni costanti

Le prestazioni possono variare notevolmente per le app ad alte prestazioni a lungo termine, a causa delle altre app in esecuzione in background o del throttling della CPU a causa dei limiti di temperatura. Android include interfacce programmatiche in modo che, se il dispositivo è compatibile, l'applicazione in primo piano più importante possa richiedere al sistema di ottimizzare l'allocazione delle risorse per gestire queste fluttuazioni.

Le implementazioni dei dispositivi DEVONO supportare la modalità di prestazioni sostenute, che può fornire all'applicazione in primo piano un livello di prestazioni costante per un periodo di tempo prolungato quando richiesto tramite il metodo dell'API Window.setSustainedPerformanceMode(). Un'implementazione del dispositivo DEVE segnalare con precisione il supporto della modalità di prestazioni sostenute tramite il metodo dell'API PowerManager.isSustainedPerformanceModeSupported().

Le implementazioni dei dispositivi con due o più core della CPU DEVONO fornire almeno un core esclusivo che può essere riservato dall'applicazione in primo piano principale. Se fornite, le implementazioni DEVONO soddisfare i seguenti requisiti:

• Le implementazioni DEVONO segnalare tramite il metodo API Process.getExclusiveCores() i numeri ID dei core esclusivi che possono essere riservati dall'applicazione in primo piano principale.
• Le implementazioni dei dispositivi NON DEVONO consentire l'esecuzione di processi nello spazio utente, ad eccezione dei driver di dispositivo utilizzati dall'applicazione, sui core esclusivi, ma POSSONO consentire l'esecuzione di alcuni processi del kernel, se necessario.

Se l'implementazione di un dispositivo non supporta un core esclusivo, DEVE restituire un elenco vuoto tramite il metodo dell'API Process.getExclusiveCores().

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 della documentazione per sviluppatori Android. Le implementazioni dei dispositivi DEVONO supportare l'installazione di applicazioni con firma autografa senza richiedere autorizzazioni/certificati aggiuntivi da parte di terze parti/autorità. In particolare, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle sottosezioni seguenti.

9.1. Autorizzazioni

Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android. Nello specifico, le implementazioni DEVONO applicare ogni autorizzazione definita come descritto nella documentazione dell'SDK; nessuna autorizzazione può essere omessa, alterata o ignorata. Le implementazioni POSSONO aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe ID autorizzazione non siano nello spazio dei nomi android.*.

Le autorizzazioni con un valore protectionLevel di 'PROTECTION_FLAG_PRIVILEGED' DEVONO essere concesse solo alle app precaricate nei percorsi privilegiati inclusi nella lista consentita dell'immagine di sistema, ad esempio il percorso system/priv-app nell'implementazione AOSP.

Le autorizzazioni con un livello di protezione pericoloso sono autorizzazioni di runtime. Le applicazioni con targetSdkVersion > 22 le 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 la gestione delle 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 separato. Le implementazioni dei dispositivi DEVONO supportare l'esecuzione di più applicazioni con lo stesso ID utente Linux, a condizione che le applicazioni siano firmate e create correttamente, come definito nella documentazione di riferimento su sicurezza e autorizzazioni .

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 .

9.4. Ambienti di esecuzione alternativi

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

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

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.
• Le applicazioni installate che utilizzano un runtime alternativo NON DEVONO riutilizzare la sandbox di qualsiasi altra app installata sul dispositivo, tranne tramite i meccanismi standard di Android per ID utente e certificato di firma condivisi.
• NON DEVE essere lanciato con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre applicazioni Android.
• NON DEVE essere lanciato con, essere concesso o concedere ad altre applicazioni 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 le 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, 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 di più utenti e l'isolamento completo degli utenti. Le implementazioni dei dispositivi POSSONO consentire più utenti, ma se abilitati DEVONO soddisfare i seguenti requisiti relativi al supporto multiutente :

• Le implementazioni di dispositivi Android Automotive con il supporto multiutente abilitato DEVONO includere un account ospite che consenta tutte le funzioni fornite dal sistema del veicolo senza che sia necessario che un utente acceda.
• 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 altri utenti possono lavorare, 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.
• Ogni istanza utente su un dispositivo Android DEVE avere directory di archiviazione esterna separate e isolate. Le implementazioni dei dispositivi POSSONO memorizzare 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 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 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 . Gli SMS premium sono messaggi inviati a un servizio registrato presso un operatore che potrebbero comportare un addebito per l'utente. Le implementazioni del dispositivo 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. L'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), il sandboxing seccomp e altre funzionalità di sicurezza nel kernel Linux. SELinux o qualsiasi altra funzionalità di sicurezza implementata sotto il 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 ha generato 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ò influire su 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 inoltre soddisfare 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 di un dispositivo/fornitore.
• NON DEVE modificare, omettere o sostituire le regole neverallow presenti nella cartella system/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 SELinux di AOSP sia per i domini specifici del dispositivo/del fornitore.
• DEBBA suddividere il framework multimediale in più processi in modo da poter concedere l'accesso in modo più specifico a ciascun processo, come descritto nel sito del progetto Android Open Source.

Le implementazioni dei dispositivi DOVREBBERO mantenere il criterio SELinux predefinito fornito nella cartella system/sepolicy del progetto open source Android upstream e aggiungere solo 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.

I dispositivi DEVONO implementare un meccanismo di sandboxing delle applicazioni del kernel che consenta di filtrare le chiamate di sistema utilizzando un criterio configurabile da programmi multithread. Il progetto Android Open Source upstream soddisfa questo requisito attivando seccomp-BPF con la sincronizzazione del gruppo di thread (TSYNC) come descritto nella sezione Configurazione del kernel di source.android.com .

9.8. Privacy

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

Se un'implementazione del dispositivo dispone di 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, a meno che la VPN non sia attivata dal Controllo criteri del dispositivo tramite DevicePolicyManager.setAlwaysOnVpnPackage() , nel qual caso l'utente non deve fornire un consenso separato, ma DEVE solo ricevere una notifica.

Le implementazioni dei dispositivi DEVONO essere fornite con un archivio delle autorità di certificazione (CA) aggiunto dall'utente vuoto e DEVONO preinstallare gli stessi certificati radice per l'archivio CA attendibile di sistema fornito nel progetto open source Android upstream.

Quando i dispositivi vengono instradati tramite una VPN o è installata una CA principale dell'utente, l'implementazione DEVE mostrare un avviso che indica all'utente che il traffico di rete potrebbe essere monitorato.

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 dell'archiviazione dei dati

Se l'implementazione del dispositivo supporta una schermata di blocco sicura come descritto nella sezione 9.11.1, il dispositivo DEVE supportare la crittografia dell'archiviazione dei dati dei dati privati dell'applicazione (partizione /data) e della partizione di archiviazione condivisa 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 dello spazio di archiviazione dei dati e con prestazioni di crittografia Advanced Encryption Standard (AES) superiori a 50 MiB/sec, la crittografia dello spazio di archiviazione dei dati DEVE essere attivata per impostazione predefinita al momento in cui l'utente ha completato l'esperienza di configurazione out-of-box. Se l'implementazione di un dispositivo è già stata lanciata su una versione precedente di Android con la crittografia disattivata per impostazione predefinita, questo dispositivo non può soddisfare il requisito tramite un aggiornamento del software di sistema e, pertanto, POTREBBE essere esente.

Le implementazioni dei dispositivi DEVONO soddisfare il requisito di crittografia dell'archiviazione dei dati riportato sopra tramite l'implementazione della crittografia basata su file (FBE).

9.9.1. Avvio diretto

Tutti i dispositivi DEVONO implementare le API della modalità di avvio diretto anche se non supportano la crittografia dello spazio di archiviazione. In particolare, gli intent LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED devono comunque essere trasmessi per segnalare alle applicazioni compatibili con il Boot diretto che le posizioni di archiviazione con crittografia del dispositivo (DE) e con crittografia delle credenziali (CE) sono disponibili per l'utente.

9.9.2. Crittografia basata su file

Implementazioni dei dispositivi che supportano FBE:

• DEVE avviarsi senza richiedere all'utente le credenziali e consentire alle app compatibili con il Boot diretto di accedere allo spazio di archiviazione criptato del dispositivo (DE) dopo l'invio del messaggio LOCKED_BOOT_COMPLETED.
• DEVE consentire l'accesso allo spazio di archiviazione con crittografia delle credenziali (CE) solo dopo che l'utente ha sbloccato il dispositivo fornendo le proprie credenziali (ad es. passcode, PIN, sequenza o impronta) e il messaggio ACTION_USER_UNLOCKED è stato trasmesso. Le implementazioni dei dispositivi NON DEVONO offrire alcun metodo per sbloccare lo spazio di archiviazione protetto CE senza le credenziali fornite dall'utente.
• DEVE supportare l'Avvio verificato e garantire che le chiavi DE siano legate in modo crittografico all'hardware root of trust del dispositivo.
• DEVE supportare la crittografia dei contenuti dei file utilizzando AES con una lunghezza della chiave di 256 bit in modalità XTS.
• DEVE supportare la crittografia del nome del file utilizzando AES con una lunghezza della chiave di 256 bit in modalità CBC-CTS.
• PUO' supportare algoritmi di crittografia, lunghezze e modalità alternative per la crittografia dei contenuti e dei nomi dei file, ma DEVE utilizzare per impostazione predefinita gli algoritmi di crittografia, le lunghezze e le modalità supportate obbligatoriamente.
• DOVREBBE rendere le app essenziali precaricate (ad es. Sveglia, Telefono, Messaggi) compatibili con il Boot diretto.

Le chiavi che proteggono le aree di archiviazione CE e DE:

• DEVE essere associata in modo crittografico a un Keystore basato su hardware. Le chiavi CE devono essere associate alle credenziali della schermata di blocco di un utente. Se l'utente non ha specificato credenziali per la schermata di blocco, le chiavi CE DEVONO essere associate a un passcode predefinito.
• DEVONO essere univoci e distinti, in altre parole nessuna chiave CE o DE di un utente può corrispondere a quella di un altro utente.

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

9.9.3. Crittografia completa del disco

Implementazioni di dispositivi che supportano la crittografia completa del disco (FDE). 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. All'utente DEVE essere fornita la possibilità di criptare la chiave di crittografia con AES, tranne quando è in uso attivo, con le credenziali della schermata di blocco allungate utilizzando un algoritmo di allungamento lento (ad es. PBKDF2 o scrypt). Se l'utente non ha specificato le credenziali della 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 sottoposta a wrapping 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à basata sulla funzionalità dm-crypt del kernel Linux.

9.10. Integrità del dispositivo

I seguenti requisiti garantiscono la trasparenza dello stato dell'integrità del dispositivo.

Le implementazioni dei dispositivi DEVONO segnalare correttamente tramite il metodo dell'API di sistema PersistentDataBlockManager.getFlashLockState() se lo stato del bootloader consente il flashing dell'immagine di sistema. Lo stato FLASH_LOCK_UNKNOWN è riservato alle implementazioni dei dispositivi che eseguono l'upgrade da una versione precedente di Android in cui non esisteva questo nuovo metodo dell'API di sistema.

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 attualmente consigliati dal NIST per gli algoritmi di hashing (SHA-256) e le dimensioni delle chiavi pubbliche (RSA-2048).
• NON DEVE consentire il completamento dell'avvio quando la verifica del sistema non va a buon fine, a meno che l'utente non accetti di tentare comunque l'avvio, nel qual caso i dati di eventuali blocchi di archiviazione non verificati NON DEVONO essere utilizzati.
• NON DEVE consentire la modifica delle partizioni verificate sul dispositivo, a meno che l'utente non abbia sbloccato esplicitamente il bootloader.

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 consente agli sviluppatori di app di archiviare le chiavi di crittografia in un contenitore e di utilizzarle nelle operazioni di crittografia tramite l'API KeyChain o l'API Keystore .

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 della schermata di blocco DEVE limitare la frequenza dei tentativi e DEVE avere un algoritmo di backoff esponenziale. Oltre 150 tentativi non riusciti, il ritardo DEVE essere di almeno 24 ore per tentativo.
• Quando l'implementazione del dispositivo supporta una schermata di blocco sicura, DEVE eseguire il backup dell'implementazione del keystore con hardware sicuro e soddisfare i seguenti requisiti:
  • DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni hash di famiglie MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e sopra. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA. Il progetto Android Open Source (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura sottoposta a revisione da parte di terze parti di un'isolamento basato su hypervisor adeguato sono opzioni alternative.
  • DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo se l'autenticazione va a buon fine, deve consentire l'utilizzo delle chiavi legate all'autenticazione. Il progetto Android Open Source upstream fornisce l'HAL (Hardware Abstraction Layer) Gatekeeper e Trusty, che possono essere utilizzati per soddisfare questo requisito.

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore basato su hardware, a meno che non dichiari la funzionalità android.hardware.fingerprint che richiede un keystore basato su hardware.

9.11.1. Schermata di blocco sicura

Le implementazioni dei dispositivi POSSONO aggiungere o modificare i metodi di autenticazione per sbloccare la schermata di blocco, ma DEVONO comunque soddisfare i seguenti requisiti:

• Il metodo di autenticazione, se basato su un segreto noto, NON DEVE essere considerato una schermata di blocco sicura, a meno che non soddisfi tutti i seguenti requisiti:
  • L'entropia della lunghezza minima consentita degli input DEVE essere maggiore di 10 bit.
  • L'entropia massima di tutti gli input possibili DEVE essere maggiore di 18 bit.
  • NON deve sostituire nessuno dei metodi di autenticazione esistenti (PIN, sequenza, password) implementati e forniti in AOSP.
  • DEVE essere disattivato quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_SOMETHING .
• Il metodo di autenticazione, se basato su un token fisico o sulla posizione, NON DEVE essere considerato una schermata di blocco sicura, a meno che non soddisfi tutti i seguenti requisiti:
  • DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali basato su un segreto noto e soddisfare i requisiti per essere considerato una schermata di blocco sicura.
  • DEBBA essere disattivata e consentire solo all'autenticazione principale di sbloccare la schermata quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio con il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED .
• Il metodo di autenticazione, se basato sulla biometria, NON DEVE essere considerato una schermata di blocco sicura, a meno che non soddisfi tutti i seguenti requisiti:
  • DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali basato su un segreto noto e soddisfare i requisiti per essere considerato una schermata di blocco sicura.
  • DEBBA essere disattivata e consentire solo all'autenticazione principale di sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio della funzionalità keguard chiamando il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) .
  • DEVE avere un tasso di accettazione di falsi positivi uguale o superiore a quello richiesto per un sensore di impronte digitali come descritto nella sezione 7.3.10 oppure DEVE essere disattivato e consentire solo all'autenticazione principale di sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK .
• Se il metodo di autenticazione non può essere considerato una schermata di blocco sicura:
  • DEVE restituire false sia per i metodi KeyguardManager.isKeyguardSecure() che KeyguardManager.isDeviceSecure().
  • DEVE essere disattivato quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED .
  • NON DEVE reimpostare i timer di scadenza della password impostati da DevicePolicyManager.setPasswordExpirationTimeout() .
  • NON DEVE autenticare l'accesso ai magazzini delle chiavi se l'applicazione ha chiamato KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).
• Se il metodo di autenticazione si basa su un token fisico, sulla posizione o sulla biometria con un tasso di accettazione di falsi più elevato di quello richiesto per i sensori di impronte digitali come descritto nella sezione 7.3.10, deve:
  • NON DEVE reimpostare i timer di scadenza della password impostati da DevicePolicyManager.setPasswordExpirationTimeout() .
  • NON DEVE autenticare l'accesso ai magazzini delle chiavi se l'applicazione ha chiamato KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) .

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 di quanto segue:

• L'immagine di sistema
• Eventuali file del sistema operativo richiesti dall'immagine di sistema

È OBBLIGATORIO eliminare tutti i dati generati dagli utenti. 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.

9.13. Modalità Avvio sicuro

Android offre una modalità che consente agli utenti di avviarsi in una modalità in cui è consentito l'esecuzione solo delle app di sistema preinstallate e tutte le app di terze parti sono disattivate. Questa modalità, nota come "Modalità di avvio sicuro", consente all'utente di disinstallare app di terze parti potenzialmente dannose.

È FORTEMENTE CONSIGLIATO implementare la modalità Avvio sicuro per i dispositivi Android e soddisfare i seguenti requisiti:

• Le implementazioni dei dispositivi DEVONO fornire all'utente la possibilità di accedere alla modalità di avvio sicuro dal menu di avvio, raggiungibile tramite un flusso di lavoro diverso da quello dell'avvio normale.

• Le implementazioni dei dispositivi DEVONO fornire all'utente un'opzione per accedere alla modalità di avvio sicuro in modo che non possa essere interrotta dalle app di terze parti installate sul dispositivo, tranne nel caso in cui l'app di terze parti sia un controller Device Policy e abbia impostato il flag UserManager.DISALLOW_SAFE_BOOT su True.

• Le implementazioni dei dispositivi DEVONO fornire all'utente la possibilità di disinstallare qualsiasi app di terze parti in modalità provvisoria.

9.14. Isolamento del sistema di veicoli a motore

I dispositivi Android Automotive devono scambiare dati con sottosistemi critici del veicolo, ad esempio utilizzando l'HAL del veicolo per inviare e ricevere messaggi tramite le reti del veicolo come il bus CAN. Le implementazioni dei dispositivi Android Automotive DEVONO implementare funzionalità di sicurezza sotto i livelli del framework Android per impedire l'interazione dannosa o involontaria tra il framework Android o le app di terze parti e i sottosistemi del veicolo. Queste funzionalità di sicurezza sono le seguenti:

• Controllo dei messaggi provenienti dai sottosistemi del veicolo del framework Android, ad esempio l'elenco consentiti di tipi di messaggi e origini dei messaggi.
• Monitoraggio per rilevare gli attacchi di tipo denial of service dal framework Android o da app di terze parti. In questo modo, si evita che il software dannoso inondi la rete del veicolo con traffico, causando il malfunzionamento dei sottosistemi del veicolo.

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 dei 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 rielaborazioni e potenziali aggiornamenti del dispositivo.

10.1. Compatibility Test Suite (CTS)

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

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi software, anche il CTS potrebbe contenere bug. La versione del CTS sarà indipendente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni del CTS per Android 7.1. 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 in CTS Verifier. CTS Verifier è incluso nella Compatibility Test Suite e deve 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 relativi all'hardware di cui sono dotati. Ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente il test case Accelerometer in CTS Verifier. Gli scenari di test per le funzionalità indicate come facoltative da questo documento di definizione della compatibilità 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 CTS Verifier su build che differiscono solo in modo banale. In particolare, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato CTS Verifier solo per l'insieme di lingue, branding e così via inclusi POSSONO omettere il test CTS Verifier.

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 approcci soddisfa questo requisito:

• I download "over-the-air (OTA)" con aggiornamento offline tramite riavvio.
• Aggiornamenti "in tethering" tramite USB da un PC host.
• Aggiornamenti "offline" tramite un riavvio e un aggiornamento da un file su una memoria rimovibile.

Tuttavia, se l'implementazione del dispositivo include il supporto di una connessione dati non conteggiata, come il profilo 802.11 o Bluetooth PAN (Personal Area Network), DEVE supportare i download OTA con aggiornamento offline tramite riavvio.

Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. In altre parole, 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 DOVREBBE 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.

Inoltre, le implementazioni dei dispositivi DEVONO supportare gli aggiornamenti di sistema A/B . AOSP implementa questa funzionalità utilizzando l'HAL di controllo del boot.

Se in un'implementazione del dispositivo viene rilevato un errore dopo il rilascio, ma entro il periodo di tempo ragionevole del prodotto, che viene stabilito in consultazione con il team di compatibilità Android, che influisce sulla compatibilità delle applicazioni di terze parti, l'implementatore del dispositivo DEVE correggere l'errore tramite un aggiornamento software disponibile che può essere applicato secondo il meccanismo appena descritto.

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.

12. Log delle modifiche del documento

Per un riepilogo delle modifiche alla definizione di compatibilità in questa release:

• Documentare il log delle modifiche

Per un riepilogo delle modifiche alle sezioni relative alle persone:

1. Introduzione
2. Tipi di dispositivi
3. Software
4. Confezione dell'applicazione
5. Contenuti multimediali
6. Strumenti e opzioni per sviluppatori
7. Compatibilità hardware
8. Prestazioni e potenza
9. Modello di sicurezza
10. Test di compatibilità del software
11. Software aggiornabile
12. Log delle modifiche della documentazione
13. Contattaci

12.1. Suggerimenti per la visualizzazione del log delle modifiche

Le modifiche sono contrassegnate come segue:

• CDD
  Modifiche sostanziali ai requisiti di compatibilità.

• Documenti
  Modifiche estetiche o relative alla compilazione.

Per una visualizzazione ottimale, aggiungi i parametri URL pretty=full e no-merges agli URL del log delle modifiche.

13. Contattaci

Puoi partecipare al forum Android Compatibility e chiedere chiarimenti o segnalare eventuali problemi che ritieni non coperti dal documento.