Revisione 1
Ultimo aggiornamento: 12 gennaio 2015
Copyright © 2015, Google Inc. Tutti i diritti riservati.
compatibility@android.com
Indice
1. Introduzione
Questo documento elenca i requisiti che devono essere soddisfatti affinché i dispositivi siano compatibili con Android 5.0.
L'uso di "DEVE", "NON DEVE", "OBBLIGATORIO", "DEVE", "NON DEVE", "DEVE", "NON DEVE", "CONSIGLIATO", "PU" e "FACOLTATIVO" è conforme allo standard IETF definito in RFC2119 [Risorse, 1].
Come utilizzato in questo documento, un "implementatore del dispositivo" o "implementatore" è una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 5.0. Un'"implementazione del dispositivo" o "implementazione" è la soluzione hardware/software così sviluppata.
Per essere considerate compatibili con Android 5.0, le implementazioni dei dispositivi DEVONO soddisfare i requisiti presentati in questa definizione di compatibilità, inclusi eventuali documenti incorporati tramite riferimento.
Se questa definizione o i test software descritti nella sezione 10 non sono chiari, ambigui o incompleti, è responsabilità dell'implementatore del dispositivo garantire la compatibilità con le implementazioni esistenti.
Per questo motivo, Android Open Source Project [Risorse, 2] è sia l'implementazione di riferimento sia quella preferita di Android. Gli implementatori di dispositivi sono vivamente incoraggiati a basare le proprie implementazioni, nella misura del possibile, sul codice sorgente "upstream" disponibile nell'Android Open Source Project. Sebbene alcuni componenti possano essere ipotetticamente sostituiti con implementazioni alternative, questa pratica è vivamente sconsigliata, in quanto superare i test software diventerà notevolmente più difficile. È responsabilità dell'implementatore garantire la piena compatibilità comportamentale con l'implementazione standard di Android, incluso e oltre il Compatibility Test Suite. Infine, tieni presente che alcune sostituzioni e modifiche dei componenti sono esplicitamente vietate da questo documento.
Molte delle risorse elencate nella sezione 14 sono ricavate direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni riportate nella documentazione dell'SDK. In tutti i casi in cui questa definizione di compatibilità o la suite di test di compatibilità non è in accordo con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Eventuali dettagli tecnici forniti nei riferimenti inclusi nella sezione 14 sono considerati parte di questa definizione di compatibilità.
2. Tipi di dispositivi
Sebbene il progetto open source Android sia stato utilizzato per l'implementazione di una varietà di tipi di dispositivi e fattori di forma, molti aspetti dell'architettura e dei requisiti di compatibilità sono stati ottimizzati per i dispositivi portatili. A partire da Android 5.0, l'Android Open Source Project mira a supportare una gamma più ampia di tipi di dispositivi, come descritto in questa sezione.
Per Dispositivo Android portatile si intende un'implementazione di un dispositivo Android che in genere viene utilizzato tenendolo in mano, ad esempio lettori MP3, telefoni e tablet. Implementazioni di dispositivi Android portatili:
- DEVE avere un touchscreen integrato nel dispositivo
- DEVE avere una fonte di alimentazione che offra mobilità, ad esempio una batteria
Per dispositivo Android TV si intende un'implementazione di un dispositivo Android che è un'interfaccia di intrattenimento per la fruizione di contenuti multimediali digitali, film, giochi, app e/o TV in diretta per gli utenti seduti a circa tre metri di distanza (un'interfaccia utente "lean back" o "10-foot"). Dispositivi Android TV:
- DEVE avere uno schermo integrato OPPURE includere una porta di uscita video, ad esempio VGA, HDMI o una porta wireless per il display
- DEVI dichiarare le funzionalità android.software.leanback e android.hardware.type.television [Risorse, 3]
Per dispositivo Android Watch si intende un'implementazione di un dispositivo Android progettata per essere indossata sul corpo, possibly sul polso, e:
- DEVE avere uno schermo con una lunghezza diagonale fisica compresa tra 28 e 64 mm
- DEVE dichiarare la funzionalità android.hardware.type.watch
- DEVE supportare uiMode = UI_MODE_TYPE_WATCH [Risorse, 4]
Tutte le implementazioni di dispositivi Android che non rientrano in nessuno dei tipi di dispositivi sopra indicati DEVONO comunque soddisfare tutti i requisiti di questo documento per essere compatibili con Android 5.0, a meno che il requisito non sia descritto esplicitamente come applicabile solo a un tipo specifico di dispositivo Android.
2.1 Configurazioni del dispositivo
Questo è un riepilogo delle principali differenze nella configurazione hardware in base al tipo di dispositivo. (Le celle vuote indicano un valore "POTREBBE"). Non tutte le configurazioni sono coperte da questa tabella. Per maggiori dettagli, consulta le sezioni hardware pertinenti.
|
Categoria |
Nome |
Sezione |
Dispositivo palmare |
Televisione |
Guarda |
Altro |
|
Input |
D-pad |
MUST |
||||
|
Touchscreen |
MUST |
MUST |
DOVREBBE |
|||
|
Microfono |
MUST |
DOVREBBE |
MUST |
DOVREBBE |
||
|
Sensori |
Accelerometro |
DOVREBBE |
DOVREBBE |
DOVREBBE |
||
|
GPS |
DOVREBBE |
|||||
|
Connettività |
Wi-Fi |
DOVREBBE |
MUST |
DOVREBBE |
||
|
Wi-Fi Direct |
DOVREBBE |
DOVREBBE |
DOVREBBE |
|||
|
Bluetooth |
DOVREBBE |
MUST |
MUST |
DOVREBBE |
||
|
Bluetooth Low Energy |
DOVREBBE |
MUST |
DOVREBBE |
DOVREBBE |
||
|
Modalità periferica/ host USB |
DOVREBBE |
|
DOVREBBE |
|||
|
Output |
Porte di uscita audio e/o altoparlanti |
MUST |
MUST |
MUST |
3. Software
3.1. Compatibilità con le API gestite
L'ambiente di esecuzione del bytecode Dalvik gestito è il veicolo principale per le applicazioni Android. L'API (interfaccia di programmazione di un'applicazione) Android è l'insieme di interfacce della piattaforma Android esposte alle applicazioni in esecuzione nell'ambiente di runtime gestito. Le implementazioni dei dispositivi DEVONO fornire implementazioni complete, inclusi tutti i comportamenti documentati, di qualsiasi API documentata esposta dall'SDK Android [Risorse, 5] o di qualsiasi API decorata con l'indicatore "@SystemApi" nel codice sorgente Android upstream.
Le implementazioni dei dispositivi NON DEVONO omettere API gestite, modificare interfacce o firme dell'API, discostarsi dal comportamento documentato o includere no-op, tranne dove specificamente consentito da questa definizione di compatibilità.
Questa definizione di compatibilità consente di omettere alcune implementazioni di dispositivi per alcuni tipi di hardware per i quali Android include API. In questi casi, le API devono essere ancora presenti e comportarsi in modo ragionevole. Consulta la sezione 7 per i requisiti specifici di questo scenario.
3.2. Compatibilità API soft
Oltre alle API gestite della sezione 3.1, Android include anche un'API "soft" significativa solo di runtime, sotto forma di elementi come intent, autorizzazioni e aspetti simili delle applicazioni Android che non possono essere applicati al momento della compilazione dell'applicazione.
3.2.1. Autorizzazioni
Gli implementatori dei dispositivi DEVONO supportare e applicare tutte le costanti di autorizzazione come documentato nella pagina di riferimento delle autorizzazioni [Risorse, 6]. Tieni presente che la sezione 9 elenca requisiti aggiuntivi relativi al modello di sicurezza di Android.
3.2.2. Parametri di compilazione
Le API Android includono una serie di costanti nella classe android.os.Build [Resources, 7] che hanno lo scopo di descrivere il dispositivo corrente. Per fornire valori coerenti e significativi per tutte le implementazioni dei dispositivi, la tabella seguente include ulteriori limitazioni relative ai formati di questi valori a cui le implementazioni dei dispositivi DEVONO essere conformi.
|
Parametro |
Dettagli |
|
VERSION.RELEASE |
La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE avere uno dei valori di stringa definiti in [Resources, 8]. |
|
VERSION.SDK |
La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 5.0, questo campo DEVE avere il valore intero 21. |
|
VERSION.SDK_INT |
La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 5.0, questo campo DEVE avere il valore intero 21. |
|
VERSION.INCREMENTAL |
Un valore scelto dall'implementatore del dispositivo che designa la build specifica del sistema Android attualmente in esecuzione, in formato leggibile. Questo valore NON deve essere riutilizzato per build diverse rese disponibili agli utenti finali. Un utilizzo tipico di questo campo è indicare il numero di build o l'identificatore della modifica del controllo del codice sorgente utilizzato per generare la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota (""). |
|
DA TAVOLO |
Un valore scelto dall'implementatore del dispositivo che identifica l'hardware interno specifico utilizzato dal dispositivo, in formato leggibile. Un possibile utilizzo di questo campo è indicare la revisione specifica della scheda che alimenta il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". |
|
BRAND |
Un valore che riflette il nome del brand associato al dispositivo, come noto agli utenti finali. DEVE essere in un formato leggibile e DEVE rappresentare il produttore del dispositivo o il brand dell'azienda con cui viene commercializzato il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". |
|
SUPPORTED_ABIS |
Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native. |
|
SUPPORTED_32_BIT_ABIS |
Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native. |
|
SUPPORTED_64_BIT_ABIS |
Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native. |
|
CPU_ABI |
Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native. |
|
CPU_ABI2 |
Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native. |
|
DISPOSITIVO |
Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice che identifica la configurazione delle funzionalità hardware e il design industriale del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". |
|
FINGERPRINT |
Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile da una persona. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ad esempio: acme/myproduct/mydevice:5.0/LRWXX/3359:userdebug/test-keys L'impronta NON DEVE includere caratteri di spazio vuoto. Se altri campi inclusi nel modello riportato sopra contengono caratteri di spazi vuoti, DEVONO essere sostituiti nell'impronta della build con un altro carattere, ad esempio l'underscore ("_"). Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit. |
|
HARDWARE |
Il nome dell'hardware (dalla riga di comando del kernel o da /proc). DOVREBBE essere ragionevolmente leggibile da una persona. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". |
|
ORGANIZZATORE |
Una stringa che identifica in modo univoco l'host su cui è stata eseguita la compilazione, in formato leggibile da un essere umano. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota (""). |
|
ID |
Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in formato leggibile da una persona. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere le build software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$". |
|
PRODUTTORE |
La ragione sociale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota (""). |
|
MODELLO |
Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo come conosciuto dall'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o una stringa vuota (""). |
|
PRODOTTO |
Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice del prodotto specifico (SKU) che DEVE essere univoco all'interno dello stesso marchio. DEVE essere leggibile, ma non necessariamente destinato alla visualizzazione da parte degli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". |
|
SERIALE |
Un numero di serie hardware, che DEVE essere disponibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^([a-zA-Z0-9]{6,20})$". |
|
TAG |
Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che distingue ulteriormente la build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni di firma della piattaforma Android: release-keys, dev-keys, test-keys. |
|
DURATA |
Un valore che rappresenta il timestamp della compilazione. |
|
MACCHINA |
Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni di runtime Android: user, userdebug o eng. |
|
UTENTE |
Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota (""). |
3.2.3. Compatibilità con gli intent
Le implementazioni dei dispositivi DEVONO rispettare il sistema di intent a disaccoppiamento flessibile di Android, come descritto nelle sezioni seguenti. Per "rispettato" si intende che l'implementatore del dispositivo DEVE fornire un'attività o un servizio Android che specifichi un filtro per intent corrispondente che si leghi e implementi il comportamento corretto per ogni pattern di intent specificato.
3.2.3.1. Intent di applicazione principali
Gli intent Android consentono ai componenti dell'applicazione di richiedere funzionalità da altri componenti Android. Il progetto upstream di Android include un elenco di applicazioni considerate applicazioni Android di base, che implementano diversi pattern di intent per eseguire azioni comuni. Le applicazioni Android di base sono:
- Orologio da scrivania
- Browser
- Calendar
- Contatti
- Galleria
- GlobalSearch
- Avvio app
- Musica
- Impostazioni
Le implementazioni dei dispositivi DOVREBBERO includere le applicazioni Android di base come appropriato, ma DEVONO includere un componente che implementi gli stessi pattern di intent definiti da tutti i componenti di attività o servizio "pubblici" di queste applicazioni Android di base. Tieni presente che i componenti Activity o Service sono considerati "pubblici" quando l'attributo android:exported è assente o ha il valore true.
3.2.3.2. Sostituzioni di intent
Poiché Android è una piattaforma estensibile, le implementazioni dei dispositivi DEVONO consentire a ogni pattern di intent a cui si fa riferimento nella sezione 3.2.3.1 di essere sostituito da applicazioni di terze parti. L'implementazione open source di Android upstream lo consente per impostazione predefinita; gli implementatori dei dispositivi NON DEVONO associare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema o impedire alle applicazioni di terze parti di associarsi a questi pattern e assumerne il controllo. Questo divieto include, in particolare, ma non è limitato a, la disattivazione dell'interfaccia utente "Chooser" che consente all'utente di scegliere tra più applicazioni che gestiscono tutte lo stesso pattern di intent.
Tuttavia, le implementazioni dei dispositivi POSSONO fornire attività predefinite per pattern URI specifici (ad es. http://play.google.com) se l'attività predefinita fornisce un filtro più specifico per l'URI dati. Ad esempio, un filtro per intent che specifica l'URI dati "http://www.android.com" è più specifico del filtro del browser per "http://". Le implementazioni dei dispositivi DEVONO fornire un'interfaccia utente che consenta agli utenti di modificare l'attività predefinita per gli intent.
3.2.3.3. Spazi dei nomi degli intent
Le implementazioni dei dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o di trasmissione di intent utilizzando una stringa ACTION, CATEGORY o di altro tipo nell'ambito dello spazio dei nomi android.* o com.android.*. Gli implementatori di dispositivi NON devono includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando ACTION, CATEGORY o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione. Gli implementatori dei dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent utilizzati dalle app di base elencate nella sezione 3.2.3.1. Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano spazi dei nomi associati chiaramente e in modo evidente alla propria organizzazione. Questo divieto è analogo a quello specificato per le classi di lingua Java nella sezione 3.6.
3.2.3.4. Intent di trasmissione
Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent per informarle delle modifiche nell'ambiente hardware o software. I dispositivi compatibili con Android DEVONO trasmettere gli intent di trasmissione pubblica in risposta a eventi di sistema appropriati. Gli intent di trasmissione sono descritti nella documentazione dell'SDK.
3.2.3.5. Impostazioni app predefinite
Android include impostazioni che offrono agli utenti un modo semplice per selezionare le applicazioni predefinite, ad esempio per la schermata Home o gli SMS. Ove opportuno, le implementazioni dei dispositivi DEVONO fornire un menu Impostazioni simile ed essere compatibili con il pattern di filtro degli intent e i metodi API descritti nella documentazione dell'SDK come indicato di seguito.
Implementazioni dei dispositivi:
- DEVE rispettare l'intent android.settings.HOME_SETTINGS per mostrare un menu delle impostazioni predefinite dell'app per la schermata Home, se l'implementazione del dispositivo segnala android.software.home_screen [Risorse, 10]
- DEVE fornire un menu Impostazioni che chiami l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT per mostrare una finestra di dialogo per modificare l'applicazione SMS predefinita, se l'implementazione del dispositivo segnala android.hardware.telephony [Risorse, 9]
- DEVE rispettare l'intent android.settings.NFC_PAYMENT_SETTINGS per mostrare un menu di impostazioni predefinite dell'app per il pagamento contactless, se l'implementazione del dispositivo segnala android.hardware.nfc.hce [Risorse, 10]
3.3. Compatibilità con le API native
3.3.1 Interfacce a livello di codice dell'applicazione
Il bytecode Dalvik gestito può chiamare il codice nativo fornito nel file .apk dell'applicazione come file .so ELF compilato per l'architettura hardware del dispositivo appropriata. Poiché il codice nativo è altamente dipendente dalla tecnologia del processore sottostante, Android definisce una serie di interfacce a livello di codice macchina (ABI) nell'NDK di Android. Le implementazioni dei dispositivi DEVONO essere compatibili con uno o più ABI definiti e DEVONO implementare la compatibilità con Android NDK, come indicato di seguito.
Se un'implementazione del dispositivo include il supporto di un'ABI Android:
- DEVE includere il supporto per il codice in esecuzione nell'ambiente gestito per chiamare il codice nativo utilizzando la semantica standard di Java Native Interface (JNI)
- DEVE essere compatibile con il codice sorgente (ovvero con l'intestazione) e con il codice binario (per l'ABI) con ogni libreria richiesta nell'elenco di seguito
- DEVE supportare l'ABI a 32 bit equivalente se è supportata un'ABI a 64 bit
- DEVE segnalare con precisione l'interfaccia a bit di applicazione (ABI) nativa supportata dal dispositivo tramite i parametri android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, ciascuno costituito da un elenco di ABI separati da virgola ordinati dal più preferito al meno preferito
- DEVE segnalare, tramite i parametri sopra indicati, solo gli ABI documentati nell'ultima versione dell'NDK di Android, "Guida per programmatori NDK | Gestione ABI" nella directory docs/
- DEVE essere compilato utilizzando il codice sorgente e i file di intestazione disponibili nell'upstream Android Open Source Project
Le seguenti API di codice nativo DEVONO essere disponibili per le app che includono codice nativo:
- libc (libreria C)
- libm (libreria matematica)
- Supporto minimo per C++
- Interfaccia JNI
- liblog (logging Android)
- libz (compressione Zlib)
- libdl (linker dinamico)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libEGL.so (gestione delle superfici OpenGL native)
- libjnigraphics.so
- libOpenSLES.so (supporto audio OpenSL ES 1.0.1)
- libOpenMAXAL.so (supporto di OpenMAX AL 1.0.1)
- libandroid.so (supporto delle attività native di Android)
- libmediandk.so (supporto delle API multimediali native)
- Supporto di OpenGL, come descritto di seguito
Tieni presente che le release future dell'Android NDK potrebbero introdurre il supporto di ABI aggiuntive. Se un'implementazione del dispositivo non è compatibile con un ABI predefinito esistente, NON DEVE segnalare il supporto di alcun ABI.
Tieni presente che le implementazioni del dispositivo DEVONO includere libGLESv3.so e DEVONO avere un link simbolico (symlink) a libGLESv2.so. A loro volta, DEVONO esportare tutti i simboli delle funzioni OpenGL ES 3.1 e Android Extension Pack [Risorse, 11] come definito nella release NDK android-21. Anche se tutti i simboli devono essere presenti, devono essere implementate completamente solo le funzioni corrispondenti per le versioni e le estensioni OpenGL ES effettivamente supportate dal dispositivo.
La compatibilità con il codice nativo è complessa. Per questo motivo, gli implementatori di dispositivi sono vivamente incoraggiati a utilizzare le implementazioni delle librerie elencate sopra dall'upstream Android Open Source Project.
3.4. Compatibilità web
3.4.1. Compatibilità con WebView
|
L'implementazione completa dell'API android.webkit.Webview PUÒ essere fornita su dispositivi Android Watch, ma DEVE essere fornita su tutti gli altri tipi di implementazioni di dispositivi. |
La funzionalità della piattaforma android.software.webview DEVE essere segnalata su qualsiasi dispositivo che fornisce un'implementazione completa dell'API android.webkit.WebView e NON DEVE essere segnalata sui dispositivi senza un'implementazione completa dell'API. L'implementazione di Android Open Source utilizza il codice del progetto Chromium per implementare android.webkit.WebView [Risorse, 12]. Poiché non è possibile sviluppare una suite di test completa per un sistema di rendering web, gli implementatori dei dispositivi DEVONO utilizzare la build upstream specifica di Chromium nell'implementazione di WebView. Nello specifico:
- Le implementazioni di android.webkit.WebView del dispositivo DEVONO essere basate sulla compilazione di Chromium proveniente dal progetto open source Android upstream per Android 5.0. Questa build include un insieme specifico di funzionalità e correzioni di sicurezza per WebView [Risorse, 13].
- La stringa dello user agent segnalata da WebView DEVE avere il seguente formato:
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)) AppleWebKit/537.36 (KHTML, come Gecko) Versione/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- Il valore della stringa $(VERSION) DEVE essere uguale al valore di android.os.Build.VERSION.RELEASE.
- Il valore della stringa $(MODEL) DEVE essere uguale al valore di android.os.Build.MODEL.
- Il valore della stringa $(BUILD) DEVE essere uguale al valore di android.os.Build.ID.
- Il valore della stringa $(CHROMIUM_VER) DEVE essere la versione di Chromium nel progetto open source Android di origine.
- Le implementazioni dei dispositivi POSSONO omettere Mobile nella stringa dello user agent.
Il componente WebView DEVE includere il supporto per il maggior numero possibile di funzionalità HTML5 e, se supporta la funzionalità, DEVE essere conforme alla specifica HTML5 [Risorse, 14].
3.4.2. Compatibilità del browser
|
I dispositivi Android TV e smartwatch POSSONO omettere un'applicazione del browser, ma DEVONO supportare i pattern di intent pubblici come descritto nella sezione 3.2.3.1. Tutti gli altri tipi di implementazioni dei dispositivi DEVONO includere un'applicazione browser autonoma per la navigazione web degli utenti generici. |
Il browser autonomo POTREBBE essere basato su una tecnologia di browser diversa da WebKit. Tuttavia, anche se viene utilizzata un'applicazione di browser alternativa, il componente android.webkit.WebView fornito alle applicazioni di terze parti DEVE essere basato su WebKit, come descritto nella sezione 3.4.1.
Le implementazioni POSSONO includere una stringa user agent personalizzata nell'applicazione Browser autonoma.
L'applicazione Browser autonoma (in base all'applicazione Browser WebKit di upstream o a una sostituzione di terze parti) DEVE includere il supporto per il maggior numero possibile di funzionalità HTML5 [Risorse, 14]. Come minimo, le implementazioni dei dispositivi DEVONO supportare ciascuna di queste API associate a HTML5:
- cache dell'applicazione/operazione offline [Resources, 15]
- il tag
- geolocalizzazione [Risorse, 17]
Inoltre, le implementazioni dei dispositivi DEVONO supportare l'API webstorage HTML5/W3C [Risorse, 18] e DOVREBBERO supportare l'API IndexedDB HTML5/W3C [Risorse, 19]. Tieni presente che, poiché gli enti di standardizzazione per lo sviluppo web stanno adottando IndexedDB al posto di webstorage, IndexedDB dovrebbe diventare un componente obbligatorio in una versione futura di Android.
3.5. Compatibilità comportamentale dell'API
Il comportamento di ciascuno dei tipi di API (gestite, soft, native e web) deve essere coerente con l'implementazione preferita del progetto Android Open Source upstream [Risorse, 2]. Ecco alcune aree specifiche di compatibilità:
- I dispositivi NON DEVONO modificare il comportamento o la semantica di uno scopo standard.
- I dispositivi NON DEVONO alterare il ciclo di vita o la semantica del ciclo di vita di un determinato tipo di componente di sistema (ad esempio Service, Activity, ContentProvider e così via).
- I dispositivi NON DEVONO modificare la semantica di un'autorizzazione standard.
L'elenco riportato sopra non è esaustivo. La Compatibility Test Suite (CTS) testa alcune parti significative della piattaforma per verificarne la compatibilità di comportamento, ma non tutte. È responsabilità dell'implementatore garantire la compatibilità del comportamento con Android Open Source Project. Per questo motivo, gli implementatori di dispositivi DEVONO utilizzare il codice sorgente disponibile tramite l'Android Open Source Project, ove possibile, anziché implementare nuovamente parti significative del sistema.
3.6. Spazi dei nomi API
Android segue le convenzioni relative allo spazio dei nomi dei pacchetti e delle classi definite dal linguaggio di programmazione Java. Per garantire la compatibilità con le applicazioni di terze parti, gli implementatori dei dispositivi NON DEVONO apportare modifiche vietate (vedi di seguito) a questi spazi dei nomi del pacchetto:
- java.*
- javax.*
- sole.*
- android.*
- com.android.*
Le modifiche vietate includono:
- Le implementazioni dei dispositivi NON DEVONO modificare le API esposte pubblicamente sulla piattaforma Android modificando le firme di metodi o classi o rimuovendo classi o campi di classi.
- Gli implementatori dei dispositivi POSSONO modificare l'implementazione sottostante delle API, ma queste modifiche NON DEVONO influire sul comportamento dichiarato e sulla firma in linguaggio Java di qualsiasi API esposta pubblicamente.
- Gli implementatori dei dispositivi NON DEVONO aggiungere elementi esposti pubblicamente (ad esempio classi o interfacce oppure campi o metodi a classi o interfacce esistenti) alle API sopra indicate.
Un "elemento esposto pubblicamente" è qualsiasi costrutto non decorato con l'indicatore "@hide" come utilizzato nel codice sorgente di Android upstream. In altre parole, gli implementatori dei dispositivi NON DEVONO esporre nuove API o modificare quelle esistenti nei spazi dei nomi sopra indicati. Gli implementatori dei dispositivi POSSONO apportare modifiche solo per uso interno, ma queste modifiche NON DEVONO essere pubblicizzate o comunque esposte agli sviluppatori.
Gli implementatori dei dispositivi POSSONO aggiungere API personalizzate, ma queste API NON DEVONO trovarsi in un ambito di nomi di proprietà di un'altra organizzazione o che fanno riferimento a un'altra organizzazione. Ad esempio, gli implementatori di dispositivi NON DEVONO aggiungere API al namespace com.google.* o a un namespace simile: solo Google può farlo. Analogamente, Google NON DEVE aggiungere API ai namespace di altre aziende. Inoltre, se un'implementazione del dispositivo include API personalizzate al di fuori dello spazio dei nomi Android standard, queste API DEVONO essere pacchettizzate in una libreria condivisa di Android in modo che solo le app che le utilizzano esplicitamente (tramite il meccanismo
Se un implementatore di dispositivi propone di migliorare uno degli spazi dei nomi del pacchetto sopra indicati (ad esempio aggiungendo nuove funzionalità utili a un'API esistente o aggiungendo una nuova API), l'implementatore DEVE visitare source.android.com e avviare la procedura per contribuire con modifiche e codice, in base alle informazioni su quel sito.
Tieni presente che le limitazioni riportate sopra corrispondono alle convenzioni standard per la denominazione delle API nel linguaggio di programmazione Java. Lo scopo di questa sezione è semplicemente rafforzare queste convenzioni e renderle vincolanti tramite l'inclusione in questa definizione di compatibilità.
3.7. Compatibilità di runtime
Le implementazioni dei dispositivi DEVONO supportare il formato Dalvik Executable (DEX) completo e la specifica e la semantica del bytecode Dalvik [Risorse, 20]. Gli implementatori di dispositivi DEVONO utilizzare ART, l'implementazione upstream di riferimento del formato eseguibile Dalvik e il sistema di gestione dei pacchetti dell'implementazione di riferimento.
Le implementazioni dei dispositivi DEVONO configurare gli ambienti di runtime Dalvik per allocare la memoria in conformità con la piattaforma Android a monte e come specificato dalla tabella seguente. (consulta la sezione 7.1.1 per le definizioni delle dimensioni e della densità dello schermo).
Tieni presente che i valori di memoria specificati di seguito sono considerati valori minimi e le implementazioni dei dispositivi POSSONO allocare più memoria per applicazione.
|
Layout schermo |
Densità dello schermo |
Memoria dell'applicazione minima |
|
piccolo / normale |
120 dpi (ldpi) |
16MB |
|
160 dpi (mdpi) |
||
|
213 dpi (tvdpi) |
32MB |
|
|
240 dpi (hdpi) |
||
|
320 dpi (xhdpi) |
64MB |
|
|
400 dpi (400dpi) |
96MB |
|
|
480 dpi (xxhdpi) |
128MB |
|
|
560 dpi (560dpi) |
192MB |
|
|
640 dpi (xxxhdpi) |
256MB |
|
|
grande |
120 dpi (ldpi) |
16MB |
|
160 dpi (mdpi) |
32MB |
|
|
213 dpi (tvdpi) |
64MB |
|
|
240 dpi (hdpi) |
||
|
320 dpi (xhdpi) |
128MB |
|
|
400 dpi (400dpi) |
192MB |
|
|
480 dpi (xxhdpi) |
256MB |
|
|
560 dpi (560dpi) |
384MB |
|
|
640 dpi (xxxhdpi) |
512MB |
|
|
xlarge |
160 dpi (mdpi) |
64MB |
|
213 dpi (tvdpi) |
96MB |
|
|
240 dpi (hdpi) |
||
|
320 dpi (xhdpi) |
192MB |
|
|
400 dpi (400dpi) |
288MB |
|
|
480 dpi (xxhdpi) |
384MB |
|
|
560 dpi (560dpi) |
576MB |
|
|
640 dpi (xxxhdpi) |
768MB |
3.8. Compatibilità dell'interfaccia utente
3.8.1. Avvio app (schermata Home)
Android include un'applicazione Avvio app (schermata Home) e il supporto per applicazioni di terze parti che sostituiscono l'Avvio app del dispositivo (schermata Home). Le implementazioni del dispositivo che consentono ad applicazioni di terze parti di sostituire la schermata Home del dispositivo DEVONO dichiarare la funzionalità della piattaforma android.software.home_screen.
3.8.2. Widget
|
I widget sono facoltativi per tutte le implementazioni dei dispositivi Android, ma DEVONO essere supportati sui dispositivi Android portatili. |
Android definisce un tipo di componente e l'API e il ciclo di vita corrispondente che consente alle applicazioni di esporre un "AppWidget" all'utente finale [Risorse, 21], una funzionalità che è MOLTO CONSIGLIATO supportare nelle implementazioni dei dispositivi palmari. Le implementazioni dei dispositivi che supportano l'inserimento di widget nella schermata Home DEVONO soddisfare i seguenti requisiti e dichiarare il supporto della funzionalità della piattaforma android.software.app_widgets.
- Gli Avvio app dei dispositivi DEVONO includere il supporto integrato per gli AppWidget e mettere a disposizione dell'utente funzionalità di interfaccia per aggiungere, configurare, visualizzare e rimuovere gli AppWidget direttamente dall'Avvio app.
- Le implementazioni dei dispositivi DEVONO essere in grado di eseguire il rendering di widget di 4 x 4 nelle dimensioni della griglia standard. Per maggiori dettagli, consulta le linee guida per la progettazione di widget per app nella documentazione dell'SDK Android [Risorse, 21].
- Le implementazioni dei dispositivi che includono il supporto della schermata di blocco POTREBBERO supportare i widget delle applicazioni nella schermata di blocco.
3.8.3. Notifiche
Android include API che consentono agli sviluppatori di notificare agli utenti eventi importanti [Risorse, 22], utilizzando le funzionalità hardware e software del dispositivo.
Alcune API consentono alle applicazioni di eseguire notifiche o attirare l'attenzione utilizzando l'hardware, in particolare suono, vibrazione e luce. Le implementazioni dei dispositivi devono supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK e, nella misura del possibile, con l'hardware di implementazione del dispositivo. Ad esempio, se un'implementazione del dispositivo include un vibratore, DEVE implementare correttamente le API di vibrazione. Se l'implementazione di un dispositivo è priva di hardware, le API corrispondenti DEVONO essere implementate come no-op. Questo comportamento è descritto in modo più dettagliato nella sezione 7.
Inoltre, l'implementazione DEVE eseguire il rendering corretto di tutte le risorse (icone, file audio e così via) previste nelle API [Risorse, 23] o nella guida di stile delle icone della barra di stato/del sistema [Risorse, 24]. Gli implementatori dei dispositivi POSSONO fornire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'implementazione di riferimento di Android Open Source. Tuttavia, questi sistemi di notifica alternativi DEVONO supportare le risorse di notifica esistenti, come sopra indicato.
Android include il supporto di varie notifiche, ad esempio:
- Notifiche avanzate: visualizzazioni interattive per le notifiche in corso.
- Notifiche in primo piano: le visualizzazioni interattive che gli utenti possono ignorare o gestire senza uscire dall'app corrente.
- Notifiche sulla schermata di blocco: notifiche visualizzate su una schermata di blocco con controllo granulare sulla visibilità.
Le implementazioni dei dispositivi DEVONO mostrare ed eseguire correttamente queste notifiche, incluso il titolo/nome, l'icona e il testo come documentato nelle API Android [Risorse, 25].
Android include le API Notification Listener Service che consentono alle app (se attivate esplicitamente dall'utente) di ricevere una copia di tutte le notifiche man mano che vengono pubblicate o aggiornate. Le implementazioni dei dispositivi DEVONO inviare correttamente e tempestivamente le notifiche nella loro interezza a tutti i servizi di listener installati e abilitati dall'utente, inclusi tutti i metadati associati all'oggetto Notification.
3.8.4. Cerca
Android include API [Risorse, 26] che consentono agli sviluppatori di incorporare la ricerca nelle loro applicazioni e di mostrare i dati della loro applicazione nella ricerca di sistema globale. In generale, questa funzionalità consiste in un'unica interfaccia utente a livello di sistema che consente agli utenti di inserire query, visualizzare suggerimenti man mano che digitano e visualizzare i risultati. Le API Android consentono agli sviluppatori di riutilizzare questa interfaccia per fornire la ricerca all'interno delle proprie app e di fornire risultati all'interfaccia utente della ricerca globale comune.
Le implementazioni dei dispositivi Android DOVREBBERO includere la ricerca globale, un'interfaccia utente di ricerca singola, condivisa e di sistema in grado di fornire suggerimenti in tempo reale in risposta all'input dell'utente. Le implementazioni dei dispositivi DOVREBBERO implementare le API che consentono agli sviluppatori di riutilizzare questa interfaccia utente per fornire la ricerca all'interno delle proprie applicazioni. Le implementazioni dei dispositivi che implementano l'interfaccia di ricerca globale devono implementare le API che consentono alle applicazioni di terze parti di aggiungere suggerimenti alla casella di ricerca quando viene eseguita in modalità di ricerca globale. Se non sono installate applicazioni di terze parti che utilizzano questa funzionalità, il comportamento predefinito DOVREBBE essere la visualizzazione di risultati e suggerimenti del motore di ricerca web.
3.8.5. Auguri
Le applicazioni possono utilizzare l'API "Toast" per mostrare all'utente finale brevi stringhe non modali che scompaiono dopo un breve periodo di tempo [Risorse, 27]. Le implementazioni dei dispositivi DEVONO mostrare i popup dalle applicazioni agli utenti finali in modo molto visibile.
3.8.6. Temi
Android fornisce i "temi" come meccanismo per consentire alle applicazioni di applicare stili a un'intera attività o applicazione.
Android include una famiglia di temi "Holo" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare l'aspetto e il feeling del tema Holo come definito dall'SDK Android [Risorse, 28]. Le implementazioni dei dispositivi NON DEVONO alterare nessuno degli attributi del tema Holo esposti alle applicazioni [Risorse, 29].
Android 5.0 include una famiglia di temi "Material" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare l'aspetto del tema di design all'ampia gamma di diversi tipi di dispositivi Android. Le implementazioni dei dispositivi DEVONO supportare la famiglia di temi "Material" e NON DEVONO alterare nessuno degli attributi del tema Material o le relative risorse esposte alle applicazioni [Risorse, 30].
Android include anche una famiglia di temi "Predefinito del dispositivo" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare l'aspetto del tema del dispositivo come definito dall'implementatore del dispositivo. Le implementazioni del dispositivo POSSONO modificare gli attributi del tema Predefinito dispositivo esposti alle applicazioni [Risorse, 29].
Android supporta un nuovo tema di variante con barre di sistema traslucide, che consente agli sviluppatori di applicazioni di riempire l'area dietro la barra di stato e la barra di navigazione con i contenuti delle app. Per consentire un'esperienza omogenea per gli sviluppatori in questa configurazione, è importante che lo stile delle icone della barra di stato venga mantenuto nelle implementazioni di dispositivi diversi. Pertanto, le implementazioni dei dispositivi Android devono obbligatoriamente utilizzare il bianco per le icone dello stato del sistema (ad esempio l'intensità del segnale e il livello della batteria) e le notifiche emesse dal sistema, a meno che l'icona non indichi uno stato problematico [Risorse, 29].
3.8.7. Sfondi animati
Android definisce un tipo di componente e l'API e il ciclo di vita corrispondente che consente alle applicazioni di esporre uno o più "Sfondi animati" all'utente finale [Risorse, 31]. Gli sfondi animati sono animazioni, motivi o immagini simili con funzionalità di input limitate che vengono visualizzate come sfondo dietro altre applicazioni.
L'hardware è considerato in grado di eseguire in modo affidabile gli sfondi animati se può eseguire tutti gli sfondi animati, senza limitazioni alla funzionalità, a una frequenza frame ragionevole senza effetti negativi su altre applicazioni. Se le limitazioni dell'hardware causano arresti anomali, malfunzionamenti, consumo eccessivo della CPU o della batteria o l'esecuzione a frequenze fotogrammi inaccettabilmente basse di sfondi e/o applicazioni, l'hardware è considerato incapace di eseguire sfondi animati. Ad esempio, alcuni sfondi animati potrebbero utilizzare un contesto OpenGL 2.0 o 3.x per il rendering dei contenuti. La funzionalità Sfondo animato non funziona in modo affidabile su hardware che non supporta più contesti OpenGL, perché l'utilizzo di un contesto OpenGL da parte della funzionalità Sfondo animato potrebbe entrare in conflitto con altre applicazioni che utilizzano anche un contesto OpenGL.
Le implementazioni dei dispositivi in grado di eseguire sfondi animati in modo affidabile come descritto sopra DEVONO implementare gli sfondi animati e, una volta implementati, DEVONO segnalare il flag della funzionalità della piattaforma android.software.live_wallpaper.
3.8.8. Cambio attività
|
Poiché il tasto di navigazione Funzionalità recenti è FACOLTATIVO, i requisiti per implementare la schermata Panoramica sono FACOLTATIVI per i dispositivi Android TV e Android Watch. |
Il codice sorgente di Android upstream include la schermata Panoramica [Risorse, 32], un'interfaccia utente a livello di sistema per il passaggio da un'attività all'altra e la visualizzazione delle attività e delle attività a cui è stato eseguito l'accesso di recente utilizzando un'immagine in miniatura dello stato grafico dell'applicazione al momento in cui l'utente ha chiuso l'applicazione per l'ultima volta. Le implementazioni del dispositivo, inclusa la chiave di navigazione della funzione Recenti descritta nella sezione 7.2.3, POSSONO modificare l'interfaccia, ma DEVONO soddisfare i seguenti requisiti:
- DEVE mostrare i contenuti recenti affiliati come un gruppo che si sposta insieme
- DEVE supportare almeno 20 attività visualizzate
- DEVE mostrare almeno il titolo di 4 attività alla volta
- DOVREBBE mostrare il colore dell'evidenziazione, l'icona e il titolo dello schermo tra le app recenti
- DEVE implementare il comportamento di blocco dello schermo [Risorse, 33] e fornire all'utente un menu delle impostazioni per attivare/disattivare la funzionalità
- DOVREBBE mostrare un'affordance di chiusura ("x"), ma PUÒ ritardare questa operazione finché l'utente non interagisce con le schermate
È FORTEMENTE CONSIGLIATO alle implementazioni dei dispositivi di utilizzare l'interfaccia utente Android di upstream (o un'interfaccia basata su miniature simile) per la schermata di panoramica.
3.8.9. Gestione dell'input
Android include il supporto per la gestione dell'input e per gli editor di metodi di input di terze parti [Risorse, 34]. Le implementazioni dei dispositivi che consentono agli utenti di utilizzare metodi di inserimento di terze parti sul dispositivo DEVONO dichiarare la funzionalità della piattaforma android.software.input_methods e supportare le API IME come definito nella documentazione dell'SDK Android.
Le implementazioni dei dispositivi che dichiarano la funzionalità android.software.input_methods devono fornire un meccanismo accessibile agli utenti per aggiungere e configurare metodi di input di terze parti. Le implementazioni del dispositivo DEVONO mostrare l'interfaccia delle impostazioni in risposta all'intent android.settings.INPUT_METHOD_SETTINGS.
3.8.10. Controllo dei contenuti multimediali nella schermata di blocco
L'API Remote Control Client è deprecata in Android 5.0 a favore del Modello di notifica multimediale che consente alle applicazioni multimediali di integrarsi con i controlli di riproduzione visualizzati nella schermata di blocco [Risorse, 35]. Le implementazioni dei dispositivi che supportano una schermata di blocco DEVONO supportare il modello di notifica multimediale insieme ad altre notifiche.
3.8.11. Sogni
Android include il supporto per i salvaschermo interattivi chiamati Sogni [Risorse, 36]. Dreams consente agli utenti di interagire con le applicazioni quando un dispositivo collegato a un'alimentazione è inattivo o agganciato alla base di ricarica. I dispositivi Android Watch POSSONO implementare Dreams, ma altri tipi di implementazioni dei dispositivi DEVONO includere il supporto di Dreams e fornire un'opzione di impostazioni per consentire agli utenti di configurare Dreams in risposta all'intent android.settings.DREAM_SETTINGS.
3.8.12. Posizione
Quando un dispositivo è dotato di un sensore hardware (ad es. GPS) in grado di fornire le coordinate geografiche, le modalità di geolocalizzazione DEVONO essere visualizzate nel menu Posizione all'interno di Impostazioni [Risorse, 37].
3.8.13. Unicode e carattere
Android include il supporto dei caratteri emoji a colori. Quando le implementazioni dei dispositivi Android includono un IME, i dispositivi DEVONO fornire all'utente un metodo di inserimento per i caratteri emoji definiti in Unicode 6.1 [Risorse, 38]. Tutti i dispositivi DEVONO essere in grado di visualizzare questi caratteri emoji in glif colorato.
Android 5.0 include il supporto del carattere Roboto 2 con diversi spessori: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light, che DEVONO essere inclusi per tutte le lingue disponibili sul dispositivo e per una copertura completa di Unicode 7.0 per latino, greco e cirillico, inclusi gli intervalli A, B, C e D del latino esteso e tutti i glifi nel blocco dei simboli di valuta di Unicode 7.0.
3.9. Amministrazione dispositivo
Android include funzionalità che consentono alle applicazioni sensibili alla sicurezza di eseguire funzioni di amministrazione del dispositivo a livello di sistema, ad esempio l'applicazione di criteri per le password o l'esecuzione di reset dei dati di fabbrica da remoto, tramite l'API Android Device Administration [Risorse, 39]. Le implementazioni dei dispositivi DEVONO fornire un'implementazione della classe DevicePolicyManager [Risorse, 40]. Le implementazioni dei dispositivi che includono il supporto della schermata di blocco DEVONO supportare la gamma completa di criteri di amministrazione del dispositivo definiti nella documentazione dell'SDK Android [Risorse, 39] e segnalare la funzionalità della piattaforma android.software.device_admin.
Le implementazioni dei dispositivi POSSONO avere un'applicazione preinstallata che esegue funzioni di amministrazione del dispositivo, ma questa applicazione NON DEVE essere impostata come app Proprietario dispositivo predefinita [Risorse, 41].
3.10. Accessibilità
Android fornisce un livello di accessibilità che aiuta gli utenti con disabilità a navigare più facilmente sui loro dispositivi. Inoltre, Android fornisce API di piattaforma che consentono alle implementazioni dei servizi di accessibilità di ricevere callback per gli eventi dell'utente e del sistema e di generare meccanismi di feedback alternativi, come text-to-speech, feedback aptico e navigazione con trackball/d-pad [Risorse, 42]. Le implementazioni dei dispositivi DEVONO fornire un'implementazione del framework di accessibilità Android coerente con l'implementazione predefinita di Android. Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti:
- DEVE supportare le implementazioni di servizi di accessibilità di terze parti tramite le API android.accessibilityservice [Risorse, 43]
- DEVE generare eventi AccessibilityEvents e inviarli a tutte le implementazioni di AccessibilityService registrate in modo coerente con l'implementazione predefinita di Android
- A meno che non si tratti di un dispositivo Android Watch senza uscita audio, le implementazioni dei dispositivi devono fornire un meccanismo accessibile all'utente per attivare e disattivare i servizi di accessibilità e devono mostrare questa interfaccia in risposta all'intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.
Inoltre, le implementazioni dei dispositivi DEVONO fornire un'implementazione di un servizio di accessibilità sul dispositivo e DEVONO fornire un meccanismo per consentire agli utenti di attivare il servizio di accessibilità durante la configurazione del dispositivo. Un'implementazione open source di un servizio di accessibilità è disponibile nel progetto Eyes Free [Risorse, 44].
3.11. Sintesi vocale
Android include API che consentono alle applicazioni di utilizzare i servizi di sintesi vocale (TTS) e ai fornitori di servizi di fornire implementazioni di questi servizi [Risorse, 45]. Le implementazioni dei dispositivi che segnalano la funzionalità android.hardware.audio.output devono soddisfare questi requisiti relativi al framework TTS di Android.
Implementazioni dei dispositivi:
- DEVE supportare le API del framework TTS di Android e DOVREBBE includere un motore TTS supportante le lingue disponibili sul dispositivo. Tieni presente che il software open source Android di upstream include un'implementazione del motore TTS con funzionalità complete.
- DEVE supportare l'installazione di motori TTS di terze parti
- DEVE fornire un'interfaccia accessibile agli utenti che consenta loro di selezionare un motore TTS da utilizzare a livello di sistema
3.12. TV Input Framework
Android Television Input Framework (TIF) semplifica la pubblicazione di contenuti dal vivo su dispositivi Android TV. TIF fornisce un'API standard per creare moduli di input che controllano i dispositivi Android TV. Le implementazioni dei dispositivi Android TV DEVONO supportare il Television Input Framework [Risorse, 46].
Le implementazioni dei dispositivi che supportano TIF DEVONO dichiarare la funzionalità della piattaforma android.software.live_tv.
4. Compatibilità con il pacchettizzazione delle applicazioni
Le implementazioni dei dispositivi DEVONO installare ed eseguire i file ".apk" Android come generati dall'aapt incluso nell'SDK Android ufficiale [Risorse, 47].
Le implementazioni dei dispositivi NON DEVONO estendere i file .apk [Risorse, 48], Android Manifest [Risorse, 49], il bytecode Dalvik [Risorse, 20] o i formati bytecode di RenderScript in modo da impedire l'installazione e l'esecuzione corretta di questi file su altri dispositivi compatibili
5. Compatibilità multimediale
5.1. Codec multimediali
Le implementazioni dei dispositivi DEVONO supportare i formati multimediali di base specificati nella documentazione dell'SDK Android [Risorse, 50], tranne dove esplicitamente consentito in questo documento. Nello specifico, le implementazioni dei dispositivi DEVONO supportare i formati multimediali, gli encoder, i decodificatori, i tipi di file e i formati dei contenitori definiti nelle tabelle riportate di seguito. Tutti questi codec sono forniti come implementazioni software nell'implementazione Android preferita dell'Android Open Source Project.
Tieni presente che né Google né l'Open Handset Alliance dichiarano che questi codec sono esenti da brevetti di terze parti. Gli utenti che intendono utilizzare questo codice sorgente in prodotti hardware o software sono informati che le implementazioni di questo codice, incluso in software open source o shareware, potrebbero richiedere licenze di brevetto da parte dei titolari dei brevetti pertinenti.
5.1.1. Codec audio
|
Formato / codec |
Codificatore |
Decodificatore |
Dettagli |
Tipi di file/formati contenitore supportati |
|
Profilo MPEG-4 AAC (AAC LC) |
REQUIRED1 |
OBBLIGATORIO |
Supporto per contenuti mono/stereo/5.0/5.12 con frequenze di campionamento standard da 8 a 48 kHz. |
• 3GPP (.3gp) • MPEG-4 (.mp4, .m4a) • AAC non compresso ADTS (.aac, decodifica in Android 3.1 e versioni successive, codifica in Android 4.0 e versioni successive, ADIF non supportato) • MPEG-TS (.ts, non cercabile, Android 3.0 e versioni successive) |
|
Profilo MPEG-4 HE AAC (AAC+) |
REQUIRED1 (Android 4.1 e versioni successive) |
OBBLIGATORIO |
Supporto per contenuti mono/stereo/5.0/5.12 con frequenze di campionamento standard da 16 a 48 kHz. |
|
|
MPEG-4 HE AACv2 Profilo (AAC+ migliorato) |
|
OBBLIGATORIO |
Supporto per contenuti mono/stereo/5.0/5.12 con frequenze di campionamento standard da 16 a 48 kHz. |
|
|
AAC ELD (AAC a bassa latenza migliorata) |
REQUIRED1 (Android 4.1 e versioni successive) |
OBBLIGATORIO (Android 4.1 e versioni successive) |
Supporto per contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz. |
|
|
AMR-NB |
REQUIRED3 |
REQUIRED3 |
4,75-12,2 Kbps campionati a 8 kHz |
3GPP (.3gp) |
|
AMR-WB |
REQUIRED3 |
REQUIRED3 |
9 frequenze da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz |
|
|
FLAC |
|
OBBLIGATORIO (Android 3.1 e versioni successive) |
Mono/stereo (nessun multicanale). Frequenze di campionamento fino a 48 kHz (ma fino a 44,1 kHz è consigliata su dispositivi con uscita a 44,1 kHz, poiché il downsampler da 48 a 44,1 kHz non include un filtro passa basso). Consigliati 16 bit; nessun dither applicato per 24 bit. |
Solo FLAC (.flac) |
|
MP3 |
|
OBBLIGATORIO |
Mono/stereo 8-320 Kbps costante (CBR) o con velocità in bit variabile (VBR) |
MP3 (.mp3) |
|
MIDI |
|
OBBLIGATORIO |
Tipo MIDI 0 e 1. Versioni 1 e 2 di DLS. XMF e Mobile XMF. Supporto per i formati di suoneria RTTTL/RTX, OTA e iMelody |
• Tipo 0 e 1 (.mid, .xmf, .mxmf) • RTTTL/RTX (.rtttl, .rtx) • OTA (.ota) • iMelody (.imy) |
|
Vorbis |
|
OBBLIGATORIO |
|
• Ogg (.ogg) • Matroska (.mkv, Android 4.0 e versioni successive) |
|
PCM/WAVE |
REQUIRED4 (Android 4.1 e versioni successive) |
OBBLIGATORIO |
PCM lineare a 16 bit (frequenze fino al limite dell'hardware). I dispositivi DEVONO supportare le frequenze di campionamento per la registrazione PCM non compressa a 8000, 11025, 16000 e 44100 Hz. |
WAVE (.wav) |
|
Opus |
OBBLIGATORIO (Android 5.0 e versioni successive). |
Matroska (.mkv) |
1 Obbligatorio per le implementazioni dei dispositivi che definiscono android.hardware.microphone, ma facoltativo per le implementazioni dei dispositivi Android Watch.
2 È richiesto solo il downmix dei contenuti 5.0/5.1; la registrazione o il rendering di più di 2 canali è facoltativo.
3 Obbligatorio per le implementazioni dei dispositivi Android portatili.
4 Obbligatorio per le implementazioni dei dispositivi che definiscono android.hardware.microphone, incluse le implementazioni dei dispositivi Android Watch.
5.1.2. Codec immagine
|
Formato / codec |
Codificatore |
Decodificatore |
Dettagli |
Tipi di file/formati contenitore supportati |
|
JPEG |
OBBLIGATORIO |
OBBLIGATORIO |
Base+progressiva |
JPEG (.jpg) |
|
GIF |
|
OBBLIGATORIO |
|
GIF (.gif) |
|
PNG |
OBBLIGATORIO |
OBBLIGATORIO |
|
PNG (.png) |
|
BMP |
|
OBBLIGATORIO |
|
BMP (.bmp) |
|
WebP |
OBBLIGATORIO |
OBBLIGATORIO |
|
WebP (.webp) |
5.1.3. Codec video
|
I codec video sono facoltativi per le implementazioni dei dispositivi Android Watch. |
|
Formato / codec |
Codificatore |
Decodificatore |
Dettagli |
Tipi di file/formati contenitore supportati |
|
H.263 |
REQUIRED1 |
REQUIRED2 |
|
• 3GPP (.3gp) • MPEG-4 (.mp4) |
|
H.264 AVC |
REQUIRED2 |
REQUIRED2 |
Per maggiori dettagli, consulta le sezioni 5.2 e 5.3 |
• 3GPP (.3gp) • MPEG-4 (.mp4) • MPEG-TS (.ts, solo audio AAC, non cercabile, Android 3.0 e versioni successive) |
|
H.265 HEVC |
REQUIRED2 |
Per informazioni dettagliate, consulta la sezione 5.3 |
MPEG-4 (.mp4) |
|
|
MPEG-4 SP |
|
REQUIRED2 |
|
3GPP (.3gp) |
|
VP83 |
REQUIRED2 (Android 4.3 e versioni successive) |
REQUIRED2 (Android 2.3.3 e versioni successive) |
Per maggiori dettagli, consulta le sezioni 5.2 e 5.3 |
• WebM (.webm) [Risorse, 110] • Matroska (.mkv, Android 4.0 e versioni successive)4 |
|
VP9 |
REQUIRED2 (Android 4.4 e versioni successive) |
Per informazioni dettagliate, consulta la sezione 5.3 |
• WebM (.webm) [Risorse, 110] • Matroska (.mkv, Android 4.0 e versioni successive)4 |
1 Obbligatorio per le implementazioni dei dispositivi che includono l'hardware della fotocamera e definiscono android.hardware.camera o android.hardware.camera.front.
2 Obbligatorio per le implementazioni dei dispositivi, ad eccezione dei dispositivi Android Watch.
3 Per una qualità accettabile dei servizi di streaming video web e di videoconferenza, le implementazioni dei dispositivi DEVONO utilizzare un codec VP8 hardware che soddisfi i requisiti riportati in [Risorse, 51].
4 Le implementazioni dei dispositivi DEVONO supportare la scrittura di file Matroska WebM.
5.2. Codifica video
|
I codec video sono facoltativi per le implementazioni dei dispositivi Android Watch. |
Le implementazioni dei dispositivi Android con supporto del codec H.264 DEVONO supportare il profilo di base di livello 3 e i seguenti profili di codifica video SD (definizione standard) e DOVREBBERO supportare il profilo principale di livello 4 e i seguenti profili di codifica video HD (alta definizione). È FORTEMENTE consigliato codificare i video HD 1080p a 30 f/s sui dispositivi Android TV.
|
SD (qualità bassa) |
SD (alta qualità) |
HD 720p1 |
HD 1080p1 |
|
|
Risoluzione video |
320 x 240 px |
720 x 480 px |
1280 x 720 px |
1920 x 1080 px |
|
Frequenza fotogrammi video |
20 f/s |
30 fps |
30 fps |
30 fps |
|
Velocità in bit video |
384 kbps |
2 Mbps |
4 Mbps |
10 Mbps |
1 Se supportato dall'hardware, ma FORTEMENTE CONSIGLIATO per i dispositivi Android TV.
Le implementazioni di dispositivi Android con supporto del codec VP8 DEVONO supportare i profili di codifica video SD e DOVREBBERO supportare i seguenti profili di codifica video HD (alta definizione).
|
SD (qualità bassa) |
SD (alta qualità) |
HD 720p1 |
HD 1080p1 |
|
|
Risoluzione video |
320 x 180 px |
640 x 360 px |
1280 x 720 px |
1920 x 1080 px |
|
Frequenza fotogrammi video |
30 fps |
30 fps |
30 fps |
30 fps |
|
Velocità in bit video |
800 kbps |
2 Mbps |
4 Mbps |
10 Mbps |
1 Se supportato dall'hardware.
5.3. Decodifica video
|
I codec video sono facoltativi per le implementazioni dei dispositivi Android Watch. |
Le implementazioni dei dispositivi DEVONO supportare il passaggio dinamico della risoluzione video all'interno dello stesso stream per i codec VP8, VP9, H.264 e H.265.
Le implementazioni dei dispositivi Android con decodificatori H.264 DEVONO supportare il profilo di base di livello 3 e i seguenti profili di decodifica video SD e DOVREBBERO supportare i profili di decodifica HD. I dispositivi Android TV DEVONO supportare il livello 4.2 del profilo High e il profilo di decodifica HD 1080p.
|
SD (qualità bassa) |
SD (alta qualità) |
HD 720p1 |
HD 1080p1 |
|
|
Risoluzione video |
320 x 240 px |
720 x 480 px |
1280 x 720 px |
1920 x 1080 px |
|
Frequenza fotogrammi video |
30 fps |
30 fps |
30 f/s/60 f/s2 |
30 f/s/60 f/s2 |
|
Velocità in bit video |
800 kbps |
2 Mbps |
8 Mbps |
20 Mbps |
1 Obbligatorio per le implementazioni dei dispositivi Android TV, ma per altri tipi di dispositivi solo se supportato dall'hardware.
2 Obbligatorio per le implementazioni dei dispositivi Android TV.
Le implementazioni dei dispositivi Android che supportano il codec VP8, come descritto nella sezione 5.1.3, DEVONO supportare i seguenti profili di decodifica SD e DOVREBBERO supportare i profili di decodifica HD. I dispositivi Android TV DEVONO supportare il profilo di decodifica HD 1080p.
|
SD (qualità bassa) |
SD (alta qualità) |
HD 720p1 |
HD 1080p1 |
|
|
Risoluzione video |
320 x 180 px |
640 x 360 px |
1280 x 720 px |
1920 x 1080 px |
|
Frequenza fotogrammi video |
30 fps |
30 fps |
30 f/s/60 f/s2 |
30/60 f/s2 |
|
Velocità in bit video |
800 kbps |
2 Mbps |
8 Mbps |
20 Mbps |
1 Obbligatorio per le implementazioni dei dispositivi Android TV, ma per altri tipi di dispositivi solo se supportato dall'hardware.
2 Obbligatorio per le implementazioni dei dispositivi Android TV.
Le implementazioni dei dispositivi Android, se supportano il codec VP9 come descritto nella sezione 5.1.3, DEVONO supportare i seguenti profili di decodifica video SD e DOVREBBERO supportare i profili di decodifica HD. È FORTEMENTE CONSIGLIATO che i dispositivi Android TV supportino il profilo di decodifica HD 1080p e DEBBANO supportare il profilo di decodifica UHD. Quando il profilo di decodifica video UHD è supportato, DEVE supportare la profondità di colore di 8 bit.
|
SD (qualità bassa) |
SD (alta qualità) |
HD 720p 1 |
HD 1080p 2 |
UHD 2 |
|
|
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 fps |
30 fps |
|
Velocità in bit video |
600 kbps |
1,6 Mbps |
4 Mbps |
10 Mbps |
20 Mbps |
1 Obbligatorio per le implementazioni dei dispositivi Android TV, ma per altri tipi di dispositivi solo se supportato dall'hardware.
2 FORTEMENTE CONSIGLIATO per le implementazioni dei dispositivi Android TV se supportato dall'hardware.
Le implementazioni dei dispositivi Android, se supportano il codec H.265 come descritto nella sezione 5.1.3, DEVONO supportare il livello principale del profilo principale 3 e i seguenti profili di decodifica video SD e DOVREBBERO supportare i profili di decodifica HD. I dispositivi TV Android DEVONO supportare il profilo principale di livello 4.1 e il profilo di decodifica HD 1080p e DOVREBBERO supportare il profilo principale di livello 5 e il profilo di decodifica UHD.
|
SD (qualità bassa) |
SD (alta qualità) |
HD 720p 1 |
HD 1080p 1 |
UHD 2 |
|
|
Risoluzione video |
352 x 288 px |
640 x 360 px |
1280 x 720 px |
1920 x 1080 px |
3840 x 2160 px |
|
Frequenza fotogrammi video |
30 fps |
30 fps |
30 fps |
30 fps |
30 fps |
|
Velocità in bit video |
600 kbps |
1,6 Mbps |
4 Mbps |
10 Mbps |
20 Mbps |
1 Obbligatorio per l'implementazione dei dispositivi Android TV, ma per altri tipi di dispositivi solo se supportato dall'hardware.
2 Obbligatorio per le implementazioni dei dispositivi Android TV, se supportato dall'hardware.
5.4. Registrazione audio
Sebbene alcuni dei requisiti descritti in questa sezione siano indicati come DOVREBBE da Android 4.3, è previsto di modificare la definizione di compatibilità per una versione futura in modo che diventino OBBLIGATORIO. È vivamente consigliato ai dispositivi Android esistenti e nuovi di soddisfare questi requisiti, altrimenti non potranno raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.
5.4.1. Acquisizione audio non compresso
Le implementazioni dei dispositivi che dichiarano android.hardware.microphone DEVONO consentire la registrazione di contenuti audio non elaborati con le seguenti caratteristiche:
- Formato: PCM lineare, 16 bit
- Frequenze di campionamento: 8000, 11025, 16000, 44100
- Canali: mono
Le implementazioni del dispositivo che dichiarano android.hardware.microphone DEVONO consentire l'acquisizione di contenuti audio non elaborati con le seguenti caratteristiche:
- Formato: PCM lineare, 16 bit
- Frequenze di campionamento: 22050, 48000
- Canali: stereo
5.4.2. Acquisisci per il riconoscimento vocale
Oltre alle specifiche di registrazione riportate sopra, quando un'applicazione ha iniziato a registrare uno stream audio utilizzando la sorgente audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:
- Il dispositivo DEVE presentare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte: in particolare, ±3 dB, da 100 Hz a 4000 Hz.
- La sensibilità dell'ingresso audio DEVE essere impostata in modo che una sorgente con un livello di potenza sonora (SPL) di 90 dB a 1000 Hz generi un RMS di 2500 per i campioni a 16 bit.
- I livelli di ampiezza PCM DEVONO seguire in modo lineare le variazioni di SPL in ingresso in un intervallo di almeno 30 dB da -18 dB a +12 dB rispetto a 90 dB SPL al microfono.
- La distorsione armonica totale DEVE essere inferiore all'1% per 1 KHz a un livello di input di 90 dB SPL sul microfono.
- L'elaborazione di riduzione del rumore, se presente, DEVE essere disattivata.
- Il controllo automatico del guadagno, se presente, DEVE essere disattivato
Se la piattaforma supporta tecnologie di soppressione del rumore ottimizzate per il riconoscimento vocale, l'effetto DEVE essere controllabile dall'API android.media.audiofx.NoiseSuppressor. Inoltre, il campo UUID per il descrittore dell'effetto del rimuovi rumore DEVE identificare in modo univoco ogni implementazione della tecnologia di soppressione del rumore.
5.4.3. Acquisisci per il reindirizzamento della riproduzione
La classe android.media.MediaRecorder.AudioSource include l'origine audio REMOTE_SUBMIX. I dispositivi che dichiarano android.hardware.audio.output DEVONO implementare correttamente l'origine audio REMOTE_SUBMIX in modo che, quando un'applicazione utilizza l'API android.media.AudioRecord per registrare da questa origine audio, possa acquisire un mix di tutti gli stream audio, ad eccezione di quanto segue:
- STREAM_RING
- STREAM_ALARM
- STREAM_NOTIFICATION
5.5. Riproduzione audio
Le implementazioni dei dispositivi che dichiarano android.hardware.audio.output DEVONO essere conformi ai requisiti di questa sezione.
5.5.1. Riproduzione audio non elaborata
Il dispositivo DEVE consentire la riproduzione di contenuti audio non elaborati con le seguenti caratteristiche:
- Formato: PCM lineare, 16 bit
- Frequenze di campionamento: 8000, 11025, 16000, 22050, 32000, 44100
- Canali: mono, stereo
Il dispositivo DEVE consentire la riproduzione di contenuti audio non elaborati con le seguenti caratteristiche:
- Frequenze di campionamento: 24000, 48000
5.5.2. Effetti audio
Android fornisce un'API per gli effetti audio per le implementazioni dei dispositivi [Risorse, 52]. Implementazioni del dispositivo che dichiarano la funzionalità android.hardware.audio.output:
- DEVE supportare le implementazioni di EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controllabili tramite le sottoclassi AudioEffect Equalizer e LoudnessEnhancer
- DEVE supportare l'implementazione dell'API di visualizzazione, controllabile tramite la classe Visualizer
- DEVE supportare le implementazioni di EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB ed EFFECT_TYPE_VIRTUALIZER controllabili tramite i sottoclassi AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer
5.5.3. Volume uscita audio
Le implementazioni dei dispositivi Android TV DEVONO includere il supporto del volume master di sistema e dell'attenuazione del volume dell'uscita audio digitale sulle uscite supportate, tranne per l'uscita passthrough audio compresso (in cui non viene eseguita la decodifica audio sul dispositivo).
5.6. Latenza audio
La latenza audio è il ritardo temporale che si verifica quando un segnale audio passa attraverso un sistema. Molte classi di applicazioni si basano su latenze brevi per ottenere effetti sonori in tempo reale.
Ai fini di questa sezione, utilizza le seguenti definizioni:
- Latenza in uscita: l'intervallo tra il momento in cui un'applicazione scrive un frame di dati codificati in PCM e il momento in cui l'audio corrispondente può essere ascoltato da un ascoltatore esterno o osservato da un trasduttore.
- Latenza di uscita a freddo: la latenza di uscita per il primo frame, quando il sistema di uscita audio è stato inattivo e spento prima della richiesta.
- Latenza di uscita continua: la latenza di uscita per i frame successivi, dopo che il dispositivo ha iniziato a riprodurre l'audio.
- Latenza di input: l'intervallo tra il momento in cui un suono esterno viene presentato al dispositivo e il momento in cui un'applicazione legge il frame corrispondente di dati codificati PCM.
- Latenza di inserimento a freddo: la somma del tempo di inserimento perso e della latenza di inserimento per il primo frame, quando il sistema di inserimento audio è inattivo e spento prima della richiesta.
- Latenza di input continua: la latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.
- Jitter in uscita a freddo: la varianza tra misurazioni separate dei valori di latenza in uscita a freddo.
- Jitter di input a freddo: la varianza tra misurazioni separate dei valori di latenza di input a freddo.
- Latenza di viaggio avanti e indietro continua: la somma della latenza di input continua più la latenza di output continua più 5 millisecondi.
- API OpenSL ES per la coda del buffer PCM: l'insieme di API OpenSL ES correlate al PCM all'interno di Android NDK; consulta NDK_root/docs/opensles/index.html.
Le implementazioni dei dispositivi che dichiarano android.hardware.audio.output DEVONO soddisfare o superare questi requisiti di uscita audio:
- latenza di output a freddo di massimo 100 millisecondi
- latenza di uscita continua di massimo 45 millisecondi
- ridurre al minimo il jitter dell'output a freddo
Se l'implementazione di un dispositivo soddisfa i requisiti di questa sezione dopo qualsiasi calibratura iniziale quando si utilizza l'API OpenSL ES PCM buffer queue, per la latenza di uscita continua e la latenza di uscita a freddo su almeno un dispositivo di uscita audio supportato, PUÒ segnalare il supporto dell'audio a bassa latenza, segnalando la funzionalità android.hardware.audio.low_latency tramite la classe android.content.pm.PackageManager [Resources, 53]. Al contrario, se l'implementazione del dispositivo non soddisfa questi requisiti, NON deve segnalare il supporto dell'audio a bassa latenza.
Le implementazioni dei dispositivi che includono android.hardware.microphone DEVONO soddisfare questi requisiti relativi all'audio di input:
- latenza di input a freddo di massimo 100 millisecondi
- latenza di input continua di massimo 30 millisecondi
- latenza nel tempo di round trip continua pari o inferiore a 50 millisecondi
- ridurre al minimo il jitter dell'input a freddo
5.7. Protocolli di rete
I dispositivi DEVONO supportare i protocolli di rete multimediale per la riproduzione di audio e video come specificato nella documentazione dell'SDK Android [Risorse, 50]. In particolare, i dispositivi DEVONO supportare i seguenti protocolli di rete multimediale:
- RTSP (RTP, SDP)
- Streaming progressivo HTTP(S)
- HTTP(S) Live Streaming draft protocol, Version 3 [Resources, 54]
5.8. Contenuti multimediali sicuri
Le implementazioni dei dispositivi che supportano l'uscita video sicura e sono in grado di supportare le piattaforme sicure DEVONO dichiarare il supporto di Display.FLAG_SECURE. Le implementazioni dei dispositivi che dichiarano il supporto di Display.FLAG_SECURE, se supportano un protocollo di visualizzazione wireless, DEVONO proteggere il collegamento con un meccanismo di crittografia efficace, come HDCP 2.x o versioni successive per i display wireless Miracast. Analogamente, se supportano un display esterno con cavo, le implementazioni dei dispositivi DEVONO supportare HDCP 1.2 o versioni successive. Le implementazioni dei dispositivi Android TV DEVONO supportare HDCP 2.2 per i dispositivi che supportano la risoluzione 4K e HDCP 1.4 o versioni successive per le risoluzioni inferiori. L'implementazione open source di Android upstream include il supporto per i display wireless (Miracast) e cablati (HDMI) che soddisfano questo requisito.
6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori
6.1. Strumenti per sviluppatori
Le implementazioni dei dispositivi DEVONO supportare gli Android Developer Tools forniti nell'SDK Android. I dispositivi Android compatibili DEVONO essere compatibili con:
- Android Debug Bridge (ADB) [Risorse, 55]
Le implementazioni dei dispositivi DEVONO supportare tutte le funzioni adb come documentato nell'SDK Android, incluso dumpsys [Risorse, 56]. Il daemon adb lato dispositivo DEVE essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivare Android Debug Bridge. Se l'implementazione di un dispositivo omette la modalità periferica USB, DEVE implementare il bridge di debug Android tramite una rete locale (ad esempio Ethernet o 802.11).
Android include il supporto per adb sicuro. adb sicuro attiva adb su host autenticati noti. Le implementazioni dei dispositivi DEVONO supportare adb sicuro.
- Dalvik Debug Monitor Service (ddms) [Risorse, 57]
Le implementazioni dei dispositivi DEVONO supportare tutte le funzionalità ddms come documentato nell'SDK Android. Poiché ddms utilizza adb, il supporto di ddms DOVREBBE essere inattivo per impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato Android Debug Bridge, come sopra.
- Monkey [Risorse, 58]
Le implementazioni dei dispositivi DEVONO includere il framework Monkey e renderlo disponibile per l'utilizzo da parte delle applicazioni.
- SysTrace [Risorse, 59]
Le implementazioni dei dispositivi DEVONO supportare lo strumento systrace come descritto nell'SDK Android. Systrace deve essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivarlo.
La maggior parte dei sistemi basati su Linux e dei sistemi Apple Macintosh riconosce i dispositivi Android utilizzando gli strumenti Android SDK standard, senza ulteriore supporto. Tuttavia, i sistemi Microsoft Windows in genere richiedono un driver per i nuovi dispositivi Android. Ad esempio, i nuovi ID fornitore e, a volte, i nuovi ID dispositivo richiedono driver USB personalizzati per i sistemi Windows. Se un'implementazione del dispositivo non è riconosciuta dallo strumento adb fornito nell'SDK Android standard, gli implementatori del dispositivo DEVONO fornire i driver Windows che consentono agli sviluppatori di connettersi al dispositivo utilizzando il protocollo adb. Questi driver DEVONO essere forniti per Windows XP, Windows Vista, Windows 7, Windows 8 e Windows 9 sia nelle versioni a 32 bit che a 64 bit.
6.2. Opzioni sviluppatore
Android include il supporto per la configurazione da parte degli sviluppatori delle impostazioni relative allo sviluppo delle applicazioni. Le implementazioni dei dispositivi DEVONO rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo dell'applicazione [Risorse, 60]. L'implementazione di Android a monte nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avviare le Opzioni sviluppatore dopo aver premuto sette volte la voce di menu Impostazioni > Informazioni sul dispositivo > Numero build. Le implementazioni dei dispositivi DEVONO fornire un'esperienza coerente per le Opzioni sviluppatore. Nello specifico, le implementazioni dei dispositivi DEVONO nascondere le Opzioni sviluppatore per impostazione predefinita e DEVONO fornire un meccanismo per attivarle in modo coerente con l'implementazione di Android a monte.
7. Compatibilità hardware
Se un dispositivo include un determinato componente hardware con un'API corrispondente per gli sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android. Se un'API nell'SDK interagisce con un componente hardware dichiarato facoltativo e l'implementazione del dispositivo non dispone di questo componente:
- Le definizioni complete delle classi (come documentato dall'SDK) per le API del componente devono essere comunque presentate.
- I comportamenti dell'API DEVONO essere implementati come no-op in modo ragionevole.
- I metodi dell'API DEVONO restituire valori null se consentito dalla documentazione dell'SDK.
- I metodi API DEVONO restituire implementazioni no-op delle classi in cui i valori null non sono consentiti dalla documentazione dell'SDK.
- I metodi API NON DEVONO generare eccezioni non documentate dalla documentazione dell'SDK.
Un esempio tipico di uno scenario in cui si applicano questi requisiti è l'API di telefonia: anche su dispositivi diversi dagli smartphone, queste API devono essere implementate come no-op ragionevoli.
Le implementazioni dei dispositivi DEVONO segnalare in modo coerente informazioni accurate sulla configurazione hardware tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) della classe android.content.pm.PackageManager per la stessa impronta di compilazione. [Resources, 53]
7.1. Display e grafica
Android include funzionalità che regolano automaticamente gli asset dell'applicazione e i layout dell'interfaccia utente in base al dispositivo, per garantire il corretto funzionamento delle applicazioni di terze parti su una serie di configurazioni hardware [Risorse, 61]. I dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.
Le unità a cui fanno riferimento i requisiti in questa sezione sono definite come segue:
- Dimensioni diagonali fisiche: la distanza in pollici tra due angoli opposti della parte illuminata del display.
- Punti per pollice (dpi): il numero di pixel inclusi in un tratto lineare orizzontale o verticale di 1". Se sono elencati i valori dpi, sia orizzontali che verticali, devono rientrare nell'intervallo.
- proporzioni: il rapporto tra la dimensione più lunga dello schermo e quella più corta. Ad esempio, un display di 480 x 854 pixel corrisponde a 854 / 480 = 1,779, ovvero approssimativamente "16:9".
- Pixel indipendente dalla densità (dp): l'unità di pixel virtuale normalizzata a uno schermo di 160 dpi, calcolata come segue: pixel = dps * (densità / 160).
7.1.1. Configurazione schermo
7.1.1.1. Dimensioni schermo
|
I dispositivi Android Watch (descritti nella sezione 2) POTREBBERO avere dimensioni dello schermo più piccole come descritto in questa sezione. |
Il framework UI di Android supporta una serie di dimensioni dello schermo diverse e consente alle applicazioni di eseguire query sulle dimensioni dello schermo del dispositivo (ovvero "layout dello schermo") tramite android.content.res.Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK. Le implementazioni dei dispositivi DEVONO segnalare le dimensioni dello schermo corrette come definite nella documentazione dell'SDK Android [Risorse, 61] e determinate dalla piattaforma Android a monte. Nello specifico, le implementazioni dei dispositivi DEVONO segnalare le dimensioni dello schermo corrette in base alle seguenti dimensioni dello schermo in pixel indipendenti dalla densità (dp) logici.
- I dispositivi DEVONO avere dimensioni dello schermo di almeno 426 dp x 320 dp ("piccolo"), a meno che non si tratti di un dispositivo Android Watch.
- I dispositivi che segnalano dimensioni dello schermo "normali" DEVONO avere dimensioni dello schermo di almeno 480 dp x 320 dp.
- I dispositivi che segnalano dimensioni dello schermo "grandi" DEVONO avere dimensioni dello schermo di almeno 640 dp x 480 dp.
- I dispositivi che segnalano dimensioni dello schermo "Molto grande" DEVONO avere dimensioni dello schermo di almeno 960 dp x 720 dp.
Inoltre, queste
- I dispositivi Android Watch DEVONO avere uno schermo con diagonale fisica compresa tra 28 e 64 mm
- Altri tipi di implementazioni di dispositivi Android, con uno schermo integrato fisicamente, DEVONO avere uno schermo con una diagonale fisica di almeno 6,35 cm.
I dispositivi NON DEVONO modificare le dimensioni dello schermo registrate in nessun momento.
Le applicazioni possono indicare facoltativamente le dimensioni dello schermo supportate tramite l'attributo
7.1.1.2. Proporzioni dello schermo
|
I dispositivi Android Watch POSSONO avere proporzioni pari a 1,0 (1:1). |
Il formato dello schermo DEVE essere un valore compreso tra 1,3333 (4:3) e 1,86 (circa 16:9), ma i dispositivi Android Watch POSSONO avere un formato 1,0 (1:1) perché l'implementazione di un dispositivo di questo tipo utilizzerà un valore UI_MODE_TYPE_WATCH come android.content.res.Configuration.uiMode.
7.1.1.3. Densità schermo
Il framework UI di Android definisce un insieme di densità logiche standard per aiutare gli sviluppatori di applicazioni a scegliere come target le risorse dell'applicazione. Le implementazioni dei dispositivi devono segnalare solo una delle seguenti densità logiche del framework Android tramite le API android.util.DisplayMetrics, devono eseguire le applicazioni a questa densità standard e non devono modificare il valore in nessun momento per la visualizzazione predefinita.
- 120 dpi (ldpi)
- 160 dpi (mdpi)
- 213 dpi (tvdpi)
- 240 dpi (hdpi)
- 320 dpi (xhdpi)
- 400 dpi (400dpi)
- 480 dpi (xxhdpi)
- 560 dpi (560dpi)
- 640 dpi (xxxhdpi)
Le implementazioni dei dispositivi DOVREBBERO definire la densità del framework Android standard che è numericamente più vicina alla densità fisica dello schermo, a meno che la densità logica non riduca le dimensioni dello schermo registrate al di sotto del minimo supportato. Se la densità del framework Android standard più vicina numericamente alla densità fisica genera dimensioni dello schermo inferiori alle dimensioni dello schermo compatibile più piccole supportate (larghezza di 320 dp), le implementazioni del dispositivo DEVONO registrare la densità del framework Android standard successiva più bassa.
7.1.2. Metriche relative alla visualizzazione
Le implementazioni dei dispositivi DEVONO riportare valori corretti per tutte le metriche del display definite in android.util.DisplayMetrics [Resources, 62] e DEVONO riportare gli stessi valori indipendentemente dall'utilizzo dello schermo integrato o esterno come display predefinito.
7.1.3. Orientamento schermo
I dispositivi DEVONO indicare gli orientamenti dello schermo supportati (android.hardware.screen.portrait e/o android.hardware.screen.landscape) e DEVONO indicare almeno un orientamento supportato. Ad esempio, un dispositivo con uno schermo orizzontale con orientamento fisso, come una TV o un laptop, DOVREBBE registrare solo android.hardware.screen.landscape.
I dispositivi che segnalano entrambi gli orientamenti dello schermo DEVONO supportare l'orientamento dinamico da parte delle applicazioni sia in orientamento verticale che orizzontale. In altre parole, il dispositivo deve rispettare la richiesta dell'applicazione di un orientamento specifico dello schermo. Le implementazioni dei dispositivi POSSONO selezionare l'orientamento verticale o orizzontale come predefinito.
I dispositivi DEVONO riportare il valore corretto per l'orientamento corrente del dispositivo, ogni volta che viene eseguito una query tramite android.content.res.Configuration.orientation, android.view.Display.getOrientation() o altre API.
I dispositivi NON DEVONO modificare le dimensioni o la densità dello schermo registrate quando si cambia orientamento.
7.1.4. Accelerazione grafica 2D e 3D
Le implementazioni dei dispositivi DEVONO supportare sia OpenGL ES 1.0 sia 2.0, come descritto e dettagliato nella documentazione dell'SDK Android. Le implementazioni dei dispositivi DEVONO supportare OpenGL ES 3.0 o 3.1 sui dispositivi in grado di supportarlo. Le implementazioni dei dispositivi DEVONO supportare anche Android RenderScript, come descritto nella documentazione dell'SDK Android [Risorse, 63].
Le implementazioni dei dispositivi DEVONO anche identificarsi correttamente come supportanti OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 o OpenGL 3.1. ovvero:
- Le API gestite (ad esempio tramite il metodo GLES10.getString()) DEVONO segnalare il supporto per OpenGL ES 1.0 e OpenGL ES 2.0.
- Le API OpenGL native C/C++ (API disponibili per le app tramite libGLES_v1CM.so, libGLES_v2.so o libEGL.so) DEVONO segnalare il supporto per OpenGL ES 1.0 e OpenGL ES 2.0.
- Le implementazioni dei dispositivi che dichiarano il supporto di OpenGL ES 3.0 o 3.1 DEVONO supportare le API gestite corrispondenti e includere il supporto per le API C/C++ native. Nelle implementazioni del dispositivo che dichiarano il supporto di OpenGL ES 3.0 o 3.1, libGLESv2.so DEVE esportare i simboli di funzione corrispondenti oltre ai simboli di funzione di OpenGL ES 2.0.
Oltre a OpenGL ES 3.1, Android fornisce un pacchetto di estensioni con interfacce Java [Resources, 64] e il supporto nativo per funzionalità grafiche avanzate come la tessellation e il formato di compressione delle texture ASTC. Le implementazioni dei dispositivi Android POSSONO supportare questo pacchetto di estensioni e, solo se completamente implementate, DEVONO identificare il supporto tramite il flag della funzionalità android.hardware.opengles.aep.
Inoltre, le implementazioni dei dispositivi POSSONO implementare le estensioni OpenGL ES desiderate. Tuttavia, le implementazioni dei dispositivi DEVONO segnalare tramite le API native e gestite di OpenGL ES tutte le stringhe di estensione supportate e, al contrario, NON DEVONO segnalare le stringhe di estensione non supportate.
Tieni presente che Android include il supporto per le applicazioni che possono specificare facoltativamente che richiedono formati di compressione delle texture OpenGL specifici. Questi formati sono tipicamente specifici del fornitore. Le implementazioni dei dispositivi non sono richieste da Android per implementare un formato di compressione delle texture specifico. Tuttavia, DOVREBBERO segnalare con precisione tutti i formati di compressione delle texture supportati tramite il metodo getString() nell'API OpenGL.
Android include un meccanismo per consentire alle applicazioni di dichiarare di voler attivare l'accelerazione hardware per la grafica 2D a livello di applicazione, attività, finestra o visualizzazione tramite l'utilizzo di un tag manifest android:hardwareAccelerated o chiamate API dirette [Risorse, 65].
Le implementazioni dei dispositivi DEVONO attivare l'accelerazione hardware per impostazione predefinita e DEVONO disattivarla se lo sviluppatore lo richiede impostando android:hardwareAccelerated="false" o disattivando l'accelerazione hardware direttamente tramite le API Android View.
Inoltre, le implementazioni dei dispositivi DEVONO avere un comportamento coerente con la documentazione dell'SDK Android sull'accelerazione hardware [Risorse, 65].
Android include un oggetto TextureView che consente agli sviluppatori di integrare direttamente le texture OpenGL ES con accelerazione hardware come target di rendering in una gerarchia dell'interfaccia utente. Le implementazioni dei dispositivi DEVONO supportare l'API TextureView e DEVONO avere un comportamento coerente con l'implementazione di Android a monte.
Android include il supporto di EGL_ANDROID_RECORDABLE, un attributo EGLConfig che indica se EGLConfig supporta il rendering in un ANativeWindow che registra le immagini in un video. Le implementazioni dei dispositivi DEVONO supportare l'estensione EGL_ANDROID_RECORDABLE [Risorse, 66].
7.1.5. Modalità di compatibilità delle applicazioni precedenti
Android specifica una "modalità di compatibilità" in cui il framework opera in una modalità equivalente a una dimensione dello schermo "normale" (larghezza di 320 dp) a vantaggio delle applicazioni legacy non sviluppate per le versioni precedenti di Android precedenti all'indipendenza dalle dimensioni dello schermo. Le implementazioni dei dispositivi DEVONO includere il supporto della modalità di compatibilità delle applicazioni precedenti, come implementata dal codice open source Android di upstream. In altre parole, le implementazioni dei dispositivi NON DEVONO modificare gli attivatori o le soglie a cui viene attivata la modalità di compatibilità e NON DEVONO modificare il comportamento della modalità di compatibilità stessa.
7.1.6. Tecnologia dello schermo
La piattaforma Android include API che consentono alle applicazioni di eseguire il rendering di grafica avanzata sul display. I dispositivi DEVONO supportare tutte queste API come definite dall'SDK Android, a meno che non sia specificamente consentito in questo documento.
- I dispositivi DEVONO supportare display in grado di eseguire il rendering di grafica a colori a 16 bit e DEVONO supportare display in grado di eseguire il rendering di grafica a colori a 24 bit.
- I dispositivi DEVONO supportare display in grado di eseguire il rendering delle animazioni.
- La tecnologia di visualizzazione utilizzata DEVE avere un rapporto di aspetto dei pixel (PAR) compreso tra 0,9 e 1,15. In altre parole, le proporzioni dei pixel DEVONO essere quasi quadrate (1,0) con una tolleranza del 10-15%.
7.1.7. Display esterni
Android include il supporto per il display secondario per abilitare le funzionalità di condivisione dei contenuti multimediali e le API per sviluppatori per accedere ai display esterni. Se un dispositivo supporta un display esterno tramite una connessione con cavo, wireless o un display aggiuntivo integrato, l'implementazione del dispositivo DEVE implementare l'API Display Manager come descritto nella documentazione dell'SDK Android [Risorse, 67].
7.2. Dispositivi di immissione
7.2.1. Tastiera
|
I dispositivi Android Watch POSSONO, ma le implementazioni di altri tipi di dispositivi DEVONO, implementare una tastiera virtuale. |
Implementazioni dei dispositivi:
- DEVE includere il supporto per l'Input Management Framework (che consente agli sviluppatori di terze parti di creare editor di metodi di inserimento, ovvero tastiere virtuali) come descritto all'indirizzo http://developer.android.com
- DEVE fornire almeno un'implementazione di tastiera software (indipendentemente dal fatto che sia presente una tastiera hardware), ad eccezione dei dispositivi Android Watch in cui le dimensioni dello schermo rendono meno ragionevole avere una tastiera software
- POTREBBE includere implementazioni aggiuntive della tastiera su schermo
- POTREBBE includere una tastiera hardware
- NON DEVE includere una tastiera hardware che non corrisponda a uno dei formati specificati in android.content.res.Configuration.keyboard [Resources, 68] (QWERTY o 12 tasti)
7.2.2. Navigazione non tocco
|
I dispositivi Android TV DEVONO supportare il D-pad. |
Implementazioni dei dispositivi:
- È POSSIBILE omettere un'opzione di navigazione non touch (trackball, d-pad o rotella) se l'implementazione del dispositivo non è un dispositivo Android TV
- DEVE riportare il valore corretto per android.content.res.Configuration.navigation [Resources, 68]
- DEVE fornire un meccanismo di interfaccia utente alternativo ragionevole per la selezione e la modifica del testo, compatibile con i motori di gestione dell'input. L'implementazione open source di Android upstream include un meccanismo di selezione adatto per l'utilizzo con dispositivi che non dispongono di input di navigazione non touch.
7.2.3. Tasti di navigazione
|
Il requisito di disponibilità e visibilità delle funzioni Home, Recenti e Indietro differisce a seconda del tipo di dispositivo, come descritto in questa sezione. |
Le funzioni Home, Recenti e Indietro (rispettivamente mappate agli eventi chiave KEYCODE_HOME, KEYCODE_APP_SWITCH, KEYCODE_BACK) sono essenziali per il paradigma di navigazione di Android e quindi:
- Le implementazioni dei dispositivi Android portatili DEVONO fornire le funzioni Home, Recenti e Indietro.
- Le implementazioni dei dispositivi Android TV DEVONO fornire le funzioni Home e Indietro.
- Le implementazioni dei dispositivi Android Watch DEVONO avere la funzione Home disponibile per l'utente e la funzione Indietro, tranne quando è in UI_MODE_TYPE_WATCH.
- Tutti gli altri tipi di implementazioni dei dispositivi DEVONO fornire le funzioni Home e Indietro.
Queste funzioni POSSONO essere implementate tramite pulsanti fisici dedicati (ad esempio pulsanti touch meccanici o capacitivi) o POSSONO essere implementate utilizzando tasti software dedicati su una parte distinta dello schermo, gesti, pannello touch e così via. Android supporta entrambe le implementazioni. Tutte queste funzioni DEVONO essere accessibili con una singola azione (ad es. tocco, doppio clic o gesto) quando sono visibili.
La funzione Recenti, se fornita, DEVE avere un pulsante o un'icona visibile, a meno che non sia nascosta insieme ad altre funzioni di navigazione in modalità a schermo intero. Questo non si applica ai dispositivi su cui viene eseguito l'upgrade da versioni precedenti di Android che dispongono di pulsanti fisici per la navigazione e non hanno il tasto Recenti.
Le funzioni Home e Indietro, se fornite, DEVONO avere ciascuna un pulsante o un'icona visibili, a meno che non siano nascoste insieme ad altre funzioni di navigazione in modalità a schermo intero o quando uiMode UI_MODE_TYPE_MASK è impostato su UI_MODE_TYPE_WATCH.
La funzione Menu è stata ritirata a favore della barra delle app da Android 4.0. Pertanto, le implementazioni dei nuovi dispositivi con Android 5.0 NON DEVONO implementare un pulsante fisico dedicato per la funzione Menu. Le implementazioni dei dispositivi meno recenti NON DEVONO implementare un pulsante fisico dedicato per la funzione Menu, ma se il pulsante Menu fisico è implementato e il dispositivo esegue applicazioni con targetSdkVersion > 10, l'implementazione del dispositivo:
- DEVE mostrare il pulsante del menu extra delle azioni nella barra delle azioni quando è visibile e il menu popup del menu extra delle azioni risultante non è vuoto. Per un'implementazione di un dispositivo lanciata prima di Android 4.4, ma con upgrade ad Android 5.0, questa è la soluzione CONSIGLIATA.
- NON DEVE modificare la posizione del popup del menu extra delle azioni visualizzato selezionando il pulsante del menu extra nella barra delle azioni
- POTREBBE visualizzare il popup extra delle azioni in una posizione modificata sullo schermo quando viene visualizzato selezionando il pulsante del menu fisico
Per la compatibilità con le versioni precedenti, le implementazioni dei dispositivi DEVONO rendere disponibile la funzione Menu per le applicazioni quando targetSdkVersion <= 10 tramite un pulsante fisico, una chiave software o gesti. Questa funzione Menu deve essere presentata se non nascosta insieme ad altre funzioni di navigazione.
Android supporta l'azione Assist [Risorse, 69]. Le implementazioni dei dispositivi Android, ad eccezione dei dispositivi Android Watch, DEVONO rendere l'azione di assistenza disponibile all'utente in qualsiasi momento durante l'esecuzione delle applicazioni. L'azione di assistenza DEVE essere implementata come pressione prolungata sul pulsante Home o come gesto di scorrimento verso l'alto sul tasto Home software. Questa funzione PUÒ essere implementata tramite un altro pulsante fisico, un tasto software o un gesto, ma DEVE essere accessibile con una singola azione (ad es. tocco, doppio clic o gesto) quando sono visibili altri tasti di navigazione.
Le implementazioni dei dispositivi POSSONO utilizzare una parte distinta dello schermo per visualizzare i tasti di navigazione, ma in questo caso DEVONO soddisfare i seguenti requisiti:
- I tasti di navigazione per l'implementazione del dispositivo DEVONO utilizzare una parte distinta dello schermo, non disponibile per le applicazioni, e NON DEVONO coprire o interferire con la parte dello schermo disponibile per le applicazioni.
- Le implementazioni dei dispositivi DEVONO rendere disponibile una parte del display per le applicazioni che soddisfano i requisiti definiti nella sezione 7.1.1.
- Le implementazioni dei dispositivi DEVONO mostrare i tasti di navigazione quando le applicazioni non specificano una modalità dell'interfaccia utente di sistema o specificano SYSTEM_UI_FLAG_VISIBLE.
- Le implementazioni dei dispositivi DEVONO presentare i tasti di navigazione in una modalità "basso profilo" (ad es. attenuata) non invadente quando le applicazioni specificano SYSTEM_UI_FLAG_LOW_PROFILE.
- Le implementazioni dei dispositivi DEVONO nascondere i tasti di navigazione quando le applicazioni specificano SYSTEM_UI_FLAG_HIDE_NAVIGATION.
7.2.4. Input touchscreen
|
I dispositivi Android e gli smartwatch DEVONO supportare l'input touchscreen. |
Le implementazioni dei dispositivi DEVONO avere un sistema di input del cursore di qualche tipo (simile a un mouse o tocco). Tuttavia, se l'implementazione di un dispositivo non supporta un sistema di input del cursore, NON DEVE segnalare la costante della funzionalità android.hardware.touchscreen o android.hardware.faketouch. Implementazioni di dispositivi che includono un sistema di input del cursore:
- DOVREBBE supportare cursori monitorati in modo completamente indipendente, se il sistema di input del dispositivo supporta più cursori
- DEVE riportare il valore di android.content.res.Configuration.touchscreen [Resources, 68] corrispondente al tipo di touchscreen specifico sul dispositivo
Android include il supporto di una serie di touchscreen, touchpad e dispositivi di input touch simulati. Le implementazioni dei dispositivi basati su touchscreen sono associate a un display [Risorse, 70] in modo che l'utente abbia l'impressione di manipolare direttamente gli elementi sullo schermo. Poiché l'utente tocca direttamente lo schermo, il sistema non richiede alcun'altra funzionalità per indicare gli oggetti manipolati. Al contrario, un'interfaccia tocco falsa fornisce un sistema di input utente che approssima un sottoinsieme di funzionalità del touchscreen. Ad esempio, un mouse o un controllino remoto che gestisce un cursore sullo schermo si avvicina al tocco, ma richiede all'utente di prima selezionare o mettere a fuoco un elemento e poi fare clic. Numerosi dispositivi di input come mouse, trackpad, mouse aereo basato su giroscopio, cursore a giroscopio, joystick e trackpad multi-touch possono supportare interazioni touch false. Android 5.0 include la costante di funzionalità android.hardware.faketouch, che corrisponde a un dispositivo di input non touch (basato su cursore) ad alta fedeltà, come un mouse o un trackpad, che può emulare adeguatamente l'input basato sul tocco (incluso il supporto di gesti di base) e indica che il dispositivo supporta un sottoinsieme emulato delle funzionalità del touchscreen. Le implementazioni dei dispositivi che dichiarano la funzionalità di tocco falso DEVONO soddisfare i requisiti relativi al tocco falso descritti nella sezione 7.2.5.
Le implementazioni dei dispositivi DEVONO segnalare la funzionalità corretta corrispondente al tipo di input utilizzato. Le implementazioni dei dispositivi che includono un touchscreen (single-touch o superiore) DEVONO segnalare la costante della funzionalità della piattaforma android.hardware.touchscreen. Le implementazioni dei dispositivi che segnalano la costante della funzionalità della piattaforma android.hardware.touchscreen DEVONO segnalare anche la costante della funzionalità della piattaforma android.hardware.faketouch. Le implementazioni dei dispositivi che non includono un touchscreen (e si basano solo su un dispositivo di puntamento) NON DEVONO segnalare alcuna funzionalità del touchscreen e DEVONO segnalare solo android.hardware.faketouch se soddisfano i requisiti di tocco falso descritti nella sezione 7.2.5.
7.2.5. Input tocco simulato
Implementazioni del dispositivo che dichiarano il supporto di android.hardware.faketouch:
- DEVE segnalare le posizioni X e Y assolute dello schermo della posizione del cursore e mostrare un cursore visivo sullo schermo [Risorse, 71]
- DEVE segnalare l'evento tocco con il codice azione che specifica la variazione di stato che si verifica quando il cursore si sposta verso il basso o verso l'alto sullo schermo [Risorse, 71]
- DEVE supportare il movimento del cursore verso il basso e verso l'alto su un oggetto sullo schermo, il che consente agli utenti di simulare il tocco di un oggetto sullo schermo
- DEVE supportare il cursore verso il basso, il cursore verso l'alto, il cursore verso il basso e poi il cursore verso l'alto nello stesso luogo su un oggetto sullo schermo entro una soglia di tempo, che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo [Risorse, 71]
- DEVE supportare il cursore verso il basso su un punto arbitrario dello schermo, il cursore si sposta su qualsiasi altro punto arbitrario dello schermo, seguito da un cursore verso l'alto, che consente agli utenti di emulare un trascinamento tocco
- DEVE supportare il cursore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in un'altra posizione sullo schermo e poi verso l'alto sullo schermo, il che consente agli utenti di lanciare un oggetto sullo schermo
I dispositivi che dichiarano il supporto di android.hardware.faketouch.multitouch.distinct devono soddisfare i requisiti per il faketouch sopra indicati e devono anche supportare il monitoraggio distinto di due o più input del cursore indipendenti.
7.2.6. Supporto del controller di gioco
Le implementazioni dei dispositivi Android TV DEVONO supportare le mappature dei pulsanti per i controller per giochi come elencato di seguito. L'implementazione di Android a monte include l'implementazione per i controller di gioco che soddisfano questo requisito.
7.2.6.1. Mappature dei pulsanti
Le implementazioni dei dispositivi Android TV DEVONO supportare le seguenti mappature delle chiavi:
|
Button |
Utilizzo HID2 |
Pulsante Android |
|
A1 |
0x09 0x0001 |
KEYCODE_BUTTON_A (96) |
|
B1 |
0x09 0x0002 |
KEYCODE_BUTTON_B (97) |
|
X1 |
0x09 0x0004 |
KEYCODE_BUTTON_X (99) |
|
Y1 |
0x09 0x0005 |
KEYCODE_BUTTON_Y (100) |
|
0x01 0x00393 |
||
|
0x01 0x00393 |
||
|
0x09 0x0007 |
KEYCODE_BUTTON_L1 (102) |
|
|
0x09 0x0008 |
KEYCODE_BUTTON_R1 (103) |
|
|
0x09 0x000E |
KEYCODE_BUTTON_THUMBL (106) |
|
|
0x09 0x000F |
KEYCODE_BUTTON_THUMBR (107) |
|
|
Home1 |
0x0c 0x0223 |
KEYCODE_HOME (3) |
|
0x0c 0x0224 |
KEYCODE_BACK (4) |
1 [Risorse, 72]
2 Gli utilizzi HID sopra indicati devono essere dichiarati all'interno di una CA per gamepad (0x01 0x0005).
3 Questo utilizzo deve avere un valore minimo logico di 0, un valore massimo logico di 7, un valore minimo fisico di 0, un valore massimo fisico di 315, unità in gradi e una dimensione del report di 4. Il valore logico è definito come la rotazione in senso orario allontanata dall'asse verticale; ad esempio, un valore logico pari a 0 rappresenta nessuna rotazione e il pulsante su premuto, mentre un valore logico pari a 1 rappresenta una rotazione di 45 gradi e i tasti su e sinistra premuti.
4 [Risorse, 71]
|
Controlli analogici1 |
Utilizzo HID |
Pulsante Android |
|
0x02 0x00C5 |
AXIS_LTRIGGER |
|
|
0x02 0x00C4 |
AXIS_RTRIGGER |
|
|
0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
|
|
0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
1 [Risorse, 71]
7.2.7. Telecomando
Le implementazioni dei dispositivi Android TV DEVONO fornire un telecomando per consentire agli utenti di accedere all'interfaccia TV. Il telecomando PUÒ essere un telecomando fisico o un telecomando basato su software accessibile da un cellulare o un tablet. Il telecomando DEVE soddisfare i requisiti definiti di seguito.
- Affordance di ricerca: le implementazioni del dispositivo DEVONO attivare KEYCODE_SEARCH quando l'utente richiama la ricerca vocale sul telecomando fisico o basato su software.
- Navigazione: tutti i telecomandi Android TV DEVONO includere i pulsanti Indietro, Home e Seleziona e supportare gli eventi del D-pad [Risorse, 72].
7.3. Sensori
Android include API per accedere a diversi tipi di sensori. Le implementazioni dei dispositivi in genere POSSONO omettere questi sensori, come previsto nelle seguenti sezioni. Se un dispositivo include un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android e nella documentazione Android Open Source sui sensori [Risorse, 73]. 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 [Risorse, 53]
- DEVE restituire un elenco accurato dei sensori supportati tramite SensorManager.getSensorList() e metodi simili
- DEVE comportarsi in modo ragionevole per tutte le altre API di sensori (ad esempio, restituendo true o false a seconda dei casi quando le applicazioni tentano di registrare gli ascoltatori, non chiamando gli ascoltatori dei sensori quando i sensori corrispondenti non sono presenti e così via).
- DEVE segnalare tutte le misurazioni dei sensori utilizzando i valori pertinenti del Sistema internazionale di misura (metrico) per ogni tipo di sensore come definito nella documentazione dell'SDK Android [Risorse, 74]
- DOVREBBE registrare la data e l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta la data e l'ora in cui si è verificato l'evento e sincronizzata con il sistema SystemClock.elapsedRealtimeNano(). I dispositivi Android esistenti e nuovi sono vivamente incoraggiati a soddisfare questi requisiti in modo da poter eseguire l'upgrade alle future release della piattaforma in cui questo potrebbe diventare un componente OBBLIGATORIO. L'errore di sincronizzazione DEVE essere inferiore a 100 millisecondi [Risorse, 75].
L'elenco riportato sopra non è esaustivo; il comportamento documentato dell'SDK Android e della documentazione Android Open Source sui sensori [Risorse, 73] deve essere considerato autorevole.
Alcuni tipi di sensori sono composti, il che significa che possono essere ricavati dai dati forniti da uno o più altri sensori. Alcuni esempi sono il sensore di orientamento e il sensore di accelerazione lineare. Le implementazioni dei dispositivi DEVONO implementare questi tipi di sensori, se includono i sensori fisici prerequisiti come descritto in [Risorse, 76]. Se l'implementazione di un dispositivo include un sensore composito, DEVE implementare il sensore come descritto nella documentazione Android Open Source sui sensori compositi [Risorse, 76].
Alcuni sensori Android supportano una modalità di attivazione "continua", che restituisce i dati continuamente [Risorse, 77]. Affinché qualsiasi API indicata dalla documentazione dell'SDK Android sia un sensore continuo, le implementazioni del dispositivo DEVONO fornire continuamente campioni di dati periodici che DOVREBBERO avere un jitter inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori timestamp registrati tra gli eventi consecutivi.
Tieni presente che le implementazioni del dispositivo DEVONO garantire che lo stream di eventi del sensore NON DEVE impedire alla CPU del dispositivo di entrare in uno stato di sospensione o di risvegliarsi da uno stato di sospensione.
Infine, quando sono attivati più sensori, il consumo di energia NON DEVE superare la somma del consumo di energia registrato dal singolo sensore.
7.3.1. Accelerometro
Le implementazioni dei dispositivi DEVONO includere un accelerometro a 3 assi. È vivamente consigliato includere questo sensore nei dispositivi Android e Android Watch. Se l'implementazione di un dispositivo include un accelerometro a 3 assi:
- È NECESSARIO implementare e segnalare il sensore TYPE_ACCELEROMETER [Risorse, 78]
- DEVE essere in grado di registrare eventi fino a una frequenza di almeno 100 Hz e DEVE registrare eventi fino ad almeno 200 Hz
- DEVE essere conforme al sistema di coordinate del sensore Android come descritto nelle API Android [Risorse, 74]
- DEVE essere in grado di misurare dalla caduta libera fino a quattro volte la gravità (4 g) o più su qualsiasi asse
- DEVE avere una risoluzione minima di 8 bit e DOVREBBE avere una risoluzione minima di almeno 16 bit
- DEVE essere calibrato durante l'uso se le caratteristiche cambiano nel ciclo di vita e vengono compensate e deve conservare i parametri di compensazione tra i riavvii del dispositivo
- DOVREBBE essere compensata in base alla temperatura
- DEVE avere una deviazione standard non superiore a 0,05 m/s^, dove la deviazione standard deve essere calcolata in base all'asse sui campioni raccolti su un periodo di almeno 3 secondi alla frequenza di campionamento più elevata
- DEVE implementare i sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento SDK Android. Per i dispositivi Android esistenti e nuovi è vivamente consigliato di implementare il sensore composito TYPE_SIGNIFICANT_MOTION. Se uno di questi sensori è implementato, la somma del loro consumo di energia DEVE essere sempre inferiore a 4 mW e OGNI sensore DEVE essere inferiore a 2 mW e 0,5 mW quando il dispositivo è in una condizione dinamica o statica.
- Se è incluso un sensore giroscopico, DEVE implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION e DOVREBBE implementare il sensore composito TYPE_GAME_ROTATION_VECTOR. I dispositivi Android esistenti e nuovi sono vivamente invitati a implementare il sensore TYPE_GAME_ROTATION_VECTOR.
- DOVREBBE implementare un sensore composito TYPE_ROTATION_VECTOR, se sono inclusi anche un sensore giroscopico e un sensore magnetometrico
7.3.2. Magnetometro
Le implementazioni dei dispositivi DEVONO includere un magnetometro a 3 assi (bussola). Se un dispositivo include un magnetometro a 3 assi:
- DEVE implementare il sensore TYPE_MAGNETIC_FIELD e DEVE anche implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED. È vivamente consigliato di implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED sui dispositivi Android esistenti e nuovi.
- DEVE essere in grado di registrare eventi fino a una frequenza di almeno 10 Hz e DEVE registrare eventi fino ad almeno 50 Hz
- DEVE essere conforme al sistema di coordinate del sensore Android come descritto nelle API Android [Risorse, 74]
- DEVE essere in grado di misurare tra -900 μT e +900 μT su ogni asse prima di saturare
- DEVE avere un valore di offset del ferro duro inferiore a 700 μT e DOVREBBE avere un valore inferiore a 200 μT, posizionando il magnetometro lontano da campi magnetici dinamici (indotti dalla corrente) e statici (indotti dal magnete)
- DEVE avere una risoluzione uguale o superiore a 0,6 μT e DEVE avere una risoluzione uguale o superiore a 0,2 μT
- DEVE essere compensata in base alla temperatura
- DEVE supportare la calibrazione e la compensazione online dell'errore di ferro duro e conservare i parametri di compensazione tra i riavvii del dispositivo
- DEVE essere applicata la compensazione del ferro dolce. La calibrazione può essere eseguita durante l'uso o durante la produzione del dispositivo
- DEVE avere una deviazione standard, calcolata in base all'asse, sui campioni raccolti su un periodo di almeno 3 secondi alla frequenza di campionamento più elevata, non superiore a 0,5 μT
- DOVREBBE implementare un sensore composito TYPE_ROTATION_VECTOR, se sono inclusi anche un sensore di accelerazione e un sensore di giroscopio
- PUO' implementare il sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR se è implementato anche un sensore di accelerazione. Tuttavia, se implementato, DEVE consumare meno di 10 mW e DOVREBBE consumare meno di 3 mW quando il sensore è registrato per la modalità batch a 10 Hz.
7.3.3. GPS
Le implementazioni dei dispositivi DEVONO includere un ricevitore GPS. Se l'implementazione di un dispositivo include un ricevitore GPS, DEVE includere una qualche forma di tecnica "GPS assistito" per ridurre al minimo il tempo di accoppiamento del GPS.
7.3.4. Giroscopio
Le implementazioni dei dispositivi DEVONO includere un giroscopio (sensore di variazione angolare). I dispositivi NON DEVONO includere un sensore giroscopio, a meno che non sia incluso anche un accelerometro a 3 assi. Se l'implementazione di un dispositivo include un giroscopio:
- DEVE implementare il sensore TYPE_GYROSCOPE e DEVE anche implementare il sensore TYPE_GYROSCOPE_UNCALIBRATED. È vivamente consigliato di implementare il sensore SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sui dispositivi Android esistenti e nuovi.
- DEVE essere in grado di misurare le variazioni di orientamento fino a 1000 gradi al secondo
- DEVE essere in grado di registrare eventi fino a una frequenza di almeno 100 Hz e DEVE registrare eventi fino ad almeno 200 Hz
- DEVE avere una risoluzione di almeno 12 bit e DOVREBBE avere una risoluzione di almeno 16 bit
- DEVE essere compensato in base alla temperatura
- DEVE essere calibrato e compensato durante l'uso e deve conservare i parametri di compensazione tra i riavvii del dispositivo
- DEVE avere una varianza non superiore a 1e-7 rad^2 / s^2 per Hz (varianza per Hz o rad^2 / s). La varianza può variare con la frequenza di campionamento, ma deve essere limitata da questo valore. In altre parole, se misuri la varianza del giroscopio a una frequenza di campionamento di 1 Hz, non deve essere superiore a 1e-7 rad^2/s^2.
- DEVE implementare un sensore composito TYPE_ROTATION_VECTOR, se sono inclusi anche un sensore di accelerazione e un sensore magnetometrico
- Se è incluso un sensore di accelerazione, DEVE implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION e DOVREBBE implementare il sensore composito TYPE_GAME_ROTATION_VECTOR. I dispositivi Android esistenti e nuovi sono vivamente invitati a implementare il sensore TYPE_GAME_ROTATION_VECTOR.
7.3.5. Barometro
Le implementazioni dei dispositivi DEVONO includere un barometro (sensore di pressione dell'aria ambiente). Se un'implementazione del dispositivo include un barometro:
- È NECESSARIO implementare e segnalare il sensore TYPE_PRESSURE
- DEVE essere in grado di inviare eventi a una frequenza di almeno 5 Hz
- DEVE avere una precisione adeguata per consentire la stima dell'altitudine
- DEVE essere compensato in base alla temperatura
7.3.6. Termometro
Le implementazioni del dispositivo POSSONO includere un termometro ambiente (sensore di temperatura). Se presente, DEVE essere definito come SENSOR_TYPE_AMBIENT_TEMPERATURE e DEVE misurare la temperatura ambiente (della stanza) in gradi Celsius.
Le implementazioni dei dispositivi POSSONO, ma NON DEVONO, includere un sensore di temperatura della CPU. Se presente, DEVE essere definito come SENSOR_TYPE_TEMPERATURE, DEVE misurare la temperatura della CPU del dispositivo e NON DEVE misurare altre temperature. Tieni presente che il tipo di sensore SENSOR_TYPE_TEMPERATURE è stato ritirato in Android 4.0.
7.3.7. Fotometro
Le implementazioni del dispositivo POSSONO includere un fotometro (sensore di luce ambientale).
7.3.8. Sensore di prossimità
Le implementazioni del dispositivo POSSONO includere un sensore di prossimità. I dispositivi in grado di effettuare una chiamata vocale e di indicare un valore diverso da PHONE_TYPE_NONE in getPhoneType DEVONO includere un sensore di prossimità. Se un'implementazione del dispositivo include un sensore di prossimità, deve:
- DEVE misurare la vicinanza di un oggetto nella stessa direzione dello schermo. In altre parole, il sensore di prossimità DEVE essere orientato in modo da rilevare gli oggetti vicini allo schermo, poiché lo scopo principale di questo tipo di sensore è rilevare uno smartphone in uso dall'utente. Se l'implementazione di un dispositivo include un sensore di prossimità con un altro orientamento, NON DEVE essere accessibile tramite questa API.
- DEVE avere una precisione di almeno 1 bit
7.4. Connettività dei dati
7.4.1. Telefonia
"Telefonia" come utilizzato dalle API Android e da questo documento si riferisce specificamente all'hardware relativo all'effettuazione di chiamate vocali e all'invio di messaggi SMS tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano o meno essere con commutazione di pacchetti, ai fini di Android sono considerate indipendenti da qualsiasi connettività di dati che possa essere implementata utilizzando la stessa rete. In altre parole, le API e la funzionalità "telefonia" di Android si riferiscono specificamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni dei dispositivi che non possono effettuare chiamate o inviare/ricevere messaggi SMS NON DEVONO segnalare la funzionalità android.hardware.telephony o eventuali sottofunzionalità, indipendentemente dal fatto che utilizzino una rete cellulare per la connettività dati.
Android PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. In altre parole, Android è compatibile con dispositivi diversi dagli smartphone. Tuttavia, se l'implementazione di un dispositivo include la telefonia GSM o CDMA, DEVE implementare il supporto completo dell'API per quella tecnologia. Le implementazioni dei dispositivi che non includono hardware di telefonia DEVONO implementare le API complete come no-op.
7.4.2. IEEE 802.11 (Wi-Fi)
|
Le implementazioni dei dispositivi Android TV DEVONO includere il supporto Wi-Fi. |
Le implementazioni dei dispositivi Android TV DEVONO includere il supporto di una o più forme di 802.11 (b/g/a/n e così via) e altri tipi di implementazioni dei dispositivi Android DOVREBBERO includere il supporto di una o più forme di 802.11. Se un'implementazione del dispositivo include il supporto per 802.11 ed espone la funzionalità a un'applicazione di terze parti, DEVE implementare l'API Android corrispondente e:
- DEVE segnalare il flag della funzionalità hardware android.hardware.wifi
- DEVE implementare l'API multicast come descritto nella documentazione dell'SDK [Risorse, 79]
- DEVE supportare il DNS multicast (mDNS) e NON DEVE filtrare i pacchetti mDNS (224.0.0.251) in qualsiasi momento di funzionamento, anche quando lo schermo non è attivo
7.4.2.1. Wi-Fi Direct
Le implementazioni dei dispositivi DEVONO includere il supporto di Wi-Fi Direct (Wi-Fi peer-to-peer). Se un'implementazione del dispositivo include il supporto di Wi-Fi Direct, DEVE implementare l'API Android corrispondente come descritto nella documentazione dell'SDK [Risorse, 80]. Se l'implementazione di un dispositivo include il supporto di Wi-Fi Direct, il dispositivo:
- DEVE segnalare la funzionalità hardware android.hardware.wifi.direct
- DEVE supportare il normale funzionamento del Wi-Fi
- DEVE supportare il funzionamento simultaneo del Wi-Fi e di Wi-Fi Direct
7.4.2.2. Configurazione del link diretto con tunnel Wi-Fi
|
Le implementazioni dei dispositivi Android TV DEVONO includere il supporto per la configurazione del link diretto in tunnel Wi-Fi (TDLS). |
Le implementazioni dei dispositivi Android TV DEVONO includere il supporto per la configurazione del link diretto in tunnel (TDLS) Wi-Fi e le implementazioni di altri tipi di dispositivi Android DOVREBBERO includere il supporto per il TDLS Wi-Fi come descritto nella documentazione dell'SDK Android [Risorse, 81]. Se l'implementazione di un dispositivo include il supporto di TDLS e TDLS è attivato dall'API WiFiManager, il dispositivo:
- DEVI utilizzare TDLS solo quando è possibile E utile
- DOVREBBE avere qualche euristica e NON utilizzare TDLS quando il rendimento potrebbe essere peggiore rispetto al passaggio tramite il punto di accesso Wi-Fi
7.4.3. Bluetooth
|
Le implementazioni dei dispositivi Android TV DEVONO supportare il Bluetooth e il Bluetooth LE, mentre le implementazioni dei dispositivi Android Watch DEVONO supportare il Bluetooth. |
Android include il supporto per Bluetooth e Bluetooth Low Energy [Risorse, 82]. Le implementazioni dei dispositivi che includono il supporto di Bluetooth e Bluetooth Low Energy DEVONO dichiarare le funzionalità della piattaforma pertinenti (rispettivamente android.hardware.bluetooth e android.hardware.bluetooth_le) e implementare le API della piattaforma. Le implementazioni dei dispositivi DOVREBBERO implementare profili Bluetooth pertinenti come A2DP, AVCP, OBEX e così via, a seconda del dispositivo. Le implementazioni dei dispositivi Android TV DEVONO supportare Bluetooth e Bluetooth LE.
Implementazioni dei dispositivi, incluso il supporto di Bluetooth Low Energy:
- DEVE dichiarare la funzionalità hardware android.hardware.bluetooth_le
- DEBBERO essere abilitate le API Bluetooth basate su GATT (Generic Attribute Profile) come descritto nella documentazione dell'SDK e in [Risorse, 82]
- DOVREBBE supportare lo sgravio della logica di filtro sul chipset Bluetooth quando viene implementata l'API ScanFilter [Risorse, 83] e DEVE segnalare il valore corretto della posizione in cui viene implementata la logica di filtro ogni volta che viene eseguita una query tramite il metodo android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported()
- DOVREBBE supportare lo sgravio della scansione collettiva sul chipset Bluetooth, ma se non è supportato, DEVE segnalare "false" ogni volta che viene eseguito un query tramite il metodo android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported()
- DOVREBBE supportare la pubblicità multipla con almeno 4 slot, ma se non è supportata, deve segnalare "false" ogni volta che viene eseguita una query tramite il metodo android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported()
7.4.4. Near Field Communication
Le implementazioni dei dispositivi DEVONO includere un transceiver e hardware correlato per la tecnologia Near Field Communication (NFC). Se l'implementazione di un dispositivo include hardware NFC e prevede di renderlo disponibile per le app di terze parti, deve:
- DEVE segnalare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature() [Risorse, 53]
- DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC:
- DEVE essere in grado di agire come lettore/scrittore NFC Forum (come definito dalla specifica tecnica NFC Forum NFCForum-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS 6319-4)
- IsoDep (ISO 14443-4)
- Tipi di tag NFC Forum 1, 2, 3, 4 (definiti dal NFC Forum)
- DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC. Tieni presente che, sebbene gli standard NFC riportati di seguito siano indicati come "DA FARE", è previsto di modificare la definizione di compatibilità per una versione futura in "DA FARE". Questi standard sono facoltativi in questa versione, ma saranno obbligatori nelle versioni future. I dispositivi esistenti e nuovi che eseguono questa versione di Android sono vivamente incoraggiati a soddisfare questi requisiti ora, in modo da poter eseguire l'upgrade alle future release della piattaforma.
- NfcV (ISO 15693)
- DEVE essere in grado di trasmettere e ricevere dati tramite i seguenti standard e protocolli peer-to-peer:
- ISO 18092
- LLCP 1.0 (definito dal NFC Forum)
- SDP 1.0 (definito dal NFC Forum)
- Protocollo push NDEF [Risorse, 84]
- SNEP 1.0 (definito dal NFC Forum)
- DEVE includere il supporto di Android Beam [Risorse, 85]:
- DEVE implementare il server SNEP predefinito. I messaggi NDEF validi ricevuti dal server SNEP predefinito DEVONO essere inviati alle applicazioni utilizzando l'intent android.nfc.ACTION_NDEF_DISCOVERED. La disattivazione di Android Beam nelle impostazioni NON DEVE disattivare l'invio di messaggi NDEF in arrivo.
- DEVE rispettare l'intent android.settings.NFCSHARING_SETTINGS per mostrare le impostazioni di condivisione NFC [Risorse, 86]
- DEVE implementare il server NPP. I messaggi ricevuti dal server NPP DEVONO essere elaborate nello stesso modo del server SNEP predefinito.
- DEVE implementare un client SNEP e tentare di inviare NDEF P2P in uscita al server SNEP predefinito quando Android Beam è attivo. Se non viene trovato un server SNEP predefinito, il client DEVE tentare di inviare a un server NPP.
- DEVE consentire alle attività in primo piano di impostare il messaggio NDEF P2P in uscita utilizzando android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback e android.nfc.NfcAdapter.enableForegroundNdefPush
- DOVREBBE utilizzare un gesto o una conferma sullo schermo, ad esempio "Tocca per trasmettere", prima di inviare messaggi NDEF P2P in uscita
- DOVREBBE attivare Android Beam per impostazione predefinita e DEVE essere in grado di inviare e ricevere utilizzando Android Beam, anche quando è attiva un'altra modalità P2P NFC proprietaria
- DEVE supportare il trasferimento della connessione NFC al Bluetooth quando il dispositivo supporta il profilo Bluetooth Object Push. Le implementazioni dei dispositivi DEVONO supportare il trasferimento della connessione al Bluetooth quando si utilizza android.nfc.NfcAdapter.setBeamPushUris, implementando le specifiche "Connection Handover version 1.2" [Risorse, 87] e "Bluetooth Secure Simple Pairing Using NFC version 1.0" [Risorse, 88] del NFC Forum. Una simile implementazione DEVE implementare il servizio LLCP di trasferimento con il nome di servizio "urn:nfc:sn:handover" per lo scambio dei record di selezione/richiesta di trasferimento tramite NFC e DEVE utilizzare il profilo Push di oggetti Bluetooth per il trasferimento effettivo dei dati Bluetooth. Per motivi di compatibilità con i dispositivi Android 4.1, l'implementazione DOVREBBE comunque accettare le richieste GET SNEP per lo scambio della richiesta di trasferimento/seleziona i record tramite NFC. Tuttavia, un'implementazione stessa NON DEVE inviare richieste GET SNEP per eseguire il trasferimento della connessione.
- DEVE eseguire il polling per tutte le tecnologie supportate in modalità di rilevamento NFC
- DOVREBBE essere in modalità di rilevamento NFC quando il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata
- DEVE essere in grado di agire come lettore/scrittore NFC Forum (come definito dalla specifica tecnica NFC Forum NFCForum-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
Tieni presente che i link disponibili pubblicamente non sono disponibili per le specifiche JIS, ISO e NFC Forum citate sopra.
Android 5.0 include il supporto per la modalità NFC Host Card Emulation (HCE). Se un'implementazione del dispositivo include un controller NFC in grado di gestire il routing HCE e AID (Application ID), deve:
- DEVE segnalare la costante della funzionalità android.hardware.nfc.hce
- DEVE supportare le API NFC HCE come definite nell'SDK Android [Risorse, 10]
Inoltre, le implementazioni dei dispositivi POSSONO includere il supporto di lettori/scrittori per le seguenti tecnologie MIFARE.
- MIFARE Classic
- MIFARE Ultralight
- NDEF su MIFARE Classic
Tieni presente che Android include le API per questi tipi di MIFARE. Se un'implementazione del dispositivo supporta MIFARE nel ruolo di lettore/scrittore:
- DEVE implementare le API Android corrispondenti come documentato dall'SDK Android
- DEVE segnalare la funzionalità com.nxp.mifare dal metodo android.content.pm.PackageManager.hasSystemFeature()[Resources, 53]. Tieni presente che questa non è una funzionalità standard di Android e, pertanto, non viene visualizzata come costante nella classe PackageManager.
- NON DEVE implementare le API Android corrispondenti né segnalare la funzionalità com.nxp.mifare, a meno che non implementi anche il supporto NFC generale come descritto in questa sezione
Se l'implementazione di un dispositivo non include hardware NFC, NON DEVE dichiarare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature() [Risorse, 53] e DEVE implementare l'API NFC di Android come no-op.
Poiché le classi android.nfc.NdefMessage e android.nfc.NdefRecord rappresentano un formato di rappresentazione dei dati indipendente dal protocollo, le implementazioni dei dispositivi DEVONO implementare queste API anche se non includono il supporto per NFC o dichiarano la funzionalità android.hardware.nfc.
7.4.5. Capacità di rete minima
Le implementazioni dei dispositivi DEVONO includere il supporto di una o più forme di reti di dati. Nello specifico, le implementazioni dei dispositivi DEVONO includere il supporto di almeno un protocollo di dati in grado di supportare una velocità di 200 Kbit/s o superiore. Alcuni esempi di tecnologie che soddisfano questo requisito sono EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN e così via.
Le implementazioni dei dispositivi in cui uno standard di rete fisica (ad esempio Ethernet) è la connessione dati principale DEVONO includere anche il supporto di almeno uno standard di dati wireless comune, ad esempio 802.11 (Wi-Fi).
I dispositivi POSSONO implementare più di una forma di connettività dati.
7.4.6. Impostazioni sincronizzazione
Le implementazioni dei dispositivi DEVONO avere l'impostazione di sincronizzazione automatica principale attiva per impostazione predefinita in modo che il metodo getMasterSyncAutomatically() restituisca "true" [Risorse, 89].
7.5. Fotocamere
Le implementazioni dei dispositivi DOVREBBERO includere una fotocamera posteriore e POTREBBERO includere una fotocamera anteriore. Una fotocamera posteriore è una fotocamera situata sul lato opposto al display del dispositivo, ovvero acquisisce le immagini sul lato opposto del dispositivo, come una fotocamera tradizionale. Una fotocamera anteriore è una fotocamera collocata sullo stesso lato del dispositivo del display, ovvero una fotocamera in genere utilizzata per acquisire immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.
Se l'implementazione di un dispositivo include almeno una fotocamera, DOVREBBE essere possibile per un'applicazione allocare contemporaneamente 3 bitmap uguali alle dimensioni delle immagini prodotte dal sensore della fotocamera con la risoluzione più alta sul dispositivo.
7.5.1. Fotocamera posteriore
Le implementazioni dei dispositivi DEVONO includere una fotocamera posteriore. Se l'implementazione di un dispositivo include almeno una fotocamera posteriore, deve:
- DEVE segnalare il flag della funzionalità android.hardware.camera e android.hardware.camera.any
- DEVE avere una risoluzione di almeno 2 megapixel
- DEVE avere la messa a fuoco automatica hardware o software implementata nel driver della fotocamera (trasparente al software dell'applicazione)
- POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa)
- PUO' includere un flash. Se la fotocamera include un flash, la lampada del flash NON DEVE essere accesa mentre è stata registrata un'istanza di android.hardware.Camera.PreviewCallback su una superficie di anteprima della fotocamera, a meno che l'applicazione non abbia attivato esplicitamente il flash attivando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON di un oggetto Camera.Parameters. Tieni presente che questo vincolo non si applica all'applicazione della fotocamera di sistema integrata del dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.
7.5.2. Fotocamera anteriore
Le implementazioni dei dispositivi POSSONO includere una fotocamera anteriore. Se l'implementazione di un dispositivo include almeno una fotocamera anteriore:
- DEVE segnalare il flag della funzionalità android.hardware.camera.any e android.hardware.camera.front
- DEVE avere una risoluzione di almeno VGA (640 x 480 pixel)
- NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Camera. L'API Camera in Android ha un supporto specifico per le fotocamere anteriori e le implementazioni dei dispositivi NON DEVONO configurare l'API in modo da trattare una fotocamera anteriore come la fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
- PUO' includere funzionalità (come messa a fuoco automatica, flash e così via) disponibili per le fotocamere rivolte all'indietro come descritto nella sezione 7.5.1
- DEVE riflettere orizzontalmente (ovvero rispecchiare) lo stream visualizzato da un'app in CameraPreview, come segue:
- Se l'implementazione del dispositivo può essere ruotata dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente), l'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto all'orientamento corrente del dispositivo.
- Se l'applicazione corrente ha richiesto esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation()[Resources, 90], l'anteprima della fotocamera DEVE essere ribaltata orizzontalmente rispetto all'orientamento specificato dall'applicazione.
- In caso contrario, l'anteprima DEVE essere speculare rispetto all'asse orizzontale predefinito del dispositivo.
- DEVE rispecchiare l'immagine visualizzata dalla visualizzazione post nello stesso modo dello stream di immagini di anteprima della videocamera. Se l'implementazione del dispositivo non supporta postview, questo requisito ovviamente non si applica.
- NON DEVE rispecchiare gli stream di video o immagini acquisiti finali restituiti ai callback dell'applicazione o sottoposti a commit nello spazio di archiviazione multimediale
7.5.3. Videocamera esterna
Le implementazioni dei dispositivi con modalità host USB POTREBBERO includere il supporto di una videocamera esterna collegata alla porta USB. Se un dispositivo include il supporto di una videocamera esterna:
- DEVE dichiarare la funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any
- DEVE supportare la classe video USB (UVC 1.0 o versioni successive)
- POTREBBE supportare più videocamere
È CONSIGLIATO supportare la compressione video (ad esempio MJPEG) per consentire il trasferimento di stream non codificati di alta qualità (ad es. stream di immagini non compressi o compressi in modo indipendente). La codifica video basata sulla fotocamera POTREBBE essere supportata. In questo caso, un simultaneo stream non codificato/ MJPEG (risoluzione QVGA o superiore) DEVE essere accessibile all'implementazione del dispositivo.
7.5.4. Comportamento dell'API Camera
Android include due pacchetti API per accedere alla fotocamera. La più recente API android.hardware.camera2 espone all'app il controllo della fotocamera a livello inferiore, inclusi flussi di scatti/streaming efficienti a copia zero e controlli per fotogramma di esposizione, guadagno, guadagni del bilanciamento del bianco, conversione del colore, riduzione del rumore, nitidezza e altro ancora.
Il pacchetto API precedente, android.hardware.Camera, è contrassegnato come deprecato in Android 5.0, ma poiché dovrebbe essere ancora disponibile per le app che utilizzano le implementazioni dei dispositivi Android, È NECESSARIO garantire il supporto continuo dell'API come descritto in questa sezione e nell'SDK Android.
Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API relative alle videocamere, per tutte le videocamere disponibili:
- Se un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int), il dispositivo DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione.
- Se un'applicazione registra un'istanza di android.hardware.Camera.PreviewCallback e il sistema chiama il metodo onPreviewFrame() quando il formato di anteprima è YCbCr_420_SP, i dati in byte[] passati a onPreviewFrame() devono essere inoltre nel formato di codifica NV21. In altre parole, NV21 DEVE essere il valore predefinito.
- Per android.hardware.Camera, le implementazioni del dispositivo DEVONO supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia anteriore che posteriore. L'encoder video hardware e la videocamera possono utilizzare qualsiasi formato pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione in YV12.
- Per android.hardware.camera2, le implementazioni del dispositivo devono supportare i formati android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG come output tramite l'API android.media.ImageReader.
Le implementazioni dei dispositivi DEVONO comunque implementare l'API Camera completa inclusa nella documentazione dell'SDK Android [Risorse, 91], indipendentemente dal fatto che il dispositivo includa l'autofocus hardware o altre funzionalità. Ad esempio, le fotocamere prive di messa a fuoco automatica DEVONO comunque chiamare eventuali istanze di android.hardware.Camera.AutoFocusCallback registrate (anche se questo non ha alcuna rilevanza per una fotocamera senza messa a fuoco automatica). Tieni presente che questo vale per le fotocamere anteriori. Ad esempio, anche se la maggior parte delle fotocamere anteriori non supporta l'autofocus, i callback dell'API devono comunque essere "falsi" come descritto.
Le implementazioni del dispositivo DEVONO riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters, se l'hardware di base supporta la funzionalità. Se l'hardware del dispositivo non supporta una funzionalità, l'API deve comportarsi come descritto nella documentazione. Al contrario, le implementazioni dei dispositivi NON DEVONO rispettare o riconoscere costanti di stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. In altre parole, le implementazioni del dispositivo DEVONO supportare tutti i parametri della videocamera standard, se l'hardware lo consente, e NON DEVONO supportare i tipi di parametri della videocamera personalizzati. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini utilizzando tecniche di imaging HDR (High Dynamic Range) DEVONO supportare il parametro della fotocamera Camera.SCENE_MODE_HDR [Risorse, 92].
Poiché non tutte le implementazioni dei dispositivi possono supportare completamente tutte le funzionalità dell'API android.hardware.camera2, le implementazioni dei dispositivi DEVONO segnalare il livello di supporto appropriato con la proprietà android.info.supportedHardwareLevel come descritto nell'SDK Android [Risorse, 93] e segnalare gli indicatori di funzionalità del framework appropriati [Risorse, 94].
Le implementazioni dei dispositivi DEVONO anche dichiarare le funzionalità delle singole videocamere di android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag di funzionalità appropriati [Risorse, 94]. Un dispositivo deve definire il flag di funzionalità se uno dei suoi dispositivi di videocamera collegati supporta la funzionalità.
Le implementazioni dei dispositivi DEVONO trasmettere l'intent Camera.ACTION_NEW_PICTURE ogni volta che la fotocamera scatta una nuova foto e la voce della foto è stata aggiunta al media store.
Le implementazioni del dispositivo DEVONO trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e l'elemento dell'immagine è stato aggiunto al media store.
7.5.5. Orientamento della fotocamera
Entrambe le fotocamere anteriori e posteriori, se presenti, DEVONO essere orientate in modo che la dimensione lunga della fotocamera sia allineata alla dimensione lunga dello schermo. In altre parole, quando il dispositivo è tenuto in orizzontale, le fotocamere DEVONO acquisire immagini in orizzontale. Questo vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica sia ai dispositivi in cui l'orientamento principale è orizzontale sia a quelli in cui è verticale.
7.6. Memoria e spazio di archiviazione
7.6.1. Memoria e spazio di archiviazione minimi
|
I dispositivi Android TV DEVONO avere almeno 5 GB di spazio di archiviazione non volatile disponibile per i dati privati delle applicazioni. |
La memoria disponibile per il kernel e lo spazio utente nelle implementazioni del dispositivo DEVE essere almeno uguale o superiore ai valori minimi specificati dalla tabella seguente. (consulta la sezione 7.1.1 per le definizioni delle dimensioni e della densità dello schermo).
|
Densità e dimensioni dello schermo |
Dispositivo a 32 bit |
Dispositivo a 64 bit |
|
Dispositivi Android Watch (a causa di schermi più piccoli) |
416MB |
Non applicabile |
|
xhdpi o inferiore su schermi piccoli/normali hdpi o inferiore su schermi di grandi dimensioni mdpi o inferiore su schermi extra large |
512MB |
832MB |
|
400 dpi o superiore su schermi piccoli/normali xhdpi o superiore su schermi di grandi dimensioni tvdpi o superiore su schermi extra large |
896MB |
1280MB |
|
560 dpi o superiore su schermi piccoli/normali 400 dpi o superiore su schermi di grandi dimensioni xhdpi o superiore su schermi extra large |
1344MB |
1824MB |
I valori di memoria minima DEVONO essere aggiuntivi allo spazio di memoria già dedicato a componenti hardware come radio, video e così via che non sono sotto il controllo del kernel.
I dispositivi Android TV DEVONO avere almeno 5 GB e altre implementazioni di dispositivi DEVONO avere almeno 1,5 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione. In altre parole, la partizione /data DEVE essere di almeno 5 GB per i dispositivi Android TV e di almeno 1,5 GB per le altre implementazioni dei dispositivi. Per le implementazioni dei dispositivi che eseguono Android è vivamente consigliato di avere almeno 3 GB di spazio di archiviazione non volatile per i dati privati delle applicazioni, in modo che possano eseguire l'upgrade alle release future della piattaforma.
Le API Android includono un gestore dei download che le applicazioni POSSONO utilizzare per scaricare file di dati [Risorse, 95]. L'implementazione del gestore dei download sul dispositivo DEVE essere in grado di scaricare singoli file di dimensioni pari o superiori a 100 MB nella posizione "cache" predefinita.
7.6.2. Spazio di archiviazione condiviso dell'applicazione
Le implementazioni dei dispositivi DEVONO offrire spazio di archiviazione condiviso per le applicazioni, spesso anche chiamato "spazio di archiviazione esterno condiviso".
Le implementazioni dei dispositivi DEVONO essere configurate con lo spazio di archiviazione condiviso montato per impostazione predefinita, "out of the box". Se lo spazio di archiviazione condiviso non è montato sul percorso Linux /sdcard, il dispositivo DEVE includere un link simbolico Linux da /sdcard al punto di montaggio effettivo.
Le implementazioni dei dispositivi POSSONO avere hardware per lo spazio di archiviazione rimovibile accessibile all'utente, come uno slot per schede Secure Digital (SD). Se questo slot viene utilizzato per soddisfare il requisito di archiviazione condivisa, l'implementazione del dispositivo:
- DEVE implementare un'interfaccia utente di tipo popup o messaggio temporaneo che avvisa l'utente quando non è presente alcuna scheda SD
- DEVE includere una scheda SD formattata FAT di almeno 1 GB OPPURE deve essere indicato sulla confezione e su altro materiale disponibile al momento dell'acquisto che la scheda SD deve essere acquistata separatamente
- DEVE montare la scheda SD per impostazione predefinita
In alternativa, le implementazioni del dispositivo POSSONO allocare lo spazio di archiviazione interno (non rimovibile) come spazio di archiviazione condiviso per le app come incluso nel progetto Android Open Source upstream; le implementazioni del dispositivo DOVREBBERO utilizzare questa configurazione e l'implementazione del software. Se l'implementazione di un dispositivo utilizza lo spazio di archiviazione interno (non rimovibile) per soddisfare il requisito di spazio di archiviazione condiviso, questo deve avere una dimensione minima di 1 GB e deve essere montato su /sdcard (o /sdcard deve essere un link simbolico alla posizione fisica se è montato altrove).
Le implementazioni dei dispositivi DEVONO applicare l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE su questo spazio di archiviazione condiviso come descritto nella documentazione. In caso contrario, lo spazio di archiviazione condiviso DEVE essere scrivibile da qualsiasi applicazione che ottenga questa permission.
Le implementazioni dei dispositivi che includono più percorsi di archiviazione condivisi (ad esempio un attacco per schede SD e uno spazio di archiviazione interno condiviso) DEVONO consentire di scrivere nello spazio di archiviazione esterno secondario solo alle applicazioni Android predefinite e privilegiate con l'autorizzazione WRITE_EXTERNAL_STORAGE, ad eccezione delle directory specifiche del pacchetto nello spazio di archiviazione esterno secondario, ma DEVONO esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione multimediale di Android e android.provider.MediaStore.
Indipendentemente dalla forma di archiviazione condivisa utilizzata, le implementazioni dei dispositivi DEVONO fornire un qualche meccanismo per accedere ai contenuti dell'archiviazione condivisa da un computer host, ad esempio archiviazione di massa USB (UMS) o Media Transfer Protocol (MTP). Le implementazioni dei dispositivi POSSONO utilizzare l'archivio di massa USB, ma DEVONO utilizzare Media Transfer Protocol. Se l'implementazione del dispositivo supporta il Media Transfer Protocol:
- DEVE essere compatibile con l'host MTP Android di riferimento, Android File Transfer [Risorse, 96]
- DOVREBBE segnalare una classe di dispositivo USB pari a 0x00
- DOVREBBE riportare il nome dell'interfaccia USB "MTP"
Se l'implementazione del dispositivo non dispone di porte USB, DEVE fornire a un computer host accesso ai contenuti dello spazio di archiviazione condiviso con altri mezzi, ad esempio un sistema file di rete.
7.7. USB
Le implementazioni dei dispositivi DEVONO supportare la modalità periferica USB e la modalità host USB.
Se l'implementazione di un dispositivo include una porta USB che supporta la modalità periferica:
- La porta DEVE essere connettibile a un host USB con una porta USB di tipo A o C standard.
- La porta DEVE utilizzare il fattore di forma USB micro-B, micro-AB o Type-C. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti in modo da poter eseguire l'upgrade alle release future della piattaforma.
- La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o attivare la rotazione dello schermo software per tutte le app (inclusa la schermata iniziale), in modo che il display venga visualizzato correttamente quando il dispositivo è orientato con la porta in basso. È FORTEMENTE CONSIGLIATO ai dispositivi Android esistenti e nuovi di soddisfare questi requisiti in modo da poter eseguire l'upgrade alle release future della piattaforma.
- DEVE implementare l'API e la specifica Android Open Accessory (AOA) come documentato nella documentazione dell'SDK Android e, se si tratta di un dispositivo Android per uso palmare, DEVE implementare l'API AOA. Implementazioni dei dispositivi che implementano la specifica AOA:
- DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.accessory [Risorse, 97]
- DEVE implementare la classe audio USB come descritto nella documentazione dell'SDK Android [Risorse, 98]
- DEVE implementare il supporto per assorbire una corrente di 1,5 A durante il chirp e il traffico HS come specificato nella specifica di ricarica della batteria USB, revisione 1.2 [Risorse, 99]. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
- Il valore di iSerialNumber nel descrittore del dispositivo standard USB DEVE essere uguale al valore di android.os.Build.SERIAL.
Se l'implementazione di un dispositivo include una porta USB che supporta la modalità host:
- DEVE utilizzare una porta USB Type-C, se l'implementazione del dispositivo supporta USB 3.1
- PUO' utilizzare un fattore di forma della porta non standard, ma in questo caso DEVE essere fornito con un cavo o più cavi che adattano la porta a una porta USB di tipo A o C standard
- PUO' utilizzare una porta USB micro-AB, ma in questo caso DEVE essere fornita con un cavo o cavi per adattare la porta a una porta USB standard di tipo A o C
- È MOLTO FORTEMENTE CONSIGLIATO implementare la classe audio USB come descritto nella documentazione dell'SDK Android [Risorse, 98]
- DEVE implementare l'API host USB Android come descritto nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host [Risorse, 100]
- DEVE supportare l'intervallo di corrente di uscita della porta di ricarica a valle di 1,5 A ~ 5 A come specificato nella specifica di ricarica della batteria USB, revisione 1.2 [Risorse, 99].
7.8. Audio
7.8.1. Microfono
|
I dispositivi Android portatili e gli smartwatch DEVONO includere un microfono. |
Le implementazioni dei dispositivi POSSONO omettere un microfono. Tuttavia, se l'implementazione di un dispositivo omette un microfono, NON DEVE segnalare la costante della funzionalità android.hardware.microphone e DEVE implementare l'API di registrazione audio almeno come no-op, come indicato nella sezione 7. Al contrario, le implementazioni dei dispositivi che dispongono di un microfono:
- DEVE segnalare la costante della funzionalità android.hardware.microphone
- DEVONO soddisfare i requisiti per le registrazioni audio descritti nella sezione 5.4
- DEVONO soddisfare i requisiti di latenza audio descritti nella sezione 5.6
7.8.2. Uscita audio
|
I dispositivi Android Watch POTREBBERO includere un'uscita audio. |
Implementazioni di dispositivi che includono uno speaker o una porta di uscita audio/multimedia per una periferica di uscita audio come cuffie o altoparlanti esterni:
- DEVE segnalare la costante della funzionalità android.hardware.audio.output
- DEVONO soddisfare i requisiti di riproduzione audio descritti nella sezione 5.5
- DEVONO soddisfare i requisiti di latenza audio descritti nella sezione 5.6
Al contrario, se l'implementazione di un dispositivo non include uno speaker o una porta di uscita audio, NON DEVE segnalare la funzionalità di uscita audio android.hardware.audio e DEVE implementare le API relative all'uscita audio almeno come no-op.
L'implementazione del dispositivo Android Watch PUÒ, ma NON DEVE, avere un'uscita audio, ma altri tipi di implementazioni di dispositivi Android DEVONO avere un'uscita audio e dichiarare android.hardware.audio.output.
7.8.2.1. Porte audio analogiche
Per essere compatibile con le cuffie e altri accessori audio che utilizzano il connettore audio da 3,5 mm nell'ecosistema Android [Risorse, 101], se l'implementazione di un dispositivo include una o più porte audio analogiche, almeno una delle porte audio DEVE essere un jack audio da 3,5 mm a 4 conduttori. Se l'implementazione di un dispositivo ha un jack audio da 3, 5 mm a 4 conduttori:
- DEVE supportare la riproduzione audio su cuffie stereo e cuffie stereo con microfono e DOVREBBE supportare la registrazione audio da cuffie stereo con microfono
- DEVE supportare i connettori audio TRRS con l'ordine dei pin CTIA e DEVE supportare i connettori audio con l'ordine dei pin OMTP
- DEVE supportare il rilevamento del microfono sull'accessorio audio collegato, se l'implementazione del dispositivo supporta un microfono, e trasmettere android.intent.action.HEADSET_PLUG con il valore extra microfono impostato su 1
- DOVREBBE supportare il rilevamento e la mappatura ai codici a chiave per i seguenti 3
intervalli di impedenza equivalente tra i conduttori del microfono e di messa a terra sul
connettore audio:
- Massimo 70 ohm: KEYCODE_HEADSETHOOK
- 210-290 Ohm: KEYCODE_VOLUME_UP
- 360–680 Ohm: KEYCODE_VOLUME_DOWN
- DOVREBBE supportare il rilevamento e la mappatura al codice a chiave per il seguente intervallo
di impedenza equivalente tra i conduttori del microfono e di messa a terra sul
collegato audio:
- 110-180 Ohm: KEYCODE_VOICE_ASSIST
- DEVE attivare ACTION_HEADSET_PLUG quando viene inserito il connettore, ma solo dopo che tutti i contatti sul connettore toccano i relativi segmenti sul jack
- DEVE essere in grado di alimentare almeno 150 mV +/- 10% della tensione di uscita su un'impedenza dello speaker di 32 Ohm
- DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V e 2,9 V
8. Compatibilità con il rendimento
Alcuni criteri di prestazioni minimi sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di riferimento che gli sviluppatori fanno quando sviluppano un'app. I dispositivi Android Watch DOVREBBERO e le implementazioni di altri tipi di dispositivi DEVONO soddisfare i seguenti criteri:
8.1. Coerenza dell'esperienza utente
Le implementazioni dei dispositivi DEVONO fornire un'interfaccia utente fluida garantendo una frequenza frame e tempi di risposta coerenti per applicazioni e giochi. Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti:
- Latenza dei fotogrammi costante: la latenza dei fotogrammi non deve verificarsi più di 5 volte al secondo e deve essere inferiore a 1 fotogramma al secondo.
- Latenza dell'interfaccia utente: le implementazioni dei dispositivi DEVONO garantire un'esperienza utente a bassa latenza scorrendo un elenco di 10.000 voci come definito dal Compatibility Test Suite (CTS) di Android in meno di 36 secondi.
- Passaggio da un'attività all'altraQuando sono state avviate più applicazioni, il riavvio di un'applicazione già in esecuzione DOVESSE richiedere meno di 1 secondo.
8.2. Prestazioni di accesso all'I/O di file
Le implementazioni dei dispositivi DEVONO garantire la coerenza delle prestazioni di accesso ai file per le operazioni di lettura e scrittura.
- Scrittura sequenziale: le implementazioni dei dispositivi DEVONO garantire prestazioni di scrittura sequenziale di 5 MB/s per un file di 256 MB che utilizza un buffer di scrittura di 10 MB.
- Scrittura casuale: le implementazioni dei dispositivi DEVONO garantire prestazioni di scrittura casuale di 0,5 MB/s per un file di 256 MB che utilizza un buffer di scrittura di 4 KB.
- Lettura sequenziale: le implementazioni dei dispositivi DEVONO garantire un rendimento di lettura sequenziale di 15 MB/s per un file di 256 MB che utilizza un buffer di scrittura di 10 MB.
- Le implementazioni dei dispositivi di lettura casuale DEVONO garantire un rendimento di lettura casuale di 3,5 MB/s per un file di 256 MB che utilizza un buffer di scrittura di 4 KB.
9. Compatibilità del modello di sicurezza
Le implementazioni dei dispositivi DEVONO implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API [Risorse, 102] nella documentazione per sviluppatori Android. Le implementazioni dei dispositivi DEVONO supportare l'installazione di applicazioni con firma autografa senza richiedere autorizzazioni/certificati aggiuntivi da parte di terze parti/autorità. Nello specifico, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle subsezioni che seguono.
9.1. Autorizzazioni
Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android [Risorse, 102]. Nello specifico, le implementazioni DEVONO applicare ogni autorizzazione definita come описано в документации SDK; nessuna autorizzazione può essere omessa, modificata o ignorata. Le implementazioni POSSONO aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe di ID autorizzazione non siano nello spazio dei nomi android.*.
9.2. Isolamento UID e dei processi
Le implementazioni dei dispositivi DEVONO supportare il modello di sandbox delle applicazioni Android, in cui ogni applicazione viene eseguita come UID Unix univoco e in un processo distinto. Le implementazioni dei dispositivi DEVONO supportare l'esecuzione di più applicazioni come lo stesso ID utente Linux, a condizione che le applicazioni siano firmate e costruite correttamente, come definito nella documentazione di riferimento Sicurezza e autorizzazioni [Risorse, 102].
9.3. Autorizzazioni del file system
Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni di accesso ai file di Android come definito nella documentazione di riferimento Sicurezza e autorizzazioni [Risorse, 102].
9.4. Ambienti di esecuzione alternativi
Le implementazioni dei dispositivi POSSONO includere ambienti di runtime che eseguono applicazioni utilizzando un altro software o un'altra tecnologia rispetto al formato eseguibile Dalvik o al codice nativo. Tuttavia, questi ambienti di esecuzione alternativi NON DEVONO compromettere il modello di sicurezza di Android o la sicurezza delle applicazioni Android installate, come descritto in questa sezione.
I runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella sezione 9.
Ai runtime alternativi NON DEVE essere concesso l'accesso alle risorse protette da autorizzazioni non richieste nel file AndroidManifest.xml del runtime tramite il
I runtime alternativi NON DEVONO consentire alle applicazioni di utilizzare funzionalità protette dalle autorizzazioni Android limitate alle applicazioni di sistema.
I runtime alternativi DEVONO rispettare il modello di sandbox di Android. Nello specifico, i runtime alternativi:
- DEVE installare le app tramite PackageManager in sandbox Android separate (ID utente Linux e così via)
- PUO' fornire una singola sandbox Android condivisa da tutte le applicazioni che utilizzano il runtime alternativo
- e le applicazioni installate che utilizzano un runtime alternativo NON DEVONO riutilizzare la sandbox di qualsiasi altra app installata sul dispositivo, tranne tramite i meccanismi standard di Android per ID utente e certificato di firma condivisi
- NON DEVE essere lanciato con, concedere o ricevere l'accesso alle sandbox corrispondente ad altre applicazioni Android
- NON DEVE essere avviata con, essere concessa o concedere ad altre applicazioni i privilegi del superutente (root) o di qualsiasi altro ID utente
I file APK dei runtime alternativi POSSONO essere inclusi nell'immagine di sistema di un'implementazione del dispositivo, ma DEVONO essere firmati con una chiave diversa da quella utilizzata per firmare altre applicazioni incluse nell'implementazione del dispositivo.
Quando installi applicazioni, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione. Se un'applicazione deve utilizzare una risorsa del dispositivo per la quale è disponibile un'autorizzazione Android corrispondente (ad esempio Fotocamera, GPS e così via), il runtime alternativo DEVE informare l'utente che l'applicazione potrà accedere a quella risorsa. Se l'ambiente di runtime non registra le funzionalità dell'applicazione in questo modo, l'ambiente di runtime DEVE elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che lo utilizza.
9.5. Supporto di più utenti
|
Questa funzionalità è facoltativa per tutti i tipi di dispositivi. |
Android include il supporto per più utenti e per l'isolamento completo degli utenti [Risorse, 103]. Le implementazioni dei dispositivi POSSONO consentire più utenti, ma se abilitati DEVONO soddisfare i seguenti requisiti relativi al supporto multiutente [Risorse, 104]:
- Le implementazioni dei dispositivi che non dichiarano il flag della funzionalità android.hardware.telephony DEVONO supportare i profili con limitazioni, una funzionalità che consente ai proprietari di dispositivi di gestire utenti aggiuntivi e le relative funzionalità sul dispositivo. Con i profili con limitazioni, i proprietari di dispositivi possono configurare rapidamente ambienti separati in cui lavorare per altri utenti, con la possibilità di gestire limitazioni più granulari nelle app disponibili in questi ambienti.
- Al contrario, le implementazioni dei dispositivi che dichiarano il flag della funzionalità android.hardware.telephony NON DEVONO supportare i profili con limitazioni, ma DEVONO essere in linea con l'implementazione dei controlli AOSP per attivare /disattivare l'accesso di altri utenti alle chiamate vocali e agli SMS.
- Le implementazioni dei dispositivi DEVONO, per ogni utente, implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API [Risorse, 102]
- Le implementazioni dei dispositivi POSSONO supportare la creazione di utenti e profili gestiti tramite le API android.app.admin.DevicePolicyManager e, se supportate, DEVONO dichiarare il flag della funzionalità della piattaforma android.software.managed_users.
- Le implementazioni dei dispositivi che dichiarano il flag di funzionalità android.software.managed_users DEVONO utilizzare il badge icona AOSP di upstream per rappresentare le applicazioni gestite e altri elementi dell'interfaccia utente del badge come Recenti e Notifiche.
- Ogni istanza utente su un dispositivo Android DEVE avere directory di archiviazione esterna separate e isolate. Le implementazioni dei dispositivi POSSONO archiviare i dati di più utenti sullo stesso volume o file system. Tuttavia, l'implementazione del dispositivo DEVE garantire che le applicazioni di proprietà di un determinato utente e in esecuzione per suo conto non possano elencare, leggere o scrivere dati di proprietà di altri utenti. Tieni presente che i supporti rimovibili, come gli slot per schede SD, possono consentire a un utente di accedere ai dati di un altro tramite un PC host. Per questo motivo, le implementazioni dei dispositivi che utilizzano supporti rimovibili per le API di archiviazione esterna principale DEVONO criptare i contenuti della scheda SD se è abilitato il multiutente utilizzando una chiave memorizzata solo su supporti non rimovibili accessibili solo al sistema. Poiché i contenuti multimediali non saranno più leggibili da un PC host, le implementazioni dei dispositivi dovranno passare a MTP o a un sistema simile per fornire ai PC host l'accesso ai dati dell'utente corrente. Di conseguenza, le implementazioni dei dispositivi POSSONO, ma NON DEVONO, attivare il multiutente se utilizzano supporti rimovibili [Risorse, 105] per lo spazio di archiviazione esterno principale.
9.6. Avviso SMS premium
Android include il supporto per avvisare gli utenti di qualsiasi messaggio SMS premium in uscita [Risorse, 106] . Gli SMS premium sono messaggi inviati a un servizio registrato con un operatore che potrebbe comportare un addebito per l'utente. Le implementazioni dei dispositivi che dichiarano il supporto di android.hardware.telephony DEVONO avvisare gli utenti prima di inviare un messaggio SMS ai numeri identificati dalle espressioni regolari definite nel file /data/misc/sms/codes.xml del dispositivo. Il progetto Android Open Source Project upstream fornisce un'implementazione che soddisfa questo requisito.
9.7. Funzionalità di sicurezza del kernel
La sandbox di Android include funzionalità che utilizzano il sistema di controllo dell'accesso obbligatorio (MAC) di Security-Enhanced Linux (SELinux) e altre funzionalità di sicurezza nel kernel di Linux. SELinux o qualsiasi altra funzionalità di sicurezza implementata al di sotto del framework Android:
- È NECESSARIO mantenere la compatibilità con le applicazioni esistenti
- NON DEVE avere un'interfaccia utente visibile quando viene rilevata e bloccata correttamente una violazione della sicurezza, ma PUÒ avere un'interfaccia utente visibile quando si verifica una violazione della sicurezza non bloccata che genera uno sfruttamento riuscito
- NON DEVE essere configurabile dall'utente o dallo sviluppatore
Se un'API per la configurazione dei criteri è esposta a un'applicazione che può colpire un'altra applicazione (ad esempio un'API di amministrazione del dispositivo), l'API NON DEVE consentire configurazioni che compromettono la compatibilità.
I dispositivi DEVONO implementare SELinux o, se si utilizza un kernel diverso da Linux, un sistema di controllo dell'accesso obbligatorio equivalente. I dispositivi devono inoltre soddisfare i seguenti requisiti, che sono soddisfatti dall'implementazione di riferimento nel progetto Android Open Source upstream.
Implementazioni dei dispositivi:
- DEVE impostare SELinux in modalità di applicazione globale,
- È NECESSARIO configurare tutti i domini in modalità di applicazione. Non sono consentiti i domini in modalità permissiva, inclusi i domini specifici per un dispositivo/fornitore.
- NON DEVE modificare, omettere o sostituire le regole neverallow presenti nella cartella external/sepolicy fornita nell'Android Open Source Project (AOSP) in upstream e il criterio DEVE essere compilato con tutte le regole neverallow presenti, sia per i domini AOSP SELinux che per i domini specifici del dispositivo/del fornitore.
Le implementazioni dei dispositivi DOVREBBERO mantenere il criterio SELinux predefinito fornito nella cartella external/sepolicy del progetto Android Open Source upstream e aggiungere solo ulteriori elementi a questo criterio per la propria configurazione specifica del dispositivo. Le implementazioni dei dispositivi DEVONO essere compatibili con l'Android Open Source Project a monte.
9.8. Privacy
Se il dispositivo implementa nel sistema una funzionalità che acquisisce i contenuti visualizzati sullo schermo e/o registra lo stream audio riprodotto sul dispositivo, deve avvisare continuamente l'utente ogni volta che questa funzionalità è attivata e acquisisce/registra attivamente.
9.9. Crittografia completa del disco
|
Facoltativo per le implementazioni dei dispositivi Android senza schermata di blocco. |
Se l'implementazione del dispositivo ha una schermata di blocco, il dispositivo DEVE supportare la crittografia completa del disco dei dati privati dell'applicazione (partizione /data) nonché la partizione della scheda SD se è una parte permanente e non rimovibile del dispositivo [Risorse, 107]. Per i dispositivi che supportano la crittografia completa del disco, la crittografia completa del disco DEVE essere attivata sempre dopo che l'utente ha completato l'esperienza out-of-box. Sebbene questo requisito sia indicato come DOVREBBE per questa versione della piattaforma Android, è MOLTO FORTEMENTE CONSIGLIATO in quanto prevediamo che diventerà OBBLIGATORIO nelle versioni future di Android. La crittografia DEVE utilizzare AES con una chiave di 128 bit (o superiore) e una modalità progettata per l'archiviazione (ad esempio AES-XTS, AES-CBC-ESSIV). La chiave di crittografia NON DEVE essere scritta nello spazio di archiviazione in nessun momento senza essere criptata. A parte quando è in uso attivo, la chiave di crittografia DEVE essere criptata con AES con il passcode della schermata di blocco allungato utilizzando un algoritmo di allungamento lento (ad es. PBKDF2 o scrypt). Se l'utente non ha specificato un passcode per la schermata di blocco o ha disattivato l'utilizzo del passcode per la crittografia, il sistema DEVE utilizzare un passcode predefinito per avvolgere la chiave di crittografia. Se il dispositivo fornisce un keystore basato su hardware, l'algoritmo di stretching della password DEVE essere legato in modo crittografico a quel keystore. La chiave di crittografia NON DEVE essere inviata dal dispositivo (anche se protetta con il passcode dell'utente e/o la chiave legata all'hardware). Il progetto Android Open Source upstream fornisce un'implementazione preferita di questa funzionalità in base alla funzionalità dm-crypt del kernel Linux.
9.10. Avvio verificato
Le implementazioni dei dispositivi DOVREBBERO supportare l'avvio verificato per l'integrità del dispositivo e, se la funzionalità è supportata, DEVONO dichiarare il flag della funzionalità della piattaforma android.software.verified_boot. Sebbene questo requisito sia indicato come DOVREBBE per questa versione della piattaforma Android, è MOLTO FORTEMENTE CONSIGLIATO in quanto prevediamo che diventerà DEVE nelle versioni future di Android. Il progetto Android Open Source upstream fornisce un'implementazione preferita di questa funzionalità in base alla funzionalità dm-verity del kernel Linux.
10. Test di compatibilità del software
Le implementazioni dei dispositivi DEVONO superare tutti i test descritti in questa sezione.
Tuttavia, tieni presente che nessun pacchetto di test software è completamente completo. Per questo motivo, gli implementatori di dispositivi sono vivamente incoraggiati ad apportare il minor numero possibile di modifiche all'implementazione di riferimento e preferita di Android disponibile nell'Android Open Source Project. In questo modo ridurrai al minimo il rischio di introdurre bug che creano incompatibilità che richiedono il rifacimento e potenziali aggiornamenti del dispositivo.
10.1. Compatibility Test Suite (CTS)
Le implementazioni dei dispositivi DEVONO superare la suite di test di compatibilità Android (CTS) [Risorse, 108] disponibile nel progetto open source Android, utilizzando il software di spedizione finale sul dispositivo. Inoltre, gli implementatori dei dispositivi DOVREBBERO utilizzare il più possibile l'implementazione di riferimento nella struttura Android Open Source e DEVONO garantire la compatibilità in caso di ambiguità nel CTS e per eventuali reimplementazioni di parti del codice sorgente di riferimento.
Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi software, anche il CTS potrebbe contenere bug. Il CTS avrà una versione indipendente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni del CTS per Android 5.0. Le implementazioni dei dispositivi DEVONO superare la versione CTS più recente disponibile al momento del completamento del software del dispositivo.
10.2. Verificatore CTS
Le implementazioni dei dispositivi DEVONO eseguire correttamente tutti i casi applicabili nel Verificatore CTS. CTS Verifier è incluso nella Compatibility Test Suite ed è pensato per essere eseguito da un operatore umano per testare le funzionalità che non possono essere testate da un sistema automatico, ad esempio il corretto funzionamento di una fotocamera e dei sensori.
CTS Verifier include test per molti tipi di hardware, incluso hardware facoltativo. Le implementazioni dei dispositivi DEVONO superare tutti i test per l'hardware di cui sono dotati. Ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente lo scenario di test dell'accelerometro in CTS Verifier. Gli scenari di test per le funzionalità indicate come facoltative da questo Compatibility Definition Document POSSONO essere saltati o omessi.
Ogni dispositivo e ogni build DEVONO eseguire correttamente CTS Verifier, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori dei dispositivi eseguano esplicitamente il verificatore CTS su build che differiscono solo in modo banale. Nello specifico, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato lo strumento di verifica CTS solo per l'insieme di lingue, branding e così via inclusi POSSONO omettere il test dello strumento di verifica CTS.
11. Software aggiornabile
Le implementazioni dei dispositivi DEVONO includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire upgrade "in tempo reale", ovvero potrebbe essere necessario riavviare il dispositivo.
È possibile utilizzare qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, qualsiasi dei seguenti approccisoddisfa questo requisito:
- Download OTA (over-the-air) con aggiornamento offline tramite riavvio
- Aggiornamenti "in tethering" tramite USB da un PC host
- Aggiornamenti "offline" tramite riavvio e aggiornamento da un file su archiviazione rimovibile
Tuttavia, se l'implementazione del dispositivo include il supporto di una connessione dati non conteggiata come il profilo 802.11 o Bluetooth PAN (Personal Area Network), il dispositivo DEVE supportare il download over-the-air con aggiornamento offline tramite riavvio.
Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. ovvero, il meccanismo di aggiornamento DEVE preservare i dati privati e condivisi dell'applicazione. Tieni presente che il software Android upstream include un meccanismo di aggiornamento che soddisfa questo requisito.
Per le implementazioni dei dispositivi che vengono lanciate con Android 5.0 e versioni successive, il meccanismo di aggiornamento DEVE supportare la verifica che l'immagine di sistema sia identica al risultato previsto dopo un aggiornamento OTA. L'implementazione OTA basata su blocchi nell'Android Open Source Project upstream, aggiunta da Android 5.0, soddisfa questo requisito.
Se viene rilevato un errore nell'implementazione di un dispositivo dopo il rilascio, ma entro la durata ragionevole del prodotto, che viene stabilita in collaborazione con il team di compatibilità di Android, che influisce sulla compatibilità delle applicazioni di terze parti, l'implementatore del dispositivo DEVE correggere l'errore tramite un aggiornamento software disponibile che può essere applicato in base al meccanismo appena descritto.
12. Log delle modifiche del documento
La tabella seguente contiene un riepilogo delle modifiche alla definizione di compatibilità in questa release.
|
Sezione o sezioni |
Riepilogo della modifica |
|
1. Introduzione |
Requisiti aggiornati per fare riferimento alla documentazione dell'SDK come fonte attendibile. |
|
2. Tipi di dispositivi |
Sono state incluse definizioni per i tipi di dispositivi per dispositivi portatili, TV e smartwatch. |
|
2.1 Configurazione del dispositivo |
È stato aggiunto un elenco non esaustivo per illustrare la deviazione della configurazione hardware tra i dispositivi. |
|
3.1. Compatibilità con le API gestite |
DEVONO anche fornire implementazioni complete delle API con l'indicatore "@SystemApi" nel codice sorgente Android upstream. |
|
3.2.2. Parametri di compilazione |
Sono stati inclusi nell'elenco i parametri SUPPORTED_ABIS, SUPPORTED_32_BIT_ABIS e SUPPORTED_64_BIT_ABIS, è stato aggiornato il campo PRODUCT in modo che richieda SKU di prodotto univoci e sono stati aggiornati i campi TAGS. |
|
3.2.3.1. Intent di applicazione principali |
È stato chiarito che il requisito di compatibilità riguarda principalmente il pattern di intenti |
|
3.2.3.5. Impostazioni app predefinite |
Sono stati inclusi nuovi requisiti per la schermata Home, NFC e le applicazioni SMS predefinite. |
|
3.3.1 Interfacce a livello di codice dell'applicazione |
Sono stati aggiunti requisiti per supportare l'ABI a 32 bit equivalente se è supportato un ABI a 64 bit. Parametri aggiornati in base a questa modifica. |
|
3.4.1. Compatibilità con WebView |
Compatibilità con Webview richiesta per tutti i dispositivi, ad eccezione di Android Watch. È stato rimosso il requisito della stringa Locale. |
|
3.4.2. Compatibilità del browser |
I dispositivi Android TV e smartwatch POSSONO omettere un'applicazione browser, ma tutti gli altri tipi di implementazioni dei dispositivi DEVONO includerne una. |
|
3.7. Compatibilità di runtime |
Requisiti minimi di memoria dell'applicazione aggiornati |
|
3.8.2. Widget |
Il supporto dei widget è facoltativo per tutti i tipi di dispositivi, ma consigliato per i dispositivi palmari. |
|
3.8.3. Notifiche |
Definizioni estese per i tipi di notifiche supportate. |
|
3.8.4. Cerca |
I dispositivi Android TV DEVONO includere la ricerca globale. Tutti gli altri tipi di dispositivi dovrebbero. |
|
3.8.6. Temi |
I dispositivi DEVONO supportare il tema Material. |
|
3.8.7. Sfondi animati |
I dispositivi che includono lo sfondo animato DEVONO segnalare il flag della funzionalità della piattaforma android.software.live_wallpaper. |
|
3.8.8. Cambio attività |
È consigliato supportare la nuova interfaccia utente della sezione Recenti. DEVE mostrare almeno il titolo di quattro attività alla volta. |
|
3.8.10. Telecomando per contenuti multimediali nella schermata di blocco |
L'API client di controllo remoto è stata ritirata a favore del modello di notifica multimediale |
|
3.8.11. Sogni |
Facoltativo per i dispositivi Android Watch. Obbligatorio per tutti gli altri tipi di dispositivi. |
|
3.8.13 Unicode e caratteri |
DEVE supportare Roboto 2 oltre ai requisiti esistenti. |
|
3.12. TV Input Framework |
Le implementazioni dei dispositivi Android TV DEVONO supportare il Television Input Framework. |
|
5.1. Codec multimediali |
Sono state aggiunte tre sezioni per i codec audio, immagine e video. |
|
5.4 Registrazione audio |
Suddiviso in sottosezioni |
|
5.4.1. Acquisizione audio non compresso |
Caratteristiche definite per l'acquisizione di audio non elaborato sui dispositivi che dichiarano android.hardware.microphone |
|
5.5. Riproduzione audio |
È stata aggiunta la sezione 5.5. Riproduzione audio con due sottosezioni: 5.5.1 Effetti audio e 5.5.2. Volume uscita audio |
|
5.6 Latenza audio |
Aggiunti definizioni e requisiti per jitter in uscita a freddo, jitter in entrata a freddo e latenza di andata e ritorno continua. |
|
5.8 Contenuti multimediali sicuri |
Sono stati inclusi i requisiti per i contenuti multimediali sicuri a partire dalla versione 7.1.8. Display esterni e requisiti aggiuntivi per Android TV. |
|
6.1. Strumenti per sviluppatori |
Risorse aggiornate. |
|
6.2.1. Sperimentale |
Sezione rimossa |
|
7. Compatibilità hardware |
Aggiornamento per riflettere il fatto che le implementazioni dei dispositivi DEVONO registrare in modo coerente una configurazione hardware accurata per la stessa impronta della build. |
|
7.1.1.1. Dimensioni schermo |
Aggiornamento per riflettere le dimensioni dello schermo dei dispositivi Android Watch e il fatto che il valore non può essere modificato |
|
7.1.1.2. Proporzioni dello schermo |
Aggiornamento per riflettere le proporzioni dello schermo dei dispositivi Android Watch (1:1). |
|
7.1.3. Orientamento schermo |
Aggiornamento per riflettere il fatto che i dispositivi con uno schermo orizzontale con orientamento fisso DEVONO segnalare solo questo orientamento. |
|
7.1.4. Accelerazione grafica 2D e 3D |
È stato aggiunto che i dispositivi Android POTREBBERO supportare il pacchetto di estensioni per Android. |
|
(precedente) 7.1.6. Tipi di schermo |
Sezione rimossa |
|
7.1.6. Tecnologia dello schermo |
Le proporzioni pixel (PAR) aggiornate devono essere comprese tra 0,9 e 1,15. (~15% di tolleranza) |
|
7.1.7. Display esterni |
Parte della sezione spostata nella sezione 5.8. Contenuti multimediali sicuri. |
|
7.2.2. Navigazione non tocco |
I dispositivi Android TV DEVONO supportare il D-pad. |
|
7.2.3. Tasti di navigazione |
Lingua inclusa per il supporto su diversi tipi di dispositivi. |
|
7.2.4. Input touchscreen |
I dispositivi Android Watch DEVONO supportare l'input touchscreen. |
|
7.2.6. Supporto del controller di gioco |
È stata aggiunta una sezione con i requisiti di Android TV. |
|
7.2.7. Telecomando |
È stata aggiunta una sezione con i requisiti di Android TV. |
|
7.3. Sensori |
I sensori sintetici sono stati ridefiniti come sensori compositi e i sensori di streaming come sensori continui. I sensori devono segnalare la data e l'ora dell'evento in nanosecondi. |
|
7.3.1. Accelerometro |
Sono stati chiariti i tipi di sensori richiesti e riviste le soglie dei requisiti. |
|
7.3.2. Magnetometro |
Sono stati chiariti i tipi di sensori richiesti e riviste le soglie dei requisiti. |
|
7.3.4. Giroscopio |
Sono stati chiariti i tipi di sensori richiesti e riviste le soglie dei requisiti. |
|
7.3.5. Barometro |
Modifica da POTREBBE a DOVREBBE implementare il barometro. DEVE implementare e segnalare il sensore TYPE_PRESSURE. |
|
7.3.6. Termometro |
I dispositivi POSSONO includere un termometro ambiente. PUO', ma NON DEVE, includere il termometro della CPU. |
|
7.3.8. Sensore di prossimità |
I dispositivi che possono effettuare una chiamata vocale e indicare un valore diverso da PHONE_TYPE_NONE in getPhoneType DEVONO includere un sensore di prossimità. |
|
7.4.2. IEEE 802.11 (Wi-Fi) |
I dispositivi Android TV DEVONO includere il supporto Wi-Fi. I dispositivi che supportano il wifi devono segnalare android.hardware.wifi. |
|
7.4.2.1. Wi-Fi Direct |
DEVE segnalare la funzionalità hardware android.hardware.wifi.direct. |
|
7.4.2.2. Configurazione del link diretto con tunnel Wi-Fi |
I dispositivi Android TV DEVONO includere il supporto per TDLS Wi-Fi. |
|
7.5. Fotocamere |
Se l'implementazione di un dispositivo include almeno una fotocamera, DOVREBBE essere possibile per un'applicazione allocare contemporaneamente 3 bitmap uguali alle dimensioni delle immagini prodotte dal sensore della fotocamera con la risoluzione più alta sul dispositivo. |
|
7.5.3. Videocamere esterne |
Sono stati aggiunti requisiti che prevedono che le implementazioni dei dispositivi con modalità host USB POSSANO includere il supporto di una videocamera esterna. |
|
7.5.5. Funzionalità del sistema di fotocamere |
È stato aggiunto un elenco delle funzionalità della videocamera e dei casi in cui devono essere definite. |
|
7.6.1. Memoria e spazio di archiviazione minimi |
Requisiti aggiornati per i dispositivi a 32 e 64 bit. Requisito di memoria SVELTE rimosso. I dispositivi DEVONO avere almeno 1,5 GB di spazio di archiviazione non volatile |
|
7.6.2. Spazio di archiviazione condiviso dell'applicazione |
Requisiti aggiornati per lo spazio di archiviazione rimovibile accessibile all'utente |
| 7.6.2. Spazio di archiviazione condiviso dell'applicazione | Requisiti aggiornati che consentono alle app di sistema preinstallate di scrivere in unità di archiviazione esterne secondarie. |
|
7.7. USB |
Sono stati rimossi i requisiti relativi alla presenza delle porte di ricarica sullo stesso bordo della porta micro-USB. Requisiti aggiornati per la modalità Host e Periferica. |
|
7.7. USB |
Correzione di errori ortografici nella sezione USB. |
|
7.8.1. Audio |
Sezione del microfono spostata qui. Sono stati aggiunti requisiti per le porte Uscita audio e Audio analogico. |
|
8. Compatibilità con il rendimento |
Sono stati aggiunti requisiti per la coerenza dell'interfaccia utente. |
|
9.5. Supporto di più utenti |
La funzionalità di supporto multiutente è facoltativa per tutti i tipi di dispositivi. Requisiti dettagliati per tipo di dispositivo nella sezione. |
|
9.5. Supporto di più utenti |
La crittografia della scheda SD è obbligatoria per lo spazio di archiviazione esterno principale. |
|
9.7. Funzionalità di sicurezza del kernel |
POTREBBE avere un'interfaccia utente visibile quando si verifica una violazione di sicurezza non bloccata con conseguente esecuzione di uno exploit. Nessun dominio in modalità permissiva consentito. |
|
9.9. Crittografia completa del disco |
I dispositivi con una schermata di blocco DOVREBBERO supportare la crittografia completa del disco. Per i nuovi dispositivi, la crittografia completa del disco deve essere attivata out-of-the-box. |
|
9.10 Avvio verificato |
È stata aggiunta una sezione che consiglia di supportare l'avvio verificato per l'integrità del dispositivo nelle implementazioni dei dispositivi. |
|
10.3. Applicazioni di riferimento |
Sezione rimossa dal CDD. |
|
11. Software aggiornabile |
Se un dispositivo supporta il profilo 802.11 o Bluetooth PAN (Personal Area Network), deve supportare il download over-the-air con aggiornamento offline tramite riavvio. |
|
14. Risorse |
Risorse spostate dalla sezione 2 alla sezione 14 |
13. Contattaci
Puoi partecipare al forum Android Compatibility [Risorse, 109] e chiedere chiarimenti o segnalare eventuali problemi che ritieni non coperti dal documento.
14. Risorse
1. Livelli di requisiti RFC2119 IETF: http://www.ietf.org/rfc/rfc2119.txt
2. Android Open Source Project: http://source.android.com/
3. Funzionalità di Android TV: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK
4. Funzionalità di Android Watch: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH
5. Definizioni e documentazione dell'API: http://developer.android.com/reference/packages.html
6. Documentazione di riferimento per le autorizzazioni Android: http://developer.android.com/reference/android/Manifest.permission.html
7. Riferimento android.os.Build: http://developer.android.com/reference/android/os/Build.html
8. Stringhe di versione consentite per Android 5.0: http://source.android.com//docs/compatibility/5.0/versions
9. Fornitore di servizi di telefonia: http://developer.android.com/reference/android/provider/Telephony.html
10. Emulazione di carte basata su host: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
11. Android Extension Pack: http://developer.android.com/guide/topics/graphics/opengl.html#aep
12. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
13. Compatibilità di WebView: http://www.chromium.org/
14. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
15. Funzionalità offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
16. Tag video HTML5: http://dev.w3.org/html5/spec/Overview.html#video
17. API Geolocation HTML5/W3C: http://www.w3.org/TR/geolocation-API/
18. API webstorage HTML5/W3C: http://www.w3.org/TR/webstorage/
19. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
20. Formato eseguibile Dalvik e specifica del bytecode: disponibile nel codice sorgente di Android, in dalvik/docs
21. AppWidget: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
22. Notifiche: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
23. Risorse per le applicazioni: https://developer.android.com/guide/topics/resources/available-resources.html
24. Style guide per le icone della barra di stato: http://developer.android.com/design/style/iconography.html
25. Risorse per le notifiche: https://developer.android.com/design/patterns/notifications.html
26. Gestione ricerche: http://developer.android.com/reference/android/app/SearchManager.html
27. Messaggi popup: http://developer.android.com/reference/android/widget/Toast.html
28. Temi: http://developer.android.com/guide/topics/ui/themes.html
29. Classe R.style: http://developer.android.com/reference/android/R.style.html
30. Material Design: http://developer.android.com/reference/android/R.style.html#Theme_Material
31. Sfondi animati: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html
32. Risorse per la schermata Panoramica: http://developer.android.com/guide/components/recents.html
33. Blocco su schermo: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning
34. Metodi di inserimento: http://developer.android.com/guide/topics/text/creating-input-method.html
35. Notifica multimediale: https://developer.android.com/reference/android/app/Notification.MediaStyle.html
36. Sogni: http://developer.android.com/reference/android/service/dreams/DreamService.html
37. Impostazioni.Sicurezza LOCATION_MODE:
http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE
38. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/
39. Amministrazione dispositivo Android: http://developer.android.com/guide/topics/admin/device-admin.html
40. Documentazione di riferimento di DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
41. App Proprietario dispositivo Android:
42. API Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html
43. API Android Accessibility: http://developer.android.com/reference/android/view/accessibility/package-summary.html
44. Progetto Eyes Free: http://code.google.com/p/eyes-free
45. API Text-to-Speech: http://developer.android.com/reference/android/speech/tts/package-summary.html
46. Television Input Framework: /devices/tv/index.html
47. Documentazione di riferimento degli strumenti (per adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html
48. Descrizione del file APK Android: http://developer.android.com/guide/components/fundamentals.html
49. File manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html
50. Formati multimediali Android: http://developer.android.com/guide/appendix/media-formats.html
51. Requisiti di codifica hardware RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/
52. API AudioEffect: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html
53. Classe Android android.content.pm.PackageManager ed elenco delle funzionalità hardware:
http://developer.android.com/reference/android/content/pm/PackageManager.html
54. Protocollo HTTP Live Streaming in versione preliminare: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
55. ADB: http://developer.android.com/tools/help/adb.html
56. Dumpsys: https://developer.android.com/studio/command-line/dumpsys.html
57. DDMS: http://developer.android.com/tools/debugging/ddms.html
58. Strumento di test Monkey: http://developer.android.com/tools/help/monkey.html
59. Strumento Systrace: http://developer.android.com/tools/help/systrace.html
60. Impostazioni relative allo sviluppo di app per Android:
61. Supporto di più schermi: http://developer.android.com/guide/practices/screens_support.html
62. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
63. RenderScript: http://developer.android.com/guide/topics/renderscript/
64. Pacchetto di estensioni Android per OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html
65. Accelerazione hardware: http://developer.android.com/guide/topics/graphics/hardware-accel.html
66. Estensione EGL-EGL_ANDROID_RECORDABLE:
http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt
67. Display Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
68. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
69. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
70. Configurazione dell'input tocco: http://source.android.com/docs/core/interaction/input/touch-devices
71. API Motion Event: http://developer.android.com/reference/android/view/MotionEvent.html
72. API Key Event: http://developer.android.com/reference/android/view/KeyEvent.html
73. Sensori Android Open Source: http://source.android.com/docs/core/interaction/sensors
74. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
75. Timestamp sensor event: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp
76. Sensori compositi Android Open Source: http://source.android.com/devices/sensors/composite_sensors.html
77. Modalità di attivazione continua: http://source.android.com/devices/sensors/base_triggers.html#continuous
78. Sensore di accelerazione: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER
79. API multicast Wi-Fi: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
80. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
81. API WifiManager: http://developer.android.com/reference/android/net/wifi/WifiManager.html
82. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html
83. API ScanFilter Bluetooth: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html
84. Protocollo NDEF Push: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
85. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html
86. Impostazioni di condivisione NFC di Android:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
87. Trasferimento NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover
88. Accoppiamento sicuro semplice Bluetooth tramite NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf
89. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html
90. API di orientamento della fotocamera: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
91. Fotocamera: http://developer.android.com/reference/android/hardware/Camera.html
92. Fotocamera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
93. Livello hardware della fotocamera: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL
94. Supporto della versione della fotocamera: http://source.android.com/docs/core/camera/versioning
95. DownloadManager di Android: http://developer.android.com/reference/android/app/DownloadManager.html
96. Android File Transfer: http://www.android.com/filetransfer
97. Android Open Accessories: http://developer.android.com/guide/topics/usb/accessory.html
98. Audio USB Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
99. Specifiche per la ricarica della batteria USB, revisione 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip
100. API host USB: http://developer.android.com/guide/topics/usb/host.html
101. Cuffie audio con cavo: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec
102. Documentazione di riferimento per la sicurezza e le autorizzazioni di Android: http://developer.android.com/guide/topics/security/permissions.html
103. Riferimento a UserManager: http://developer.android.com/reference/android/os/UserManager.html
104. Riferimento all'unità di archiviazione esterna: http://source.android.com/docs/core/storage
105. API di archiviazione esterna: http://developer.android.com/reference/android/os/Environment.html
106. Short code SMS: http://it.wikipedia.org/wiki/Short_code
107. Crittografia open source di Android: http://source.android.com/devices/tech/encryption/index.html
108. Panoramica del Programma di compatibilità Android: http://source.android.com/docs/compatibility
109. Forum sulla compatibilità Android: https://groups.google.com/forum/#!forum/android-compatibility
110. Progetto WebM: http://www.webmproject.org/
Molte di queste risorse sono ricavate direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni riportate nella documentazione dell'SDK. In tutti i casi in cui questa definizione di compatibilità o la Compatibility Test Suite non è in accordo con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Eventuali dettagli tecnici forniti nei riferimenti inclusi sopra sono considerati parte di questa Definizione di compatibilità.