Definizione di compatibilità di Android 8.1

1. Introduzione

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

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

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

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

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

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

Molte delle risorse a cui si fa riferimento in questo documento derivano direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni riportate nella documentazione dell'SDK. In tutti i casi in cui questa definizione di compatibilità o la suite di test di compatibilità non è in linea con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Eventuali dettagli tecnici forniti nelle risorse collegate in questo documento sono considerati parte di questa definizione di compatibilità.

1.1 Struttura del documento

1.1.1. Requisiti per tipo di dispositivo

La sezione 2 contiene tutti i requisiti OBBLIGATORI e FORTEMENTE CONSIGLIATI che si applicano a un tipo di dispositivo specifico. Ogni sottosezione della Sezione 2 è dedicata a un tipo di dispositivo specifico.

Tutti gli altri requisiti, che si applicano universalmente a qualsiasi implementazione di dispositivi Android, sono elencati nelle sezioni successive alla Sezione 2. In questo documento, a questi requisiti viene fatto riferimento come "Requisiti principali".

1.1.2. ID requisito

L'ID requisito viene assegnato per i requisiti MUST.

  • L'ID viene assegnato solo per i requisiti MUST.
  • I requisiti FORTEMENTE CONSIGLIATI sono contrassegnati come [SR], ma non è stato assegnato un ID.
  • L'ID è costituito da : ID tipo di dispositivo - ID condizione - ID requisito (ad es. C-0-1).

