Android 7.0, (N) definizione di compatibilità

Indice

1. Introduzione

Questo documento elenca i requisiti che devono essere soddisfatti per rendere i dispositivi compatibili con Android 7.0.

L'utilizzo di "DEVE", "NON DEVE", "OBBLIGATORIO", "SHALL", "NON CONSENTITO", "DOVREBRE", "NON DOVREBBE", "CONSIGLIATO", "MAGGIO" e "FACOLTATIVO" è conforme allo standard IETF definito nel documento RFC2119.

Per "implementatore del dispositivo" o "implementatore" si intende una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 7.0. Per "implementazione del dispositivo" o "implementazione" si intende la soluzione hardware/software così sviluppata.

Per essere considerate compatibili con Android 7.0, le implementazioni dei dispositivi DEVONO soddisfare i requisiti presentati nella presente Definizione di compatibilità, compresi gli eventuali documenti incorporati tramite riferimento.

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

Per questo motivo, l'Android Open Source Project è sia il riferimento sia l'implementazione preferita di Android. Gli utenti che implementano i dispositivi sono VIVAMENTE CONSIGLIATI di basare le loro implementazioni il più possibile sul codice sorgente "upstream" disponibile nell'Android Open Source Project. Sebbene alcuni componenti possano ipoteticamente essere sostituiti con implementazioni alternative, è VIVAMENTE CONSIGLIATO di non seguire questa prassi, in quanto il superamento dei test del software diventerà molto più difficile. È responsabilità dell'implementatore di garantire la piena compatibilità comportamentale con l'implementazione standard di Android, inclusa e oltre il Compatibility Test Suite. Infine, tieni presente che determinate sostituzioni e modifiche dei componenti sono espressamente vietate dal presente documento.

Molte delle risorse collegate in questo documento derivano direttamente o indirettamente dall'SDK Android e saranno identiche dal punto di vista funzionale alle informazioni contenute nella documentazione dell'SDK. Nei casi in cui la presente Definizione di compatibilità o il Test Suite di compatibilità non concordi con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevoli. Eventuali dettagli tecnici forniti nelle risorse collegate in questo documento sono considerati parte integrante della presente Definizione di compatibilità.

2. Tipi di dispositivi

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

Un dispositivo portatile Android fa riferimento a un'implementazione di dispositivi Android che solitamente si tiene in mano, ad esempio lettori mp3, telefoni e tablet. Implementazioni di dispositivi portatili Android:

  • DEVE avere un touchscreen incorporato nel dispositivo.
  • DEVE avere una fonte di alimentazione che offra mobilità, come una batteria.

Dispositivo Android TV si riferisce a un'implementazione di dispositivi Android, ovvero un'interfaccia di intrattenimento per l'utilizzo di media digitali, film, giochi, app e/o TV in diretta per utenti seduti a circa 3 metri di distanza ("interfaccia utente di 3 metri di distanza"). Dispositivi Android TV:

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

Dispositivo Android Watch si riferisce a un'implementazione del dispositivo Android da indossare a corpo, forse al polso e:

  • DEVE avere uno schermo con la lunghezza diagonale fisica nell'intervallo da 1,1 a 2,5 pollici.
  • 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 su cui è in esecuzione Android come sistema operativo per l'intero sistema e/o la funzionalità di infotainment o per intero. Implementazioni di Android Automotive:

  • DEVE avere uno schermo con la lunghezza diagonale fisica uguale o superiore a 6 pollici.
  • 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.*.

Per essere compatibili con Android 7.0, tutte le implementazioni di dispositivi Android che non rientrano in nessuno dei tipi di dispositivi sopra indicati DEVONO comunque soddisfare tutti i requisiti riportati in questo documento, a meno che non sia indicato esplicitamente come applicabile solo a un tipo di dispositivo Android specifico indicato in precedenza.

2.1 Configurazioni dei dispositivi

Questo è un riepilogo delle principali differenze nella configurazione hardware in base al tipo di dispositivo. (le celle vuote indicano "MAG"). Non tutte le configurazioni sono trattate in questa tabella. consulta le sezioni pertinenti sull'hardware per ulteriori dettagli.

Categoria Funzionalità Sezione A mano Televisione Guarda contenuti Automotive Altro
Ingresso D-pad 7.2.2. Navigazione non touch DEVE
Touchscreen 7.2.4. Input touchscreen DEVE DEVE DOVREBBE
Microfono 7.8.1. Microfono DEVE DOVREBBE DEVE DEVE 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 DEVE DEVE DEVE DOVREBBE
Bluetooth Low Energy 7.4.3. Bluetooth DOVREBBE DEVE DOVREBBE DOVREBBE DOVREBBE
Segnale radio cell 7.4.5. Capacità di rete minima DOVREBBE
Modalità host/periferica USB 7.7. USB DOVREBBE DOVREBBE DOVREBBE
Output Porte di uscita per altoparlante e/o audio 7.8.2. Uscita audio DEVE DEVE DEVE DEVE

3. Software

3.1. Compatibilità delle API gestite

L'ambiente di esecuzione bytecode Dalvik gestito è il veicolo principale per le app per Android. L'API (Application Programming Interface) di Android è un 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 per Android o di qualsiasi API decorata con l'indicatore "@SystemApi" nel codice sorgente Android upstream.

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

Le implementazioni dei dispositivi NON DEVONO omettere API gestite, alterare le interfacce o le firme delle API, deviare dal comportamento documentato né includere operazioni autonome, salvo nei casi espressamente consentiti dalla presente Definizione di compatibilità.

Questa definizione di compatibilità consente di omettere dalle implementazioni dei dispositivi alcuni tipi di hardware per cui Android include le API. In questi casi, le API DEVONO essere comunque presenti e comportarsi in modo ragionevole. Consulta la sezione 7 per i requisiti specifici relativi a questo scenario.

3.1.1. Estensioni Android

Android include il supporto dell'estensione delle API gestite mantenendo la stessa versione a livello API. Le implementazioni dei dispositivi Android DEVONO precaricare l'implementazione AOSP sia della libreria condivisa ExtShared che dei servizi ExtServices con versioni superiori o uguali al numero minimo di versioni consentite per ogni livello API. Ad esempio, le implementazioni dei dispositivi Android 7.0 e l'esecuzione del 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 per il runtime, sotto forma di, ad esempio, intent, autorizzazioni e aspetti simili delle app per Android che non possono essere applicati al momento della compilazione dell'applicazione.

3.2.1. Autorizzazioni

Gli utenti che implementano i dispositivi DEVONO supportare e applicare tutte le costanti di autorizzazione come documentato nella pagina di riferimento alle autorizzazioni. Tieni presente che la sezione 9 elenca ulteriori requisiti relativi al modello di sicurezza di Android.

3.2.2. Parametri build

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 riportata di seguito include ulteriori limitazioni sui formati di questi valori a cui le implementazioni dei dispositivi DEVONO essere conformi.

Parametro Dettagli
VERSIONE.LANCIO La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE contenere uno dei valori di stringa definiti nella sezione 7.0.
VERSIONE.SDK La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 7.0, questo campo DEVE avere il valore intero 7.0_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.0, questo campo DEVE avere il valore intero 7.0_INT.
VERSIONE.INCREMENTALE 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 diverse build rese disponibili agli utenti finali. Un utilizzo tipico di questo campo è quello di indicare il numero di build o l'identificatore della modifica del controllo del codice sorgente utilizzato per generare la build. Non esistono requisiti sul formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere null 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. Questo campo può essere utilizzato per 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 e che è noto agli utenti finali. DEVONO essere in formato leggibile e DEVONO rappresentare il produttore del dispositivo o il brand aziendale con cui il dispositivo viene commercializzato. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
SUPPORTO_ABIS Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle API native.
SUPPORTO_32_BIT_ABIS Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle API native.
SUPPORTATO_64_BIT_ABIS Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle API native.
CPU_ABI Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle 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à delle 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 di questo dispositivo NON DEVE cambiare per tutta la durata del prodotto.
IMPRONTA Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile. DEVE seguire questo modello:

$(BRAND)/$(PRODUCT)/
$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Ad esempio:

acme/mioprodotto/
mydevice:7.0/LMYXX/3359:userdebug/test-keys

L'impronta NON DEVE includere spazi vuoti. Se altri campi inclusi nel modello precedente contengono spazi vuoti, questi DEVONO essere sostituiti nella fingerprint della build con un altro carattere, come 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). DEVE essere ragionevolmente leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
PRESENTATORE Una stringa che identifica in modo univoco l'host su cui è stata basata la build, in formato leggibile. Non esistono requisiti sul formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere null o la stringa vuota ("").
ID Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in 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 tra build del software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
PRODUTTORE Il nome commerciale del produttore di apparecchiature originali (OEM) del prodotto. Non esistono requisiti sul formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere null o la stringa vuota ("").
MODELLO Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo noto all'utente finale. DEVE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non esistono requisiti sul formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere null 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 deve essere necessariamente visibile agli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Questo nome del prodotto NON DEVE cambiare per tutta la durata del prodotto.
SERIE Un numero di serie hardware, che DEVE essere disponibile e univoco per 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 contraddistinguono ulteriormente la build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni tipiche di firma della piattaforma Android: chiavi di rilascio, chiavi di sviluppo e chiavi di test.
DURATA Un valore che rappresenta il timestamp di quando è avvenuta la build.
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 tipiche di runtime Android: user, userdebug o eng.
UTENTE Il nome o l'ID utente dell'utente (o dell'utente automatico) che ha generato la build. Non esistono requisiti sul formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere null o la stringa vuota ("").
PATCH_DI_SICUREZZA Un valore che indica il livello patch di sicurezza di una build. DEVE indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti nel Bollettino sulla sicurezza pubblica di Android designato. DEVE essere nel formato [AAAA-MM-GG], corrispondente a una stringa definita documentata nel Bollettino sulla sicurezza pubblica di Android o nell'Avviso sulla sicurezza di Android, ad esempio "2015-11-01".
Sistema operativo BASE Un valore che rappresenta il parametro FINGERPRINT della build che è altrimenti identico a questa build, ad eccezione delle patch fornite nel Bollettino sulla sicurezza pubblica di Android. DEVE segnalare il valore corretto e, se la build non esiste, segnalare una stringa vuota ("").

3.2.3. Compatibilità degli intent

3.2.3.1. Application Intent principali

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

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

Le implementazioni dei dispositivi DEVONO includere le applicazioni principali per Android, a seconda dei casi, o un componente che implementa gli stessi pattern di intent definiti da tutti i componenti Attività o Servizi di queste applicazioni Android principali esposte ad altre applicazioni, in modo implicito o esplicito, tramite l'attributo android:exported.

3.2.3.2. Risoluzione dell'intenzione

Android è una piattaforma estensibile, pertanto 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 utenti che implementano i dispositivi NON DEVONO assegnare privilegi speciali alle applicazioni di sistema l'utilizzo di questi pattern di intent o impedire che applicazioni di terze parti si impegnino a questi pattern e ne assumano il controllo. Questo divieto include nello specifico, a titolo esemplificativo, la disattivazione dell'interfaccia utente "Selettore", 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 in cui gli utenti possano 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 dei dati. Ad esempio, un pattern di filtro per intent che specifica l'URI di dati "http://www.android.com" è più specifico del pattern di intent principale del browser per "http://".

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

  • DEVE tentare di convalidare eventuali filtri per intent eseguendo la procedura di convalida definita nella specifica Digital Asset Links come implementata dal gestore di pacchetti nel progetto open source Android a monte.
  • DEVE tentare la convalida dei filtri per intent durante l'installazione dell'applicazione e impostare tutti i filtri per intent UIR convalidati come gestori di app predefiniti per i rispettivi UIR.
  • POTREBBE impostare filtri di intent specifici per gli URI come gestori di app predefiniti per i relativi URI, se vengono verificati correttamente, ma gli altri filtri URI candidati non superano la verifica. Se l'implementazione avviene in questo modo, DEVE fornire all'utente override appropriati di pattern per URI nel menu delle impostazioni.
  • DEVE fornire all'utente i controlli dei link alle app per ogni app nelle Impostazioni, come descritto di seguito:
    • L'utente DEVE essere in grado di ignorare a livello globale il comportamento predefinito dei link dell'app affinché un'app sia sempre aperta, sempre chiedere o mai aperta, che deve essere applicata a tutti i filtri per intent dell'URI candidato in modo uguale.
    • L'utente DEVE essere in grado di visualizzare un elenco di filtri per intent dell'URI candidati.
    • L'implementazione del dispositivo POTREBBE offrire all'utente la possibilità di ignorare specifici filtri per intent dell'URI candidato che sono stati verificati correttamente, in base a un filtro per intent.
    • L'implementazione del dispositivo DEVE offrire agli utenti la possibilità di visualizzare ed eseguire l'override di specifici filtri per intent dell'URI candidato se l'implementazione del dispositivo consente ad alcuni filtri per intent dell'URI candidato di completare la verifica, mentre altri potrebbero non riuscire.

3.2.3.3. Spazi dei nomi per intent

Le implementazioni dei dispositivi NON DEVONO includere componenti Android che rispettano i nuovi pattern per intent o di trasmissione utilizzando un'AZIONE, una CATEGORIA o un'altra stringa chiave in Android. o com.android.. Gli implementatori del dispositivo NON DEVONO includere componenti Android che rispettano i nuovi pattern per intent o di trasmissione utilizzando un'AZIONE, una CATEGORIA o un'altra stringa chiave in uno spazio di pacchetti appartenente a un'altra organizzazione. Gli utenti che implementano i dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent utilizzati dalle app principali elencate nella sezione 3.2.3.1. Le implementazioni sui dispositivi POTREBBERO includere pattern di intent che utilizzano spazi dei nomi in modo chiaro e ovvio associati alla propria organizzazione. Questo divieto è analogo a quello specificato per le classi di linguaggio Java nella sezione 3.6.

3.2.3.4. Intent di trasmissione

Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent per notificare modifiche all'ambiente hardware o software. I dispositivi compatibili con Android DEVONO trasmettere gli intent di trasmissione pubblica in risposta agli 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 consentono agli utenti di selezionare facilmente le applicazioni predefinite, ad esempio per la schermata Home o gli SMS. Ove opportuno, le implementazioni dei dispositivi DEVONO fornire un menu di impostazioni simile ed essere compatibili con il pattern di filtro per 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 di impostazioni dell'app predefinito per la schermata Home, se l'implementazione del dispositivo segnala android.software.home_screen.
  • DEVE fornire un menu delle impostazioni che chiamerà 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 di impostazioni dell'app predefinito per la funzionalità Tocca e paga, se nell'implementazione del dispositivo risulta android.hardware.nfc.hce.
  • DEVE rispettare l'intent android.telecom.action.CHANGE_DEFAULT_DIALER per mostrare una finestra di dialogo per consentire all'utente di modificare l'applicazione predefinita Telefono, se l'implementazione del dispositivo riporta android.hardware.telephony .

3.3. Compatibilità API native

La compatibilità del codice nativo è impegnativa. Per questo motivo, agli utenti che implementano i dispositivi è CONSIGLIATO l'utilizzo delle implementazioni delle librerie elencate di seguito provenienti dal progetto open source Android a monte.

3.3.1. Interfacce binarie dell'applicazione

Il bytecode Dalvik gestito può richiamare il codice nativo fornito nel file .apk dell'applicazione come file .so ELF compilato per l'architettura hardware del dispositivo appropriata. Poiché il codice nativo dipende fortemente dalla tecnologia del processore sottostante, Android definisce una serie di ABI (Application Binary Interface) nell'NDK di Android. 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 l'implementazione di un dispositivo include il supporto per un'ABI Android:

  • DEVE includere il supporto del codice in esecuzione nell'ambiente gestito per richiamare il codice nativo, utilizzando la semantica standard di Java Native Interface (JNI).
  • DEVE essere compatibile con l'origine (ovvero con l'intestazione) e binaria (per l'ABI) con ciascuna libreria obbligatoria nell'elenco seguente.
  • DEVE supportare l'ABI a 32 bit equivalente se è supportata qualsiasi ABI a 64 bit.
  • DEVE segnalare con precisione l'ABI (Application Binary Interface) 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, ognuno con un elenco separato da virgole di ABI ordinate dalla più alla meno preferita.
  • DEVE segnalare, tramite i parametri sopra indicati, solo le ABI documentate e descritte nella versione più recente della documentazione sulla gestione delle ABI NDK per Android e DEVONO includere il supporto dell'estensione SIM avanzata (ovvero NEON).
  • DOVREBBE essere create utilizzando il codice sorgente e i file di intestazione disponibili nel progetto open source Android a monte

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

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

  • libandroid.so (supporto nativo attività Android)
  • libc (libreria C)
  • libcamera2ndk.so
  • libdl (linker dinamico)
  • libEGL.so (gestione della superficie OpenGL nativa)
  • 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 native per i media)
  • 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 per 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, poiché le librerie di sistema sono riservate e NON DEVONO essere esposte ad app di terze parti che hanno come target il livello API 24 o superiore.

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

Tieni presente che le implementazioni dei dispositivi DEVONO includere libGLESv3.so e, a loro volta, DEVONO esportare tutti i simboli delle funzioni OpenGL ES 3.1 e Android Extension Pack, come definito nella release NDK Android-24. Anche se devono essere presenti tutti i simboli, devono essere implementate completamente solo le funzioni corrispondenti per le versioni e le estensioni OpenGL ES effettivamente supportate dal dispositivo.

3.3.1.1. Librerie grafiche

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

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

Implementazioni dei dispositivi, se incluso il supporto delle API Vulkan:

  • DEVONO segnalare uno o più VkPhysicalDevices tramite la chiamata vkEnumeratePhysicalDevices.
  • Ogni VkPhysicalDevices enumerato DEVE implementare completamente l'API Vulkan 1.0.
  • DEVONO segnalare i flag funzionalità PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL e PackageManager#FEATURE_VULKAN_HARDWARE_VERSION corretti.
  • DEVE enumerare i livelli, contenuti nelle librerie native denominate libVkLayer*.so nella directory della libreria nativa 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, né fornire altri modi per tracciare o intercettare l'API Vulkan, a meno che l'applicazione non disponga dell'attributo android:debuggable=”true”.

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

3.3.2. Compatibilità del codice nativo ARM a 32 bit

L'architettura ARMv8 ritira diverse operazioni della CPU, incluse alcune operazioni 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 emulazione software:

  • Istruzioni per SWP e SWPB
  • Istruzione SETEND
  • Operazioni con barriera CP15ISB, CP15DSB e CP15DMB

Le versioni legacy di Android NDK utilizzavano /proc/cpuinfo per scoprire le funzionalità della CPU dal codice nativo ARM a 32 bit. Per garantire la compatibilità con applicazioni create utilizzando questo NDK, i dispositivi DEVONO includere le seguenti righe in /proc/cpuinfo quando viene letto da applicazioni ARM a 32 bit:

  • "Funzionalità: ", seguita 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ù supportata del dispositivo (ad es. "8" per i dispositivi ARMv8).

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

3.4. Compatibilità web

3.4.1. Compatibilità con WebView

I dispositivi Android Watch POSSONO, ma tutte le altre implementazioni dei dispositivi DEVONO fornire un'implementazione completa dell'API android.webkit.Webview.

La funzionalità della piattaforma android.software.webview DEVE essere segnalata su qualsiasi dispositivo che fornisce un'implementazione completa dell'API android.webkit.WebView e NON DEVE essere segnalata su dispositivi senza un'implementazione completa dell'API. L'implementazione open source di Android 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 specifica build upstream di Chromium nell'implementazione di WebView. Nello specifico:

  • Le implementazioni android.webkit.WebView del dispositivo DEVONO essere basate sulla build Chromium dell'Android Open Source Project a monte per Android 7.0. Questa build include un insieme specifico di correzioni di funzionalità e sicurezza per WebView.

  • La stringa dello user agent riportata dalla WebView DEVE essere in questo formato:

    Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/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 a monte.
    • Le implementazioni dei dispositivi POSSONO omettere "Mobile" nella stringa dello user agent.

Il componente WebView DEVE includere il supporto per il maggior numero possibile di funzionalità HTML5 e, se supporta la funzione DEVE essere conforme alla specifica HTML5.

3.4.2. Compatibilità del browser

Le implementazioni di Android Television, Watch e Android Automotive POSSONO omettere un'applicazione browser, ma DEVONO supportare i pattern di intenti pubblici come descritto nella sezione 3.2.3.1. Tutti gli altri tipi di implementazioni sui dispositivi DEVONO includere un'applicazione browser autonoma per la navigazione generale degli utenti sul web.

Il browser autonomo POTREBBE essere basato su una tecnologia browser diversa da WebKit. Tuttavia, anche se viene utilizzata un'applicazione 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 fornire una stringa personalizzata dello user agent nell'applicazione browser autonoma.

L'applicazione browser autonoma (basata sull'applicazione browser WebKit upstream o su una sostituzione di terze parti) DEVE includere il supporto del maggior numero possibile di HTML5. Le implementazioni dei dispositivi DEVONO supportare almeno tutte le API associate a HTML5:

Inoltre, le implementazioni dei dispositivi DEVONO supportare l'API webstorage HTML5/W3C e l'API IndexedDB per HTML5/W3C. Tieni presente che, poiché gli enti degli standard di sviluppo web stanno passando a preferire IndexedDB rispetto allo spazio di archiviazione web, è previsto che IndexedDB diventerà un componente obbligatorio in una versione futura di Android.

3.5. Compatibilità di comportamento delle API