Ogni ID è definito come segue:

  • ID tipo di dispositivo (scopri di più nella sezione 2. Tipi di dispositivi
    • C: Core (requisiti applicati a qualsiasi implementazione del dispositivo Android)
    • H: dispositivo palmare Android
    • T: dispositivo Android TV
    • A: Implementazione di Android Automotive
  • ID condizione
    • Quando il requisito è incondizionato, questo ID viene impostato su 0.
    • Quando il requisito è condizionale, viene assegnato 1 per la prima condizione e il numero aumenta di 1 all'interno della stessa sezione e dello stesso tipo di dispositivo.
  • ID requisito
    • Questo ID inizia da 1 e aumenta di 1 all'interno della stessa sezione e della stessa condizione.

2. Tipi di dispositivi

Sebbene il progetto open source Android fornisca uno stack software che può essere utilizzato per una serie di tipi di dispositivi e fattori di forma, esistono alcuni tipi di dispositivi che hanno un ecosistema di distribuzione delle applicazioni relativamente più consolidato.

Questa sezione descrive questi tipi di dispositivi, nonché requisiti e consigli aggiuntivi applicabili a ciascun tipo di dispositivo.

Tutte le implementazioni di dispositivi Android che non rientrano in nessuno dei tipi di dispositivi descritti DEVONO comunque soddisfare tutti i requisiti delle altre sezioni di questa definizione di compatibilità.

2.1 Configurazioni del dispositivo

Per le principali differenze nella configurazione hardware in base al tipo di dispositivo, consulta i requisiti specifici del dispositivo riportati di seguito in questa sezione.

2.2. Requisiti del dispositivo portatile

Un dispositivo Android portatile si riferisce a un'implementazione di un dispositivo Android che in genere viene utilizzato tenendolo in mano, ad esempio un mp3 player, uno smartphone o un tablet.

Le implementazioni dei dispositivi Android sono classificate come dispositivi mobili se soddisfano tutti i seguenti criteri:

  • Avere una fonte di alimentazione che offra mobilità, ad esempio una batteria.
  • Avere una dimensione dello schermo in diagonale fisica compresa tra 6,35 e 20,32 cm.

I requisiti aggiuntivi riportati nel resto di questa sezione sono specifici per le implementazioni dei dispositivi Android portatili.

Nota:i requisiti che non si applicano ai tablet Android sono contrassegnati da un asterisco (*).

2.2.1. Hardware

Dimensioni schermo (Sezione 7.1.1.1)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE avere uno schermo con una diagonale fisica di almeno 6,35 cm.*

Densità dello schermo (sezione 7.1.1.3)

Implementazioni dei dispositivi portatili:

  • [H-SR] È MOLTO CONSIGLIATO fornire agli utenti un'affordance per modificare le dimensioni del display.

Modalità di compatibilità delle applicazioni legacy (sezione 7.1.5)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE includere il supporto per la modalità di compatibilità delle applicazioni precedenti, come implementata dal codice open source di Android upstream. In altre parole, le implementazioni dei dispositivi NON DEVONO modificare gli attivatori o le soglie a cui viene attivata la modalità di compatibilità e NON DEVONO modificare il comportamento della modalità di compatibilità stessa.

Tastiera (sezione 7.2.1)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE includere il supporto per le applicazioni Input Method Editor (IME) di terze parti.

Tasti di navigazione (sezione 7.2.3)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE fornire le funzioni Home, Recenti e Indietro.

  • [H-0-2] DEVE inviare all'applicazione in primo piano sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK).

Input touchscreen (sezione 7.2.4)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE supportare l'input touchscreen.

Accelerometro (sezione 7.3.1)

Implementazioni dei dispositivi portatili:

  • [H-SR] È FORTEMENTE CONSIGLIATO includere un accelerometro a 3 assi.

Se le implementazioni dei dispositivi palmari includono un accelerometro a 3 assi, devono:

  • [H-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 100 Hz.

Giroscopio (sezione 7.3.4)

Se le implementazioni dei dispositivi palmari includono un giroscopio, devono:

  • [H-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 100 Hz.

Sensore di prossimità (sezione 7.3.8)

Implementazioni di dispositivi portatili che possono effettuare una chiamata vocale e indicare un valore diverso da PHONE_TYPE_NONE in getPhoneType:

  • DOVREBBE includere un sensore di prossimità.

Sensore di posizione (sezione 7.3.12)

Implementazioni dei dispositivi portatili:

  • È CONSIGLIATO supportare il sensore di posizione con 6 gradi di libertà.

Bluetooth (sezione 7.4.3)

Implementazioni dei dispositivi portatili:

  • DOVREBBE includere il supporto per Bluetooth e Bluetooth LE.

Risparmio dati (sezione 7.4.7)

Se le implementazioni dei dispositivi palmari includono una connessione con misuratore, devono:

  • [H-1-1] DEVE fornire la modalità Risparmio dati.

Memoria e spazio di archiviazione minimi (sezione 7.6.1)

Se le implementazioni dei dispositivi palmari dichiarano il supporto di un'ABI solo a 32 bit:

  • [H-1-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 416 MB se il display predefinito utilizza risoluzioni framebuffer fino a qHD (ad es. FWVGA).

  • [H-2-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 592 MB se il display predefinito utilizza risoluzioni framebuffer fino a HD+ (ad es. HD, WSVGA).

  • [H-3-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 896 MB se il display predefinito utilizza risoluzioni framebuffer fino a FHD (ad es. WSXGA+).

  • [H-4-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1344 MB se il display predefinito utilizza risoluzioni framebuffer fino a QHD (ad es. QWXGA).

Se le implementazioni dei dispositivi mobili dichiarano il supporto di ABI a 32 e 64 bit:

  • [H-5-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 816 MB se il display predefinito utilizza risoluzioni framebuffer fino a qHD (ad es. FWVGA).

  • [H-6-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 944 MB se il display predefinito utilizza risoluzioni framebuffer fino a HD+ (ad es. HD, WSVGA).

  • [H-7-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1280 MB se il display predefinito utilizza risoluzioni framebuffer fino a FHD (ad es. WSXGA+).

  • [H-8-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1824 MB se il display predefinito utilizza risoluzioni framebuffer fino a QHD (ad es. QWXGA).

Tieni presente che la "memoria disponibile per il kernel e lo spazio utente" riportata sopra si riferisce allo spazio di memoria fornito in aggiunta a qualsiasi memoria già dedicata a componenti hardware come radio, video e così via che non sono sotto il controllo del kernel nelle implementazioni del dispositivo.

Se le implementazioni dei dispositivi portatili includono meno o uguale a 1 GB di memoria disponibile per il kernel e lo spazio utente, devono:

  • [H-9-1] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.ram.low.
  • [H-9-2] DEVE avere almeno 1,1 GB di spazio di archiviazione non volatile per i dati privati dell'applicazione (ovvero la partizione "/data").

Se le implementazioni dei dispositivi palmari includono più di 1 GB di memoria disponibile per il kernel e lo spazio utente:

  • [H-10-1] DEVE avere almeno 4 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione (ovvero la partizione "/data").
  • DEVE dichiarare il flag funzionalità android.hardware.ram.normal.

Spazio di archiviazione condiviso per le applicazioni (sezione 7.6.2)

Implementazioni dei dispositivi portatili:

  • [H-0-1] NON DEVE fornire uno spazio di archiviazione condiviso dell'applicazione inferiore a 1 GB.

Modalità periferica USB (sezione 7.7.1)

Implementazioni dei dispositivi portatili:

  • DEVE includere una porta USB che supporti la modalità periferica.

Se le implementazioni dei dispositivi palmari includono una porta USB che supporta la modalità periferica, devono:

  • [H-1-1] DEVE implementare l'API Android Open Accessory (AOA).*

Microfono (sezione 7.8.1)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE includere un microfono.

Uscita audio (sezione 7.8.2)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE avere un'uscita audio e dichiarare android.hardware.audio.output.

Modalità Realtà virtuale (sezione 7.9.1)

Se le implementazioni dei dispositivi mobili includono il supporto della modalità VR:

  • [H-1-1] È OBBLIGATORIO dichiarare la funzionalità android.software.vr.mode.*

Se le implementazioni del dispositivo dichiarano la funzionalità android.software.vr.mode:

  • [H-2-1] DEVE includere un'applicazione che implementa android.service.vr.VrListenerService che può essere attivata dalle applicazioni VR tramite android.app.Activity#setVrModeEnabled.*

Realtà virtuale ad alte prestazioni (sezione 7.9.2)

Se le implementazioni dei dispositivi portatili sono in grado di soddisfare tutti i requisiti per dichiarare il flag della funzionalità android.hardware.vr.high_performance:

  • [H-1-1] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.vr.high_performance.*

2.2.2. Multimediale

Codifica audio (sezione 5.1.1)

Le implementazioni dei dispositivi portatili DEVONO supportare la seguente codifica audio:

  • [H-0-1] AMR-NB
  • [H-0-2] AMR-WB
  • [H-0-3] Profilo AAC MPEG-4 (AAC LC)
  • [H-0-4] Profilo MPEG-4 HE AAC (AAC+)
  • [H-0-5] AAC ELD (AAC a basso ritardo migliorato)

Decodifica audio (sezione 5.1.2)

Le implementazioni dei dispositivi portatili DEVONO supportare la seguente decodifica audio:

  • [H-0-1] AMR-NB
  • [H-0-2] AMR-WB

Codifica video (sezione 5.2)

Le implementazioni dei dispositivi portatili DEVONO supportare la seguente codifica video e renderla disponibile per le applicazioni di terze parti:

  • [H-0-1] H.264 AVC
  • [H-0-2] VP8

Decodifica video (sezione 5.3)

Le implementazioni dei dispositivi portatili DEVONO supportare la seguente decodifica video:

  • [H-0-1] H.264 AVC.
  • [H-0-2] H.265 HEVC.
  • [H-0-3] MPEG-4 SP.
  • [H-0-4] VP8.
  • [H-0-5] VP9.

2.2.3. Software

Compatibilità con WebView (sezione 3.4.1)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.

Compatibilità del browser (sezione 3.4.2)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE includere un'applicazione di browser autonoma per la navigazione web degli utenti generici.

Avvio app (sezione 3.8.1)

Implementazioni dei dispositivi portatili:

  • [H-SR] È FORTEMENTE CONSIGLIATO implementare un Avvio app predefinito che supporti il bloccaggio in-app di scorciatoie e widget.

  • [H-SR] È FORTEMENTE CONSIGLIATO implementare un Avvio app predefinito che offra un accesso rapido alle scorciatoie aggiuntive fornite dalle app di terze parti tramite l'API ShortcutManager.

  • [H-SR] È FORTEMENTE CONSIGLIATO includere un'app Avvio app predefinita che mostri i badge per le icone delle app.

Widget (sezione 3.8.2)

Implementazioni dei dispositivi portatili:

  • [H-SR] Sono FORTEMENTE CONSIGLIATI per supportare i widget delle app di terze parti.

Notifiche (sezione 3.8.3)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE consentire alle app di terze parti di notificare agli utenti eventi importanti tramite le classi API Notification e NotificationManager.
  • [H-0-2] DEVE supportare le notifiche avanzate.
  • [H-0-3] DEVE supportare le notifiche in evidenza.
  • [H-0-4] DEVE includere una tenda delle notifiche, che offra all'utente la possibilità di controllare direttamente (ad es. rispondere, posticipare, ignorare, bloccare) le notifiche tramite elementi come i pulsanti di azione o il pannello di controllo, come implementato in AOSP.

Ricerca (sezione 3.8.4)

Implementazioni dei dispositivi portatili:

  • [H-SR] È FORTEMENTE CONSIGLIATO implementare un assistente sul dispositivo per gestire l'azione di assistenza.

Controllo multimediale nella schermata di blocco (sezione 3.8.10)

Se le implementazioni dei dispositivi Android supportano una schermata di blocco,devono:

  • [H-1-1] DEVE mostrare le notifiche della schermata di blocco, incluso il modello di notifica multimediale.

Amministrazione dei dispositivi (Sezione 3.9)

Se le implementazioni dei dispositivi mobili supportano una schermata di blocco sicura:

Accessibilità (Sezione 3.10)

Implementazioni dei dispositivi portatili:

  • [H-SR] DEVE supportare i servizi di accessibilità di terze parti.

  • [H-SR] È FORTEMENTE CONSIGLIATO precaricare sul dispositivo servizi di accessibilità paragonabili o superiori alle funzionalità di Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale precaricato) come indicato nel progetto open source talkback.

Text-to-Speech (sezione 3.11)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE supportare l'installazione di motori TTS di terze parti.

  • [H-SR] È FORTEMENTE CONSIGLIATO includere un motore TTS che supporti le lingue disponibili sul dispositivo.

Impostazioni rapide (sezione 3.13)

Implementazioni dei dispositivi portatili:

  • [H-SR] È MOLTO CONSIGLIATO includere un componente dell'interfaccia utente delle Impostazioni rapide.

Accoppiamento del dispositivo complementare (sezione 3.15)

Se le implementazioni dei dispositivi portatili Android dichiarano il supporto di FEATURE_BLUETOOTH o FEATURE_WIFI:

  • [H-1-1] DEVE supportare la funzionalità di accoppiamento del dispositivo complementare.

2.2.4. Prestazioni e potenza

Coerenza dell'esperienza utente (sezione 8.1)

Per le implementazioni dei dispositivi palmari:

  • [H-0-1] Latenza dei frame coerente. La latenza dei fotogrammi incoerente o un ritardo nel rendering dei fotogrammi NON DEVONO verificarsi più di 5 volte al secondo e DEVONO essere inferiori a 1 fotogramma al secondo.
  • [H-0-2] 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.
  • [H-0-3] Passaggio da un'attività all'altra. Quando sono state avviate più applicazioni, il riavvio di un'applicazione già in esecuzione DOVESSE richiedere meno di 1 secondo.

Rendimento dell'accesso all'I/O dei file (sezione 8.2)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE garantire prestazioni di scrittura sequenziale di almeno 5 MB/s.
  • [H-0-2] DEVE garantire un rendimento di scrittura casuale di almeno 0,5 MB/s.
  • [H-0-3] DEVE garantire un rendimento di lettura sequenziale di almeno 15 MB/s.
  • [H-0-4] DEVE garantire un rendimento di lettura casuale di almeno 3,5 MB/s.

Modalità di risparmio energetico (sezione 8.3)

Per le implementazioni dei dispositivi palmari:

  • [H-0-1] Tutte le app esenti dalle modalità di risparmio energetico App Standby e Sospensione DEVONO essere rese visibili all'utente finale.
  • [H-0-2] Gli algoritmi di attivazione, manutenzione e risveglio e l'utilizzo delle impostazioni di sistema globali delle modalità di risparmio energetico App Standby e Sospensione NON DEVONO discostarsi dal progetto open source Android.

Contabilità del consumo di energia (sezioni 8.4)

Implementazioni dei dispositivi portatili:

  • [H-0-1] È NECESSARIO fornire un profilo di alimentazione per componente che definisce il valore di consumo corrente per ciascun componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
  • [H-0-2] È OBBLIGATORIO segnalare tutti i valori di consumo di energia in milliampere ora (mAh).
  • [H-0-3] È OBBLIGATORIO segnalare il consumo energetico della CPU per l'UID di ogni processo. Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
  • [H-0-4] DEVE rendere disponibile questo consumo di energia tramite il comando a riga di comando adb shell dumpsys batterystats per lo sviluppatore dell'app.
  • DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.

Se le implementazioni dei dispositivi portatili includono uno schermo o un'uscita video, devono:

2.2.5. Modello di sicurezza

Autorizzazioni (sezioni 9.1)

Implementazioni dei dispositivi portatili:

  • [H-0-1] DEVE consentire alle app di terze parti di accedere alle statistiche di utilizzo tramite l'autorizzazione android.permission.PACKAGE_USAGE_STATS e fornire un meccanismo accessibile agli utenti per concedere o revocare l'accesso a queste app in risposta all'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

2.3. Requisiti della TV

Un dispositivo Android TV è un'implementazione di un dispositivo Android che funge da interfaccia di intrattenimento per l'utilizzo di contenuti multimediali digitali, film, giochi, app e/o TV in diretta per gli utenti seduti a circa tre metri di distanza (un'interfaccia utente "lean back" o "10-foot").

Le implementazioni dei dispositivi Android sono classificate come TV se soddisfano tutti i seguenti criteri:

  • Avere fornito un meccanismo per controllare da remoto l'interfaccia utente visualizzata sul display, che potrebbe trovarsi a tre metri di distanza dall'utente.
  • Avere uno schermo integrato con una diagonale maggiore di 61 cm OPPURE includere una porta di uscita video, ad esempio VGA, HDMI, DisplayPort o una porta wireless per il display.

I requisiti aggiuntivi nel resto di questa sezione sono specifici per le implementazioni dei dispositivi Android TV.

2.3.1. Hardware

Navigazione non tocco (sezione 7.2.2)

Implementazioni dei dispositivi TV:

  • [T-0-1] DEVE supportare il D-pad.

Tasti di navigazione (sezione 7.2.3)

Implementazioni dei dispositivi TV:

  • [T-0-1] DEVE fornire le funzioni Home e Indietro.
  • [T-0-2] DEVE inviare all'applicazione in primo piano sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK).

Mappature dei pulsanti (sezione 7.2.6.1)

Implementazioni dei dispositivi TV:

  • [T-0-1] DEVE includere il supporto dei controller di gioco e dichiarare il flag della funzionalità android.hardware.gamepad.

Telecomando (sezione 7.2.7)

Implementazioni dei dispositivi TV:

Giroscopio (sezione 7.3.4)

Se le implementazioni dei dispositivi TV includono un giroscopio:

  • [T-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 100 Hz.

Bluetooth (sezione 7.4.3)

Implementazioni dei dispositivi TV:

  • [T-0-1] DEVE supportare Bluetooth e Bluetooth LE.

Memoria e spazio di archiviazione minimi (sezione 7.6.1)

Implementazioni dei dispositivi TV:

  • [T-0-1] DEVE essere disponibile almeno 4 GB di spazio di archiviazione non volatile per i dati privati dell'applicazione (ovvero la partizione "/data")
  • [T-0-2] DEVE restituire "true" per ActivityManager.isLowRamDevice() quando è disponibile meno di 1 GB di memoria per il kernel e lo spazio utente.

Microfono (sezione 7.8.1)

Implementazioni dei dispositivi TV:

  • DOVREBBE includere un microfono.

Uscita audio (sezione 7.8.2)

Implementazioni dei dispositivi TV:

  • [T-0-1] DEVE avere un'uscita audio e dichiarare android.hardware.audio.output.

2.3.2. Multimediale

Codifica audio (sezione 5.1)

Le implementazioni dei dispositivi TV DEVONO supportare la seguente codifica audio:

  • [T-0-1] Profilo MPEG-4 AAC (AAC LC)
  • [T-0-2] Profilo MPEG-4 HE AAC (AAC+)
  • [T-0-3] AAC ELD (AAC a basso ritardo migliorato)

Codifica video (sezione 5.2)

Le implementazioni dei dispositivi TV DEVONO supportare la seguente codifica video:

  • [T-0-1] H.264 AVC
  • [T-0-2] VP8

H-264 (sezione 5.2.2)

Le implementazioni dei dispositivi TV sono:

  • [T-SR] È FORTEMENTE CONSIGLIATO supportare la codifica H.264 dei video con risoluzione 720p e 1080p.
  • [T-SR] È FORTEMENTE CONSIGLIATO supportare la codifica H.264 dei video con risoluzione 1080p a 30 fotogrammi al secondo (fps).

Decodifica video (sezione 5.3)

Le implementazioni dei dispositivi TV DEVONO supportare la seguente decodifica video:

  • [T-0-1] H.264 AVC
  • [T-0-2] H.265 HEVC
  • [T-0-3] MPEG-4 SP
  • [T-0-4] VP8
  • [T-0-5] VP9

È FORTEMENTE CONSIGLIATO che le implementazioni dei dispositivi TV supportino la seguente decodifica video:

  • [T-SR] MPEG-2

H.264 (sezione 5.3.4)

Se le implementazioni dei dispositivi TV supportano i decodificatori H.264:

  • [T-1-1] DEVE supportare il profilo High Profile 4.2 e il profilo di decodifica HD 1080p (a 60 fps).
  • [T-1-2] DEVE essere in grado di decodificare i video con entrambi i profili HD indicati nella tabella seguente e codificati con il profilo di base, il profilo principale o il profilo alto di livello 4.2

H.265 (HEVC) (sezione 5.3.5)

Se le implementazioni dei dispositivi TV supportano il codec H.265 e il profilo di decodifica HD 1080p:

  • [T-1-1] DEVE supportare il livello principale del profilo principale 4.1.
  • [T-SR] È FORTEMENTE CONSIGLIATO supportare la frequenza fotogrammi video di 60 fps per HD 1080p.

Se le implementazioni dei dispositivi TV supportano il codec H.265 e il profilo di decodifica UHD:

  • [T-2-1] Il codec DEVE supportare il profilo Main10 di livello 5 del livello principale.

VP8 (sezione 5.3.6)

Se le implementazioni dei dispositivi TV supportano il codec VP8:

  • [T-1-1] DEVE supportare il profilo di decodifica HD 1080p60.

Se le implementazioni dei dispositivi TV supportano il codec VP8 e 720p:

  • [T-2-1] DEVE supportare il profilo di decodifica HD 720p60.

VP9 (sezione 5.3.7)

Se le implementazioni dei dispositivi TV supportano il codec VP9 e la decodifica video UHD:

  • [T-1-1] DEVE supportare una profondità di colore di 8 bit e DOVREBBE supportare VP9 Profile 2 (10 bit).

Se le implementazioni dei dispositivi TV supportano il codec VP9, il profilo 1080p e la decodifica hardware VP9:

  • [T-2-1] DEVE supportare 60 f/s per 1080p.

Contenuti multimediali protetti (sezione 5.8)

Se le implementazioni dei dispositivi sono dispositivi Android TV e supportano la risoluzione 4K:

  • [T-1-1] DEVE supportare HDCP 2.2 per tutti i display esterni con cavo.

Se le implementazioni dei dispositivi TV non supportano la risoluzione 4K:

  • [T-2-1] DEVE supportare HDCP 1.4 per tutti i display esterni con cavo.

Implementazioni dei dispositivi TV:

  • [T-SR] Sono FORTEMENTE CONSIGLIATI per supportare la decodifica simultanea di stream sicuri. È MOLTO CONSIGLIATO, come minimo, la decodifica simultanea di due stream.

Volume di uscita audio (sezione 5.5.3)

Implementazioni dei dispositivi TV:

  • [T-0-1] DEVE includere il supporto del volume principale di sistema e dell'attenuazione del volume dell'uscita audio digitale sulle uscite supportate, ad eccezione dell'uscita passthrough audio compresso (in cui non viene eseguita alcuna decodifica audio sul dispositivo).

2.3.3. Software

Implementazioni dei dispositivi TV:

Compatibilità con WebView (sezione 3.4.1)

Implementazioni dei dispositivi TV:

  • [T-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.

Controllo multimediale nella schermata di blocco (sezione 3.8.10)

Se le implementazioni dei dispositivi Android TV supportano una schermata di blocco,devono:

  • [T-1-1] DEVE mostrare le notifiche della schermata di blocco, incluso il modello di notifica multimediale.

Multi-finestra (sezione 3.8.14)

Implementazioni dei dispositivi TV:

  • [T-SR] È MOLTO CONSIGLIATO supportare la modalità Picture in picture (PIP) multi-finestra.

Accessibilità (Sezione 3.10)

Implementazioni dei dispositivi TV:

  • [T-SR] DEVE supportare i servizi di accessibilità di terze parti.

  • [T-SR] Per le implementazioni dei dispositivi Android TV è FORTEMENTE CONSIGLIATO precaricare servizi di accessibilità sul dispositivo paragonabili o superiori alle funzionalità di Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale precaricato) come indicato nel progetto open source talkback.

Text-to-Speech (sezione 3.11)

Se le implementazioni del dispositivo segnalano la funzionalità android.hardware.audio.output, devono:

  • [T-SR] È FORTEMENTE CONSIGLIATO includere un motore TTS che supporti le lingue disponibili sul dispositivo.

  • [T-0-1] DEVE supportare l'installazione di motori TTS di terze parti.

Framework di input TV (sezione 3.12)

Implementazioni dei dispositivi TV:

  • [T-0-1] DEVE supportare il TV Input Framework.

2.2.4. Prestazioni e potenza

Coerenza dell'esperienza utente (sezione 8.1)

Per le implementazioni dei dispositivi TV:

  • [T-0-1] Latenza dei frame coerente. La latenza dei fotogrammi incoerente o un ritardo nel rendering dei fotogrammi NON DEVONO verificarsi più di 5 volte al secondo e DEVONO essere inferiori a 1 fotogramma al secondo.

Rendimento dell'accesso all'I/O dei file (sezione 8.2)

Implementazioni dei dispositivi TV:

  • [T-0-1] DEVE garantire prestazioni di scrittura sequenziale di almeno 5 MB/s.
  • [T-0-2] DEVE garantire prestazioni di scrittura casuale di almeno 0,5 MB/s.
  • [T-0-3] DEVE garantire un rendimento di lettura sequenziale di almeno 15 MB/s.
  • [T-0-4] DEVE garantire un rendimento di lettura casuale di almeno 3,5 MB/s.

Modalità di risparmio energetico (sezione 8.3)

Per le implementazioni dei dispositivi TV:

  • [T-0-1] Tutte le app esenti dalle modalità di risparmio energetico App Standby e Sospensione DEVONO essere rese visibili all'utente finale.
  • [T-0-2] Gli algoritmi di attivazione, manutenzione e risveglio e l'utilizzo delle impostazioni di sistema globali delle modalità di risparmio energetico App Standby e Sospensione NON DEVONO discostarsi dal progetto open source Android.

Contabilità del consumo di energia (sezioni 8.4)

Implementazioni dei dispositivi TV:

  • [T-0-1] È NECESSARIO fornire un profilo di alimentazione per componente che definisca il valore di consumo corrente per ciascun componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
  • [T-0-2] DEVI segnalare tutti i valori di consumo di energia in milliampere ora (mAh).
  • [T-0-3] DEVE segnalare il consumo energetico della CPU per l'UID di ogni processo. Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
  • DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.
  • [T-0-4] DEVE rendere disponibile questo consumo di energia tramite il comando a riga di comando adb shell dumpsys batterystats per lo sviluppatore dell'app.

2.4. Requisiti dell'orologio

Un dispositivo Android Watch si riferisce a un'implementazione di un dispositivo Android progettata per essere indossata sul corpo, ad esempio sul polso.

Le implementazioni dei dispositivi Android sono classificate come smartwatch se soddisfano tutti i seguenti criteri:

  • Avere uno schermo con una lunghezza diagonale fisica compresa tra 28 e 64 mm.
  • Avere un meccanismo che ne consenta l'uso a contatto con il corpo.

I requisiti aggiuntivi riportati nel resto di questa sezione sono specifici per le implementazioni dei dispositivi Android Watch.

2.4.1. Hardware

Dimensioni schermo (Sezione 7.1.1.1)

Guarda le implementazioni dei dispositivi:

  • [W-0-1] DEVE avere uno schermo con dimensioni fisiche diagonali comprese tra 28 e 64 mm.

Tasti di navigazione (sezione 7.2.3)

Guarda le implementazioni dei dispositivi:

  • [W-0-1] L'utente DEVE avere a disposizione la funzione Home e la funzione Indietro, tranne quando è in UI_MODE_TYPE_WATCH.

Input touchscreen (sezione 7.2.4)

Guarda le implementazioni dei dispositivi:

  • [W-0-2] DEVE supportare l'input touchscreen.

Accelerometro (sezione 7.3.1)

Guarda le implementazioni dei dispositivi:

  • [W-SR] È MOLTO CONSIGLIATO includere un accelerometro a 3 assi.

Bluetooth (sezione 7.4.3)

Guarda le implementazioni dei dispositivi:

  • [W-0-1] DEVE supportare il Bluetooth.

Memoria e spazio di archiviazione minimi (sezione 7.6.1)

Guarda le implementazioni dei dispositivi:

  • [W-0-1] DEVE essere disponibile almeno 1 GB di spazio di archiviazione non volatile per i dati privati dell'applicazione (ovvero la partizione "/data")
  • [W-0-2] DEVE avere almeno 416 MB di memoria disponibili per il kernel e lo spazio utente.

Microfono (sezione 7.8.1)

Guarda le implementazioni dei dispositivi:

  • [W-0-1] DEVE includere un microfono.

Uscita audio (sezione 7.8.1)

Guarda le implementazioni dei dispositivi:

  • Può, ma NON deve, avere un'uscita audio.

2.4.2. Multimediale

Nessun altro requisito.

2.4.3. Software

Guarda le implementazioni dei dispositivi:

  • [W-0-1] È OBBLIGATORIO dichiarare la funzionalità android.hardware.type.watch.
  • [W-0-2] DEVE supportare uiMode = UI_MODE_TYPE_WATCH.

Ricerca (sezione 3.8.4)

Guarda le implementazioni dei dispositivi:

  • [W-SR] È FORTEMENTE CONSIGLIATO implementare un assistente sul dispositivo per gestire l'azione di assistenza.

Accessibilità (Sezione 3.10)

Guarda le implementazioni dei dispositivi che dichiarano il flag della funzionalità android.hardware.audio.output:

  • [W-1-1] DEVE supportare i servizi di accessibilità di terze parti.

  • [W-SR] È FORTEMENTE CONSIGLIATO di precaricare sul dispositivo servizi di accessibilità paragonabili o superiori alle funzionalità di Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale precaricato) come indicato nel progetto open source talkback.

Text-to-Speech (sezione 3.11)

Se le implementazioni dei dispositivi smartwatch segnalano la funzionalità android.hardware.audio.output:

  • [W-SR] È FORTEMENTE CONSIGLIATO includere un motore TTS che supporti le lingue disponibili sul dispositivo.

  • [W-0-1] DEVE supportare l'installazione di motori TTS di terze parti.

2.5. Requisiti per il settore auto e motori

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

Le implementazioni dei dispositivi Android sono classificate come Automotive se dichiarano la funzionalità android.hardware.type.automotive o soddisfano tutti i seguenti criteri.

  • Sono integrati in un veicolo auto e motori o possono essere collegati a un veicolo.
  • Utilizzi uno schermo nella fila del sedile del conducente come display principale.

I requisiti aggiuntivi riportati nel resto di questa sezione sono specifici per le implementazioni dei dispositivi Android Automotive.

2.5.1. Hardware

Dimensioni schermo (Sezione 7.1.1.1)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE avere uno schermo con una diagonale fisica di almeno 15 cm.
  • [A-0-2] DEVE avere un layout delle dimensioni dello schermo di almeno 750 dp x 480 dp.

Tasti di navigazione (sezione 7.2.3)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE fornire la funzione Home e PUÒ fornire le funzioni Indietro e Recenti.
  • [A-0-2] DEVE inviare all'applicazione in primo piano sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK).

Accelerometro (sezione 7.3.1)

Implementazioni di dispositivi per auto e motori:

  • [A-SR] È FORTEMENTE CONSIGLIATO includere un accelerometro a 3 assi.

Se le implementazioni dei dispositivi per auto e motori includono un accelerometro a 3 assi:

GPS (sezione 7.3.3)

Se le implementazioni dei dispositivi per auto e motori includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag della funzionalità android.hardware.location.gps:

  • [A-1-1] La generazione della tecnologia GNSS DEVE essere dell'anno "2017" o successiva.

Giroscopio (sezione 7.3.4)

Se le implementazioni dei dispositivi per auto includono un giroscopio:

  • [A-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 100 Hz.

Sensori solo per Android Automotive (sezione 7.3.11) Marcia attuale (sezione 7.3.11.1)

Implementazioni di dispositivi per auto e motori:

  • DOVREBBE fornire l'attrezzatura attuale come SENSOR_TYPE_GEAR.

Modalità Giorno/Notte (sezione 7.3.11.2)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE supportare la modalità giorno/notte definita come SENSOR_TYPE_NIGHT.
  • [A-0-2] Il valore del flag SENSOR_TYPE_NIGHT DEVE essere coerente con la modalità giorno/notte della dashboard e DOVREBBE essere basato sull'input del sensore di luce ambientale.
  • Il sensore di luce ambientale sottostante POTREBBE essere lo stesso di Fotometro.

Stato di guida (sezione 7.3.11.3)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE supportare lo stato di guida definito come SENSOR_TYPE_DRIVING_STATUS, con un valore predefinito di DRIVE_STATUS_UNRESTRICTED quando il veicolo è completamente fermo e parcheggiato. È responsabilità dei produttori di dispositivi configurare SENSOR_TYPE_DRIVING_STATUS in conformità con tutte le leggi e normative vigenti nei mercati in cui viene spedito il prodotto.

Velocità delle ruote (sezione 7.3.11.4)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] È OBBLIGATORIO fornire la velocità del veicolo definita come SENSOR_TYPE_CAR_SPEED.

Bluetooth (sezione 7.4.3)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE supportare il Bluetooth e DOVREBBE supportare il Bluetooth LE.

  • [A-0-2] Le implementazioni di Android Automotive DEVONO supportare i seguenti profili Bluetooth:

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

Capacità di rete minima (sezione 7.4.5)

Implementazioni di dispositivi per auto e motori:

  • DOVREBBE includere il supporto per la connettività dati basata su rete mobile.

Memoria e spazio di archiviazione minimi (sezione 7.6.1)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE avere almeno 4 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione (ovvero la partizione "/data")

Modalità periferica USB (sezione 7.7.1)

Implementazioni di dispositivi per auto e motori:

  • DEVE includere una porta USB che supporti la modalità periferica.

Microfono (sezione 7.8.1)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE includere un microfono.

Uscita audio (sezione 7.8.2)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE avere un'uscita audio e dichiarare android.hardware.audio.output.

2.5.2. Multimediale

Codifica audio (sezione 5.1)

Le implementazioni dei dispositivi per auto DEVONO supportare la seguente codifica audio:

  • [A-1-1] Profilo MPEG-4 AAC (AAC LC)
  • [A-1-2] Profilo MPEG-4 HE AAC (AAC+)
  • [A-1-3] AAC ELD (AAC a basso ritardo migliorato)

Codifica video (sezione 5.2)

Le implementazioni dei dispositivi per auto e motori DEVONO supportare la seguente codifica video:

  • [A-0-1] H.264 AVC
  • [A-0-2] VP8

Decodifica video (sezione 5.3)

Le implementazioni dei dispositivi per auto e motori DEVONO supportare la seguente decodifica video:

  • [A-0-1] H.264 AVC
  • [A-0-2] MPEG-4 SP
  • [A-0-3] VP8
  • [A-0-4] VP9

È FORTEMENTE CONSIGLIATO che le implementazioni dei dispositivi per auto e motori supportino la seguente decodifica video:

  • [A-SR] H.265 HEVC

2.5.3. Software

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE dichiarare la funzionalità android.hardware.type.automotive.
  • [A-0-2] DEVE supportare uiMode = UI_MODE_TYPE_CAR.
  • [A-0-3] Le implementazioni di Android Automotive DEVONO supportare tutte le API pubbliche nello spazio dei nomi android.car.*.

Compatibilità con WebView (sezione 3.4.1)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE fornire un'implementazione completa di android.webkit.Webview API.

Notifiche (sezione 3.8.3)

Implementazioni di dispositivi Android Automotive:

  • [A-0-1] DEVE mostrare notifiche che utilizzano l'API Notification.CarExtender quando richiesto da applicazioni di terze parti.

Ricerca (sezione 3.8.4)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] È NECESSARIO implementare un assistente sul dispositivo per gestire l'azione di assistenza.

Interfaccia utente dei contenuti multimediali (sezione 3.14)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE includere un framework UI per supportare le app di terze parti che utilizzano le API multimediali come descritto nella sezione 3.14.

2.2.4. Prestazioni e potenza

Modalità di risparmio energetico (sezione 8.3)

Per le implementazioni dei dispositivi per auto e motori:

  • [A-0-1] Tutte le app esenti dalle modalità di risparmio energetico App Standby e Sospensione DEVONO essere rese visibili all'utente finale.
  • [A-0-2] Gli algoritmi di attivazione, manutenzione e risveglio e l'utilizzo delle impostazioni di sistema globali delle modalità di risparmio energetico App Standby e Sospensione NON DEVONO discostarsi dal progetto open source Android.

Contabilità del consumo di energia (sezioni 8.4)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] È OBBLIGATORIO fornire un profilo di alimentazione per componente che definisce il valore di consumo corrente per ciascun componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
  • [A-0-2] DEVI indicare tutti i valori di consumo di energia in milliampere ora (mAh).
  • [A-0-3] DEVE segnalare il consumo energetico della CPU per l'UID di ogni processo. Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
  • DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.
  • [A-0-4] DEVE rendere disponibile questo consumo di energia tramite il comando a riga di comando adb shell dumpsys batterystats per lo sviluppatore dell'app.

2.2.5. Modello di sicurezza

Supporto multiutente (Sezione 9.5)

Se le implementazioni dei dispositivi per auto e motori includono più utenti:

  • [A-1-1] DEVE includere un account ospite che consenta tutte le funzioni fornite dal sistema del veicolo senza che sia necessario che un utente acceda.

Isolamento del sistema del veicolo auto e motori (sezione 9.14)

Implementazioni di dispositivi per auto e motori:

  • [A-0-1] DEVE controllare i messaggi provenienti dai sottosistemi del veicolo del framework Android, ad esempio inserendo nella lista consentita i tipi di messaggi e le origini dei messaggi consentiti.
  • [A-0-2] È OBBLIGATORIO il monitoraggio degli attacchi di tipo denial of service dal framework Android o da app di terze parti. In questo modo, si evita che il software dannoso inondi la rete del veicolo con traffico, causando il malfunzionamento dei sottosistemi del veicolo.

2.6. Requisiti del tablet

Un dispositivo tablet Android si riferisce a un'implementazione di un dispositivo Android che in genere viene tenuto in entrambe le mani e non in un fattore di forma a conchiglia.

Le implementazioni dei dispositivi Android sono classificate come tablet se soddisfano tutti i seguenti criteri:

  • Avere una fonte di alimentazione che offra mobilità, ad esempio una batteria.
  • Avere una dimensione dello schermo in diagonale fisica compresa tra 18 e 45 cm.

Le implementazioni dei tablet hanno requisiti simili a quelli dei dispositivi palmari. Le eccezioni sono indicate da * nella sezione in questione e riportate per riferimento in questa sezione.

2.4.1. Hardware

Dimensioni schermo (Sezione 7.1.1.1)

Implementazioni dei dispositivi tablet:

  • [Ta-0-1] DEVE avere uno schermo compreso tra 18 e 45 cm.

Memoria e spazio di archiviazione minimi (sezione 7.6.1)

Le densità dello schermo elencate per schermi piccoli/normali nei requisiti per i dispositivi portatili non sono applicabili ai tablet.

Modalità periferica USB (sezione 7.7.1)

Se le implementazioni dei dispositivi palmari includono una porta USB che supporta la modalità periferica, devono:

  • PUO' implementare l'API Android Open Accessory (AOA).

Modalità Realtà virtuale (sezione 7.9.1)

Realtà virtuale ad alte prestazioni (sezione 7.9.2)

I requisiti per la realtà virtuale non sono applicabili ai tablet.

3. Software

3.1. Compatibilità con le API gestite

L'ambiente di esecuzione del codice bytecode Dalvik gestito è il veicolo principale per le applicazioni Android. L'API (interfaccia di programmazione di un'applicazione) Android è l'insieme di interfacce della piattaforma Android esposte alle applicazioni in esecuzione nell'ambiente di runtime gestito.

  • [C-0-1] Le implementazioni dei dispositivi DEVONO fornire implementazioni complete, inclusi tutti i comportamenti documentati, di qualsiasi API documentata esposta dall'SDK Android o di qualsiasi API decorata con l'indicatore "@SystemApi" nel codice sorgente di Android upstream.

  • [C-0-2] Le implementazioni dei dispositivi DEVONO supportare/preservare tutte le classi, i metodi e gli elementi associati contrassegnati dall'annotazione TestApi (@TestApi).

  • [C-0-3] Le implementazioni dei dispositivi NON DEVONO omettere API gestite, modificare interfacce o firme delle API, discostarsi dal comportamento documentato o includere no-op, tranne nei casi specificamente consentiti da questa definizione di compatibilità.

  • [C-0-4] Le implementazioni dei dispositivi DEVONO comunque mantenere le API presenti e comportarsi in modo ragionevole, anche quando alcune funzionalità hardware per le quali Android include API vengono omesse. Consulta la sezione 7 per i requisiti specifici di questo scenario.

3.1.1. Estensioni Android

Android include il supporto per l'estensione delle API gestite mantenendo la stessa versione del livello API.

  • [C-0-1] Le implementazioni dei dispositivi Android DEVONO precaricare l'implementazione AOSP sia della libreria condivisa ExtShared sia dei servizi ExtServices con versioni superiori o uguali alle versioni minime consentite per ogni livello API. Ad esempio, le implementazioni dei dispositivi Android 7.0 con livello API 24 DEVONO includere almeno la versione 1.

3.2. Compatibilità API soft

Oltre alle API gestite della sezione 3.1, Android include anche un'API "soft" significativa solo di runtime, sotto forma di intent, autorizzazioni e aspetti simili delle applicazioni Android che non possono essere applicati al momento della compilazione dell'applicazione.

3.2.1. Autorizzazioni

  • [C-0-1] Gli implementatori dei dispositivi DEVONO supportare e applicare tutte le costanti di autorizzazione come documentato nella pagina di riferimento delle autorizzazioni. Tieni presente che la sezione 9 elenca requisiti aggiuntivi relativi al modello di sicurezza di Android.

3.2.2. Parametri di compilazione

Le API Android includono una serie di costanti nella classe android.os.Build che hanno lo scopo di descrivere il dispositivo corrente.

  • [C-0-1] 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 8.1.
VERSION.SDK La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 8.1, questo campo DEVE avere il valore intero 8.1_INT.
VERSION.SDK_INT La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 8.1, questo campo DEVE avere il valore intero 8.1_INT.
VERSION.INCREMENTAL Un valore scelto dall'implementatore del dispositivo che designa la build specifica del sistema Android attualmente in esecuzione, in formato leggibile. Questo valore NON DEVE essere riutilizzato per build diverse rese disponibili agli utenti finali. Un utilizzo tipico di questo campo è indicare il numero di build o l'identificatore della modifica del controllo del codice sorgente utilizzato per generare la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
DA TAVOLO Un valore scelto dall'implementatore del dispositivo che identifica l'hardware interno specifico utilizzato dal dispositivo, in formato leggibile. Un possibile utilizzo di questo campo è indicare la revisione specifica della scheda che alimenta il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
BRAND Un valore che riflette il nome del brand associato al dispositivo, come noto agli utenti finali. DEVE essere in un formato leggibile e DEVE rappresentare il produttore del dispositivo o il brand dell'azienda con cui viene commercializzato il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
SUPPORTED_32_BIT_ABIS Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
SUPPORTED_64_BIT_ABIS Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
CPU_ABI Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
CPU_ABI2 Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
DISPOSITIVO Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice che identifica la configurazione delle funzionalità hardware e il design industriale del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Il nome del dispositivo NON DEVE cambiare durante la vita utile del prodotto.
FINGERPRINT Una stringa che identifica in modo univoco questa build. DOVREBBE essere ragionevolmente leggibile da una persona. DEVE seguire questo modello:

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

Ad esempio:

acme/myproduct/
    mydevice:8.1/LMYXX/3359:userdebug/test-keys

L'impronta NON DEVE includere caratteri di spazio vuoto. Se altri campi inclusi nel modello riportato sopra contengono spazi vuoti, DEVONO essere sostituiti nell'impronta della build con un altro carattere, ad esempio il trattino basso ("_"). Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit.

HARDWARE Il nome dell'hardware (dalla riga di comando del kernel o da /proc). DOVREBBE essere ragionevolmente leggibile da una persona. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
ORGANIZZATORE Una stringa che identifica in modo univoco l'host su cui è stata eseguita la compilazione, in formato leggibile. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
ID Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una versione specifica, in un formato leggibile. Questo campo può essere uguale ad android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere le build software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
PRODUTTORE La ragione sociale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota (""). Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.
MODELLO Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo noto all'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota (""). Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.
PRODOTTO Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice del prodotto specifico (SKU) che DEVE essere univoco all'interno dello stesso brand. DEVE essere leggibile, ma non necessariamente destinato alla visualizzazione da parte degli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Il nome del prodotto NON DEVE cambiare durante il ciclo di vita del prodotto.
SERIALE Un numero di serie hardware, che DEVE essere disponibile e univoco su tutti i dispositivi con lo stesso MODELLO e PRODUTTORE. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^([a-zA-Z0-9]{6,20})$".
TAG Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che distingue ulteriormente la build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni di firma della piattaforma Android: release-keys, dev-keys, test-keys.
DURATA Un valore che rappresenta il timestamp della compilazione.
MACCHINA Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni di runtime Android tipiche: user, userdebug o eng.
UTENTE Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
SECURITY_PATCH Un valore che indica il livello della patch di sicurezza di una build. DEBBA indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti nel Bollettino pubblico sulla sicurezza di Android designato. DEVE essere nel formato [AAAA-MM-GG] e corrispondere a una stringa definita documentata nel Bollettino pubblico sulla sicurezza di Android o nell'Avviso sulla sicurezza di Android, ad esempio "2015-11-01".
BASE_OS Un valore che rappresenta il parametro FINGERPRINT della build, che è altrimenti identico a questa build, ad eccezione delle patch fornite nel bollettino Android Public Security. DEVE riportare il valore corretto e, se una build di questo tipo non esiste, deve riportare una stringa vuota ("").
BOOTLOADER Un valore scelto dall'implementatore del dispositivo che identifica la versione specifica del bootloader interno utilizzata nel dispositivo, in formato leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
getRadioVersion() DEVE (essere o restituire) un valore scelto dall'implementatore del dispositivo che identifica la versione specifica della radio/del modem interna utilizzata nel dispositivo, in formato leggibile. Se un dispositivo non ha radio/modem interni, DEVE restituire NULL. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-,]+$".

3.2.3. Compatibilità con gli intent

3.2.3.1. Intent di applicazione principali

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

  • [C-0-1] Le implementazioni dei dispositivi DEVONO precaricare una o più applicazioni o componenti di servizio con un gestore intent per tutti i pattern di filtro per intent pubblici definiti dalle seguenti applicazioni Android di base in AOSP:

    • Orologio da scrivania
    • Browser
    • Calendar
    • Contatti
    • Galleria
    • GlobalSearch
    • Avvio app
    • Musica
    • Impostazioni
3.2.3.2. Risoluzione dell'intent
  • [C-0-1] 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.

  • [C-0-2] Gli implementatori di Dvice NON DEVONO assegnare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema o impedire alle applicazioni di terze parti di associarsi a questi pattern e assumerne il controllo. Questo divieto include, in particolare, la disattivazione dell'interfaccia utente "Chooser" che consente all'utente di scegliere tra più applicazioni che gestiscono tutte lo stesso pattern di intent.

  • [C-0-3] Le implementazioni dei dispositivi DEVONO fornire un'interfaccia utente che consenta agli utenti di modificare l'attività predefinita per gli intent.

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

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

  • [C-0-4] DEVE tentare di convalidare tutti i filtri per intent eseguendo i passaggi di convalida definiti nella specifica Digital Asset Links, come implementato dal gestore pacchetti nel progetto open source Android upstream.
  • [C-0-5] DEVE tentare la convalida dei filtri di intent durante l'installazione dell'applicazione e impostare tutti i filtri di intent UIR convalidati correttamente come gestori di app predefiniti per i relativi UIR.
  • PUO' impostare filtri di intent URI specifici come gestori di app predefiniti per i propri URI, se vengono verificati correttamente, ma altri filtri URI candidati non superano la verifica. Se un'implementazione del dispositivo esegue questa operazione, DEVE fornire all'utente le sostituzioni dei pattern per URI appropriate nel menu delle impostazioni.
  • DEVE fornire all'utente i controlli dei link dell'app per app nelle Impostazioni come segue:
    • [C-0-6] L'utente DEVE essere in grado di sostituire in modo olistico il comportamento predefinito dei link alle app in modo che un'app sia: sempre aperta, sempre chiedi o mai aperta, che deve essere applicato allo stesso modo a tutti i filtri di intent URI candidati.
    • [C-0-7] L'utente DEVE essere in grado di visualizzare un elenco dei filtri di intent URI candidati.
    • L'implementazione del dispositivo PUÒ fornire all'utente la possibilità di ignorare filtri di intent URI candidati specifici che sono stati verificati correttamente, in base al filtro di intent.
    • [C-0-8] L'implementazione del dispositivo DEVE fornire agli utenti la possibilità di visualizzare e sostituire filtri di intent URI candidati specifici se l'implementazione del dispositivo consente a alcuni filtri di intent URI candidati di superare la verifica, mentre altri possono non riuscirci.
3.2.3.3. Spazi dei nomi degli intent
  • [C-0-1] Le implementazioni dei dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando un'AZIONE, una CATEGORIA o un'altra stringa chiave nello spazio dei nomi android. o com.android.
  • [C-0-2] Gli implementatori di dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando un'azione, una CATEGORY o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione.
  • [C-0-3] Gli implementatori dei dispositivi NON DEVONO modificare o estendere nessuno dei pattern di intent utilizzati dalle app di base elencate nella sezione 3.2.3.1.
  • Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano spazi dei nomi chiaramente e inequivocabilmente associati alla propria organizzazione. Questo divieto è analogo a quello specificato per i corsi di lingua Java nella sezione 3.6.
3.2.3.4. Intent di trasmissione

Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent al fine di essere avvisate delle modifiche nell'ambiente hardware o software.

Implementazioni dei dispositivi:

  • [C-0-1] DEVE trasmettere gli intent di trasmissione pubblica in risposta a eventi di sistema appropriati come descritto nella documentazione dell'SDK. Tieni presente che questo requisito non è in conflitto con la sezione 3.5, poiché la limitazione per le applicazioni in background è descritta anche nella documentazione dell'SDK.
3.2.3.5. Impostazioni app predefinite

Android include impostazioni che offrono agli utenti un modo semplice per selezionare le applicazioni predefinite, ad esempio per la schermata Home o gli SMS.

Ove opportuno, le implementazioni dei dispositivi DEVONO fornire un menu delle impostazioni simile ed essere compatibili con il pattern del filtro intent e i metodi API descritti nella documentazione dell'SDK come indicato di seguito.

Se le implementazioni dei dispositivi segnalano android.software.home_screen:

Se le implementazioni dei dispositivi segnalano android.hardware.telephony:

  • [C-2-1] DEVE fornire un menu delle impostazioni che chiami l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT per mostrare una finestra di dialogo per modificare l'applicazione SMS predefinita.

  • [C-2-2] DEVE rispettare l'intent android.telecom.action.CHANGE_DEFAULT_DIALER per mostrare una finestra di dialogo che consenta all'utente di modificare l'applicazione Telefono predefinita.

  • [C-2-3] DEVE rispettare l'intent android.telecom.action.CHANGE_PHONE_ACCOUNTS per fornire all'utente la possibilità di configurare il ConnectionServices associato al PhoneAccounts, nonché un PhoneAccount predefinito che il fornitore di servizi di telecomunicazioni utilizzerà per effettuare chiamate in uscita. L'implementazione AOSP soddisfa questo requisito includendo un menu "Opzione per gli account chiamate" nel menu delle impostazioni "Chiamate".

Se le implementazioni dei dispositivi segnalano android.hardware.nfc.hce:

Se le implementazioni dei dispositivi supportano VoiceInteractionService e hanno più di un'applicazione che utilizza questa API installata contemporaneamente:

3.2.4. Attività sui display secondari

Se le implementazioni dei dispositivi consentono di avviare normali attività Android sui display secondari:

  • [C-1-1] È NECESSARIO impostare il flag funzionalità android.software.activities_on_secondary_displays.
  • [C-1-2] DEVE garantire la compatibilità con l'API simile a un'attività in esecuzione sul display principale.
  • [C-1-3] DEVE mostrare la nuova attività sulla stessa visualizzazione dell'attività che l'ha lanciata, quando la nuova attività viene lanciata senza specificare una visualizzazione target tramite l'API ActivityOptions.setLaunchDisplayId().
  • [C-1-4] DEVE distruggere tutte le attività quando viene rimosso un display con il flag Display.FLAG_PRIVATE.
  • [C-1-5] È NECESSARIO ridimensionare di conseguenza tutte le attività su un VirtualDisplay se il display stesso viene ridimensionato.
  • PUÒ mostrare un editor di metodi di inserimento (IME, un controllo utente che consente agli utenti di inserire testo) sul display principale quando un campo di immissione di testo diventa attivo su un display secondario.
  • DEVE implementare lo stato attivo dell'input sul display secondario indipendentemente dal display principale, quando sono supportati input tocco o da tastiera.
  • DEVE avere android.content.res.Configuration che corrisponde a quel display per essere visualizzato, funzionare correttamente e mantenere la compatibilità se un'attività viene avviata sul display secondario.

Se le implementazioni del dispositivo consentono di avviare normali attività Android sui display secondari e i display principale e secondario hanno android.util.DisplayMetrics diversi:

  • [C-2-1] Le attività non ridimensionabili (con resizeableActivity=false in AndroidManifest.xml) e le app che hanno come target il livello API 23 o precedente NON DEVONO essere consentite sui display secondari.

Se le implementazioni del dispositivo consentono di avviare normali attività Android sui display secondari e un display secondario ha il flag android.view.Display.FLAG_PRIVATE:

  • [C-3-1] Solo il proprietario del display, del sistema e delle attività già presenti sul display DEVE essere in grado di avviarlo. Chiunque può avviare un'app su un display con il flag android.view.Display.FLAG_PUBLIC.

3.3. Compatibilità con le API native

Gli implementatori di dispositivi sono:

La compatibilità con il codice nativo è complessa. Per questo motivo, gli implementatori di dispositivi sono:

  • [SR] È FORTEMENTE CONSIGLIATO di utilizzare le implementazioni delle librerie elencate di seguito dal progetto open source Android upstream.

3.3.1. Application Binary Interface

Il bytecode Dalvik gestito può chiamare il codice nativo fornito nel file .apk dell'applicazione come file ELF .so compilato per l'architettura hardware del dispositivo appropriata. Poiché il codice nativo è altamente dipendente dalla tecnologia del processore sottostante, Android definisce una serie di interfacce a livello di codice macchina (ABI) nell'Android NDK.

Implementazioni dei dispositivi:

  • [C-0-1] DEVE essere compatibile con una o più ABI definite e implementare la compatibilità con il kit di sviluppo NDK per Android.
  • [C-0-2] 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).
  • [C-0-3] DEVE essere compatibile con il codice sorgente (ovvero con gli header) e con il codice binario (per l'ABI) di ogni libreria richiesta nell'elenco di seguito.
  • [C-0-4] DEVE supportare l'ABI a 32 bit equivalente se è supportato un ABI a 64 bit.
  • [C-0-5] DEVE segnalare con precisione l'interfaccia a oggetti di base dell'applicazione (ABI) nativa supportata dal dispositivo tramite i parametri android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, ciascuno un elenco separato da virgole di ABI ordinati dal più preferito al meno preferito.
  • [C-0-6] DEVE segnalare, tramite i parametri sopra indicati, solo le ABI documentate e descritte nell'ultima versione della documentazione di gestione ABI di Android NDK e DEVE includere il supporto dell'estensione Advanced SIMD (nota anche come NEON).

  • [C-0-7] DEVE rendere disponibili per le app che includono codice nativo tutte le seguenti librerie che forniscono API native:

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

  • [C-0-8] NON DEVE aggiungere o rimuovere le funzioni pubbliche per le librerie native elencate sopra.

  • [C-0-9] È OBBLIGATORIO elencare le librerie non AOSP aggiuntive esposte direttamente alle app di terze parti in /vendor/etc/public.libraries.txt.
  • [C-0-10] NON DEVE esporre altre librerie native, implementate e fornite in AOSP come librerie di sistema, ad app di terze parti che hanno come target il livello API 24 o versioni successive, in quanto sono riservate.
  • [C-0-11] È OBBLIGATORIO esportare tutti i simboli delle funzioni OpenGL ES 3.1 e del pacchetto di estensioni Android, come definiti nell'NDK, tramite la libreria libGLESv3.so. Tieni presente che, anche se tutti i simboli DEVONO essere presenti, la sezione 7.1.4.1 descrive in modo più dettagliato i requisiti per l'implementazione completa di ogni funzione corrispondente.
  • [C-0-12] È OBBLIGATORIO esportare i simboli di funzione per i simboli di funzione di base di Vulkan 1.0, nonché le estensioni VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 tramite la libreria libvulkan.so. Tieni presente che, anche se tutti i simboli DEVONO essere presenti, la sezione 7.1.4.2 descrive in modo più dettagliato i requisiti per l'implementazione completa di ogni funzione corrispondente.
  • DEVE essere compilato utilizzando il codice sorgente e i file di intestazione disponibili nel progetto open source Android upstream

Tieni presente che le release future dell'Android NDK potrebbero introdurre il supporto di ABI aggiuntivi.

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

Se le implementazioni dei dispositivi sono dispositivi ARM a 64 bit:

  • [C-1-1] Sebbene l'architettura ARMv8 ritiri diverse operazioni della CPU, incluse alcune operazioni utilizzate nel codice nativo esistente, le seguenti operazioni ritirate DEVONO rimanere disponibili per il codice ARM nativo a 32 bit, tramite il supporto della CPU nativa o tramite l'emulazione software:

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

Se le implementazioni del dispositivo includono un'ABI ARM a 32 bit:

  • [C-2-1] È OBBLIGATORIO includere le seguenti righe in /proc/cpuinfo quando viene letto da applicazioni ARM a 32 bit per garantire la compatibilità con le applicazioni create utilizzando le versioni precedenti di Android NDK.

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

  • NON deve modificare /proc/cpuinfo quando viene letto da applicazioni ARM o non ARM a 64 bit.

3.4. Compatibilità web

3.4.1. Compatibilità con WebView

Se le implementazioni dei dispositivi forniscono un'implementazione completa dell'API android.webkit.Webview:

  • [C-1-1] È obbligatorio segnalare android.software.webview.
  • [C-1-2] È OBBLIGATORIO utilizzare la build del progetto Chromium dal progetto open source Android upstream sul ramo Android 8.1 per l'implementazione dell'API android.webkit.WebView.

  • [C-1-3] La stringa dello user agent segnalata da WebView DEVE avere il seguente formato:

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

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

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

3.4.2. Compatibilità del browser

Se le implementazioni dei dispositivi includono un'applicazione Browser autonoma per la navigazione web generale, devono:

  • [C-1-1] DEVE supportare ciascuna di queste API associate a HTML5:
  • [C-1-2] DEVE supportare l'API webstorage HTML5/W3C e DOVREBBE supportare l'API IndexedDB HTML5/W3C. Tieni presente che, poiché gli enti di standardizzazione dello sviluppo web stanno adottando IndexedDB al posto di webstorage, IndexedDB dovrebbe diventare un componente obbligatorio in una versione futura di Android.
  • PUÒ includere una stringa user agent personalizzata nell'applicazione Browser autonoma.
  • DOVREBBE implementare il supporto per il maggior numero possibile di funzionalità di HTML5 nell'applicazione Browser autonoma (in base all'applicazione Browser WebKit a monte o a una sostituzione di terze parti).

Tuttavia, se le implementazioni dei dispositivi non includono un'applicazione browser autonoma, queste:

  • [C-2-1] DEVE comunque supportare i pattern di intenti pubblici come descritto nella sezione 3.2.3.1.

3.5. Compatibilità comportamentale dell'API

I comportamenti di ciascuno dei tipi di API (gestite, soft, native e web) devono essere coerenti con l'implementazione preferita del progetto Android Open Source a monte. Ecco alcune aree specifiche di compatibilità:

  • [C-0-1] I dispositivi NON DEVONO modificare il comportamento o la semantica di uno scopo standard.
  • [C-0-2] 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).
  • [C-0-3] I dispositivi NON DEVONO modificare la semantica di un'autorizzazione standard.
  • I dispositivi NON DEVONO modificare le limitazioni applicate alle applicazioni in background. Più nello specifico, per le app in background:
    • [C-0-4] DEVONO interrompere l'esecuzione dei callback registrati dall'app per ricevere gli output da GnssMeasurement e GnssNavigationMessage.
    • [C-0-5] DEVONO limitare la frequenza degli aggiornamenti forniti all'app tramite la classe API LocationManager o il metodo WifiManager.startScan().
    • [C-0-6] Se l'app ha come target il livello API 25 o versioni successive, NON DEVE consentire la registrazione di broadcast receiver per le trasmissioni implicite degli intent Android standard nel file manifest dell'app, a meno che l'intent di trasmissione non richieda un'autorizzazione "signature" o "signatureOrSystem" protectionLevel o non sia presente nell'elenco delle esenzioni.
    • [C-0-7] Se l'app ha come target il livello API 25 o versioni successive, DEVE interrompere i servizi in background dell'app, proprio come se l'app avesse chiamato il metodo stopSelf() dei servizi, a meno che l'app non sia inserita in una lista consentita temporanea per gestire un'attività visibile all'utente.
    • [C-0-8] Se l'app ha come target il livello API 25 o versioni successive, DEVE rilasciare i wakelock detenuti dall'app.

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

3.6. Spazi dei nomi API

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

  • java.*
  • javax.*
  • sun.*
  • android.*
  • com.android.*

ovvero:

  • [C-0-1] NON DEVE modificare le API esposte pubblicamente sulla piattaforma Android modificando le firme di metodi o classi o rimuovendo classi o campi di classe.
  • [C-0-2] NON DEVE aggiungere elementi esposti pubblicamente (ad esempio classi o interfacce oppure campi o metodi a classi o interfacce esistenti) o API di test o di sistema alle API negli spazi dei nomi precedenti. Un "elemento esposto pubblicamente" è qualsiasi costrutto non decorato con l'indicatore "@hide" come utilizzato nel codice sorgente di Android upstream.

Gli implementatori dei dispositivi POSSONO modificare l'implementazione sottostante delle API, ma queste modifiche:

  • [C-0-3] NON DEVE influire sul comportamento dichiarato e sulla firma in linguaggio Java di qualsiasi API esposta pubblicamente.
  • [C-0-4] NON DEVE essere pubblicizzato o altrimenti esposto agli sviluppatori.

Tuttavia, gli implementatori dei dispositivi POSSONO aggiungere API personalizzate al di fuori dello spazio dei nomi Android standard, ma le API personalizzate:

  • [C-0-5] NON DEVE trovarsi in uno spazio dei nomi di proprietà di un'altra organizzazione o che fa riferimento a un'altra organizzazione. Ad esempio, gli implementatori di dispositivi NON DEVONO aggiungere API al namespace com.google.* o a uno simile: solo Google può farlo. Analogamente, Google NON DEVE aggiungere API ai namespace di altre aziende.
  • [C-0-6] DEVE essere pacchettizzato in una libreria condivisa Android in modo che solo le app che le utilizzano esplicitamente (tramite il meccanismo <uses-library>) siano interessate dall'aumento dell'utilizzo di memoria di queste API.

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

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

3.7. Compatibilità di runtime

Implementazioni dei dispositivi:

  • [C-0-1] DEVE supportare il formato Dalvik Executable (DEX) completo e la semantica e le specifiche del bytecode Dalvik.

  • [C-0-2] È NECESSARIO configurare i runtime Dalvik per allocare la memoria in conformità con la piattaforma Android upstream e come specificato dalla tabella seguente. (consulta la sezione 7.1.1 per le definizioni delle dimensioni e della densità dello schermo).

  • DEVE utilizzare Android RunTime (ART), l'implementazione upstream di riferimento del formato eseguibile Dalvik e il sistema di gestione dei pacchetti dell'implementazione di riferimento.

  • DOVREBBE eseguire test di fuzz in varie modalità di esecuzione e architetture di destinazione per garantire la stabilità del runtime. Consulta JFuzz e DexFuzz sul sito web di Android Open Source Project.

Tieni presente che i valori di memoria specificati di seguito sono considerati valori minimi e le implementazioni dei dispositivi POTREBBERO allocare più memoria per applicazione.

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

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

Android include un'applicazione Avvio app (schermata Home) e il supporto di applicazioni di terze parti per sostituire l'Avvio app del dispositivo (schermata Home).

Se le implementazioni del dispositivo consentono ad applicazioni di terze parti di sostituire la schermata Home del dispositivo, queste:

  • [C-1-1] È OBBLIGATORIO dichiarare la funzionalità della piattaforma android.software.home_screen.
  • [C-1-2] DEVE restituire l'oggetto AdaptiveIconDrawable quando l'applicazione di terze parti utilizza il tag <adaptive-icon> per fornire la propria icona e vengono chiamati i metodi PackageManager per recuperare le icone.

Se le implementazioni dei dispositivi includono un Avvio app predefinito che supporta il bloccaggio delle scorciatoie in-app, devono:

Al contrario, se le implementazioni dei dispositivi non supportano il bloccaggio delle scorciatoie all'interno dell'app:

Se le implementazioni del dispositivo implementano un Avvio app predefinito che fornisce un accesso rapido alle scorciatoie aggiuntive fornite dalle app di terze parti tramite l'API ShortcutManager, devono:

  • [C-4-1] DEVE supportare tutte le funzionalità delle scorciatoie documentate (ad es. scorciatoie statiche e dinamiche, scorciatoie bloccate) e implementare completamente le API della classe API ShortcutManager.

Se le implementazioni del dispositivo includono un'app Avvio app predefinita che mostra i badge per le icone delle app:

  • [C-5-1] DEVE rispettare il metodo dell'API NotificationChannel.setShowBadge(). In altre parole, mostra un'affordance visiva associata all'icona dell'app se il valore è impostato su true e non mostrare alcun schema di badge per l'icona dell'app quando tutti i canali di notifica dell'app hanno impostato il valore su true.false
  • PUÒ sostituire i badge delle icone delle app con il proprio schema di badge proprietario quando le applicazioni di terze parti indicano il supporto dello schema di badge proprietario tramite l'utilizzo di API proprietarie, ma DEVE utilizzare le risorse e i valori forniti tramite le API dei badge di notifica descritte nell'SDK, come le API Notification.Builder.setNumber() e Notification.Builder.setBadgeIconType().

3.8.2. Widget

Android supporta i widget di app di terze parti definendo un tipo di componente e un'API e un ciclo di vita corrispondenti che consentono alle applicazioni di esporre un "AppWidget" all'utente finale.

Se le implementazioni dei dispositivi supportano i widget di app di terze parti:

  • [C-1-1] È OBBLIGATORIO dichiarare il supporto della funzionalità della piattaforma android.software.app_widgets.
  • [C-1-2] DEVE includere il supporto integrato per AppWidget ed esporre funzionalità dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere AppWidget direttamente all'interno del programma di avvio.
  • [C-1-3] DEVE essere in grado di eseguire il rendering di widget di dimensioni 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.
  • POTREBBE supportare i widget delle applicazioni nella schermata di blocco.

Se le implementazioni dei dispositivi supportano i widget di app di terze parti e il fissaggio delle scorciatoie all'interno dell'app, devono:

3.8.3. Notifiche

Android include le API Notification e NotificationManager che consentono agli sviluppatori di app di terze parti di notificare agli utenti eventi importanti e attirare la loro attenzione utilizzando i componenti hardware (ad es. suoni, vibrazioni e luce) e le funzionalità software (ad es. barra delle notifiche, barra di sistema) del dispositivo.

3.8.3.1. Presentazione delle notifiche

Se le implementazioni dei dispositivi consentono alle app di terze parti di inviare notifiche agli utenti su eventi importanti, queste:

  • [C-1-1] DEVE supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK, e, nella misura del possibile, con l'hardware di implementazione del dispositivo. Ad esempio, se l'implementazione di un dispositivo include un vibratore, DEVE implementare correttamente le API di vibrazione. Se l'implementazione di un dispositivo non dispone di hardware, le API corrispondenti DEVONO essere implementate come no-op. Questo comportamento è descritto in maggiore dettaglio nella sezione 7.
  • [C-1-2] DEVONO eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) previste nelle API o nella guida allo stile delle icone della barra di stato/sistema, anche se POSSONO offrire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'implementazione di riferimento di Android Open Source.
  • [C-1-3] DEVE rispettare e implementare correttamente i comportamenti descritti per le API per aggiornare, rimuovere e raggruppare le notifiche.
  • [C-1-4] DEVE fornire il comportamento completo dell'API NotificationChannel documentato nell'SDK.
  • [C-1-5] DEVE fornire all'utente la possibilità di bloccare e modificare la notifica di una determinata app di terze parti per ogni livello di canale e pacchetto di app.
  • [C-1-6] È NECESSARIO anche fornire all'utente un'affordance per visualizzare i canali di notifica eliminati.
  • DOVREBBE supportare le notifiche avanzate.
  • DOVREBBE presentare alcune notifiche con priorità più elevata come notifiche in evidenza.
  • DOVREBBE avere un'affordance per consentire all'utente di posticipare le notifiche.
  • PUO' gestire solo la visibilità e la tempistica in cui le app di terze parti possono inviare notifiche agli utenti di eventi importanti per ridurre i problemi di sicurezza, come la distrazione del conducente.

Se le implementazioni dei dispositivi supportano le notifiche avanzate:

  • [C-2-1] DEVI utilizzare le risorse esatte come fornite tramite la classe API Notification.Style e i relativi sottoclassi per gli elementi della risorsa presentati.
  • DEVE presentare tutti gli elementi della risorsa (ad es. icona, titolo e testo di riepilogo) definiti nella classe API Notification.Style e nei relativi sottoclassi.

Se le implementazioni dei dispositivi supportano le notifiche in primo piano:

  • [C-3-1] DEVE utilizzare la visualizzazione e le risorse delle notifiche in primo piano come descritto nella classe dell'API Notification.Builder quando vengono presentate notifiche in primo piano.
3.8.3.2. Servizio di listener di notifiche

Android include le API NotificationListenerService che consentono alle app (una volta attivate esplicitamente dall'utente) di ricevere una copia di tutte le notifiche man mano che vengono pubblicate o aggiornate.

Se le implementazioni dei dispositivi segnalano il flag della funzionalità android.hardware.ram.normal:

  • [C-1-1] DEVE aggiornare correttamente e tempestivamente le notifiche nella loro interezza su tutti i servizi di ascolto installati e abilitati dall'utente, inclusi tutti i metadati associati all'oggetto Notification.
  • [C-1-2] DEVE rispettare la chiamata all'API snoozeNotification(), ignorare la notifica ed eseguire un callback dopo la durata del posticipo impostata nella chiamata all'API.

Se le implementazioni del dispositivo offrono all'utente la possibilità di posticipare le notifiche, devono:

  • [C-2-1] DEVE riflettere correttamente lo stato della notifica posticipata tramite le API standard come NotificationListenerService.getSnoozedNotifications().
  • [C-2-2] È OBBLIGATORIO rendere disponibile questa funzionalità per posticipare le notifiche di ogni app di terze parti installata, a meno che non provengano da servizi persistenti/in primo piano.
3.8.3.3. DND (Non disturbare)

Se le implementazioni dei dispositivi supportano la funzionalità Non disturbare:

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

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

  • Le implementazioni dei dispositivi Android DEVONO includere la ricerca globale, un'interfaccia utente di ricerca singola, condivisa e a livello di sistema in grado di fornire suggerimenti in tempo reale in risposta all'input dell'utente.

Se le implementazioni dei dispositivi implementano l'interfaccia di ricerca globale:

  • [C-1-1] DEVE 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 la ricerca globale:

  • Il comportamento predefinito DOVREBBE essere la visualizzazione di risultati e suggerimenti del motore di ricerca web.

Android include anche le API Assist per consentire alle applicazioni di scegliere quante informazioni del contesto corrente devono essere condivise con l'assistente sul dispositivo.

Se le implementazioni dei dispositivi supportano l'azione di assistenza, devono:

  • [C-2-1] DEVE indicare chiaramente all'utente finale quando il contesto viene condiviso, in uno dei seguenti modi:
    • Ogni volta che l'app di assistenza accede al contesto, viene visualizzata una luce bianca intorno ai bordi dello schermo che soddisfa o supera la durata e la luminosità dell'implementazione del progetto open source Android.
    • Per l'app di assistenza preinstallata, fornire all'utente un'affordance a meno di due navigazioni dal menu delle impostazioni dell'app di assistenza e dell'input vocale predefinito e condividere il contesto solo quando l'app di assistenza viene invocata esplicitamente dall'utente tramite una hotword o l'input della chiave di navigazione dell'assistente.
  • [C-2-2] L'interazione designata per avviare l'app di assistenza come descritto nella sezione 7.2.3 DEVE avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService o un'attività che gestisce l'intent ACTION_ASSIST.
  • [SR] È FORTEMENTE CONSIGLIATO di utilizzare la pressione prolungata sul tasto HOME come interazione designata.

3.8.5. Avvisi e popup

Le applicazioni possono utilizzare l'API Toast per mostrare all'utente finale brevi stringhe non modali che scompaiono dopo un breve periodo di tempo e l'API di tipo di finestra TYPE_APPLICATION_OVERLAY per visualizzare finestre di avviso come overlay su altre app.

Se le implementazioni dei dispositivi includono uno schermo o un'uscita video, devono:

  • [C-1-1] DEVE fornire all'utente la possibilità di impedire a un'app di visualizzare finestre di avviso che utilizzano TYPE_APPLICATION_OVERLAY . L'implementazione AOSP soddisfa questo requisito grazie ai controlli nella barra delle notifiche.

  • [C-1-2] DEVE rispettare l'API Toast e mostrare i toast 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" e "Material" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare il look and feel del tema Holo come definito dall'SDK Android.

Se le implementazioni dei dispositivi includono uno schermo o un'uscita video, devono:

  • [C-1-1] NON DEVE alterare nessuno degli attributi del tema Holo esposti alle applicazioni.
  • [C-1-2] DEVE supportare la famiglia di temi "Material" e NON DEVE alterare nessuno degli attributi del tema Material o le relative risorse esposte alle applicazioni.

Android include anche una famiglia di temi "Predefinito del dispositivo" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare l'aspetto del tema del dispositivo come definito dall'implementatore del dispositivo.

Android supporta un tema con barre di sistema traslucide, che consente agli sviluppatori di applicazioni di riempire l'area dietro la barra di stato e la barra di navigazione con i contenuti delle app. Per consentire un'esperienza utente coerente in questa configurazione, è importante che lo stile dell'icona della barra di stato venga mantenuto nelle diverse implementazioni del dispositivo.

Se le implementazioni dei dispositivi includono una barra di stato di sistema, devono:

  • [C-2-1] È obbligatorio utilizzare il bianco per le icone di stato del sistema (ad esempio l'intensità del segnale e il livello della batteria) e le notifiche inviate dal sistema, a meno che l'icona non indichi uno stato problematico o un'app non richieda una barra di stato chiara utilizzando il flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
  • [C-2-2] Le implementazioni dei dispositivi Android DEVONO impostare il colore delle icone di stato di sistema su nero (per maggiori dettagli, fai riferimento a R.style) quando un'app richiede una barra di stato chiara.

3.8.7. Sfondi animati

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

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

  • Le implementazioni dei dispositivi in grado di eseguire sfondi animati in modo affidabile come descritto sopra DOVREBBERO implementare gli sfondi animati.

Se le implementazioni dei dispositivi implementano sfondi animati:

  • [C-1-1] È OBBLIGATORIO segnalare il flag della funzionalità della piattaforma android.software.live_wallpaper.

3.8.8. Cambio attività

Il codice sorgente di Android upstream include la schermata di panoramica, un'interfaccia utente a livello di sistema per il passaggio da un'attività all'altra e la visualizzazione delle attività e delle attività a cui è stato eseguito l'accesso di recente utilizzando un'immagine in miniatura dello stato grafico dell'applicazione al momento in cui l'utente ha chiuso l'applicazione per l'ultima volta.

Le implementazioni dei dispositivi, inclusa la chiave di navigazione della funzione Recenti descritta nella sezione 7.2.3, POTREBBERO alterare l'interfaccia.

Se le implementazioni del dispositivo, inclusa la chiave di navigazione della funzione Recenti descritta nella sezione 7.2.3, modificano l'interfaccia:

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

  • POTREBBE mostrare i contenuti recenti affiliati come un gruppo che si sposta insieme.

  • [SR] È FORTEMENTE CONSIGLIATO di utilizzare l'interfaccia utente Android a monte (o un'interfaccia basata su miniature simile) per la schermata Panoramica.

3.8.9. Gestione dell'input

Android include il supporto per la gestione dell'input e per gli editor di metodi di immissione di terze parti.

Se le implementazioni del dispositivo consentono agli utenti di utilizzare metodi di immissione di terze parti sul dispositivo, questi:

  • [C-1-1] DEVE dichiarare la funzionalità della piattaforma android.software.input_methods e supportare le API IME come definito nella documentazione dell'SDK Android.
  • [C-1-2] DEVE fornire un meccanismo accessibile agli utenti per aggiungere e configurare metodi di immissione di terze parti in risposta all'intent android.settings.INPUT_METHOD_SETTINGS.

Se le implementazioni del dispositivo dichiarano il flag della funzionalità android.software.autofill:

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.

3.8.11. Salvaschermo (in precedenza Sogni)

Android include il supporto per i salvaschermo interattivi, precedentemente noti come Sogni. I salvaschermo consentono agli utenti di interagire con le applicazioni quando un dispositivo collegato a una fonte di alimentazione è inattivo o agganciato alla base di ricarica. I dispositivi Android Watch POSSONO implementare i salvaschermo, ma altri tipi di implementazioni dei dispositivi DEVONO includere il supporto dei salvaschermo e fornire un'opzione di impostazioni per consentire agli utenti di configurarli in risposta all'intent android.settings.DREAM_SETTINGS.

3.8.12. Posizione

Se le implementazioni del dispositivo includono un sensore hardware (ad es. GPS) in grado di fornire le coordinate della posizione:

3.8.13. Unicode e carattere

Android include il supporto dei caratteri emoji definiti in Unicode 10.0.

Se le implementazioni dei dispositivi includono uno schermo o un'uscita video, devono:

  • [C-1-1] DEVE essere in grado di eseguire il rendering di questi caratteri emoji in un glifo a colori.
  • [C-1-2] DEVE includere il supporto per:
  • 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 per le lingue disponibili sul dispositivo.
  • Copertura completa di Unicode 7.0 per latino, greco e cirillico, inclusi gli intervalli A, B, C e D estesi latini e tutti i glifi nel blocco dei simboli di valuta di Unicode 7.0.
  • DOVREBBE supportare la tonalità della pelle e le diverse emoji di famiglia come specificato nel report tecnico Unicode n. 51.

Se le implementazioni del dispositivo includono un IME, devono:

  • DEVE fornire all'utente un metodo di inserimento per questi caratteri emoji.

3.8.14. Multi-finestra

Se le implementazioni dei dispositivi hanno la capacità di mostrare più attività contemporaneamente:

  • [C-1-1] DEVE implementare queste modalità multi-finestra in conformità con i comportamenti e le API dell'applicazione descritti nella documentazione di supporto della modalità multi-finestra dell'SDK Android e soddisfare i seguenti requisiti:
  • [C-1-2] Le applicazioni possono indicare se sono in grado di operare in modalità multi-finestra nel file AndroidManifest.xml, esplicitamente impostando l'attributo android:resizeableActivity su true o implicitamente impostando targetSdkVersion su un valore maggiore di 24. Le app che impostano esplicitamente questo attributo su false nel file manifest NON DEVONO essere avviate in modalità multifinestra. Le app precedenti con targetSdkVersion < 24 che non hanno impostato questo attributo android:resizeableActivity POSSONO essere avviate in modalità multi-finestra, ma il sistema DEVE fornire un avviso che l'app potrebbe non funzionare come previsto in modalità multi-finestra.
  • [C-1-3] NON DEVE offrire la modalità schermo diviso o a forma libera se l'altezza dello schermo è inferiore a 440 dp e la larghezza dello schermo è inferiore a 440 dp.
  • Le implementazioni dei dispositivi con dimensioni dello schermo xlarge DEVONO supportare la modalità a forma libera.

Se le implementazioni del dispositivo supportano le modalità a più finestre e la modalità schermo diviso:

  • [C-2-1] È obbligatorio precaricare un Avvio app redimensionabile come predefinito.
  • [C-2-2] DEVE ritagliare l'attività agganciata di una finestra multipla a schermo diviso, ma DEVE mostrare alcuni contenuti, se l'app Avvio app è la finestra attiva.
  • [C-2-3] DEVE rispettare i valori AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight dichiarati dell'applicazione di avvio di terze parti e non deve sostituirli durante la visualizzazione di alcuni contenuti dell'attività agganciata.

Se le implementazioni dei dispositivi supportano una o più modalità multi-finestra e la modalità multi-finestra Picture in picture, devono:

  • [C-3-1] DEVE avviare le attività in modalità finestra multipla Picture in Picture quando l'app: * ha come target il livello API 26 o versioni successive e dichiara android:supportsPictureInPicture * ha come target il livello API 25 o versioni precedenti e dichiara sia android:resizeableActivity sia android:supportsPictureInPicture.
  • [C-3-2] DEVE esporre le azioni nella UI di sistema come specificato dall'attività PIP corrente tramite l'API setActions().
  • [C-3-3] DEVE supportare proporzioni maggiori o uguali a 1:2,39 e minori o uguali a 2,39:1, come specificato dall'attività PIP tramite l'API setAspectRatio().
  • [C-3-4] DEVE utilizzare KeyEvent.KEYCODE_WINDOW per controllare la finestra PIP; se la modalità PIP non è implementata, la chiave DEVE essere disponibile per l'attività in primo piano.
  • [C-3-5] DEVE fornire all'utente la possibilità di bloccare la visualizzazione di un'app in modalità PIP; l'implementazione AOSP soddisfa questo requisito grazie ai controlli nella barra delle notifiche.
  • [C-3-6] DEVE allocare una larghezza e un'altezza minime di 108 dp per la finestra PIP e una larghezza minima di 240 dp e un'altezza di 135 dp per la finestra PIP quando Configuration.uiMode è configurato come UI_MODE_TYPE_TELEVISION

3.9. Amministrazione dispositivo

Android include funzionalità che consentono alle applicazioni sensibili alla sicurezza di eseguire funzioni di amministrazione del dispositivo a livello di sistema, ad esempio l'applicazione di criteri per le password o l'esecuzione di una cancellazione dei dati da remoto, tramite l'API Android Device Administration].

Se le implementazioni dei dispositivi implementano l'intera gamma di criteri di amministrazione del dispositivo definiti nella documentazione dell'SDK Android, devono:

  • [C-1-1] È OBBLIGATORIO dichiarare android.software.device_admin.
  • [C-1-2] DEVE supportare il provisioning del proprietario del dispositivo come descritto nella sezione 3.9.1 e nella sezione 3.9.1.1.
  • [C-1-3] DEVE dichiarare il supporto dei profili gestiti tramite il flag della funzionalità android.software.managed_users, tranne quando il dispositivo è configurato in modo da segnalarsi come dispositivo con poca RAM o in modo da allocare lo spazio di archiviazione interno (non rimovibile) come spazio di archiviazione condiviso.

3.9.1 Provisioning del dispositivo

3.9.1.1 Provisioning del proprietario del dispositivo

Se le implementazioni del dispositivo dichiarano android.software.device_admin:

  • [C-1-1] DEVE supportare la registrazione di un client Device Policy (DPC) come app Proprietario dispositivo come descritto di seguito:
  • [C-1-2] NON DEVE impostare un'applicazione (inclusa un'app preinstallata) come app Proprietario dispositivo senza il consenso esplicito o l'azione dell'utente o dell'amministratore del dispositivo.

Se le implementazioni dei dispositivi dichiarano android.software.device_admin, ma includono anche una soluzione di gestione proprietaria del proprietario del dispositivo e forniscono un meccanismo per promuovere un'applicazione configurata nella loro soluzione come "equivalente del proprietario del dispositivo" al "proprietario del dispositivo" standard riconosciuto dalle API DevicePolicyManager standard di Android, devono:

  • [C-2-1] È OBBLIGATORIO disporre di una procedura per verificare che l'app specifica promossa appartenga a una soluzione di gestione dei dispositivi aziendali legittima e che sia già configurata nella soluzione proprietaria per avere i diritti equivalenti a quelli di un "proprietario del dispositivo".
  • [C-2-2] DEVE mostrare la stessa informativa per il consenso del proprietario del dispositivo AOSP del flusso avviato da android.app.action.PROVISION_MANAGED_DEVICE prima di registrare l'applicazione DPC come "proprietario del dispositivo".
  • POTREBBE avere dati utente sul dispositivo prima della registrazione dell'applicazione DPC come "Proprietario del dispositivo".
3.9.1.2 Provisioning dei profili gestiti

Se le implementazioni del dispositivo dichiarano android.software.managed_users:

  • [C-1-1] DEVE implementare le API che consentono a un'applicazione Device Policy Controller (DPC) di diventare il proprietario di un nuovo profilo gestito.

  • [C-1-2] L'esperienza degli utenti durante la procedura di provisioning del profilo gestito (il flusso avviato da android.app.action.PROVISION_MANAGED_PROFILE) DEVE essere in linea con l'implementazione AOSP.

  • [C-1-3] DEVE fornire le seguenti funzionalità per l'utente nelle Impostazioni per indicare all'utente quando una determinata funzionalità di sistema è stata disattivata dal Device Policy Controller (DPC):

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

3.9.2 Assistenza per i profili gestiti

Se le implementazioni del dispositivo dichiarano android.software.managed_users:

  • [C-1-1] DEVE supportare i profili gestiti tramite le API android.app.admin.DevicePolicyManager.
  • [C-1-2] DEVE consentire la creazione di un solo profilo gestito.
  • [C-1-3] È OBBLIGATORIO utilizzare un badge icona (simile al badge di lavoro in upstream AOSP) per rappresentare le applicazioni e i widget gestiti e altri elementi dell'interfaccia utente con badge come Recenti e Notifiche.
  • [C-1-4] DEVE essere visualizzata un'icona di notifica (simile al badge di lavoro in upstream AOSP) per indicare quando l'utente si trova in un'applicazione del profilo gestito.
  • [C-1-5] DEVE mostrare una notifica che indica che l'utente si trova nel profilo gestito se e quando il dispositivo si riattiva (ACTION_USER_PRESENT) e l'applicazione in primo piano si trova nel profilo gestito.
  • [C-1-6] Se esiste un profilo gestito, DEVE essere mostrata un'affordance visiva nel "selettore" di intent per consentire all'utente di inoltrare l'intent dal profilo gestito all'utente principale o viceversa, se abilitato dal Controller dei criteri del dispositivo.
  • [C-1-7] Se esiste un profilo gestito, DEVE esporre le seguenti funzionalità per l'utente principale e per il profilo gestito:
    • Contabilità separata per l'utilizzo di batteria, posizione, dati mobili e spazio di archiviazione per l'utente principale e il profilo gestito.
    • Gestione indipendente delle applicazioni VPN installate nell'utente principale o nel profilo gestito.
    • Gestione indipendente delle applicazioni installate nell'utente principale o nel profilo gestito.
    • Gestione indipendente degli account all'interno dell'utente principale o del profilo gestito.
  • [C-1-8] DEVE garantire che le applicazioni di tastiera, contatti e messaggistica preinstallate possano cercare e trovare le informazioni sull'autore della chiamata dal profilo gestito (se esistente) insieme a quelle del profilo principale, se il Controller dei criteri del dispositivo lo consente.
  • [C-1-9] DEVE garantire che soddisfi tutti i requisiti di sicurezza applicabili a un dispositivo con più utenti abilitati (vedi sezione 9.5), anche se il profilo gestito non viene conteggiato come un altro utente oltre all'utente principale.
  • [C-1-10] DEVE supportare la possibilità di specificare una schermata di blocco separata che soddisfi i seguenti requisiti per concedere l'accesso alle app in esecuzione in un profilo gestito.
    • Le implementazioni del dispositivo DEVONO rispettare l'intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrare un'interfaccia per configurare una credenziale della schermata di blocco separata per il profilo gestito.
    • Le credenziali della schermata di blocco del profilo gestito DEVONO utilizzare gli stessi meccanismi di archiviazione e gestione delle credenziali del profilo principale, come descritto sul sito del progetto open source Android
    • I criteri delle password del DPC DEVONO essere applicati solo alle credenziali della schermata di blocco del profilo gestito, a meno che non vengano richiamati nell'istanza DevicePolicyManager restituita da getParentProfileInstance.
  • Quando i contatti del profilo gestito vengono visualizzati nel registro chiamate preinstallato, nell'interfaccia utente durante la chiamata, nelle notifiche di chiamate in corso e perse, nelle app di contatti e messaggistica, DEVONO essere contrassegnati con lo stesso badge utilizzato per indicare le applicazioni del profilo gestito.

3.10. Accessibilità

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

Se le implementazioni dei dispositivi supportano servizi di accessibilità di terze parti:

  • [C-1-1] DEVE fornire un'implementazione del framework di accessibilità di Android come descritto nella documentazione dell'SDK delle API di accessibilità.
  • [C-1-2] DEVE generare eventi di accessibilità e inviare il AccessibilityEvent appropriato a tutte le implementazioni di AccessibilityService registrate, come documentato nell'SDK.
  • [C-1-3] DEVE rispettare l'intenzione di android.settings.ACCESSIBILITY_SETTINGS di fornire un meccanismo accessibile agli utenti per attivare e disattivare i servizi di accessibilità di terze parti insieme ai servizi di accessibilità preinstallati.
  • [C-1-4] DEVE aggiungere un pulsante nella barra di navigazione del sistema che consenta all'utente di controllare il servizio di accessibilità quando i servizi di accessibilità abilitati dichiarano AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Tieni presente che per le implementazioni dei dispositivi senza barra di navigazione di sistema, questo requisito non è applicabile, ma le implementazioni dei dispositivi DOVREBBERO fornire all'utente un'affordance per controllare questi servizi di accessibilità.

Se le implementazioni del dispositivo includono servizi di accessibilità precaricati, questi:

  • [C-2-1] DEVE implementare questi servizi di accessibilità precaricati come app compatibili con il riavvio diretto quando lo spazio di archiviazione dei dati è criptato con la crittografia basata su file (FBE).
  • DOVREBBE fornire un meccanismo nel flusso di configurazione out-of-box per consentire agli utenti di attivare i servizi di accessibilità pertinenti, nonché opzioni per regolare le dimensioni dei caratteri, le dimensioni del display e i gesti di ingrandimento.

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.

Se le implementazioni del dispositivo segnalano la funzionalità android.hardware.audio.output:

Se le implementazioni dei dispositivi supportano l'installazione di motori TTS di terze parti:

  • [C-2-1] DEVE fornire all'utente la possibilità di selezionare un motore TTS da utilizzare a livello di sistema.

3.12. TV Input Framework

L'Android Television Input Framework (TIF) semplifica l'importazione di contenuti dal vivo sui dispositivi Android TV. TIF fornisce un'API standard per creare moduli di input che controllano i dispositivi Android TV.

Se le implementazioni del dispositivo supportano TIF:

  • [C-1-1] È OBBLIGATORIO dichiarare la funzionalità della piattaforma android.software.live_tv.
  • [C-1-2] DEVE precaricare un'applicazione TV (app TV) e soddisfare tutti i requisiti descritti nella sezione 3.12.1.

3.12.1. App TV

Se le implementazioni del dispositivo supportano TIF:

  • [C-1-1] L'app TV DEVE fornire strutture per installare e utilizzare i canali TV e soddisfare i seguenti requisiti:

L'app TV richiesta per le implementazioni dei dispositivi Android che dichiarano il flag della funzionalità android.software.live_tv DEVE soddisfare i seguenti requisiti:

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

Android Open Source Project fornisce un'implementazione dell'app TV che soddisfa i requisiti sopra indicati.

3.12.1.1. Guida elettronica ai programmi

Se le implementazioni del dispositivo supportano TIF:

  • [C-1-1] DEVE mostrare un overlay informativo e interattivo, che DEVE includere una guida elettronica dei programmi (EPG) generata dai valori nei campi TvContract.Programs.
  • [C-1-2] Al cambio di canale, le implementazioni del dispositivo DEVONO mostrare i dati EPG del programma attualmente in riproduzione.
  • [SR] È MOLTO CONSIGLIATO che l'EPG mostri gli input installati e quelli di terze parti con la stessa evidenza. L'EPG NON DEVE mostrare gli ingressi di terze parti a più di una singola azione di navigazione dagli ingressi installati nell'EPG.
  • L'EPG DEVE mostrare le informazioni di tutti gli ingressi installati e di terze parti.
  • L'EPG PUÒ fornire una separazione visiva tra gli ingressi installati e quelli di terze parti.
3.12.1.2. Navigazione

Se le implementazioni del dispositivo supportano TIF:

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

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

  • DOVREBBE trasmettere gli eventi chiave agli ingressi HDMI tramite CEC.

3.12.1.3. Collegamento delle app all'ingresso TV

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

3.12.1.4. Spostamento temporale

Se le implementazioni del dispositivo supportano TIF:

  • [SR] MOLTO CONSIGLIATO supportare il time shifting, che consente all'utente di mettere in pausa e riprendere i contenuti in diretta.
  • DOVREBBE fornire all'utente un modo per mettere in pausa e riprendere il programma attualmente in riproduzione, se il fuso orario per quel programma è disponibile.
3.12.1.5. Registrazione TV

Se le implementazioni del dispositivo supportano TIF:

  • [SR] MOLTO CONSIGLIATO per supportare la registrazione TV.
  • Se l'ingresso della TV supporta la registrazione e la registrazione di un programma non è vietata, l'EPG POTREBBE fornire un modo per registrare un programma.

3.13. Impostazioni rapide

Android fornisce un componente dell'interfaccia utente Impostazioni rapide che consente di accedere rapidamente alle azioni utilizzate di frequente o necessarie con urgenza.

Se le implementazioni del dispositivo includono un componente dell'interfaccia utente delle Impostazioni rapide:

  • [C-1-1] DEVE consentire all'utente di aggiungere o rimuovere i riquadri forniti tramite le API quicksettings da un'app di terze parti.
  • [C-1-2] NON DEVE aggiungere automaticamente un riquadro di un'app di terze parti direttamente alle Impostazioni rapide.
  • [C-1-3] DEVE mostrare tutti i riquadri aggiunti dall'utente da app di terze parti insieme ai riquadri delle impostazioni rapide forniti dal sistema.

3.14. UI multimediale

Se le implementazioni dei dispositivi includono il framework UI che supporta le app di terze parti che dipendono da MediaBrowser e MediaSession:

3.15. App istantanee

Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti:

  • [C-0-1] Alle app istantanee DEVONO essere concesse solo le autorizzazioni con android:protectionLevel impostato su "ephemeral".
  • [C-0-2] Le app istantanee NON DEVONO interagire con le app installate tramite intent impliciti, a meno che non sia vera una delle seguenti condizioni:
    • Il filtro pattern intent del componente è esposto e ha CATEGORY_BROWSABLE
    • L'azione è una di ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • Il target è esposto esplicitamente con android:visibleToInstantApps
  • [C-0-3] Le app istantanee NON DEVONO interagire esplicitamente con le app installate, a meno che il componente non sia esposto tramite android:visibleToInstantApps.
  • [C-0-4] Le app installate NON DEVONO vedere i dettagli delle app istantanee sul dispositivo, a meno che l'app istantanea non si connetta esplicitamente all'applicazione installata.

3.16. Accoppiamento dispositivo complementare

Android include il supporto per l'accoppiamento dei dispositivi complementari per gestire in modo più efficace l'associazione con i dispositivi complementari e fornisce l'API CompanionDeviceManager per consentire alle app di accedere a questa funzionalità.

Se le implementazioni dei dispositivi supportano la funzionalità di accoppiamento del dispositivo complementare:

  • [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità FEATURE_COMPANION_DEVICE_SETUP .
  • [C-1-2] DEVI assicurarti che le API nel pacchetto android.companion siano completamente implementate.
  • [C-1-3] DEVE fornire all'utente le funzionalità necessarie per selezionare/confermare che un dispositivo complementare è presente e operativo.

4. Compatibilità con il pacchettizzazione delle applicazioni

Implementazioni dei dispositivi:

  • [C-0-1] DEVE essere in grado di installare ed eseguire file ".apk" Android come generati dallo strumento "aapt" incluso nell'SDK Android ufficiale.
  • Poiché il requisito sopra indicato può essere impegnativo, per le implementazioni dei dispositivi è CONSIGLIATO utilizzare le implementazioni del sistema di gestione dei pacchetti dell'implementazione di riferimento AOSP.
  • [C-0-2] DEVE supportare la verifica dei file ".apk" utilizzando lo schema di firma dell'APK v2 e la firma JAR.
  • [C-0-3] NON DEVE estendere i formati .apk, Android Manifest, bytecode Dalvik o bytecode RenderScript in modo da impedire l'installazione e l'esecuzione corretta di questi file su altri dispositivi compatibili.
  • [C-0-4] NON DEVE consentire ad app diverse dall'attuale "installatore registrato" del pacchetto di disinstallare l'app in modo silenzioso senza alcuna richiesta, come documentato nell'SDK per l'autorizzazione DELETE_PACKAGE. Le uniche eccezioni sono l'app di verifica del pacchetto di sistema che gestisce l'intent PACKAGE_NEEDS_VERIFICATION e l'app di gestione dello spazio di archiviazione che gestisce l'intent ACTION_MANAGE_STORAGE.

Le implementazioni dei dispositivi NON DEVONO installare pacchetti di applicazioni da origini sconosciute, a meno che l'app che richiede l'installazione non soddisfi tutti i seguenti requisiti:

  • DEVE dichiarare l'autorizzazione REQUEST_INSTALL_PACKAGES o avere android:targetSdkVersion impostato su 24 o meno.
  • È OBBLIGATORIO che l'utente abbia concesso l'autorizzazione per installare app da origini sconosciute.

Le implementazioni dei dispositivi DEVONO avere un'attività che gestisce l'intent android.settings.MANAGE_UNKNOWN_APP_SOURCES. DOVREBBERO fornire all'utente la possibilità di concedere/revocare l'autorizzazione per installare app da origini sconosciute per ogni applicazione, ma POSSONO scegliere di implementare questa operazione come no-op e restituire RESULT_CANCELED per startActivityForResult(), se l'implementazione del dispositivo non vuole consentire agli utenti di fare questa scelta. Tuttavia, anche in questi casi, DOVREBBE indicare all'utente il motivo per cui non viene presentata questa scelta.

5. Compatibilità multimediale

Implementazioni dei dispositivi:

  • [C-0-1] DEVE supportare i formati multimediali, gli encoder, i decodificatori, i tipi di file e i formati dei contenitori definiti nella sezione 5.1 per ogni codec dichiarato da MediaCodecList.
  • [C-0-2] DEVE dichiarare e segnalare il supporto degli encoder e dei decodificatori disponibili per le applicazioni di terze parti tramite MediaCodecList.
  • [C-0-3] DEVE essere in grado di decodificare e mettere a disposizione delle app di terze parti tutti i formati che può codificare. Sono inclusi tutti i bitstream generati dai suoi codificatori e i profili registrati nel suo CamcorderProfile.

Implementazioni dei dispositivi:

  • DEVONO mirare a una latenza minima del codec, in altre parole, devono
    • NON DEVE consumare e memorizzare i buffer di input e restituire i buffer di input solo dopo l'elaborazione.
    • NON DEVE conservare i buffer decodificati per più tempo di quanto specificato dallo standard (ad es. SPS).
    • NON DEVE conservare i buffer codificati più a lungo di quanto richiesto dalla struttura GOP.

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

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

5.1. Codec multimediali

5.1.1. Codifica audio

Per ulteriori dettagli, consulta la sezione 5.1.3. Dettagli codec audio.

Se le implementazioni del dispositivo dichiarano android.hardware.microphone, DEVONO supportare la seguente codifica audio:

  • [C-1-1] PCM/WAVE

5.1.2. Decodifica audio

Per ulteriori dettagli, consulta la sezione 5.1.3. Dettagli codec audio.

Se le implementazioni dei dispositivi dichiarano il supporto della funzionalità android.hardware.audio.output:

  • [C-1-1] Profilo MPEG-4 AAC (AAC LC)
  • [C-1-2] Profilo MPEG-4 HE AAC (AAC+)
  • [C-1-3] Profilo MPEG-4 HE AACv2 (AAC+ migliorato)
  • [C-1-4] AAC ELD (AAC a basso ritardo migliorato)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE
  • [C-1-10] Opus

Se le implementazioni del dispositivo supportano la decodifica dei buffer di input AAC degli stream multicanale (ovvero più di due canali) in PCM tramite il decodificatore audio AAC predefinito nell'API android.media.MediaCodec, DEVE essere supportato quanto segue:

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

5.1.3. Dettagli sui codec audio

Formato/codec Dettagli Tipi di file/formati contenitore supportati
Profilo MPEG-4 AAC
(AAC LC) 		Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 8 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC non compresso ADTS (.aac, ADIF non supportato)
  • MPEG-TS (.ts, non cercabile)
Profilo MPEG-4 HE AAC (AAC+) Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.
Profilo MPEG-4 HE AACv2
(AAC+ avanzato) 		Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.
AAC ELD (AAC a bassa latenza migliorata) Supporto per contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.
AMR-NB Da 4,75 a 12,2 Kbps campionati a 8 kHz 3GPP (.3gp)
AMR-WB 9 velocità da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz
FLAC Mono/stereo (nessun multicanale). Frequenze di campionamento fino a 48 kHz (ma fino a 44,1 kHz è CONSIGLIATO sui dispositivi con uscita a 44,1 kHz, poiché il downsampler da 48 a 44,1 kHz non include un filtro passa basso). CONSIGLIATO 16 bit; nessun dither applicato per 24 bit. Solo FLAC (.flac)
MP3 Mono/stereo 8-320 Kbps costante (CBR) o con velocità in bit variabile (VBR) MP3 (.mp3)
MIDI Tipo MIDI 0 e 1. Versioni 1 e 2 di DLS. XMF e Mobile XMF. Supporto per i formati delle sveglie RTTTL/RTX, OTA e iMelody
  • Tipo 0 e 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0 e versioni successive)
PCM/WAVE 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 Matroska (.mkv), Ogg(.ogg)

5.1.4. Codifica delle immagini

Per ulteriori dettagli, consulta la sezione 5.1.6. Dettagli codec immagine.

Le implementazioni dei dispositivi DEVONO supportare la codifica delle seguenti immagini:

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP

5.1.5. Decodifica delle immagini

Per ulteriori dettagli, consulta la sezione 5.1.6. Dettagli codec immagine.

Le implementazioni dei dispositivi DEVONO supportare la codifica della seguente decodifica delle immagini:

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Non elaborato

5.1.6. Dettagli sui codec delle immagini

Formato/codec Dettagli Tipi di file/formati contenitore supportati
JPEG Base+progressiva JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
Raw - Una cruda verità ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.7. Codec video

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

Se le implementazioni del dispositivo includono un decodificatore o un codificatore video:

  • [C-1-1] I codec video DEVONO supportare dimensioni dei buffer di byte di output e di input che supportino il frame compresso e non compresso più grande possibile, come stabilito dallo standard e dalla configurazione, ma che non prevedano anche una sovraallocazione.

  • [C-1-2] I codificatori e decodificatori video DEVONO supportare il formato di colore flessibile YUV420 (COLOR_FormatYUV420Flexible).

Se le implementazioni dei dispositivi pubblicizzano il supporto del profilo HDR tramite Display.HdrCapabilities:

  • [C-2-1] DEVE supportare l'analisi e la gestione dei metadati statici HDR.

Se le implementazioni dei dispositivi pubblicizzano il supporto dell'aggiornamento interno tramite FEATURE_IntraRefresh nella classe MediaCodecInfo.CodecCapabilities:

  • [C-3-1]DEVE supportare i periodi di aggiornamento nell'intervallo di 10-60 frame e funzionare con precisione entro il 20% del periodo di aggiornamento configurato.

5.1.8. Elenco dei codec video

Formato/codec Dettagli Tipi di file supportati/
Formati contenitore
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC Per maggiori dettagli, consulta le sezioni 5.2 e 5.3
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, solo audio AAC, non cercabile, Android 3.0 e versioni successive)
H.265 HEVC Per informazioni dettagliate, consulta la sezione 5.3 MPEG-4 (.mp4)
MPEG-2 Profilo principale MPEG2-TS
MPEG-4 SP 3GPP (.3gp)
VP8 Per maggiori dettagli, consulta le sezioni 5.2 e 5.3
VP9 Per informazioni dettagliate, consulta la sezione 5.3

5.2. Codifica video

Se le implementazioni dei dispositivi supportano qualsiasi codificatore video e lo rendono disponibile per le app di terze parti:

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

Se le implementazioni dei dispositivi includono un display integrato con una diagonale di almeno 6,35 cm o una porta di uscita video o dichiarano il supporto di una videocamera tramite il flag della funzionalità android.hardware.camera.any, devono:

  • [C-1-1] DEVE includere il supporto di almeno uno degli encoder video VP8 o H.264 e renderlo disponibile per le applicazioni di terze parti.
  • DOVREBBE supportare i codificatori video VP8 e H.264 e renderli disponibili per le applicazioni di terze parti.

Se le implementazioni dei dispositivi supportano uno degli encoder video H.264, VP8, VP9 o HEVC e lo rendono disponibile per le applicazioni di terze parti, devono:

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

Se le implementazioni dei dispositivi supportano il codificatore video MPEG-4 SP e lo rendono disponibile per le app di terze parti, devono:

  • DOVREBBE supportare le velocità in bit configurabili dinamicamente per il codificatore supportato.

5.2.1. H.263

Se le implementazioni dei dispositivi supportano i codificatori H.263 e li rendono disponibili per le app di terze parti, devono:

  • [C-1-1] DEVE supportare il livello 45 del profilo di baseline.
  • DOVREBBE supportare le velocità in bit configurabili dinamicamente per il codificatore supportato.

5.2.2. H-264

Se le implementazioni dei dispositivi supportano il codec H.264:

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

Se le implementazioni dei dispositivi segnalano il supporto della codifica H.264 per i video con risoluzione 720p o 1080p tramite le API multimediali:

  • [C-2-1] DEVE supportare i profili di codifica riportati nella tabella seguente.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p
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

5.2.3. VP8

Se le implementazioni dei dispositivi supportano il codec VP8:

  • [C-1-1] DEVE supportare i profili di codifica video SD.
  • DEVE supportare i seguenti profili di codifica video HD (alta definizione).
  • DOVREBBE supportare la scrittura di file Matroska WebM.
  • DEBBA utilizzare un codec VP8 hardware che soddisfi i requisiti di codifica hardware RTC del progetto WebM, per garantire una qualità accettabile dei servizi di streaming video web e di videoconferenza.

Se le implementazioni dei dispositivi segnalano il supporto della codifica VP8 per i video con risoluzione 720p o 1080p tramite le API multimediali:

  • [C-2-1] DEVE supportare i profili di codifica riportati nella tabella seguente.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p
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

5.2.4. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

  • DOVREBBE supportare la scrittura di file Matroska WebM.

5.3. Decodifica video

Se le implementazioni dei dispositivi supportano i codec VP8, VP9, H.264 o H.265:

  • [C-1-1] DEVE supportare il passaggio dinamico della risoluzione video e della frequenza frame tramite le API Android standard all'interno dello stesso stream per tutti i codec VP8, VP9, H.264 e H.265 in tempo reale e fino alla risoluzione massima supportata da ciascun codec sul dispositivo.

Se le implementazioni dei dispositivi dichiarano il supporto del decodificatore Dolby Vision tramite HDR_TYPE_DOLBY_VISION:

  • [C-2-1] È OBBLIGATORIO fornire un'apposita app per l'estrazione di file compatibile con Dolby Vision.
  • [C-2-2] DEVE mostrare correttamente i contenuti Dolby Vision sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).
  • [C-2-3] L'indice traccia dei livelli base compatibili con le versioni precedenti (se presenti) DEVE essere uguale all'indice traccia del livello Dolby Vision combinato.

5.3.1. MPEG-2

Se le implementazioni dei dispositivi supportano i decodificatori MPEG-2:

  • [C-1-1] DEVE supportare il profilo principale di alto livello.

5.3.2. H.263

Se le implementazioni dei dispositivi supportano i decodificatori H.263:

  • [C-1-1] DEVE supportare il profilo di riferimento di livello 30 e 45.

5.3.3. MPEG-4

Se le implementazioni dei dispositivi con decodificatori MPEG-4:

  • [C-1-1] DEVE supportare il profilo semplice di livello 3.

5.3.4. H.264

Se le implementazioni dei dispositivi supportano i decodificatori H.264:

  • [C-1-1] DEVE supportare il profilo principale di livello 3.1 e il profilo di baseline. Il supporto di ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) e RS (Redundant Slices) è FACOLTATIVO.
  • [C-1-2] DEVE essere in grado di decodificare i video con i profili SD (definizione standard) elencati nella tabella seguente e codificati con il profilo di base e il profilo principale di livello 3.1 (incluso 720p30).
  • DEVE essere in grado di decodificare i video con i profili HD (alta definizione) come indicato nella tabella seguente.

Se l'altezza indicata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, le implementazioni del dispositivo:

  • [C-2-1] DEVE supportare i profili di codifica video HD 720p riportati nella tabella seguente.
  • [C-2-2] DEVE supportare i profili di codifica video HD 1080p riportati nella tabella seguente.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p
Risoluzione video 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
Frequenza fotogrammi video 30 fps 30 fps 60 FPS 30 fps (60 fpsTelevisore)
Velocità in bit video 800 kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5. H.265 (HEVC)

Se le implementazioni dei dispositivi supportano il codec H.265:

  • [C-1-1] DEVE supportare il livello principale del profilo principale di Livello 3 e i profili di decodifica video SD come indicato nella tabella seguente.
  • DEVE supportare i profili di decodifica HD come indicato nella tabella seguente.
  • [C-1-2] DEVE supportare i profili di decodifica HD come indicato nella tabella seguente se è presente un decodificatore hardware.

Se l'altezza indicata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video:

  • [C-2-1] Le implementazioni dei dispositivi DEVONO supportare almeno una decodifica H.265 o VP9 dei profili 720, 1080 e UHD.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p UHD
Risoluzione video 352 x 288 px 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
Frequenza fotogrammi video 30 fps 30 fps 30 fps 30/60 f/s (60 f/sTelevisore con decodifica hardware H.265) 60 FPS
Velocità in bit video 600 kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.3.6. VP8

Se le implementazioni dei dispositivi supportano il codec VP8:

  • [C-1-1] DEVE supportare i profili di decodifica SD riportati nella tabella seguente.
  • DEBBA utilizzare un codec VP8 hardware che soddisfi i requisiti.
  • DEVE supportare i profili di decodifica HD riportati nella tabella seguente.

Se l'altezza indicata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, allora:

  • [C-2-1] Le implementazioni dei dispositivi DEVONO supportare i profili 720p indicati nella tabella seguente.
  • [C-2-2] Le implementazioni dei dispositivi DEVONO supportare i profili 1080p indicati nella tabella seguente.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p
Risoluzione video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Frequenza fotogrammi video 30 fps 30 fps 30 fps (60 fpsTelevisore) 30 (60 fpsTelevisione)
Velocità in bit video 800 kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

  • [C-1-1] DEVE supportare i profili di decodifica video SD come indicato nella tabella seguente.
  • DEVE supportare i profili di decodifica HD come indicato nella tabella seguente.

Se le implementazioni del dispositivo supportano il codec VP9 e un decodificatore hardware:

  • [C-2-2] DEVE supportare i profili di decodifica HD come indicato nella tabella seguente.

Se l'altezza indicata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video:

  • [C-3-1] Le implementazioni dei dispositivi DEVONO supportare almeno una decodifica VP9 o H.265 dei profili 720, 1080 e UHD.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p UHD
Risoluzione video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
Frequenza fotogrammi video 30 fps 30 fps 30 fps 30 fps (60 fpsTelevisore con decodifica hardware VP9) 60 FPS
Velocità in bit video 600 kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.4. Registrazione audio

Sebbene alcuni dei requisiti descritti in questa sezione siano elencati come DOVREBBE fin da Android 4.3, è previsto che la definizione di compatibilità per le versioni future li modifichi in DEVE. Per i dispositivi Android esistenti e nuovi è FORTEMENTE CONSIGLIATO soddisfare questi requisiti indicati come DOVREBBE, altrimenti non potranno raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

5.4.1. Acquisizione audio non compresso

Se le implementazioni del dispositivo dichiarano android.hardware.microphone:

  • [C-1-1] DEVE consentire l'acquisizione di contenuti audio non elaborati con le seguenti caratteristiche:

  • Formato: PCM lineare, 16 bit

  • Frequenze di campionamento: 8000, 11025, 16000, 44100 Hz

  • Canali: mono

  • [C-1-2] È OBBLIGATORIO acquisire a frequenze di campionamento superiori senza upsampling.

  • [C-1-3] DEVE includere un filtro anti-aliasing appropriato quando le frequenze di campionamento indicate sopra vengono acquisite con il downsampling.

  • DEVE consentire l'acquisizione di contenuti audio non elaborati con qualità DVD e radio AM, il che significa che deve avere le seguenti caratteristiche:

  • Formato: PCM lineare, 16 bit

  • Frequenze di campionamento: 22050, 48000 Hz
  • Canali: stereo

Se le implementazioni dei dispositivi consentono l'acquisizione di contenuti audio non elaborati con qualità DVD e radio AM, devono:

  • [C-2-1] È NECESSARIO acquisire senza upsampling a qualsiasi rapporto superiore a 16000:22050 o 44100:48000.
  • [C-2-2] DEVE includere un filtro anti-aliasing appropriato per qualsiasi upsampling o downsampling.

5.4.2. Acquisisci per il riconoscimento vocale

Se le implementazioni del dispositivo dichiarano android.hardware.microphone:

  • [C-1-1] È NECESSARIO acquisire l'origine audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION a una delle frequenze di campionamento 44100 e 48000.
  • [C-1-2] PER IMPOSTAZIONE PREDEFINITA, deve disattivare qualsiasi elaborazione audio di riduzione del rumore durante la registrazione di uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
  • [C-1-3] PER IMPOSTAZIONE PREDEFINITA, deve essere disattivato qualsiasi controllo automatico del guadagno durante la registrazione di uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
  • DEBBA registrare lo stream audio di riconoscimento vocale con caratteristiche di ampiezza approssimativamente piatte rispetto alla frequenza: in particolare, ±3 dB, da 100 Hz a 4000 Hz.
  • DOVREBBE registrare lo stream audio di riconoscimento vocale con la sensibilità di input impostata in modo che una sorgente con livello di potenza sonora (SPL) di 90 dB a 1000 Hz generi un RMS di 2500 per i campioni a 16 bit.
  • DEVE registrare lo stream audio di riconoscimento vocale in modo che i livelli di ampiezza PCM seguano 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.
  • DEVE registrare lo stream audio di riconoscimento vocale con una distorsione armonica totale (THD) inferiore all'1% per 1 kHz a un livello di ingresso di 90 dB SPL al microfono.

Se le implementazioni dei dispositivi dichiarano tecnologie android.hardware.microphone e di soppressione (riduzione) del rumore ottimizzate per il riconoscimento vocale, devono:

  • [C-2-1] DEVE consentire il controllo di questo effetto audio con l'API android.media.audiofx.NoiseSuppressor.
  • [C-2-2] DEVE identificare in modo univoco ogni implementazione della tecnologia di soppressione del rumore tramite il campo AudioEffect.Descriptor.uuid.

5.4.3. Acquisisci per il reindirizzamento della riproduzione

La classe android.media.MediaRecorder.AudioSource include l'origine audio REMOTE_SUBMIX.

Se le implementazioni del dispositivo dichiarano sia android.hardware.audio.output sia android.hardware.microphone:

  • [C-1-1] DEVE 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, acquisisca un mix di tutti gli stream audio, ad eccezione di quanto segue:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.5. Riproduzione audio

Android include il supporto per consentire alle app di riprodurre l'audio tramite la periferica di uscita audio come definito nella sezione 7.8.2.

5.5.1. Riproduzione audio non elaborata

Se le implementazioni del dispositivo dichiarano android.hardware.audio.output:

  • [C-1-1] 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

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

Se le implementazioni del dispositivo dichiarano la funzionalità android.hardware.audio.output:

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

5.5.3. Volume uscita audio

Implementazioni di dispositivi per auto e motori:

  • DOVREBBE consentire la regolazione del volume audio separatamente per ogni stream audio utilizzando il tipo di contenuti o l'utilizzo come definito da AudioAttributes e l'utilizzo dell'audio in auto come definito pubblicamente in android.car.CarAudioManager.

5.6. Latenza audio

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

Ai fini di questa sezione, utilizza le seguenti definizioni:

  • Latenza in uscita. L'intervallo tra il momento in cui un'applicazione scrive un frame di dati codificati in PCM e il momento in cui il suono corrispondente viene presentato all'ambiente da un trasduttore on-device o il segnale esce dal dispositivo tramite una porta e può essere osservato esternamente.
  • Latenza di output a freddo. La latenza di uscita per il primo frame, quando il sistema di uscita audio è inattivo e spento prima della richiesta.
  • Latenza di output continua. La latenza di uscita per i frame successivi, dopo che il dispositivo ha iniziato a riprodurre l'audio.
  • Latenza di input. L'intervallo tra il momento in cui un suono viene presentato dall'ambiente al dispositivo su un trasduttore on-device o il segnale entra nel dispositivo tramite una porta e il momento in cui un'applicazione legge il frame corrispondente dei dati codificati PCM.
  • Ha perso l'input. La parte iniziale di un segnale di input inutilizzabile o non disponibile.
  • Latenza di input a freddo. La somma del tempo di inserimento perso e della latenza di inserimento per il primo frame, quando il sistema di inserimento audio è inattivo e spento prima della richiesta.
  • Latenza di input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.
  • Jitter in uscita a freddo. La variabilità tra misurazioni separate dei valori di latenza di output a freddo.
  • Jitter di input a freddo. La variabilità tra misurazioni separate dei valori della latenza di input a freddo.
  • latenza di viaggio avanti e indietro continua. La somma della latenza di input continua più la latenza di output continua più un periodo di buffer. Il periodo di buffer consente all'app di elaborare il segnale e di attenuare la differenza di fase tra gli stream di input e di output.
  • API OpenSL ES PCM buffer queue. L'insieme di API OpenSL ES correlate a PCM in Android NDK.
  • API audio nativa AAudio. L'insieme di API AAudio in Android NDK.

Se le implementazioni dei dispositivi dichiarano android.hardware.audio.output, è MOLTO CONSIGLIATO soddisfare o superare i seguenti requisiti:

  • [SR] Latenza di uscita a freddo di massimo 100 millisecondi
  • [SR] Latenza di uscita continua di massimo 45 millisecondi
  • [SR] Riduci al minimo il jitter dell'output a freddo

Se le implementazioni dei dispositivi soddisfano i requisiti sopra indicati dopo la calibrazione iniziale quando si utilizza l'API OpenSL ES PCM buffer queue, per la latenza di uscita continua e la latenza di uscita a freddo su almeno un dispositivo di uscita audio supportato, devono essere:

  • [SR] È FORTEMENTE CONSIGLIATO segnalare l'audio a bassa latenza dichiarando il flag della funzionalità android.hardware.audio.low_latency.
  • [SR] È MOLTO CONSIGLIATO soddisfare anche i requisiti per l'audio a bassa latenza tramite l'API AAudio.

Se le implementazioni dei dispositivi non soddisfano i requisiti per l'audio a bassa latenza tramite l'API OpenSL ES PCM buffer queue, non:

  • [C-1-1] NON DEVE segnalare il supporto dell'audio a bassa latenza.

Se le implementazioni dei dispositivi includono android.hardware.microphone, è MOLTO CONSIGLIATO soddisfare i seguenti requisiti per l'input audio:

  • [SR] Latenza di input a freddo pari o inferiore a 100 millisecondi
  • [RP] Latenza di input continua pari o inferiore a 30 millisecondi
  • [SR] Latenza nel tempo di round trip continua pari o inferiore a 50 millisecondi
  • [SR] Riduci al minimo il jitter dell'input a freddo

5.7. Protocolli di rete

Le implementazioni dei dispositivi DEVONO supportare i protocolli di rete multimediale per la riproduzione di audio e video come specificato nella documentazione dell'SDK Android.

Se le implementazioni dei dispositivi includono un decodificatore audio o video, devono:

  • [C-1-1] DEVE supportare tutti i codec e i formati contenitore richiesti nella sezione 5.1 tramite HTTP(S).

  • [C-1-2] DEVE supportare i formati dei segmenti multimediali indicati nella tabella dei formati dei segmenti multimediali di seguito tramite il protocollo HTTP Live Streaming nella versione 7.

  • [C-1-3] DEVE supportare il seguente profilo video audio RTP e i codec correlati nella tabella RTSP di seguito. Per le eccezioni, consulta le note a piè di pagina della tabella nella sezione 5.1.

Formati dei segmenti di contenuti multimediali

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

Codec audio:

  • AAC
Per informazioni dettagliate sull'AAC e sulle sue varianti, consulta la sezione 5.1.1.
AAC con framing ADTS e tag ID3 ISO 13818-7 Per informazioni dettagliate sull'AAC e sulle sue varianti, consulta la sezione 5.1.1.
WebVTT WebVTT

RTSP (RTP, SDP)

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

5.8. Contenuti multimediali sicuri

Se le implementazioni dei dispositivi supportano l'uscita video sicura e sono in grado di supportare le piattaforme sicure, devono:

  • [C-1-1] È OBBLIGATORIO dichiarare il supporto di Display.FLAG_SECURE.

Se le implementazioni del dispositivo dichiarano il supporto di Display.FLAG_SECURE e supportano il protocollo di visualizzazione wireless, devono:

  • [C-2-1] È NECESSARIO proteggere il collegamento con un meccanismo crittograficamente sicuro come HDCP 2.x o versioni successive per i display collegati tramite protocolli wireless come Miracast.

Se le implementazioni dei dispositivi dichiarano il supporto di Display.FLAG_SECURE e supportano lo schermo esterno con cavo, devono:

  • [C-3-1] DEVE supportare HDCP 1.2 o versioni successive per tutti gli schermi esterni con cavo.

5.9. Musical Instrument Digital Interface (MIDI)

Se le implementazioni dei dispositivi segnalano il supporto della funzionalità android.software.midi tramite la classe android.content.pm.PackageManager:

  • [C-1-1] DEVE supportare il MIDI su tutti i trasporti hardware compatibili con MIDI per i quali fornisce connettività non MIDI generica, dove questi trasporti sono:

  • [C-1-2] DEVE supportare il trasporto software MIDI inter-app (dispositivi MIDI virtuali)

5.10. Audio professionale

Se le implementazioni del dispositivo segnalano il supporto della funzionalità android.hardware.audio.pro tramite la classe android.content.pm.PackageManager:

  • [C-1-1] DEVE segnalare il supporto della funzionalità android.hardware.audio.low_latency.
  • [C-1-2] DEVE avere una latenza audio in tempo di round trip continua, come definito nella sezione 5.6 Latenza audio, DEVE essere inferiore o uguale a 20 millisecondi e DEVE essere inferiore o uguale a 10 millisecondi su almeno un percorso supportato.
  • [C-1-3] DEVE includere una o più porte USB che supportano la modalità host USB e la modalità periferica USB.
  • [C-1-4] DEVE segnalare il supporto della funzionalità android.software.midi.
  • [C-1-5] DEVE soddisfare le latenze e i requisiti audio USB utilizzando l'API coda del buffer PCM OpenSL ES.
  • [SR] Sono FORTEMENTE CONSIGLIATI per fornire un livello coerente di prestazioni della CPU quando l'audio è attivo e il carico della CPU varia. Questo deve essere testato utilizzando il commit SimpleSynth 1bd6391. L'app SimpleSynth deve essere eseguita con i parametri riportati di seguito e non deve presentare sottocarichi dopo 10 minuti:
    • Cicli di lavoro: 200.000
    • Carico variabile: ON (passa dal 100% al 10% del valore dei cicli di lavoro ogni 2 secondi ed è progettato per testare il comportamento del governatore della CPU)
    • Carico stabilizzato: OFF
  • DOVREBBE ridurre al minimo l'inaccuratezza e lo scostamento dell'orologio audio rispetto all'ora standard.
  • DOVREBBE ridurre al minimo lo scostamento dell'orologio audio rispetto alla CPU CLOCK_MONOTONIC quando entrambe sono attive.
  • DEVE ridurre al minimo la latenza audio sui trasduttori sul dispositivo.
  • DEVE ridurre al minimo la latenza audio tramite l'audio digitale USB.
  • DOVREBBE documentare le misurazioni della latenza audio su tutti i percorsi.
  • DOVREBBE ridurre al minimo il jitter nei tempi di inserimento del callback di completamento del buffer audio, in quanto influisce sulla percentuale utilizzabile della larghezza di banda completa della CPU dal callback.
  • DOVREBBE non presentare sottocarichi (uscita) o sovraccarichi (ingresso) audio durante l'uso normale con la latenza registrata.
  • DOVREBBE fornire una differenza di latenza intercanale pari a zero.
  • DOVREBBE ridurre al minimo la latenza media MIDI su tutti i trasporti.
  • DOVREBBE ridurre al minimo la variabilità della latenza MIDI sotto carico (jitter) su tutti i trasporti.
  • DOVREBBE fornire timestamp MIDI accurati su tutti i trasporti.
  • DOVREBBE ridurre al minimo il rumore del segnale audio sui trasduttori sul dispositivo, incluso il periodo immediatamente successivo all'avvio a freddo.
  • DEVE fornire una differenza di clock audio pari a zero tra i lati di input e di output degli endpoint corrispondenti, quando entrambi sono attivi. Alcuni esempi di endpoint corrispondenti sono il microfono e lo speaker sul dispositivo oppure l'ingresso e l'uscita del jack audio.
  • DEVE gestire i callback di completamento del buffer audio per i lati di input e di output degli endpoint corrispondenti nello stesso thread quando entrambi sono attivi e deve inserire il callback di output immediatamente dopo il ritorno dal callback di input. In alternativa, se non è possibile gestire i callback nello stesso thread, inserisci il callback di output poco dopo aver inserito il callback di input per consentire all'applicazione di avere una tempistica coerente dei lati di input e output.
  • DEVE ridurre al minimo la differenza di fase tra il buffering audio HAL per i lati di input e di output degli endpoint corrispondenti.
  • DEVE ridurre al minimo la latenza del tocco.
  • DOVREBBE ridurre al minimo la variabilità della latenza tocco sotto carico (jitter).

Se le implementazioni dei dispositivi soddisfano tutti i requisiti sopra indicati:

Se le implementazioni dei dispositivi soddisfano i requisiti tramite l'API OpenSL ES PCM buffer queue, devono:

  • [SR] È MOLTO CONSIGLIATO soddisfare gli stessi requisiti anche tramite l'API AAudio.

Se le implementazioni dei dispositivi includono un jack audio da 3,5 mm a 4 conduttori, devono:

  • [C-2-1] La latenza audio continua nel tempo di andata e ritorno deve essere pari o inferiore a 20 millisecondi sul percorso del jack audio.
  • [SR] È FORTEMENTE CONSIGLIATO di rispettare la sezione Specifiche del jack per dispositivi mobili della Specifica per cuffie audio con cavo (v1.1).
  • La latenza audio continua nel tempo di round trip DEVE essere pari o inferiore a 10 millisecondi lungo il percorso del jack audio.

Se le implementazioni dei dispositivi omettono un jack audio da 3, 5 mm a 4 conduttori e includono una o più porte USB che supportano la modalità host USB:

  • [C-3-1] È NECESSARIO implementare la classe audio USB.
  • [C-3-2] DEVE avere una latenza audio continua nel tempo di round trip pari o inferiore a 20 ms sulla porta in modalità host USB utilizzando la classe audio USB.
  • La latenza audio in tempo di round trip continuo DEVE essere pari o inferiore a 10 millisecondi sulla porta in modalità host USB utilizzando la classe audio USB.

Se le implementazioni dei dispositivi includono una porta HDMI, devono:

  • [C-4-1] DEVE supportare l'uscita in stereo e in otto canali a una profondità di 20 o 24 bit e 192 kHz senza perdita di profondità di bit o ricampionamento.

5.11. Acquisisci per non elaborato

Android include il supporto per la registrazione di audio non elaborato tramite la sorgente audio android.media.MediaRecorder.AudioSource.UNPROCESSED. In OpenSL ES, è possibile accedervi con il preset di registrazione SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Se le implementazioni dei dispositivi hanno l'intenzione di supportare l'origine audio non elaborata e renderla disponibile per le app di terze parti:

  • [C-1-1] È OBBLIGATORIO segnalare il supporto tramite la proprietà android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

  • [C-1-2] DEVE presentare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte nell'intervallo di frequenza medio: in particolare ±10 dB da 100 Hz a 7000 Hz per ogni microfono utilizzato per registrare l'origine audio non elaborata.

  • [C-1-3] DEVE presentare livelli di ampiezza nell'intervallo di frequenza basso: in particolare da ±20 dB da 5 Hz a 100 Hz rispetto all'intervallo di frequenza medio per ogni microfono utilizzato per registrare l'origine audio non elaborata.

  • [C-1-4] DEVE presentare livelli di ampiezza nell'intervallo di frequenza alto: in particolare da ±30 dB da 7000 Hz a 22 KHz rispetto all'intervallo di frequenza medio per ogni microfono utilizzato per registrare l'origine audio non elaborata.

  • [C-1-5] È NECESSARIO impostare la sensibilità di ingresso audio in modo che una sorgente di toni sinusoidali a 1000 Hz riprodotta a un livello di pressione sonora (SPL) di 94 dB generi una risposta con un RMS di 520 per campioni a 16 bit (o -36 dB Full Scale per campioni a virgola mobile/doppia precisione) per ogni microfono utilizzato per registrare la sorgente audio non elaborata.

  • [C-1-6] DEVE avere un rapporto segnale/rumore (SNR) di almeno 60 dB per ogni microfono utilizzato per registrare l'origine audio non elaborata. (mentre il rapporto SNR viene misurato come differenza tra 94 dB SPL e SPL equivalente del rumore proprio, ponderato A).

  • [C-1-7] DEVE avere una distorsione armonica totale (THD) inferiore all'1% per 1 kHz a un livello di ingresso di 90 dB SPL su ogni microfono utilizzato per registrare l'origine audio non elaborata.

  • NON deve essere presente nel percorso alcun altro trattamento del segnale (ad es. controllo automatico del guadagno, filtro passa alto o cancellazione dell'eco) oltre a un moltiplicatore di livello per portare il livello nell'intervallo desiderato. In altre parole:

  • [C-1-8] Se per qualsiasi motivo nell'architettura è presente un'elaborazione del segnale, questa DEVE essere disattivata e deve introdurre un ritardo zero o una latenza aggiuntiva nel percorso del segnale.
  • [C-1-9] Il moltiplicatore di livello, sebbene sia consentito nel percorso, NON DEVE introdurre ritardi o latenze nel percorso del segnale.

Tutte le misurazioni SPL vengono effettuate direttamente accanto al microfono in prova. Per più configurazioni del microfono, questi requisiti si applicano a ogni microfono.

Se le implementazioni del dispositivo dichiarano android.hardware.microphone, ma non supportano la sorgente audio non elaborata:

  • [C-2-1] DEVE restituire null per il metodo dell'API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), per indicare correttamente la mancanza di supporto.
  • [SR] sono comunque FORTEMENTE CONSIGLIATI per soddisfare il maggior numero possibile di requisiti per il percorso del segnale per l'origine di registrazione non elaborata.

6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori

6.1. Strumenti per sviluppatori

Implementazioni dei dispositivi:

  • [C-0-1] DEVE supportare gli Android Developer Tools forniti nell'SDK Android.

  • Android Debug Bridge (ADB)

    • [C-0-2] DEVE supportare tutte le funzioni adb come documentato nell'SDK Android, inclusa dumpsys.
    • [C-0-3] NON DEVE alterare il formato o i contenuti degli eventi di sistema del dispositivo (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrati tramite dumpsys.
    • [C-0-4] È NECESSARIO che il daemon adb lato dispositivo sia inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivare Android Debug Bridge.
    • [C-0-5] DEVE supportare adb sicuro. Android include il supporto per adb sicuro. adb sicuro attiva adb su host autenticati noti.

    • [C-0-6] DEVE fornire un meccanismo che consenta di connettere adb da una macchina host. Ad esempio:

      • Le implementazioni dei dispositivi senza una porta USB che supporta la modalità periferica DEVONO implementare adb tramite una rete locale (ad esempio Ethernet o Wi-Fi).
      • DEVE fornire i driver per Windows 7, 9 e 10, consentendo agli sviluppatori di connettersi al dispositivo utilizzando il protocollo adb.

  • Dalvik Debug Monitor Service (ddms)

    • [C-0-7] DEVE 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.
  • Scimmia
    • [C-0-8] DEVE includere il framework Monkey e renderlo disponibile per l'utilizzo da parte delle applicazioni.
  • SysTrace
    • [C-0-9] DEVE 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.

6.2. Opzioni sviluppatore

Android include il supporto per la configurazione delle impostazioni relative allo sviluppo delle applicazioni.

Le implementazioni dei dispositivi DEVONO fornire un'esperienza coerente per le Opzioni sviluppatore, devono:

  • [C-0-1] DEVE rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo delle applicazioni. L'implementazione di Android a monte nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avviare le Opzioni sviluppatore dopo aver premuto sette (7) volte l'elemento di menu Impostazioni > Informazioni sul dispositivo > Numero build.
  • [C-0-2] DEVE nascondere le Opzioni sviluppatore per impostazione predefinita e DEVE fornire un meccanismo per attivarle senza la necessità di una lista consentita speciale.
  • POTREBBE limitare temporaneamente l'accesso al menu Opzioni sviluppatore nascondendolo o disattivandolo visivamente per evitare distrazioni in scenari in cui la sicurezza dell'utente è in discussione.

7. Compatibilità hardware

Se un dispositivo include un determinato componente hardware con un'API corrispondente per gli sviluppatori di terze parti:

  • [C-0-1] 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:

  • [C-0-2] È comunque necessario presentare definizioni di classi complete (come documentato dall'SDK) per le API dei componenti.
  • [C-0-3] I comportamenti dell'API DEVONO essere implementati come no-op in modo ragionevole.
  • [C-0-4] I metodi API DEVONO restituire valori null se consentito dalla documentazione dell'SDK.
  • [C-0-5] I metodi API DEVONO restituire implementazioni no-op delle classi in cui i valori null non sono consentiti dalla documentazione dell'SDK.
  • [C-0-6] I metodi dell'API NON DEVONO generare eccezioni non documentate dalla documentazione dell'SDK.
  • [C-0-7] Le implementazioni dei dispositivi DEVONO segnalare in modo coerente informazioni accurate sulla configurazione hardware tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) della classe android.content.pm.PackageManager per la stessa impronta di build.

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.

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 varietà di configurazioni hardware. I dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

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

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

7.1.1. Configurazione schermo

7.1.1.1. Dimensioni schermo

Il framework UI di Android supporta una serie di dimensioni diverse del layout dello schermo logico e consente alle applicazioni di eseguire query sulle dimensioni del layout dello schermo della configurazione corrente tramite Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK e Configuration.smallestScreenWidthDp.

  • [C-0-1] Le implementazioni dei dispositivi DEVONO segnalare le dimensioni corrette del layout per Configuration.screenLayout come definito nella documentazione dell'SDK Android. Nello specifico, le implementazioni dei dispositivi DEVONO segnalare le dimensioni dello schermo logiche in pixel indipendenti dalla densità (dp) corrette come indicato di seguito:

    • I dispositivi con Configuration.uiMode impostato su un valore diverso da UI_MODE_TYPE_WATCH e che segnalano una dimensione small per Configuration.screenLayout DEVONO avere almeno 426 dp x 320 dp.
    • I dispositivi che segnalano una dimensione normal per Configuration.screenLayout DEVONO avere almeno 480 dp x 320 dp.
    • I dispositivi che segnalano una dimensione large per Configuration.screenLayout DEVONO avere almeno 640 dp x 480 dp.
    • I dispositivi che segnalano una dimensione di xlarge per Configuration.screenLayout DEVONO avere almeno 960 dp x 720 dp.

  • [C-0-2] Le implementazioni dei dispositivi DEVONO rispettare correttamente il supporto dichiarato dalle applicazioni per le dimensioni dello schermo tramite l'attributo <supports-screens> in AndroidManifest.xml, come descritto nella documentazione dell'SDK Android.

7.1.1.2. Proporzioni dello schermo

Sebbene non sia prevista alcuna limitazione per il valore delle proporzioni dello schermo del display fisico, le proporzioni dello schermo del display logico in cui vengono visualizzate le app di terze parti, come dedotto dai valori di altezza e larghezza riportati tramite le API view.Display e l'API Configuration, DEVONO soddisfare i seguenti requisiti:

  • [C-0-1] Le implementazioni dei dispositivi con Configuration.uiMode impostato su UI_MODE_TYPE_NORMAL DEVONO avere un valore di proporzioni compreso tra 1,3333 (4:3) e 1,86 (circa 16:9), a meno che l'app non possa essere considerata pronta per essere allungata soddisfacendo una delle seguenti condizioni:

    • L'app ha dichiarato di supportare un formato dello schermo più grande tramite il valore dei metadati android.max_aspect.
    • L'app dichiara di essere ridimensionabile tramite l'attributo android:resizeableActivity.
    • L'app ha come target il livello API 26 o versioni successive e non dichiara un android:MaxAspectRatio che limiti le proporzioni consentite.

  • [C-0-2] Le implementazioni dei dispositivi con Configuration.uiMode impostato su UI_MODE_TYPE_WATCH DEVONO avere un valore di proporzioni impostato su 1,0 (1:1).

7.1.1.3. Densità schermo

Il framework dell'interfaccia utente di Android definisce un insieme di densità logiche standard per aiutare gli sviluppatori di applicazioni a scegliere come target le risorse dell'applicazione.

  • [C-0-1] Per impostazione predefinita, le implementazioni dei dispositivi DEVONO segnalare solo una delle seguenti densità del framework Android logico tramite l'API DENSITY_DEVICE_STABLE e questo valore NON DEVE cambiare in nessun momento; tuttavia, il dispositivo PUÒ segnalare una densità arbitraria diversa in base alle modifiche alla configurazione del display apportate dall'utente (ad esempio le dimensioni del display) impostate dopo l'avvio iniziale.

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

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

Se è presente un'affordance per modificare le dimensioni del display del dispositivo:

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

7.1.2. Metriche relative alla visualizzazione

Se le implementazioni dei dispositivi includono uno schermo o un'uscita video, devono:

Se le implementazioni dei dispositivi non includono uno schermo incorporato o un'uscita video, devono:

  • [C-2-1] DEVE riportare valori ragionevoli per tutte le metriche di visualizzazione definite nell'API android.util.DisplayMetrics per il view.Display predefinito emulato.

7.1.3. Orientamento schermo

Implementazioni dei dispositivi:

  • [C-0-1] DEVE indicare gli orientamenti dello schermo supportati (android.hardware.screen.portrait e/o android.hardware.screen.landscape) e DEVE indicare almeno un orientamento supportato. Ad esempio, un dispositivo con uno schermo in orientamento orizzontale fisso, come una TV o un laptop, DOVREBBE segnalare solo android.hardware.screen.landscape.
  • [C-0-2] DEVE 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.

Se le implementazioni dei dispositivi supportano entrambi gli orientamenti dello schermo:

  • [C-1-1] DEVE supportare l'orientamento dinamico da parte delle applicazioni per l'orientamento dello schermo verticale o orizzontale. In altre parole, il dispositivo deve rispettare la richiesta dell'applicazione di un orientamento dello schermo specifico.
  • [C-1-2] NON DEVE modificare le dimensioni o la densità dello schermo registrate quando si cambia l'orientamento.
  • PUO' selezionare l'orientamento verticale o orizzontale come predefinito.

7.1.4. Accelerazione grafica 2D e 3D

7.1.4.1 OpenGL ES

Implementazioni dei dispositivi:

  • [C-0-1] DEVE identificare correttamente le versioni OpenGL ES supportate (1.1, 2.0, 3.0, 3.1, 3.2) tramite le API gestite (ad esempio tramite il metodo GLES10.getString()) e le API native.
  • [C-0-2] DEVE includere il supporto di tutte le API native e gestite corrispondenti per tutte le versioni di OpenGL ES che ha identificato come supportate.

Se le implementazioni dei dispositivi includono uno schermo o un'uscita video, devono:

  • [C-1-1] DEVE supportare sia OpenGL ES 1.0 che 2.0, come descritto e dettagliato nella documentazione dell'SDK Android.
  • [SR] sono FORTEMENTE CONSIGLIATI per supportare OpenGL ES 3.0.
  • DEVE supportare OpenGL ES 3.1 o 3.2.

Se le implementazioni del dispositivo supportano una delle versioni OpenGL ES, devono:

  • [C-2-1] DEVE segnalare tramite le API OpenGL ES gestite e le API native tutte le altre estensioni OpenGL ES che ha implementato e, al contrario, NON DEVE segnalare le stringhe di estensione che non supporta.
  • [C-2-2] DEVE supportare le estensioni EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage e EGL_ANDROID_recordable.
  • [SR] È MOLTO CONSIGLIATO supportare EGL_KHR_partial_update.
  • DEVE segnalare con precisione tramite il metodo getString() qualsiasi formato di compressione delle texture supportato, che in genere è specifico del fornitore.

Se le implementazioni del dispositivo dichiarano il supporto di OpenGL ES 3.0, 3.1 o 3.2:

  • [C-3-1] È NECESSARIO esportare i simboli di funzione corrispondenti per queste versioni, oltre ai simboli di funzione OpenGL ES 2.0, nella libreria libGLESv2.so.

Se le implementazioni dei dispositivi supportano OpenGL ES 3.2:

  • [C-4-1] DEVE supportare l'intero pacchetto di estensioni OpenGL ES per Android.

Se le implementazioni dei dispositivi supportano l'Android Extension Pack OpenGL ES nella sua interezza, devono:

  • [C-5-1] È NECESSARIO identificare il supporto tramite il flag della funzionalità android.hardware.opengles.aep.

Se le implementazioni dei dispositivi espongono il supporto per l'estensione EGL_KHR_mutable_render_buffer:

  • [C-6-1] DEVE supportare anche l'estensione EGL_ANDROID_front_buffer_auto_refresh.
7.1.4.2 Vulkan

Android include il supporto di Vulkan, un'API multipiattaforma a basso overhead per la grafica 3D ad alte prestazioni.

Se le implementazioni del dispositivo supportano OpenGL ES 3.0 o 3.1:

  • [SR] È FORTEMENTE CONSIGLIATO includere il supporto di Vulkan 1.0 .

Se le implementazioni dei dispositivi includono uno schermo o un'uscita video, devono:

  • DEVE includere il supporto di Vulkan 1.0.

Implementazioni del dispositivo, se includono il supporto di Vulkan 1.0:

  • [C-1-1] DEVE riportare il valore intero corretto con i flag di funzionalità android.hardware.vulkan.level e android.hardware.vulkan.version.
  • [C-1-2] DEVE elencare almeno un VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] DEVE implementare completamente le API Vulkan 1.0 per ogni VkPhysicalDevice elencato.
  • [C-1-4] DEVE enumerare i livelli contenuti nelle librerie native denominate libVkLayer*.so nella directory delle librerie native del pacchetto dell'applicazione tramite le API native di Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties() .
  • [C-1-5] NON DEVE enumerare i livelli forniti dalle librerie esterne al pacchetto dell'applicazione o fornire altri modi per tracciare o intercettare l'API Vulkan, a meno che l'attributo android:debuggable dell'applicazione non sia impostato su true.
  • [C-1-6] DEVE segnalare tutte le stringhe di estensione supportate tramite le API native di Vulkan e, al contrario, NON DEVE segnalare le stringhe di estensione non supportate correttamente.

Implementazioni dei dispositivi, se non includono il supporto di Vulkan 1.0:

  • [C-2-1] NON DEVE dichiarare nessuno dei flag funzionalità Vulkan (ad es. android.hardware.vulkan.level, android.hardware.vulkan.version).
  • [C-2-2] NON DEVE elencare alcun VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices().
7.1.4.3 RenderScript
  • [C-0-1] Le implementazioni dei dispositivi DEVONO supportare Android RenderScript, come descritto nella documentazione dell'SDK Android.
7.1.4.4 Accelerazione grafica 2D

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

Implementazioni dei dispositivi:

  • [C-0-1] DEVE attivare l'accelerazione hardware per impostazione predefinita e DEVE disattivarla se lo sviluppatore lo richiede impostando android:hardwareAccelerated="false" o disattivando l'accelerazione hardware direttamente tramite le API View di Android.
  • [C-0-2] DEVE mostrare un comportamento coerente con la documentazione dell'SDK Android sull'accelerazione hardware.

Android include un oggetto TextureView che consente agli sviluppatori di integrare direttamente le texture OpenGL ES con accelerazione hardware come target di rendering in una gerarchia dell'interfaccia utente.

  • [C-0-3] DEVE supportare l'API TextureView e DEVE avere un comportamento coerente con l'implementazione Android a monte.
7.1.4.5 Display con gamma di colori ampliata

Se le implementazioni dei dispositivi dichiarano il supporto dei display a gamma estesa tramite Display.isWideColorGamut():

  • [C-1-1] DEVE avere un display calibrato a colori.
  • [C-1-2] DEVE avere un display la cui gamma copra interamente la gamma di colori sRGB nello spazio xyY CIE 1931.
  • [C-1-3] DEVE avere un display la cui gamma ha un'area di almeno il 90% di NTSC 1953 nello spazio xyY CIE 1931.
  • [C-1-4] DEVE supportare OpenGL ES 3.0, 3.1 o 3.2 e segnalarlo correttamente.
  • [C-1-5] È OBBLIGATORIO pubblicizzare il supporto delle estensioni EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_colorspace_scrgb_linear e EGL_GL_colorspace_display_p3.
  • [SR] Sono MOLTO CONSIGLIATI per supportare GL_EXT_sRGB.

Al contrario, se le implementazioni dei dispositivi non supportano i display a gamma estesa:

  • [C-2-1] DEVE coprire almeno il 100% di sRGB nello spazio xyY CIE 1931, anche se la gamma di colori dello schermo non è definita.

7.1.5. Modalità di compatibilità delle applicazioni precedenti

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

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.

Implementazioni dei dispositivi:

  • [C-0-1] DEVE supportare i display in grado di eseguire il rendering di grafica a colori a 16 bit.
  • DOVREBBE supportare i display in grado di gestire la grafica a colori a 24 bit.
  • [C-0-2] DEVE supportare i display in grado di eseguire il rendering delle animazioni.
  • [C-0-3] È OBBLIGATORIO utilizzare la tecnologia di visualizzazione con un rapporto di aspetto dei pixel (PAR) compreso tra 0,9 e 1,15. In altre parole, le proporzioni dei pixel DEVONO essere quasi quadrate (1,0) con una tolleranza del 10-15%.

7.1.7. Display secondari

Android include il supporto per il display secondario per abilitare le funzionalità di condivisione dei contenuti multimediali e le API per sviluppatori per accedere ai display esterni.

Se le implementazioni dei dispositivi supportano un display esterno tramite una connessione con cavo, wireless o un display aggiuntivo integrato, devono:

  • [C-1-1] DEVE implementare il servizio di sistema e l'API DisplayManager come descritto nella documentazione dell'SDK Android.

7.2. Dispositivi di immissione

Implementazioni dei dispositivi:

7.2.1. Tastiera

Se le implementazioni dei dispositivi includono il supporto di applicazioni Input Method Editor (IME) di terze parti, devono:

Implementazioni del dispositivo: [C-0-1] NON DEVE includere una tastiera hardware che non corrisponde a uno dei formati specificati in android.content.res.Configuration.keyboard (QWERTY o 12 tasti). DOVREBBE includere implementazioni aggiuntive della tastiera virtuale. * POTREBBE includere una tastiera hardware.

7.2.2. Navigazione non tocco

Android include il supporto per il d-pad, la trackball e il mouse come meccanismi per la navigazione non tocco.

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi non dispongono di navigazione non tocco, presentano i seguenti problemi:

  • [C-1-1] DEVE fornire un meccanismo di interfaccia utente alternativo ragionevole per la selezione e la modifica del testo, compatibile con gli Input Management Engine. L'implementazione open source di Android upstream include un meccanismo di selezione adatto all'uso con dispositivi che non dispongono di input di navigazione non touch.

7.2.3. Tasti di navigazione

Le funzioni Home, Recenti e Indietro, in genere fornite tramite un'interazione con un pulsante fisico dedicato o una parte distinta del touchscreen, sono essenziali per il paradigma di navigazione di Android e, di conseguenza, per le implementazioni dei dispositivi:

  • [C-0-1] DEVE fornire all'utente la possibilità di avviare le applicazioni installate che hanno un'attività con <intent-filter> impostato su ACTION=MAIN e CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER per le implementazioni dei dispositivi TV. La funzione Home DOVREBBE essere il meccanismo per questa funzionalità per l'utente.
  • DOVREBBE fornire pulsanti per le funzioni Recenti e Indietro.

Se sono fornite le funzioni Home, Recenti o Indietro:

  • [C-1-1] DEVONO essere accessibili con una singola azione (ad es. tocco, doppio clic o gesto) quando uno di questi è accessibile.
  • [C-1-2] DEVE fornire un'indicazione chiara della singola azione che attiverà ogni funzione. Alcuni esempi di queste indicazioni sono l'inserimento di un'icona visibile sul pulsante, la visualizzazione di un'icona del software nella parte della barra di navigazione dello schermo o la guida dell'utente attraverso un flusso di dimostrazione passo passo durante l'esperienza di configurazione out-of-box.

Implementazioni dei dispositivi:

  • [SR] È FORTEMENTE CONSIGLIATO di non fornire il meccanismo di immissione per la funzione Menu, in quanto è stata ritirata a favore dell'app bar da Android 4.0.

Se le implementazioni del dispositivo forniscono la funzione Menu, devono:

  • [C-2-1] DEVE mostrare il pulsante di overflow delle azioni ogni volta che il menu popup di overflow delle azioni non è vuoto e la barra delle azioni è visibile.
  • [C-2-2] NON DEVE modificare la posizione del popup di overflow delle azioni visualizzato selezionando il pulsante di overflow nella barra delle azioni, ma PUÒ visualizzare il popup di overflow delle azioni in una posizione modificata sullo schermo quando viene visualizzato selezionando la funzione Menu.

Se le implementazioni dei dispositivi non forniscono la funzione Menu, per la compatibilità con le versioni precedenti:

  • [C-3-1] DEVE rendere disponibile la funzione Menu per le applicazioni quando targetSdkVersion è inferiore a 10, tramite un pulsante fisico, una chiave software o gesti. Questa funzione Menu dovrebbe essere accessibile, a meno che non sia nascosta insieme ad altre funzioni di navigazione.

Se le implementazioni dei dispositivi forniscono la funzione di assistenza:

  • [C-4-1] È NECESSARIO rendere accessibile la funzione di assistenza con una singola azione (ad es. tocco, doppio clic o gesto) quando sono accessibili altri tasti di navigazione.
  • [SR] È FORTEMENTE CONSIGLIATO di utilizzare la pressione prolungata sulla funzione HOME come interazione designata.

Se le implementazioni del dispositivo utilizzano una parte distinta dello schermo per visualizzare i tasti di navigazione:

  • [C-5-1] I tasti di navigazione DEVONO utilizzare una parte distinta dello schermo, non disponibile per le applicazioni, e NON DEVONO coprire o interferire in altro modo con la parte dello schermo disponibile per le applicazioni.
  • [C-5-2] DEVE rendere disponibile una parte del display per le applicazioni che soddisfano i requisiti definiti nella sezione 7.1.1.
  • [C-5-3] DEVE rispettare i flag impostati dall'app tramite il metodo dell'API View.setSystemUiVisibility(), in modo che questa parte distinta della schermata (ovvero la barra di navigazione) venga nascosta correttamente come descritto nell'SDK.

7.2.4. Input touchscreen

Android include il supporto di una serie di sistemi di input del cursore, come touchscreen, touchpad e dispositivi di input touch simulati. Le implementazioni dei dispositivi basati su touchscreen sono associate a un display in modo che l'utente abbia l'impressione di manipolare direttamente gli elementi sullo schermo. Poiché l'utente tocca direttamente lo schermo, il sistema non richiede alcun'altra funzionalità per indicare gli oggetti manipolati.

Implementazioni dei dispositivi:

  • DEVE avere un sistema di input del cursore di qualche tipo (simile a un mouse o tocco).
  • DOVREBBE supportare gli indicatori monitorati in modo completamente indipendente.

Se le implementazioni dei dispositivi includono un touchscreen (monotocco o superiore), devono:

  • [C-1-1] È OBBLIGATORIO segnalare TOUCHSCREEN_FINGER per il campo dell'API Configuration.touchscreen.
  • [C-1-2] DEVI segnalare i flag di funzionalità android.hardware.touchscreen e android.hardware.faketouch

Se le implementazioni del dispositivo includono un touchscreen che può rilevare più di un tocco, devono:

  • [C-2-1] DEVE segnalare i flag di funzionalità appropriati android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand corrispondenti al tipo di touchscreen specifico sul dispositivo.

Se le implementazioni dei dispositivi non includono un touchscreen (e si basano solo su un dispositivo di puntamento) e soddisfano i requisiti per i tocchi falsi descritti nella sezione 7.2.5, devono:

  • [C-3-1] NON DEVE segnalare alcun flag della funzionalità che inizia con android.hardware.touchscreen e DEVE segnalare solo android.hardware.faketouch.

7.2.5. Input tocco simulato

L'interfaccia touch simulata fornisce un sistema di input utente che approssima un sottoinsieme di funzionalità del touchscreen. Ad esempio, un mouse o un telecomando che gestisce un cursore sullo schermo si avvicina al tocco, ma richiede all'utente di prima puntare o mettere a fuoco e poi fare clic. Numerosi dispositivi di input come mouse, trackpad, mouse aereo basato su giroscopio, cursore a giroscopio, joystick e trackpad multi-touch possono supportare interazioni touch false. Android include la costante di funzionalità android.hardware.faketouch, che corrisponde a un dispositivo di input non touch (basato su cursore) ad alta fedeltà, come un mouse o un trackpad, che può emulare adeguatamente l'input touch (incluso il supporto di gesti di base) e indica che il dispositivo supporta un sottoinsieme emulato delle funzionalità del touchscreen.

Se le implementazioni dei dispositivi non includono un touchscreen, ma includono un altro sistema di input del cursore che vogliono rendere disponibile:

  • DOVREBBE dichiarare il supporto per il flag funzionalità android.hardware.faketouch.

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.faketouch:

  • [C-1-1] DEVE indicare le posizioni sullo schermo X e Y assolute della posizione del cursore e mostrare un cursore visivo sullo schermo.
  • [C-1-2] È OBBLIGATORIO registrare l'evento tocco con il codice azione che specifica la modifica dello stato che si verifica quando il cursore si sposta verso il basso o verso l'alto sullo schermo.
  • [C-1-3] DEVE supportare il movimento del cursore verso il basso e verso l'alto su un oggetto sullo schermo, il che consente agli utenti di emulare il tocco di un oggetto sullo schermo.
  • [C-1-4] 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 punto su un oggetto sullo schermo entro una soglia di tempo, il che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo.
  • [C-1-5] DEVE supportare il cursore verso il basso in un punto arbitrario dello schermo, il cursore si sposta in un altro punto arbitrario dello schermo, seguito da un cursore verso l'alto, che consente agli utenti di emulare un trascinamento con tocco.
  • [C-1-6] DEVE supportare il cursore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in un'altra posizione sullo schermo e poi il cursore verso l'alto sullo schermo, in modo da consentire agli utenti di lanciare un oggetto sullo schermo.
  • [C-1-7] È OBBLIGATORIO segnalare TOUCHSCREEN_NOTOUCH per il campo dell'API Configuration.touchscreen.

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.faketouch.multitouch.distinct:

  • [C-2-1] È OBBLIGATORIO dichiarare il supporto di android.hardware.faketouch.
  • [C-2-2] DEVE supportare il monitoraggio distinto di due o più input del cursore indipendenti.

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.faketouch.multitouch.jazzhand:

  • [C-3-1] È OBBLIGATORIO dichiarare il supporto di android.hardware.faketouch.
  • [C-3-2] DEVE supportare il rilevamento distinto di 5 (monitoraggio di una mano di dita) o più input del cursore in modo completamente indipendente.

7.2.6. Supporto del controller di gioco

7.2.6.1. Mappature dei pulsanti

Se le implementazioni del dispositivo dichiarano il flag della funzionalità android.hardware.gamepad:

  • [C-1-1] DEVE avere un controller integrato o essere fornito con un controller separato nella confezione, che fornisca i mezzi per inserire tutti gli eventi elencati nelle tabelle seguenti.
  • [C-1-2] DEVE essere in grado di mappare gli eventi HID alle costanti view.InputEvent di Android associate, come elencato nelle tabelle seguenti. L'implementazione di Android a monte include l'implementazione per i controller di gioco che soddisfano questo requisito.
Pulsante Utilizzo HID2 Pulsante Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
Pulsante direzionale su1
Pulsante direzionale giù1 		0x01 0x00393 AXIS_HAT_Y4
D-pad sinistra1
D-pad destra1 		0x01 0x00393 AXIS_HAT_X4
Pulsante del tasto sinistro1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Pulsante del tasto funzione destro1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clic con la levetta sinistra1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clic con il tasto destro della levetta1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Home1 0x0c 0x0223 KEYCODE_HOME (3)
Indietro1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

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

3 Questo utilizzo deve avere un valore minimo logico di 0, un valore massimo logico di 7, un valore minimo fisico di 0, un valore massimo fisico di 315, unità in gradi e una dimensione del report di 4. Il valore logico è definito come la rotazione in senso orario dall'asse verticale; ad esempio, un valore logico pari a 0 indica che non è presente alcuna rotazione e che è stato premuto il tasto Su, mentre un valore logico pari a 1 indica una rotazione di 45 gradi e che sono stati premuti sia il tasto Su sia il tasto Sinistra.

4 MotionEvent

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

1 MotionEvent

7.2.7. Telecomando

Per i requisiti specifici dei dispositivi, consulta la sezione 2.3.1.

7.3. Sensori

Se le implementazioni del dispositivo includono 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.

Implementazioni dei dispositivi:

  • [C-0-1] DEVE segnalare con precisione la presenza o l'assenza di sensori in base alla classe android.content.pm.PackageManager.
  • [C-0-2] DEVE restituire un elenco accurato dei sensori supportati tramite SensorManager.getSensorList() e metodi simili.
  • [C-0-3] 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).

Se le implementazioni del dispositivo includono un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti, devono:

  • [C-1-1] È NECESSARIO segnalare tutte le misurazioni del sensore utilizzando i valori pertinenti del Sistema internazionale di unità di misura (metrico) per ogni tipo di sensore, come definito nella documentazione dell'SDK Android.
  • [C-1-2] DEVE segnalare i dati del sensore con una latenza massima di 100 millisecondi
  • 2 * sample_time per il caso di un sensore in streaming con una latenza minima richiesta di 5 ms + 2 * sample_time quando il processore dell'applicazione è attivo. Questo ritardo non include i ritardi dovuti ai filtri.
  • [C-1-3] DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time dall'attivazione del sensore. È accettabile che questo campione abbia una precisione pari a 0.

  • [SR] DOVREBBE registrare l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta l'ora in cui si è verificato l'evento e sincronizzata con l'orologio SystemClock.elapsedRealtimeNano(). È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma, dove questo potrebbe diventare un componente OBBLIGATORIO. L'errore di sincronizzazione DEVE essere inferiore a 100 millisecondi.

  • [C-1-7] 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 DEVONO avere un jitter inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori timestamp registrati tra eventi consecutivi.

  • [C-1-8] DEVE garantire che lo stream di eventi del sensore NON DEVE impedire alla CPU del dispositivo di entrare in uno stato di sospensione o di riattivarsi da uno stato di sospensione.

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

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

Alcuni tipi di sensori sono composti, il che significa che possono essere ricavati dai dati forniti da uno o più altri sensori. Alcuni esempi sono il sensore di orientamento e il sensore di accelerazione lineare.

Implementazioni dei dispositivi:

  • DEBBA implementare questi tipi di sensori, se includono i sensori fisici prerequisiti descritti nella sezione tipi di sensori.

Se le implementazioni dei dispositivi includono un sensore composito:

  • [C-2-1] È NECESSARIO implementare il sensore come descritto nella documentazione Android Open Source sui sensori compositi.

7.3.1. Accelerometro

  • Le implementazioni dei dispositivi DEVONO includere un accelerometro a 3 assi.

Se le implementazioni del dispositivo includono un accelerometro a 3 assi, devono:

  • [C-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 50 Hz.
  • [C-1-2] È NECESSARIO implementare e segnalare il sensore TYPE_ACCELEROMETER.
  • [C-1-3] DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nelle API Android.
  • [C-1-4] DEVE essere in grado di misurare da caduta libera fino a quattro volte la gravità(4 g) o più su qualsiasi asse.
  • [C-1-5] DEVE avere una risoluzione di almeno 12 bit.
  • [C-1-6] DEVE avere una deviazione standard non superiore a 0,05 m/s^, dove la deviazione standard deve essere calcolata in base all'asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più elevata.
  • [SR] sono FORTEMENTE CONSIGLIATI per implementare il sensore composito TYPE_SIGNIFICANT_MOTION.
  • [SR] È MOLTO CONSIGLIATO implementare il sensore TYPE_ACCELEROMETER_UNCALIBRATED se è disponibile la calibrazione dell'accelerometro online.
  • DEBBA implementare i sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento dell'SDK Android.
  • DEVE registrare eventi fino ad almeno 200 Hz.
  • DEVE avere una risoluzione di almeno 16 bit.
  • DEVE essere calibrato durante l'uso se le caratteristiche cambiano nel ciclo di vita e vengono compensate e deve conservare i parametri di compensazione tra i riavvii del dispositivo.
  • DEVE essere compensato in base alla temperatura.
  • DOVREBBE anche implementare il sensore TYPE_ACCELEROMETER_UNCALIBRATED.

Se le implementazioni del dispositivo includono un accelerometro a 3 assi e sono implementati uno dei sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER:

  • [C-2-1] La somma del loro consumo di energia DEVE essere sempre inferiore a 4 mW.
  • DEVONO essere inferiori a 2 mW e 0,5 mW quando il dispositivo è in una condizione dinamica o statica.

Se le implementazioni del dispositivo includono un accelerometro a tre assi e un sensore giroscopio:

  • [C-3-1] È NECESSARIO implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • DEVE implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.
  • [SR] È FORTEMENTE CONSIGLIATO di implementare il sensore TYPE_GAME_ROTATION_VECTOR sui dispositivi Android esistenti e nuovi.

Se le implementazioni del dispositivo includono un accelerometro a 3 assi, un sensore giroscopio e un sensore magnetometro:

  • [C-4-1] È NECESSARIO implementare un sensore composito TYPE_ROTATION_VECTOR.

7.3.2. Magnetometro

  • Le implementazioni dei dispositivi DEVONO includere un magnetometro a 3 assi (bussola).

Se le implementazioni del dispositivo includono un magnetometro a tre assi, devono:

  • [C-1-1] È NECESSARIO implementare il sensore TYPE_MAGNETIC_FIELD.
  • [C-1-2] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 10 Hz e DOVREBBE registrare eventi fino ad almeno 50 Hz.
  • [C-1-3] DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nelle API Android.
  • [C-1-4] DEVE essere in grado di misurare tra -900 µT e +900 µT su ogni asse prima della saturazione.
  • [C-1-5] 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).
  • [C-1-6] DEVE avere una risoluzione uguale o superiore a 0,6 µT.
  • [C-1-7] DEVE supportare la calibrazione e la compensazione online del bias hardware e conservare i parametri di compensazione tra i riavvii del dispositivo.
  • [C-1-8] È OBBLIGATORIO applicare la compensazione del ferro dolce. La calibrazione può essere eseguita durante l'uso o durante la produzione del dispositivo.
  • [C-1-9] DEVE avere una deviazione standard, calcolata in base all'asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più elevata, non superiore a 1,5 µT; DEVE avere una deviazione standard non superiore a 0,5 µT.
  • DOVREBBE implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] È FORTEMENTE CONSIGLIATO di implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED sui dispositivi Android esistenti e nuovi.

Se le implementazioni del dispositivo includono un magnetometro a 3 assi, un sensore di accelerometro e un sensore di giroscopio:

  • [C-2-1] È NECESSARIO implementare un sensore composito TYPE_ROTATION_VECTOR.

Se le implementazioni del dispositivo includono un magnetometro a 3 assi, un accelerometro:

  • PUO' implementare il sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Se le implementazioni del dispositivo includono un magnetometro a 3 assi, un accelerometro e un sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR, devono:

  • [C-3-1] DEVE consumare meno di 10 mW.
  • DEVE consumare meno di 3 mW quando il sensore è registrato per la modalità batch a 10 Hz.

7.3.3. GPS

Implementazioni dei dispositivi:

  • DEVE includere un ricevitore GPS/GNSS.

Se le implementazioni dei dispositivi includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag di funzionalità android.hardware.location.gps:

  • [C-1-1] DEVE supportare le uscite di posizione a una frequenza di almeno 1 Hz quando richieste tramite LocationManager#requestLocationUpdate.
  • [C-1-2] DEVE essere in grado di determinare la posizione in condizioni di cielo aperto (segnali forti, multipath trascurabile, HDOP < 2) entro 10 secondi (tempo di prima correzione rapido), quando è connesso a una connessione a internet con velocità di dati di almeno 0,5 Mbps. Questo requisito viene generalmente soddisfatto mediante l'utilizzo di una qualche forma di tecnica GPS/GNSS assistita o prevista per ridurre al minimo il tempo di accoppiamento GPS/GNSS (i dati di assistenza includono ora di riferimento, posizione di riferimento ed effemeride/orologio satellitare).
    • [SR] Dopo aver effettuato questo calcolo della posizione, è FORTEMENTE CONSIGLIATO che il dispositivo sia in grado di determinare la propria posizione, a cielo aperto, entro 10 secondi, quando le richieste di geolocalizzazione vengono riavviate, fino a un'ora dopo il calcolo della posizione iniziale, anche quando la richiesta successiva viene effettuata senza una connessione dati e/o dopo un ciclo di alimentazione.

  • In condizioni di cielo aperto dopo aver determinato la posizione, a veicolo fermo o in movimento con un'accelerazione inferiore a 1 metro al secondo quadrato:

    • [C-1-3] DEVE essere in grado di determinare la posizione entro 20 metri e la velocità entro 0, 5 metri al secondo, almeno il 95% delle volte.
    • [C-1-4] DEVE monitorare e segnalare contemporaneamente tramite GnssStatus.Callback almeno 8 satelliti di una costellazione.
    • DOVREBBE essere in grado di rilevare contemporaneamente almeno 24 satelliti di più costellazioni (ad es. GPS + almeno uno di Glonass, Beidou, Galileo).
    • [C-1-5] DEVE segnalare la generazione della tecnologia GNSS tramite l'API di test "getGnssYearOfHardware".
    • [SR] Continuare a fornire normali output di posizione GPS/GNSS durante una chiamata di emergenza.
    • [SR] Segnala le misurazioni GNSS di tutte le costellazioni monitorate (come indicato nei messaggi GnssStatus), ad eccezione di SBAS.
    • [SR] Segnala AGC e la frequenza della misurazione GNSS.
    • [SR] Segnala tutte le stime di accuratezza (incluse direzione, velocità e verticale) all'interno di ogni posizione GPS.
    • [SR] È FORTEMENTE CONSIGLIATO soddisfare il maggior numero possibile di requisiti obbligatori aggiuntivi per i dispositivi che riportano l'anno "2016" o "2017" tramite l'API di test LocationManager.getGnssYearOfHardware().

Se le implementazioni dei dispositivi includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag di funzionalità android.hardware.location.gps e l'API di test LocationManager.getGnssYearOfHardware() riportano l'anno "2016" o versioni successive, devono:

  • [C-2-1] DEVE segnalare le misurazioni GPS non appena vengono rilevate, anche se una posizione calcolata dal GPS/GNSS non è ancora stata segnalata.
  • [C-2-2] DEVE segnalare pseudorange e tassi di pseudorange GPS che, in condizioni di cielo aperto dopo aver determinato la posizione, mentre sono fermi o si muovono con un'accelerazione inferiore a 0, 2 metri al secondo quadrato, sono sufficienti per calcolare la posizione entro 20 metri e la velocità entro 0, 2 metri al secondo, almeno il 95% delle volte.

Se le implementazioni dei dispositivi includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag di funzionalità android.hardware.location.gps e l'API di test LocationManager.getGnssYearOfHardware() riportano l'anno "2017" o versioni successive, devono:

  • [C-3-1] DEVE continuare a fornire normali output di posizione GPS/GNSS durante una chiamata di emergenza.
  • [C-3-2] DEVE segnalare le misurazioni GNSS di tutte le costellazioni monitorate (come indicato nei messaggi GnssStatus), ad eccezione di SBAS.
  • [C-3-3] È OBBLIGATORIO segnalare l'AGC e la frequenza della misurazione GNSS.
  • [C-3-4] È OBBLIGATORIO segnalare tutte le stime di accuratezza (tra cui direzione, velocità e verticale) all'interno di ogni posizione GPS.

7.3.4. Giroscopio

Implementazioni dei dispositivi:

  • DEVE includere un giroscopio (sensore di variazione angolare).
  • NON DEVE includere un sensore giroscopio, a meno che non sia incluso anche un accelerometro a 3 assi.

Se le implementazioni del dispositivo includono un giroscopio:

  • [C-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 50 Hz.
  • [C-1-2] DEVE implementare il sensore TYPE_GYROSCOPE e DOVREBBE implementare anche il sensore TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-3] DEVE essere in grado di misurare le variazioni di orientamento fino a 1000 gradi al secondo.
  • [C-1-4] DEVE avere una risoluzione di almeno 12 bit e DOVREBBE avere una risoluzione di almeno 16 bit.
  • [C-1-5] DEVE essere compensato in base alla temperatura.
  • [C-1-6] DEVE essere calibrato e compensato durante l'uso e deve conservare i parametri di compensazione tra i riavvii del dispositivo.
  • [C-1-7] DEVE avere una varianza non superiore a 1e-7 rad^2 / s^2 per Hz (varianza per Hz o rad^2 / s). La varianza può variare con la frequenza di campionamento, ma DEVE essere vincolata da questo valore. In altre parole, se misuri la varianza del giroscopio a una frequenza di campionamento di 1 Hz, NON deve essere superiore a 1e-7 rad^2/s^2.
  • [SR] È FORTEMENTE CONSIGLIATO di implementare il sensore SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sui dispositivi Android esistenti e nuovi.
  • [SR] È FORTEMENTE CONSIGLIATO che l'errore di calibrazione sia inferiore a 0,01 rad/s quando il dispositivo è fermo a temperatura ambiente.
  • DEVE registrare eventi fino ad almeno 200 Hz.

Se le implementazioni del dispositivo includono un giroscopio, un sensore di accelerazione e un sensore di magnete:

  • [C-2-1] È NECESSARIO implementare un sensore composito TYPE_ROTATION_VECTOR.

Se le implementazioni del dispositivo includono un giroscopio e un sensore di accelerazione, devono:

  • [C-3-1] È NECESSARIO implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • [SR] È FORTEMENTE CONSIGLIATO di implementare il sensore TYPE_GAME_ROTATION_VECTOR sui dispositivi Android esistenti e nuovi.
  • DEVE implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometro

  • Le implementazioni dei dispositivi DEVONO includere un barometro (sensore di pressione dell'aria ambiente).

Se le implementazioni del dispositivo includono un barometro:

  • [C-1-1] È NECESSARIO implementare e segnalare il sensore TYPE_PRESSURE.
  • [C-1-2] DEVE essere in grado di inviare eventi a una frequenza minima di 5 Hz.
  • [C-1-3] DEVE essere compensato in base alla temperatura.
  • [SR] FORTEMENTE CONSIGLIATO per poter registrare misurazioni della pressione nell'intervallo da 300 hPa a 1100 hPa.
  • DEVE avere una precisione assoluta di 1 hPa.
  • DEVE avere una precisione relativa di 0,12 hPa su un intervallo di 20 hPa (equivalente a una precisione di circa 1 m su una variazione di circa 200 m a livello del mare).

7.3.6. Termometro

Implementazioni del dispositivo: POSSONO includere un termometro ambiente (sensore di temperatura). PUO\', ma NON DEVE, includere un sensore di temperatura della CPU.

Se le implementazioni del dispositivo includono un termometro ambiente (sensore di temperatura), devono:

  • [C-1-1] DEVE essere definito come SENSOR_TYPE_AMBIENT_TEMPERATURE e DEVE misurare la temperatura ambiente (della stanza/della cabina del veicolo) da dove l'utente interagisce con il dispositivo in gradi Celsius.
  • [C-1-2] DEVE essere definito come SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] DEVE misurare la temperatura della CPU del dispositivo.
  • [C-1-4] 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à.

Se le implementazioni del dispositivo includono un sensore di prossimità:

  • [C-1-1] DEVE misurare la prossimità 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 le implementazioni del dispositivo includono un sensore di prossimità con qualsiasi altro orientamento, NON DEVE essere accessibile tramite questa API.
  • [C-1-2] DEVE avere una precisione di almeno 1 bit.

7.3.9. Sensori ad alta fedeltà

Se le implementazioni dei dispositivi includono un insieme di sensori di qualità superiore come definito in questa sezione e li rendono disponibili per le app di terze parti, devono:

  • [C-1-1] DEVE identificare la funzionalità tramite il flag funzionalità android.hardware.sensor.hifi_sensors.

Se le implementazioni del dispositivo dichiarano android.hardware.sensor.hifi_sensors:

  • [C-2-1] DEVE avere un sensore TYPE_ACCELEROMETER che:

    • DEVE avere un intervallo di misurazione compreso tra almeno -8 g e +8 g.
    • DEVE avere una risoluzione di misurazione di almeno 1024 LSB/g.
    • DEVE avere una frequenza di misurazione minima pari o inferiore a 12,5 Hz.
    • DEVE avere una frequenza di misurazione massima di almeno 400 Hz.
    • DEVE avere un rumore di misurazione non superiore a 400 μG/√Hz.
    • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore.
    • DEVE avere un consumo energetico per il raggruppamento non superiore a 3 mW.
    • DEVE avere una stabilità del bias del rumore stazionario inferiore a 15 μg √Hz dal set di dati statico di 24 ore.
    • DOVREBBE avere una variazione di bias rispetto alla temperatura di ≤ +/- 1 mg / °C.
    • DEVE avere una non linearità della linea di adattamento ottimale pari o inferiore allo 0,5% e una variazione di sensibilità rispetto alla temperatura pari o inferiore allo 0,03%/°C.
    • DEVE avere uno spettro di rumore bianco per garantire una qualificazione adeguata dell'integrità del rumore del sensore.

  • [C-2-2] DEVE avere un TYPE_ACCELEROMETER_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_ACCELEROMETER.

  • [C-2-3] DEVE avere un sensore TYPE_GYROSCOPE che:

    • DEVE avere un intervallo di misurazione compreso tra almeno -1000 e +1000 dps.
    • DEVE avere una risoluzione di misurazione di almeno 16 LSB/dps.
    • DEVE avere una frequenza di misurazione minima pari o inferiore a 12,5 Hz.
    • DEVE avere una frequenza di misurazione massima di almeno 400 Hz.
    • DEVE avere un rumore di misurazione non superiore a 0,014°/s/√Hz.
    • DEVE avere una stabilità del bias stazionario inferiore a 0,0002 °/s √Hz dal set di dati statico di 24 ore.
    • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 0,05 °/ s / °C.
    • DOVREBBE avere una variazione di sensibilità rispetto alla temperatura di ≤ 0,02% / °C.
    • DEVE avere una non linearità della linea di miglior adattamento pari o inferiore allo 0,2%.
    • DEVE avere una densità di rumore ≤ 0,007 °/s/√Hz.
    • DEVE avere uno spettro di rumore bianco per garantire una qualificazione adeguata dell'integrità del rumore del sensore.
    • DEVE avere un errore di calibrazione inferiore a 0,002 rad/s nell'intervallo di temperatura compreso tra 10 e 40 °C quando il dispositivo è fermo.

  • [C-2-4] DEVE avere un TYPE_GYROSCOPE_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GYROSCOPE.

  • [C-2-5] DEVE avere un sensore TYPE_GEOMAGNETIC_FIELD che:
    • DEVE avere un intervallo di misurazione compreso tra almeno -900 e +900 uT.
    • DEVE avere una risoluzione di misurazione di almeno 5 LSB/uT.
    • DEVE avere una frequenza di misurazione minima pari o inferiore a 5 Hz.
    • DEVE avere una frequenza di misurazione massima di 50 Hz o superiore.
    • DEVE avere un rumore di misurazione non superiore a 0,5 uT.
  • [C-2-6] DEVE avere un TYPE_MAGNETIC_FIELD_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GEOMAGNETIC_FIELD e, inoltre:
    • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 600 eventi del sensore.
    • DEVE avere uno spettro di rumore bianco per garantire una qualificazione adeguata dell'integrità del rumore del sensore.
  • [C-2-7] DEVE avere un sensore TYPE_PRESSURE che:
    • DEVE avere un intervallo di misurazione compreso tra almeno 300 e 1100 hPa.
    • DEVE avere una risoluzione di misurazione di almeno 80 LSB/hPa.
    • DEVE avere una frequenza di misurazione minima pari o inferiore a 1 Hz.
    • DEVE avere una frequenza di misurazione massima di almeno 10 Hz.
    • DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz.
    • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
    • DEVE avere un consumo energetico per il raggruppamento non superiore a 2 mW.
  • [C-2-8] DEVE avere un sensore TYPE_GAME_ROTATION_VECTOR che:
    • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
    • DEVE avere un consumo energetico per l'aggregazione non superiore a 4 mW.
  • [C-2-9] DEVE avere un sensore TYPE_SIGNIFICANT_MOTION che:
    • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
  • [C-2-10] DEVE avere un sensore TYPE_STEP_DETECTOR che:
    • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 100 eventi del sensore.
    • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
    • DEVE avere un consumo energetico per l'aggregazione non superiore a 4 mW.
  • [C-2-11] DEVE avere un sensore TYPE_STEP_COUNTER che:
    • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
  • [C-2-12] DEVE avere un sensore TILT_DETECTOR che:
    • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
  • [C-2-13] Il timestamp dello stesso evento fisico registrato dall'accelerometro, dal sensore giroscopico e dal magnetometro DEVE essere compreso tra 2,5 millisecondi.
  • [C-2-14] DEVE avere i timestamp degli eventi del sensore giroscopico sulla stessa base di tempo del sottosistema della videocamera e con un errore massimo di 1 millisecondo.
  • [C-2-15] DEVE inviare i campioni alle applicazioni entro 5 millisecondi dal momento in cui i dati sono disponibili su uno dei sensori fisici sopra indicati per l'applicazione.
  • [C-2-16] NON deve avere un consumo di energia superiore a 0,5 mW quando il dispositivo è fermo e 2,0 mW quando il dispositivo è in movimento quando è attiva qualsiasi combinazione dei seguenti sensori:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] PUO' avere un sensore TYPE_PROXIMITY, ma se presente DEVE avere una capacità di buffer minima di 100 eventi del sensore.

Tieni presente che tutti i requisiti di consumo energetico in questa sezione non includono il consumo energetico dell'Application Processor. Sono incluse le potenze assorbite dall'intera catena del sensore: il sensore, eventuali circuiti di supporto, qualsiasi sistema di elaborazione del sensore dedicato e così via.

Se le implementazioni dei dispositivi includono il supporto diretto dei sensori, devono:

  • [C-3-1] È NECESSARIO dichiarare correttamente il supporto dei tipi di canali diretti e del livello di frequenza dei report diretti tramite le API isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
  • [C-3-2] DEVE supportare almeno uno dei due tipi di canali diretti del sensore per tutti i sensori che dichiarano il supporto del canale diretto del sensore
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
  • DOVREBBE supportare la generazione di report sugli eventi tramite il canale diretto del sensore per il sensore principale (variante non sveglia) dei seguenti tipi:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensore di impronte digitali

Se le implementazioni del dispositivo includono una schermata di blocco sicura:

  • DEVE includere un sensore di impronte digitali.

Se le implementazioni del dispositivo includono un sensore di impronte e lo rendono disponibile per le app di terze parti, devono:

  • [C-1-1] DEVE dichiarare il supporto della funzionalità android.hardware.fingerprint.
  • [C-1-2] DEVE implementare completamente l'API corrispondente come descritto nella documentazione dell'SDK Android.
  • [C-1-3] DEVE avere un tasso di accettazione di falsi positivi non superiore allo 0,002%.
  • [SR] È FORTEMENTE CONSIGLIATO di avere un tasso di accettazione di attività fraudolente e di furto d'identità non superiore al 7%.
  • [C-1-4] È OBBLIGATORIO indicare che questa modalità potrebbe essere meno sicura di una sequenza, un PIN o una password efficaci ed elencare chiaramente i rischi di attivazione, se i tassi di accettazione di spoofing e furto d'identità sono superiori al 7%.
  • [C-1-5] È OBBLIGATORIO applicare un limite di frequenza dei tentativi per almeno 30 secondi dopo cinque tentativi falsi per la verifica dell'impronta.
  • [C-1-6] DEVE avere un'implementazione del keystore basata su hardware ed eseguire la corrispondenza delle impronte in un Trusted Execution Environment (TEE) o su un chip con un canale sicuro per il TEE.
  • [C-1-7] DEVE avere tutti i dati delle impronte identificabili criptati e autenticati tramite crittografia in modo che non possano essere acquisiti, letti o alterati al di fuori del Trusted Execution Environment (TEE), come documentato nelle linee guida per l'implementazione sul sito del progetto open source Android.
  • [C-1-8] DEVE impedire l'aggiunta di un'impronta senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare una credenziale del dispositivo esistente o di aggiungerne una nuova (PIN/pattern/password) protetta dal TEE; l'implementazione del progetto open source Android fornisce il meccanismo nel framework per farlo.
  • [C-1-9] NON DEVE consentire ad applicazioni di terze parti di distinguere tra impronte individuali.
  • [C-1-10] DEVE rispettare il flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • [C-1-11] È NECESSARIO, quando viene eseguito l'upgrade da una versione precedente ad Android 6.0, eseguire la migrazione sicura dei dati delle impronte per soddisfare i requisiti precedenti o rimuoverli.
  • [SR] È FORTEMENTE CONSIGLIATO di avere un tasso di falsi rifiuti inferiore al 10%, misurato sul dispositivo.
  • [SR] È MOLTO CONSIGLIATO avere una latenza inferiore a 1 secondo, misurata dal momento in cui viene toccato il sensore di impronte digitali fino al momento in cui lo schermo viene sbloccato, per un dito registrato.
  • DEBBA utilizzare l'icona Impronta Android fornita nell'Android Open Source Project.

7.3.11. Sensori solo per Android Automotive

I sensori specifici per i veicoli a motore sono definiti in android.car.CarSensorManager API.

7.3.11.1. Marcia attuale

Per i requisiti specifici dei dispositivi, consulta la sezione 2.5.1.

7.3.11.2. Modalità Giorno/Notte

Per i requisiti specifici del dispositivo, consulta la sezione 2.5.1.

7.3.11.3. Stato di guida

Per i requisiti specifici del dispositivo, consulta la sezione 2.5.1.

7.3.11.4. Velocità della ruota

Per i requisiti specifici del dispositivo, consulta la sezione 2.5.1.

7.3.12. Sensore di posizione

Implementazioni dei dispositivi:

  • PUO' supportare il sensore di posa con 6 gradi di libertà.

Se le implementazioni del dispositivo supportano il sensore di posizione con 6 gradi di libertà, devono:

  • [C-1-1] È NECESSARIO implementare e segnalare il sensore TYPE_POSE_6DOF.
  • [C-1-2] DEVE essere più preciso del solo vettore di rotazione.

7.4. Connettività dei dati

7.4.1. Telefonia

Per "Telefonia", come utilizzato dalle API Android e in questo documento, si intende in modo specifico l'hardware relativo all'invio di chiamate vocali e di messaggi SMS tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano o meno essere con commutazione di pacchetti, ai fini di Android sono considerate indipendenti da qualsiasi connettività dati che possa essere implementata utilizzando la stessa rete. In altre parole, le API e la funzionalità "telefonia" di Android si riferiscono specificamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni di dispositivi che non possono effettuare chiamate o inviare/ricevere messaggi SMS non sono considerate dispositivi di telefonia, 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.

Se le implementazioni dei dispositivi includono la telefonia GSM o CDMA, devono:

  • [C-1-1] DEVE dichiarare il flag funzionalità android.hardware.telephony e altri flag delle sottofunzionalità in base alla tecnologia.
  • [C-1-2] DEVE implementare il supporto completo dell'API per la tecnologia in questione.

Se le implementazioni dei dispositivi non includono hardware di telefonia, devono:

  • [C-2-1] È OBBLIGATORIO implementare le API complete come no-op.
7.4.1.1. Compatibilità con il blocco dei numeri

Se le implementazioni dei dispositivi segnalano il valore android.hardware.telephony feature:

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

Se le implementazioni dei dispositivi segnalano android.hardware.telephony:

  • [C-SR] È FORTEMENTE CONSIGLIATO gestire gli eventi KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK dell'audio headset per le API android.telecom come indicato di seguito:
    • Chiama Connection.onDisconnect() quando viene rilevata una breve pressione dell'evento chiave durante una chiamata in corso.
    • Chiama Connection.onAnswer() quando viene rilevata una breve pressione dell'evento chiave durante una chiamata in arrivo.
    • Chiama Connection.onReject() quando viene rilevata una pressione prolungata dell'evento chiave durante una chiamata in arrivo.
    • Attiva/disattiva lo stato di disattivazione dell'audio del CallAudioState

7.4.2. IEEE 802.11 (Wi-Fi)

Implementazioni dei dispositivi:

  • DEVE includere il supporto di una o più forme di 802.11.

Se le implementazioni dei dispositivi includono il supporto per 802.11 e mettono a disposizione la funzionalità a un'applicazione di terze parti,

  • [C-1-1] DEVE implementare l'API Android corrispondente.
  • [C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.wifi.
  • [C-1-3] DEVE implementare l'API multicast come descritto nella documentazione dell'SDK.
  • [C-1-4] DEVE supportare il DNS multicast (mDNS) e NON DEVE filtrare i pacchetti mDNS (224.0.0.251) in qualsiasi momento di funzionamento, inclusi:
    • Anche quando lo schermo non è attivo.
    • Per le implementazioni dei dispositivi Android TV, anche in stato di alimentazione in standby.
  • DOVREBBE randomizzare l'indirizzo MAC di origine e il numero di sequenza dei frame di richiesta di prova, una volta all'inizio di ogni scansione, mentre lo STA è disconnesso.
    • Ogni gruppo di frame di richiesta di prova che comprende una scansione deve utilizzare un indirizzo MAC coerente (NON DEVE essere randomizzato a metà scansione).
    • Il numero di sequenza della richiesta di probe deve essere eseguito normalmente (in sequenza) tra le richieste di probe in una scansione
    • Il numero di sequenza della richiesta di probe deve essere casuale tra l'ultima richiesta di probe di una scansione e la prima richiesta di probe della scansione successiva
  • DOVREBBE consentire solo i seguenti elementi di informazione nei frame di richiesta di prova, mentre lo STA è disconnesso:
    • Set di parametri SSID (0)
    • DS Parameter Set (3)
7.4.2.1. Wi-Fi Direct

Implementazioni dei dispositivi:

  • DEVE includere il supporto di Wi-Fi Direct (Wi-Fi peer-to-peer).

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Direct:

  • [C-1-1] DEVE implementare l'API Android corrispondente come descritto nella documentazione dell'SDK.
  • [C-1-2] DEVE segnalare la funzionalità hardware android.hardware.wifi.direct.
  • [C-1-3] DEVE supportare il normale funzionamento del Wi-Fi.
  • DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Direct.

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi includono il supporto di TDLS e TDLS è abilitato dall'API WiFiManager, i dispositivi:

  • [C-1-1] È OBBLIGATORIO dichiarare il supporto di TDLS tramite WifiManager.isTdlsSupported.
  • 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.2.3. Wi-Fi Aware

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Aware e mettono a disposizione la funzionalità per le app di terze parti, devono:

  • [C-1-1] DEVE implementare le API WifiAwareManager come descritto nella documentazione dell'SDK.
  • [C-1-2] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.wifi.aware.
  • [C-1-3] DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Aware.
  • [C-1-4] DEVE randomizzare l'indirizzo dell'interfaccia di gestione Wi-Fi Aware a intervalli non superiori a 30 minuti e ogni volta che Wi-Fi Aware è attivato.
7.4.2.4. Wi-Fi Passpoint

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Passpoint:

  • [C-1-1] DEVE implementare le API WifiManager relative a Passpoint come descritto nella documentazione dell'SDK.
  • [C-1-2] DEVE supportare lo standard IEEE 802.11u, in particolare per quanto riguarda la rilevamento e la selezione della rete, come il servizio Generic Advertisement Service (GAS) e il protocollo Access Network Query Protocol (ANQP).

Al contrario, se le implementazioni dei dispositivi non includono il supporto di Wi-Fi Passpoint:

  • [C-2-1] L'implementazione delle API WifiManager relative a Passpoint DEVE generare un UnsupportedOperationException.

7.4.3. Bluetooth

Se le implementazioni dei dispositivi supportano il profilo Bluetooth Audio:

  • DOVREBBE supportare codec audio avanzati e codec audio Bluetooth (ad es. LDAC).

Se le implementazioni del dispositivo dichiarano la funzionalità android.hardware.vr.high_performance:

  • [C-1-1] DEVE supportare Bluetooth 4.2 e l'estensione della lunghezza dei dati Bluetooth LE.

Android include il supporto per Bluetooth e Bluetooth Low Energy.

Se le implementazioni dei dispositivi includono il supporto di Bluetooth e Bluetooth Low Energy:

  • [C-2-1] DEVE dichiarare le funzionalità della piattaforma pertinenti (rispettivamente android.hardware.bluetooth e android.hardware.bluetooth_le) e implementare le API della piattaforma.
  • DEVE implementare profili Bluetooth pertinenti come A2DP, AVCP, OBEX e così via, a seconda del dispositivo.

Se le implementazioni dei dispositivi includono il supporto di Bluetooth Low Energy:

  • [C-3-1] È OBBLIGATORIO dichiarare la funzionalità hardware android.hardware.bluetooth_le.
  • [C-3-2] È NECESSARIO attivare le API Bluetooth basate su GATT (Generic Attribute Profile) come descritto nella documentazione dell'SDK e in android.bluetooth.
  • [C-3-3] DEVE riportare il valore corretto per BluetoothAdapter.isOffloadedFilteringSupported() per indicare se è implementata la logica di filtro per le classi dell'API ScanFilter.
  • [C-3-4] È OBBLIGATORIO indicare il valore corretto per BluetoothAdapter.isMultipleAdvertisementSupported() per indicare se la pubblicità a basso consumo energetico è supportata.
  • DOVREBBE supportare lo sgravio della logica di filtro sul chipset Bluetooth durante l'implementazione dell'API ScanFilter.
  • DOVREBBE supportare lo sgravio della scansione collettiva sul chipset Bluetooth.

  • DEVE supportare più annunci con almeno 4 slot.

  • [RP] È FORTEMENTE CONSIGLIATO implementare un timeout per gli indirizzi privati risolvibili (RPA) non superiore a 15 minuti e ruotare l'indirizzo al termine del timeout per proteggere la privacy dell'utente.

7.4.4. Near Field Communication

Implementazioni dei dispositivi:

  • DOVREBBE includere un transceiver e hardware correlato per la tecnologia Near Field Communication (NFC).
  • [C-0-1] DEVE implementare le API android.nfc.NdefMessage e android.nfc.NdefRecord anche se non includono il supporto per NFC o dichiarano la funzionalità android.hardware.nfc poiché le classi rappresentano un formato di rappresentazione dei dati indipendente dal protocollo.

Se le implementazioni dei dispositivi includono hardware NFC e prevedono di renderlo disponibile per le app di terze parti, devono:

  • [C-1-1] DEVE segnalare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature().
  • DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC:
  • [C-1-2] DEVE essere in grado di agire come lettore/scrittore NFC Forum (come definito dalla specifica tecnica NFC Forum NFCForum-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Tipi di tag NFC Forum 1, 2, 3, 4, 5 (definiti dal NFC Forum)

  • [SR] FORTEMENTE CONSIGLIATO di essere in grado di leggere e scrivere messaggi NDEF e dati non elaborati tramite i seguenti standard NFC. Tieni presente che, sebbene gli standard NFC siano indicati come FORTEMENTE CONSIGLIATI, è previsto che la definizione di compatibilità per una versione futura li modifichi in OBBLIGATORI. Questi standard sono facoltativi in questa versione, ma saranno obbligatori nelle versioni future. I dispositivi esistenti e nuovi che eseguono questa versione di Android sono vivamente invitati a soddisfare questi requisiti ora, in modo da poter eseguire l'upgrade alle release future della piattaforma.

  • [C-1-3] DEVE essere in grado di trasmettere e ricevere dati tramite i seguenti standard e protocolli peer-to-peer:

  • ISO 18092
  • LLCP 1.2 (definito dal NFC Forum)
  • SDP 1.0 (definito dal NFC Forum)
  • Protocollo push NDEF
  • SNEP 1.0 (definito dal NFC Forum)
  • [C-1-4] DEVE includere il supporto di Android Beam e DOVREBBE attivare Android Beam per impostazione predefinita.
  • [C-1-5] DEVE essere in grado di inviare e ricevere utilizzando Android Beam, quando questa funzionalità è attivata o è attivata un'altra modalità P2P NFC proprietaria.
  • [C-1-6] DEVE implementare il server SNEP predefinito. I messaggi NDEF validi ricevuti dal server SNEP predefinito DEVONO essere inviati alle applicazioni che utilizzano l'intent android.nfc.ACTION_NDEF_DISCOVERED. La disattivazione di Android Beam nelle impostazioni NON DEVE disattivare l'invio del messaggio NDEF in arrivo.
  • [C-1-7] DEVE rispettare l'intent android.settings.NFCSHARING_SETTINGS per mostrare le impostazioni di condivisione NFC.
  • [C-1-8] È OBBLIGATORIO implementare il server NPP. I messaggi ricevuti dal server NPP DEVONO essere elaborati nello stesso modo del server SNEP predefinito.
  • [C-1-9] DEVE implementare un client SNEP e tentare di inviare NDEF P2P in uscita al server SNEP predefinito quando Android Beam è abilitato. Se non viene trovato alcun server SNEP predefinito, il client DEVE tentare di inviare a un server NPP.
  • [C-1-10] 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.
  • [C-1-11] DEVE supportare il trasferimento della connessione NFC al Bluetooth quando il dispositivo supporta il profilo Bluetooth Object Push.
  • [C-1-12] DEVE supportare il trasferimento della connessione al Bluetooth quando si utilizza android.nfc.NfcAdapter.setBeamPushUris, implementando le specifiche "Connection Handover version 1.2" e "Bluetooth Secure Simple Pairing Using NFC version 1.0" del NFC Forum. Una simile implementazione DEVE implementare il servizio LLCP di trasferimento con il nome di servizio "urn:nfc:sn:handover" per lo scambio dei record di richiesta/selezione del trasferimento tramite NFC e DEVE utilizzare il profilo Bluetooth Object Push per il trasferimento effettivo dei dati Bluetooth. Per motivi di compatibilità con i dispositivi Android 4.1, l'implementazione DOVREBBE comunque accettare le richieste GET SNEP per lo scambio della richiesta di trasferimento/seleziona i record tramite NFC. Tuttavia, un'implementazione stessa NON DEVE inviare richieste GET SNEP per eseguire il trasferimento della connessione.
  • [C-1-13] DEVE eseguire la ricerca di 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.
  • DOVREBBE essere in grado di leggere il codice a barre e l'URL (se codificato) dei prodotti Thinfilm NFC Barcode.

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

Android include il supporto per la modalità NFC Host Card Emulation (HCE).

Se le implementazioni dei dispositivi includono un chipset del controller NFC in grado di supportare HCE (per NfcA e/o NfcB) e supportano il routing dell'ID applicazione (AID), devono:

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

Se le implementazioni del dispositivo includono un chipset del controller NFC in grado di supportare HCE per NfcF e implementano la funzionalità per applicazioni di terze parti, devono:

  • [C-3-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.nfc.hcef.
  • [C-3-2] DEVE implementare le API di emulazione di carte NfcF come definite nell'SDK Android.

Se le implementazioni dei dispositivi includono il supporto generale NFC come descritto in questa sezione e supportano le tecnologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF su MIFARE Classic) nel ruolo di lettore/scrittore, devono:

  • [C-4-1] DEVE implementare le API Android corrispondenti come documentato dall'SDK Android.
  • [C-4-2] DEVE segnalare la funzionalità com.nxp.mifare dal metodo android.content.pm.PackageManager.hasSystemFeature(). Tieni presente che questa non è una funzionalità standard di Android e, pertanto, non viene visualizzata come costante nella classe android.content.pm.PackageManager.

7.4.5. Capacità di rete minima

Implementazioni dei dispositivi:

  • [C-0-1] DEVE includere il supporto di una o più forme di reti di dati. Nello specifico, le implementazioni dei dispositivi DEVONO includere il supporto di almeno uno standard di dati in grado di supportare velocità di almeno 200 Kbit/s. Alcuni esempi di tecnologie che soddisfano questo requisito sono EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN e così via.
  • [C-0-2] DEVE includere uno stack di rete IPv6 e supportare la comunicazione IPv6 utilizzando le API gestite, come java.net.Socket e java.net.URLConnection, nonché le API native, come le socket AF_INET6.
  • [C-0-3] DEVE attivare IPv6 per impostazione predefinita.
  • DEVE garantire che la comunicazione IPv6 sia affidabile come quella IPv4, ad esempio.
  • [C-0-4] DEVE mantenere la connettività IPv6 in modalità sospensione.
  • [C-0-5] Il limite di velocità NON DEVE causare la perdita della connettività IPv6 sul dispositivo su qualsiasi rete IPv6 conforme che utilizza durate RA di almeno 180 secondi.
  • DEVE includere anche il supporto di almeno uno standard di dati wireless comune, come 802.11 (Wi-Fi), quando uno standard di rete fisica (come Ethernet) è la connessione dati principale
  • PUO' implementare più di una forma di connettività dei dati.

Il livello di supporto IPv6 richiesto dipende dal tipo di rete, come segue:

Se le implementazioni dei dispositivi supportano le reti Wi-Fi:

  • [C-1-1] DEVE supportare il funzionamento a doppio stack e solo IPv6 su Wi-Fi.

Se le implementazioni dei dispositivi supportano le reti Ethernet:

  • [C-2-1] DEVE supportare il funzionamento dual-stack su Ethernet.

Se le implementazioni dei dispositivi supportano i dati di rete mobile:

  • [C-3-1] DEVE soddisfare contemporaneamente questi requisiti su ogni rete a cui è connesso quando un dispositivo è connesso contemporaneamente a più di una rete (ad es. Wi-Fi e rete dati).
  • DOVREBBE supportare il funzionamento IPv6 (solo IPv6 ed eventualmente a doppio stack) sulla rete dati.

7.4.6. Impostazioni sincronizzazione

Implementazioni dei dispositivi:

  • [C-0-1] L'impostazione di sincronizzazione automatica principale DEVE essere attiva per impostazione predefinita in modo che il metodo getMasterSyncAutomatically() restituisca "true".

7.4.7. Risparmio dati

Se le implementazioni dei dispositivi includono una connessione con misuratore, sono:

  • [SR] MOLTO CONSIGLIATO fornire la modalità Risparmio dati.

Se le implementazioni dei dispositivi forniscono la modalità Risparmio dati, devono:

Se le implementazioni dei dispositivi non forniscono la modalità Risparmio dati, devono:

  • [C-2-1] DEVE restituire il valore RESTRICT_BACKGROUND_STATUS_DISABLED per ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] NON DEVE trasmettere ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • [C-2-3] DEVE avere un'attività che gestisce l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ma PUÒ implementarlo come no-op.

7.5. Fotocamere

Se le implementazioni dei dispositivi includono almeno una videocamera:

  • [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.camera.any.
  • [C-1-2] DEVE essere possibile per un'applicazione allocare contemporaneamente tre bitmap RGBA_8888 uguali alle dimensioni delle immagini prodotte dal sensore della fotocamera con la risoluzione più alta sul dispositivo, mentre la fotocamera è aperta a scopo di anteprima di base e acquisizione di foto.

7.5.1. Fotocamera posteriore

Una fotocamera posteriore è una fotocamera posizionata sul lato del dispositivo opposto al display, ovvero acquisisce le immagini delle scene sul lato opposto del dispositivo, come una fotocamera tradizionale.

Implementazioni dei dispositivi:

  • DOVREBBE includere una fotocamera posteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera posteriore, devono:

  • [C-1-1] È OBBLIGATORIO segnalare i flag funzionalità android.hardware.camera e android.hardware.camera.any.
  • [C-1-2] DEVE avere una risoluzione di almeno 2 megapixel.
  • DEVE avere l'autofocus hardware o l'autofocus software implementato nel driver della fotocamera (trasparente al software dell'applicazione).
  • POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
  • PUO' includere un flash.

Se la videocamera include un flash:

  • [C-2-1] la spia del flash NON DEVE essere accesa quando è 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

Una fotocamera anteriore è una fotocamera situata sullo stesso lato del dispositivo del display, ovvero una fotocamera in genere utilizzata per acquisire immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.

Implementazioni dei dispositivi:

  • PUO' includere una fotocamera anteriore

Se le implementazioni dei dispositivi includono almeno una fotocamera anteriore, devono:

  • [C-1-1] È OBBLIGATORIO segnalare i flag funzionalità android.hardware.camera.any e android.hardware.camera.front.
  • [C-1-2] DEVE avere una risoluzione di almeno VGA (640 x 480 pixel).
  • [C-1-3] NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Camera e NON DEVE configurare l'API in modo da trattare una fotocamera anteriore come fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
  • [C-1-5] L'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto all'orientamento specificato dall'applicazione quando l'applicazione corrente ha richiesto esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation(). Al contrario, l'anteprima DEVE essere speculare rispetto all'asse orizzontale predefinito del dispositivo quando l'applicazione corrente non richiede esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation().
  • [C-1-6] NON DEVE rispecchiare gli stream video o di fermo immagine acquisiti finali restituiti ai callback dell'applicazione o sottoposti a commit nello spazio di archiviazione multimediale.
  • [C-1-7] DEVE rispecchiare l'immagine visualizzata dalla visualizzazione post nello stesso modo dello stream di immagini dell'anteprima della fotocamera.
  • PUO' includere funzionalità (come messa a fuoco automatica, flash e così via) disponibili per le fotocamere posteriori come descritto nella sezione 7.5.1.

Se le implementazioni dei dispositivi possono essere ruotate dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente):

  • [C-2-1] L'anteprima della fotocamera DEVE essere ribaltata orizzontalmente rispetto all'orientamento corrente del dispositivo.

7.5.3. Videocamera esterna

Implementazioni dei dispositivi:

  • POTREBBE includere il supporto di una videocamera esterna non necessariamente sempre connessa.

Se le implementazioni dei dispositivi includono il supporto di una videocamera esterna:

  • [C-1-1] È OBBLIGATORIO dichiarare i flag funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any.
  • [C-1-2] DEVE supportare la classe video USB (UVC 1.0 o versioni successive) se la videocamera esterna si connette tramite la porta USB.
  • DOVREBBE supportare compressioni video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ad es. stream di immagini non compressi o compressi in modo indipendente).
  • POTREBBE supportare più videocamere.
  • POTREBBE supportare la codifica video basata sulla fotocamera. Se supportato, un flusso non codificato / MJPEG simultaneo (risoluzione QVGA o superiore) DEVE essere accessibile all'implementazione del dispositivo.

7.5.4. Comportamento dell'API Camera

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

Il pacchetto API precedente, android.hardware.Camera, è contrassegnato come deprecato in Android 5.0, ma dovrebbe essere ancora disponibile per le app. Le implementazioni dei dispositivi Android DEVONO 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. Implementazioni dei dispositivi:

  • [C-0-1] È OBBLIGATORIO utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione quando un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] DEVE essere inoltre nel formato di codifica NV21 quando un'applicazione registra un'istanza android.hardware.Camera.PreviewCallback e il sistema chiama il metodo onPreviewFrame() e il formato di anteprima è YCbCr_420_SP, i dati in byte[] passati a onPreviewFrame(). In altre parole, NV21 DEVE essere il valore predefinito.
  • [C-0-3] DEVE supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia per le fotocamere anteriori che posteriori per android.hardware.Camera. Il codificatore video hardware e la videocamera possono utilizzare qualsiasi formato di pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione in YV12.
  • [C-0-4] DEVE supportare i formati android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG come output tramite l'API android.media.ImageReader per i dispositivi android.hardware.camera2 che pubblicizzano la funzionalità REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities.
  • [C-0-5] DEVE comunque implementare l'API Camera completa inclusa nella documentazione dell'SDK Android, indipendentemente dal fatto che il dispositivo includa l'autofocus hardware o altre funzionalità. Ad esempio, le fotocamere prive di messa a fuoco automatica DEVONO comunque chiamare le eventuali istanze 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.
  • [C-0-6] DEVE riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters. Al contrario, le implementazioni dei dispositivi NON DEVONO rispettare o riconoscere costanti di stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. In altre parole, le implementazioni dei dispositivi DEVONO supportare tutti i parametri Camera standard, se l'hardware lo consente, e NON DEVONO supportare i tipi di parametri Camera personalizzati. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini utilizzando tecniche di imaging HDR (High Dynamic Range) DEVONO supportare il parametro della fotocamera Camera.SCENE_MODE_HDR.
  • [C-0-7] DEVE segnalare il livello di supporto appropriato con la proprietà android.info.supportedHardwareLevel come descritto nell'SDK Android e segnalare gli flag delle funzionalità del framework appropriati.
  • [C-0-8] DEVE anche dichiarare le singole funzionalità della videocamera di android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag di funzionalità appropriati; DEVE definire il flag di funzionalità se uno dei dispositivi videocamera collegati supporta la funzionalità.
  • [C-0-9] DEVE 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.
  • [C-0-10] DEVE trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e la voce della foto è stata aggiunta al media store.

7.5.5. Orientamento della fotocamera

Se le implementazioni del dispositivo dispongono di una fotocamera anteriore o posteriore, queste fotocamere:

  • [C-1-1] DEVE essere orientata in modo che la dimensione più lunga della fotocamera sia allineata alla dimensione più lunga dello schermo. In altre parole, quando il dispositivo è tenuto in orizzontale, le fotocamere DEVONO acquisire le immagini in orizzontale. Questo vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica ai dispositivi con orientamento principale orizzontale e verticale.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

Implementazioni dei dispositivi:

  • [C-0-1] DEVE includere un gestore dei download che le applicazioni POSSONO utilizzare per scaricare file di dati e DEVE essere in grado di scaricare singoli file di dimensioni di almeno 100 MB nella posizione predefinita "cache".

7.6.2. Spazio di archiviazione condiviso dell'applicazione

Implementazioni dei dispositivi:

  • [C-0-1] DEVE offrire spazio di archiviazione da condividere con le applicazioni, spesso indicato anche come "spazio di archiviazione esterno condiviso", "spazio di archiviazione condiviso per le applicazioni" o dal percorso Linux "/sdcard" su cui è montato.
  • [C-0-2] DEVE essere configurato con lo spazio di archiviazione condiviso montato per impostazione predefinita, in altre parole "out of the box", indipendentemente dal fatto che lo spazio di archiviazione sia implementato su un componente di archiviazione interno o su un supporto di archiviazione rimovibile (ad es. slot per schede Secure Digital).
  • [C-0-3] È NECESSARIO montare lo spazio di archiviazione condiviso dell'applicazione direttamente sul percorso Linux sdcard o includere un link simbolico Linux da sdcard al punto di montaggio effettivo.
  • [C-0-4] È OBBLIGATORIO applicare l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE a questo spazio di archiviazione condiviso, come descritto nell'SDK. In caso contrario, lo spazio di archiviazione condiviso DEVE essere scrivibile da qualsiasi applicazione che ottenga l'autorizzazione.

Le implementazioni dei dispositivi POSSONO soddisfare i requisiti sopra indicati utilizzando:

  • Un'unità di archiviazione rimovibile accessibile all'utente, ad esempio uno slot per schede Secure Digital (SD).
  • una parte della memoria interna (non rimovibile) implementata nell'Android Open Source Project (AOSP).

Se le implementazioni dei dispositivi utilizzano lo spazio di archiviazione rimovibile per soddisfare i requisiti sopra indicati:

  • [C-1-1] DEVE implementare un'interfaccia utente popup o di tipo toast che avvisi l'utente quando non è presente alcun supporto di archiviazione inserito nello slot.
  • [C-1-2] DEVE includere un supporto di archiviazione con formato FAT (ad es. una scheda SD) o indicare sulla confezione e su altro materiale disponibile al momento dell'acquisto che il supporto di archiviazione deve essere acquistato separatamente.

Se le implementazioni dei dispositivi utilizzano una parte dello spazio di archiviazione non rimovibile per soddisfare i requisiti sopra indicati:

  • DOVREBBE utilizzare l'implementazione AOSP dello spazio di archiviazione condiviso dell'applicazione interna.
  • POTREBBE condividere lo spazio di archiviazione con i dati privati dell'applicazione.

Se le implementazioni dei dispositivi includono più percorsi di archiviazione condivisi (ad esempio uno slot per schede SD e una memoria interna condivisa), devono:

  • [C-3-1] DEVE consentire solo alle applicazioni Android preinstallate e privilegiate con l'autorizzazione WRITE_EXTERNAL_STORAGE di scrivere nella memoria esterna secondaria, tranne quando scrivono nelle directory specifiche del pacchetto o all'interno del URI restituito dall'attivazione dell'intent ACTION_OPEN_DOCUMENT_TREE.

Se le implementazioni dei dispositivi dispongono di una porta USB con supporto della modalità periferica USB, devono:

  • [C-3-1] DEVE fornire un meccanismo per accedere ai dati nello spazio di archiviazione condiviso dell'applicazione da un computer host.
  • DOVREBBE esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione multimediale di Android e android.provider.MediaStore.
  • PUO' utilizzare la memoria di massa USB, ma DEVE utilizzare il protocollo Media Transfer per soddisfare questo requisito.

Se le implementazioni dei dispositivi dispongono di una porta USB con modalità periferica USB e supportano il protocollo Media Transfer, devono:

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

7.6.3. Spazio di archiviazione utilizzabile

Se il dispositivo è di natura mobile, a differenza della televisione, le implementazioni del dispositivo sono:

  • [RP] È FORTEMENTE CONSIGLIATO di implementare lo spazio di archiviazione adottabile in una posizione stabile a lungo termine, poiché la disconnessione accidentale può causare la perdita/corruzione dei dati.

Se la porta del dispositivo di archiviazione rimovibile si trova in una posizione stabile a lungo termine, ad esempio all'interno del vano batteria o di un'altra copertura protettiva, le implementazioni del dispositivo sono:

7.7. USB

Se le implementazioni dei dispositivi dispongono di una porta USB:

  • DEVE supportare la modalità periferica USB e DEVE supportare la modalità host USB.

7.7.1. Modalità periferica USB

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità periferica:

  • [C-1-1] La porta DEVE essere connettibile a un host USB con una porta USB standard di tipo A o C.
  • [C-1-2] DEVE riportare il valore corretto di iSerialNumber nel descrittore del dispositivo standard USB tramite android.os.Build.SERIAL.
  • [C-1-3] DEVE rilevare i caricabatterie da 1,5 A e 3 A in base allo standard del resistore di tipo C e DEVE rilevare le modifiche nell'annuncio se supportano USB di tipo C.
  • [SR] La porta DEVE utilizzare il fattore di forma USB micro-B, micro-AB o Type-C. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
  • [SR] La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o attivare la rotazione dello schermo software per tutte le app (inclusa la schermata Home), in modo che il display venga visualizzato correttamente quando il dispositivo è orientato con la porta in basso. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
  • [SR] DOVREBBE implementare il supporto per assorbire una corrente di 1,5 A durante il traffico e il chirp HS come specificato nella specifica di ricarica della batteria USB, revisione 1.2. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
  • [SR] È FORTEMENTE CONSIGLIATO di non supportare metodi di ricarica proprietari che modificano la tensione Vbus oltre i livelli predefiniti o alterano i ruoli di sink/sorgente, in quanto potrebbero verificarsi problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard di Power Delivery USB. Sebbene questa opzione sia indicata come "FORTEMENTE CONSIGLIATA", nelle versioni future di Android potremmo RICHIEDERE a tutti i dispositivi Type-C di supportare la piena interoperabilità con i caricabatterie Type-C standard.
  • [SR] È FORTEMENTE CONSIGLIATO supportare Power Delivery per lo scambio di ruoli di alimentazione e dati quando supportano USB Type-C e la modalità host USB.
  • DOVREBBE supportare Power Delivery per la ricarica ad alta tensione e le modalità alternative come la visualizzazione.
  • DEVE implementare l'API e la specifica Android Open Accessory (AOA) come descritto nella documentazione dell'SDK Android.

Se le implementazioni dei dispositivi includono una porta USB e implementano la specifica AOA, devono:

  • [C-2-1] DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.accessory.
  • [C-2-2] La classe di archiviazione di massa USB DEVE includere la stringa "android" alla fine della stringa iInterface della descrizione dell'interfaccia dell'archiviazione di massa USB

7.7.2. Modalità host USB

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host, devono:

  • [C-1-1] DEVE implementare l'API host USB Android come documentato nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host.
  • [C-1-2] DEVONO implementare il supporto per il collegamento di periferiche USB standard, in altre parole DEVONO:
    • Avere una porta di tipo C sul dispositivo o essere dotato di cavi che adattano una porta proprietaria sul dispositivo a una porta USB Type-C standard (dispositivo USB Type-C).
    • Avere un connettore di tipo A sul dispositivo o essere fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB di tipo A standard.
    • Avere una porta micro-AB sul dispositivo, che DOVREBBE essere fornita con un cavo adattabile a una porta di tipo A standard.
  • [C-1-3] NON deve essere fornito con un adattatore che converte da porte USB di tipo A o micro-AB a una porta di tipo C (presa).
  • [SR] È MOLTO CONSIGLIATO implementare la classe audio USB come descritto nella documentazione dell'SDK Android.
  • DEVE supportare la ricarica del dispositivo periferico USB collegato in modalità host; deve pubblicizzare una corrente di alimentazione di almeno 1,5 A come specificato nella sezione Parametri di terminazione della USB Type-C Cable and Connector Specification Revision 1.2 per i connettori USB Type-C o utilizzare l'intervallo di corrente di uscita della porta di ricarica a valle(CDP) come specificato nelle USB Battery Charging specifications, revision 1.2 per i connettori Micro-AB.
  • DEVE implementare e supportare gli standard USB Type-C.

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e la classe audio USB, devono:

  • [C-2-1] DEVE supportare la classe HID USB
  • [C-2-2] DEVE supportare il rilevamento e la mappatura dei seguenti campi di dati HID specificati nelle tabelle di utilizzo HID USB e nella richiesta di utilizzo dei comandi vocali alle costanti KeyEvent come indicato di seguito:
    • Pagina di utilizzo (0xC) ID utilizzo (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Pagina di utilizzo (0xC) ID utilizzo (0x0E9): KEYCODE_VOLUME_UP
    • Pagina di utilizzo (0xC) ID utilizzo (0x0EA): KEYCODE_VOLUME_DOWN
    • Pagina di utilizzo (0xC) ID utilizzo (0x0CF): KEYCODE_VOICE_ASSIST

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e Storage Access Framework (SAF), devono:

  • [C-3-1] DEVE riconoscere tutti i dispositivi MTP (Media Transfer Protocol) connessi da remoto e rendere accessibili i relativi contenuti tramite gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e USB Type-C:

  • [C-4-1] DEVE implementare la funzionalità della porta con doppio ruolo come definito dalla specifica USB Type-C (sezione 4.5.1.3.3).
  • [SR] È MOLTO CONSIGLIATO supportare DisplayPort, DOVREBBE supportare le velocità di trasferimento dati USB SuperSpeed ed È MOLTO CONSIGLIATO supportare Power Delivery per lo scambio di ruoli di alimentazione e dati.
  • [RP] È FORTEMENTE CONSIGLIATO di NON supportare la modalità accessorio dell'adattatore audio come descritto nell'appendice A della Revisione 1.2 della specifica del cavo e del connettore USB Type-C.
  • DOVREBBE implementare il modello Try.* più appropriato per il fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DOVREBBE implementare il modello Try.SNK.

7.8. Audio

7.8.1. Microfono

Se le implementazioni del dispositivo includono un microfono:

  • [C-1-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.microphone.
  • [C-1-2] DEVE soddisfare i requisiti di registrazione audio descritti nella sezione 5.4.
  • [C-1-3] DEVE soddisfare i requisiti di latenza audio descritti nella sezione 5.6.
  • [SR] È MOLTO CONSIGLIATO supportare la registrazione in modalità quasi ultrasuoni come descritto nella sezione 7.8.3.

Se le implementazioni del dispositivo omettono un microfono:

  • [C-2-1] NON DEVE segnalare la costante della funzionalità android.hardware.microphone.
  • [C-2-2] È OBBLIGATORIO implementare l'API di registrazione audio almeno come no-op, come indicato nella sezione 7.

7.8.2. Uscita audio

Se le implementazioni del dispositivo includono uno speaker o una porta di uscita audio/multimediale per una periferica di uscita audio, ad esempio un jack audio da 3,5 mm a 4 conduttori o una porta in modalità host USB che utilizza la classe audio USB, devono:

  • [C-1-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.audio.output.
  • [C-1-2] DEVE soddisfare i requisiti di riproduzione audio descritti nella sezione 5.5.
  • [C-1-3] DEVE soddisfare i requisiti di latenza audio descritti nella sezione 5.6.
  • [SR] È MOLTO CONSIGLIATO supportare la riproduzione a frequenza quasi ultrasonica come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono uno speaker o una porta di uscita audio, devono:

  • [C-2-1] NON DEVE segnalare la funzionalità android.hardware.audio.output.
  • [C-2-2] È NECESSARIO implementare le API relative all'output audio almeno come no-op.

Ai fini di questa sezione, una "porta di uscita" è un'interfaccia fisica, ad esempio un jack audio da 3,5 mm, HDMI o una porta in modalità host USB con classe audio USB. Il supporto dell'uscita audio tramite protocolli basati su radio, come Bluetooth, Wi-Fi o rete mobile, non è considerato come "porta di uscita".

7.8.2.1. Porte audio analogiche

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

Se le implementazioni del dispositivo hanno un jack audio da 3,5 mm a 4 conduttori, devono:

  • [C-1-1] DEVE supportare la riproduzione audio su cuffie stereo e cuffie stereo con microfono.
  • [C-1-2] DEVE supportare i connettori audio TRRS con l'ordine dei pin CTIA.
  • [C-1-3] DEVE supportare il rilevamento e la mappatura ai codici a tasti per i seguenti tre intervalli di impedenza equivalente tra i conduttori del microfono e della terra sul connettore audio:
    • Massimo 70 ohm: KEYCODE_HEADSETHOOK
    • 210-290 ohm: KEYCODE_VOLUME_UP
    • 360-680 ohm: KEYCODE_VOLUME_DOWN
  • [C-1-4] DEVE attivare ACTION_HEADSET_PLUG quando viene inserito il connettore, ma solo dopo che tutti i contatti del connettore toccano i relativi segmenti sul jack.
  • [C-1-5] DEVE essere in grado di alimentare almeno 150 mV ± 10% di tensione di uscita su un'impedenza dello speaker di 32 ohm.
  • [C-1-6] DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V e 2,9 V.
  • [SR] MOLTO CONSIGLIATO rilevare e mappare al codice a chiave il seguente intervallo di impedenza equivalente tra i conduttori del microfono e della messa a terra sul connettore audio:
    • 110-180 ohm: KEYCODE_VOICE_ASSIST
  • DOVREBBE supportare i connettori audio con l'ordine di pin-out OMTP.
  • DOVREBBE supportare la registrazione audio da cuffie stereo con microfono.

Se le implementazioni del dispositivo hanno un jack audio da 3, 5 mm a 4 conduttori e supportano un microfono e trasmettono android.intent.action.HEADSET_PLUG con il valore extra del microfono impostato su 1, devono:

  • [C-2-1] DEVE supportare il rilevamento del microfono sull'accessorio audio collegato.

7.8.3. Near-Ultrasound

L'audio quasi a ultrasuoni è la banda da 18,5 kHz a 20 kHz.

Implementazioni dei dispositivi:

  • DEVE segnalare correttamente il supporto della funzionalità audio a ultrasuoni vicini tramite l'API AudioManager.getProperty come segue:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND è "true", le sorgenti audio VOICE_RECOGNITION e UNPROCESSED DEVONO soddisfare i seguenti requisiti:

  • [C-1-1] La risposta di potenza media del microfono nella banda da 18,5 kHz a 20 kHz NON DEVE essere superiore a 15 dB al di sotto della risposta a 2 kHz.
  • [C-1-2] Il rapporto segnale/rumore non pesato del microfono in un intervallo di frequenza compreso tra 18,5 kHz e 20 kHz per un tono a 19 kHz a -26 dBFS NON DEVE essere inferiore a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND è "true":

  • [C-2-1] La risposta media dell'altoparlante nella gamma di frequenze 18,5 kHz - 20 kHz NON DEVE essere inferiore a 40 dB rispetto alla risposta a 2 kHz.

7.9. Realtà virtuale

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

7.9.1. Modalità realtà virtuale

Android include il supporto della modalità VR, una funzionalità che gestisce il rendering stereoscopico delle notifiche e disattiva i componenti dell'interfaccia utente di sistema monoculare quando un'applicazione VR ha l'attenzione dell'utente.

7.9.2. Realtà virtuale ad alte prestazioni

Se le implementazioni dei dispositivi identificano il supporto della realtà virtuale ad alte prestazioni per periodi di utilizzo più lunghi tramite il flag della funzionalità android.hardware.vr.high_performance:

  • [C-1-1] DEVE avere almeno 2 core fisici.
  • [C-1-2] È OBBLIGATORIO dichiarare android.software.vr.mode feature.
  • [C-1-3] DEVE supportare la modalità di rendimento sostenuto.
  • [C-1-4] DEVE supportare OpenGL ES 3.2.
  • [C-1-5] DEVE supportare il livello hardware Vulkan 0 e DOVREBBE supportare il livello hardware Vulkan 1.
  • [C-1-6] DEVE implementare EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content ed esporre le estensioni nell'elenco delle estensioni EGL disponibili.
  • [C-1-7] La GPU e il display DEVONO essere in grado di sincronizzare l'accesso al buffer anteriore condiviso in modo che il rendering con l'occhio alternato dei contenuti VR a 60 fps con due contesti di rendering venga visualizzato senza artefatti di tearing visibili.
  • [C-1-8] DEVE implementare GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures, GL_EXT_EGL_image_array, GL_EXT_external_buffer ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
  • [C-1-9] È OBBLIGATORIO implementare il supporto per i flag AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER e AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA AHardwareBuffer come descritto nell'NDK.
  • [C-1-10] È OBBLIGATORIO implementare il supporto di AHardwareBuffers con più di un livello.
  • [C-1-11] DEVE supportare la decodifica H.264 di almeno 3840 x 2160 a 30 fps e 40 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps e 10 Mbps o 2 istanze di 1920 x 1080 a 60 fps e 20 Mbps).
  • [C-1-12] DEVE supportare HEVC e VP9, DEVE essere in grado di decodificare almeno 1920 x 1080 a 30 fps e 10 Mbps e DOVREBBE essere in grado di decodificare 3840 x 2160 a 30 fps e 20 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps e 5 Mbps).
  • [C-1-13] DEVE supportare l'API HardwarePropertiesManager.getDeviceTemperatures e restituire valori accurati per la temperatura cutanea.
  • [C-1-14] DEVE avere uno schermo integrato e la sua risoluzione DEVE essere almeno FullHD(1080p) e MOLTO CONSIGLIATO che sia QuadHD (1440p) o superiore.
  • [C-1-15] Il display DEVE aggiornarsi ad almeno 60 Hz in modalità VR.
  • [C-1-16] La latenza del display (misurata in base al tempo di transizione da grigio a grigio, da bianco a nero e da nero a bianco) DEVE essere inferiore a 6 millisecondi.
  • [C-1-17] Il display DEVE supportare una modalità a bassa persistenza con una persistenza massima di 5 millisecondi, dove persistenza viene definita come il periodo di tempo per cui un pixel emette luce.
  • [C-1-18] DEVE supportare Bluetooth 4.2 e l'estensione della lunghezza dei dati Bluetooth LE sezione 7.4.3.
  • [C-1-19] DEVE supportare e segnalare correttamente il tipo di canale diretto per tutti i seguenti tipi di sensori predefiniti:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-1-20] DEVE supportare il tipo di canale diretto TYPE_HARDWARE_BUFFER per tutti i tipi di canale diretto elencati sopra.
  • [SR] È MOLTO CONSIGLIATO supportare la funzionalità android.hardware.sensor.hifi_sensors e DEVI soddisfare i requisiti relativi a giroscopio, accelerometro e magnetometro per android.hardware.hifi_sensors.
  • PUO' fornire un core esclusivo all'applicazione in primo piano e PUO' supportare l'API Process.getExclusiveCores per restituire i numeri dei core della CPU esclusivi dell'applicazione in primo piano principale. Se il nucleo esclusivo è supportato, il nucleo NON DEVE consentire l'esecuzione di altri processi nello spazio utente (tranne i driver di dispositivo utilizzati dall'applicazione), ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

8. Prestazioni e potenza

Alcuni criteri minimi di prestazioni e potenza sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di riferimento che gli sviluppatori dovrebbero fare durante lo sviluppo di un'app.

8.1. Coerenza dell'esperienza utente

È possibile fornire all'utente finale un'interfaccia utente fluida se sono presenti determinati requisiti minimi per garantire una frequenza frame e tempi di risposta coerenti per applicazioni e giochi. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POTREBBERO avere requisiti misurabili per la latenza dell'interfaccia utente e il passaggio da un'attività all'altra, come descritto nella sezione 2.

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

Fornire una linea di base comune per un rendimento coerente dell'accesso ai file nell'archiviazione dei dati privati dell'applicazione (partizione /data) consente agli sviluppatori di app di impostare un'aspettativa adeguata che possa essere utile per il design del software. Le implementazioni dei dispositivi, a seconda del tipo, POTREBBERO avere determinati requisiti descritti nella sezione 2 per le seguenti operazioni di lettura e scrittura:

  • Prestazioni di scrittura sequenziale. Misurato scrivendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
  • Rendimento delle scritture casuali. Misurato scrivendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.
  • Rendimento di lettura sequenziale. Misurato leggendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
  • Rendimento delle letture casuali. Misurato leggendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.

8.3. Modalità di risparmio energetico

Android include le modalità di risparmio energetico App Standby e Sospensione per ottimizzare l'utilizzo della batteria. [SR] È FORTEMENTE CONSIGLIATO rendere visibili all'utente finale tutte le app esenti da queste modalità. [SR] È FORTEMENTE CONSIGLIATO di NON discostarsi dagli algoritmi di attivazione, manutenzione e risveglio e dall'utilizzo delle impostazioni di sistema globali di queste modalità di risparmio energetico del progetto open source Android.

Oltre alle modalità di risparmio energetico, le implementazioni dei dispositivi Android POSSONO implementare uno o tutti e quattro gli stati di alimentazione in sospensione come definiti dall'Advanced Configuration and Power Interface (ACPI).

Se le implementazioni del dispositivo implementano gli stati di alimentazione S3 e S4 come definiti dall'ACPI, devono:

  • [C-1-1] DEVE entrare in questi stati solo quando si chiude un coperchio che fa parte fisicamente del dispositivo.

8.4. Contabilità del consumo energetico

Una contabilità e una generazione di report più accurati sul consumo di energia forniscono allo sviluppatore di app gli incentivi e gli strumenti per ottimizzare il pattern di utilizzo dell'energia dell'applicazione.

Implementazioni dei dispositivi:

  • [SR] È FORTEMENTE CONSIGLIATO fornire un profilo di alimentazione per componente che definisca il valore di consumo corrente per ciascun componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
  • [SR] È FORTEMENTE CONSIGLIATO segnalare tutti i valori di consumo di energia in milliampere ora (mAh).
  • [SR] È FORTEMENTE CONSIGLIATO segnalare il consumo di energia della CPU per l'UID di ogni processo. Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
  • [SR] VIVAMENTE CONSIGLIATO di rendere disponibile questo utilizzo di energia tramite il comando shell adb shell dumpsys batterystats per lo sviluppatore dell'app.
  • DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.

8.5. Prestazioni costanti

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

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi segnalano il supporto della modalità di prestazioni sostenute:

  • [C-1-1] DEVE fornire all'applicazione in primo piano un livello di prestazioni costante per almeno 30 minuti, quando l'app lo richiede.
  • [C-1-2] DEVE rispettare l'API Window.setSustainedPerformanceMode() e altre API correlate.

Se le implementazioni dei dispositivi includono due o più core della CPU:

  • DEVE fornire almeno un core esclusivo che può essere riservato dall'applicazione in primo piano principale.

Se le implementazioni del dispositivo supportano la prenotazione di un core esclusivo per l'applicazione in primo piano principale, devono:

  • [C-2-1] DEVE segnalare tramite il metodo dell'API Process.getExclusiveCores() i numeri ID dei core esclusivi che possono essere riservati dall'applicazione in primo piano principale.
  • [C-2-2] NON DEVE consentire l'esecuzione di processi nello spazio utente, ad eccezione dei driver di dispositivo utilizzati dall'applicazione, sui core esclusivi, ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

Se le implementazioni dei dispositivi non supportano un core esclusivo:

9. Compatibilità del modello di sicurezza

Implementazioni dei dispositivi:

  • [C-0-1] DEVE implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API della documentazione per sviluppatori Android.

  • [C-0-2] DEVE supportare l'installazione di applicazioni con firma autografa senza richiedere autorizzazioni/certificati aggiuntivi da parte di terze parti/autorità. In particolare, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle sottosezioni seguenti.

9.1. Autorizzazioni

Implementazioni dei dispositivi:

  • [C-0-1] DEVE supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android. Nello specifico, DEVONO applicare ogni autorizzazione definita come descritto nella documentazione dell'SDK; nessuna autorizzazione può essere omessa, alterata o ignorata.

  • PUO' aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe di ID autorizzazione non siano nello spazio dei nomi android.\*.

  • [C-0-2] Le autorizzazioni con un valore protectionLevel pari a PROTECTION_FLAG_PRIVILEGED DEVONO essere concesse solo alle app precaricate nei percorsi privilegiati dell'immagine di sistema e all'interno del sottoinsieme di autorizzazioni esplicitamente consentite per ogni app. L'implementazione AOSP soddisfa questo requisito leggendo e rispettando le autorizzazioni consentite per ogni app dai file nel percorso etc/permissions/ e utilizzando il percorso system/priv-app come percorso privilegiato.

Le autorizzazioni con un livello di protezione pericoloso sono autorizzazioni di runtime. Le applicazioni con targetSdkVersion > 22 le richiedono in fase di esecuzione.

Implementazioni dei dispositivi:

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

Se le implementazioni dei dispositivi includono un'app preinstallata o vogliono consentire ad app di terze parti di accedere alle statistiche di utilizzo, devono:

  • [C-1-1] È FORTEMENTE CONSIGLIATO fornire un meccanismo accessibile agli utenti per concedere o revocare l'accesso alle statistiche di utilizzo in risposta all'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS per le app che dichiarano l'autorizzazione android.permission.PACKAGE_USAGE_STATS.

Se le implementazioni dei dispositivi non vogliono consentire ad alcuna app, incluse quelle preinstallate, di accedere alle statistiche di utilizzo, devono:

  • [C-2-1] DEVE comunque avere un'attività che gestisce il pattern di intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, ma DEVE implementarlo come no-op, ovvero avere un comportamento equivalente a quello che si verifica quando l'utente viene rifiutato per l'accesso.

9.2. Isolamento UID e dei processi

Implementazioni dei dispositivi:

  • [C-0-1] DEVE supportare il modello di sandbox delle applicazioni Android, in cui ogni applicazione viene eseguita come UID Unix univoco e in un processo separato.
  • [C-0-2] DEVE supportare l'esecuzione di più applicazioni con lo stesso ID utente Linux, a condizione che le applicazioni siano firmate e create correttamente, come definito nella documentazione di riferimento su sicurezza e autorizzazioni.

9.3. Autorizzazioni del file system

Implementazioni dei dispositivi:

9.4. Ambienti di esecuzione alternativi

Le implementazioni dei dispositivi DEVONO mantenere la coerenza del modello di sicurezza e delle autorizzazioni di Android, anche se includono ambienti di runtime che eseguono applicazioni utilizzando un altro software o tecnologia rispetto al formato eseguibile Dalvik o al codice nativo. In altre parole:

  • [C-0-1] I runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella sezione 9.

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

  • [C-0-3] I runtime alternativi NON DEVONO consentire alle applicazioni di utilizzare funzionalità protette dalle autorizzazioni Android limitate alle applicazioni di sistema.

  • [C-0-4] I runtime alternativi DEVONO rispettare il modello di sandbox di Android 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.

  • [C-0-5] I runtime alternativi NON DEVONO essere avviati con le sandbox corrispondenti ad altre applicazioni Android, né devono concedere o ricevere l'accesso alle sandbox.

  • [C-0-6] I runtime alternativi NON DEVONO essere avviati con, essere concessi o concedere ad altre applicazioni privilegi del superutente (root) o di qualsiasi altro ID utente.

  • [C-0-7] Quando i file .apk dei runtime alternativi sono inclusi nell'immagine di sistema delle implementazioni del dispositivo, DEVONO essere firmati con una chiave diversa da quella utilizzata per firmare le altre applicazioni incluse nelle implementazioni del dispositivo.

  • [C-0-8] Durante l'installazione delle applicazioni, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione.

  • [C-0-9] Quando un'applicazione deve utilizzare una risorsa del dispositivo per la quale esiste un'autorizzazione Android corrispondente (ad esempio Fotocamera, GPS e così via), il runtime alternativo DEVE informare l'utente che l'applicazione potrà accedere a quella risorsa.

  • [C-0-10] Quando 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.

  • I runtime alternativi DOVREBBERO installare le app tramite PackageManager in sandbox Android separate (ID utente Linux e così via).

  • I runtime alternativi POSSONO fornire una singola sandbox Android condivisa da tutte le applicazioni che li utilizzano.

9.5. Supporto di più utenti

Android include il supporto di più utenti e l'isolamento completo degli utenti.

  • Le implementazioni dei dispositivi POSSONO, ma NON DEVONO, attivare il multiutente se utilizzano supporti rimovibili per lo spazio di archiviazione esterno principale.

Se le implementazioni dei dispositivi includono più utenti, questi:

  • [C-1-1] DEVE soddisfare i seguenti requisiti relativi al supporto multiutente.
  • [C-1-2] DEVE, 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.
  • [C-1-3] DEVE avere directory di spazio di archiviazione delle applicazioni condivise (ovvero /sdcard) separate e isolate per ogni istanza utente.
  • [C-1-4] DEVE garantire che le applicazioni di proprietà di un determinato utente e in esecuzione per suo conto non possano elencare, leggere o scrivere nei file di proprietà di altri utenti, anche se i dati di entrambi gli utenti sono archiviati nello stesso volume o file system.
  • [C-1-5] DEVE criptare i contenuti della scheda SD quando il multiutente è abilitato utilizzando una chiave memorizzata solo su supporti non rimovibili accessibili solo al sistema se le implementazioni del dispositivo utilizzano supporti rimovibili per le API di archiviazione esterna. 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.

Se le implementazioni dei dispositivi includono più utenti e non dichiarano il flag della funzionalità android.hardware.telephony, si verificano i seguenti casi:

  • [C-2-1] DEVE supportare i profili con limitazioni, una funzionalità che consente ai proprietari di dispositivi di gestire utenti aggiuntivi e le relative funzionalità sul dispositivo. Con i profili con limitazioni, i proprietari di dispositivi possono configurare rapidamente ambienti separati in cui altri utenti possono lavorare, con la possibilità di gestire limitazioni più granulari nelle app disponibili in questi ambienti.

Se le implementazioni dei dispositivi includono più utenti e dichiarano il flag della funzionalità android.hardware.telephony, devono:

  • [C-3-1] NON DEVE supportare i profili con limitazioni, ma DEVE essere in linea con l'implementazione dei controlli AOSP per attivare /disattivare l'accesso di altri utenti alle chiamate vocali e agli SMS.

9.6. Avviso SMS premium

Android include il supporto per avvisare gli utenti di qualsiasi messaggio SMS premium in uscita. Gli SMS premium sono messaggi inviati a un servizio registrato presso un operatore che potrebbero comportare un addebito per l'utente.

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.telephony:

  • [C-1-1] DEVE avvisare gli utenti prima di inviare un messaggio SMS ai numeri identificati dalle espressioni regolari definite nel file /data/misc/sms/codes.xml del dispositivo. L'Android Open Source Project upstream fornisce un'implementazione che soddisfa questo requisito.

9.7. Funzionalità di sicurezza del kernel

La sandbox di Android include funzionalità che utilizzano il sistema di controllo dell'accesso obbligatorio (MAC) di Security-Enhanced Linux (SELinux), il sandboxing seccomp e altre funzionalità di sicurezza nel kernel Linux. Implementazioni dei dispositivi:

  • [C-0-1] DEVE mantenere la compatibilità con le applicazioni esistenti, anche quando SELinux o altre funzionalità di sicurezza sono implementate sotto il framework Android.
  • [C-0-2] NON DEVE avere un'interfaccia utente visibile quando viene rilevata una violazione della sicurezza e bloccata correttamente dalla funzionalità di sicurezza implementata sotto il framework Android, ma PUÒ avere un'interfaccia utente visibile quando si verifica una violazione della sicurezza non bloccata che si traduce in uno sfruttamento riuscito.
  • [C-0-3] NON DEVE consentire all'utente o allo sviluppatore di app di configurare SELinux o altre funzionalità di sicurezza implementate sotto il framework Android.
  • [C-0-4] NON DEVE consentire a un'applicazione che può influire su un'altra applicazione tramite un'API (ad esempio un'API di amministrazione del dispositivo) di configurare un criterio che violi la compatibilità.
  • [C-0-5] È OBBLIGATORIO suddividere il framework multimediale in più processi in modo da poter concedere l'accesso in modo più specifico per ogni processo, come descritto nel sito del progetto open source Android.
  • [C-0-6] È NECESSARIO implementare un meccanismo di sandboxing delle applicazioni del kernel che consenta di filtrare le chiamate di sistema utilizzando un criterio configurabile da programmi multithread. Il progetto Android Open Source upstream soddisfa questo requisito attivando seccomp-BPF con la sincronizzazione del gruppo di thread (TSYNC) come descritto nella sezione Configurazione del kernel di source.android.com.

Le funzionalità di integrità e autoprotezione del kernel sono parte integrante della sicurezza di Android. Implementazioni dei dispositivi:

  • [C-0-7] DEVE implementare le protezioni contro gli overflow del buffer dello stack del kernel (ad es. CONFIG_CC_STACKPROTECTOR_STRONG).
  • [C-0-8] È OBBLIGATORIO implementare protezioni rigorose della memoria del kernel in cui il codice eseguibile è di sola lettura, i dati di sola lettura non sono eseguibili e non sono scrivibili e i dati scrivibili non sono eseguibili (ad es. CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
  • [SR] È FORTEMENTE CONSIGLIATO mantenere i dati del kernel scritti solo durante l'inizializzazione contrassegnati come di sola lettura dopo l'inizializzazione (ad es. __ro_after_init).
  • [SR] È MOLTO CONSIGLIATO implementare il controllo dei limiti di dimensione degli oggetti statici e dinamici delle copie tra spazio utente e spazio kernel (ad es. CONFIG_HARDENED_USERCOPY).
  • [SR] È FORTEMENTE CONSIGLIATO di non eseguire mai la memoria dello spazio utente durante l'esecuzione nel kernel (ad es. PXN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] È FORTEMENTE CONSIGLIATO di non leggere o scrivere mai la memoria dello spazio utente nel kernel al di fuori delle normali API di accesso usercopy (ad es. PAN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] È FORTEMENTE CONSIGLIATO di randomizzare il layout del codice e della memoria del kernel ed evitare esposizioni che potrebbero compromettere la randomizzazione (ad es. CONFIG_RANDOMIZE_BASE con l'entropia del bootloader tramite /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).

Se le implementazioni dei dispositivi utilizzano un kernel Linux:

  • [C-1-1] È NECESSARIO implementare SELinux.
  • [C-1-2] È NECESSARIO impostare SELinux sulla modalità di applicazione globale.
  • [C-1-3] È NECESSARIO configurare tutti i domini in modalità di applicazione. Non sono consentiti domini in modalità permissiva, inclusi i domini specifici di un dispositivo/fornitore.
  • [C-1-4] NON DEVE modificare, omettere o sostituire le regole neverallow presenti nella cartella system/sepolicy fornita nell'Android Open Source Project (AOSP) in upstream e il criterio DEVE essere compilato con tutte le regole neverallow presenti, sia per i domini SELinux AOSP sia per i domini specifici del dispositivo/del fornitore.
  • DOVREBBE mantenere il criterio SELinux predefinito fornito nella cartella system/sepolicy del progetto open source Android upstream e aggiungere ulteriori elementi a questo criterio solo per la propria configurazione specifica del dispositivo.

Se le implementazioni dei dispositivi utilizzano un kernel diverso da Linux:

  • [C-2-1] È NECESSARIO utilizzare un sistema di controllo degli accessi obbligatorio equivalente a SELinux.

9.8. Privacy

9.8.1. Cronologia utilizzo

Android archivia la cronologia delle scelte dell'utente e la gestisce tramite UsageStatsManager.

Implementazioni dei dispositivi:

  • [C-1-1] DEVE mantenere un periodo di conservazione ragionevole di questa cronologia utente.
  • [SR] È FORTEMENTE CONSIGLIATO di mantenere il periodo di conservazione di 14 giorni come configurato per impostazione predefinita nell'implementazione AOSP.

9.8.2. Registrazione in corso…

Se le implementazioni dei dispositivi includono nel sistema funzionalità che acquisiscono i contenuti visualizzati sullo schermo e/o registrano lo stream audio riprodotto sul dispositivo, queste:

  • [C-1-1] DEVE essere presente una notifica continua all'utente ogni volta che questa funzionalità è attiva e acquisisce/registra attivamente.

Se le implementazioni dei dispositivi includono un componente abilitato out-of-the-box, in grado di registrare l'audio ambientale per dedurre informazioni utili sul contesto dell'utente, devono:

  • [C-2-1] NON DEVE memorizzare nello spazio di archiviazione permanente sul dispositivo o trasmettere dal dispositivo l'audio non elaborato registrato o qualsiasi formato che possa essere convertito nuovamente nell'audio originale o in una copia quasi esatta, tranne con il consenso esplicito dell'utente.

9.8.3. Connettività

Se le implementazioni dei dispositivi dispongono di una porta USB con supporto della modalità periferica USB, devono:

  • [C-1-1] DEVE presentare un'interfaccia utente che richieda il consenso dell'utente prima di consentire l'accesso ai contenuti dello spazio di archiviazione condiviso tramite la porta USB.

9.8.4. Traffico di rete

Implementazioni dei dispositivi:

  • [C-0-1] DEVE preinstallare gli stessi certificati radice per l'archivio delle autorità di certificazione (CA) attendibili di sistema forniti nel progetto open source Android upstream.
  • [C-0-2] DEVE essere fornito con un magazzino di CA radice utente vuoto.
  • [C-0-3] DEVE mostrare un avviso all'utente che indica che il traffico di rete potrebbe essere monitorato quando viene aggiunta una CA principale dell'utente.

Se il traffico del dispositivo viene instradato tramite una VPN, le implementazioni del dispositivo:

  • [C-1-1] DEVE mostrare un avviso all'utente che indica:
    • Il traffico di rete potrebbe essere monitorato.
    • Il traffico di rete viene instradato tramite l'applicazione VPN specifica che fornisce la VPN.

Se le implementazioni dei dispositivi dispongono di un meccanismo, abilitato per impostazione predefinita, che instrada il traffico di dati di rete tramite un server proxy o un gateway VPN (ad esempio, il precaricamento di un servizio VPN con android.permission.CONTROL_VPN concesso), devono:

  • [C-2-1] DEVE chiedere il consenso dell'utente prima di attivare il meccanismo, a meno che la VPN non sia attivata dal Device Policy Controller tramite DevicePolicyManager.setAlwaysOnVpnPackage() , nel qual caso l'utente non deve fornire un consenso separato, ma DEVE solo essere informato.

Se le implementazioni dei dispositivi implementano un'affordance utente per attivare/disattivare la funzionalità "VPN sempre attiva" di un'app VPN di terze parti, devono:

  • [C-3-1] È OBBLIGATORIO disattivare questa funzionalità per gli utenti per le app che non supportano il servizio VPN sempre attivo nel file AndroidManifest.xml impostando l'attributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON su false.

9.9. Crittografia dell'archiviazione dei dati

Se le implementazioni del dispositivo supportano una schermata di blocco sicura come descritto nella sezione 9.11.1, devono:

  • [C-1-1] DEVE supportare la crittografia dello spazio di archiviazione dei dati privati dell'applicazione (/data partition), nonché la partizione dello spazio di archiviazione condiviso dell'applicazione (/sdcard partition) se si tratta di una parte permanente e non rimovibile del dispositivo.

Se le implementazioni dei dispositivi supportano una schermata di blocco sicura come descritto nella sezione 9.11.1 e supportano la crittografia dello spazio di archiviazione dei dati con prestazioni di crittografia Advanced Encryption Standard (AES) superiori a 50 MiB/sec, devono:

  • [C-2-1] DEVE attivare la crittografia dello spazio di archiviazione dei dati per impostazione predefinita al momento in cui l'utente ha completato l'esperienza di configurazione fuori dalla scatola. Se le implementazioni dei dispositivi sono già state avviate su una versione precedente di Android con la crittografia disattivata per impostazione predefinita, un dispositivo di questo tipo non può soddisfare il requisito tramite un aggiornamento del software di sistema e, pertanto, POTREBBE essere esente.

  • DEVE soddisfare il requisito di crittografia dell'archiviazione dei dati riportato sopra tramite l'implementazione della crittografia basata su file (FBE).

9.9.1. Avvio diretto

Implementazioni dei dispositivi:

  • [C-0-1] DEVE implementare le API della modalità di avvio diretto anche se non supportano la crittografia dello spazio di archiviazione.

  • [C-0-2] Gli intent ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED DEVONO comunque essere trasmessi per segnalare alle applicazioni compatibili con il Boot diretto che le posizioni di archiviazione con crittografia del dispositivo (DE) e con crittografia delle credenziali (CE) sono disponibili per l'utente.

9.9.2. Crittografia basata su file

Se le implementazioni dei dispositivi supportano FBE:

  • [C-1-1] DEVE avviarsi senza richiedere all'utente le credenziali e consentire alle app compatibili con il riavvio diretto di accedere allo spazio di archiviazione criptato del dispositivo dopo l'invio del messaggio ACTION_LOCKED_BOOT_COMPLETED.
  • [C-1-2] DEVE consentire l'accesso allo spazio di archiviazione con crittografia delle credenziali (CE) solo dopo che l'utente ha sbloccato il dispositivo fornendo le proprie credenziali (ad es. passcode, PIN, sequenza o impronta) e il messaggio ACTION_USER_UNLOCKED viene trasmesso.
  • [C-1-3] NON DEVE offrire alcun metodo per sbloccare lo spazio di archiviazione protetto CE senza le credenziali fornite dall'utente.
  • [C-1-4] DEVE supportare l'Avvio verificato e garantire che le chiavi DE siano legate in modo crittografico all'hardware root of trust del dispositivo.
  • [C-1-5] DEVE supportare la crittografia dei contenuti dei file utilizzando AES con una lunghezza della chiave di 256 bit in modalità XTS.

  • [C-1-6] DEVE supportare la crittografia del nome del file utilizzando AES con una lunghezza della chiave di 256 bit in modalità CBC-CTS.

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

  • [C-1-7] DEVE essere associato in modo crittografico a un Keystore basato su hardware.

  • [C-1-8] Le chiavi CE DEVONO essere associate alle credenziali della schermata di blocco di un utente.
  • [C-1-9] Le chiavi CE DEVONO essere associate a un passcode predefinito quando l'utente non ha specificato le credenziali della schermata di blocco.

  • [C-1-10] DEVE essere univoco e distinto, in altre parole nessuna chiave CE o DE di un utente corrisponde alle chiavi CE o DE di un altro utente.

  • DOVREBBE rendere le app essenziali precaricate (ad es. Sveglia, Telefono, Messaggi) compatibili con il Boot diretto.

  • PUO' supportare algoritmi di crittografia, lunghezze e modalità alternative per la crittografia dei contenuti e dei nomi dei file, ma DEVE utilizzare per impostazione predefinita gli algoritmi di crittografia, le lunghezze e le modalità supportate obbligatoriamente.

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

9.9.3. Crittografia completa del disco

Se le implementazioni dei dispositivi supportano la crittografia completa del disco (FDE), devono:

  • [C-1-1] 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).
  • [C-1-2] DEVE utilizzare un passcode predefinito per il wrapping della chiave di crittografia e NON DEVE scrivere la chiave di crittografia nello spazio di archiviazione in nessun momento senza che sia criptata.
  • [C-1-3] La chiave di crittografia DEVE essere criptata con AES per impostazione predefinita, a meno che l'utente non disattivi esplicitamente questa opzione, tranne quando è in uso attivo, con le credenziali della schermata di blocco allungate utilizzando un algoritmo di allungamento lento (ad es. PBKDF2 o scrypt).
  • [C-1-4] L'algoritmo di stretching della password predefinito riportato sopra DEVE essere legato in modo crittografico a quel keystore quando l'utente non ha specificato le credenziali della schermata di blocco o ha disattivato l'uso del passcode per la crittografia e il dispositivo fornisce un keystore basato su hardware.
  • [C-1-5] NON DEVE inviare la chiave di crittografia dal dispositivo (anche se sottoposta a wrapping con il passcode dell'utente e/o la chiave legata all'hardware).

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

9.10. Integrità del dispositivo

I seguenti requisiti garantiscono la trasparenza dello stato dell'integrità del dispositivo. Implementazioni dei dispositivi:

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

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

  • [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità della piattaforma android.software.verified_boot.
  • [C-1-2] È NECESSARIO eseguire la verifica a ogni sequenza di avvio.
  • [C-1-3] È NECESSARIO avviare la verifica da una chiave hardware immutabile che è la radice della attendibilità e arrivare fino alla partizione di sistema.
  • [C-1-4] DEVE implementare ogni fase di verifica per controllare l'integrità e l'autenticità di tutti i byte nella fase successiva prima di eseguire il codice nella fase successiva.
  • [C-1-5] È NECESSARIO utilizzare algoritmi di verifica altrettanto efficaci dei consigli attuali del NIST per gli algoritmi di hashing (SHA-256) e le dimensioni delle chiavi pubbliche (RSA-2048).
  • [C-1-6] NON DEVE consentire il completamento dell'avvio quando la verifica del sistema non va a buon fine, a meno che l'utente non accetti di tentare comunque l'avvio, nel qual caso i dati di eventuali blocchi di archiviazione non verificati NON DEVONO essere utilizzati.
  • [C-1-7] NON DEVE consentire la modifica delle partizioni verificate sul dispositivo, a meno che l'utente non abbia sbloccato esplicitamente il bootloader.
  • [SR] Se il dispositivo contiene più chip distinti (ad es. radio, processore di immagini specializzato), è MOLTO CONSIGLIATO verificare ogni fase del processo di avvio di ciascun chip all'avvio.
  • [SR] È FORTEMENTE CONSIGLIATO di utilizzare lo spazio di archiviazione con dispositivo di protezione antimanomissione: per quando il bootloader è sbloccato. Lo spazio di archiviazione con rilevamento di manomissione indica che il bootloader può rilevare se lo spazio di archiviazione è stato manomesso dall'interno del sistema operativo di alto livello (HLOS).
  • [RP] È MOLTO CONSIGLIATO chiedere all'utente, durante l'utilizzo del dispositivo, di confermare fisicamente prima di consentire la transizione dalla modalità di blocco del bootloader alla modalità di sblocco del bootloader.
  • [SR] È FORTEMENTE CONSIGLIATO di implementare la protezione del rollback per il sistema operativo host (ad es. avvio, partizioni di sistema) e di utilizzare lo spazio di archiviazione con rilevamento di manomissione per memorizzare i metadati utilizzati per determinare la versione minima del sistema operativo consentita.
  • DEVE implementare la protezione del rollback per qualsiasi componente con firmware persistente (ad es. modem, videocamera) e DEVE utilizzare uno spazio di archiviazione con protezione antimanomissione per archiviare i metadati utilizzati per determinare la versione minima consentita.

Il progetto Android Open Source upstream fornisce un'implementazione preferita di questa funzionalità nel repository external/avb/, che può essere integrata nel bootloader utilizzato per il caricamento di Android.

Se le implementazioni dei dispositivi segnalano il flag della funzionalità android.hardware.ram.normal:

  • [C-2-1] DEVE supportare l'avvio verificato per l'integrità del dispositivo.

Se l'implementazione di un dispositivo è già stata lanciata senza supportare l'avvio verificato su una versione precedente di Android, questo dispositivo non può aggiungere il supporto di questa funzionalità con un aggiornamento del software di sistema ed è quindi esente dal requisito.

9.11. Chiavi e credenziali

Il sistema Android Keystore consente agli sviluppatori di app di archiviare le chiavi di crittografia in un contenitore e di utilizzarle nelle operazioni di crittografia tramite l'API KeyChain o l'API Keystore. Implementazioni dei dispositivi:

  • [C-0-1] DEVE consentire almeno l'importazione di più di 8192 chiavi.
  • [C-0-2] L'autenticazione nella schermata di blocco DEVE limitare la frequenza dei tentativi e DEVE avere un algoritmo di backoff esponenziale. Oltre 150 tentativi non riusciti, il ritardo DEVE essere di almeno 24 ore per tentativo.
  • NON deve limitare il numero di chiavi che possono essere generate

Quando l'implementazione del dispositivo supporta una schermata di blocco sicura:

  • [C-1-1] È NECESSARIO eseguire il backup dell'implementazione del keystore con hardware sicuro.
  • [C-1-2] DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni hash di famiglie MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e sopra. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA. Il progetto Android Open Source (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura sottoposta a revisione da parte di terze parti di un'isolamento basato su hypervisor adeguato sono opzioni alternative.
  • [C-1-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo se l'autenticazione va a buon fine, consentire l'utilizzo delle chiavi legate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto Android Open Source upstream fornisce l'HAL (Hardware Abstraction Layer) Gatekeeper e Trusty, che possono essere utilizzati per soddisfare questo requisito.
  • [C-1-4] DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori dei dispositivi. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

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

9.11.1. Schermata di blocco sicura

Se le implementazioni dei dispositivi hanno una schermata di blocco sicura e includono uno o più agenti di attendibilità che implementano l'TrustAgentServiceAPI di sistema, devono:

  • [C-1-1] L'interfaccia utente delle Impostazioni e della schermata di blocco DEVE indicare all'utente le situazioni in cui il blocco automatico dello schermo è differito o lo schermo può essere sbloccato dall'agente di attendibilità. AOSP soddisfa il requisito mostrando una descrizione del testo per i menu "Imposta blocco automatico" e "Imposta blocco immediato con il tasto di accensione" e un'icona distinguibile nella schermata di blocco.
  • [C-1-2] DEVE rispettare e implementare completamente tutte le API di agenti di attendibilità nella classe DevicePolicyManager, ad esempio la costante KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-1-3] NON DEVE implementare completamente la funzione TrustAgentService.addEscrowToken() su un dispositivo che viene utilizzato come dispositivo personale principale (ad es. palmare), ma PUÒ implementare completamente la funzione sulle implementazioni del dispositivo in genere condivise.
  • [C-1-4] DEVE criptare i token aggiunti da TrustAgentService.addEscrowToken() prima di memorizzarli sul dispositivo.
  • [C-1-5] NON DEVE memorizzare la chiave di crittografia sul dispositivo.
  • [C-1-6] È OBBLIGATORIO informare l'utente sulle implicazioni per la sicurezza prima di attivare il token escrow per decriptare lo spazio di archiviazione dei dati.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco, affinché un metodo di autenticazione del genere venga considerato un modo sicuro per bloccare lo schermo, devono:

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco se si basano su una chiave segreta nota, affinché questo metodo di autenticazione venga considerato un modo sicuro per bloccare lo schermo, devono:

  • [C-3-1] L'entropia della lunghezza minima consentita degli input DEVE essere maggiore di 10 bit.
  • [C-3-2] L'entropia massima di tutti gli input possibili DEVE essere maggiore di 18 bit.
  • [C-3-3] NON deve sostituire nessuno dei metodi di autenticazione esistenti (PIN,sequenza, password) implementati e forniti in AOSP.
  • [C-3-4] DEVE essere disattivato quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_SOMETHING.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco se basati su un token fisico o sulla posizione, affinché questo metodo di autenticazione venga considerato un modo sicuro per bloccare lo schermo, devono:

  • [C-4-1] DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali basato su una chiave segreta nota e che soddisfi i requisiti per essere considerato una schermata di blocco sicura.
  • [C-4-2] DEVE essere disattivato e consentire solo l'autenticazione principale per sbloccare la schermata quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio con il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED.
  • [C-4-3] All'utente DEVE essere richiesta l'autenticazione principale (ad es. PIN, sequenza, password) almeno una volta ogni 72 ore.

Se le implementazioni dei dispositivi aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco in base alla biometria, affinché questo metodo di autenticazione venga considerato un modo sicuro per bloccare lo schermo, devono:

  • [C-5-1] DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali basato su una chiave segreta nota e che soddisfi i requisiti per essere considerato una schermata di blocco sicura.
  • [C-5-2] DEVE essere disattivata e consentire solo l'autenticazione principale per sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio della funzionalità keguard chiamando il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • [C-5-3] DEVE avere un tasso di accettazione di falsi pari o superiore a quello richiesto per un sensore di impronte digitali come descritto nella sezione 7.3.10 oppure DEVE essere disattivato e consentire solo l'autenticazione principale per sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [SR] È MOLTO CONSIGLIATO avere tassi di accettazione di spoofing e furto d'identità uguali o superiori a quelli richiesti per un sensore di impronte digitali, come descritto nella sezione 7.3.10.

Se i tassi di accettazione di spoofing e di attacco di impostore non sono uguali o superiori a quelli richiesti per un sensore di impronte digitali come descritto nella sezione 7.3.10 e l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK, allora:

  • [C-6-1] È OBBLIGATORIO disattivare questi metodi biometrici e consentire solo l'autenticazione principale per sbloccare lo schermo.
  • [C-6-2] DEVE richiedere all'utente l'autenticazione principale (ad es. PIN, sequenza, password) almeno una volta ogni 72 ore.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco e se un metodo di autenticazione del genere verrà utilizzato per sbloccare la schermata di blocco, ma non verrà considerato una schermata di blocco sicura, allora:

9.12. Eliminazione dei dati

Tutte le implementazioni dei dispositivi:

  • [C-0-1] DEVE fornire agli utenti un meccanismo per eseguire un "Ripristino dei dati di fabbrica".
  • [C-0-2] È NECESSARIO eliminare tutti i dati generati dagli utenti. ovvero tutti i dati, ad eccezione di quanto segue:
    • L'immagine di sistema
    • Eventuali file del sistema operativo richiesti dall'immagine di sistema
  • [C-0-3] DEVE eliminare i dati in modo da soddisfare gli standard di settore pertinenti, come NIST SP800-88.
  • [C-0-4] DEVE attivare la procedura di "Ripristino dei dati di fabbrica" riportata sopra quando l'API DevicePolicyManager.wipeData() viene chiamata dall'app Device Policy Controller dell'utente principale.
  • POTREBBE fornire un'opzione di eliminazione rapida dei dati che esegue solo un'eliminazione logica dei dati.

9.13. Modalità Avvio sicuro

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

Le implementazioni dei dispositivi sono:

  • [SR] MOLTO CONSIGLIATO implementare la modalità Avvio protetto.

Se le implementazioni dei dispositivi implementano la modalità di avvio sicuro, devono:

  • [C-1-1] DEVE fornire all'utente un'opzione per avviare la modalità provvisoria in modo che non possa essere interrotta dalle app di terze parti installate sul dispositivo, tranne quando l'app di terze parti è un controller Device Policy e ha impostato il flag UserManager.DISALLOW_SAFE_BOOT su true.

  • [C-1-2] DEVE fornire all'utente la possibilità di disinstallare qualsiasi app di terze parti in modalità provvisoria.

  • DOVREBBE fornire all'utente un'opzione per accedere alla modalità di avvio sicuro dal menu di avvio utilizzando un flusso di lavoro diverso da quello di un normale avvio.

9.14. Isolamento del sistema di veicoli a motore

I dispositivi Android Automotive devono scambiare dati con i sottosistemi critici del veicolo utilizzando l'HAL del veicolo per inviare e ricevere messaggi tramite le reti del veicolo, come il bus CAN.

Lo scambio di dati può essere protetto implementando funzionalità di sicurezza sotto i livelli del framework Android per impedire l'interazione dannosa o involontaria con questi sottosistemi.

10. Test di compatibilità del software

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

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

10.1. Compatibility Test Suite (CTS)

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

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

10.2. Verificatore CTS

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

CTS Verifier include test per molti tipi di hardware, incluso hardware facoltativo. Le implementazioni dei dispositivi DEVONO superare tutti i test relativi all'hardware di cui sono dotati. Ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente il test case Accelerometer in CTS Verifier. Gli scenari di test per le funzionalità indicate come facoltative da questo documento di definizione della compatibilità POSSONO essere saltati o omessi.

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

11. Software aggiornabile

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

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

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

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

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

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

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

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

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

12. Log delle modifiche del documento

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

Per un riepilogo delle modifiche alle sezioni relative alle persone:

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

12.1. Suggerimenti per la visualizzazione del log delle modifiche

Le modifiche sono contrassegnate come segue:

  • CDD
    Modifiche sostanziali ai requisiti di compatibilità.

  • Documenti
    Modifiche estetiche o relative alla compilazione.

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

13. Contattaci

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