I comportamenti di ogni tipo di API (gestita, soft, nativa e web) devono essere coerenti con l'implementazione preferita del progetto open source Android upstream. Ecco alcune aree specifiche di compatibilità:

  • I dispositivi NON DEVONO modificare il comportamento o la semantica di un intent standard.
  • I dispositivi NON DEVONO alterare il ciclo di vita o la semantica del ciclo di vita di un particolare tipo di componente di sistema (come 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 parti significative della piattaforma per verificarne la compatibilità comportamentale, ma non tutte. È responsabilità dell'implementatore di garantire la compatibilità comportamentale con Android Open Source Project. Per questo motivo, gli implementatori dei dispositivi DEVONO utilizzare il codice sorgente disponibile tramite il progetto open source Android, ove possibile, anziché reimplementare parti significative del sistema.

3.6. Spazi dei nomi API

Android segue le convenzioni dello spazio dei nomi dei pacchetti e delle classi definite dal linguaggio di programmazione Java. Per garantire la compatibilità con applicazioni di terze parti, gli utenti che implementano i dispositivi NON DEVONO apportare modifiche vietate (vedi di seguito) agli spazi dei nomi dei pacchetti:

  • java.*
  • javax.*
  • dom.*
  • android.*
  • com.android.*

Le modifiche vietate includono :

  • Le implementazioni dei dispositivi NON DEVONO modificare le API esposte pubblicamente sulla piattaforma Android cambiando le firme dei metodi o delle classi né rimuovendo le classi o i campi dei corsi.
  • Gli implementatori dei dispositivi POSSONO modificare l'implementazione sottostante delle API, ma tali modifiche NON DEVONO influire sul comportamento dichiarato e sulla firma in linguaggio Java di eventuali API esposte pubblicamente.
  • Gli utenti che implementano i 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 che non è decorato con l'indicatore "@hide" come utilizzato nel codice sorgente Android upstream. In altre parole, gli implementatori dei dispositivi NON DEVONO esporre nuove API o alterare le API esistenti negli spazi dei nomi indicati sopra. Gli implementatori dei dispositivi POSSONO apportare modifiche solo per uso interno, ma tali modifiche NON DEVONO essere pubblicizzate o mostrate in altro modo agli sviluppatori.

Gli implementatori dei dispositivi POSSONO aggiungere API personalizzate, ma tali API NON DEVONO trovarsi in uno spazio dei nomi di proprietà di un'altra organizzazione o che faccia riferimento a un'altra. Ad esempio, gli utenti che implementano i dispositivi NON DEVONO aggiungere API a com.google.* o a uno spazio dei nomi simile: solo Google può farlo. Analogamente, Google NON DEVE aggiungere API ai spazi dei nomi. Inoltre, se l'implementazione di un dispositivo include API personalizzate che non rientrano nello spazio dei nomi Android standard, queste API DEVONO essere pacchettizzate in una libreria condivisa di Android, in modo che solo le app che le usano esplicitamente (tramite il meccanismo <uses-library>) siano interessate dall'aumento della memoria utilizzata da queste API.

Se un implementatore del dispositivo propone di migliorare uno degli spazi dei nomi pacchetto sopra indicati (ad esempio, aggiungendo nuove utili funzionalità 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 scrivere codice, in base alle informazioni presenti sul sito.

Notare che le limitazioni precedenti corrispondono alle convenzioni standard per la denominazione delle API nel linguaggio di programmazione Java; questa sezione mira semplicemente a rafforzare tali convenzioni e a renderle vincolanti per l'inclusione in questa definizione di compatibilità.

3.7. Compatibilità di runtime

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

Le implementazioni dei dispositivi DEVONO configurare i runtime Dalvik in modo che allocano la memoria in base alla piattaforma Android upstream e a quanto 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 sui dispositivi POSSONO allocare più memoria per applicazione.

Layout schermo Densità schermo Memoria minima delle applicazioni
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à con l'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 Avvio applicazioni (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

I widget sono facoltativi per tutte le implementazioni sui dispositivi Android, ma DEVONO essere supportati sui dispositivi portatili Android.

Android definisce un tipo di componente e l'API e il ciclo di vita corrispondenti che consentono alle applicazioni di esporre un "AppWidget" all'utente finale, una funzionalità che è VIVAMENTE CONSIGLIATA di essere supportata sulle implementazioni dei dispositivi portatili. Le implementazioni dei dispositivi che supportano l'incorporamento di widget nella schermata Home DEVONO soddisfare i seguenti requisiti e dichiarare il supporto per la funzionalità della piattaforma android.software.app_widgets.

  • Le applicazioni per l'avvio dei dispositivi DEVONO includere il supporto integrato per AppWidgets ed esporre le autorizzazioni dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere AppWidget direttamente all'interno di Avvio app.
  • Le implementazioni dei dispositivi DEVONO essere in grado di visualizzare widget 4 x 4 nelle dimensioni griglia standard. Per informazioni dettagliate, consulta le linee guida sulla progettazione del widget dell'app nella documentazione dell'SDK per Android.
  • Le implementazioni dei dispositivi che includono il supporto della schermata di blocco POTREBBERO supportare i widget delle applicazioni su quest'ultima.

3.8.3. Notifiche

Android include API che consentono agli sviluppatori di informare gli utenti di eventi importanti utilizzando le funzionalità hardware e software del dispositivo.

Alcune API consentono alle applicazioni di eseguire notifiche o attirare l'attenzione utilizzando l'hardware, in particolare suoni, vibrazione e luce. Le implementazioni dei dispositivi DEVONO supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK e nella misura possibile con l'hardware di implementazione del dispositivo. Ad esempio, se l'implementazione di un dispositivo include una vibrazione, DEVE implementare correttamente le API di vibrazione. Se l'implementazione in un dispositivo è priva di hardware, le API corrispondenti DEVONO essere implementate in modalità autonoma. Questo comportamento è descritto più dettagliatamente nella sezione 7.

Inoltre, l'implementazione DEVE visualizzare correttamente tutte le risorse (icone, file di animazione e così via) fornite nelle API o nella guida di stile per le icone della barra di stato/di sistema, che nel caso di un dispositivo Android Television 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 open source di Android di riferimento. tuttavia, tali sistemi di notifica alternativi DEVONO supportare le risorse di notifica esistenti, come indicato sopra.

Le implementazioni di Android Automotive POTREBBERO gestire la visibilità e i tempi delle notifiche per ridurre la distrazione del conducente, ma DEVONO visualizzare notifiche che utilizzano CarExtender quando richiesto dalle applicazioni.

Android supporta diverse notifiche, tra cui:

  • Notifiche avanzate . Visualizzazioni interattive per le notifiche continue.
  • Notifiche avanzate . Gli utenti delle visualizzazioni interattive possono agire su o ignorare senza uscire dall'app corrente.
  • Notifiche nella schermata di blocco . Notifiche mostrate 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 di avviso e includere titolo/nome, icona e testo come documentati nelle API Android.

Android include le API del servizio listener di notifiche che consentono alle app (una volta attivate esplicitamente dall'utente) di ricevere una copia di tutte le notifiche non appena vengono pubblicate o aggiornate. Le implementazioni dei dispositivi DEVONO inviare in modo corretto e tempestivo le notifiche nella loro interezza a tutti i servizi ascoltatori installati e abilitati all'utente, inclusi tutti i metadati allegati all'oggetto Notification.

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

  • DEVE implementare un'attività che risponda all'intento 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 DND.
  • DEVE, quando l'implementazione del dispositivo ha fornito all'utente un mezzo per concedere o negare ad app di terze parti l'accesso alla configurazione dei criteri di Non disturbare, visualizzare le regole DND automatiche create dalle applicazioni insieme alle regole create dall'utente e predefinite.
  • DEVE rispettare i valori suppressedVisualEffects trasmessi insieme alla NotificationManager.Policy e, se un'app ha impostato uno qualsiasi dei flag SUPPRESSED_Effetti_SCREEN_OFF o SUPPRESSED_Effetti_SCREEN_ON, DEVE indicare all'utente che gli effetti visivi sono soppressi nel menu delle impostazioni DND.

Android include API che consentono agli sviluppatori di incorporare la ricerca nelle loro applicazioni ed esporre i dati delle loro applicazioni nella ricerca globale di sistema. 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 gli utenti digitano testo e risultati. Le API Android consentono agli sviluppatori di riutilizzare questa interfaccia per fornire ricerche all'interno delle loro app e di fornire risultati all'interfaccia utente di ricerca globale comune.

Le implementazioni dei dispositivi Android DEVONO includere la ricerca globale, una singola interfaccia utente di ricerca condivisa e a livello di sistema in grado di fornire suggerimenti in tempo reale in risposta all'input dell'utente. Le implementazioni dei dispositivi DEVONO implementare le API che consentano agli sviluppatori di riutilizzare questa interfaccia utente per fornire ricerche all'interno delle loro applicazioni. Le implementazioni dei dispositivi che implementano l'interfaccia di ricerca globale DEVONO implementare le API che consentano 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 visualizzare i risultati e i suggerimenti del motore di ricerca web.

Le implementazioni dei dispositivi Android DEVONO 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 vengono condivise con l'assistente sul dispositivo. Le implementazioni dei dispositivi che supportano l'azione evento indiretto DEVONO indicare chiaramente all'utente finale quando il contesto è condiviso mostrando una spia bianca ai bordi dello schermo. Per garantire una chiara visibilità all'utente finale, l'indicazione DEVE rispettare o superare la durata e la luminosità dell'implementazione di Android Open Source Project.

3.8.5. Toast

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 agli utenti finali i messaggi Toast dalle applicazioni in modo ad alta visibilità.

3.8.6. Temi

Android offre i "temi" come meccanismo per 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 per abbinare l'aspetto del tema Holo definito dall'SDK Android. Le implementazioni dei dispositivi NON DEVONO alterare gli 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 del design all'ampia gamma di diversi tipi di dispositivi Android. Le implementazioni dei dispositivi DEVONO supportare la famiglia di temi "Materiale" e NON DEVONO alterare gli attributi del tema materiale o i relativi asset esposti alle applicazioni.

Android include anche una famiglia di temi "Predefinito in base al dispositivo", ovvero un 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 delle varianti con barre di sistema traslucide, che consentono agli sviluppatori di applicazioni di riempire con i contenuti delle app l'area dietro la barra di stato e di navigazione. Per offrire agli sviluppatori un'esperienza coerente in questa configurazione, è importante che lo stile dell'icona della barra di stato venga mantenuto in diverse implementazioni dei dispositivi. Pertanto, le implementazioni dei dispositivi Android DEVONO essere in bianco per le icone di stato del sistema (come 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 non richieda una barra di stato luminosa utilizzando il flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Quando un'app richiede una barra di stato luminosa, le implementazioni dei dispositivi Android DEVONO cambiare il colore delle icone di stato del sistema in nero (per maggiori dettagli, fai riferimento a R.style).

3.8.7. Sfondi animati

Android definisce un tipo di componente, nonché l'API e il ciclo di vita corrispondenti, che consente alle applicazioni di esporre uno o più "sfondi animati" all'utente finale. Gli sfondi animati sono animazioni, motivi o immagini simili con capacità di input limitate che vengono visualizzate come sfondo dietro altre applicazioni.

L'hardware è considerato in grado di eseguire in modo affidabile sfondi animati se è in grado di eseguire tutti gli sfondi animati, senza limitazioni di funzionalità, a una frequenza fotogrammi ragionevole senza effetti negativi su altre applicazioni. Se limitazioni dell'hardware causano l'arresto anomalo degli sfondi e/o delle applicazioni, il malfunzionamento, un consumo eccessivo di CPU o batteria o l'esecuzione a frequenze fotogrammi eccessivamente basse, l'hardware viene considerato incapace di eseguire lo sfondo animato. Ad esempio, alcuni sfondi animati potrebbero utilizzare un contesto OpenGL 2.0 o 3.x per eseguire il rendering dei contenuti. L'esecuzione dello sfondo animato non viene eseguita in modo affidabile su hardware che non supportano diversi contesti OpenGL, perché l'utilizzo di sfondi animati di un contesto OpenGL potrebbe essere in conflitto con altre applicazioni che usano anch'essi un contesto OpenGL.

Le implementazioni del dispositivo in grado di eseguire gli sfondi animati in modo affidabile, come descritto in precedenza, DEVONO implementare gli sfondi animati e, se implementata, DEVONO segnalare la segnalazione della funzionalità della piattaforma: android.software.live_wallpaper.

3.8.8. Cambio attività

Poiché il tasto di navigazione della funzione Recenti è FACOLTATIVO, il requisito per implementare la schermata Panoramica è FACOLTATIVO per le implementazioni Android Watch e Android Automotive e CONSIGLIATO per i dispositivi Android Television. DEVE comunque essere disponibile un metodo per passare da un'attività all'altra sulle implementazioni di Android Automotive.

Il codice sorgente Android upstream include la schermata Panoramica, un'interfaccia utente a livello di sistema per il cambio delle attività 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 nel momento in cui l'utente ha abbandonato l'applicazione per l'ultima volta. Le implementazioni dei dispositivi, incluso il tasto di navigazione recente della funzione, come descritto nella sezione 7.2.3 POTREBBERO modificare l'interfaccia, ma DEVONO soddisfare i seguenti requisiti:

  • DEVE supportare almeno 6 attività visualizzate.
  • DEVE visualizzare almeno il titolo di 4 attività alla volta.
  • DEVE implementare il comportamento di blocco su schermo e fornire all'utente un menu di impostazioni per attivare/disattivare la funzionalità.
  • DOVREBBE visualizzare il colore di evidenziazione, l'icona e il titolo dello schermo nei recenti.
  • DEVONO mostrare un invito di chiusura ("x"), ma POTREBBE ritardarlo finché l'utente non interagisce con gli schermi.
  • DEVI implementare una scorciatoia per passare facilmente all'attività precedente
  • POTREBBE mostrare gli elementi 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à multi-finestra schermo diviso, se supportata, quando il tasto funzioni recenti viene premuto a lungo.

Alle implementazioni dei dispositivi è VIVAMENTE CONSIGLIATO di utilizzare l'interfaccia utente Android upstream (o un'interfaccia simile basata su miniature) per la schermata della panoramica.

3.8.9. Gestione degli input

Android include il supporto per Gestione del metodo di immissione e per editor dei metodi di immissione di terze parti. Le implementazioni dei dispositivi che consentono agli utenti di utilizzare metodi di immissione 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 dall'utente per aggiungere e configurare metodi di immissione di terze parti. Le implementazioni dei dispositivi DEVONO mostrare l'interfaccia delle impostazioni in risposta all'intento android.settings.INPUT_METHOD_SETTINGS.

3.8.10. Controllo contenuti multimediali schermata di blocco

L'API Remote Control Client è stata ritirata da Android 5.0 a favore del Media Notification Template, che consente l'integrazione delle applicazioni multimediali con i controlli di riproduzione visualizzati nella schermata di blocco. Le implementazioni dei dispositivi che supportano una schermata di blocco, a meno che non sia un'implementazione di Android Automotive o Watch, DEVONO mostrare le notifiche della schermata di blocco, incluso il modello di notifica multimediale.

3.8.11. Salvaschermi (in precedenza Sogni)

Android include il supporto dei salvaschermi interattivi, precedentemente chiamati Sogni. I salvaschermo consentono agli utenti di interagire con le applicazioni quando un dispositivo collegato a una fonte di alimentazione è inattivo o agganciato a una base di ricarica. I dispositivi Android Watch POSSONO implementare salvaschermo, ma altri tipi di implementazioni dispositivo DEVONO includere il supporto per questi salvaschermi e fornire un'opzione di impostazioni per consentire agli utenti di configurarli in risposta all'intento di 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 di posizione, le modalità di geolocalizzazione DEVONO essere visualizzate nel menu Posizione nelle Impostazioni.

3.8.13. Unicode e Font

Android supporta i caratteri emoji definiti in Unicode 9.0. Tutte le implementazioni sui dispositivi DEVONO essere in grado di visualizzare questi caratteri emoji in glifo a colori e, quando le implementazioni su dispositivi Android includono un IME, DEVE fornire all'utente un metodo di inserimento per questi caratteri emoji.

I dispositivi portatili Android DEVONO supportare la tonalità della pelle e le diverse emoji per la famiglia, come specificato nel Rapporto tecnico Unicode n. 51.

Android include il supporto del carattere Roboto 2 con pesi diversi - Sans- Serif-thin, Sans Serif-light, Sans Serif-medium, Sans Serif-Black, Sans Serif-condensed, Sans Serif-Condensed Light, che DEVE essere tutti inclusi per le lingue disponibili sul dispositivo e la copertura completa Unicode 7.0 di Latino, Greco e Cirillico

3.8.14. Multifinestre

Un'implementazione del dispositivo POTREBBE scegliere di non implementare alcuna modalità multi-finestra, ma se ha la capacità di visualizzare più attività contemporaneamente DEVE implementarle in base ai comportamenti dell'applicazione e alle API descritti nella documentazione di supporto per la modalità multi-finestra SDK per Android e soddisfare i seguenti requisiti:

  • Le applicazioni possono indicare se sono in grado di funzionare in modalità multi-finestra nel file AndroidManifest.xml, in modo esplicito tramite l'attributo android:resizeableActivity o in modo implicito impostando targetSdkVersion > 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 lanciate in modalità multi-finestra, ma il sistema DEVE fornire un avviso che informa che l'app potrebbe non funzionare come previsto in modalità multi-finestra.
  • Le implementazioni dei dispositivi NON DEVONO offrire la modalità schermo diviso o formato libero se l'altezza e la larghezza dello schermo sono inferiori a 440 dp.
  • Le implementazioni dei dispositivi con dimensioni dello schermo xlarge DEVONO supportare la modalità in formato libero.
  • Le implementazioni dei dispositivi Android Television DEVONO supportare la modalità multi-finestra Picture in picture (PIP) e posizionare la modalità multi-finestra PIP nell'angolo in alto a destra quando questa opzione è attiva.
  • Le implementazioni dei dispositivi con il supporto multi-finestra in modalità PIP DEVONO allocare almeno 240x135 dp per la finestra PIP.
  • Se la modalità multi-finestra PIP è supportata, il tasto KeyEvent.KEYCODE_WINDOW DEVE essere utilizzato per controllare la finestra PIP; altrimenti 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 dei dispositivi a livello di sistema, ad esempio l'applicazione di criteri relativi alle password o l'eliminazione da remoto, tramite l'API Android Device Administration. Le implementazioni dei dispositivi 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 dei dispositivi definiti nella documentazione dell'SDK Android e segnalare la funzionalità della piattaforma android.software.device_admin.

3.9.1 Provisioning dei dispositivi

3.9.1.1 Provisioning dei proprietari del dispositivo

Se l'implementazione di un dispositivo dichiara la funzionalità android.software.device_admin, DEVE implementare il provisioning dell'app proprietario del dispositivo di un'applicazione client Criteri dispositivi, come indicato di seguito:

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 del proprietario del dispositivo senza il consenso esplicito o l'azione da parte dell'utente o dell'amministratore del dispositivo.

3.9.1.2 Provisioning dei profili gestiti

Se l'implementazione di un dispositivo dichiara android.software.managed_users, DEVE essere possibile registrare un'applicazione controller dei criteri dei dispositivi come proprietario di un nuovo profilo gestito.

La procedura di provisioning del profilo gestito (il flusso avviato da android.app.action.PROVISION_MANAGED_PROFILE ) dev'essere in linea con l'implementazione di AOSP.

Le implementazioni dei dispositivi DEVONO fornire le seguenti autorizzazioni utente all'interno dell'interfaccia utente delle Impostazioni per indicare all'utente quando una determinata funzione di sistema è stata disattivata dal controller dei criteri dei dispositivi (DPC):

  • Un'icona coerente o un altro invito all'utente (ad esempio l'icona delle informazioni AOSP upstream) da rappresentare quando una determinata impostazione è limitata da un amministratore del dispositivo.
  • Un breve messaggio esplicativo fornito dall'amministratore del dispositivo tramite setShortSupportMessage.
  • L'icona dell'applicazione DPC (controller criteri dispositivi).

3.9.2 Supporto dei profili gestiti

I dispositivi che supportano i profili gestiti sono quelli che:

I dispositivi che supportano i profili gestiti DEVONO:

  • Dichiara il flag delle funzionalità della piattaforma android.software.managed_users .
  • Supporta i profili gestiti tramite le API di android.app.admin.DevicePolicyManager.
  • Consenti la creazione di un solo profilo gestito.
  • Utilizza un badge con icona (simile al badge di lavoro upstream di AOSP) per rappresentare le applicazioni e i widget gestiti e altri elementi UI con badge come Recenti e Notifiche.
  • Deve mostrare un'icona di notifica (simile al badge di lavoro upstream di AOSP) per indicare quando l'utente si trova all'interno di un'applicazione con profilo gestito.
  • Mostra un avviso popup che indica che l'utente è nel profilo gestito se e quando il dispositivo si attiva (ACTION_USER_PRESENT) e l'applicazione in primo piano si trova all'interno del profilo gestito.
  • Se esiste un profilo gestito, mostra un'invito 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 dei dispositivi.
  • Se esiste un profilo gestito, esponi le seguenti autorizzazioni utente sia per l'utente principale sia per il profilo gestito:
    • Account separati 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 all'interno dell'utente principale o del profilo gestito.
    • Gestione indipendente delle applicazioni installate nel profilo gestito o utente principale.
    • 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 cercare le informazioni sul chiamante nel profilo gestito (se presente) oltre a quelli nel profilo principale, se il controller dei criteri dei dispositivi lo consente. Quando i contatti del profilo gestito sono visualizzati nel registro chiamate preinstallato, nell'interfaccia utente in corso, nelle notifiche di chiamata in corso e persa, nei contatti e nelle app di 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 su cui sono attivi più utenti (consulta la sezione 9.5), anche se il profilo gestito non viene conteggiato come un altro utente oltre all'utente principale.
  • Supporta la possibilità di specificare una schermata di blocco separata che soddisfi i seguenti requisiti per concedere l'accesso alle app eseguite in un profilo gestito.
    • Le implementazioni dei dispositivi DEVONO rispettare l'intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrare un'interfaccia per configurare una credenziale separata nella schermata di blocco per il profilo gestito.
    • Le credenziali della schermata di blocco del profilo gestito DEVONO usare gli stessi meccanismi di archiviazione e gestione delle credenziali del profilo principale, come documentato sul sito del progetto open source Android.
    • I criteri relativi alle password del DPC DEVONO essere applicati solo alle credenziali della schermata di blocco del profilo gestito, a meno che non vengano richiamati l'istanza DevicePolicyManager restituita da getParentProfileInstance.

3.10. Accessibilità

Android fornisce un livello di accessibilità che aiuta gli utenti con disabilità a navigare più facilmente sui dispositivi. Inoltre, Android fornisce API delle piattaforme che consentono le implementazioni del servizio di accessibilità per ricevere callback per gli eventi dell'utente e del sistema e generare meccanismi di feedback alternativi, come sintesi vocale, feedback aptico e navigazione trackball/D-pad.

Le implementazioni dei dispositivi includono i seguenti requisiti:

  • Le implementazioni di Android Automotive DEVONO fornire un'implementazione del framework di accessibilità di Android coerente con l'implementazione predefinita di Android.
  • Le implementazioni dei dispositivi (escluso Android Automotive) DEVONO fornire un'implementazione del framework di accessibilità di Android coerente con l'implementazione predefinita di Android.
  • Le implementazioni dei dispositivi (escluso Android Automotive) DEVONO supportare le implementazioni di servizi di accessibilità di terze parti tramite le API android.accessibilityservice.
  • Le implementazioni dei dispositivi (escluso Android Automotive) DEVONO generare eventi di accessibilità e fornire questi eventi a tutte le implementazioni di AccessibilityService registrate, in modo coerente con l'implementazione predefinita di Android

  • Le implementazioni dei dispositivi (dispositivi Android Automotive e Android Watch senza output audio escluso) DEVONO fornire un meccanismo accessibile all'utente per attivare e disattivare i servizi di accessibilità e DEVONO visualizzare questa interfaccia in risposta all'intento android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

  • Le implementazioni su dispositivi Android con output audio sono VIVAMENTE CONSIGLIATE di fornire implementazioni di servizi di accessibilità sul dispositivo paragonabili o superiori alle funzionalità dei servizi di accessibilità TalkBack** e Switch Access (https://github.com/google/talkback).

  • I dispositivi Android Watch con output audio DEVONO fornire implementazioni sul dispositivo di un servizio di accessibilità simile o superiore al servizio di accessibilità TalkBack (https://github.com/google/talkback).
  • Le implementazioni dei dispositivi DEVONO fornire agli utenti un meccanismo nel flusso di configurazione predefinito per abilitare i servizi di accessibilità pertinenti, nonché opzioni per regolare le dimensioni del carattere, delle dimensioni di visualizzazione e dei gesti di ingrandimento.

** Per le lingue supportate dalla sintesi vocale.

Inoltre, tieni presente che se c'è un servizio di accessibilità precaricato, DEVE essere un'app {directBootAware} sensibile ad Avvio diretto se il dispositivo dispone di spazio di archiviazione criptato tramite crittografia basata su file (FBE).

3.11. Sintesi vocale

Android include API che consentono alle applicazioni di usare servizi di sintesi vocale 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 Android TTS.

Implementazioni di Android Automotive:

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

Tutte le altre implementazioni sui dispositivi:

  • DEVONO supportare le API del framework Android TTS e DOVREBBERO includere un motore TTS che supporti le lingue disponibili sul dispositivo. Tieni presente che il software open source Android upstream include un'implementazione completa del motore di sintesi vocale.
  • DEVE supportare l'installazione di motori di sintesi vocale di terze parti.
  • DEVE fornire un'interfaccia accessibile dall'utente che consenta agli utenti di selezionare un motore di sintesi vocale da utilizzare a livello di sistema.

3.12. Framework input TV

Il Android Television Input Framework (TIF) semplifica la distribuzione dei contenuti in diretta ai dispositivi Android TV. TIF fornisce un'API standard per creare moduli di input che controllano i dispositivi Android Television. Le implementazioni dei dispositivi Android Television DEVONO supportare il framework di input TV.

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

3.12.1. App TV

Qualsiasi implementazione su un dispositivo che dichiara il supporto per la 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 la funzionalità 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 basati su TIF di terze parti ( input di terze parti).
  • Le implementazioni dei dispositivi POTREBBERO offrire una separazione visiva tra input preinstallati basati su TIF (ingressi installati) e input di terze parti.
  • Le implementazioni dei dispositivi NON DEVONO mostrare gli input di terze parti a più di una singola azione di navigazione all'esterno dell'app TV (ovvero l'espansione di un elenco di input di terze parti dall'app TV).

3.12.1.1. Guida ai programmi elettronica

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

  • L'EPG DEVE visualizzare informazioni provenienti da tutti gli ingressi installati e di terze parti.
  • L'EPG MAGGIO può fornire una separazione visiva tra gli input installati e quelli di terze parti.
  • L'EPG è VIVAMENTE CONSIGLIATA per visualizzare gli ingressi installati e quelli di terze parti in modo uniforme. L'EPG NON DEVE mostrare gli input di terze parti a più di una singola azione di navigazione lontano dagli ingressi installati sull'EPG.
  • Al cambio di canale, le implementazioni del dispositivo DEVONO mostrare i dati EPG per il programma al momento 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 del dispositivo o dei dispositivi di input del dispositivo Android TV (ad esempio telecomando, applicazione per il telecomando o controller di gioco):

  • Cambio di canali TV
  • Apertura dell'EPG in corso...
  • Configurazione e ottimizzazione su input basati su TIF di terze parti
  • Apertura del menu Impostazioni in corso...

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

3.12.1.3. Collegamento app di ingresso TV

Le implementazioni dei dispositivi Android Television DEVONO supportare il collegamento delle app di ingresso TV, il che consente a tutti gli input di fornire link di attività dall'attività in corso a un'altra attività (ad esempio un link dalla programmazione live a contenuti correlati). L'app TV DEVE mostrare il collegamento all'app di ingresso TV quando viene fornita.

3.12.1.4. Time shifting

Le implementazioni dei dispositivi Android Television DEVONO supportare il timeshift, in modo che l'utente possa 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 è disponibile il cambio temporale per quel programma.

3.12.1.5. Registrazione TV

Le implementazioni dei dispositivi Android Television sono VIVAMENTE CONSIGLIATE per supportare la registrazione TV. Se l'ingresso TV supporta la registrazione, l'EPG POTREBBE fornire un modo per registrare un programma se la registrazione di tale programma non è vietata. Le implementazioni del dispositivo 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 di Impostazioni rapide che consenta di accedere rapidamente alle azioni utilizzate di frequente o urgenti.

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 delle Impostazioni rapide. Se l'implementazione di un dispositivo ha un componente UI Impostazioni rapide:

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

3.14. API UI veicoli

3.14.1. UI multimediale del veicolo

Qualsiasi implementazione su dispositivi che dichiara il supporto del settore automobilistico DEVE includere un framework dell'interfaccia utente per supportare app di terze parti che utilizzano le API MediaBrowser e MediaSession.

Il framework dell'interfaccia utente che supporta app di terze parti che dipendono da MediaBrowser e MediaSession prevede i seguenti requisiti visivi:

  • DEVE mostrare le icone di MediaItem e le icone di notifica inalterate.
  • DEVONO mostrare questi elementi come descritto da MediaSession, ad es. metadati, icone, immagini.
  • DEVE mostrare il titolo dell'app.
  • DEVE avere il riquadro a scomparsa per presentare la gerarchia di MediaBrowser.

4. Compatibilità con la confezione dell'applicazione

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

Il gestore di 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 bytecode .apk, file manifest Android, Dalvik bytecode o RenderScript in modo da impedire la corretta installazione e l'esecuzione di questi file su altri dispositivi compatibili.

5. Compatibilità multimediale

5.1. Codec multimediali

Implementazioni dei dispositivi:

  • DEVONO supportare i formati multimediali principali specificati nella documentazione dell'SDK per Android, tranne dove esplicitamente consentito in questo documento.

  • DEVE supportare i formati multimediali, i codificatori, i decoder, i tipi di file e i formati container definiti nelle tabelle riportate di seguito e riportati tramite MediaCodecList.

  • DEVE inoltre essere in grado di decodificare tutti i profili segnalati nel proprio CamcorderProfile

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

I codec DEVONO puntare a una latenza minima dei codec, ovvero i codec...

  • NON DEVE utilizzare e archiviare i buffer di input e restituirli solo una volta elaborati
  • NON DEVE conservare i buffer decodificati per un tempo superiore a quello specificato dallo standard (ad es. SPS).
  • NON DEVE conservare i buffer codificati per un tempo superiore a quello richiesto dalla struttura GOP.

Tutti i codec elencati nella tabella che segue sono forniti come implementazioni software nell'implementazione Android preferita dell'Android Open Source Project.

Tieni presente che né Google né l'Open Handset Alliance rilasciano alcuna dichiarazione secondo cui questi codec sono esenti da brevetti di terze parti. Coloro che intendono utilizzare questo codice sorgente in prodotti hardware o software sono informati che le implementazioni di questo codice, anche in software open source o shareware, potrebbero richiedere licenze di brevetto da parte dei rispettivi titolari dei brevetti.

5.1.1. Codec audio

Formato/Codec Codificatore Decodificatore Dettagli Tipi di file/formati container supportati
Profilo AAC MPEG-4
(LC AAC) 		OBBLIGATORIO1 OBBLIGATORIO Supporto di contenuti mono/stereo/5.0/5.12 con frequenze di campionamento standard da 8 a 48 kHz.
  • 3 GPP (0,3 gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC non elaborato 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 ricercabile, Android 3.0 e versioni successive)
Profilo MPEG-4 HE AAC (AAC+) OBBLIGATORIO 1
(Android 4.1 e versioni successive). 		OBBLIGATORIO Supporto di contenuti mono/stereo/5.0/5.12 con frequenze di campionamento standard da 16 a 48 kHz.
MPEG-4 HE AACv2
Profilo (AAC+ migliorato) 		OBBLIGATORIO Supporto di contenuti mono/stereo/5.0/5.12 con frequenze di campionamento standard da 16 a 48 kHz.
AAC ELD (AAC a basso ritardo migliorato) OBBLIGATORIO 1
(Android 4.1 e versioni successive). 		OBBLIGATORIO
(Android 4.1 e versioni successive). 		Supporto di contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.
AMR-NB OBBLIGATORIO3 OBBLIGATORIO3 Da 4,75 a 12,2 kbps campionati a 8 kHz 3 GPP (0,3 gp)
AMR-WB OBBLIGATORIO3 OBBLIGATORIO3 9 velocità da 6,60 kbit/s a 23,85 kbit/s campionati a 16 kHz
FLAC OBBLIGATORIO
(Android 3.1 e versioni successive). 		Mono/Stereo (no multicanale). Frequenze di campionamento fino a 48 kHz (ma fino a 44,1 kHz è CONSIGLIATA su dispositivi con uscita a 44,1 kHz, poiché il downsampler da 48 a 44,1 kHz non include un filtro passa-basso). 16 bit CONSIGLIATA; il dithering applicato per la versione a 24 bit. Solo FLAC (.flac)
MP3 OBBLIGATORIO Costante mono/stereo da 8-320 Kbps (CBR) o velocità in bit variabile (VBR) MP3 (.mp3)
MIDI OBBLIGATORIO MIDI Type 0 e 1. DLS versione 1 e 2. XMF e XMF mobile. Supporto per formati di suoneria RTTTL/RTX, OTA e iMelody
  • Tipo 0 e 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis OBBLIGATORIO
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0 e versioni successive)
PCM/WAVE OBBLIGATORIO 4
(Android 4.1 e versioni successive). 		OBBLIGATORIO PCM lineare a 16 bit (ratenze fino al limite dell'hardware). I dispositivi DEVONO supportare le frequenze di campionamento per la registrazione PCM non elaborata alle frequenze 8000, 11025, 16000 e 44100 Hz. onda (.wav)
Opus OBBLIGATORIO
(Android 5.0 e versioni successive). 		Matroska (.mkv), Ogg(.ogg)

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

2 La registrazione o la riproduzione POTREBBE essere effettuata in mono o stereo, ma la decodifica dei buffer di ingresso AAC degli stream multicanale (ossia più di due canali) in PCM tramite il decodificatore audio AAC predefinito nell'API android.media.MediaCodec, DEVE essere supportata quanto segue:

  • la decodifica viene eseguita senza downmixing (ad esempio, un flusso 5.0 AAC deve essere decodificato su cinque canali di PCM, un flusso 5.1 AAC deve essere decodificato su sei canali di PCM),
  • i metadati dell'intervallo dinamico, come definito in "Controllo intervallo dinamico (DRC)" conforme allo standard ISO/IEC 14496-3 e ai tasti DRC android.media.MediaFormat per configurare i comportamenti correlati 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 sui dispositivi portatili Android.

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

5.1.2. Codec immagine

Formato/Codec Codificatore Decodificatore Dettagli Tipi di file/formati container supportati
JPEG OBBLIGATORIO OBBLIGATORIO Base+progressivo 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 annuncia il supporto intra refresh, DEVE supportare i periodi di aggiornamento nell'intervallo 10-60 frame e funzionare accuratamente entro il 20% del periodo di aggiornamento configurato.

  • I codec video DEVONO supportare dimensioni bytebuffer di output e di input che ospitano il frame compresso e non compresso più grande fattibile, come dettato dallo standard e dalla configurazione, ma non complessivamente.

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

Formato/Codec Codificatore Decodificatore Dettagli Tipi di file supportati/
Formati container
H.263 MAG MAG
  • 3 GPP (0,3 gp)
  • MPEG-4 (.mp4)
AVC H.264 OBBLIGATORIO2 OBBLIGATORIO2 Per informazioni dettagliate, consulta le sezioni 5.2 e 5.3
  • 3 GPP (0,3 gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, solo audio AAC, non ricercabile, Android 3.0 e versioni successive)
HEVC H.265 OBBLIGATORIO 5 Per informazioni dettagliate, consulta la sezione 5.3. MPEG-4 (.mp4)
MPEG-2 VIVAMENTE CONSIGLIATO6 Profilo principale MPEG2-TS
MPEG-4 SP OBBLIGATORIO2 3 GPP (0,3 gp)
VP8 3 OBBLIGATORIO 2
(Android 4.3 e versioni successive). 		OBBLIGATORIO 2
(Android 2.3.3 e versioni successive). 		Per informazioni dettagliate, consulta le sezioni 5.2 e 5.3
  • WebM (.webm)
  • Matroska (.mkv, Android 4.0 e versioni successive) 4
VP9 OBBLIGATORIO 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 dei dispositivi che includono l'hardware della fotocamera e definiscono android.hardware.camera o android.hardware.camera.front.

2 Obbligatorio per le implementazioni sui dispositivi, ad eccezione degli smartwatch Android.

3 Per una qualità accettabile dei servizi di streaming video e videoconferenze, le implementazioni dei dispositivi DEVONO utilizzare un codec VP8 hardware che soddisfi i requisiti.

4 Le implementazioni del dispositivo DEVONO supportare la scrittura di file Matroska WebM.

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

6 Si applica solo alle implementazioni di dispositivi Android Television.

5.2. Codifica video

I codec video sono facoltativi per le implementazioni sui dispositivi Android Watch.

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

  • DEVE supportare la velocità in bit configurabile dinamicamente.
  • DEVONO supportare frequenze fotogrammi variabili, laddove il codificatore video DEVE determinare la durata istantanea dei fotogrammi in base ai timestamp dei buffer di input e allocare il proprio bucket di bit in base a quella durata di frame.

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

Tutti i codificatori video DEVONO raggiungere i seguenti target di velocità in bit in due finestre scorrevoli:

  • Non DEVE essere superiore a circa il 15% rispetto alla velocità in bit tra gli intervalli di intraframe (I-frame).
  • Non DEVE essere superiore a circa il 100% rispetto alla velocità in bit in una finestra scorrevole di 1 secondo.

5.2.1. H.263

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

5.2.2. H-264

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

  • DEVE supportare il livello 3 del profilo di riferimento.
    Tuttavia, il supporto per ASO (Ordine delle sezioni arbitrario), Ordine flessibile delle sezioni (FMO) e RS (sezioni ridondanti) è FACOLTATIVO. Inoltre, per mantenere la compatibilità con altri dispositivi Android, è CONSIGLIATO che ASO, FMO e RS non vengano utilizzati per il profilo di base dai codificatori.
  • DEVONO supportare i profili di codifica video SD (Standard Definition) riportati nella seguente tabella.
  • DEVE supportare il livello del profilo principale 4.
  • DEVONO supportare i profili di codifica video HD (alta definizione) come indicato nella tabella seguente.
  • Inoltre, per i dispositivi Android TV è VIVAMENTE CONSIGLIATO di codificare video HD 1080p a 30 fps.
SD (bassa qualità) SD (alta qualità) HD 720p 1 HD a 1080p1
Risoluzione video 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
Frequenza fotogrammi video 20 f/s 30 fps 30 fps 30 fps
Velocità in bit video 384 Kbps 2 Mbps 4 Mbps 10 Mbps

1 Se supportata dall'hardware, ma VIVAMENTE CONSIGLIATA per i televisori Android.

5.2.3. VP8

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

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

1 Se supportata dall'hardware.

5.3 Decodifica video

I codec video sono facoltativi per le implementazioni sui dispositivi Android Watch.

Implementazioni dei dispositivi:

  • DEVE supportare il cambio dinamico della risoluzione video e della frequenza fotogrammi 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 decoder Dolby Vision:

  • DEVE fornire un estrattore compatibile con Dolby Vision.

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

  • Le implementazioni che forniscono un estrattore compatibile con Dolby Vision DEVONO impostare l'indice della traccia degli strati di base compatibili con le versioni precedenti (se presenti) in modo che corrisponda all'indice della traccia dello strato Dolby Vision combinato.

5.3.1. MPEG-2

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

5.3.2. H.263

Le implementazioni dei dispositivi Android con decoder H.263 DEVONO supportare il livello 30 e il livello 45 del profilo di riferimento.

5.3.3. MPEG-4

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

5.3.4. H.264

Implementazioni di dispositivi Android con decoder H.264:

  • DEVE supportare il livello 3.1 del profilo principale e il profilo di base.
    Il supporto per 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 seguente tabella e codificati con il profilo di base e il livello del profilo principale 3.1 (inclusi 720p30).
  • DOVREBBE essere in grado di decodificare i video con i profili HD (alta definizione) come indicato nella tabella seguente.
  • Inoltre, i dispositivi Android Television,
    • DEVE supportare High Profile Level 4.2 e il profilo di decodifica HD 1080p60.
    • DEVE essere in grado di decodificare i video con entrambi i profili HD come indicato nella seguente tabella e codificati con il profilo di base, il profilo principale o il livello di alto profilo 4.2
SD (bassa qualità) SD (alta qualità) HD 720p 1 HD a 1080p1
Risoluzione video 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
Frequenza fotogrammi video 30 fps 30 fps 60 FPS 30 f/s (60 f/s2)
Velocità in bit video 800 kbps 2 Mbps 8 Mbps 20 Mbps

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

2 OBBLIGATORIO per le implementazioni dei dispositivi Android Television.

5.3.5. H.265 (HEVC)

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

  • DEVONO supportare il livello principale del profilo principale 3 e i profili di decodifica video SD come indicato nella tabella seguente.
  • DEVONO 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.
  • VIVAMENTE CONSIGLIATO per il supporto del profilo di decodifica HD 1080p. Se il profilo di decodifica HD 1080p è supportato, DEVE supportare il livello principale del livello 4.1 del profilo principale.
  • DOVREBBE supportare il profilo di decodifica UHD. Se il profilo di decodifica UHD è supportato, il codec DEVE supportare il profilo di livello principale Main10 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/s1) 60 FPS
Velocità in bit video 600 kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

1 OBBLIGATORIO per le implementazioni di dispositivi Android TV con decodifica hardware H.265.

5.3.6. VP8

Implementazioni di dispositivi Android, se supportati il codec VP8 come descritto nella sezione 5.1.3:

  • DEVE supportare i profili di decodifica SD nella tabella seguente.
  • DEVONO supportare i profili di decodifica HD 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 a 1080p1
Risoluzione video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Frequenza fotogrammi video 30 fps 30 fps 30 f/s (60 f/s2) 30 (60 f/s2)
Velocità in bit video 800 kbps 2 Mbps 8 Mbps 20 Mbps

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

2 OBBLIGATORIO per le implementazioni dei dispositivi Android Television.

5.3.7. VP9

Implementazioni di dispositivi Android, se supportati il codec VP9 come descritto nella sezione 5.1.3:

  • DEVE supportare i profili di decodifica video SD come indicato nella tabella seguente.
  • DEVONO 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.
    • VIVAMENTE CONSIGLIATO per il supporto del profilo di decodifica HD 1080p.
    • DOVREBBE supportare il profilo di decodifica UHD. Se il profilo di decodifica video UHD è supportato, DEVE supportare la profondità di colore a 8 bit e DEVE supportare VP9 Profilo 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/s1) 60 FPS
Velocità in bit video 600 kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

1 OBBLIGATORIO per le implementazioni di dispositivi Android Television con decodifica hardware VP9.

5.4. Registrazione audio

Mentre alcuni dei requisiti descritti in questa sezione sono indicati come DOVREBBE a partire da Android 4.3, si prevede che la definizione di compatibilità per una versione futura li modifichi in DEVE. I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare questi requisiti che sono indicati come DOVRESTI oppure non saranno in grado di raggiungere la compatibilità con Android dopo l'upgrade alla versione futura.

5.4.1. Acquisizione audio RAW

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

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

L'acquisizione delle frequenze di campionamento sopra indicate DEVE essere eseguita senza up-sampling e ogni down-sampling DEVE includere un filtro anti-aliasing appropriato.

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

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

Se l'acquisizione per le frequenze di campionamento sopra indicate è supportata, l'acquisizione DEVE essere eseguita senza upcampionamento a qualsiasi rapporto superiore a 16000:22050 o 44100:48000. Qualsiasi up-sampling o down-sampling 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 precedenti, quando un'applicazione ha iniziato a registrare uno stream audio utilizzando la sorgente audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

  • Il dispositivo DEVE presentare un'ampiezza approssimativamente piatta rispetto alle caratteristiche di frequenza: in particolare, ±3 dB, da 100 Hz a 4000 Hz.
  • La sensibilità dell'ingresso audio DEVE essere impostata in modo che una sorgente di livello di potenza sonora (SPL) a 90 dB a 1000 Hz produca RMS di 2500 per campioni a 16 bit.
  • I livelli di ampiezza del PCM DOVREBBERO che l'SPL di ingresso traccia in modo lineare cambi nel corso di almeno 30 dB, da -18 dB a +12 dB re 90 dB SPL al microfono.
  • La distorsione armonica totale DEVE essere inferiore all'1% per 1 kHz a 90 dB di livello di ingresso SPL al microfono.
  • L'elaborazione della riduzione del rumore, se presente, DEVE essere disattivata.
  • Il controllo automatico del guadagno, se presente, DEVE essere disattivato.

Se la piattaforma supporta tecnologie di eliminazione dei rumori 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 soppressore del rumore DEVE identificare in modo univoco ogni implementazione della tecnologia di eliminazione dei rumori.

5.4.3. Acquisisci per il reindirizzamento della riproduzione

La classe android.media.MediaRecorder.AudioSource include la sorgente audio REMOTE_SUBMIX. I dispositivi con la dichiarazione android.hardware.audio.output DEVONO implementare correttamente la sorgente audio REMOTE_SUBMIX, in modo che un'applicazione che utilizza l'API android.media.AudioRecord per registrare da questa sorgente audio possa acquisire un mix di tutti gli stream audio tranne i seguenti:

  • ANELLO_STREAM
  • ALARM_STREAM
  • NOTIFICA_STREAM

5.5. Riproduzione audio

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

5.5.1. Riproduzione audio RAW

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

  • Formato : PCM lineare, a 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 : 24.000, 48.000

5.5.2. Effetti audio

Android fornisce un'API per gli effetti audio per le implementazioni sui dispositivi. Implementazioni del dispositivo che dichiarano la funzionalità android.hardware.audio.output:

  • DEVE supportare le implementazioni Effetti_TYPE_EQUALIZER ed Effetti_TYPE_LOUDNESS_ENHANCER controllabili tramite le sottoclassi AudioEffect, Equalizer, LoudnessEnhancer.
  • DEVE supportare l'implementazione dell'API Visualizer, controllabile tramite la classe Visualizer.
  • DEVONO supportare le implementazioni Effetti_TYPE_BASS_BOOST, Effetti_TYPE_ENV_REVERB, Effetti_TYPE_PRESET_REVERB ed Effetti_TYPE_VIRTUALIZER controllabili tramite le sottoclassi AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.

5.5.3. Volume di uscita audio

Le implementazioni dei dispositivi Android Television DEVONO includere il supporto per il volume principale del sistema e l'attenuazione del volume dell'uscita audio digitale sulle uscite supportate, ad eccezione dell'uscita passthrough audio compresso (dove non viene effettuata alcuna decodifica audio sul dispositivo).

Le implementazioni dei dispositivi Android Automotive DEVONO 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 di un segnale audio che passa attraverso un sistema. Molte classi di applicazioni si basano su brevi latenze per ottenere effetti sonori in tempo reale.

Ai fini di questa sezione, utilizza le seguenti definizioni:

  • latenza di output . 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 nell'ambiente di un trasduttore o di un segnale sul dispositivo esce dal dispositivo tramite una porta e può essere osservato esternamente.
  • latenza di output a freddo . La latenza di output per il primo frame, quando il sistema di output audio è stato inattivo e si è spento prima della richiesta.
  • latenza di output continua . La latenza di output per i frame successivi, dopo che il dispositivo ha avviato la riproduzione dell'audio.
  • latenza dell'input . L'intervallo tra il momento in cui un suono viene presentato dall'ambiente al dispositivo su un trasduttore o il segnale sul dispositivo entra nel dispositivo tramite una porta e quando un'applicazione legge il frame corrispondente di dati codificati PCM.
  • input perso . La parte iniziale di un segnale di input che è inutilizzabile o non disponibile.
  • latenza input freddo . La somma del tempo di input perso e della latenza di input per il primo frame, quando il sistema di input audio è stato 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 output a freddo . La variabilità tra misurazioni separate dei valori di latenza dell'output a freddo.
  • jitter ingresso a freddo . La variabilità tra misurazioni separate dei valori di latenza dell'input a freddo.
  • latenza di round trip continua . La somma della latenza di input continuo più la latenza di output continuo più un periodo di buffer. Il periodo di buffer lascia all'app il tempo di elaborare il segnale e il tempo necessario per mitigare la differenza di fase tra gli stream di input e quelli di uscita.
  • API OpenSL ES PCM buffer Queue Il set di API OpenSL ES correlate a PCM in Android NDK.

Le implementazioni dei dispositivi che dichiarano la presenza di android.hardware.audio.output sono VIVAMENTE CONSIGLIATE di soddisfare o superare i seguenti requisiti di output audio:

  • latenza dell'output a freddo pari o inferiore a 100 millisecondi
  • latenza di output continua di 45 millisecondi o inferiore
  • riduci al minimo il jitter dell'output a freddo

Se l'implementazione di un dispositivo soddisfa i requisiti di questa sezione dopo una calibrazione iniziale quando si utilizza l'API OpenSL ES PCM buffer Queue, per la latenza continua dell'output e la latenza dell'output a freddo su almeno un dispositivo di output audio supportato, è VIVAMENTE CONSIGLIATO segnalare il supporto per l'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 per audio a bassa latenza.

Le implementazioni dei dispositivi che includono android.hardware.microphone sono VIVAMENTE CONSIGLIATE per soddisfare i seguenti requisiti per l'input audio:

  • latenza dell'input a freddo pari o inferiore a 100 millisecondi
  • latenza di input continua di 30 millisecondi o inferiore
  • latenza di round trip continua di 50 millisecondi o inferiore
  • riduci al minimo il tremolio dell'input a freddo

5.7. Protocolli di rete

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

Formati dei segmenti Riferimenti Supporto codec richiesto
Stream di trasporto MPEG-2 ISO 13818 Codec video:
  • AVC H264
  • MPEG-4 SP
  • MPEG-2
Consulta la sezione 5.1.3 per maggiori dettagli su H264 AVC, MPEG2-4 SP.
e MPEG-2.

Codec audio:

  • AAC
Consulta la sezione 5.1.1 per informazioni dettagliate su AAC e sulle sue varianti.
AAC con inquadratura ADTS e tag ID3 ISO 13818-7 Consulta la sezione 5.1.1 per i dettagli su AAC e sulle sue varianti
WebVTT WebVTT

  • RTSP (RTP, SDP)

    Il seguente profilo audio video RTP e i codec correlati DEVONO essere supportati. Per le eccezioni, consulta le note a piè di pagina nella tabella nella sezione 5.1.

Nome del profilo Riferimenti Supporto codec richiesto
AVC H264 RFC 6184 Consulta la sezione 5.1.3 per maggiori dettagli sugli AVC H264
MP4A-LATM RFC 6416 Consulta la sezione 5.1.1 per i dettagli su AAC e sulle sue varianti
H263-1998 RFC 3551
RFC 4629
RFC 2190 		Consulta la sezione 5.1.3 per maggiori dettagli su H263
263-2000 RFC 4629 Consulta la sezione 5.1.3 per maggiori dettagli su H263
Retrospettiva RFC 4867 Consulta la sezione 5.1.1 per i dettagli su AMR-NB
AMR-WB RFC 4867 Consulta la sezione 5.1.1 per informazioni dettagliate su AMR-WB
MP4V-ES RFC 6416 Consulta la sezione 5.1.3 per maggiori dettagli su MPEG-4 SP
mpeg4-generico RFC 3640 Consulta la sezione 5.1.1 per i dettagli su AAC e sulle sue varianti
MP2T RFC 2250 Per maggiori dettagli, consulta MPEG-2 Transport Stream sotto Live Streaming HTTP

5.8 Contenuti multimediali sicuri

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

5.9 MIDI (Musical Instrument Digital Interface)

Se un'implementazione del dispositivo supporta il trasporto del software MIDI tra app (dispositivi MIDI virtuali) e supporta il MIDI su tutti i seguenti trasporti hardware con funzionalità MIDI per i quali fornisce una connettività generica non MIDI, ti consigliamo VIVAMENTE di 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 con ruolo centrale (sezione 7.4.3 Bluetooth)

Al contrario, se l'implementazione del dispositivo fornisce una connettività generica non MIDI su un determinato trasporto hardware compatibile con MIDI elencato in precedenza, ma non supporta il MIDI su tale 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 requisiti che seguono, ti consigliamo VIVAMENTE di segnalare il supporto della funzionalità android.hardware.audio.pro tramite la classe android.content.pm.PackageManager.

  • L'implementazione del dispositivo DEVE segnalare il supporto per la funzionalità android.hardware.audio.low_latency.
  • La latenza audio di andata e ritorno continua, come definita nella sezione 5.6 Latenza audio, DEVE essere pari o inferiore a 20 millisecondi e DEVE 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 andata e ritorno continua DEVE essere di 20 millisecondi o meno sul percorso jack audio e DEVE essere di 10 millisecondi o meno a percorso 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 DEVE supportare l'uscita in stereo e otto canali a una profondità di 20 bit o 24 bit e a 192 kHz senza perdita o ricampionamento della profondità di bit.
  • 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, l'implementazione del dispositivo è VIVAMENTE CONSIGLIATA per rispettare la sezione Specifiche per i dispositivi mobili (jack) della Specifica delle cuffie audio con cavo (v1.1).

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

Inoltre, un'implementazione su dispositivo che segnala il supporto di questa funzione DOVREBBE:

  • Fornire un livello sostenibile di prestazioni della CPU quando l'audio è attivo.
  • Riduci al minimo le imprecisioni e la deviazione dell'orologio audio rispetto all'ora standard.
  • Riduci al minimo la deviazione dell'orologio audio rispetto alla CPU CLOCK_MONOTONIC quando entrambe sono attive.
  • Riduci al minimo la latenza audio sui trasduttori sul dispositivo.
  • Riduci al minimo la latenza audio tramite l'audio digitale USB.
  • Documenta le misurazioni della latenza audio in tutti i percorsi.
  • Riduci al minimo il tremolio nei tempi di ingresso del callback di completamento del buffer audio, poiché influisce sulla percentuale utilizzabile della larghezza di banda completa della CPU da parte del callback.
  • Non fornire valori inferiori (output) o sovraccarichi (input) audio in condizioni di normale utilizzo con la latenza segnalata.
  • Non fornire alcuna differenza 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 precisi su tutti i trasporti.
  • Riduci al minimo il rumore del segnale audio sui trasduttori sul dispositivo, incluso il periodo immediatamente dopo l'avvio a freddo.
  • Non fornisce alcuna differenza di orologio audio tra i lati di ingresso e di uscita degli endpoint corrispondenti, quando entrambi sono attivi. Esempi di endpoint corrispondenti includono il microfono e l'altoparlante 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 dei punti finali corrispondenti sullo stesso thread quando entrambi sono attivi e inserisci il callback di output subito dopo il ritorno dal callback di input. Oppure, se non è possibile gestire i callback sullo stesso thread, inserisci il callback di output subito dopo il callback di input per consentire all'applicazione di avere una tempistica coerente dei lati di input e di output.
  • Riduci al minimo la differenza di fase tra il buffering audio HAL per i lati di input e output dei endpoint corrispondenti.
  • Riduci al minimo la latenza al tocco.
  • Riduci al minimo la variabilità della latenza del tocco sotto carico (jitter).

5.11. Acquisisci per i dati non elaborati

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

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

  • Il dispositivo DEVE presentare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatta nella gamma di frequenza media: in particolare ± 10 dB da 100 Hz a 7000 Hz.

  • Il dispositivo DEVE presentare livelli di ampiezza nella gamma di frequenza bassa: in particolare da ±20 dB da 5 Hz a 100 Hz rispetto alla gamma di media frequenza.

  • Il dispositivo DEVE presentare livelli di ampiezza nella gamma delle alte frequenze: in particolare da ±30 dB da 7000 Hz a 22 KHz rispetto alla gamma di media frequenza.

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

  • SNR > 60 dB (differenza tra 94 dB SPL e SPL equivalente di autorumore, ponderato in base alla curva A).

  • La distorsione armonica totale DEVE essere inferiore all'1% per 1 kHZ a 90 dB SPL di ingresso del microfono.

  • L'unica elaborazione degli indicatori consentita nel percorso è un moltiplicatore di livelli per portare il livello all'intervallo desiderato. Questo moltiplicatore di livello NON DEVE introdurre ritardo o latenza nel percorso del segnale.

  • Nessun'altra elaborazione del segnale è consentita nel percorso, come il controllo automatico del guadagno, il filtro passa-alto o la cancellazione dell'eco. Se per qualsiasi motivo è presente un'elaborazione del segnale nell'architettura, DEVE essere disabilitata e effettivamente introdurre zero ritardo o latenza aggiuntiva nel percorso del segnale.

Tutte le misurazioni SPL vengono effettuate direttamente accanto al microfono sottoposto a test.

In caso di configurazioni multiple, questi requisiti si applicano a ogni microfono.

È VIVAMENTE CONSIGLIATO che un dispositivo soddisfi tutti i requisiti del percorso del segnale per la sorgente di registrazione non elaborata. tuttavia, un dispositivo deve soddisfare tutti i requisiti elencati sopra, se dichiara di supportare la sorgente audio non elaborata.

6. Compatibilità degli strumenti e delle opzioni per sviluppatori

6.1 Strumenti per sviluppatori

Le implementazioni dei dispositivi DEVONO supportare gli Strumenti per sviluppatori Android forniti nell'SDK Android. I dispositivi compatibili con Android DEVONO essere compatibili con:

  • Android Debug Bridge (adb)
    • Le implementazioni dei dispositivi DEVONO supportare tutte le funzioni adb come documentato nell'SDK per Android, compreso dumpsys.
    • Il daemon adb lato dispositivo DEVE essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile dall'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 (come Ethernet o 802.11).
    • Android include il supporto dell'ADB sicuro. Secure adb abilita adb su host autenticati noti. Le implementazioni dei dispositivi DEVONO supportare l'ADB sicuro.
  • Dalvik Debug Monitor (DDMS)
    • Le implementazioni dei dispositivi DEVONO supportare tutte le funzionalità DDMS come documentato nell'SDK Android.
    • Poiché ddms utilizza adb, il supporto per ddms DEVE essere inattivo per impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato Android Debug Bridge, come indicato sopra.
  • Monkey Le implementazioni del dispositivo DEVONO includere il framework Monkey e renderlo disponibile per l'utilizzo da parte delle applicazioni.
  • SysTrace
    • Le implementazioni del dispositivo DEVONO supportare lo strumento systrace come documentato nell'SDK per Android. Systrace deve essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile dall'utente per attivarlo.
    • La maggior parte dei sistemi basati su Linux e dei sistemi Apple Macintosh riconosce i dispositivi Android utilizzando gli strumenti SDK Android standard, senza ulteriore supporto. tuttavia, i sistemi Microsoft Windows in genere richiedono un driver per i nuovi dispositivi Android. Ad esempio, i nuovi ID fornitore e talvolta i nuovi ID dispositivo richiedono driver USB personalizzati per i sistemi Windows.
    • Se lo strumento adb non riconosce l'implementazione di un dispositivo come previsto dall'SDK Android standard, gli implementatori del dispositivo DEVONO fornire driver di Windows che consentano 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 nelle versioni a 32 e 64 bit.

6.2. Opzioni sviluppatore

Android include il supporto per gli sviluppatori per la configurazione delle impostazioni relative allo sviluppo di applicazioni. Le implementazioni dei dispositivi DEVONO rispettare l'intento android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo di applicazioni L'implementazione Android upstream nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avviare Opzioni sviluppatore dopo aver premuto sette (7) volte in Impostazioni > Informazioni sul dispositivo > Voce di menu Numero build. Le implementazioni dei dispositivi DEVONO fornire un'esperienza coerente per le Opzioni sviluppatore. In particolare, le implementazioni dei dispositivi DEVONO nascondere le Opzioni sviluppatore per impostazione predefinita e DEVONO fornire un meccanismo per abilitare le Opzioni sviluppatore in modo coerente con l'implementazione upstream di Android.

Le implementazioni di Android Automotive POTREBBERO limitare l'accesso al menu Opzioni sviluppatore nascondendo o disattivando visivamente il menu quando il veicolo è in movimento.

7. Compatibilità hardware

Se un dispositivo include un particolare componente hardware con un'API corrispondente per sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare tale API come descritto nella documentazione dell'SDK Android. Se un'API nell'SDK interagisce con un componente hardware che è stato dichiarato facoltativo e l'implementazione sul dispositivo non possiede questo componente:

  • Le definizioni complete delle classi (come documentate dall'SDK) per le API del componente DEVONO essere comunque presentate.
  • I comportamenti dell'API DEVONO essere implementati come operativi in modo autonomo e in modo ragionevole.
  • I metodi API DEVONO restituire valori nulli ove consentito dalla documentazione dell'SDK.
  • I metodi API DEVONO restituire implementazioni no-op per 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 scenario in cui si applicano questi requisiti è l'API per la telefonia: anche sui dispositivi diversi dagli smartphone, queste API devono essere implementate in modo ragionevole.

Le implementazioni dei dispositivi DEVONO segnalare in modo coerente informazioni accurate sulla configurazione hardware tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) nella classe android.content.pm.PackageManager per la stessa fingerprint della build.

7.1 Display e grafica

Android include funzionalità che regolano automaticamente gli asset delle applicazioni e i layout dell'interfaccia utente in modo appropriato in base al dispositivo per garantire che le applicazioni di terze parti funzionino correttamente su diverse configurazioni hardware. I dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in dettaglio in questa sezione.

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

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

7.1.1. Configurazione schermata

7.1.1.1. Dimensioni schermo

I dispositivi Android Watch (dettagli nella sezione 2) POTREBBERO avere schermi di dimensioni inferiori, come descritto in questa sezione.

Il framework della UI di Android supporta una serie di dimensioni dello schermo diverse e consente alle applicazioni di eseguire query sulle dimensioni dello schermo del dispositivo (noto anche come "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 definito nella documentazione dell'SDK Android e determinato dalla piattaforma Android upstream. In particolare, le implementazioni dei dispositivi DEVONO indicare le dimensioni dello schermo corrette in base alle seguenti dimensioni dello schermo in pixel indipendenti dalla densità logica (dp).

  • I dispositivi DEVONO avere dimensioni dello schermo di almeno 426 dp x 320 dp ("piccolo"), a meno che non si tratti di dispositivi 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 con schermo di dimensioni "xlarge" DEVONO avere dimensioni dello schermo di almeno 960 dp x 720 dp.

Inoltre:

  • I dispositivi Android Watch DEVONO avere uno schermo con una diagonale fisica compresa tra 1,1 e 2,5 pollici.
  • I dispositivi Android Automotive DEVONO avere uno schermo con diagonale fisica maggiore o uguale a 6 pollici.
  • I dispositivi Android Automotive DEVONO avere dimensioni dello schermo di almeno 750 dp x 480 dp.
  • Altri tipi di implementazioni di dispositivi Android, con uno schermo fisicamente integrato, DEVONO avere uno schermo di almeno 2,5 pollici di diagonale fisico.

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

Le applicazioni facoltativamente indicano le dimensioni dello schermo supportate tramite <supports-screen> nel file AndroidManifest.xml. Le implementazioni dei dispositivi DEVONO rispettare correttamente le applicazioni dichiarava il supporto di schermi piccoli, normali, grandi e xlarge, come descritto nella documentazione dell'SDK Android.

7.1.1.2. Proporzioni dello schermo

Sebbene non vi siano limitazioni al valore delle proporzioni dello schermo fisico, le proporzioni della piattaforma su cui vengono visualizzate le app di terze parti e che possono essere ricavate dai valori segnalati tramite DisplayMetrics DEVONO soddisfare i seguenti requisiti:

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

7.1.1.3. Densità schermo

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

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

Le implementazioni dei dispositivi DEVONO definire la densità del framework Android standard numericamente più vicina alla densità fisica dello schermo, a meno che questa densità logica non spinga le dimensioni dello schermo riportate al di sotto del minimo supportato. Se la densità del framework Android standard numericamente più vicina alla densità fisica risulta in una dimensione dello schermo inferiore a quella minima supportata dello schermo compatibile (320 dp di larghezza), le implementazioni dei dispositivi DEVONO segnalare la densità del framework Android standard più bassa successiva.

Le implementazioni nei dispositivi sono VIVAMENTE CONSIGLIATE di fornire agli utenti un'impostazione per modificare le dimensioni di visualizzazione. Se esiste un'implementazione per modificare le dimensioni di visualizzazione del dispositivo, DEVE essere in linea con l'implementazione AOSP come indicato di seguito:

  • Le dimensioni di visualizzazione NON DEVONO essere ridimensionate di più di 1,5 volte la densità nativa, né produrre una dimensione minima effettiva dello schermo inferiore a 320 dp (equivalente al qualificatore risorsa sw320dp), a seconda dell'evento che si verifica per primo.
  • Le dimensioni di visualizzazione NON DEVONO essere ridimensionate meno di 0,85 volte la densità nativa.
  • Per garantire una buona usabilità e dimensioni dei caratteri coerenti, consigliamo di fornire le seguenti opzioni di ridimensionamento degli annunci nativi (nel rispetto dei limiti specificati sopra)
  • Piccola: 0,85x
  • Valore predefinito: 1x (scala display nativa)
  • Grande: 1,15x
  • Più grande: 1,3x
  • Il più grande 1,45x

7.1.2. Metriche di visualizzazione

Le implementazioni dei dispositivi DEVONO riportare i valori corretti per tutte le metriche di visualizzazione definite in android.util.DisplayMetrics e DEVONO riportare gli stessi valori a prescindere dal fatto che lo schermo incorporato o esterno venga utilizzato come visualizzazione predefinita.

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 schermo orizzontale con orientamento fisso, come un televisore o un laptop, DOVREBBE indicare solo android.hardware.screen.landscape.

I dispositivi che segnalano entrambi gli orientamenti dello schermo DEVONO supportare l'orientamento dinamico delle applicazioni con l'orientamento verticale o orizzontale dello schermo. Ciò significa che il dispositivo deve rispettare la richiesta dell'applicazione relativa a un orientamento dello schermo specifico. Le implementazioni dei dispositivi POSSONO selezionare l'orientamento verticale o orizzontale come impostazione predefinita.

I dispositivi DEVONO segnalare il valore corretto per l'orientamento corrente del dispositivo, ogni volta che viene eseguita 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 segnalate quando cambiano l'orientamento.

7.1.4. Accelerazione delle schede grafiche 2D e 3D

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

Inoltre, le implementazioni dei dispositivi DEVONO identificarsi correttamente come che supportano OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0, OpenGL 3.1 o OpenGL 3.2. Vale a dire:

  • Le API gestite (ad esempio tramite il metodo GLES10.getString()) DEVONO segnalare il supporto per OpenGL ES 1.0 e OpenGL ES 2.0.
  • Le API OpenGL native C/C++ (API disponibili per le app tramite libGLES_v1CM.so, libGLES_v2.so o libEGL.so) DEVONO segnalare il supporto per OpenGL ES 1.0 e OpenGL ES 2.0.
  • Le implementazioni dei dispositivi che dichiarano il supporto per 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. Sul dispositivo implementazioni che dichiarano il supporto per 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 tassellazione e il formato di compressione delle texture ASTC. Le implementazioni sui dispositivi Android DEVONO supportare il pacchetto di estensioni, se il dispositivo supporta OpenGL ES 3.2 e POTREBBE supportarlo in altro modo. 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 riportare tramite le API native e gestite OpenGL ES tutte le stringhe di estensioni supportate e, viceversa, NON DEVONO riportare le stringhe di estensioni non supportate.

Tieni presente che Android supporta le applicazioni che consentono facoltativamente di specificare che richiedono formati di compressione della texture OpenGL specifici. Questi formati sono in genere specifici del fornitore. Android non richiede le implementazioni dei dispositivi per implementare alcun formato specifico di compressione delle texture. Tuttavia, DEVONO segnalare con precisione tutti i formati di compressione delle texture supportati, tramite il metodo getString() nell'API OpenGL.

Android include un meccanismo che consente alle applicazioni di dichiarare l'intenzione di attivare l'accelerazione hardware per la grafica 2D a livello di applicazione, attività, finestra o vista 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 richiesto dallo sviluppatore impostando android:hardwareAccelerated="false" o disattivando l'accelerazione hardware direttamente tramite le API Android View.

Inoltre, le implementazioni dei dispositivi DEVONO presentare un comportamento coerente con la documentazione relativa all'SDK per Android sull'accelerazione hardware.

Android include un oggetto TextureView che consente agli sviluppatori di integrare direttamente trame 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 presentare un comportamento coerente con l'implementazione Android upstream.

Android include il supporto per EGL_ANDROID_RECORDABLE, un attributo EGLConfig che indica se EGLConfig supporta il rendering in un A NativeWindow che registra le immagini in un video. Le implementazioni dei dispositivi DEVONO supportare l'estensione EGL_ANDROID_RECORDABLE.

7.1.5. Modalità di compatibilità delle applicazioni legacy

Android specifica una "modalità di compatibilità" in cui il framework funziona in modo "normale" modalità equivalente a dimensioni dello schermo (larghezza di 320 dp) a vantaggio delle applicazioni legacy non sviluppate per le versioni precedenti di Android antecedenti all'indipendenza delle dimensioni dello schermo.

  • Android Automotive non supporta la modalità di compatibilità precedente.
  • Tutte le altre implementazioni sui dispositivi DEVONO includere il supporto per la modalità di compatibilità delle applicazioni legacy come implementata dal codice open source di Android upstream. In altre parole, le implementazioni dei dispositivi NON DEVONO alterare gli attivatori o le soglie ai quali viene attivata la modalità di compatibilità e NON DEVONO alterare il comportamento della modalità 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 definito dall'SDK Android, a meno che non siano specificamente consentiti in questo documento.

  • I dispositivi DEVONO supportare display in grado di eseguire il rendering di grafica a colori a 16 bit e DEVONO supportare display in grado di supportare grafica a colori a 24 bit.
  • I dispositivi DEVONO supportare display in grado di visualizzare animazioni.
  • La tecnologia di visualizzazione utilizzata DEVE avere proporzioni pixel (PAR) comprese 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 del display secondario per attivare le funzionalità di condivisione dei contenuti multimediali e delle API per gli sviluppatori per l'accesso a display esterni. Se un dispositivo supporta un display esterno tramite una connessione display cablata, wireless o incorporata, 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 nella sezione 7.2.2 per la navigazione non touch.

7.2.1. Tastiera

Le implementazioni su Android Watch e Android Automotive POTREBBERO implementare una tastiera virtuale. Tutte le altre implementazioni del dispositivo DEVONO implementare una tastiera software e:

Implementazioni dei dispositivi:

  • DEVE includere il supporto per il framework di gestione dell'input (che consente agli sviluppatori di terze parti di creare editor del metodo di input, ovvero tastiere software), come descritto all'indirizzo http://developer.android.com.
  • DEVE fornire almeno un'implementazione di tastiera software (indipendentemente dal fatto che sia presente una tastiera rigida), ad eccezione degli smartwatch Android in cui le dimensioni dello schermo rendono meno ragionevole l'utilizzo di una tastiera software.
  • POTREBBERO includere ulteriori implementazioni di tastiere software.
  • 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 a 12 tasti).

7.2.2. Navigazione non touch

I dispositivi Android Television DEVONO supportare il D-pad.

Implementazioni dei dispositivi:

  • POTREBBE omettere un'opzione di navigazione non touch (trackball, D-pad o wheel) se l'implementazione del dispositivo non è un dispositivo Android TV.
  • DEVE segnalare il valore corretto per android.content.res.Configuration.navigation.
  • DEVE fornire un meccanismo di interfaccia utente ragionevole e alternativo per la selezione e la modifica del testo, compatibile con i motori di gestione degli input. L'implementazione open source di Android upstream include un meccanismo di selezione adatto all'uso con dispositivi privi di input di navigazione non touch.

7.2.3. Tasti di navigazione

I requisiti di disponibilità e visibilità delle funzioni Home, Recenti e Indietro variano in base al tipo di dispositivo, come descritto in questa sezione.

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

  • Le implementazioni dei dispositivi portatili Android DEVONO fornire le funzioni Home, Recenti e Indietro.
  • Le implementazioni dei dispositivi Android Television DEVONO fornire le funzioni Home e Indietro.
  • Le implementazioni sui 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 dispositivi Android POSSONO utilizzare l'evento di pressione prolungata sull'evento chiave KEYCODE_BACK e ometterlo dall'invio all'applicazione in primo piano.
  • Le implementazioni di Android Automotive DEVONO fornire la funzione Home e POTREBBERO fornire le funzioni Indietro e Recenti.
  • Tutti gli altri tipi di implementazioni sui dispositivi DEVONO fornire le funzioni Home e Indietro.

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

La funzione Recenti, se disponibile, DEVE avere un pulsante o un'icona visibile, a meno che non siano nascosti insieme ad altre funzioni di navigazione in modalità a schermo intero. Questo non vale per i dispositivi che eseguono l'upgrade da versioni precedenti di Android, che dispongono di pulsanti fisici per la navigazione e nessuna chiave recente.

Le funzioni Home e Indietro, se presenti, DEVONO avere un pulsante o un'icona visibile, 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 azioni da Android 4.0. Pertanto, le nuove implementazioni dei dispositivi con Android 7.0 e versioni successive NON DEVONO implementare un pulsante fisico dedicato per la funzione Menu. Le implementazioni meno recenti dei dispositivi NON DEVONO implementare un pulsante fisico dedicato per la funzione Menu, ma se il pulsante fisico è implementato e sul dispositivo sono in esecuzione applicazioni con targetSdkVersion > 10, l'implementazione del dispositivo:

  • DEVE visualizzare il pulsante di overflow dell'azione sulla barra delle azioni quando è visibile e il popup del menu extra dell'azione risultante non è vuoto. È CONSIGLIATO per un'implementazione del dispositivo lanciata prima di Android 4.4 ma in fase di upgrade ad Android 7.0.
  • NON DEVE modificare la posizione del popup di overflow dell'azione visualizzato selezionando il pulsante di overflow nella barra delle azioni.
  • POTREBBE visualizzare il popup di overflow dell'azione in una posizione modificata sullo schermo quando viene visualizzato selezionando il pulsante fisico del menu.

Per garantire la compatibilità con le versioni precedenti, le implementazioni dei dispositivi DEVONO rendere disponibile la funzione Menu alle applicazioni quando il valore targetSdkVersion è inferiore a 10, tramite un pulsante fisico, una chiave software o gesti. Questa funzione di menu dovrebbe essere presentata 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 poter avviare un'app di assistenza con una singola interazione (ad esempio tocco, doppio clic o gesto) quando sono visibili altri tasti di navigazione. Ti consigliamo VIVAMENTE di usare la pressione prolungata sulla schermata Home come interazione. L'interazione designata DEVE avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService, oppure 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 caso affermativo, DEVONO soddisfare i seguenti requisiti:

  • I tasti di navigazione dell'implementazione del dispositivo DEVONO utilizzare una parte distinta dello schermo, non disponibile per le applicazioni, e NON DEVONO oscurare 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à UI di sistema o specifica SYSTEM_UI_FLAG_VISIBLE.
  • Le implementazioni dei dispositivi DEVONO presentare i tasti di navigazione in una modalità non invadente a "basso profilo" (ad es. attenuata) quando le applicazioni specificano SYSTEM_UI_FLAG_LOW_PROFILE.
  • Le implementazioni del dispositivo DEVONO nascondere i tasti di navigazione quando le applicazioni specificano SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Ingresso touchscreen

I dispositivi portatili e gli smartwatch Android DEVONO supportare l'input touchscreen.

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

  • DEVONO supportare puntatori tracciati in modo completamente indipendente, se il sistema di input del dispositivo supporta più puntatori.
  • DEVE indicare il valore di android.content.res.Configuration.touchscreen corrispondente al tipo di touchscreen specifico sul dispositivo.

Android include il supporto di una vasta gamma di touchscreen, touchpad e dispositivi di input tocco falsi. Le implementazioni dei dispositivi basate 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 ulteriori inviti per indicare gli oggetti manipolati. Al contrario, un'interfaccia touch fittizia fornisce un sistema di input dell'utente che si avvicina a un sottoinsieme di funzionalità touchscreen. Ad esempio, un mouse o un telecomando che aziona il cursore sullo schermo è simile al tocco, ma richiede all'utente di puntare o mettere a fuoco e poi fare clic. Numerosi dispositivi di input come mouse, trackpad, air mouse basato su giroscopio, giroscopio, joystick e trackpad multi-touch possono supportare interazioni false con il tocco. Android include la funzionalità costante android.hardware.faketouch, che corrisponde a un dispositivo di input non touch (basato su puntatore) ad alta fedeltà, come un mouse o un trackpad, in grado di emulare in modo adeguato l'input basato sul tocco (incluso il supporto tramite gesti di base), e indica che il dispositivo supporta un sottoinsieme emulato di funzionalità touchscreen. Le implementazioni dei dispositivi che dichiarano la funzionalità di tocco simulato DEVONO soddisfare i requisiti relativi al tocco fittizio di cui alla sezione 7.2.5.

Le implementazioni dei dispositivi DEVONO segnalare la funzione corretta corrispondente al tipo di input utilizzato. Le implementazioni dei dispositivi che includono un touchscreen (singolo tocco o migliore) DEVONO segnalare la funzionalità della piattaforma costante android.hardware.touchscreen. Le implementazioni dei dispositivi che indicano 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 che si basano solo su un dispositivo di puntamento) NON DEVONO segnalare alcuna funzionalità touchscreen e DEVONO segnalare soltanto android.hardware.faketouch se soddisfano i requisiti relativi al tocco fittizio di cui alla sezione 7.2.5.

7.2.5. Input tocco fittizio

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

  • DEVE indicare le posizioni assolute nello schermo X e Y della posizione del puntatore e visualizzare un puntatore visivo sullo schermo.
  • DEVE segnalare l'evento touch con il codice di azione che specifica il cambiamento di stato che si verifica sul puntatore verso il basso o verso l'alto sullo schermo.
  • DEVE supportare il puntatore verso il basso e verso l'alto su un oggetto sullo schermo, il che consente agli utenti di emulare il tocco su un oggetto sullo schermo.
  • DEVONO supportare i puntatori verso il basso, verso l'alto, verso il basso e poi verso l'alto nella stessa posizione di un oggetto dello schermo entro una soglia di tempo, il che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo.
  • DEVE supportare il puntatore verso il basso in un punto arbitrario dello schermo, il puntatore si sposta in qualsiasi altro punto arbitrario sullo schermo, seguito da un puntatore verso l'alto, che consente agli utenti di emulare un trascinamento al tocco.
  • DEVE supportare il puntatore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in una posizione diversa sullo schermo e poi puntare in alto sullo schermo, consentendo agli utenti di far scorrere un oggetto sullo schermo.

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

7.2.6. Supporto del controller di gioco

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

7.2.6.1. Mappature pulsanti

Le implementazioni dei dispositivi Android Television DEVONO supportare le seguenti mappature dei tasti:

Pulsante Utilizzo HID2 Pulsante Android
R 1 0x09 0x0001 KEYCODE_PULSANTE_A (96)
B 1 0x09 0x0002 KEYCODE_PULSANTE_B (97)
X 1 0x09 0x0004 KEYCODE_PULSANTE_X (99)
A 1 0x09 0x0005 KEYCODE_PULSANTE_Y (100)
D-pad in alto 1
D-pad in basso 1 		0x01 0x0039 3 AXIS_HAT_Y 4
D-pad sinistro 1
D-pad destro 1 		0x01 0x0039 3 AXIS_HAT_X 4
Pulsante sulla spalla sinistra 1 0x09 0x0007 KEYCODE_PULSANTE_L1 (102)
Pulsante sulla spalla destra 1 0x09 0x0008 KEYCODE_PULSANTE_R1 (103)
Clic sulla levetta sinistra 1 0x09 0x000E KEYCODE_button_THUMBL (106)
Clic sulla levetta destra 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 dell'HID di cui sopra devono essere dichiarati all'interno di un Gamepad CA (0x01 0x0005).

3 Questo utilizzo deve avere un minimo logico di 0, un massimo logico di 7, un minimo fisico di 0, un massimo fisico di 315, le unità in gradi e una dimensione del report di 4. Il valore logico è la rotazione in senso orario rispetto all'asse verticale; ad esempio, un valore logico di 0 rappresenta l'assenza di rotazione e il pulsante su viene premuto, mentre un valore logico di 1 rappresenta una rotazione di 45 gradi e vengono premuti sia i tasti su sia quelli a sinistra.

4 MotionEvent

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

1 MotionEvent

7.2.7. Telecomando

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

7.3. Sensori

Android include API per accedere a diversi tipi di sensori. Le implementazioni dei dispositivi POSSONO in genere omettere questi sensori, come previsto nelle sottosezioni che seguono. Se un dispositivo include un determinato tipo di sensore con un'API corrispondente per sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare tale API come descritto nella documentazione relativa all'SDK Android e nella documentazione open source di Android 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 dei sensori (ad esempio, restituendo true o false come appropriato quando le applicazioni tentano di registrare i listener, non chiamando i listener dei sensori quando i sensori corrispondenti non sono presenti e così via).
  • DEVE segnalare tutte le misurazioni dei sensori utilizzando i valori del sistema internazionale di unità di misura (metrica) pertinenti per ciascun tipo di sensore, come definito nella documentazione dell'SDK per Android.
  • DEVE segnalare l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta l'ora in cui si è verificato l'evento e la sincronizzazione con l'orologio SystemClock.elapsedRealtimeNano(). I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare questi requisiti, in modo che possano eseguire l'upgrade alle future release della piattaforma dove questo potrebbe diventare un componente OBBLIGATORIO. L'errore di sincronizzazione DEVE essere inferiore a 100 millisecondi.
  • DEVE riportare i dati dei sensori con una latenza massima di 100 millisecondi + 2 * sample_time per il caso di un sensore in streaming con una latenza minima richiesta di 5 ms + 2 * sample_time quando il processore dell'applicazione è attivo. Questo ritardo non include eventuali ritardi dei filtri.
  • DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time del sensore da attivare. È accettabile che questo campione abbia un'accuratezza pari a 0.

L'elenco riportato sopra non è esaustivo. il comportamento documentato dell'SDK Android e della documentazione open source di Android sui sensori deve essere considerato autorevole.

Alcuni tipi di sensori sono composti, ovvero 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 DEVONO implementare questi tipi di sensori, se includono i prerequisiti fisici dei sensori, come descritto nella sezione Tipi di sensori. Se l'implementazione di un dispositivo include un sensore composito, DEVE implementarlo come descritto nella documentazione open source di Android sui sensori composti.

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

Tieni presente che le implementazioni del dispositivo DEVONO garantire che il flusso di eventi del sensore NON DEVI impedire alla CPU del dispositivo di entrare in stato di sospensione o di riattivarsi da questo stato.

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

7.3.1. Accelerometro

Le implementazioni del dispositivo DEVONO includere un accelerometro a 3 assi. I dispositivi portatili Android, le implementazioni di Android Automotive e gli smartwatch Android sono VIVAMENTE CONSIGLIATI di includere questo sensore. Se l'implementazione di un dispositivo include un accelerometro a 3 assi:

  • DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER.
  • DEVE essere in grado di segnalare eventi con una frequenza di almeno 50 Hz per i dispositivi Android Watch, in quanto questi dispositivi hanno un vincolo di alimentazione più rigido e 100 Hz per tutti gli altri tipi di dispositivi.
  • DEVI segnalare eventi fino ad almeno 200 Hz.
  • DEVE essere conforme al sistema di coordinate dei sensori Android come descritto nelle API di Android. Le implementazioni di Android Automotive DEVONO essere conformi al sistema di coordinate dei sensori per auto Android.
  • DEVE essere in grado di misurare dalla caduta libera fino a quattro volte la gravità (4 g) o più su qualsiasi asse.
  • DEVE avere una risoluzione di almeno 12 bit e DEVE avere una risoluzione di almeno 16 bit.
  • DEVE essere calibrata durante l'uso se le caratteristiche cambiano nel corso del ciclo di vita e vengono compensate, oltre a preservare i parametri di compensazione tra i riavvii del dispositivo.
  • DEVONO essere compensati in base alla temperatura.
  • DEVE avere una deviazione standard non superiore a 0,05 m/s^, laddove la deviazione standard deve essere calcolata per asse su campioni raccolti in un periodo di almeno 3 secondi alla frequenza di campionamento più elevata.
  • DEVI implementare i sensori composti TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento relativo all'SDK Android. I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE di 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 condizioni dinamiche o statiche.
  • Se è incluso un sensore giroscopio, DEVE implementare i sensori composito TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION e DEVE implementare il sensore composito TYPE_GAME_ROTATION_VECTOR. Sui dispositivi Android nuovi ed esistenti è VIVAMENTE CONSIGLIATO di implementare il sensore TYPE_GAME_ROTATION_VECTOR.
  • DEVE implementare un sensore composito TYPE_ROTATION_VECTOR, se sono inclusi anche un sensore giroscopio e un sensore magnetometro.

7.3.2. Magnetometro

Le implementazioni del dispositivo 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 anche implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED. Sui dispositivi Android nuovi ed esistenti è VIVAMENTE CONSIGLIATO di implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 10 Hz e DEVE essere in grado di segnalare eventi fino ad almeno 50 Hz.
  • DEVE essere conforme al sistema di coordinate dei sensori Android come descritto nelle API di Android.
  • DEVE essere in grado di misurare tra -900 μT e +900 μT su ciascun asse prima della saturazione.
  • DEVE avere un valore di offset del ferro duro inferiore a 700 μT e DEVE avere un valore inferiore a 200 μT, posizionando il magnetometro lontano dai campi magnetici dinamici (indotti dalla corrente) e statici (indotti dal magnete).
  • DEVE avere una risoluzione uguale o più densa di 0,6 μT e DEVE avere una risoluzione uguale o più densa di 0,2 μT.
  • DEVONO essere compensati in base alla temperatura.
  • DEVE supportare la calibrazione online e la compensazione dei bias in ferro duro e preservare i parametri di compensazione tra i riavvii del dispositivo.
  • DEVE applicare la compensazione del ferro morbido; la calibrazione può essere eseguita mentre il dispositivo è in uso o durante la produzione del dispositivo.
  • DEVE avere una deviazione standard, calcolata per asse sui campioni raccolti in un periodo di almeno 3 secondi alla frequenza di campionamento più veloce, non superiore a 0,5 μT.
  • DEVE implementare un sensore composito TYPE_ROTATION_VECTOR, se sono inclusi anche un sensore accelerometro e un sensore giroscopio.
  • POTREBBE implementare il sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR se viene implementato anche un sensore dell'accelerometro. Tuttavia, se implementato, DEVE consumare meno di 10 mW e DEVE consumare meno di 3 mW quando il sensore è registrato per la modalità batch a 10 Hz.

7.3.3. GPS

Le implementazioni del dispositivo 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:

  • È VIVAMENTE CONSIGLIATO che il dispositivo continui a fornire le normali uscite GPS/GNSS alle applicazioni durante una chiamata di emergenza e che l'output della posizione non venga bloccato durante una telefonata di emergenza.
  • DEVE supportare gli output di localizzazione a una frequenza di almeno 1 Hz quando richiesto 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 veloce per la prima correzione), quando connesso a una connessione Internet con velocità dati di 0,5 Mbps o superiore. Questo requisito viene in genere soddisfatto utilizzando una qualche forma di tecnica GPS/GNSS assistito o prevista per ridurre al minimo il tempo di blocco del GPS/GNSS (i dati di assistenza includono ora di riferimento, posizione di riferimento ed efemerie/orologio satellitari).
    • Dopo aver effettuato questo calcolo della posizione, è VIVAMENTE CONSIGLIATO che il dispositivo sia in grado di determinare la sua posizione, in cielo aperto, entro 10 secondi, quando le richieste di posizione vengono riavviate, fino a un'ora dopo il calcolo della posizione iniziale, anche se la richiesta successiva viene effettuata senza una connessione dati e/o dopo un ciclo di spegnimento e riaccensione.
  • 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 monitorare contemporaneamente almeno 24 satelliti, da più costellazioni (ad esempio GPS + almeno uno tra Glonass, Beidou, Galileo).
  • DEVE segnalare la generazione della tecnologia GNSS tramite l'API di test "getGnssYearOfHardware".
  • È VIVAMENTE CONSIGLIATO soddisfare e DEVE soddisfare tutti i requisiti riportati di seguito se la generazione della tecnologia GNSS è riportata come anno "2016" o più recente.
    • DEVE segnalare le misurazioni GPS non appena vengono rilevate, anche se non è stata ancora segnalata una posizione calcolata da GPS/GNSS.
    • DEVE segnalare gli pseudorange e i tassi di pseudointervallo GPS, che, in condizioni di cielo aperto dopo aver determinato la posizione, da fermo o in movimento con meno di 0,2 metri al secondo quadrato di accelerazione, 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 mentre alcuni dei requisiti GPS sopra indicati sono indicati come VIVAMENTE CONSIGLIATI, la definizione di compatibilità per la prossima versione principale dovrebbe cambiarli in DEVE.

7.3.4. Giroscopio

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

  • DEVE implementare il sensore TYPE_GYROSCOPE e DEVE implementare anche il sensore TYPE_GYROSCOPE_UNCALIBRATED. Sui dispositivi Android nuovi ed esistenti è VIVAMENTE CONSIGLIATO di implementare il sensore SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
  • DEVE essere in grado di misurare cambiamenti di orientamento fino a 1000 gradi al secondo.
  • DEVE essere in grado di segnalare eventi con una frequenza di almeno 50 Hz per i dispositivi Android Watch, in quanto questi dispositivi hanno un vincolo di alimentazione più rigido e 100 Hz per tutti gli altri tipi di dispositivi.
  • DEVI segnalare eventi fino ad almeno 200 Hz.
  • DEVE avere una risoluzione di 12 bit o più e DEVE avere una risoluzione di 16 bit o più.
  • 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 limitata da questo valore. In altre parole, se si misura la varianza del giroscopio a una frequenza di campionamento di 1 Hz, non dovrebbe essere superiore a 1e-7 rad^2/s^2.
  • DEVE implementare un sensore composito TYPE_ROTATION_VECTOR, se sono inclusi anche un sensore accelerometro e un sensore magnetometro.
  • Se è incluso un sensore accelerometro, DEVE implementare i sensori composito TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION e DEVE implementare il sensore composito TYPE_GAME_ROTATION_VECTOR. Sui dispositivi Android nuovi ed esistenti è VIVAMENTE CONSIGLIATO di implementare il sensore TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometro

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

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

7.3.6. Termometro

Le implementazioni dei dispositivi POSSONO includere un termometro ambientale (sensore di temperatura). Se presente, DEVE essere definita come SENSOR_TYPE_AMBIENT_TEMPERATURE e DEVE misurare la temperatura ambiente (stanza) in gradi Celsius.

Le implementazioni del dispositivo 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 nessun'altra temperatura. Tieni presente che il tipo di sensore SENSOR_TYPE_TEMPERATURE è stato ritirato in Android 4.0.

Per le implementazioni Android Automotive, SENSOR_TYPE_AMBIENT_TEMPERATURE DEVE misurare la temperatura all'interno dell'abitacolo del veicolo.

7.3.7. Fotometro

Le implementazioni dei dispositivi POTREBBERO includere un fotometro (sensore della luce ambientale).

7.3.8. Sensore di prossimità

Le implementazioni dei dispositivi POTREBBERO includere un sensore di prossimità. I dispositivi che possono effettuare una chiamata vocale e indicare qualsiasi 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à, questo:

  • 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 oggetti vicini allo schermo, in quanto l'intento principale di questo tipo di sensore è rilevare lo smartphone in uso dall'utente. Se l'implementazione di un dispositivo include un sensore di prossimità con qualsiasi altro orientamento, NON DEVE essere accessibile tramite questa API.
  • DEVE avere una precisione di almeno 1 bit.

7.3.9. Sensori ad alta affidabilità

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:

  • ACCELEROMETRO_TIPO_SENSORE
    • 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 di 12,5 Hz o inferiore.
    • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore.
    • DEVE avere un rumore di misurazione non superiore a 400 uG/√Hz.
    • È NECESSARIO implementare una forma non riattivazione di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore.
    • DEVE avere un consumo energetico per i batch non inferiore a 3 mW.
    • DEVE avere una stabilità della bias di rumore stazionario di \<15 μg √Hz da un set di dati statico per 24 ore.
    • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 1 mg / °C.
    • DEVE avere una non linearità della linea di best-fit pari a ≤ 0,5%, e una variazione di sensibilità rispetto alla temperatura di ≤ 0,03%/C°.

  • TIPO_DI_SENSORE_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 di 12,5 Hz o inferiore.
    • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore.
    • DEVE avere un rumore di misurazione non superiore a 0,014°/s/√Hz.
    • DEVE avere una stabilità di bias stazionaria di < 0,0002 °/s √Hz da un set di dati statico di 24 ore.
    • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 0,05 °/ s / °C.
    • DEVE avere una variazione di sensibilità rispetto alla temperatura ≤ 0,02% / °C.
    • DEVE avere una non linearità della linea di best-fit pari a ≤ 0,2%.
    • DEVE avere una densità del 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 di 5 Hz o inferiore.
    • 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 inoltre:
    • È NECESSARIO implementare una forma non riattivazione di questo sensore con una capacità di buffering di almeno 600 eventi del sensore.
  • PRESSIONE_TIPO_SENSORE
    • 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 di 1 Hz o inferiore.
    • DEVE avere una frequenza di misurazione massima di 10 Hz o superiore.
    • DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz.
    • È NECESSARIO implementare una forma non riattivazione di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
    • DEVE avere un consumo energetico per i batch non inferiore a 2 mW.
  • SENSOR_TYPE_GAME_ROTATION_VECTOR
    • È NECESSARIO implementare una forma non riattivazione di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
    • DEVE avere un consumo energetico per i batch non inferiore a 4 mW.
  • TIPO_SENSORE_TIPO_SIGNIFICANT_MOTION
    • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.
  • SENSORE_TIPO_STEP_DETECTOR
    • È NECESSARIO implementare una forma non riattivazione di questo sensore con una capacità di buffering di almeno 100 eventi del sensore.
    • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.
    • DEVE avere un consumo energetico per i batch non inferiore a 4 mW.
  • SENSOR_TYPE_STEP_COUNTER
    • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.
  • SENSORE_TILT_DETECTOR
    • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.

Inoltre, un dispositivo di questo tipo DEVE soddisfare i seguenti requisiti del sottosistema dei sensori:

  • Il timestamp dello stesso evento fisico riportato dall'accelerometro, dal sensore giroscopio e dal magnetometro DEVE essere di massimo 2,5 millisecondi l'uno dall'altro.
  • I timestamp degli eventi del sensore giroscopio DEVONO trovarsi nella stessa base temporale del sottosistema della fotocamera ed entro 1 millisecondi dall'errore.
  • I sensori ad alta affidabilità DEVONO consegnare i campioni alle applicazioni entro 5 millisecondi dal momento in cui i dati sono disponibili sul sensore fisico per l'applicazione.
  • Il consumo energetico non DEVE essere superiore a 0,5 mW quando il dispositivo è statico e 2,0 mW quando il dispositivo è in movimento quando è attiva una qualsiasi combinazione dei seguenti sensori:
    • TIPO_SENSORE_TIPO_SIGNIFICANT_MOTION
    • SENSORE_TIPO_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSORE_TILT_DETECTORS

Tieni presente che tutti i requisiti di consumo di energia presenti in questa sezione non includono il consumo di corrente del processore di applicazioni. Include la potenza assorbita dall'intera catena dei sensori: il sensore, eventuali circuiti di supporto, qualsiasi sistema di elaborazione dei sensori dedicato e così via.

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

  • 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 digitali. Se l'implementazione di un dispositivo include un sensore di impronte digitali e ha un'API corrispondente per sviluppatori di terze parti, l'implementazione:

  • DEVE dichiarare il supporto per la funzionalità android.hardware.fingerprint.
  • DEVE implementare completamente l'API corrispondente come descritto nella documentazione relativa all'SDK per Android.
  • DEVE avere un tasso di falsa accettazione non superiore allo 0,002%.
  • È VIVAMENTE CONSIGLIATO avere un tasso di rifiuto errato inferiore al 10%, come misurato sul dispositivo
  • È VIVAMENTE CONSIGLIATO avere una latenza inferiore a 1 secondo, misurata dal momento in cui si tocca il sensore di impronte digitali fino allo sblocco dello schermo, per un dito registrato.
  • DEVE limite di frequenza dei tentativi per almeno 30 secondi dopo cinque false prove per la verifica dell'impronta.
  • DEVE avere un'implementazione di un archivio chiavi supportato da hardware ed eseguire la corrispondenza delle impronte in un Trusted Execution Environment (TEE) o su un chip con un canale sicuro al TEE.
  • DEVONO essere criptati e autenticati criptati tutti i dati relativi alle impronte identificabili tramite crittografia, in modo che non possano essere acquisiti, letti o modificati 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 se esiste già o di aggiungere una nuova credenziale dispositivo (PIN/sequenza/password) protetta da TEE; l'implementazione del progetto open source Android fornisce il meccanismo per farlo.
  • NON DEVE consentire alle applicazioni di terze parti di distinguere tra le singole fingerprint.
  • DEVE rispettare il flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • Quando viene eseguito l'upgrade da una versione precedente ad Android 6.0, i dati relativi alle impronte devono essere migrati in modo sicuro per soddisfare i requisiti riportati sopra o devono essere rimossi.
  • DEVE utilizzare l'icona dell'impronta di Android fornita nell'Android Open Source Project.

7.3.11. Sensori solo per Android Automotive

I sensori specifici del settore automobilistico sono definiti in android.car.CarSensorManager API .

7.3.11.1. Attrezzo attuale

Le implementazioni di Android Automotive DEVONO fornire l'ingranaggio 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 DEVE essere basato sull'input del sensore di luce ambientale. Il sensore di luce ambientale sottostante POTREBBE essere lo stesso del Fotometro.

7.3.11.3. Stato di guida

Le implementazioni di Android Automotive DEVONO supportare lo stato alla guida definito come SENSOR_TYPE_DRIVING_STATUS, con il valore predefinito Drive_STATUS_UNRESTRICTED quando il veicolo è completamente fermo e parcheggiato. È responsabilità dei produttori di dispositivi configurare SENSOR_TYPE_DRIVING_STATUS in conformità a tutte le leggi e normative applicabili ai 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 un sensore di posizione con 6 gradi di libertà. I dispositivi portatili Android sono CONSIGLIATI di supportare questo sensore. Se l'implementazione di un dispositivo supporta un sensore di posizione con 6 gradi di libertà, questo:

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

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

Android POTREBBE essere utilizzato su dispositivi che non includono hardware per la telefonia. Questo significa che 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 tale tecnologia. Le implementazioni dei dispositivi che non includono hardware di telefonia DEVONO implementare le API complete in modalità autonoma.

7.4.1.1. Compatibilità con blocco numerico

Le implementazioni dei dispositivi di telefonia Android DEVONO includere il supporto del blocco di numeri e:

  • DEVE implementare completamente BlockNumberContract e l'API corrispondente come descritto nella documentazione dell'SDK.
  • DEVE bloccare tutte le chiamate e i messaggi da un numero di telefono in "BlockNumberProvider" senza alcuna interazione con le app. L'unica eccezione si verifica quando il blocco del numero viene temporaneamente rimosso, come descritto nella documentazione dell'SDK.
  • NON DEVE scrivere nel provider del registro chiamate della piattaforma per una chiamata bloccata.
  • NON DEVE scrivere nel provider di telefonia per un messaggio bloccato.
  • DEVE implementare un'interfaccia utente per la gestione dei numeri bloccata, che viene aperta con l'intent restituito dal metodo TelecomManager.createGestisciBlockNumbersIntent().
  • 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 pieno controllo dei servizi di telefonia, una singola istanza, sul dispositivo. Tutte le UI correlate al blocco DEVONO essere nascoste per gli utenti secondari e l'elenco bloccato DEVE essere comunque rispettato.
  • DEVONO eseguire la migrazione dei numeri bloccati al provider 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 uno o più moduli di codice 802.11. Se l'implementazione di un 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 funzionalità hardware android.hardware.wifi.
  • DEVE implementare l'API multicast come descritto nella documentazione dell'SDK.
  • DEVE supportare il DNS multicast (mDNS) e NON filtrare i pacchetti mDNS (224.0.0.251) in qualsiasi momento del funzionamento, tra cui:
    • anche quando lo schermo non è in stato attivo.
    • Per implementazioni di dispositivi Android Television, anche in stato di alimentazione in standby.

7.4.2.1. Wi-Fi Direct

Le implementazioni dei dispositivi DEVONO includere il supporto per Wi-Fi Direct (peer-to-peer Wi-Fi). Se l'implementazione di un dispositivo include il supporto per 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:

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

Le implementazioni dei dispositivi DEVONO includere il supporto per la configurazione del collegamento diretto tramite tunnel Wi-Fi (TDLS), come descritto nella documentazione dell'SDK Android. Se l'implementazione di un dispositivo include il supporto per TDLS e TDLS è abilitato dall'API WiFiManager, il dispositivo:

  • DOVREBBE usare TDLS solo quando è possibile E vantaggioso.
  • DOVREBBE avere un po' di euristica e NON usare TDLS quando le sue prestazioni potrebbero essere peggiori rispetto al passaggio attraverso il punto di accesso Wi-Fi.

7.4.3. Bluetooth

Le implementazioni degli smartwatch Android DEVONO supportare il Bluetooth. Le implementazioni di Android Television DEVONO supportare Bluetooth e Bluetooth LE. Le implementazioni di Android Automotive DEVONO supportare il Bluetooth e DEVONO supportare Bluetooth LE.

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 per 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 del dispositivo DEVONO implementare profili Bluetooth pertinenti, come A2DP, AVCP, OBEX e così via, in base alle esigenze del dispositivo.

Le implementazioni di Android Automotive DEVONO supportare il profilo di accesso ai messaggi (MAP). Le implementazioni di Android Automotive DEVONO supportare i seguenti profili Bluetooth:

  • Chiamate con Profilo in vivavoce (HFP).
  • Riproduzione di contenuti multimediali tramite Audio Distribution Profile (A2DP).
  • Controllo della riproduzione di contenuti multimediali tramite Remote Control Profile (AVRCP).
  • Condivisione dei contatti tramite il Phone Book Access Profile (PBAP).

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

  • DEVE dichiarare la funzionalità hardware android.hardware.bluetooth_le.
  • DEVE attivare le API Bluetooth basate su GATT (generic attributi profile) come descritto nella documentazione dell'SDK e su android.bluetooth.
  • è VIVAMENTE CONSIGLIATO di implementare un timeout dell'indirizzo privato risolvibile (RPA) non superiore a 15 minuti e di ruotare l'indirizzo al timeout per proteggere la privacy degli utenti.
  • DEVONO supportare lo scarico della logica di filtro al chipset Bluetooth durante l'implementazione dell'API ScanFilter e DEVONO segnalare il valore corretto di dove la logica di filtro viene implementata ogni volta che viene eseguita una query tramite il metodo android.bluetooth.BluetoothAdapter.isOffloadingFilteringSupported().
  • DEVE supportare lo scarico della scansione in batch sul chipset Bluetooth, ma se non è supportata, DEVE segnalare "false" ogni volta che viene eseguita una query tramite il metodo android.bluetooth.BluetoothAdapter.isOffloadScanBatchingSupported().
  • DEVONO supportare più annunci con almeno 4 aree, ma se non sono supportati, DEVONO segnalare "false" ogni volta che viene eseguita una query tramite il metodo android.bluetooth.BluetoothAdapter.isMultipleAdvertisingmentSupported().

7.4.4. Near Field Communication

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

  • 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 dalle specifiche tecniche 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 del forum NFC 1, 2, 3, 4 (definiti dal forum NFC)
    • VIVAMENTE CONSIGLIATA di essere in grado di leggere e scrivere messaggi NDEF e dati non elaborati tramite i seguenti standard NFC. Tieni presente che sebbene gli standard NFC riportati di seguito siano indicati come VIVAMENTE CONSIGLIATI, si prevede che nella definizione di compatibilità per una versione futura vengano modificati in DEVI. Questi standard sono facoltativi in questa versione, ma saranno obbligatori nelle versioni future. I dispositivi nuovi ed esistenti che eseguono questa versione di Android sono vivamente consigliati di soddisfare questi requisiti ora in modo da poter eseguire l'upgrade alle future release 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 dall'NFC Forum)
      • SDP 1.0 (definito dall'NFC Forum)
      • Protocollo push NDEF
      • SNEP 1.0 (definito dall'NFC Forum)
    • DEVE includere il supporto per Android Beam.
    • DEVE implementare il server predefinito SNEP. I messaggi NDEF validi ricevuti dal server SNEP predefinito DEVONO essere inviati alle applicazioni utilizzando l'intent android.nfc.ACTION_NDEF_DISCOVERED. La disattivazione di Android Beam nelle impostazioni NON DEVE disattivare l'invio di messaggi NDEF in arrivo.
    • DEVE rispettare l'intent android.settings.NFCSHARING_SETTINGS per mostrare le impostazioni di condivisione NFC.
    • DEVE implementare il server NPP. I messaggi ricevuti dal server NPP DEVONO essere elaborati allo stesso modo del server predefinito SNEP.
    • 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.
    • DEVI utilizzare un gesto o una conferma sullo schermo, ad esempio "Tocca per trasmettere", prima di inviare messaggi P2P NDEF in uscita.
    • DEVE attivare Android Beam per impostazione predefinita e DEVE essere in grado di inviare e ricevere messaggi tramite Android Beam, anche quando è attiva un'altra modalità NFC proprietaria P2p.
    • DEVE supportare il passaggio della connessione NFC a Bluetooth quando il dispositivo supporta Bluetooth Object Push Profile. Le implementazioni dei dispositivi DEVONO supportare il trasferimento della connessione a Bluetooth quando si utilizza android.nfc.NfcAdapter.setBeamPushUris, implementando le specifiche "Connection Handover versione 1.2" e "Bluetooth Secure Simple Pairing Using NFC versione 1.0" del forum NFC. Tale implementazione DEVE implementare il servizio LLCP di passaggio con il nome del servizio "urn:nfc:sn:handover" per lo scambio della richiesta di trasferimento/dei record di selezione tramite NFC e DEVE utilizzare il Bluetooth Object Push Profile per l'effettivo trasferimento di dati Bluetooth. Per motivi legacy (per rimanere compatibile con i dispositivi Android 4.1), l'implementazione DEVE comunque accettare richieste SNEP GET per lo scambio della richiesta di passaggio/selezione dei record tramite NFC. Tuttavia, un'implementazione stessa NON DEVE inviare richieste SNEP GET per l'esecuzione del trasferimento della connessione.
    • DEVE effettuare il polling per tutte le tecnologie supportate in modalità di rilevamento NFC.
    • DEVE essere in modalità di rilevamento NFC mentre il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.

Tieni presente che i link disponibili pubblicamente non sono disponibili per le specifiche JIS, ISO e NFC Forum citate in precedenza.

Android supporta la modalità HCE (NFC Host Card Emulation). Se l'implementazione di un dispositivo include un chipset controller NFC in grado di eseguire HCE (per NfcA e/o NfcB) e supporta il routing ID applicazione (AID), questo:

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

Se l'implementazione di un dispositivo include un chipset controller NFC in grado di eseguire HCE per NfcF e quest'ultima implementa la funzionalità per applicazioni di terze parti, questo:

  • DEVE segnalare la costante della funzionalità android.hardware.nfc.hcef.
  • DEVE implementare le API NFC Card Emulation come definito nell'SDK Android.

Inoltre, le implementazioni dei dispositivi POTREBBERO includere il supporto per lettore/scrittura per le seguenti tecnologie MIFARE.

  • MIFARE Classico
  • MIFARE ultraleggero
  • NDEF su MIFARE Classic

Tieni presente che Android include API per questi tipi di MIFARE. Se un'implementazione dispositivo supporta MIFARE nel ruolo di lettore/autore, questo:

  • 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 non si tratta di una funzionalità di Android standard e, in quanto tale, 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 un'implementazione del dispositivo non include hardware NFC, NON DEVE dichiarare la funzionalità android.hardware.nfc del metodo android.content.pm.PackageManager.hasSystemFeature() e DEVE implementare l'API NFC Android come soluzione autonoma.

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 non 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 networking di dati. In particolare, le implementazioni dei dispositivi DEVONO includere il supporto di almeno uno standard di dati in grado di funzionare a 200 Kbit/sec o superiore. Esempi di tecnologie che soddisfano questo requisito includono EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN, ecc.

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

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

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

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

IPv6 DEVE essere abilitato per impostazione predefinita.

Per garantire che la comunicazione IPv6 sia affidabile quanto IPv4, i pacchetti IPv6 unicast inviati al dispositivo NON DEVONO essere eliminati, anche quando lo schermo non è in stato attivo. I pacchetti IPv6 multicast ridondanti, come la ripetizione di annunci pubblicitari identici, POTREBBERO avere limitazioni di frequenza nell'hardware o nel firmware, se necessario, per risparmiare energia. In tali casi, la limitazione di frequenza NON DEVE causare la perdita della connettività IPv6 da parte del dispositivo su qualsiasi rete conforme a IPv6 che utilizzi una durata 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 attivata per impostazione predefinita, in modo che il metodo getMasterSyncSync() restituisca "true".

7.4.7. Risparmio dati

Le implementazioni dei dispositivi con una connessione a consumo sono VIVAMENTE CONSIGLIATE per offrire la modalità Risparmio dati.

Se un'implementazione del dispositivo offre la modalità Risparmio dati, questo:

  • 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 applicazioni o rimuoverle dalla lista consentita.

Al contrario, se un'implementazione su dispositivo non offre la modalità Risparmio dati:

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

  • DEVE non trasmettere ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

  • DEVE avere un'attività che gestisca l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ma POTREBBE implementarla come autonomo.

7.5. Fotocamere

Le implementazioni dei dispositivi DEVONO includere una fotocamera posteriore e POTREBBERO includere una fotocamera anteriore. Una fotocamera posteriore è una fotocamera che si trova sul lato del dispositivo opposto al display. cioè immagini le scene sul lato più lontano del dispositivo, come una fotocamera tradizionale. Una fotocamera anteriore è una fotocamera situata sullo stesso lato del dispositivo del display. ovvero una videocamera solitamente utilizzata per mostrare immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.

Se l'implementazione di un dispositivo include almeno una videocamera, DEVE essere possibile per un'applicazione allocare contemporaneamente 3 bitmap RGBA_8888 uguali alle dimensioni delle immagini prodotte dal sensore della fotocamera con la più grande risoluzione presente sul dispositivo, mentre la fotocamera è aperta per l'anteprima di base e l'acquisizione.

7.5.1. Fotocamera posteriore

Le implementazioni del dispositivo DEVONO includere una fotocamera posteriore. Se l'implementazione di un dispositivo include almeno una fotocamera posteriore:

  • DEVE segnalare il flag funzionalità android.hardware.camera e android.hardware.camera.any.
  • DEVE avere una risoluzione di almeno 2 megapixel.
  • DEVE avere la messa a fuoco automatica hardware o software implementata nel driver della fotocamera (trasparente al software dell'applicazione).
  • POTREBBERO avere hardware a fuoco fisso o EDOF (profondità di campo estesa).
  • POSSONO includere un flash. Se la fotocamera include un flash, il flash NON DEVE essere acceso mentre è stata registrata un'istanza android.hardware.Camera.PreviewCallback su una superficie di anteprima di Fotocamera, a meno che l'applicazione non abbia abilitato 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 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 POTREBBERO includere una fotocamera anteriore. Se l'implementazione di un dispositivo include almeno una fotocamera anteriore:

  • DEVE segnalare il flag 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 frontali e le implementazioni dei dispositivi NON DEVONO configurare l'API in modo da considerare una fotocamera anteriore come fotocamera posteriore predefinita, anche se è l'unica fotocamera del dispositivo.
  • POTREBBERO includere funzionalità (quali messa a fuoco automatica, flash e così via) disponibili per le fotocamere posteriori come descritto nella sezione 7.5.1.
  • DEVE riflettere orizzontalmente (cioè speculare) lo stream visualizzato da un'app in un'Anteprima di Fotocamera, come segue:
    • Se l'implementazione del dispositivo è in grado di essere ruotata dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite input 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 speculare orizzontalmente rispetto all'orientamento specificato dall'applicazione.
    • In caso contrario, l'anteprima DEVE essere visualizzata lungo l'asse orizzontale predefinito del dispositivo.
  • DEVE eseguire il mirroring dell'immagine visualizzata dal postview come lo stream di immagini di anteprima della fotocamera. Se l'implementazione del dispositivo non supporta la visualizzazione post-visualizzazione, questo requisito non si applica ovviamente.
  • NON DEVE riflettere gli stream video o l'immagine statica acquisiti finali restituiti ai callback dell'applicazione o impegnati nello spazio di archiviazione multimediale.

7.5.3. Videocamera esterna

Le implementazioni dei dispositivi POTREBBERO includere il supporto di una videocamera esterna che non è necessariamente sempre collegata. Se un dispositivo supporta una fotocamera esterna:

  • DEVE dichiarare il flag della funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any .
  • POTREBBE supportare più fotocamere.
  • DEVE supportare la classe video USB (UVC 1.0 o superiore) se la videocamera esterna si collega tramite la porta USB.
  • DEVONO supportare le compresse video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ovvero stream di immagini non elaborati o compressi in modo indipendente).
  • POTREBBE supportare la codifica video basata su fotocamera. Se supportato, uno stream non codificato / MJPEG simultaneo (QVGA o risoluzione 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 espongono all'app un controllo della fotocamera di livello inferiore, inclusi flussi efficienti di streaming/burst zero-copy e controlli per fotogramma di esposizione, guadagno, guadagno 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 per l'utilizzo delle implementazioni dei dispositivi Android, DEVE garantire il supporto continuo dell'API come descritto in questa sezione e nell'SDK per Android.

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API relative alle fotocamere, 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 nel byte[] passato in onPreviewFrame() devono essere inoltre nel formato di codifica NV21. Vale a dire che NV21 DEVE essere l'impostazione predefinita.
  • Per android.hardware.Camera, le implementazioni dei dispositivi DEVONO supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime delle fotocamere per le fotocamere anteriori e posteriori. (Il codificatore video hardware e la videocamera possono utilizzare qualsiasi formato pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione a YV12.)
  • Per le implementazioni android.hardware.camera2, le implementazioni dei dispositivi devono supportare i formati android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG come output tramite l'API android.media.ImageReader.

Le implementazioni dei dispositivi DEVONO comunque implementare l'API Camera completa inclusa nella documentazione dell'SDK Android, indipendentemente dal fatto che il dispositivo includa la messa a fuoco automatica hardware o altre funzionalità. Ad esempio, le fotocamere prive di messa a fuoco automatica DEVONO comunque richiamare qualsiasi istanza android.hardware.Camera.AutoFocusCallback registrata (anche se non è pertinente per una fotocamera senza messa a fuoco automatica). Tieni presente che questo vale per le fotocamere anteriori. Ad esempio, anche se la maggior parte delle fotocamere anteriori non supporta la messa a fuoco automatica, i callback API devono essere comunque "falsi" come descritto.

Le implementazioni dei dispositivi DEVONO riconoscere e rispettare il nome di ogni 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 documentato. Al contrario, le implementazioni dei dispositivi NON DEVONO rispettare o riconoscere costanti stringhe passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. In altre parole, le implementazioni del dispositivo DEVONO supportare tutti i parametri standard della fotocamera, se l'hardware lo consente, e NON DEVONO supportare tipi di parametri personalizzati della fotocamera. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini con tecniche di imaging HDR (High Dynamic Range) DEVONO supportare il parametro della fotocamera Camera.SCENE_MODE_HDR.

Poiché non tutte le implementazioni dei dispositivi sono in grado di supportare completamente tutte le funzionalità dell'API android.hardware.camera2, le implementazioni dei dispositivi DEVONO segnalare il livello di assistenza corretto con la proprietà android.info.supportedHardwareLevel, come descritto nell'SDK per Android, nonché i flag delle funzionalità framework appropriati.

Le implementazioni dei dispositivi DEVONO inoltre dichiarare le funzionalità della fotocamera individuale di android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag di funzionalità appropriati. un dispositivo deve definire il flag funzionalità se uno dei dispositivi con fotocamera collegata supporta la funzionalità.

Le implementazioni dei dispositivi DEVONO trasmettere l'intent Fotocamera.ACTION_NEW_PICTURE ogni volta che la fotocamera scatta una nuova foto e il relativo ingresso viene aggiunto al media store.

Le implementazioni dei dispositivi DEVONO trasmettere l'intent Fotocamera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e l'immagine viene aggiunta al media store.

7.5.5. Orientamento fotocamera

Entrambe le fotocamere anteriore e posteriore, 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 è mantenuto in orientamento orizzontale, le videocamere DEVONO acquisire le immagini con l'orientamento orizzontale. Ciò vale indipendentemente dall'orientamento naturale del dispositivo. vale a dire ai dispositivi principali con orientamento orizzontale e verticale.

7.6 Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

I dispositivi Android Television DEVONO avere almeno 4 GB di spazio di archiviazione permanente disponibile per i dati privati delle applicazioni.

La memoria disponibile per le implementazioni del kernel e dello spazio utente sui dispositivi DEVE essere almeno uguale o superiore ai valori minimi specificati dalla seguente tabella. (Consulta la sezione 7.1.1 per le definizioni di dimensioni e densità dello schermo.)

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

I valori minimi di memoria DEVONO essere in aggiunta a qualsiasi spazio di memoria già dedicato ai componenti hardware, come radio, video, ecc., che non è sotto il controllo del kernel.

Le implementazioni dei dispositivi con meno di 512 MB di memoria disponibile per il kernel e lo spazio utente, a meno che un orologio Android, DEVE restituire il valore "true" per ActivityManager.isLowRamDevice().

I dispositivi Android Television DEVONO avere almeno 4 GB e le altre implementazioni DEVONO avere almeno 3 GB di spazio di archiviazione permanente per i dati privati delle applicazioni. In altre parole, la partizione /data DEVE essere di almeno 4 GB per i dispositivi Android Television e almeno 3 GB per altre implementazioni dei dispositivi. CONSIGLIATE VIVAMENTE le implementazioni dei dispositivi che eseguono Android di avere almeno 4 GB di spazio di archiviazione permanente per i dati privati delle applicazioni, in modo che possano eseguire l'upgrade alle future release della piattaforma.

Le API Android includono una Gestione dei download, che le applicazioni POSSONO utilizzare per scaricare file di dati. L'implementazione su dispositivo di Gestione dei download DEVE essere in grado di scaricare singoli file di almeno 100 MB nella posizione predefinita della "cache".

7.6.2. Archiviazione condivisa delle applicazioni

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

Le implementazioni dei dispositivi DEVONO essere configurate con lo spazio di archiviazione condiviso montato per impostazione predefinita, "pronte all'uso". 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 POTREBBERO avere hardware per dispositivi di archiviazione rimovibili accessibili agli utenti, ad esempio uno slot per schede SD (Secure Digital). Se questo slot viene utilizzato per soddisfare il requisito di spazio di archiviazione condiviso, l'implementazione del dispositivo:

  • DEVE implementare un avviso popup o un popup sull'interfaccia utente che avvisa l'utente quando non è presente una scheda SD.
  • DEVE includere una scheda SD in formato FAT da almeno 1 GB OPPURE mostrare sulla confezione e 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 lo spazio di archiviazione interno (non rimovibile) come spazio condiviso per le app incluse nell'upstream Open Source Project di Android; le implementazioni nei dispositivi DEVONO utilizzare questa configurazione e questa implementazione software. Se l'implementazione di un dispositivo utilizza uno spazio di archiviazione interno (non rimovibile) per soddisfare il requisito dello spazio di archiviazione condiviso, mentre tale spazio di archiviazione POTREBBE condividere spazio con i dati privati dell'applicazione, DEVE essere di almeno 1 GB e montato su /sdcard (o /sdcard DEVE essere un collegamento simbolico alla posizione fisica se è montato altrove).

Le implementazioni dei dispositivi DEVONO applicare, come documentato, l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE su questo spazio di archiviazione condiviso. L'archivio condiviso DEVE essere altrimenti scrivibile da qualsiasi applicazione che ottiene tale autorizzazione.

Le implementazioni dei dispositivi che includono più percorsi di archiviazione condivisa (ad esempio sia uno slot per scheda SD sia una memoria interna condivisa) DEVONO consentire solo lo spazio app per Android con privilegi dotate dell'autorizzazione WRITE_EXTERNAL_STORAGE per scrivere sullo spazio di archiviazione esterno secondario, tranne durante la scrittura nelle directory specifiche del pacchetto o all'interno dell'elemento URI restituito attivando l'intent ACTION_OPEN_DOCUMENT_TREE.

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

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

  • DEVE essere compatibile con l'host Android MTP di riferimento, Android File Transfer.
  • DEVI segnalare una classe di dispositivi USB pari a 0x00.
  • DEVI segnalare un nome di interfaccia USB di "MTP".

7.6.3. Spazio di archiviazione utilizzabile

Le implementazioni dei dispositivi sono VIVAMENTE CONSIGLIATE di implementare lo spazio di archiviazione utilizzabile se la porta del dispositivo di archiviazione rimovibile si trova in una posizione stabile a lungo termine, ad esempio all'interno del vano batterie o di un'altra copertura protettiva.

Le implementazioni dei dispositivi, ad esempio i televisori, POSSONO consentire l'adozione tramite porte USB, in quanto si prevede che il dispositivo sia statico e non mobile. Tuttavia, per altre implementazioni di dispositivi di natura mobile, è VIVAMENTE CONSIGLIATO di implementare lo spazio di archiviazione utilizzabile in una posizione stabile a lungo termine, poiché scollegarli accidentalmente 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 collegabile a un host USB dotato di porta USB standard di tipo A o C.
  • La porta DEVE usare il fattore di forma USB micro-B, micro-AB o Tipo-C. I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare questi requisiti, in modo da essere in grado di eseguire l'upgrade alle future release della piattaforma.
  • La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o abilitare la rotazione dello schermo del software per tutte le app (inclusa la schermata Home), in modo che il display venga inserito correttamente quando il dispositivo è orientato con la porta in basso. I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare questi requisiti, in modo da essere in grado di eseguire l'upgrade a release future della piattaforma.
  • DEVE consentire a un host USB collegato al dispositivo Android di accedere ai contenuti del volume dell'archivio condiviso utilizzando l'archivio di massa USB o il protocollo Media Transfer Protocol.
  • DEVE implementare l'API e la specifica Android Open Accessory (AOA) come documentato nella documentazione relativa all'SDK Android e, se si tratta di un dispositivo portatile Android, DEVE implementare l'API AOA. Implementazioni dei dispositivi che implementano la specifica AOA:
    • DEVE dichiarare il supporto per la funzionalità hardware android.hardware.usb.accessory.
    • DEVE implementare la classe audio USB come documentato nella documentazione dell'SDK Android.
    • La classe di archiviazione di massa USB DEVE includere la stringa "android" alla fine della descrizione dell'interfaccia iInterface stringa dell'archivio di massa USB
  • DOVREBBE implementare il supporto per assorbire 1,5 A di corrente durante il suono e il traffico HS, come specificato nella specifica per la ricarica della batteria USB, revisione 1.2. I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare questi requisiti, in modo da essere in grado di eseguire l'upgrade alle future release della piattaforma.
  • I dispositivi di tipo C DEVONO rilevare i caricabatterie da 1,5 A e 3,0 A in base allo standard di resistenza di tipo C e devono rilevare le variazioni nella pubblicità.
  • I dispositivi di tipo C che supportano anche la modalità host USB sono VIVAMENTE CONSIGLIATI per supportare Power Delivery per lo scambio di dati e ruoli di alimentazione.
  • I dispositivi di tipo C DEVONO supportare la funzionalità Power Delivery per la ricarica ad alta tensione e il supporto di modalità alternative come il display out.
  • Il valore di iSerialNumber nel descrittore del dispositivo standard USB DEVE essere uguale al valore di android.os.Build.SERIAL.
  • I dispositivi di tipo C sono VIVAMENTE CONSIGLIATI di non supportare metodi di ricarica proprietari che modificano la tensione Vbus oltre i livelli predefiniti o alterano i ruoli sink/source in quanto ciò potrebbe causare problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard USB Power Delivery. Anche se questa opzione è definita "FORTEMENTE CONSIGLIATA", nelle future versioni di Android potremmo OBBLIGARE tutti i dispositivi di tipo C per il supporto della completa interoperabilità con i caricabatterie standard di tipo C.

7.7.2. Modalità host USB

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

  • DOVREBBE utilizzare una porta USB di tipo C, se l'implementazione del dispositivo supporta USB 3.1.
  • POTREBBE utilizzare un fattore di forma della porta non standard, ma in caso affermativo DEVE essere fornito con un cavo o cavi adatti per la porta a una porta USB standard di tipo A o C.
  • POTREBBE usare una porta USB micro-AB, ma in questo caso DEVI spedirla con un cavo o dei cavi adatti per la porta a una porta USB standard di tipo A o C.
  • è CONSIGLIATO di implementare la classe audio USB come documentato nella documentazione dell'SDK Android.
  • DEVE implementare l'API Android USB host come documentato nell'SDK per Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host.
  • DEVONO supportare la ricarica del dispositivo in modalità host; pubblicizzare una corrente di origine di almeno 1,5 A, come specificato nella sezione Parametri di terminazione della sezione [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 utilizzando l'intervallo di corrente di uscita Charging Downstream Port (CDP) per i connettori di revisione Micro-ABP (Ricarica della batteria USB tipo-C), come specificato nelle specifiche della revisione Batteria di ricarica USB 1.
  • I dispositivi USB Type-C sono VIVAMENTE CONSIGLIATI per supportare DisplayPort, DOVREBBERO supportare USB SuperSpeed Data Rates e sono VIVAMENTE CONSIGLIATI per supportare Power Delivery per lo scambio di dati e ruoli dell'alimentazione.
  • I dispositivi con porte di tipo A o tipo AB NON DEVONO essere forniti con un adattatore che converte da questa porta a una presa di tipo C.
  • DEVONO riconoscere tutti i dispositivi MTP (Media Transfer Protocol) collegati da remoto e rendere i relativi contenuti accessibili tramite gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT, se è supportato Storage Access Framework (SAF).
  • Se si utilizza una porta USB Type-C ed è incluso il supporto per la modalità periferica, DEVE implementare la funzionalità Dual Role Port come definito dalla specifica USB Type-C (sezione 4.5.1.3.3).
  • DOVREBBE, se la funzionalità della porta del ruolo doppia è supportata, implementare il modello Prova.* più appropriato per il fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DOVREBBE implementare il modello provare.SNK.

7.8 Audio

7.8.1. Microfono

Le implementazioni Android, Watch e Automotive DEVONO includere un microfono.

Le implementazioni del dispositivo 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 Registrazione audio almeno in modalità autonoma, come previsto dalla 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 per la registrazione audio di cui alla sezione 5.4.
  • DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
  • VIVAMENTE CONSIGLIATO di supportare la registrazione quasi a ultrasuoni, come descritto nella sezione 7.8.3.

7.8.2. Uscita audio

Gli smartwatch Android POSSONO includere un output audio.

Implementazioni di dispositivi che includono un altoparlante o una porta di uscita audio/multimediale per una periferica di uscita audio come cuffie o altoparlante esterno:

  • DEVE segnalare la costante della funzionalità android.hardware.audio.output.
  • DEVE soddisfare i requisiti per la riproduzione audio di cui alla sezione 5.5.
  • DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
  • VIVAMENTE CONSIGLIATO per il supporto della riproduzione quasi a ultrasuoni, come descritto nella sezione 7.8.3.

Al contrario, se l'implementazione di un dispositivo non include un altoparlante o una porta di uscita audio, NON DEVE segnalare la funzionalità di output android.hardware.audio e DEVE implementare le API relative all'output audio almeno in modalità autonoma.

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

7.8.2.1. Porte audio analogiche

Per la compatibilità con auricolari e altri accessori audio che utilizzano il connettore audio da 3,5 mm sull'ecosistema Android, se l'implementazione di un dispositivo include una o più porte audio analogiche, almeno una di queste porte DEVE essere un jack audio da 3,5 mm a 4 conduttori. Se l'implementazione di un dispositivo ha un jack audio da 3,5 mm a 4 conduttori, questo:

  • DEVONO supportare la riproduzione audio su cuffie e cuffie stereo dotate di microfono e DEVONO supportare la registrazione audio da cuffie stereo con microfono.
  • DEVE supportare i connettori audio TRRS con l'ordine di pin-out CTIA e DOVREBBE supportare connettori audio con l'ordine di pin-out 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 aggiuntivo microfono impostato su 1.
  • DEVE supportare il rilevamento e la mappatura sui codici chiave per i seguenti 3 intervalli di impedenza equivalente tra il microfono e i conduttori di terra sulla spina audio:
    • 70 ohm o meno : KEYCODE_HEADSETHOOK
    • 210-290 Ohm : KEYCODE_VOLUME_UP
    • 360-680 Ohm : KEYCODE_VOLUME_DOWN
  • VIVAMENTE CONSIGLIATO di rilevare e mappare il keycode per il seguente intervallo di impedenza equivalente tra il microfono e i conduttori di terra sulla spina audio:
    • 110-180 Ohm: KEYCODE_VOICE_ASSIST
  • DEVE attivare ACTION_HEADSET_PLUG su un inserto, ma solo dopo che tutti i contatti sulla spina toccano i segmenti pertinenti sul jack.
  • DEVE essere in grado di pilotare almeno 150 mV ± 10% della tensione di uscita su un altoparlante da 32 Ohm.
  • DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8V ~ 2,9V.

7.8.3. Quasi a ultrasuoni

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

  • Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASound è impostato su "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 DEVE essere non più di 15 dB al di sotto della risposta a 2 kHz.
    • Il rapporto tra segnale e rumore non ponderato del microfono tra 18,5 kHz e 20 kHz per un tono di 19 kHz a -26 dBFS DEVE essere non inferiore a 50 dB.
  • Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASound è "true", la risposta media dell'altoparlante nella banda 18,5 kHz - 20 kHz DEVE essere non inferiore a 40 dB al di sotto della risposta a 2 kHz.

7.9 Realtà virtuale

Android include API e strutture per creare la "realtà virtuale" Applicazioni (VR) che includono esperienze VR di alta qualità sui dispositivi mobili. Le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in dettaglio in questa sezione.

7.9.1. Modalità realtà virtuale

Le implementazioni di dispositivi portatili Android che supportano una modalità per le applicazioni VR che gestisce il rendering stereoscopico delle notifiche e disattivano i componenti dell'interfaccia utente del sistema monoculare mentre un'applicazione VR è incentrata sull'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 possa essere attivata dalle applicazioni VR tramite android.app.Activity#setVrModeEnabled .

7.9.2. Alte prestazioni di realtà virtuale

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

  • Le implementazioni dei dispositivi DEVONO avere almeno due core fisici.
  • Le implementazioni del dispositivo 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.getEsclusiCores per restituire i numeri di core CPU esclusivi dell'applicazione in primo piano principale. Se è supportato il core esclusivo, il core DEVE non consentire l'esecuzione di altri processi dello spazio utente (ad eccezione dei driver di dispositivo utilizzati dall'applicazione), ma POTREBBE consentire l'esecuzione di alcuni processi del kernel all'occorrenza.
  • Le implementazioni dei dispositivi DEVONO supportare la modalità prestazioni sostenute.
  • Le implementazioni dei dispositivi DEVONO supportare OpenGL ES 3.2.
  • Le implementazioni dei dispositivi DEVONO supportare l'hardware Vulkan livello 0 e DEVONO supportare l'hardware Vulkan di livello 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 e EGL_KHR_wait_sync in modo che possano essere utilizzate 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 frontale condiviso in modo che il rendering a occhio alternato dei contenuti VR a 60 f/s con due contesti di rendering venga visualizzato senza artefatti di strappo visibili.
  • Le implementazioni dei dispositivi DEVONO implementare EGL_IMG_context_priorità 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 i contenuti EGL_EXT_protect_content e GL_EXT_protect_textures in modo da poter essere utilizzati per la riproduzione di video con texture sicura ed esporre le estensioni nell'elenco delle estensioni EGL e GL disponibili.
  • Le implementazioni dei dispositivi DEVONO supportare la decodifica H.264 almeno 3840x2160@30fps-40Mbps (equivalente a 4 istanze di 1920x1080@30fps-10Mbps o 2 istanze di 1920x1080@60fps-20Mbps).
  • Le implementazioni dei dispositivi DEVONO supportare HEVC e VP9, DEVONO essere in grado di decodificare almeno 1920x1080@30fps-10Mbps e DEVE essere in grado di decodificare 3840x2160@30fps-20Mbps (equivalente a 4 istanze di 1920x1080@3Mbps).
  • Le implementazioni del dispositivo sono VIVAMENTE CONSIGLIATE per il supporto della 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 precisi per la temperatura cutanea.
  • L'implementazione del dispositivo DEVE avere uno schermo incorporato e la risoluzione DEVE essere almeno FullHD(1080p) e VIVAMENTE CONSIGLIATA di essere in formato QuadHD (1440p) o superiore.
  • Il display DEVE misurare tra 4,7" e 6" in diagonale.
  • Il display DEVE aggiornarsi di almeno 60 Hz in modalità VR.
  • La latenza dello schermo nei colori da grigio a grigio, da bianco a nero e da nero a bianco DEVE essere ≤ 3 ms.
  • Il display DEVE supportare una modalità a bassa persistenza con una persistenza ≤ 5 ms; la persistenza è definita come la quantità di tempo per cui un pixel emette luce.
  • Le implementazioni dei dispositivi DEVONO supportare Bluetooth 4.2 e l'estensione data Length dati Bluetooth LE sezione 7.4.3.

8. Prestazioni e potenza

Alcuni criteri minimi di potenza e prestazioni sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di base che gli sviluppatori avrebbero quando sviluppano un'app. I dispositivi Android Watch DEVONO e altri tipi di implementazioni sui dispositivi DEVONO soddisfare i seguenti criteri.

8.1. Coerenza dell'esperienza utente

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

  • Latenza frame coerente . Una latenza di frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più di 5 frame al secondo e DEVE essere inferiore a 1 frame al secondo.
  • Latenza dell'interfaccia utente . Le implementazioni dei dispositivi DEVONO garantire un'esperienza utente a bassa latenza scorrendo un elenco di 10.000 voci, come definito dalla suite per il test di compatibilità Android (CTS, Android Compatibility Test Suite, CTS) in meno di 36 secondi.
  • Cambio di attività . Quando sono state lanciate più applicazioni, il riavvio di un'applicazione già in esecuzione dopo l'avvio DEVE richiedere meno di un secondo.

8.2. Prestazioni accesso file I/O

Le implementazioni del dispositivo DEVONO garantire la coerenza delle prestazioni di accesso ai file nella memoria interna per le operazioni di lettura e scrittura.

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

8.3. Modalità di risparmio energetico

Android 6.0 ha introdotto le modalità di risparmio energetico di 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, l'attivazione, la manutenzione, gli algoritmi di riattivazione e l'uso di impostazioni di sistema globali di queste modalità di risparmio energetico non DEVONO discostarsi dall'Android Open Source Project.

Oltre alle modalità di risparmio energetico, le implementazioni dei dispositivi Android POSSONO implementare uno o tutti i quattro stati di alimentazione a riposo definiti dall'ACPI (Advanced Configuration and Power Interface), ma se implementa gli stati di alimentazione S3 e S4, può entrare in questi stati solo quando si chiude un coperchio che fa fisicamente parte del dispositivo.

8.4. Contabilità consumo energetico

Una contabilità e un report più accurati sul consumo energetico forniscono allo sviluppatore di app sia gli incentivi sia gli strumenti per ottimizzare il modello di consumo energetico dell'applicazione. Di conseguenza, le implementazioni dei dispositivi:

  • DEVE essere in grado di tenere traccia dell'utilizzo dell'energia dei componenti hardware e attribuire tale utilizzo ad applicazioni specifiche. In particolare, le implementazioni:
    • DEVE fornire un profilo alimentazione per componente che definisca il valore del consumo attuale per ciascun componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
    • DEVE indicare tutti i valori del consumo energetico in milliampere-ora (mAh).
    • DEVE essere attribuito al componente hardware stesso se non è in grado di attribuire l'utilizzo dell'energia del componente hardware a un'applicazione.
    • DEVE segnalare il consumo energetico della CPU per ogni UID di processo. Il progetto open source Android soddisfa il requisito tramite l'implementazione del modulo kernel uid_cputime.
  • DEVE rendere disponibile questo consumo energetico tramite il comando shell adb shell dumpsys batterystats allo sviluppatore dell'app.
  • DEVE rispettare l'intent android.intent.action.POWER_USAGE_SUMMARY e visualizzare un menu di impostazioni che mostri questo consumo energetico.

8.5. Prestazioni costanti

Le prestazioni possono variare notevolmente per le app a lunga esecuzione ad alte prestazioni, a causa delle altre app in esecuzione in background o della limitazione della CPU dovuta ai limiti di temperatura. Android include interfacce programmatiche che, quando il dispositivo è in grado di funzionare, l'applicazione in primo piano principale può richiedere al sistema di ottimizzare l'allocazione delle risorse per risolvere queste fluttuazioni.

Le implementazioni dei dispositivi DEVONO supportare la modalità prestazioni sostenute, che può fornire all'applicazione in primo piano principale un livello coerente di prestazioni per un periodo di tempo prolungato quando richiesto tramite il metodo API Window.setSustainedPerformanceMode(). L'implementazione di un dispositivo DEVE segnalare in modo preciso il supporto della modalità di rendimento sostenuto tramite il metodo API PowerManager.isSustainedPerformanceModeSupported().

Le implementazioni dei dispositivi con due o più core 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 dell'API Process.getExclusiveCores() i numeri ID dei core esclusivi che possono essere prenotati dall'applicazione in primo piano principale.
  • Le implementazioni dei dispositivi DEVONO non consentire l'esecuzione di processi dello spazio utente, ad eccezione dei driver dei dispositivi utilizzati dall'applicazione, su core esclusivi, ma POTREBBE consentire l'esecuzione di alcuni processi del kernel all'occorrenza.

Se l'implementazione di un dispositivo non supporta un core esclusivo, DEVE restituire un elenco vuoto tramite il metodo 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 su sicurezza e autorizzazioni nelle API della documentazione per gli sviluppatori Android. Le implementazioni dei dispositivi DEVONO supportare l'installazione di applicazioni autofirmate 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 che seguono.

9.1. Autorizzazioni

Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android. In particolare, le implementazioni DEVONO applicare in modo forzato ogni autorizzazione definita come descritto nella documentazione SDK; nessuna autorizzazione può essere omessa, modificata o ignorata. Le implementazioni POSSONO aggiungere ulteriori autorizzazioni, a condizione che le nuove stringhe dell'ID autorizzazione non si trovino nello spazio dei nomi android.*.

Le autorizzazioni con protectionLevel di 'PROTECTION_FLAG_PRIVILEGED' DEVONO essere concesse soltanto alle app precaricate nei percorsi con privilegi inseriti 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. Applicazioni con targetSdkVersion > in fase di runtime. Implementazioni dei dispositivi:

  • DEVE mostrare all'utente un'interfaccia dedicata per decidere se concedere le autorizzazioni di runtime richieste, oltre a fornire un'interfaccia in cui gestire le autorizzazioni di runtime.
  • DEVE avere una sola implementazione per 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. UID e isolamento dei processi

Le implementazioni dei dispositivi DEVONO supportare il modello sandbox dell'applicazione Android, in cui ogni applicazione viene eseguita come UID Unixstyle 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 sulla sicurezza e sulle autorizzazioni.

9.3. Autorizzazioni del file system

Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni di accesso ai file Android, come definito nella sezione Informazioni su sicurezza e autorizzazioni.

9.4 Ambienti di esecuzione alternativi

Le implementazioni dei dispositivi POTREBBERO includere ambienti di runtime che eseguono applicazioni utilizzando un software o una tecnologia diversi 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 standard di Android, 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 <uses-permission> meccanismo di attenzione.

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

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

  • DEVI installare le app tramite PackageManager in sandbox Android separate (ID utente Linux e così via).
  • POTREBBE fornire un'unica 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 altre app installate sul dispositivo, a meno che tramite i meccanismi Android standard di ID utente condiviso e certificato di firma.
  • NON DEVE essere avviato con, concedere o ottenere l'accesso alle sandbox corrispondenti ad altre applicazioni Android.
  • NON DEVE essere avviato con, essere concesso o concedere ad altre applicazioni privilegi del super user (root) o di qualsiasi altro ID utente.

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

Durante l'installazione di applicazioni, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione. Se un'applicazione deve utilizzare una risorsa dispositivo per la quale esiste un'autorizzazione Android corrispondente (ad esempio Fotocamera, GPS e così via), il runtime alternativo DEVE informare l'utente che l'applicazione sarà in grado di accedere a tale risorsa. Se l'ambiente di runtime non registra le funzionalità dell'applicazione in questo modo, l'ambiente di runtime DEVE elencare tutte le autorizzazioni di cui dispone il runtime durante l'installazione di qualsiasi applicazione che utilizza tale runtime.

9.5 Supporto di più utenti

Questa funzionalità è facoltativa per tutti i tipi di dispositivi.

Android include il supporto per più utenti e per l'isolamento completo degli utenti. Le implementazioni dei dispositivi POSSONO attivare più utenti, ma se attivate DEVONO soddisfare i seguenti requisiti relativi all'assistenza multiutente:

  • Le implementazioni dei dispositivi Android Automotive con il supporto multiutente attivato DEVONO includere un account ospite che consenta tutte le funzioni fornite dal sistema del veicolo senza richiedere all'utente di accedere.
  • 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 dei dispositivi possono configurare rapidamente ambienti separati in cui far lavorare altri utenti, con la possibilità di gestire limitazioni più granulari nelle app disponibili in questi ambienti.
  • Al contrario, le implementazioni dei dispositivi che dichiarano il flag della funzione android.hardware.telephony NON DEVONO supportare profili con limitazioni, ma DEVONO allinearsi con l'implementazione AOSP dei controlli 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 per sicurezza e autorizzazioni nelle API.
  • Ogni istanza utente su un dispositivo Android DEVE avere directory di archiviazione esterne separate e isolate. Le implementazioni dei dispositivi POTREBBERO memorizzare più dati sullo stesso volume o file system. Tuttavia, l'implementazione del dispositivo DEVE garantire che le applicazioni di proprietà di ed in esecuzione per conto di un determinato utente non possano elencare, leggere o scrivere nei dati di proprietà di qualsiasi altro utente. 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 crittografare i contenuti della scheda SD se l'opzione Multiutente è abilitata utilizzando una chiave archiviata solo su supporti non rimovibili accessibili solo al sistema. Dal momento che ciò renderà i contenuti illeggibili da parte di 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 nei dispositivi POSSONO, ma NON DEVONO abilitare l'opzione multiutente se utilizzano supporti rimovibili come unità di archiviazione esterna principale.

9.6. Avviso SMS premium

Android include il supporto per avvisare gli utenti di qualsiasi messaggio SMS premium in uscita. I messaggi SMS premium sono messaggi inviati a un servizio registrato con un operatore che può comportare un addebito per l'utente. Le implementazioni dei dispositivi che dichiarano il supporto per android.hardware.telephony DEVONO avvisare gli utenti prima di inviare un messaggio SMS a numeri identificati da espressioni regolari definite nel file /data/misc/sms/codes.xml nel dispositivo. Il progetto open source Android a monte fornisce un'implementazione che soddisfa questo requisito.

9.7 Funzionalità di sicurezza del kernel

Android Sandbox include funzionalità che utilizzano il sistema di controllo dell'accesso obbligatorio (MAC) di Linux (SELinux), la sandbox 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 una violazione della sicurezza, ma POTREBBE avere un'interfaccia utente visibile quando si verifica una violazione della sicurezza sbloccata che determina un exploit.
  • NON DEVE essere configurabile dall'utente o dallo sviluppatore.

Se un'API per la configurazione dei criteri viene esposta a un'applicazione che può influire su un'altra applicazione (ad esempio un'API di amministrazione dei dispositivi), l'API NON DEVE consentire configurazioni che interrompono la compatibilità.

I dispositivi DEVONO implementare SELinux o, se si usa un kernel diverso da Linux, un sistema di controllo dell'accesso obbligatorio equivalente. I dispositivi DEVONO inoltre soddisfare i seguenti requisiti, che vengono soddisfatti dall'implementazione di riferimento nell'Android Open Source Project a monte.

Implementazioni dei dispositivi:

  • DEVE impostare SELinux sulla modalità di applicazione globale.
  • DEVE configurare tutti i domini in modalità di applicazione forzata. Non sono consentiti domini in modalità permissiva, inclusi quelli specifici di un dispositivo/fornitore.
  • NON DEVE modificare, omettere o sostituire le regole non consentite all'interno della cartella del sistema/sepolicy fornita nell'AOSP (Android Open Source Project) upstream e il criterio DEVE essere compilato con tutte le regole non consentite presenti sia per i domini AOSP SELinux sia per i domini specifici del dispositivo/fornitore.
  • DEVE suddividere il framework multimediale in più processi in modo che sia possibile concedere in modo più limitato l'accesso a ogni processo come descritto nel sito del progetto open source Android.

Le implementazioni dei dispositivi DEVONO mantenere il criterio SELinux predefinito fornito nella cartella di sistema/sepolicy del progetto open source Android a monte e aggiungere ulteriormente a questo criterio solo per la configurazione specifica del dispositivo. Le implementazioni dei dispositivi DEVONO essere compatibili con l'upstream Android Open Source Project.

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 open source Android upstream soddisfa questo requisito mediante l'abilitazione di 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 una funzionalità che acquisisce i contenuti visualizzati sullo schermo e/o registra lo stream audio riprodotto al suo interno, DEVE informare continuamente l'utente ogni volta che questa funzionalità viene attivata e l'acquisizione/registrazione attiva è attiva.

Se l'implementazione di un dispositivo ha un meccanismo che instrada il traffico di dati di rete attraverso un server proxy o un gateway VPN (ad esempio, precaricando un servizio VPN con android.permission.CONTROL_VPN concesso), l'implementazione del dispositivo DEVE richiedere il consenso dell'utente prima di attivare il meccanismo, a meno che la VPN non sia attivata dal controller dei criteri dei dispositivi tramite DevicePolicyManager.setAlwaysOnVpnPackage(). In questo caso l'utente non deve fornire un consenso separato, ma DEVE ricevere soltanto una notifica.

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

Quando i dispositivi vengono indirizzati tramite una VPN o quando viene installata una CA radice dell'utente, l'implementazione DEVE mostrare un avviso che indica che il traffico di rete potrebbe essere monitorato per l'utente.

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

9,9 Crittografia archiviazione dati

Facoltativo per le implementazioni su dispositivi Android senza una schermata di blocco sicura.

Se l'implementazione del dispositivo supporta una schermata di blocco protetta come descritto nella sezione 9.11.1, il dispositivo DEVE supportare la crittografia dell'archiviazione dei dati dei dati privati dell'applicazione (/partizione dati), così come la partizione dello spazio di archiviazione condiviso dell'applicazione (partizione scheda SD) se è una parte permanente e non rimovibile del dispositivo.

Per le implementazioni dei dispositivi che supportano la crittografia dell'archiviazione dei dati e le prestazioni crittografiche Advanced Encryption Standard (AES) sono superiori a 50 MiB/sec, la crittografia dell'archiviazione dei dati DEVE essere attivata per impostazione predefinita nel momento in cui l'utente ha completato l'esperienza di configurazione immediata. Se l'implementazione di un dispositivo è già stata avviata su una versione precedente di Android e la crittografia è disattivata per impostazione predefinita, un dispositivo di questo tipo non può soddisfare i requisiti tramite un aggiornamento software di sistema e, pertanto, POTREBBE essere esentato.

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

9.9.1. Avvio diretto

Tutti i dispositivi DEVONO implementare le API in modalità di avvio diretto anche se non supportano Storage Encryption. In particolare, gli intent LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED devono comunque essere trasmessi per segnalare alle applicazioni sensibili all'avvio diretto che le posizioni di archiviazione con crittografia dei dispositivi (DE) e con credenziali criptate (CE) sono disponibili per gli utenti.

9.9.2. Crittografia basata su file

Implementazioni dei dispositivi che supportano FBE:

  • DEVE avviarsi senza richiedere le credenziali all'utente e consentire alle app sensibili all'avvio diretto di accedere allo spazio di archiviazione con crittografia del dispositivo (DE) dopo la trasmissione del messaggio LOCKED_BOOT_COMPLETED.
  • DEVE consentire l'accesso allo spazio di archiviazione con crittografia CE (Credential Encrypted) solo dopo che l'utente ha sbloccato il dispositivo fornendo le proprie credenziali (ad esempio passcode, PIN, sequenza o impronta) e dopo che è stato trasmesso il messaggio ACTION_USER_UNLOCKED. Le implementazioni dei dispositivi NON DEVONO offrire alcun metodo per sbloccare lo spazio di archiviazione protetto da CE senza le credenziali fornite dall'utente.
  • DEVE supportare l'Avvio verificato e garantire che le chiavi DE siano criptate in modo crittografico alla radice di attendibilità hardware del dispositivo.
  • DEVE supportare la crittografia dei contenuti dei file utilizzando AES con una chiave di lunghezza a 256 bit in modalità XTS.
  • DEVE supportare la crittografia del nome del file utilizzando AES con una chiave di lunghezza di 256 bit in modalità CBC-CTS.
  • POSSONO supportare crittografie alternative, lunghezze e modalità delle chiavi per il contenuto dei file e la crittografia dei nomi dei file, ma DEVONO utilizzare per impostazione predefinita le crittografie, le lunghezze e le modalità della chiave obbligatoriamente supportate.
  • DEVI mettere in evidenza le app essenziali precaricate (ad es. Sveglia, Telefono, Messenger) nell'Avvio diretto.

I token che proteggono le aree di stoccaggio CE e DE:

  • DEVE essere associato tramite crittografia a un archivio chiavi supportato da 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.
  • DEVE essere univoca e distinta, in altre parole nessuna chiave CE o DE di un utente può corrispondere alle chiavi CE o DE di un altro utente.

Il progetto open source Android 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 dei dispositivi che supportano la crittografia completa del disco (FDE). DEVE utilizzare AES con una chiave a 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. Tranne quando in uso attivo, la chiave di crittografia DEVE essere criptata con AES con le credenziali della schermata di blocco ampliate utilizzando un algoritmo di stretching lento (ad es. PBKDF2 o scrypt). Se l'utente non ha specificato le credenziali della schermata di blocco o ha disattivato l'uso del passcode per la crittografia, il sistema DEVE utilizzare un passcode predefinito per eseguire il wrapping della chiave di crittografia. Se il dispositivo fornisce un archivio chiavi supportato da hardware, l'algoritmo di stretching della password DEVE essere crittograficamente associato a questo archivio chiavi. La chiave di crittografia NON DEVE essere spedita dal dispositivo (nemmeno se è crittografata con il passcode dell'utente e/o la chiave associata all'hardware). Il progetto open source Android upstream fornisce un'implementazione preferita di questa funzionalità basata sulla funzionalità kernel Linux dm-crypt.

9.10. Integrità del dispositivo

I seguenti requisiti garantiscono che lo stato di integrità del dispositivo sia trasparenza.

Le implementazioni dei dispositivi DEVONO segnalare correttamente tramite il metodo dell'API di sistema PersistentDataBlockManager.getFlashLockState() se il relativo 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 questo nuovo metodo API di sistema non esisteva.

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

  • Dichiara il flag della funzionalità della piattaforma android.software.verify_boot.
  • Esegui la verifica per ogni sequenza di avvio.
  • Inizia la verifica da una chiave hardware immutabile che è la radice di attendibilità e arriva 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 quanto gli attuali consigli del 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 acconsenta comunque a tentare l'avvio; in questo caso i dati di eventuali blocchi di archiviazione non verificati 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 open source Android upstream fornisce un'implementazione preferita di questa funzionalità basata sulla funzionalità kernel Linux dm-verity.

A partire da Android 6.0, le implementazioni dei dispositivi con prestazioni crittografiche Advanced Encryption Standard (AES) superiori a 50 MiB/secondo DEVONO supportare l'avvio verificato per l'integrità del dispositivo.

Se un'implementazione di un dispositivo è già stata avviata senza supportare l'avvio verificato su una versione precedente di Android, questi dispositivi non possono aggiungere il supporto di questa funzionalità con un aggiornamento del software di sistema e sono quindi esentati dal requisito.

9.11. Chiavi e credenziali

Il sistema Android Keystore consente agli sviluppatori di app di archiviare le chiavi di crittografia in un container e di utilizzarle in operazioni crittografiche tramite l'API KeyChain o l'API Keystore.

Tutte le implementazioni sui 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 8.192 chiavi.
  • L'autenticazione della schermata di blocco DEVE limitare i tentativi e DEVE avere un algoritmo di backoff esponenziale. Oltre i 150 tentativi non riusciti, il ritardo DEVE essere di almeno 24 ore per tentativo.
  • Se l'implementazione del dispositivo supporta una schermata di blocco sicura, DEVE eseguire il backup dell'implementazione dell'archivio chiavi con hardware sicuro e soddisfare i seguenti requisiti:
    • DEVONO avere implementazioni supportate dall'hardware degli algoritmi crittografici RSA, AES, ECDSA e HMAC e delle funzioni di hash della famiglia MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati del sistema dell'archivio chiavi Android.
    • DEVE eseguire l'autenticazione della schermata di blocco nell'hardware sicuro e solo in caso di esito positivo consentire l'utilizzo delle chiavi associate all'autenticazione. Il progetto open source Android upstream fornisce il livello Gatekeeper Hardware Abstraction Layer (HAL) che può essere utilizzato per soddisfare questo requisito.

Tieni presente che se un'implementazione del dispositivo è già stata avviata su una versione precedente di Android, un dispositivo di questo tipo è esonerato dal requisito di un archivio chiavi supportato dall'hardware, a meno che non dichiari la funzionalità android.hardware.fingerprint che richiede un archivio chiavi supportato da 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 secret noto, NON DEVE essere trattato come una schermata di blocco sicura, a meno che non soddisfi tutti i requisiti seguenti:
    • L'entropia della lunghezza di input minima consentita 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à delle 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 località, NON DEVE essere trattato come una schermata di blocco sicura, a meno che non soddisfi tutti i requisiti seguenti:
    • DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali che si basa su un secret noto e soddisfa i requisiti per essere trattato come una schermata di blocco sicura.
    • DEVE essere disattivato e consentire all'autenticazione principale di sbloccare lo schermo solo se l'applicazione Device Policy Controller (DPC) ha impostato il criterio con il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o 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 come una schermata di blocco sicura, a meno che non soddisfi tutti i requisiti seguenti:
    • DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali che si basa su un secret noto e soddisfa i requisiti per essere trattato come una schermata di blocco sicura.
    • DEVE essere disattivato e consentire all'autenticazione principale di sbloccare lo schermo solo 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 falsa accettazione uguale o superiore a quello richiesto per un sensore di impronte digitali come descritto nella sezione 7.3.10 oppure DEVE essere disattivato e DEVE essere disattivato e deve consentire all'autenticazione principale di sbloccare lo schermo soltanto quando l'applicazione del controller dei criteri dei dispositivi (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 come una schermata di blocco sicura:
  • Se il metodo di autenticazione si basa su un token fisico, sulla posizione o sulla biometria con un tasso di accettazione falsa più elevato rispetto a quanto richiesto per i sensori di impronte digitali come descritto nella sezione 7.3.10, tale metodo:

9.12. Eliminazione dei dati

I dispositivi DEVONO fornire agli utenti un meccanismo per eseguire un "ripristino dei dati di fabbrica" che consente la cancellazione logica e fisica di tutti i dati, ad eccezione di quanto segue:

  • L'immagine di sistema
  • Tutti i file del sistema operativo richiesti dall'immagine di sistema

Tutti i dati generati dagli utenti DEVONO essere eliminati. DEVE soddisfare gli standard di settore pertinenti per l'eliminazione dei dati, come NIST SP800-88. DEVE essere utilizzato per l'implementazione dell'API wipeData() (parte dell'API Android Device Administration) descritta nella sezione 3.9 Amministrazione dispositivo.

I dispositivi POSSONO fornire una cancellazione rapida dei dati che comporti una cancellazione logica dei dati.

9.13. Modalità di avvio protetto

Android offre una modalità che consente agli utenti di avviare una modalità in cui possono essere eseguite solo le app di sistema preinstallate e tutte le app di terze parti sono disattivate. Questa modalità, nota come "Avvio sicuro", offre all'utente la possibilità di disinstallare app di terze parti potenzialmente dannose.

Le implementazioni dei dispositivi Android sono VIVAMENTE CONSIGLIATE per implementare la modalità di avvio protetto e soddisfare i seguenti requisiti:

  • Le implementazioni del dispositivo DEVONO fornire all'utente la possibilità di attivare la modalità di avvio protetto dal menu di avvio, raggiungibile attraverso un flusso di lavoro diverso da quello del normale avvio.

  • Le implementazioni dei dispositivi DEVONO offrire all'utente la possibilità di attivare la modalità di avvio protetto in modo tale che non possa essere interrotta dalle app di terze parti installate sul dispositivo, tranne nei casi in cui l'app di terze parti sia un controller dei criteri dei dispositivi e abbia impostato il flag UserManager.DISALLOW_SAFE_BOOT su true.

  • Le implementazioni del dispositivo DEVONO fornire all'utente la possibilità di disinstallare eventuali app di terze parti in modalità provvisoria.

9.14. Isolamento dei sistemi per veicoli automobilistici

I dispositivi Android Automotive dovrebbero scambiare dati con sottosistemi critici dei veicoli, ad esempio utilizzando l'HAL del veicolo per inviare e ricevere messaggi sulle reti di veicoli come il bus CAN. Le implementazioni dei dispositivi Android Automotive DEVONO implementare funzionalità di sicurezza al di sotto dei livelli del framework Android per impedire interazioni dannose o non intenzionali tra il framework Android o app di terze parti e sottosistemi dei veicoli. Le funzionalità di sicurezza sono le seguenti:

  • Protezione dei messaggi provenienti dai sottosistemi dei veicoli del framework Android, ad esempio l'inserimento nella lista consentita di tipi di messaggi e origini messaggi consentiti.
  • Fai attenzione agli attacchi denial of service da parte del framework Android o di app di terze parti. Questo protegge da software dannoso che inonda di traffico la rete veicolare, 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 è del tutto completo. Per questo motivo, agli utenti che implementano i dispositivi è CONSIGLIATO di apportare il numero minimo di modifiche possibile al riferimento e all'implementazione preferita di Android disponibili nel progetto open source Android. In questo modo si ridurrà al minimo il rischio di introdurre bug che creano incompatibilità che richiedono rielaborazione e potenziali aggiornamenti dei dispositivi.

10.1 Suite di test di compatibilità

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

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi altro software, il CTS stesso può contenere dei bug. Il CTS verrà sottoposto al controllo delle versioni indipendentemente da questa Definizione di compatibilità e potrebbero essere rilasciate più revisioni per Android 7.0. Le implementazioni dei dispositivi DEVONO superare l'ultima versione CTS disponibile al momento del completamento del software del dispositivo.

10.2. Verificatore CTS

Le implementazioni dei dispositivi DEVONO eseguire correttamente tutti i casi applicabili nello strumento di verifica CTS. Lo strumento di verifica CTS è incluso nella suite di test di compatibilità ed è destinato a essere eseguito da un operatore umano per testare funzionalità che non possono essere testate da un sistema automatico, come il corretto funzionamento di una fotocamera e dei sensori.

Lo strumento di verifica CTS effettua test per molti tipi di hardware, inclusi alcuni hardware facoltativi. Le implementazioni dei dispositivi DEVONO superare tutti i test relativi all'hardware in possesso. Ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente lo scenario di test dell'accelerometro nello strumento di verifica CTS. Gli scenari di test per le funzionalità indicate come facoltative nel presente documento sulla definizione di compatibilità POSSONO essere ignorati o omessi.

Ogni dispositivo e ogni build DEVONO eseguire correttamente lo strumento di verifica CTS, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementer dei dispositivi eseguano in modo esplicito CTS Verifier su build che differiscono solo per aspetti banali. In particolare, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato lo strumento di verifica CTS solo per il set di paesi, branding e così via inclusi. POSSONO omettere il test di verifica CTS.

11. Software aggiornabile

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

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

  • Download di "over-the-air (OTA)" con aggiornamento offline tramite riavvio.
  • Aggiornamenti "con tethering" tramite USB da un PC host.
  • "Offline" si aggiorna tramite riavvio e aggiornamento da un file su uno spazio di archiviazione rimovibile.

Tuttavia, se l'implementazione del dispositivo include il supporto per una connessione dati senza limiti 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 conservare i dati privati e quelli condivisi dall'applicazione. Tieni presente che il software Android upstream include un meccanismo di aggiornamento che soddisfa questo requisito.

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

Se viene rilevato un errore nell'implementazione di un dispositivo dopo che è stato rilasciato, ma entro il suo ciclo di vita ragionevole del prodotto, determinato in consultazione con il team per la compatibilità Android per incidere sulla compatibilità delle applicazioni di terze parti, l'implementatore del dispositivo DEVE correggerlo tramite un aggiornamento software disponibile che possa essere applicato in base al meccanismo appena descritto.

Android include funzionalità che consentono all'app Proprietario del dispositivo (se presente) di controllare l'installazione degli aggiornamenti di sistema. Per facilitare questa operazione, il sottosistema dell'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:

Per un riepilogo delle modifiche apportate alle sezioni delle singole persone:

  1. Introduzione
  2. Tipi di dispositivi
  3. Software
  4. Pacchetto 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 del documento
  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 relative all'aspetto o all'edilizia.

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 sulla compatibilità con Android e chiedere chiarimenti o segnalare eventuali problemi che ritieni non siano trattati nel documento.