A partire dal 2026, per allinearci al nostro modello di sviluppo stabile del trunk e garantire la stabilità della piattaforma per l'ecosistema, pubblicheremo il codice sorgente su AOSP nel secondo e nel quarto trimestre. Per la creazione e il contributo ad AOSP, consigliamo di utilizzare android-latest-release anziché aosp-main. Il ramo del manifest android-latest-release farà sempre riferimento alla release più recente inviata ad AOSP. Per saperne di più, vedi Modifiche ad AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Definizione di compatibilità di Android 17 [ANTEPRIMA]

1. Introduzione

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

L'utilizzo di "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" è conforme allo standard IETF definito in RFC2119.

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

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

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

Per questo motivo, l'Android Open Source Project è l'implementazione di riferimento e preferita di Android. È FORTEMENTE CONSIGLIATO agli implementatori di dispositivi di basare le proprie implementazioni, nella misura più ampia possibile, sul codice sorgente "upstream" disponibile nell'Android Open Source Project. Anche se alcuni componenti possono essere sostituiti con implementazioni alternative, è VIVAMENTE CONSIGLIATO di non seguire questa pratica, in quanto superare i test del software diventerà molto più difficile. È responsabilità dell'implementatore garantire la piena compatibilità comportamentale con l'implementazione Android standard, inclusa e oltre la suite di test di compatibilità. Infine, tieni presente che alcune sostituzioni e modifiche dei componenti sono esplicitamente vietate da questo documento.

Molte delle risorse a cui viene fatto riferimento in questo documento derivano direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni contenute nella documentazione di questo SDK. In tutti i casi in cui questa definizione di compatibilità o il Compatibility Test Suite non sono in linea con la documentazione dell'SDK, quest'ultima è considerata autorevole. Qualsiasi dettaglio tecnico fornito nelle risorse collegate in questo documento è considerato 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 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, questi requisiti sono indicati 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 viene assegnato alcun ID.
L'ID è composto da : ID tipo di dispositivo - ID condizione - ID requisito (ad es. C-0-1).

Ogni ID è definito come segue:

ID tipo di dispositivo (vedi di più in 2. Tipi di dispositivi)
- C: Core (requisiti applicati a tutte le implementazioni dei dispositivi Android)
- H: Dispositivo palmare Android
- T: Dispositivo Android Television
- R: Implementazione di Android Automotive
- W: Implementazione di Android Watch
- Scheda: implementazione del tablet Android
ID condizione
- Quando il requisito è incondizionato, questo ID è 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 viene incrementato di 1 all'interno della stessa sezione e della stessa condizione.

1.1.3. ID requisito nella sezione 2

Gli ID requisito nella sezione 2 sono composti da due parti. Il primo corrisponde a un ID sezione come descritto sopra. La seconda parte identifica il fattore di forma e il requisito specifico del fattore di forma.

ID sezione seguito dall'ID requisito descritto sopra.

L'ID nella Sezione 2 è costituito da: ID sezione / ID tipo di dispositivo - ID condizione - ID requisito (ad es. 7.4.3/A-0-1).

2. Tipi di dispositivi

L'Android Open Source Project fornisce uno stack software che può essere utilizzato per una varietà di tipi di dispositivi e fattori di forma. Per supportare la sicurezza sui dispositivi, lo stack software, incluso qualsiasi sistema operativo sostitutivo o un'implementazione alternativa del kernel, deve essere eseguito in un ambiente sicuro come descritto nella sezione 9 e in altre parti di questo CDD. 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.

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 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 per dispositivi portatili

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

Le implementazioni di dispositivi Android sono classificate come portatili se soddisfano tutti i seguenti criteri:

Avere una fonte di alimentazione che garantisca la mobilità, ad esempio una batteria.
Avere una dimensione diagonale fisica dello schermo compresa tra 4 e 8 pollici.
Avere un'interfaccia di input touch screen.

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

2.2.1. Hardware

Implementazioni di dispositivi palmari:

[7.1.1.1/H-0-1] DEVE avere almeno un display compatibile con Android che misuri almeno 5,6 cm sul lato corto e 8,6 cm sul lato lungo.
[7.1.1.3/H-SR-1] Sono FORTEMENTE CONSIGLIATE per offrire agli utenti la possibilità di modificare le dimensioni di visualizzazione (densità schermo).
[7.1.1.1/H-0-2] DEVE supportare la composizione della GPU di buffer grafici almeno grandi quanto la risoluzione più alta di qualsiasi display integrato.
[7.1.1.1/H-0-3]^* DEVE mappare ogni UI_MODE_NORMAL display reso disponibile per applicazioni di terze parti su un'area di visualizzazione fisica libera da ostacoli di almeno 5,6 cm sul lato corto e 8,6 cm sul lato lungo.
[7.1.1.3/H-0-1]^* DEVE impostare DENSITY_DEVICE_STABLE in modo che sia pari o superiore al 92% della densità fisica effettiva del display corrispondente.

Se le implementazioni dei dispositivi palmari includono il supporto di Vulkan:

[7.1.4.2/H-1-1] DEVE soddisfare i requisiti specificati dal profilo Android Baseline 2021.

Se le implementazioni di dispositivi palmari dichiarano il supporto di qualsiasi ABI a 64 bit (con o senza ABI a 32 bit) e restituiscono false per ActivityManager.isLowRamDevice(), :

[7.1.4.2/H-2-1] DEVE supportare Vulkan 1.1 o versioni successive.

Se le implementazioni di dispositivi palmari dichiarano il supporto per display High Dynamic Range tramite Configuration.isScreenHdr(), devono:

[7.1.4.5/H-1-1] DEVE pubblicizzare il supporto per le estensioni EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace e VK_EXT_hdr_metadata.

Implementazioni di dispositivi palmari:

[7.1.4.6/H-0-1] DEVE segnalare se il dispositivo supporta la funzionalità di profilazione della GPU tramite una proprietà di sistema graphics.gpu.profiler.support.

Se le implementazioni di dispositivi palmari dichiarano il supporto tramite una proprietà di sistema graphics.gpu.profiler.support:

[7.1.4.6/H-1-1] DEVE segnalare come output una traccia protobuf conforme allo schema per i contatori GPU e le fasi di rendering della GPU definiti nella documentazione di Perfetto.
[7.1.4.6/H-1-2] DEVE segnalare valori conformi per i contatori GPU del dispositivo seguendo il proto pacchetto gpu counter trace.
[7.1.4.6/H-1-3] DEVE segnalare valori conformi per le fasi di rendering della GPU del dispositivo seguendo il proto del pacchetto di traccia della fase di rendering.
[7.1.4.6/H-1-4] DEVE segnalare un punto di traccia della frequenza della GPU come specificato dal formato: power/gpu_frequency.

Implementazioni di dispositivi palmari:

[7.1.5/H-0-1] DEVE includere il supporto della modalità di compatibilità delle applicazioni legacy implementata dal codice sorgente open source Android upstream. ovvero le implementazioni dei dispositivi NON DEVONO alterare i trigger o le soglie in corrispondenza delle quali viene attivata la modalità di compatibilità e NON DEVONO alterare il comportamento della modalità di compatibilità stessa.
[7.2.1/H-0-1] DEVE includere il supporto per applicazioni Input Method Editor (IME) di terze parti.
[7.2.3/H-0-2] DEVE inviare sia l'evento di pressione normale che quello di pressione prolungata della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano. Questi eventi NON DEVONO essere utilizzati dal sistema e POSSONO essere attivati al di fuori del dispositivo Android (ad es. tastiera hardware esterna collegata al dispositivo Android).
[7.2.3/H-0-3] DEVE fornire la funzione Home su tutti i display compatibili con Android che forniscono la schermata Home.
[7.2.3/H-0-4] DEVE fornire la funzione Indietro su tutti i display compatibili con Android e la funzione Recenti su almeno uno dei display compatibili con Android.
[7.2.4/H-0-1] DEVE supportare l'input touchscreen.
[7.2.4/H-SR-1] Sono FORTEMENTE CONSIGLIATE per avviare l'app di assistenza selezionata dall'utente; in altre parole, l'app che implementa VoiceInteractionService o un'attività che gestisce ACTION_ASSIST con la pressione prolungata di KEYCODE_MEDIA_PLAY_PAUSE o KEYCODE_HEADSETHOOK se l'attività in primo piano non gestisce questi eventi di pressione prolungata.
[7.3.1/H-SR-1] È FORTEMENTE CONSIGLIATO includere un accelerometro a 3 assi.

Se le implementazioni di dispositivi portatili includono un accelerometro a 3 assi:

[7.3.1/H-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 100 Hz.

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

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

Se le implementazioni di dispositivi palmari includono un giroscopio a 3 assi:

[7.3.4/H-3-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 100 Hz.
[7.3.4/H-3-2] DEVE essere in grado di misurare i cambiamenti di orientamento fino a 1000 gradi al secondo.

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

[7.3.8/H] DEVE includere un sensore di prossimità.

Implementazioni di dispositivi palmari:

[7.3.11/H-SR-1] Sono FORTEMENTE CONSIGLIATI per supportare il sensore di posa con 6 gradi di libertà.

Se le implementazioni di dispositivi palmari supportano la connettività dati cellulare:

[7.4.1/H-1-1] DEVE dichiarare il flag funzionalità android.hardware.telephony.data.

Implementazioni di dispositivi palmari che includono il supporto di Bluetooth LE:

[7.4.3/H-SR-1] Sono FORTEMENTE CONSIGLIATI per supportare l'estensione della lunghezza del pacchetto di dati Bluetooth LE.

Nota: questo requisito [7.4.3/H-SR-1] diventerà obbligatorio in una futura release di Android.

Se le implementazioni dei dispositivi includono il supporto di 802.11 (Wi-Fi):

[7.4.2.4/H-1-1] DEVE includere il supporto per Wi-Fi Passpoint.

Se i dispositivi supportano il protocollo Wi-Fi Neighbor Awareness Networking (NAN) dichiarando PackageManager.FEATURE_WIFI_AWARE e la posizione Wi-Fi (tempo di andata e ritorno Wi-Fi - RTT) dichiarando PackageManager.FEATURE_WIFI_RTT,

[7.4.2.5/H-1-1] DEVE segnalare l'intervallo con precisione entro +/- 1 metro con una larghezza di banda di 160 MHz al 68° percentile (come calcolato con la funzione di distribuzione cumulativa), +/- 2 metri con una larghezza di banda di 80 MHz al 68° percentile, +/- 4 metri con una larghezza di banda di 40 MHz al 68° percentile e +/- 8 metri con una larghezza di banda di 20 MHz al 68° percentile a distanze di 10 cm, 1 m, 3 m e 5 m, come osservato tramite l'API Android WifiRttManager#startRanging.
[7.4.2.5/H-SR-1] È VIVAMENTE CONSIGLIATO segnalare l'intervallo con una precisione di +/- 1 metro a una larghezza di banda di 160 MHz al 90° percentile (come calcolato con la funzione di distribuzione cumulativa), +/- 2 metri a una larghezza di banda di 80 MHz al 90° percentile, +/- 4 metri a una larghezza di banda di 40 MHz al 90° percentile, e +/- 8 metri a una larghezza di banda di 20 MHz al 90° percentile a distanze di 10 cm, come osservato tramite l'API WifiRttManager#startRanging di Android.

È VIVAMENTE CONSIGLIATO seguire i passaggi di configurazione della misurazione specificati in Calibrazione della presenza.

Se i dispositivi portatili supportano il protocollo di rilevamento di prossimità (PD) Wi-Fi dichiarando PackageManager.FEATURE_WIFI_PD e la posizione Wi-Fi (tempo di andata e ritorno Wi-Fi - RTT) dichiarando PackageManager.FEATURE_WIFI_RTT, allora:

[7.4.2.10/H-1-1] DEVE utilizzare una larghezza di banda di almeno 160 MHz.
[7.4.2.10/H-1-2] DEVE segnalare l'intervallo con una precisione di +/- 0,25 metri a una larghezza di banda di 160 MHz al 68° percentile (come calcolato con la funzione di distribuzione cumulativa), come osservato tramite l'API Android WifiRttManager#startRanging.

È VIVAMENTE CONSIGLIATO seguire i passaggi di configurazione della misurazione specificati in Calibrazione della presenza.

Se le implementazioni di dispositivi palmari dichiarano FEATURE_BLUETOOTH_LE:

[7.4.3/H-1-3] DEVE misurare e compensare l'offset Rx per garantire che l'RSSI BLE mediano sia -50 dBm +/-15 dB a 1 m di distanza da un dispositivo di riferimento che trasmette a ADVERTISE_TX_POWER_HIGH.
[7.4.3/H-1-4] DEVE misurare e compensare l'offset di trasmissione per garantire che l'RSSI BLE mediano sia pari a -50 dBm +/-15 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e la trasmissione a ADVERTISE_TX_POWER_HIGH.

Se le implementazioni di dispositivi palmari includono almeno una fotocamera posteriore:

[7.5.1/H-1-1] DEVE avere una risoluzione di almeno 2 megapixel.

Se le implementazioni di dispositivi palmari includono un dispositivo fotocamera logico che elenca le funzionalità utilizzando CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, questi:

[7.5.4/H-1-1] DEVE avere un campo visivo normale per impostazione predefinita e DEVE essere compreso tra 50 e gradi.

Implementazioni di dispositivi palmari:

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

Se le implementazioni dei dispositivi palmari dichiarano il supporto di una sola ABI a 32 bit:

[7.6.1/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 del framebuffer fino a qHD (ad es. FWVGA).
[7.6.1/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 del framebuffer fino a HD+ (ad es. HD, WSVGA).
[7.6.1/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 del framebuffer fino a FHD (ad es. WSXGA+).
[7.6.1/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 del framebuffer fino a QHD (ad es. QWXGA).

Se le implementazioni dei dispositivi palmari dichiarano il supporto di qualsiasi ABI a 64 bit (con o senza ABI a 32 bit):

[7.6.1/H-5-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere almeno 816 MB se il display predefinito utilizza risoluzioni framebuffer fino a qHD (ad es. FWVGA).
[7.6.1/H-6-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere almeno 944 MB se il display predefinito utilizza risoluzioni del framebuffer fino a HD+ (ad es. HD, WSVGA).
[7.6.1/H-7-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere almeno 1280 MB se il display predefinito utilizza risoluzioni del framebuffer fino a FHD (ad es. WSXGA+).
[7.6.1/H-8-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere 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" sopra indicata 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 dei dispositivi.

Se le implementazioni di dispositivi palmari includono una memoria disponibile per il kernel e lo spazio utente inferiore o uguale a 1 GB,

[7.6.1/H-9-1] DEVE dichiarare il flag funzionalità android.hardware.ram.low.
[7.6.1/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 di dispositivi palmari includono più di 1 GB di memoria disponibile per il kernel e lo spazio utente:

[7.6.1/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.

Se le implementazioni di dispositivi palmari includono una memoria disponibile per il kernel e lo spazio utente maggiore o uguale a 2 GB e inferiore a 4 GB:

[7.6.1/H-SR-1] È VIVAMENTE CONSIGLIATO di supportare solo lo spazio utente a 32 bit (sia per le app che per il codice di sistema)

Se le implementazioni di dispositivi palmari includono meno di 2 GB di memoria disponibile per il kernel e lo spazio utente:

[7.6.1/H-1-1] DEVE supportare una sola ABI (solo a 64 bit o solo a 32 bit).

Implementazioni di dispositivi palmari:

[7.6.2/H-0-1] NON DEVE fornire uno spazio di archiviazione condiviso dell'applicazione inferiore a 1 GiB.
[7.7.1/H] DEVE includere una porta USB che supporti la modalità periferica.

Se le implementazioni di dispositivi palmari includono una porta USB con un controller che funziona in modalità periferica,

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

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

[7.7.2/H-1-1] DEVE implementare la classe audio USB come documentato nella documentazione dell'SDK Android.

Implementazioni di dispositivi palmari:

[7.8.1/H-0-1] DEVE includere un microfono.
[7.8.2/H-0-1] DEVE avere un'uscita audio e dichiarare android.hardware.audio.output.

Se le implementazioni di dispositivi palmari sono in grado di soddisfare tutti i requisiti di prestazioni per supportare la Modalità VR e includono il supporto,

[7.9.1/H-1-1] DEVE dichiarare il flag funzionalità android.hardware.vr.high_performance.
[7.9.1/H-1-2] DEVE includere un'applicazione che implementi android.service.vr.VrListenerService che può essere attivata da applicazioni VR tramite android.app.Activity#setVrModeEnabled.

Se le implementazioni di dispositivi palmari includono una o più porte USB-C in modalità host e implementano (classe audio USB), oltre ai requisiti della sezione 7.7.2, devono:

[7.8.2.2/H-1-1] DEVE fornire la seguente mappatura del software dei codici HID:

Funzione	Mappature	Contesto	Comportamento
A	Pagina di utilizzo HID: 0x0C Utilizzo HID: 0x0CD Tasto del kernel: `KEY_PLAYPAUSE` Tasto Android: `KEYCODE_MEDIA_PLAY_PAUSE`	Riproduzione di contenuti multimediali	Input: pressione breve Output: riproduci o metti in pausa
		Riproduzione di contenuti multimediali	Input: tieni premuto Output: avvia il comando vocale Invio: `android.speech.action.VOICE_SEARCH_HANDS_FREE` se il dispositivo è bloccato o lo schermo è spento. Invia `android.speech.RecognizerIntent.ACTION_WEB_SEARCH` altrimenti
		Chiamata in arrivo	Input: pressione breve Output: accetta chiamata
		Chiamata in arrivo	Input: tieni premuto Output: rifiuta chiamata
		Chiamata in corso	Input: pressione breve Output: termina la chiamata
		Chiamata in corso	Input: pressione prolungata Output: disattiva o riattiva il microfono
B	Pagina di utilizzo HID: 0x0C Utilizzo HID: 0x0E9 Chiave del kernel: `KEY_VOLUMEUP` Chiave Android: `VOLUME_UP`	Riproduzione di contenuti multimediali, Chiamata in corso	Input: pressione breve o lunga Output: aumenta il volume del sistema o delle cuffie
C	Pagina di utilizzo HID: 0x0C Utilizzo HID: 0x0EA Chiave del kernel: `KEY_VOLUMEDOWN` Chiave Android: `VOLUME_DOWN`	Riproduzione di contenuti multimediali, Chiamata in corso	Input: pressione breve o lunga Output: diminuisce il volume del sistema o delle cuffie
D	Pagina di utilizzo HID: 0x0C Utilizzo HID: 0x0CF Chiave kernel: `KEY_VOICECOMMAND` Chiave Android: `KEYCODE_VOICE_ASSIST`	Tutte. Può essere attivato in qualsiasi istanza.	Input: pressione breve o lunga Output: avvia il comando vocale

[7.8.2.2/H-1-2] DEVE attivare ACTION_HEADSET_PLUG all'inserimento di un connettore, ma solo dopo che le interfacce e gli endpoint audio USB sono stati enumerati correttamente per identificare il tipo di terminale collegato.

Quando vengono rilevati i tipi di terminale audio USB 0x0302, questi:

[7.8.2.2/H-2-1] DEVE trasmettere l'intent ACTION_HEADSET_PLUG con l'extra "microphone" impostato su 0.

Quando vengono rilevati i tipi di terminale audio USB 0x0402:

[7.8.2.2/H-3-1] DEVE trasmettere l'intent ACTION_HEADSET_PLUG con l'extra "microphone" impostato su 1.

Quando viene chiamata l'API AudioManager.getDevices() mentre la periferica USB è collegata:

[7.8.2.2/H-4-1] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e ruolo isSink() se il campo Tipo di terminale audio USB è 0x0302.
[7.8.2.2/H-4-2] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e ruolo isSink() se il campo del tipo di terminale audio USB è 0x0402.
[7.8.2.2/H-4-3] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e ruolo isSource() se il campo tipo di terminale audio USB è 0x0402.
[7.8.2.2/H-4-4] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_DEVICE e ruolo isSink() se il campo del tipo di terminale audio USB è 0x603.
[7.8.2.2/H-4-5] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_DEVICE e ruolo isSource() se il campo del tipo di terminale audio USB è 0x604.
[7.8.2.2/H-4-6] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_DEVICE e ruolo isSink() se il campo tipo di terminale audio USB è 0x400.
[7.8.2.2/H-4-7] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_DEVICE e ruolo isSource() se il campo del tipo di terminale audio USB è 0x400.
[7.8.2.2/H-SR-1] Sono FORTEMENTE CONSIGLIATI al collegamento di una periferica audio USB-C, per eseguire l'enumerazione dei descrittori USB, identificare i tipi di terminale e trasmettere l'intent ACTION_HEADSET_PLUG in meno di 1000 millisecondi.

Per le implementazioni di dispositivi palmari che dichiarano android.hardware.audio.output e android.hardware.microphone, consulta i requisiti RTL e TTL nella sezione 5.6.

Un attuatore risonante lineare (LRA) è un sistema a molla a massa singola che ha una frequenza di risonanza dominante in cui la massa si sposta nella direzione del movimento desiderato.

Se le implementazioni di dispositivi palmari includono almeno un attuatore 7.10 lineare risonante per uso generico, questi:

[7.10/H] DEVE posizionare l'attuatore vicino alla posizione in cui il dispositivo viene in genere tenuto o toccato con le mani.
[7.10/H] DEVE spostare l'attuatore aptico sull'asse X (sinistra-destra) dell'orientamento naturale del dispositivo.

Se le implementazioni di dispositivi palmari hanno un attuatore aptico generico che è un attuatore risonante lineare (LRA) sull'asse X, allora:

[7.10/H] DEVE avere la frequenza di risonanza dell'LRA dell'asse X inferiore a 200 Hz.

Se le implementazioni dei dispositivi palmari seguono la mappatura delle costanti aptiche,

[7.10/H]^* DEVE verificare lo stato di implementazione eseguendo le API android.os.Vibrator.areAllEffectsSupported() e android.os.Vibrator.arePrimitivesSupported().
[7.10/H]^* DEVE eseguire una valutazione della qualità per le costanti aptiche.
[7.10/H]^* DEVE verificare e aggiornare, se necessario, la configurazione di riserva per le primitive non supportate, come descritto nelle indicazioni per l'implementazione per le costanti.

2.2.2. Multimediali

Le implementazioni dei dispositivi palmari DEVONO supportare i seguenti formati di codifica e decodifica audio e renderli disponibili per le applicazioni di terze parti:

[5.1/H-0-1] AMR-NB
[5.1/H-0-2] AMR-WB
[5.1/H-0-3] Profilo MPEG-4 AAC (AAC LC)
[5.1/H-0-4] Profilo MPEG-4 HE AAC (AAC+)
[5.1/H-0-5] AAC ELD (enhanced low delay AAC)

[5.1/H-0-6] MPEG-D USAC con MPEG-D DRC (Extended High Efficiency AAC)

2.2.3. Software

Le implementazioni dei dispositivi palmari DEVONO supportare i seguenti formati di codifica video e renderli disponibili per le applicazioni di terze parti:

[5.2/H-0-1] H.264 AVC
[5.2/H-0-2] VP8
[5.2/H-0-3] AV1

Le implementazioni dei dispositivi palmari DEVONO supportare i seguenti formati di decodifica video e renderli disponibili per le applicazioni di terze parti:

[5.3/H-0-1] H.264 AVC
[5.3/H-0-2] H.265 HEVC
[5.3/H-0-3] MPEG-4 SP
[5.3/H-0-4] VP8
[5.3/H-0-5] VP9
[5.3/H-0-6] AV1

2.2.3. Software

Implementazioni di dispositivi palmari:

[3.2.3.1/H-0-1] DEVE avere un'applicazione che gestisca gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE e ACTION_CREATE_DOCUMENT come descritto nei documenti dell'SDK e fornire all'utente la possibilità di accedere ai dati del provider di documenti utilizzando l'API DocumentsProvider.

[3.2.3.1/H-0-2]^* DEVE precaricare uno o più componenti di applicazioni o servizi con un gestore di intent, per tutti i pattern di filtri per intent pubblici definiti dagli intent delle applicazioni elencati qui. Nota: la pagina "Intent comuni delle app" includerà il nuovo intent obbligatorio "android.settings.VPN_APP_EXCLUSION_SETTINGS".

[3.2.3.1/H-SR-1] È FORTEMENTE CONSIGLIATO precaricare un'applicazione email in grado di gestire intent ACTION_SENDTO o ACTION_SEND o ACTION_SEND_MULTIPLE per inviare un'email.
[3.4.1/H-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.
[3.4.2/H-0-1] DEVE includere un'applicazione browser autonoma per la navigazione web generica degli utenti.

[3.8.1/H-0-1] DEVE implementare un Avvio app predefinito che supporti l'aggiunta di widget all'interno delle app.

[3.8.1/H-SR-1] È FORTEMENTE CONSIGLIATO implementare un launcher predefinito che supporti l'aggiunta di scorciatoie, widget e widgetFeatures all'interno dell'app.
[3.8.1/H-SR-2] È VIVAMENTE CONSIGLIATO implementare un launcher predefinito che fornisca un accesso rapido alle scorciatoie aggiuntive fornite da app di terze parti tramite l'API ShortcutManager.
[3.8.1/H-SR-3] È VIVAMENTE CONSIGLIATO includere un'app di avvio predefinita che mostri i badge per le icone delle app.

[3.8.2/H-SR-1] Sono FORTEMENTE CONSIGLIATE per supportare i widget delle app di terze parti.

[3.8.2/H-0-1] DEVE supportare i widget delle app di terze parti.

[3.8.3/H-0-1] DEVE consentire alle app di terze parti di notificare agli utenti eventi importanti tramite le classi API Notification e NotificationManager.
[3.8.3/H-0-2] DEVE supportare le notifiche avanzate.
[3.8.3/H-0-3] DEVE supportare le notifiche in primo piano.
[3.8.3/H-0-4] DEVE includere un'area notifiche, che offre all'utente la possibilità di controllare direttamente (ad es. rispondere, posticipare, chiudere, bloccare) le notifiche tramite funzionalità utente come pulsanti di azione o il pannello di controllo come implementato in AOSP.
[3.8.3/H-0-5] DEVONO essere visualizzate le scelte fornite tramite RemoteInput.Builder setChoices() nell'area notifiche.
[3.8.3/H-SR-1] È FORTEMENTE CONSIGLIATO visualizzare la prima scelta fornita tramite RemoteInput.Builder setChoices() nell'area notifiche senza ulteriori interazioni utente.
[3.8.3/H-SR-2] È VIVAMENTE CONSIGLIATO di mostrare tutte le scelte fornite tramite RemoteInput.Builder setChoices() nell'area notifiche quando l'utente espande tutte le notifiche nell'area notifiche.
[3.8.3.1/H-SR-1] È VIVAMENTE CONSIGLIATO di mostrare le azioni per le quali Notification.Action.Builder.setContextual è impostato come true in linea con le risposte visualizzate da Notification.Remoteinput.Builder.setChoices.
[3.8.4/H-SR-1] È VIVAMENTE CONSIGLIATO di implementare un assistente sul dispositivo per gestire l'azione Assist.

Se le implementazioni dei dispositivi portatili supportano le notifiche MediaStyle, queste:

[3.8.3.1/H-SR-2] È VIVAMENTE CONSIGLIATO fornire un'opzione per l'utente (ad esempio, un selettore di output) accessibile dall'interfaccia utente di sistema che consenta agli utenti di passare da un percorso multimediale disponibile all'altro (ad esempio, dispositivi Bluetooth e percorsi forniti a MediaRouter2Manager) quando un'app pubblica una notifica MediaStyle con un token MediaSession.

La notifica di aggiornamento live di un'app può essere promossa quando l'app soddisfa tutte le caratteristiche di promozione. Questa notifica è descritta come notifica di aggiornamento live promozionale in questo documento. Le implementazioni dei dispositivi palmari DEVONO mostrare in modo ben visibile la notifica di aggiornamento live promozionale in base ai seguenti requisiti.

Se le implementazioni dei dispositivi palmari dichiarano il livello API 36.1 o versioni successive:

[3.8.3.1/H-0-1] DEVE mostrare una notifica di aggiornamento live promozionale in una posizione ben visibile sulla schermata di blocco.
[3.8.3.1/H-0-12] DEVE essere visualizzata in cima alla pila di notifiche Notifica Heads Up e sopra le notifiche colorate (dove setColorized è true) quando la notifica di aggiornamento live promozionale viene visualizzata tra le altre notifiche.
- MAY determine the order sequence of Promoted Live Update Notifications displayed within notification shade and lock screen when more than one app is eligible for Promoted Live Update Notification.
[3.8.3.1/H-0-2] DEVE mostrare una notifica di aggiornamento live promozionale nello stato espanso.
[3.8.3.1/H-0-3] NON DEVE fornire un'affordance utente per comprimere la notifica espansa sopra.
[3.8.3.1/H-0-4] DEVE mostrare gli stili di base (grassetto, corsivo e sottolineato) dei contenuti di testo in una notifica di aggiornamento live promozionale, come fornito da StyleSpan o UnderlineSpan.
[3.8.3.1/H-0-5] DEVE mostrare solo oggetti azione standard (tramite Notification.Action), e DEVE nascondere oggetti azione non standard come caselle di input, pulsanti di risposta e azioni contestuali (tramite addRemoteInput() e setContextual()) in una notifica di aggiornamento live promozionale, anche quando la notifica li contiene.
[3.8.3.1/H-0-6] DEVE mostrare una rappresentazione compatta, chiamata anche chip di stato nella documentazione dell'SDK, per una notifica di aggiornamento live promozionale che DEVE includere Notification.getSmallIcon().
- [3.8.3.1/H-0-7] Gli altri campi sono facoltativi per la rappresentazione compatta, ma ogni volta che la rappresentazione compatta può essere espansa, DEVE mostrare Notification.getShortCriticalText() se presente o Notification.when se Notification.getShortCriticalText non è presente.
- [3.8.3.1/H-0-8] Quando sono presenti più notifiche di aggiornamento live promozionale, DEVE visualizzarne almeno una nella barra di stato come rappresentazione compatta.
- [3.8.3.1/H-0-9] DEVE mostrare la notifica associata (preferibile) o aprire l'app associata (tramite Notification.contentIntent) quando l'utente tocca la rappresentazione compatta.
- [3.8.3.1/H-0-13] DEVE mostrare gli stessi contenuti nella notifica associata di quelli disponibili nell'area notifiche.
[3.8.3.1/H-0-10] DEVE fornire un'agevolazione per l'utente per disattivare e attivare la visualizzazione promozionale delle notifiche delle singole app.
[3.8.3.1/H-0-11] DEVE eseguire il rendering corretto di tutte le notifiche di aggiornamento live, incluse, a titolo esemplificativo, le notifiche di aggiornamento live non promosse che non soddisfano o soddisfano solo parzialmente le caratteristiche della promozione. Queste notifiche non promosse DEVONO essere visualizzate in uno stato non promosso.

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

[3.8.3/H-1-1] DEVE implementare il comportamento di blocco su schermo e fornire all'utente un menu delle impostazioni per attivare/disattivare la funzionalità.

Se le implementazioni di dispositivi palmari supportano l'azione Assistente, devono:

[3.8.4/H-SR-2] È FORTEMENTE CONSIGLIATO di utilizzare la pressione prolungata del tasto HOME come 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.

Se le implementazioni dei dispositivi palmari supportano conversation notifications e le raggruppano in una sezione separata dalle notifiche di avviso e silenziose non di conversazione, queste:

[3.8.4/H-1-1]^* DEVE mostrare le notifiche di conversazione prima delle notifiche non di conversazione, ad eccezione delle notifiche di servizi in primo piano in corso e delle notifiche con importanza:alta.

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

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

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

[3.9/H-1-1] DEVE implementare l'intera gamma di criteri di amministrazione dei dispositivi definiti nella documentazione dell'SDK Android.

Se le implementazioni dei dispositivi palmari includono il supporto delle API ControlsProviderService e Control e consentono alle applicazioni di terze parti di pubblicare controllo dei dispositivi, devono:

[3.8.16/H-1-1] DEVE dichiarare il flag della funzionalità android.software.controls e impostarlo su true.
[3.8.16/H-1-2] DEVE fornire un'interfaccia utente con la possibilità di aggiungere, modificare, selezionare e utilizzare i controlli dei dispositivi preferiti dell'utente dai controlli registrati dalle applicazioni di terze parti tramite le API ControlsProviderService e Control.
[3.8.16/H-1-3] DEVE fornire l'accesso a questa funzionalità utente entro tre interazioni da un Avvio app predefinito.
[3.8.16/H-1-4] DEVE eseguire il rendering in questa funzionalità per l'utente del nome e dell'icona di ogni app di terze parti che fornisce controlli tramite l'API ControlsProviderService e di tutti i campi specificati forniti dalle API Control.
[3.8.16/H-1-5] DEVE fornire un'opzione per disattivare i controlli del dispositivo di autenticazione banale designati dall'app dai controlli registrati dalle applicazioni di terze parti tramite l'API ControlsProviderService e l'API Control Control.isAuthRequired.
[3.8.16/H-1-6] Le implementazioni del dispositivo DEVONO eseguire il rendering accurato dell'ausilio per l'utente nel seguente modo:
- Se il dispositivo ha impostato config_supportsMultiWindow=true e l'app dichiara i metadati META_DATA_PANEL_ACTIVITY nella dichiarazione ControlsProviderService, incluso il ComponentName di un'attività valida (come definita dall'API), l'app DEVE incorporare questa attività in questa funzionalità per l'utente.
- Se l'app non dichiara i metadati META_DATA_PANEL_ACTIVITY, deve eseguire il rendering dei campi specificati forniti dall'API ControlsProviderService, nonché di tutti i campi specificati forniti dalle API Control.
[3.8.16/H-1-7] Se l'app dichiara i metadati META_DATA_PANEL_ACTIVITY, DEVE superare l'impostazione definita in [3.8.16/H-1-5] utilizzando EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS all'avvio dell'attività incorporata.

Al contrario, se le implementazioni dei dispositivi palmari non implementano questi controlli, non:

[3.8.16/H-2-1] DEVE segnalare null per le API ControlsProviderService e Control.
[3.8.16/H-2-2] DEVE dichiarare il flag della funzionalità android.software.controls e impostarlo su false.

Se le implementazioni dei dispositivi palmari non vengono eseguite in modalità di blocco attività, quando i contenuti vengono copiati negli appunti:

[3.8.17/H-1-1] DEVE mostrare all'utente una conferma che i dati sono stati copiati negli appunti (ad es. una miniatura o un avviso con il messaggio "Contenuti copiati"). Inoltre, indica qui se i dati degli appunti verranno sincronizzati su tutti i dispositivi.

Implementazioni di dispositivi palmari:

[3.10/H-0-1] DEVE supportare servizi di accessibilità di terze parti.
[3.10/H-SR-1] È VIVAMENTE CONSIGLIATO precaricare servizi di accessibilità sul dispositivo paragonabili o superiori alla funzionalità dei servizi di accessibilità Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato) come forniti nel progetto open source TalkBack.
[3.11/H-0-1] DEVE supportare l'installazione di motori TTS di terze parti.
[3.11/H-SR-1] È FORTEMENTE CONSIGLIATO includere un motore TTS che supporti le lingue disponibili sul dispositivo.
[3.13/H-SR-1] È FORTEMENTE CONSIGLIATO includere un componente UI Impostazioni rapide.

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

[3.16/H-1-1] DEVE supportare la funzionalità di accoppiamento di dispositivi complementari.

Se la funzione di navigazione viene fornita come azione sullo schermo basata su gesti:

Implementazioni di dispositivi palmari:

[3.20.1/H-0-1] DEVE implementare tutti i requisiti relativi al flusso audio dell'assistente.

[7.2.3/H] La zona di riconoscimento dei gesti per la funzione Home NON DEVE superare i 32 dp di altezza dalla parte inferiore dello schermo.

Se le implementazioni dei dispositivi palmari forniscono una funzione di navigazione come gesto da qualsiasi punto dei bordi sinistro e destro dello schermo:

[7.2.3/H-0-1] L'area dei gesti della funzione di navigazione DEVE avere una larghezza inferiore a 40 dp su ogni lato. L'area dei gesti DOVREBBE avere una larghezza di 24 dp per impostazione predefinita.

Se le implementazioni di dispositivi palmari supportano una schermata di blocco sicura e hanno una memoria disponibile per il kernel e lo spazio utente maggiore o uguale a 2 GB,

[3.9/H-1-2] DEVE dichiarare il supporto dei profili gestiti tramite il flag di funzionalità android.software.managed_users.

Se le implementazioni di dispositivi palmari Android dichiarano il supporto della fotocamera tramite android.hardware.camera.any:

[7.5.4/H-1-1] DEVE rispettare l'intent android.media.action.STILL_IMAGE_CAMERA e android.media.action.STILL_IMAGE_CAMERA_SECURE e avviare la fotocamera in modalità immagine statica come descritto nell'SDK.
[7.5.4/H-1-2] DEVE rispettare l'intent android.media.action.VIDEO_CAMERA di avviare la fotocamera in modalità video come descritto nell'SDK.

Se l'applicazione delle impostazioni dell'implementazione del dispositivo implementa una funzionalità di divisione, utilizzando l'incorporamento di attività, essa:

[3.2.3.1/ H-1-1] DEVE avere un'attività che gestisce l'intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY quando la funzionalità di divisione è attiva. L'attività DEVE essere protetta da android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK e DEVE avviare l'attività dell'intent analizzato da Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

Se le implementazioni dei dispositivi consentono agli utenti di effettuare chiamate di qualsiasi tipo,

[7.4.1.2/H-0-1] DEVE dichiarare il flag funzionalità android.software.telecom.

[7.4.1.2/H-0-2] DEVE implementare il framework telecom.

2.2.4. Prestazioni e potenza

[8.1/H-0-1] Latenza dei frame coerente. La latenza dei frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più di 5 frame al secondo e DOVREBBE essere inferiore a 1 frame al secondo.
[8.1/H-0-2] Latenza dell'interfaccia utente. Le implementazioni del dispositivo DEVONO garantire un'esperienza utente a bassa latenza scorrendo un elenco di 10.000 voci di elenco come definito da Android Compatibility Test Suite (CTS) in meno di 36 secondi.
[8.1/H-0-3] Passaggio da un'attività all'altra. Quando sono state avviate più applicazioni, il riavvio di un'applicazione già in esecuzione dopo l'avvio deve richiedere meno di 1 secondo.

Implementazioni di dispositivi palmari:

[8.2/H-0-1] DEVE garantire una velocità di scrittura sequenziale di almeno 5 MB/s.
[8.2/H-0-2] DEVE garantire una velocità di scrittura casuale di almeno 0,5 MB/s.
[8.2/H-0-3] DEVE garantire una lettura sequenziale con prestazioni di almeno 15 MB/s.
[8.2/H-0-4] DEVE garantire una velocità di lettura casuale di almeno 3,5 MB/s.

Se le implementazioni di dispositivi portatili includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP, queste:

[8.3/H-1-1] DEVE fornire all'utente la possibilità di attivare e disattivare la funzionalità di risparmio energetico.
[8.3/H-1-2] DEVE fornire all'utente la possibilità di visualizzare tutte le app esentate dalle modalità di risparmio energetico Standby delle app e Sospensione.

Implementazioni di dispositivi palmari:

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

Se le implementazioni di dispositivi palmari includono uno schermo o un'uscita video:

[8.4/H-1-1] DEVE rispettare l'intento di android.intent.action.POWER_USAGE_SUMMARY e mostrare un menu delle impostazioni che mostri questo consumo energetico.

Implementazioni di dispositivi palmari:

[8.5/H-0-1] DEVE fornire un'interfaccia utente per visualizzare tutte le app con servizi in primo piano attivi o job avviati dall'utente, inclusa la durata di ciascuno di questi servizi dall'inizio, come descritto nel documento SDK.
[8.5/H-0-2]DEVE fornire un'interfaccia utente per interrompere un'app che esegue un servizio in primo piano o un job avviato dall'utente.

2.2.5. Modello di sicurezza

Implementazioni di dispositivi palmari:

[9/H-0-1] DEVE dichiarare la funzionalità android.hardware.security.model.compatible.
[9.1/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.

Se le implementazioni di dispositivi palmari includono un'applicazione predefinita per supportare VoiceInteractionService, queste:

[9.1/H-0-2] NON DEVE concedere ACCESS_FINE_LOCATION come valore predefinito per l'applicazione.

Le implementazioni dei dispositivi DEVONO dichiarare il supporto di android.software.credentials e:

[9/H-0-2] DEVE rispettare l'android.settings.CREDENTIAL_PROVIDERintento di consentire la selezione di un provider preferito per Gestore delle credenziali. Questo provider verrà attivato per la compilazione automatica e sarà anche la posizione predefinita per salvare le nuove credenziali inserite tramite Gestore delle credenziali.
[9/H-0-3] DEVE supportare almeno due provider di credenziali simultanei e fornire un invito per l'utente nell'app Impostazioni per attivare o disabilitare i provider.
[9.5/H-1-1] Requisito rimosso in Android 16.

Implementazioni di dispositivi palmari:

[9.11/H-0-2] MUST back up the keystore implementation with an isolated execution environment.
[9.11/H-0-3] DEVE avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e delle funzioni hash MD5, SHA-1 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 versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi con cui il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto Android Open Source Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti esaminata di un isolamento basato su hypervisor adeguato sono opzioni alternative.
[9.11/H-0-4] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere archiviate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto open source Android fornisce il livello di astrazione hardware (HAL) Gatekeeper e Trusty, che possono essere utilizzati per soddisfare questo requisito.
[9.11/H-0-5] DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma è eseguita in hardware sicuro. Le chiavi di firma dell'attestazione NON DEVONO essere utilizzate come identificatori permanenti del dispositivo.

Nota :per soddisfare questo requisito, devi condividere la stessa chiave di attestazione per un determinato SKU,a meno che non vengano prodotte almeno 100.000 unità di questo SKU. Se vengono prodotte più di 100.000 unità di questo SKU, DOPO questa quantità POTREBBE essere utilizzata una chiave diversa per ogni gruppo di 100.000 unità. In alternativa, è possibile utilizzare la soluzione di provisioning delle chiavi remoto per eseguire il provisioning di chiavi di attestazione di breve durata sul dispositivo.

Tieni presente che se l'implementazione di un dispositivo è già stata lanciata su una versione precedente di Android, il dispositivo è esente dal requisito di disporre di un keystore supportato da un ambiente di esecuzione isolato e supportare l'attestazione della chiave, a meno che non dichiari la funzionalità android.hardware.fingerprint, che richiede un keystore supportato da un ambiente di esecuzione isolato.

Quando le implementazioni di dispositivi palmari supportano una schermata di blocco sicura:

[9.11/H-1-1] DEVE consentire all'utente di scegliere il timeout di sospensione più breve, ovvero un tempo di transizione dallo stato sbloccato a quello bloccato, pari a 15 secondi o meno.
[9.11/H-1-2] DEVE fornire all'utente la possibilità di nascondere le notifiche e disattivare tutte le forme di autenticazione, ad eccezione dell'autenticazione principale descritta in 9.11.1 Schermata di blocco sicura. AOSP soddisfa il requisito come modalità di blocco.

Se le implementazioni del dispositivo hanno una schermata di blocco sicura e includono uno o più agenti di attendibilità, che implementano l'API di sistema TrustAgentService, si verifica quanto segue:

[9.11.1/H-1-1] DEVE richiedere all'utente uno dei metodi di autenticazione primaria consigliati (ad esempio PIN, sequenza o password) più di una volta ogni 72 ore.

Se le implementazioni dei dispositivi palmari hanno una schermata di blocco sicura e includono uno o più agenti di attendibilità che chiamano l'API di sistema TrustAgentService.grantTrust() con il flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, questi:

[9.11.1/H-1-1] DEVE chiamare TrustManagerService.revokeTrust() dopo una delle seguenti azioni:
- Un massimo di 24 ore dalla concessione dell'attendibilità.
- Una finestra di inattività di 8 ore.

Se le implementazioni di dispositivi palmari includono più utenti e non dichiarano il flag funzionalità android.hardware.telephony,

[9.5/H-2-1] DEVE supportare i profili con limitazioni, una funzionalità che consente ai proprietari del dispositivo di gestire altri utenti e le loro funzionalità sul dispositivo. Con i profili con limitazioni, i proprietari dei dispositivi possono configurare rapidamente ambienti separati in cui far lavorare altri utenti, con la possibilità di gestire limitazioni più granulari nelle app disponibili in questi ambienti.

Se le implementazioni di dispositivi palmari includono più utenti e dichiarano il flag funzionalità android.hardware.telephony:

[9.5/H-3-1] NON DEVE supportare i profili con limitazioni, ma DEVE essere in linea con l'implementazione AOSP dei controlli per consentire /disattivare l'accesso di altri utenti alle chiamate vocali e agli SMS.
[9.5/H-4-1] Requisito rimosso in Android 16.
[9.5/H-4-2] Requisito rimosso in Android 16.

Impostazioni limitate

Le impostazioni con restrizioni forniscono all'utente avvisi visibili e richiedono la conferma dell'utente per concedere le autorizzazioni per ogni applicazione che:

Installazione dopo il download tramite un'applicazione (ad esempio un'applicazione di messaggistica o un browser) diversa da un'applicazione "app store" identificata da PackageManager come PACKAGE_DOWNLOADED_FILE.
Installazione da un file locale (ad esempio, l'applicazione è stata caricata lateralmente) identificata da PackageManager come PACKAGE_SOURCE_LOCAL_FILE.

Per qualsiasi autorizzazione forzata e i relativi identificatori elencati in [9.8/H-0-5] di seguito.

Queste applicazioni sono etichettate come "Applicazioni coperte" per i requisiti elencati in questa sezione.

Implementazioni del dispositivo:

[9.8/H-0-1] MUST implement Restricted Settings as outlined above for the following:
- Autorizzazioni speciali
  - Accessibilità (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
  - Listener di notifica (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
  - App di amministrazione del dispositivo (Manifest.permission.BIND_DEVICE_ADMIN)
  - Mostra sopra altre app (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
  - Accesso ai dati d'uso (AppOpsManager.OPSTR_GET_USAGE_STATS)
- Ruoli (app predefinite)
  - Tastierino (RoleManager.ROLE_DIALER)
  - SMS (RoleManager.ROLE_SMS)
- Autorizzazioni di runtime
  - Durata dell'SMS (Manifest.permission_group.SMS)
[9.8/H-0-2] DEVE attivare le Impostazioni con limitazioni come impostazione predefinita ed è FORTEMENTE CONSIGLIATO di non avere alcuna funzionalità che consenta a un utente di disattivare le Impostazioni con limitazioni per tutte le applicazioni.
[9.8/H-0-3] DEVE garantire che venga ottenuta la conferma dell'utente per ogni Applicazione coperta prima che possa essere concessa una qualsiasi delle Autorizzazioni applicate.
[9.8/H-0-4] DEVE consentire di ottenere la conferma dell'utente per attivare le impostazioni con limitazioni solo dalla pagina AppInfo dell'applicazione coperta, utilizzando l'API EnhancedConfirmationManager.
[9.8/H-0-5] È VIVAMENTE CONSIGLIATO di eseguire l'integrazione con EnhancedConfirmationManager e chiamarlo per tutte le autorizzazioni speciali, per determinare dinamicamente se si tratta di un'impostazione con limitazioni.
- Sveglie e promemoria: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- Accesso a tutti i file: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- Mostra sopra altre app: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- Installa app sconosciute: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- Gestisci contenuti multimediali: AppOpsManager.OPSTR_MANAGE_MEDIA
- Modifica impostazioni sistema: AppOpsManager.OPSTR_WRITE_SETTINGS
- Picture in picture: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- Attiva lo schermo: AppOpsManager.OPSTR_TURN_SCREEN_ON
- Notifiche a schermo intero: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- Controllo del Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- Accessibilità: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- Listener di notifica: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- Accesso ai dati d'uso: AppOpsManager.OPSTR_GET_USAGE_STATS
- Amministratore del dispositivo: Manifest.permission.BIND_DEVICE_ADMIN
- Non disturbare: Manifest.permission.MANAGE_NOTIFICATIONS

Android, tramite l'API di sistema VoiceInteractionService, supporta un meccanismo per il rilevamento hotword sicuro e sempre attivo senza indicazione di accesso al microfono e il rilevamento di query sempre attivo, senza indicazione di accesso al microfono o alla fotocamera.

Se le implementazioni dei dispositivi palmari supportano l'API di sistema HotwordDetectionService o un altro meccanismo per il rilevamento dell'hotword senza indicazione di accesso al microfono:

[9.8/H-1-1] DEVE assicurarsi che il servizio di rilevamento dell'hotword possa trasmettere dati solo al sistema, ContentCaptureService, o al servizio di riconoscimento vocale sul dispositivo creato da SpeechRecognizer#createOnDeviceSpeechRecognizer().
[9.8/H-1-2] DEVE assicurarsi che il servizio di rilevamento dell'hotword possa trasmettere i dati audio del microfono o i dati derivati solo al server di sistema tramite l'API HotwordDetectionService o a ContentCaptureService tramite l'API ContentCaptureManager.
[9.8/H-1-3] NON DEVE fornire audio del microfono più lungo di 30 secondi per una singola richiesta attivata dall'hardware al servizio di rilevamento dell'hotword.
[9.8/H-1-4] NON DEVE fornire audio del microfono memorizzato nel buffer più vecchio di 8 secondi per una singola richiesta al servizio di rilevamento hotword.
[9.8/H-1-5] NON DEVE fornire audio del microfono memorizzato nel buffer più vecchio di 30 secondi al servizio di interazione vocale o a un'entità simile.
[9.8/H-1-6] NON DEVE consentire la trasmissione di più di 100 byte di dati (esclusi i flussi audio) dal servizio di rilevamento dell'hotword a ogni risultato positivo dell'hotword.
[9.8/H-1-7] NON DEVE consentire la trasmissione di più di 5 bit di dati dal servizio di rilevamento dell'hotword per ogni risultato negativo dell'hotword.
[9.8/H-1-8] DEVE consentire la trasmissione di dati dal servizio di rilevamento della hotword solo su una richiesta di convalida della hotword dal server di sistema.
[9.8/H-1-9] NON DEVE consentire a un'applicazione installabile dall'utente di fornire il servizio di rilevamento dell'hotword.
[9.8/H-1-10] NON DEVE mostrare nell'interfaccia utente dati quantitativi sull'utilizzo del microfono da parte del servizio di rilevamento dell'hotword.
[9.8/H-1-11] DEVE registrare il numero di byte inclusi in ogni trasmissione dal servizio di rilevamento delle hotword per consentire l'ispezionabilità ai ricercatori di sicurezza.
[9.8/H-1-12] DEVE supportare una modalità di debug che registra i contenuti non elaborati di ogni trasmissione dal servizio di rilevamento dell'hotword per consentire l'ispezionabilità per i ricercatori di sicurezza.
[9.8/H-1-14] DEVE mostrare l'indicatore del microfono, come descritto nella sezione 9.8.2, quando un risultato di hotword riuscito viene trasmesso al servizio di interazione vocale o a un'entità simile.
[9.8/H-1-15] DEVE garantire che i flussi audio forniti in caso di risultati di hotword riusciti vengano trasmessi in una sola direzione dal servizio di rilevamento delle hotword al servizio di interazione vocale.
[9.8/H-SR-1] È FORTEMENTE CONSIGLIATO notificare agli utenti prima di impostare un'applicazione come fornitore del servizio di rilevamento dell'hotword.
[9.8/H-SR-2] È VIVAMENTE CONSIGLIATO di non consentire la trasmissione di dati non strutturati al di fuori del servizio di rilevamento della hotword.
[9.8/H-SR-3] È FORTEMENTE CONSIGLIATO riavviare il processo che ospita il servizio di rilevamento dell'hotword almeno una volta ogni ora o ogni 30 eventi di attivazione hardware, a seconda di quale si verifica per primo.

Se le implementazioni del dispositivo includono un'applicazione che utilizza l'API System HotwordDetectionService o un meccanismo simile per il rilevamento dell'hotword senza indicazione dell'utilizzo del microfono, l'applicazione:

[9.8/H-2-1] DEVE fornire una notifica esplicita all'utente per ogni frase di comando vocale supportata.
[9.8/H-2-2] NON DEVE conservare i dati audio grezzi o i dati derivati da questi tramite il servizio di rilevamento dell'hotword.
[9.8/H-2-3] NON DEVE trasmettere dal servizio di rilevamento dell'hotword, dati audio, dati che possono essere utilizzati per ricostruire (in tutto o in parte) l'audio o contenuti audio non correlati all'hotword stessa, tranne che a ContentCaptureService o al servizio di riconoscimento vocale sul dispositivo.

Se le implementazioni dei dispositivi palmari supportano l'API di sistema VisualQueryDetectionService o un altro meccanismo per il rilevamento delle query senza indicazione di accesso al microfono e/o alla videocamera, devono:

[9.8/H-3-1] DEVE assicurarsi che il servizio di rilevamento delle query possa trasmettere dati solo al sistema, a ContentCaptureService o al servizio di riconoscimento vocale sul dispositivo (creato da SpeechRecognizer#createOnDeviceSpeechRecognizer()).
[9.8/H-3-2] NON DEVE consentire la trasmissione di informazioni audio o video al di fuori del VisualQueryDetectionService, tranne che a ContentCaptureService o al servizio di riconoscimento vocale sul dispositivo.
[9.8/H-3-3] DEVE mostrare un avviso all'utente nella UI di sistema quando il dispositivo rileva l'intenzione dell'utente di interagire con l'applicazione di Assistente digitale (ad esempio rilevando la presenza dell'utente tramite la videocamera).
[9.8/H-3-4] DEVE mostrare un indicatore del microfono e visualizzare la query dell'utente rilevata nell'interfaccia utente subito dopo il rilevamento.
[9.8/H-3-5] NON DEVE consentire a un'applicazione installabile dall'utente di fornire il servizio di rilevamento delle query visive.

Se le implementazioni di dispositivi palmari dichiarano android.hardware.microphone:

[9.8.2/H-4-1] DEVE mostrare l'indicatore del microfono quando un'app accede ai dati audio dal microfono, ma non quando il microfono viene utilizzato solo da HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o da app che hanno i ruoli indicati nella sezione 9.1 con identificatore CDD [C-4-X].
[9.8.2/H-4-2] DEVE mostrare l'elenco delle app recenti e attive che utilizzano il microfono come restituito da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.
[9.8.2/H-4-3] NON DEVE nascondere l'indicatore del microfono per le app di sistema che hanno interfacce utente visibili o interazione utente diretta.
[9.8.2/H-4-4] DEVE mostrare l'elenco delle app recenti e attive che utilizzano il microfono come restituito da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.

Se le implementazioni di dispositivi palmari dichiarano android.hardware.camera.any:

[9.8.2/H-5-1] DEVE mostrare l'indicatore fotocamera quando un'app accede ai dati della fotocamera in diretta, ma non quando la fotocamera viene utilizzata solo da app che detengono i ruoli indicati nella sezione 9.1 con identificatore CDD [C-4-X].
[9.8.2/H-5-2] DEVE mostrare le app recenti e attive che utilizzano la videocamera restituita da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.
[9.8.2/H-5-3] NON DEVE nascondere l'indicatore della fotocamera per le app di sistema con interfacce utente visibili o interazione utente diretta.

Quando un'app non di sistema in primo piano accede alla posizione esatta di un dispositivo, il dispositivo:

[9.8.8/H-6-1] DEVE mostrare un indicatore visibile all'utente.

L'Avvio verificato è una funzionalità che garantisce l'integrità del software del dispositivo. Se le implementazioni dei dispositivi supportano la funzionalità:

[9.10/H-1-1] DEVE verificare tutte le partizioni di sola lettura montate durante la sequenza di avvio di Android e il digest VBMeta deve includere tutte queste partizioni verificate nel calcolo.

2.2.6. Compatibilità di strumenti e opzioni per sviluppatori

Implementazioni di dispositivi palmari (* Non applicabile ai tablet):

[6.1/H-0-1]* DEVE supportare il comando shell cmd testharness.

Implementazioni di dispositivi palmari:

Perfetto
- [6.1/H-0-2] MUST expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.
- [6.1/H-0-3] Il binario perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
- [6.1/H-0-4] Il binario perfetto DEVE scrivere come output una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
- [6.1/H-0-5] DEVE fornire, tramite il binario perfetto, almeno le origini dati descritte nella documentazione di perfetto.
- [6.1/H-0-6] Il daemon di tracciamento Perfetto DEVE essere attivato per impostazione predefinita (proprietà di sistema persist.traced.enable).

Abbiamo apportato modifiche significative alla struttura dei requisiti della classe Rendimento dei contenuti multimediali. A partire dall'API 37, abbiamo aggiunto i nuovi livelli 1, 10, 20 e 37. Abbiamo anche ridotto la complessità dei requisiti facendo riferimento a una pagina con le misurazioni della classe di rendimento dei media, che descrive in dettaglio ogni requisito misurato in base al livello MPC.

2.2.7. Classe di prestazioni multimediali portatili

Per la definizione di classe di rendimento dei media e della definizione di classe di rendimento dei media per tutte le misure, consulta la sezione 7.11.

2.2.7.1. Media

Se le implementazioni dei dispositivi palmari restituiscono un valore diverso da zero per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

DEVE soddisfare tutti i requisiti multimediali elencati nella sezione 2.2.7.1 di Android 17 CDD corrispondente al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-1] DEVE pubblicizzare il numero massimo di sessioni di decodifica video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints() corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-2] DEVE supportare sessioni di decodifica video hardware (AVC, HEVC, VP9, AV1 o versioni successive), istanze simultanee e frame persi corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-3] DEVE pubblicizzare il numero massimo di sessioni di codifica video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints() corrispondenti al livello di classe di rendimento multimediale dichiarato del dispositivo.
[5.1/H-1-4] DEVE supportare sessioni di codifica video hardware (AVC, HEVC, VP9, AV1 o versioni successive), istanze simultanee e frame persi corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-5] DEVE pubblicizzare il numero massimo di sessioni simultanee di codifica e decodifica video hardware in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints() corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-6] DEVE supportare sessioni di decodifica video hardware e codifica video hardware (AVC, HEVC, VP9, AV1 o versioni successive), istanze simultanee e frame persi corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-7] DEVE avere una latenza di inizializzazione del codec per una sessione di codifica video a 1080p o inferiore per tutti i codificatori video hardware quando sono sotto carico corrispondente al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-8] DEVE avere una latenza di inizializzazione del codec per una sessione di codifica audio con bitrate di 128 kbps o inferiore per tutti i codificatori audio in condizioni di carico corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-9] DEVE supportare due istanze di sessioni di decodifica video hardware sicure (AVC, HEVC, VP9, AV1 o versioni successive) e frame persi corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-10] DEVE supportare 3 istanze di sessioni di decodifica video hardware non sicure insieme a 1 istanza di sessione di decodifica video hardware sicura (4 istanze in totale) (AVC, HEVC, VP9, AV1 o versioni successive), risoluzioni e frame persi corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-11] DEVE supportare un decoder sicuro per ogni decoder hardware AVC, HEVC, VP9 o AV1 corrispondente al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-12] DEVE avere una latenza di inizializzazione del codec per una sessione di decodifica video a 1080p o inferiore per tutti i decoder video hardware quando è sotto carico corrispondente al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-13] DEVE avere una latenza di inizializzazione del codec per una sessione di decodifica audio a 128 kbps o bitrate inferiore per tutti i decoder audio in condizioni di carico corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-14] DEVE supportare il profilo, la funzionalità e il metodo di visualizzazione del decoder hardware AV1 corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-15] DEVE avere almeno un decoder video hardware che supporti 4K60 corrispondente al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-16] DEVE avere almeno un codificatore video hardware che supporti 4K60 corrispondente al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-17] DEVE avere almeno un decodificatore di immagini hardware che supporti il profilo di baseline AVIF corrispondente al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-18] DEVE supportare il codificatore AV1 che soddisfi i requisiti di bitrate, frame al secondo e risoluzione corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-19] DEVE supportare 3 istanze di decodificatore video hardware a 10 bit (HDR) e sessioni di codificatore video hardware (AVC, HEVC, VP9, AV1 o versioni successive), risoluzione e perdita di frame corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-20] DEVE supportare la funzionalità Feature_HdrEditing per tutti i codificatori hardware AV1 e HEVC presenti sul dispositivo corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-21] DEVE supportare FEATURE_DynamicColorAspect per tutti i decoder video hardware (AVC, HEVC, VP9, AV1 o versioni successive) corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.1/H-1-22] DEVE supportare la codifica, la decodifica, la modifica con GPU e la visualizzazione di contenuti video con proporzioni verticali corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.2/H-2-1] Se l'implementazione del dispositivo supporta i codificatori hardware AVC o HEVC, DEVE soddisfare il target di qualità minimo definito dalle curve di distorsione della velocità del codificatore video per questi codec, corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.

[5.2/H-2-2] DEVE supportare MMAP nel percorso dell'altoparlante corrispondente al livello di classe di prestazioni multimediali dichiarato del dispositivo.

[5.3/H-1-1] DEVE soddisfare i requisiti di prestazioni della sessione video e di perdita di frame corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.3/H-1-2] DEVE soddisfare i requisiti di rendimento per la modifica della risoluzione video corrispondenti al livello di classe di rendimento dei contenuti multimediali dichiarato del dispositivo.
[5.6/H-1-1] DEVE soddisfare i requisiti di latenza del tocco per il tono corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.6/H-1-2] DEVE soddisfare i requisiti di latenza audio di andata e ritorno corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.6/H-1-3] DEVE soddisfare i requisiti audio a 24 bit corrispondenti al livello della classe di rendimento multimediale dichiarato del dispositivo.
[5.6/H-1-4] DEVE supportare dispositivi audio USB con almeno 4 canali corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.6/H-1-5] DEVE supportare i dispositivi MIDI conformi alla classe e dichiarare il flag di funzionalità MIDI corrispondente al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.6/H-1-9] DEVE supportare almeno 12 canali di mixaggio corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.

[5.6/H-3-1] DEVE essere in grado di gestire il passaggio dalla riproduzione di onde sinusoidali senza sottoproduzione di buffer audio corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.6/H-3-2] DEVE soddisfare i requisiti del canale di output del dispositivo audio USB corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.6/H-3-3] DEVE soddisfare i requisiti del canale di input del dispositivo audio USB corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.

[5.6/H-SR-1] Sono FORTEMENTE CONSIGLIATI per supportare il mixaggio dei canali audio corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.7/H-1-2] DEVE supportare MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL con le funzionalità di decrittografia corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[5.12/H-1-2] DEVE soddisfare i requisiti di formato colore per i codificatori hardware AV1 e HEVC corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[5.12/H-1-3] DEVE pubblicizzare il supporto dell'estensione EXT_YUV_target corrispondente al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[7.1.4/H-1-1] DEVE soddisfare i requisiti dell'unità di elaborazione del display (DPU) corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.

2.2.7.2. Fotocamera

Se le implementazioni dei dispositivi palmari restituiscono un valore diverso da zero per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, questi:

DEVE soddisfare i requisiti della fotocamera elencati nella sezione 2.2.7.2 di Android 17 CDD corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.

Se le implementazioni dei dispositivi palmari restituiscono un valore diverso da zero per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, questi:

[7.5/H-1-1] DEVE soddisfare i requisiti di risoluzione e acquisizione video della fotocamera posteriore principale corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-2] DEVE soddisfare i requisiti principali di risoluzione della fotocamera anteriore e di acquisizione video corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-3] DEVE supportare i requisiti della proprietà android.info.supportedHardwareLevel corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-4] DEVE supportare CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME per entrambe le videocamere principali corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-5] DEVE soddisfare i requisiti di latenza di acquisizione JPEG di camera2 corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-6] DEVE soddisfare i requisiti di latenza di avvio di camera2 corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-8] DEVE soddisfare i requisiti di acquisizione della fotocamera RAW corrispondenti al livello di classe di rendimento multimediale dichiarato del dispositivo.
[7.5/H-1-9] DEVE soddisfare i requisiti di acquisizione video ad alta velocità della fotocamera principale posteriore corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-10] DEVE soddisfare i requisiti minimi del rapporto di zoom corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-11] DEVE implementare lo streaming simultaneo anteriore-posteriore sulle videocamere principali corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-12] DEVE supportare la stabilizzazione video per la fotocamera posteriore principale corrispondente al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-13] DEVE supportare la funzionalità LOGICAL_MULTI_CAMERA per la fotocamera posteriore principale corrispondente al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-14] DEVE supportare la funzionalità STREAM_USE_CASE per la fotocamera anteriore principale e quella posteriore principale corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-15] DEVE supportare le estensioni della modalità Notte tramite le estensioni CameraX e Camera2 per le fotocamere principali corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-16] DEVE supportare la funzionalità DYNAMIC_RANGE_TEN_BIT per le fotocamere principali corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-17] DEVE supportare le funzionalità di rilevamento del volto per le fotocamere principali corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-18] DEVE supportare JPEG_R per le fotocamere posteriori e anteriori principali corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-19] DEVE supportare CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION per la fotocamera posteriore principale corrispondente al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.5/H-1-20] DEVE per impostazione predefinita restituire JPEG_R per le fotocamere posteriore principale e anteriore principale nell'app fotocamera nativa corrispondente al livello di classe di prestazioni multimediali dichiarato del dispositivo.

[7.5/H-1-21] DEVE avere almeno una fotocamera anteriore o posteriore corrispondente al livello di classe di prestazioni multimediali dichiarato del dispositivo.

2.2.7.3. Hardware

Se le implementazioni dei dispositivi palmari restituiscono un valore diverso da zero per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

DEVE soddisfare i requisiti hardware elencati nella sezione 2.2.7.3 del CDD di Android 17 corrispondente al livello della classe di prestazioni multimediali dichiarato del dispositivo.

Se le implementazioni dei dispositivi palmari restituiscono un valore diverso da zero per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

[7.1.1.1/H-1-1] Questo elemento viene intenzionalmente ignorato.
[7.1.1.1/H-2-1] DEVE avere una risoluzione dello schermo corrispondente al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[7.1.1.3/H-1-1] Questo elemento viene intenzionalmente ignorato.
[7.1.1.3/H-2-1] DEVE avere una densità dello schermo corrispondente al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.1.1.3/H-3-1] DEVE supportare i requisiti di visualizzazione HDR corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.6.1/H-1-1] Questo elemento viene intenzionalmente ignorato.
[7.6.1/H-2-1] DEVE soddisfare i requisiti di memoria corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.

2.2.7.4. Rendimento

Se le implementazioni dei dispositivi palmari restituiscono un valore diverso da zero per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, questi:

DEVE soddisfare i requisiti di prestazioni elencati nella sezione 2.2.7.4 del CDD di Android 17 corrispondente al livello di classe di prestazioni multimediali dichiarato del dispositivo.

Se le implementazioni dei dispositivi palmari restituiscono un valore diverso da zero per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, questi:

[8.2/H-1-1] DEVE garantire prestazioni di scrittura sequenziale corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[8.2/H-1-2] DEVE garantire prestazioni di scrittura casuale corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[8.2/H-1-3] DEVE garantire prestazioni di lettura sequenziale corrispondenti al livello della classe di prestazioni multimediali dichiarato del dispositivo.
[8.2/H-1-4] DEVE garantire prestazioni di lettura casuale corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[8.2/H-1-5] DEVE garantire prestazioni di lettura e scrittura sequenziali parallele corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.

2.2.7.5. Grafica

Se le implementazioni dei dispositivi palmari restituiscono un valore diverso da zero per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

[7.1.4.1/H-1-2] DEVE supportare le estensioni EGL richieste corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.
[7.1.4.1/H-1-3] DEVE supportare le funzionalità Vulkan richieste corrispondenti al livello di classe di prestazioni multimediali dichiarato del dispositivo.

2.3. Requisiti della TV

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

Le implementazioni di dispositivi Android sono classificate come televisioni se soddisfano tutti i seguenti criteri:

Hanno 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 lunghezza diagonale superiore a 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 di dispositivi Android TV.

2.3.1. Hardware

Implementazioni di dispositivi TV:

[7.2.2/T-0-1] DEVE supportare il D-pad.
[7.2.3/T-0-1] DEVE fornire le funzioni Home e Indietro.
[7.2.3/T-0-2] DEVE inviare sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano.
[7.2.6.1/T-0-1] DEVE includere il supporto per i controller di gioco e dichiarare il flag di funzionalità android.hardware.gamepad.
[7.2.7/T] DOVREBBE fornire un telecomando da cui gli utenti possono accedere alla navigazione non touch e agli input dei tasti di navigazione principali.

Se le implementazioni dei dispositivi televisivi includono un giroscopio a 3 assi:

[7.3.4/T-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 100 Hz.
[7.3.4/T-1-2] DEVE essere in grado di misurare i cambiamenti di orientamento fino a 1000 gradi al secondo.

Implementazioni di dispositivi TV:

[7.4.3/T-0-1] DEVE supportare Bluetooth e Bluetooth LE.
[7.6.1/T-0-1] DEVE avere almeno 4 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione (ovvero la partizione "/data").

Se le implementazioni dei dispositivi televisivi includono una porta USB che supporta la modalità host, questi:

[7.5.3/T-1-1] DEVE includere il supporto per una videocamera esterna che si connette tramite questa porta USB, ma non è necessariamente sempre connessa.

Se le implementazioni dei dispositivi TV sono a 32 bit:

[7.6.1/T-1-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 896 MB se viene utilizzata una delle seguenti densità:
- 400 dpi o superiore su schermi piccoli/normali
- xhdpi o superiore su schermi di grandi dimensioni
- tvdpi o superiore su schermi molto grandi

Se le implementazioni dei dispositivi TV sono a 64 bit:

[7.6.1/T-2-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1280 MB se viene utilizzata una delle seguenti densità:
- 400 dpi o superiore su schermi piccoli/normali
- xhdpi o superiore su schermi di grandi dimensioni
- tvdpi o superiore su schermi molto grandi

Implementazioni di dispositivi TV:

[7.8.1/T] DEVE includere un microfono.
[7.8.2/T-0-1] DEVE avere un'uscita audio e dichiarare android.hardware.audio.output.

2.3.2. Multimediali

Le implementazioni dei dispositivi televisivi DEVONO supportare i seguenti formati di codifica e decodifica audio e renderli disponibili per le applicazioni di terze parti:

[5.1/T-0-1] Profilo MPEG-4 AAC (AAC LC)
[5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
[5.1/T-0-3] AAC ELD (enhanced low delay AAC)

[5.1/T-0-4] MPEG-D USAC con MPEG-D DRC (Extended High Efficiency AAC)

Le implementazioni dei dispositivi televisivi DEVONO supportare i seguenti formati di codifica video e renderli disponibili per le applicazioni di terze parti:

[5.2/T-0-1] H.264
[5.2/T-0-2] VP8
[5.2/T-0-3] AV1

Implementazioni di dispositivi TV:

[5.2.2/T-SR-1] È FORTEMENTE CONSIGLIATO supportare la codifica H.264 di video con risoluzione 720p e 1080p a 30 fotogrammi al secondo.

Le implementazioni dei dispositivi televisivi DEVONO supportare i seguenti formati di decodifica video e renderli disponibili per le applicazioni di terze parti:

[5.3.3/T-0-1] MPEG-4 SP
[5.3.4/T-0-2] H.264 AVC
[5.3.5/T-0-3] H.265 HEVC
[5.3.6/T-0-4] VP8
[5.3.7/T-0-5] VP9
[5.3.1/T-0-6] MPEG-2
[5.3.2/T-0-7] AV1

Le implementazioni dei dispositivi televisivi DEVONO supportare la decodifica MPEG-2, come descritto nella Sezione 5.3.1, a frame rate e risoluzioni video standard fino a e inclusi:

[5.3.1/T-1-1] HD 1080p a 29,97 fotogrammi al secondo con Main Profile High Level.
[5.3.1/T-1-2] HD 1080i a 59,94 fotogrammi al secondo con Main Profile High Level. Devono deinterlacciare il video MPEG-2 interlacciato e renderlo disponibile per applicazioni di terze parti.

Le implementazioni dei dispositivi televisivi DEVONO supportare la decodifica H.264, come descritto nella sezione 5.3.4, a frame rate e risoluzioni video standard fino a e inclusi:

[5.3.4/T-1-1] HD 1080p a 60 frame al secondo con profilo di baseline
[5.3.4/T-1-2] HD 1080p a 60 fotogrammi al secondo con Main Profile
[5.3.4/T-1-3] HD 1080p a 60 frame al secondo con High Profile Level 4.2

Le implementazioni di dispositivi televisivi con decoder hardware H.265 DEVONO supportare la decodifica H.265, come descritto nella sezione 5.3.5, a frame rate video standard e risoluzioni fino a:

[5.3.5/T-1-1] HD 1080p a 60 fotogrammi al secondo con Main Profile Level 4.1

Se le implementazioni di dispositivi televisivi con decoder hardware H.265 supportano la decodifica H.265 e il profilo di decodifica UHD:

[5.3.5/T-2-1] DEVE supportare il profilo di decodifica UHD a 60 fotogrammi al secondo con il profilo Main10 Level 5 Main Tier

Le implementazioni dei dispositivi televisivi DEVONO supportare la decodifica VP8, come descritto nella Sezione 5.3.6, a frequenze fotogrammi video standard e risoluzioni fino a e inclusi:

[5.3.6/T-1-1] Profilo di decodifica HD 1080p a 60 frame al secondo

Le implementazioni di dispositivi televisivi con decoder hardware VP9 DEVONO supportare la decodifica VP9, come descritto nella sezione 5.3.7, a frame rate video standard e risoluzioni fino a:

[5.3.7/T-1-1] HD 1080p a 60 fotogrammi al secondo con profilo 0 (profondità colore a 8 bit)

Se le implementazioni di dispositivi televisivi con decoder hardware VP9 supportano la decodifica VP9 e il profilo di decodifica UHD:

[5.3.7/T-2-1] DEVE supportare il profilo di decodifica UHD a 60 frame al secondo con il profilo 0 (profondità del colore a 8 bit).
[5.3.7/T-SR1] Sono FORTEMENTE CONSIGLIATI per supportare il profilo di decodifica UHD a 60 fotogrammi al secondo con il profilo 2 (profondità di colore a 10 bit).

Implementazioni di dispositivi TV:

[5.5/T-0-1] DEVE includere il supporto per il volume principale del sistema e l'attenuazione del volume dell'output audio digitale sugli output supportati, ad eccezione dell'output passthrough audio compresso (in cui non viene eseguita la decodifica audio sul dispositivo).

Se le implementazioni dei dispositivi televisivi non hanno un display integrato, ma supportano un display esterno collegato tramite HDMI:

[5.8/T-0-1] DEVE impostare la modalità di uscita HDMI sulla risoluzione più alta per il formato pixel scelto che funziona con una frequenza di aggiornamento di 50 Hz o 60 Hz per il display esterno, a seconda della frequenza di aggiornamento video per la regione in cui viene venduto il dispositivo.
[5.8/T-SR-1] È VIVAMENTE CONSIGLIATO fornire un selettore della frequenza di aggiornamento HDMI configurabile dall'utente.
[5.8] DEVE impostare la frequenza di aggiornamento della modalità di uscita HDMI su 50 Hz o 60 Hz, a seconda della frequenza di aggiornamento video per la regione in cui viene venduto il dispositivo.

Se le implementazioni dei dispositivi televisivi non hanno un display integrato, ma supportano un display esterno collegato tramite HDMI:

[5.8/T-1-1] MUST support HDCP 2.2.

Se le implementazioni dei dispositivi televisivi non supportano la decodifica UHD, ma supportano invece un display esterno collegato tramite HDMI:

[5.8/T-2-1] MUST support HDCP 1.4

2.3.3. Software

Implementazioni di dispositivi TV:

[3/T-0-1] DEVE dichiarare le funzionalità android.software.leanback e android.hardware.type.television.
[3.2.3.1/T-0-1] DEVE precaricare uno o più componenti di applicazioni o servizi con un gestore di intent, per tutti i pattern di filtri per intent pubblici definiti dai seguenti intent di applicazioni elencati qui.
[3.4.1/T-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.

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

[3.8.10/T-1-1] DEVE visualizzare le notifiche della schermata di blocco, incluso il modello di notifica multimediale.

Implementazioni di dispositivi TV:

[3.8.14/T-SR-1] Sono FORTEMENTE CONSIGLIATE per supportare la modalità multi-finestra Picture in Picture (PIP).
[3.10/T-0-1] DEVE supportare i servizi di accessibilità di terze parti.
[3.10/T-SR-1] È FORTEMENTE CONSIGLIATO di precaricare sul dispositivo servizi di accessibilità paragonabili o superiori per funzionalità a Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato) come forniti nel progetto open source TalkBack.

Se le implementazioni dei dispositivi televisivi segnalano la funzionalità android.hardware.audio.output,

[3.11/T-SR-1] È FORTEMENTE CONSIGLIATO includere un motore TTS che supporti le lingue disponibili sul dispositivo.
[3.11/T-1-1] DEVE supportare l'installazione di motori TTS di terze parti.

L'Android Television Input Framework (TIF) semplifica la distribuzione di contenuti live ai dispositivi Android TV. TIF fornisce un'API standard per creare moduli di input che controllano i dispositivi Android TV.

Implementazioni di dispositivi TV:

[3/T-0-2] DEVE dichiarare la funzionalità della piattaforma android.software.live_tv.
[3/T-0-3] DEVE supportare tutte le API TIF in modo che un'applicazione che utilizza queste API e il servizio di input basati su TIF di terze parti possa essere installata e utilizzata sul dispositivo.

Il framework del sintonizzatore televisivo Android (TF) unifica la gestione dei contenuti live del sintonizzatore con i contenuti in streaming da IP sui dispositivi Android TV. Tuner Framework fornisce un'API standard per creare servizi di input che utilizzano il sintonizzatore TV Android.

Se le implementazioni dei dispositivi supportano Tuner:

[3/T-1-1] DEVE supportare tutte le API Tuner Framework in modo che un'applicazione che le utilizza possa essere installata e usata sul dispositivo.

2.3.4. Prestazioni e potenza

[8.1/T-0-1] Latenza dei frame coerente. La latenza dei frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più di 5 frame al secondo e DOVREBBE essere inferiore a 1 frame al secondo.
[8.2/T-0-1] DEVE garantire una prestazione di scrittura sequenziale di almeno 5 MB/s.
[8.2/T-0-2] DEVE garantire una velocità di scrittura casuale di almeno 0,5 MB/s.
[8.2/T-0-3] DEVE garantire una velocità di lettura sequenziale di almeno 15 MB/s.
[8.2/T-0-4] DEVE garantire una velocità di lettura casuale di almeno 3,5 MB/s.

Se le implementazioni dei dispositivi televisivi includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP:

[8.3/T-1-1] DEVE fornire all'utente la possibilità di attivare e disattivare la funzionalità di risparmio energetico.

Se le implementazioni dei dispositivi televisivi non hanno una batteria:

[8.3/T-1-2] DEVE registrare il dispositivo come dispositivo senza batteria, come descritto in Supporto dei dispositivi senza batteria.

Se le implementazioni dei dispositivi televisivi hanno una batteria:

[8.3/T-1-3] DEVE fornire all'utente la possibilità di visualizzare tutte le app esentate dalle modalità di risparmio energetico Standby delle app e Sospensione.

Implementazioni di dispositivi TV:

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

2.3.5. Modello di sicurezza

Implementazioni di dispositivi TV:

[9/T-0-1] DEVE dichiarare la funzionalità android.hardware.security.model.compatible.

Se le implementazioni dei dispositivi televisivi includono un'applicazione predefinita per supportare VoiceInteractionService:

[9.1/T-0-1] NON DEVE concedere ACCESS_FINE_LOCATION come predefinito per l'applicazione.

Implementazioni di dispositivi TV:

[9.11/T-0-1] MUST back up the keystore implementation with an isolated execution environment.
[9.11/T-0-2] DEVE avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e delle funzioni hash MD5, SHA-1 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 versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi con cui il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto Android Open Source Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti di un isolamento basato su hypervisor adeguato sono opzioni alternative.
[9.11/T-0-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate 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 open source Android fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
[9.11/T-0-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 NON DEVONO essere utilizzate come identificatori permanenti del dispositivo.

Nota :per soddisfare questo requisito, devi condividere la stessa chiave di attestazione per un determinato SKU,a meno che non vengano prodotte almeno 100.000 unità di questo SKU. Se vengono prodotte più di 100.000 unità di questo SKU, DOPO questa quantità POTREBBE essere utilizzata una chiave diversa per ogni gruppo di 100.000 unità. In alternativa, è possibile utilizzare la soluzione di provisioning delle chiavi remoto per eseguire il provisioning delle chiavi di attestazione di breve durata sul dispositivo.

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

[9.11/T-1-1] DEVE consentire all'utente di scegliere il timeout di sospensione per la transizione dallo stato sbloccato a quello bloccato, con un timeout minimo consentito fino a 15 secondi o meno.

Se le implementazioni dei dispositivi televisivi includono più utenti e non dichiarano il flag di funzionalità android.hardware.telephony:

[9.5/T-2-1] DEVE supportare i profili con limitazioni, una funzionalità che consente ai proprietari del dispositivo di gestire altri utenti e le loro funzionalità sul dispositivo. Con i profili con limitazioni, i proprietari dei dispositivi possono configurare rapidamente ambienti separati in cui far lavorare altri utenti, con la possibilità di gestire limitazioni più granulari nelle app disponibili in questi ambienti.

Se le implementazioni dei dispositivi televisivi includono più utenti e dichiarano il flag di funzionalità android.hardware.telephony:

[9.5/T-3-1] NON DEVE supportare i profili con limitazioni, ma DEVE essere in linea con l'implementazione AOSP dei controlli per consentire /disattivare l'accesso di altri utenti alle chiamate vocali e agli SMS.

Se le implementazioni dei dispositivi televisivi dichiarano android.hardware.microphone:

[9.8.2/T-4-1] DEVE mostrare l'indicatore del microfono quando un'app accede ai dati audio dal microfono, ma non quando il microfono viene utilizzato solo da HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o da app che detengono i ruoli indicati nella sezione 9.1 Autorizzazioni con identificatore CDD C-3-X.
[9.8.2/T-4-2] NON DEVE nascondere l'indicatore del microfono per le app di sistema che hanno interfacce utente visibili o interazione diretta con l'utente.

Se le implementazioni dei dispositivi televisivi dichiarano android.hardware.camera.any:

[9.8.2/T-5-1] DEVE mostrare l'indicatore fotocamera quando un'app accede ai dati della fotocamera in diretta, ma non quando la fotocamera viene utilizzata solo da app che detengono i ruoli indicati nella sezione 9.1 Autorizzazioni con identificatore CDD [C-3-X].
[9.8.2/T-5-2] NON DEVE nascondere l'indicatore fotocamera per le app di sistema con interfacce utente visibili o interazione utente diretta.

2.3.6. Compatibilità di strumenti e opzioni per sviluppatori

Implementazioni di dispositivi TV:

Perfetto
- [6.1/T-0-1] DEVE esporre un binario /system/bin/perfetto all'utente della shell la cui riga di comando è conforme alla documentazione di Perfetto.
- [6.1/T-0-2] Il binario perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
- [6.1/T-0-3] Il binario perfetto DEVE scrivere come output una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
- [6.1/T-0-4] DEVE fornire, tramite il binario perfetto, almeno le origini dati descritte nella documentazione di perfetto.
- [6.1/T-0-5] Il daemon di tracciamento perfetto DEVE essere attivato per impostazione predefinita (proprietà di sistema persist.traced.enable).

2.4. Requisiti dell'orologio

Un dispositivo Android Watch si riferisce a un'implementazione di un dispositivo Android destinato a essere indossato sul corpo, ad esempio sul polso.

Le implementazioni di dispositivi Android sono classificate come orologi se soddisfano tutti i criteri seguenti:

Avere uno schermo con lunghezza diagonale fisica compresa tra 2,8 e 6,3 cm.
Avere un meccanismo da indossare sul corpo.

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

2.4.1. Hardware

Guarda le implementazioni dei dispositivi:

[7.1.1.1/W-0-1] DEVE avere uno schermo con dimensioni diagonali fisiche comprese tra 1,1 e 2,5 pollici.
[7.2.3/W-0-1] DEVE avere a disposizione dell'utente la funzione Home e la funzione Indietro, tranne quando si trova in UI_MODE_TYPE_WATCH.
[7.2.4/W-0-1] DEVE supportare l'input tramite touchscreen.
[7.3.1/W-SR-1] È FORTEMENTE CONSIGLIATO includere un accelerometro a 3 assi.

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

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

Se le implementazioni del dispositivo Watch includono un giroscopio a 3 assi:

[7.3.4/W-2-1] DEVE essere in grado di misurare i cambiamenti di orientamento fino a 1000 gradi al secondo.

Se le implementazioni dei dispositivi di orologio supportano la connettività dati cellulare:

[7.4.1/W-1-1] DEVE dichiarare la funzionalità android.hardware.telephony.data.

Guarda le implementazioni dei dispositivi:

[7.4.3/W-0-1] DEVE supportare il Bluetooth.
[7.6.1/W-0-1] DEVE avere almeno 1 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione (ovvero la partizione "/data").
[7.6.1/W-0-2] DEVE avere almeno 416 MB di memoria disponibile per il kernel e lo spazio utente.
[7.8.1/W-0-1] DEVE includere un microfono.
[7.8.2/W] POTREBBE avere un'uscita audio.

2.4.2. Multimediali

Nessun altro requisito.

2.4.3. Software

Guarda le implementazioni dei dispositivi:

[3/W-0-1] DEVE dichiarare la funzionalità android.hardware.type.watch.
[3/W-0-2] DEVE supportare uiMode = UI_MODE_TYPE_WATCH.
[3.2.3.1/W-0-1] DEVE precaricare una o più applicazioni o componenti di servizio con un gestore di intent, per tutti i pattern di filtri per intent pubblici definiti dai seguenti intent dell'applicazione elencati qui.

Guarda le implementazioni dei dispositivi:

[3.8.4/W-SR-1] È VIVAMENTE CONSIGLIATO di implementare un assistente sul dispositivo per gestire l'azione Assist.

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

[3.10/W-1-1] DEVE supportare i servizi di accessibilità di terze parti.
[3.10/W-SR-1] È FORTEMENTE CONSIGLIATO precaricare servizi di accessibilità sul dispositivo con funzionalità paragonabili o superiori a quelle di Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato) come forniti nel progetto open source TalkBack.

Se le implementazioni dei dispositivi orologio segnalano la funzionalità android.hardware.audio.output, devono:

[3.11/W-SR-1] È FORTEMENTE CONSIGLIATO includere un motore TTS che supporti le lingue disponibili sul dispositivo.
[3.11/W-0-1] DEVE supportare l'installazione di motori TTS di terze parti.

2.4.4. Prestazioni e potenza

Se le implementazioni dei dispositivi Watch includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP:

[8.3/W-SR-1] È FORTEMENTE CONSIGLIATO fornire agli utenti la possibilità di visualizzare tutte le app esenti dalle modalità di risparmio energetico Standby delle app e Sospensione.
[8.3/W-SR-2] Sono FORTEMENTE CONSIGLIATI per fornire all'utente la possibilità di attivare e disattivare la funzionalità di risparmio energetico.

Guarda le implementazioni dei dispositivi:

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

2.4.5. Modello di sicurezza

Guarda le implementazioni dei dispositivi:

[9/W-0-1] DEVE dichiarare la funzionalità android.hardware.security.model.compatible.

Se le implementazioni del dispositivo Watch includono un'applicazione predefinita per supportare VoiceInteractionService:

[9.1/W-0-1] NON DEVE concedere ACCESS_FINE_LOCATION come predefinito per l'applicazione.

Se le implementazioni del dispositivo Watch includono più utenti e non dichiarano il flag di funzionalità android.hardware.telephony:

[9.5/W-1-1] DEVE supportare i profili con limitazioni, una funzionalità che consente ai proprietari del dispositivo di gestire altri utenti e le loro funzionalità sul dispositivo. Con i profili con limitazioni, i proprietari dei dispositivi possono configurare rapidamente ambienti separati in cui far lavorare altri utenti, con la possibilità di gestire limitazioni più granulari nelle app disponibili in questi ambienti.

Se le implementazioni dei dispositivi Wear includono più utenti e dichiarano il flag di funzionalità android.hardware.telephony:

[9.5/W-2-1] NON DEVE supportare i profili con limitazioni, ma DEVE essere in linea con l'implementazione AOSP dei controlli per consentire /disattivare l'accesso di altri utenti alle chiamate vocali e agli SMS.

Se le implementazioni del dispositivo hanno una schermata di blocco sicura e includono uno o più agenti di attendibilità, che implementano l'API TrustAgentServiceSystem,

[9.11.1/W-1-1] DEVE richiedere all'utente uno dei metodi di autenticazione principali consigliati (ad esempio PIN, sequenza o password) più frequentemente di una volta ogni 72 ore almeno ogni 336 ore (14 giorni) .

Se le implementazioni del dispositivo hanno una schermata di blocco sicura e includono uno o più agenti di attendibilità, che chiamano l'API di sistema TrustAgentService.grantTrust() con il flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, questi:

[9.11.1/W-2-1] DEVE soddisfare le seguenti condizioni per chiamare grantTrust() con questo flag:
- Il dispositivo è connesso a un dispositivo portatile principale fisico nelle vicinanze con una schermata di blocco propria e
- L'utente ha autenticato la propria identità rispetto a quella schermata di blocco o alla biometria di Classe 3 negli ultimi 30 secondi.
[9.11.1/W-2-2] DEVE impostare lo stato del dispositivo su TrustState.TRUSTABLE quando il dispositivo indossabile viene rimosso dal polso o dal corpo e TrustAgent non ha revocato l'attendibilità.

2.5. Requisiti per il settore automobilistico

L'implementazione di Android Automotive si riferisce a un'unità principale del veicolo che esegue Android come sistema operativo per parte o per l'intero sistema e/o funzionalità di infotainment.

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

Sono incorporati o collegabili a un veicolo.
Utilizzi uno schermo nella fila del sedile del conducente come display principale.

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

2.5.1. Hardware

Implementazioni di dispositivi per il settore automotive:

[7.1.1.1/A-0-1] DEVE avere uno schermo di almeno 6 pollici di dimensione diagonale fisica.
[7.1.1.1/A-0-2] DEVE avere un layout delle dimensioni dello schermo di almeno 750 dp x 480 dp.
[7.1.1.1/A-0-3] DEVE supportare la composizione della GPU di buffer grafici almeno grandi quanto la risoluzione più alta di qualsiasi display integrato.

Se le implementazioni dei dispositivi per il settore automobilistico supportano la funzionalità multiutente simultanea (in cui più utenti Android possono interagire con il dispositivo contemporaneamente, ognuno utilizzando il proprio display quando config_multiuserVisibleBackgroundUsers è attivata),:

[7.1.1.1/A-1-1] DEVE avere uno schermo separato di almeno 6 pollici di dimensione diagonale fisica per ogni zona dell'abitacolo per il display principale. Questo deve essere taggato come CarOccupantZoneManager.DISPLAY_TYPE_MAIN per ogni zona occupata.
[7.1.1.1/A-1-2] DEVE avere un layout delle dimensioni dello schermo di almeno 750 dp x 480 dp per ogni display principale.

Se le implementazioni dei dispositivi per il settore automobilistico supportano OpenGL ES 3.1:

[7.1.4.1/A-0-1] DEVE dichiarare OpenGL ES 3.1 o versioni successive.
[7.1.4.1/A-0-2] DEVE supportare Vulkan 1.1.
[7.1.4.1/A-0-3] DEVE includere il caricatore Vulkan ed esportare tutti i simboli.

Se le implementazioni dei dispositivi per il settore automobilistico includono il supporto di Vulkan:

[7.1.4.2/A-1-1] DEVE soddisfare i requisiti specificati dal profilo Android Baseline 2021.

Se le implementazioni di dispositivi per il settore automobilistico dichiarano di supportare display High Dynamic Range tramite Configuration.isScreenHdr(), devono:

[7.1.4.5/A-1-1] DEVE pubblicizzare il supporto per le estensioni EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace, e VK_EXT_hdr_metadata.

Implementazioni di dispositivi per il settore automotive:

[7.1.4.6/A-0-1] DEVE segnalare se il dispositivo supporta la funzionalità di profilazione della GPU tramite una proprietà di sistema graphics.gpu.profiler.support.

Se le implementazioni dei dispositivi per il settore automobilistico dichiarano il supporto tramite una proprietà di sistema graphics.gpu.profiler.support:

[7.1.4.6/A-1-1] DEVE segnalare come output una traccia protobuf conforme allo schema per i contatori GPU e le fasi di rendering della GPU definiti nella documentazione di Perfetto.
[7.1.4.6/A-1-2] DEVE segnalare valori conformi per i contatori GPU del dispositivo seguendo il proto del pacchetto gpu counter trace.
[7.1.4.6/A-1-3] DEVE segnalare valori conformi per le fasi di rendering della GPU del dispositivo seguendo il proto del pacchetto di traccia della fase di rendering.
[7.1.4.6/A-1-4] DEVE segnalare un punto di traccia della frequenza della GPU come specificato dal formato: power/gpu_frequency.

Implementazioni di dispositivi per il settore automotive:

[7.1.5/A-0-1] DEVE includere il supporto per la modalità di compatibilità delle app legacy implementata dal codice open source Android upstream. ovvero le implementazioni dei dispositivi NON DEVONO alterare i trigger o le soglie in corrispondenza delle quali viene attivata la modalità di compatibilità e NON DEVONO alterare il comportamento della modalità di compatibilità stessa.

Implementazioni di dispositivi per il settore automotive:

[7.1.7/A-0-1] DEVE configurare i display secondari nel campo visivo del conducente come FLAG_PRIVATE.
[7.2.3/A-0-1] DEVE fornire la funzione Home e PUÒ fornire le funzioni Indietro e Recenti.
[7.2.3/A-0-2] DEVE inviare sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano.
[7.3/A-0-1] DEVE implementare e segnalare GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED e PARKING_BRAKE_ON.
[7.3/A-0-2] Il valore del flag NIGHT_MODE DEVE essere coerente con la modalità giorno/notte del cruscotto e DOVREBBE basarsi sull'input del sensore della luce ambientale. Il sensore della luce ambientale sottostante POTREBBE essere lo stesso del fotometro.
[7.3/A-0-3] DEVE fornire il campo delle informazioni aggiuntive del sensore TYPE_SENSOR_PLACEMENT come parte di SensorAdditionalInfo per ogni sensore fornito.
[7.3/A-SR1] MAY dead reckon Location by fusing GPS/GNSS with additional sensors. Se la posizione è stimata, è VIVAMENTE CONSIGLIATO implementare e segnalare i tipi di sensore e/o gli ID proprietà veicolo corrispondenti utilizzati.
[7.3/A-0-4] La posizione richiesta tramite LocationManager#requestLocationUpdates() NON DEVE essere associata alla mappa.
[7.3.1/A-0-4] DEVE essere conforme al sistema di coordinate del sensore dell'auto di Android.
[7.3/A-SR-1] È VIVAMENTE CONSIGLIATO includere un accelerometro a 3 assi e un giroscopio a 3 assi.
[7.3/A-SR-2] È FORTEMENTE CONSIGLIATO implementare e segnalare il sensore TYPE_HEADING.

[7.3/A-1-1] DEVE impostare il valore del flag NIGHT_MODE in modo coerente con la modalità giorno/notte del cruscotto su tutti i display, inclusi quelli dei sedili posteriori.

Se le implementazioni di dispositivi per il settore automobilistico includono un accelerometro:

[7.3.1/A-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 100 Hz.

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

[7.3.1/A-SR-1] È FORTEMENTE CONSIGLIATO di implementare il sensore composito per l'accelerometro con assi limitati.

Se le implementazioni dei dispositivi per il settore automobilistico includono un accelerometro con meno di 3 assi:

[7.3.1/A-1-3] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER_LIMITED_AXES.
[7.3.1/A-1-4] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Se le implementazioni dei dispositivi per il settore automobilistico includono un giroscopio:

[7.3.4/A-2-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 100 Hz.
[7.3.4/A-2-3] DEVE essere in grado di misurare i cambiamenti di orientamento fino a 250 gradi al secondo.
[7.3.4/A-SR-1] È VIVAMENTE CONSIGLIATO configurare l'intervallo di misurazione del giroscopio su +/-250 dps per massimizzare la risoluzione possibile.

Se le implementazioni dei dispositivi per il settore automobilistico includono un giroscopio a 3 assi:

[7.3.4/A-SR-2] È FORTEMENTE CONSIGLIATO di implementare il sensore composito per il giroscopio con assi limitati.

Se le implementazioni dei dispositivi per il settore automobilistico includono un giroscopio con meno di 3 assi, questi:

[7.3.4/A-4-1] DEVE implementare e segnalare il sensore TYPE_GYROSCOPE_LIMITED_AXES.
[7.3.4/A-4-2] DEVE implementare e segnalare il sensore TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Se le implementazioni di dispositivi per il settore automobilistico includono un ricevitore GPS/GNSS, ma non includono la connettività dati basata sulla rete cellulare:

[7.3.3/A-3-1] DEVE determinare la posizione la prima volta che il ricevitore GPS/GNSS viene acceso o dopo 4 o più giorni entro 60 secondi.
[7.3.3/A-3-2] DEVE soddisfare i criteri relativi al tempo necessario per il primo fix come descritto in 7.3.3/C-1-2 e 7.3.3/C-1-6 per tutte le altre richieste di localizzazione (ovvero le richieste che non sono la prima volta in assoluto o dopo 4 o più giorni). Il requisito 7.3.3/C-1-2 viene in genere soddisfatto nei veicoli senza connessione dati basata su rete mobile, utilizzando le previsioni dell'orbita GNSS calcolate sul ricevitore o utilizzando l'ultima posizione nota del veicolo insieme alla capacità di stimare la posizione per almeno 60 secondi con una precisione della posizione che soddisfi 7.3.3/C-1-3 o una combinazione di entrambi.

Se le implementazioni dei dispositivi per auto includono un sensore TYPE_HEADING:

[7.3.4/A-4-3] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 1 Hz.
[7.3.4/A-SR-3] È FORTEMENTE CONSIGLIATO segnalare eventi fino a una frequenza di almeno 10 Hz.
DEVE essere in riferimento al nord geografico.
DEVE essere disponibile anche quando il veicolo è fermo.
DOVREBBE avere una risoluzione di almeno 1 grado.

Implementazioni di dispositivi per il settore automotive:

[7.4.3/A-0-1] DEVE supportare il Bluetooth e DOVREBBE supportare il Bluetooth LE.
[7.4.3/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 di distribuzione audio (A2DP).
- Controllo della riproduzione dei contenuti multimediali tramite il profilo controllo remoto (AVRCP).
- Condivisione dei contatti tramite il profilo di accesso alla rubrica (PBAP).
[7.4.3/A-SR-1] Sono FORTEMENTE CONSIGLIATI per supportare il profilo di accesso ai messaggi (MAP) se il dispositivo ha la zona occupante del conducente.

[7.4.3/A-1-1] DEVE essere indipendente e NON interferire con l'esperienza BT di altri utenti.

Implementazioni di dispositivi per il settore automotive:

[7.4.5/A] DOVREBBE includere il supporto per la connettività dati basata sulla rete cellulare.
[7.4.5/A] PUÒ utilizzare la costante NetworkCapabilities#NET_CAPABILITY_OEM_PAID dell'API di sistema per le reti che devono essere disponibili per le app di sistema.

Se le implementazioni dei dispositivi includono il supporto della radio AM/FM e espongono la funzionalità a qualsiasi applicazione, queste:

[7.4/A-1-1] DEVE dichiarare il supporto per FEATURE_BROADCAST_RADIO.

Una fotocamera posteriore è una fotocamera rivolta verso l'esterno che può essere posizionata in qualsiasi punto del veicolo ed è rivolta verso l'esterno dell'abitacolo del veicolo, ovvero riprende scene sul lato opposto della carrozzeria del veicolo, come la telecamera posteriore.

Una fotocamera anteriore è una fotocamera rivolta verso l'utente che può essere posizionata in qualsiasi punto del veicolo ed è rivolta verso l'interno dell'abitacolo; ovvero fotografa l'utente, ad esempio per videoconferenze e applicazioni simili.

Implementazioni di dispositivi per il settore automotive:

[7.5/A-SR-1] È FORTEMENTE CONSIGLIATO includere una o più videocamere rivolte verso l'esterno.
POTREBBE includere una o più videocamere rivolte all'utente.
[7.5/A-SR-2] Sono FORTEMENTE CONSIGLIATI per supportare lo streaming simultaneo di più videocamere.

Se le implementazioni di dispositivi per il settore automobilistico includono almeno una videocamera rivolta verso l'esterno, per questa videocamera:

[7.5/A-1-1] DEVE essere orientata in modo che la dimensione lunga della videocamera sia allineata al piano X-Y degli assi del sensore Android Automotive.
[7.5/A-SR-3] Sono FORTEMENTE CONSIGLIATE con hardware a messa a fuoco fissa o EDOF (Extended Depth of Field).
[7.5/A-1-2] DEVE avere la fotocamera principale world-facing come fotocamera world-facing con l'ID fotocamera più basso.

Se le implementazioni di dispositivi per il settore automobilistico includono almeno una videocamera rivolta verso l'utente, per questa videocamera:

[7.5/A-2-1] La fotocamera principale rivolta verso l'utente DEVE essere la fotocamera rivolta verso l'utente con l'ID fotocamera più basso.
PUÒ essere orientata in modo che la dimensione lunga della videocamera sia allineata al piano X-Y degli assi del sensore Android Automotive.

Se le implementazioni di dispositivi per il settore automobilistico includono una videocamera accessibile tramite l'API android.hardware.Camera o android.hardware.camera2, queste:

[7.5/A-3-1] DEVE rispettare i requisiti principali della fotocamera riportati nella sezione 7.5.

Se le implementazioni di dispositivi per il settore automobilistico includono una videocamera non accessibile tramite l'API android.hardware.Camera o android.hardware.camera2, allora:

[7.5/A-4-1] DEVE essere accessibile tramite il servizio di sistema Extended View System.

Se le implementazioni di dispositivi per il settore automobilistico includono una o più videocamere accessibili tramite il servizio di sistema Extended View, per queste videocamere:

[7.5/A-5-1] NON DEVE ruotare o eseguire il mirroring orizzontale dell'anteprima della videocamera.
[7.5/A-SR-4] È FORTEMENTE CONSIGLIATO che abbiano una risoluzione di almeno 1,3 megapixel.

Se le implementazioni di dispositivi per auto includono una o più videocamere accessibili sia tramite il servizio Extended View System sia tramite l'API android.hardware.Camera o android.hardware.Camera2, per questa videocamera:

[7.5/A-6-1] DEVE segnalare lo stesso ID videocamera.

Se le implementazioni dei dispositivi per il settore automobilistico forniscono un'API fotocamera proprietaria:

[7.5/A-7-1] DEVE implementare un'API per la fotocamera utilizzando l'API android.hardware.camera2 o l'API Extended View System.

Implementazioni di dispositivi per il settore automotive:

[7.6.1/A-0-1] DEVE avere almeno 4 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione (partizione /data).
[7.6.1/A] DEVE formattare la partizione di dati per offrire prestazioni e durata migliori sull'archiviazione flash (ad esempio, utilizzando il file system f2fs).

Se le implementazioni di dispositivi per il settore automobilistico forniscono spazio di archiviazione esterno condiviso tramite una parte dello spazio di archiviazione interno non rimovibile:

[7.6.1/A-SR-1] Sono FORTEMENTE CONSIGLIATE per ridurre l'overhead I/O sulle operazioni eseguite sullo spazio di archiviazione esterno, ad esempio utilizzando SDCardFS.

[7.6.1/A-1-1] DEVE avere, su una singola istanza AAOS, almeno 4 GB per ogni utente Android simultaneo di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione (partizione /data).

Se le implementazioni dei dispositivi per il settore automobilistico sono a 64 bit:

[7.6.1/A-2-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 816 MB per display principale se viene utilizzata una delle seguenti densità:
- 280 dpi o meno su schermi piccoli/normali
- ldpi o inferiore su schermi molto grandi
- mdpi o inferiore su schermi di grandi dimensioni
[7.6.1/A-2-2] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 944 MB per display principale se viene utilizzata una delle seguenti densità:
- xhdpi o superiore su schermi piccoli/normali
- hdpi o superiore su schermi di grandi dimensioni
- mdpi o superiore su schermi molto grandi
[7.6.1/A-2-3] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1280 MB per display principale se viene utilizzata una delle seguenti densità:
- 400 dpi o superiore su schermi piccoli/normali
- xhdpi o superiore su schermi di grandi dimensioni
- tvdpi o superiore su schermi molto grandi
[7.6.1/A-2-4] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1824 MB per display principale se viene utilizzata una delle seguenti densità:
- 560 dpi o superiore su schermi piccoli/normali
- 400 dpi o superiore su schermi grandi
- xhdpi o superiore su schermi molto grandi

Implementazioni di dispositivi per il settore automotive:

[7.7.1/A] DEVE includere una porta USB che supporti la modalità periferica.

Se le implementazioni di dispositivi per il settore automobilistico includono una porta USB con un controller che funziona in modalità periferica:

[7.7.1/A-1-1] DEVE implementare l'API Android Open Accessory (AOA).

Se le implementazioni di dispositivi per il settore automobilistico includono una porta USB che supporta la modalità host,

[7.7.2/A-1-1] DEVE implementare la classe audio USB come descritto nella documentazione dell'SDK Android.

Implementazioni di dispositivi per il settore automotive:

[7.8.1/A-0-1] DEVE includere un microfono.

Implementazioni di dispositivi per il settore automotive:

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

[7.8.2/A-1-1] DEVE disporre di un dispositivo di uscita audio per ogni display principale per sistemi con più utenti simultanei.
[7.8.2/A-1-2] DEVE avere una zona audio del conducente che copra l'altoparlante globale dell'abitacolo. La zona del passeggero anteriore può condividere la zona audio del conducente o avere la propria uscita audio.

Quando viene chiamata l'API AudioManager.getDevices() mentre la periferica USB è connessa:

[7.8.2.2/A-1-1] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e ruolo isSink() se il campo Tipo di terminale audio USB è 0x0302.
[7.8.2.2/A-1-2] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e ruolo isSink() se il campo Tipo di terminale audio USB è 0x0402.
[7.8.2.2/A-1-3] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e ruolo isSink() se il campo Tipo di terminale audio USB è 0x0603.
[7.8.2.2/A-1-4] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e ruolo isSink() se il campo del tipo di terminale audio USB è 0x0400.

2.5.2. Multimediali

Le implementazioni dei dispositivi per auto DEVONO supportare i seguenti formati di codifica e decodifica audio e renderli disponibili per le applicazioni di terze parti:

[5.1/A-0-1] Profilo MPEG-4 AAC (AAC LC)
[5.1/A-0-2] Profilo MPEG-4 HE AAC (AAC+)
[5.1/A-0-3] AAC ELD (enhanced low delay AAC)

[5.1/A-0-4] MPEG-D USAC con MPEG-D DRC (Extended High Efficiency AAC)

Le implementazioni dei dispositivi per auto DEVONO supportare i seguenti formati di codifica video e renderli disponibili per le applicazioni di terze parti:

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

Le implementazioni di dispositivi per auto DEVONO supportare i seguenti formati di decodifica video e renderli disponibili per le applicazioni di terze parti:

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

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

[5.3/A-SR-1] H.265 HEVC

[5.5.3/A-1-1] MUST define identical volume curves for all audio output streams mapping to the same volume-group as defined in the car audio configuration file.

2.5.3. Software

Implementazioni di dispositivi per il settore automotive:

[3/A-0-1] DEVE dichiarare la funzionalità android.hardware.type.automotive.
[3/A-0-2] DEVE supportare uiMode = UI_MODE_TYPE_CAR.
[3/A-0-3] MUST support all public APIs in the android.car.* namespace.

Se le implementazioni di dispositivi per il settore automobilistico forniscono un'API proprietaria utilizzando android.car.CarPropertyManager con android.car.VehiclePropertyIds, devono:

[3/A-1-1] NON DEVE assegnare privilegi speciali all'utilizzo di queste proprietà da parte dell'applicazione di sistema né impedire alle applicazioni di terze parti di utilizzare queste proprietà.
[3/A-1-2] NON DEVE replicare una proprietà del veicolo già presente nell'SDK.

Implementazioni di dispositivi per il settore automotive:

[3.2.1/A-0-1] DEVE supportare e applicare tutte le costanti di autorizzazione come documentato nella pagina di riferimento delle autorizzazioni per il settore automobilistico.
[3.2.3.1/A-0-1] DEVE precaricare uno o più componenti di applicazioni o servizi con un gestore di intent, per tutti i pattern di filtri per intent pubblici definiti dai seguenti intent dell'applicazione elencati qui.
[3.2.3.1/A-0-2] DEVE avere un'app che gestisca gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, e ACTION_CREATE_DOCUMENT come descritto nei documenti dell'SDK e fornire all'utente la possibilità di accedere ai dati del provider di documenti utilizzando l'API DocumentsProvider.

Se l'applicazione delle impostazioni dell'implementazione del dispositivo Automotive implementa una funzionalità di suddivisione, utilizzando l'incorporamento di attività, essa:

[3.2.3.1/A-1-1] DEVE avere un'attività che gestisce l'intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY quando la funzionalità di divisione è attiva. L'attività DEVE essere protetta da android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK e DEVE avviare l'attività dell'intent analizzato da Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
[3.4.1/A-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.

[3.8/A-1-1] DEVE implementare il seguente elenco predefinito di UserRestrictions per gli utenti secondari completi che non sono l'utente in primo piano corrente, ma hanno accesso all'interfaccia utente del display assegnato. L'elenco di UserRestrictions è DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE, e DISALLOW_MICROPHONE_TOGGLE.
[3.8/A-1-2] NON DEVE consentire agli utenti secondari completi che non sono l'utente in primo piano corrente, ma che hanno accesso all'interfaccia utente del display assegnato, di modificare la modalità giorno/notte, le impostazioni internazionali, la data, l'ora, il fuso orario o le funzionalità di colore del display (tra cui luminosità, Luce notturna, scala di grigi di Benessere digitale e riduzione dei colori brillanti) per qualsiasi altro utente tramite le Impostazioni o un'API.

Implementazioni di dispositivi per il settore automotive:

[3.8.3/A-0-1] DEVE mostrare le notifiche che utilizzano l'API Notification.CarExtender quando richiesto da applicazioni di terze parti.
[3.8.4/A-SR-1] È VIVAMENTE CONSIGLIATO implementare un assistente sul dispositivo per gestire l'azione Assist.

Se le implementazioni dei dispositivi per auto includono un pulsante push-to-talk:

[3.8.4/A-1-1] DEVE utilizzare una pressione breve del pulsante Push to Talk come interazione designata per avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService.

Implementazioni di dispositivi per il settore automotive:

[3.8.3.1/A-0-1] DEVE eseguire il rendering corretto delle risorse come descritto nella documentazione dell'SDK Notifications on Automotive OS.
[3.8.3.1/A-0-2] DEVE visualizzare RIPRODUCI e DISATTIVA AUDIO per le azioni di notifica al posto di quelle fornite tramite Notification.Builder.addAction()
[3.8.3.1/A] DOVREBBE limitare l'utilizzo di attività di gestione avanzate, come i controlli per canale di notifica. PUÒ utilizzare l'affordance dell'interfaccia utente per applicazione per ridurre i controlli.

Se le implementazioni dei dispositivi automotive supportano le proprietà HAL utente:

[3.9.3/A-1-1] DEVE implementare tutte le proprietà del ciclo di vita dell'utente: INITIAL_USER_INFO, SWITCH_USER, CREATE_USER e REMOVE_USER.

Implementazioni di dispositivi per il settore automotive:

[3.14/A-0-1] DEVE includere un framework UI per supportare app di terze parti che utilizzano le API media come descritto nella sezione 3.14.
[3.14/A-0-2] DEVE consentire all'utente di interagire in sicurezza con le applicazioni multimediali durante la guida.
[3.14/A-0-3] DEVE supportare l'azione CAR_INTENT_ACTION_MEDIA_TEMPLATE dell'intent implicito con l'extra CAR_EXTRA_MEDIA_PACKAGE.
[3.14/A-0-4] DEVE fornire un invito per accedere all'attività delle preferenze di un'applicazione multimediale, ma DEVE attivarla solo quando le limitazioni dell'esperienza utente dell'auto non sono attive.
[3.14/A-0-5] DEVE visualizzare messaggi di errore impostati dalle applicazioni multimediali e DEVE supportare gli extra opzionali ERROR_RESOLUTION_ACTION_LABEL e ERROR_RESOLUTION_ACTION_INTENT.
[3.14/A-0-6] DEVE supportare una funzionalità di ricerca in-app per le app che supportano la ricerca.
[3.14/A-0-7] DEVE rispettare le definizioni di CONTENT_STYLE_BROWSABLE_HINT e CONTENT_STYLE_PLAYABLE_HINT quando viene visualizzata la gerarchia di MediaBrowser.

Implementazioni di dispositivi per il settore automotive:

[3.14/A-0-8] DEVE dichiarare il flag funzionalità android.software.car.templates_host.
[3.14/A-0-9] DEVE dichiarare il flag funzionalità com.android.car.background_audio_while_driving.
[3.14/A-0-10] DEVE dichiarare il flag funzionalità android.software.car.templates_host.media.

Se le implementazioni dei dispositivi per il settore automobilistico includono un'app di avvio predefinita:

[3.14/A-1-1] MUST include media services and open them with the CAR_INTENT_ACTION_MEDIA_TEMPLATE intent.

Implementazioni di dispositivi per il settore automotive:

[3.8/A] POTREBBE limitare le richieste dell'applicazione di entrare in modalità a schermo intero come descritto in immersive documentation.
[3.8/A] POTREBBE mantenere sempre visibili la barra di stato e la barra di navigazione.
[3.8/A] POTREBBE limitare le richieste dell'applicazione di modificare i colori dietro gli elementi della UI di sistema, per garantire che questi elementi siano sempre chiaramente visibili.

Implementazioni di dispositivi per il settore automotive:

[7.1.1/A-0-1] DEVE dichiarare il flag funzionalità android.software.car.display_compatibility.

Durante l'esecuzione di applicazioni in primo piano con la funzionalità android.software.car.display_compatibility o di applicazioni senza la funzionalità android.hardware.type.automotive, i dispositivi per il settore automobilistico:

[7.1.1/A-1-1] DEVE fornire la funzione Indietro.

Se le implementazioni dei dispositivi per il settore automobilistico consentono agli utenti di effettuare chiamate di qualsiasi tipo, devono:

[7.4.1.2/A-1-1] DEVE dichiarare il flag funzionalità android.software.telecom.

[7.4.1.2/A-1-2] DEVE implementare il framework per le telecomunicazioni.

2.5.4. Prestazioni e potenza

[8.1/A-0-1] Latenza dei frame coerente. La latenza dei frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più di 5 frame al secondo e DOVREBBE essere inferiore a 1 frame al secondo.
[8.1/A-0-2] Latenza dell'interfaccia utente. Le implementazioni del dispositivo DEVONO garantire un'esperienza utente a bassa latenza scorrendo un elenco di 10.000 voci di elenco come definito da Android Compatibility Test Suite (CTS) in meno di 36 secondi.
[8.1/A-0-3] Passaggio da un'attività all'altra. Quando sono state avviate più app, il riavvio di un'applicazione già in esecuzione dopo l'avvio DEVE richiedere meno di 1 secondo.

Implementazioni di dispositivi per il settore automotive:

[8.2/A-0-1] DEVE segnalare il numero di byte letti e scritti nella memoria non volatile per ogni UID del processo, in modo che le statistiche siano disponibili per gli sviluppatori tramite l'API di sistema android.car.storagemonitoring.CarStorageMonitoringManager. Android Open Source Project soddisfa il requisito tramite il modulo kernel uid_sys_stats.
[8.2/A-0-2] DEVE garantire una velocità di scrittura sequenziale di almeno 5 MB/s.
[8.2/A-0-3] DEVE garantire una velocità di scrittura casuale di almeno 0,5 MB/s.
[8.2/A-0-4] DEVE garantire una lettura sequenziale con prestazioni di almeno 15 MB/s.
[8.2/A-0-5] DEVE garantire una lettura casuale con prestazioni di almeno 3,5 MB/s.

Se le implementazioni dei dispositivi per il settore automobilistico restituiscono android.os.Build.VERSION_CODES.U o un valore superiore per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS,

[8.2/A-1-1] DEVE garantire una velocità di scrittura sequenziale di almeno 150 MB/s.
[8.2/A-1-2] DEVE garantire una scrittura casuale con prestazioni di almeno 10 MB/s.
[8.2/A-1-3] DEVE garantire una velocità di lettura sequenziale di almeno 250 MB/s.
[8.2/A-1-4] DEVE garantire una lettura casuale con una velocità di almeno 100 MB/s.
[8.2/A-1-5] DEVE garantire prestazioni di lettura e scrittura sequenziali parallele con prestazioni di lettura doppie e prestazioni di scrittura singole di almeno 50 MB/s.
[8.3/A-1-3] DEVE supportare la modalità Garage.
[8.3/A] DEVE essere in modalità Garage per almeno 15 minuti dopo ogni viaggio, a meno che:
- La batteria è scarica.
- Nessun job inattivo è pianificato.
- Il conducente esce dalla modalità Garage.
[8.4/A-0-1] DEVE fornire un profilo di consumo energetico per componente che definisca il valore di consumo di corrente per ogni componente hardware e il consumo eccessivo della batteria causato dai componenti nel tempo, come documentato nel sito dell'Android Open Source Project.
[8.4/A-0-2] DEVE segnalare tutti i valori di consumo energetico in milliampere ora (mAh).
[8.4/A-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID del processo. L'Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
[8.4/A] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire l'utilizzo di energia del componente hardware a un'applicazione.
[8.4/A-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando shell adb shell dumpsys batterystats allo sviluppatore di app.

2.5.5. Modello di sicurezza

Se le implementazioni dei dispositivi per il settore automobilistico supportano più utenti:

[9.5/A-1-1] NON DEVE consentire agli utenti di interagire con né di passare all'utente di sistema headless, ad eccezione del provisioning del dispositivo.
[9.5/A-1-2] DEVE passare a un utente secondario prima del giorno BOOT_COMPLETED.
[9.5/A-1-3] DEVE supportare la possibilità di creare un utente ospite anche quando è stato raggiunto il numero massimo di utenti su un dispositivo.

Se le implementazioni dei dispositivi per il settore automobilistico supportano l'API di sistema VisualQueryDetectionService o un altro meccanismo per il rilevamento delle query senza indicazione di accesso al microfono e/o alla fotocamera:

[9.8/A-1-1] DEVE assicurarsi che il servizio di rilevamento delle query possa trasmettere dati solo al sistema, a ContentCaptureService o al servizio di riconoscimento vocale sul dispositivo (creato da SpeechRecognizer#createOnDeviceSpeechRecognizer()).
[9.8/A-1-2] NON DEVE consentire la trasmissione di informazioni audio o video al di fuori di VisualQueryDetectionService, tranne che a ContentCaptureService o al servizio di riconoscimento vocale sul dispositivo.
[9.8/A-1-3] DEVE mostrare una notifica all'utente nell'UI di sistema quando il dispositivo rileva l'intenzione dell'utente di interagire con l'applicazione Assistente digitale (ad esempio rilevando la presenza dell'utente tramite la fotocamera).
[9.8/A-1-4] DEVE mostrare un indicatore del microfono e visualizzare la query dell'utente rilevata nell'interfaccia utente immediatamente dopo il rilevamento della query dell'utente.
[9.8/A-1-5] NON DEVE consentire a un'applicazione installabile dall'utente di fornire il servizio di rilevamento delle query visive.

Se le implementazioni dei dispositivi per il settore automobilistico dichiarano android.hardware.microphone, devono:

[9.8.2/A-1-1] DEVE mostrare l'indicatore del microfono quando un'app accede ai dati audio dal microfono, ma non quando il microfono è accessibile solo da HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o da app che detengono i ruoli indicati nella sezione 9.1 con identificatore CDD [C-4-X].
[9.8.2/A-1-2] NON deve nascondere l'indicatore del microfono per le app di sistema che hanno interfacce utente visibili o interazione diretta con l'utente.
[9.8.2/A-1-3] DEVE fornire un'opzione per attivare/disattivare il microfono nell'app Impostazioni.

Se le implementazioni dei dispositivi per il settore automobilistico dichiarano android.hardware.camera.any, devono:

[9.8.2/A-2-1] DEVE mostrare l'indicatore della videocamera quando un'app accede ai dati della videocamera in diretta, ma non quando la videocamera viene utilizzata solo da app che detengono i ruoli definiti nella sezione 9.1 Autorizzazioni con identificatore CDD [C-4-X].
[9.8.2/A-2-2] NON DEVE nascondere l'indicatore fotocamera per le app di sistema che hanno interfacce utente visibili o interazione utente diretta.
[9.8.2/A-2-3] DEVE fornire un'opzione per attivare/disattivare la fotocamera nell'app Impostazioni.
[9.8.2/A-2-4] DEVE mostrare le app recenti e attive che utilizzano la fotocamera come restituito da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.

Implementazioni di dispositivi per il settore automotive:

[9/A-0-1] DEVE dichiarare la funzionalità android.hardware.security.model.compatible.
[9.11/A-0-1] DEVE eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
[9.11/A-0-2] DEVE avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e delle funzioni hash MD5, SHA-1 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 versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi con cui il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto Android Open Source Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti esaminata di un isolamento basato su hypervisor adeguato sono opzioni alternative.
[9.11/A-0-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e solo in caso di esito positivo consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere archiviate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto open source Android fornisce il livello di astrazione hardware (HAL) Gatekeeper e Trusty, che possono essere utilizzati per soddisfare questo requisito.
[9.11/A-0-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 NON DEVONO essere utilizzate come identificatori permanenti del dispositivo.

Nota :per soddisfare questo requisito, devi condividere la stessa chiave di attestazione per un determinato SKU,a meno che non vengano prodotte almeno 100.000 unità di questo SKU. Se vengono prodotte più di 100.000 unità di questo SKU, DOPO questa quantità POTREBBE essere utilizzata una chiave diversa per ogni gruppo di 100.000 unità. In alternativa, è possibile utilizzare la soluzione di provisioning delle chiavi remoto per eseguire il provisioning di chiavi di attestazione di breve durata sul dispositivo.

Implementazioni di dispositivi per il settore automotive:

[9.14/A-0-1] MUST gatekeep messages from Android framework vehicle subsystems (e.g., allowlisting permitted message types and message sources).
[9.14/A-0-2] DEVE proteggere da attacchi Denial of Service dal framework Android o da app di terze parti. In questo modo si evita che software dannosi inondino la rete del veicolo con traffico, il che potrebbe portare a malfunzionamenti dei sottosistemi del veicolo.

2.5.6. Compatibilità di strumenti e opzioni per sviluppatori

Implementazioni di dispositivi per il settore automotive:

Perfetto
- [6.1/A-0-1] DEVE esporre un binario /system/bin/perfetto all'utente della shell la cui riga di comando è conforme alla documentazione di Perfetto.
- [6.1/A-0-2] Il binario perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
- [6.1/A-0-3] Il binario perfetto DEVE scrivere come output una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
- [6.1/A-0-4] DEVE fornire, tramite il binario perfetto, almeno le origini dati descritte nella documentazione di perfetto.
- [6.1/A-0-5] Il daemon di tracciamento perfetto DEVE essere abilitato per impostazione predefinita (proprietà di sistema persist.traced.enable).

2.6. Requisiti per i tablet

Un dispositivo tablet Android si riferisce a un'implementazione di un dispositivo Android che in genere soddisfa tutti i seguenti criteri:

Si utilizza tenendolo con entrambe le mani.
Non ha una configurazione a conchiglia o convertibile.
Le implementazioni della tastiera fisica utilizzate con il dispositivo si connettono tramite una connessione standard (ad es. USB, Bluetooth).
Ha una fonte di alimentazione che fornisce mobilità, ad esempio una batteria.
Ha una dimensione del display dello schermo superiore a 7" e inferiore a 18", misurata in diagonale.

Le implementazioni di dispositivi tablet hanno requisiti simili a quelle dei dispositivi palmari. Le eccezioni sono indicate con un asterisco nella sezione e sono riportate a titolo di riferimento in questa sezione.

2.6.1. Hardware

Giroscopio

Se le implementazioni dei dispositivi tablet includono un giroscopio a 3 assi:

[7.3.4/Tab-1-1] DEVE essere in grado di misurare i cambiamenti di orientamento fino a 1000 gradi al secondo.

Memoria e spazio di archiviazione minimi (sezione 7.6.1)

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

Modalità Realtà virtuale (sezione 7.9.1)

Virtual Reality High Performance (Sezione 7.9.2)

I requisiti di realtà virtuale non sono applicabili ai tablet.

2.6.2. Modello di sicurezza

Chiavi e credenziali (sezione 9.11)

Fai riferimento alla sezione [9.11].

Se le implementazioni dei dispositivi tablet includono più utenti e non dichiarano il flag di funzionalità android.hardware.telephony:

[9.5/T-1-1] DEVE supportare i profili con limitazioni, una funzionalità che consente ai proprietari del dispositivo di gestire utenti aggiuntivi e le loro funzionalità sul dispositivo. Con i profili con limitazioni, i proprietari dei dispositivi possono configurare rapidamente ambienti separati in cui far lavorare altri utenti, con la possibilità di gestire limitazioni più granulari nelle app disponibili in questi ambienti.

Se le implementazioni dei dispositivi tablet includono più utenti e dichiarano il flag di funzionalità android.hardware.telephony:

[9.5/T-2-1] NON DEVE supportare i profili con limitazioni, ma DEVE essere in linea con l'implementazione AOSP dei controlli per consentire /disattivare l'accesso di altri utenti alle chiamate vocali e agli SMS.

2.6.2. Software

[3.2.3.1/Tab-0-1] DEVE precaricare uno o più componenti di applicazioni o servizi con un gestore di intent, per tutti i pattern di filtri per intent pubblici definiti dai seguenti intent di applicazioni elencati qui.

3. Software

3.1. Compatibilità API gestita

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

Implementazioni del dispositivo:

[C-0-1] DEVE 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 Android upstream.
[C-0-2] DEVE supportare/conservare tutte le classi, i metodi e gli elementi associati contrassegnati dall'annotazione TestApi (@TestApi).
[C-0-3] NON DEVE omettere alcuna API gestita, alterare interfacce o firme API, deviare dal comportamento documentato o includere no-op, tranne nei casi specificamente consentiti da questa definizione di compatibilità.
[C-0-4] DEVONO comunque mantenere le API presenti e comportarsi in modo ragionevole, anche quando vengono omesse alcune funzionalità hardware per le quali Android include API. Per i requisiti specifici per questo scenario, consulta la sezione 7.
[C-0-5] NON DEVE consentire ad app di terze parti di utilizzare interfacce non SDK, che sono definite come metodi e campi nei pacchetti di linguaggio Java che si trovano nel boot classpath in AOSP e che non fanno parte dell'SDK pubblico. Ciò include le API decorate con l'annotazione @hide, ma non con un @SystemAPI, come descritto nei documenti SDK e nei membri di classe privati e privati del pacchetto.
[C-0-6] MUST ship with each and every non-SDK interface on the same restricted lists as provided via the provisional and denylist flags in prebuilts/runtime/appcompat/hiddenapi-flags.csv path for the appropriate API level branch in the AOSP.
[C-0-7] DEVE supportare il meccanismo di aggiornamento dinamico della configurazione firmata per rimuovere le interfacce non SDK da un elenco con limitazioni incorporando la configurazione firmata in qualsiasi APK, utilizzando le chiavi pubbliche esistenti presenti in AOSP.

Tuttavia,
- MAY, if a hidden API is absent or implemented differently on the device implementation, move the hidden API into the denylist or omit it from all restricted lists.
- MAGGIO, se un'API nascosta non esiste già in AOSP, aggiungila a uno degli elenchi con limitazioni.

[C-0-8] NON DEVE supportare l'installazione di applicazioni che hanno come target un livello API inferiore a 24 26.

3.1.1. Estensioni Android

Android supporta l'estensione della superficie API gestita di un determinato livello API aggiornando la versione dell'estensione per quel livello API. L'API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) restituisce la versione dell'estensione del apiLevel fornito, se esistono estensioni per quel livello API.

Implementazioni del dispositivo Android:

[C-0-1] DEVE precaricare l'implementazione AOSP sia della libreria condivisa ExtShared sia dei servizi ExtServices con versioni maggiori o uguali alle versioni minime consentite per ogni livello API. Ad esempio, le implementazioni di dispositivi Android 7.0 che eseguono il livello API 24 DEVONO includere almeno la versione 1.
[C-0-2] MUST only return valid extension version number that have been defined by the AOSP.
[C-0-3] DEVE supportare tutte le API definite dalle versioni delle estensioni restituite da android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) allo stesso modo in cui sono supportate le altre API gestite, seguendo i requisiti della sezione 3.1.

3.1.2. Libreria Android

A causa del ritiro del client HTTP Apache, le implementazioni del dispositivo:

[C-0-1] NON DEVE inserire la libreria org.apache.http.legacy nel bootclasspath.
[C-0-2] DEVE aggiungere la libreria org.apache.http.legacy al classpath dell'applicazione solo quando l'app soddisfa una delle seguenti condizioni:
- Ha come target il livello API 28 o versioni precedenti.
- Dichiara nel manifest che ha bisogno della libreria impostando l'attributo android:name di <uses-library> su org.apache.http.legacy.

L'implementazione AOSP soddisfa questi requisiti.

3.2. Compatibilità API soft

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

3.2.1. Autorizzazioni

[C-0-1] Gli implementatori di 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 creazione

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 nelle implementazioni dei dispositivi, la tabella seguente include ulteriori limitazioni sui formati di questi valori a cui le implementazioni dei dispositivi DEVONO conformarsi.

Parametro	Dettagli
VERSIONE.RELEASE	La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE contenere uno dei valori stringa definiti in Stringhe di versione consentite per Android 17.
VERSION.SDK	La versione del sistema Android in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 17, questo campo DEVE avere il valore intero 17_INT.
VERSION.SDK&lowbar;INT	La versione del sistema Android in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 17, questo campo DEVE avere il valore intero 17&lowbar;INT.
VERSION.INCREMENTAL	Un valore scelto dall'implementatore del dispositivo che indica 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 build o l'identificatore di modifica del controllo del codice sorgente utilizzato per generare la build. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit stampabile e corrispondere all'espressione regolare `^[^ :\/~]+$`.
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 noto agli utenti finali. DEVE essere in un formato leggibile e DOVREBBE 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&lowbar;ABIS	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. API nativa Compatibilità.
SUPPORTED&lowbar;32&lowbar;BIT&lowbar;ABIS	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. API nativa Compatibilità.
SUPPORTED&lowbar;64&lowbar;BIT&lowbar;ABIS	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
CPU&lowbar;ABI	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. API nativa Compatibilità.
CPU&lowbar;ABI2	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
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 durata del prodotto.
FINGERPRINT	Una stringa che identifica in modo univoco questa build. Deve essere ragionevolmente leggibile. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ad esempio: acme/myproduct/ mydevice:17/LMYXX/3359:userdebug/test-keys L'impronta NON DEVE includere spazi vuoti. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit.
HARDWARE	Il nome dell'hardware (dalla riga di comando del kernel o da /proc). Deve essere ragionevolmente leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `^[a-zA-Z0-9_-]+$`.
HOST	Una stringa che identifica in modo univoco l'host su cui è stata creata la build, in formato leggibile. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota ("").
ID	Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in formato leggibile. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DOVREBBE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere tra 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	Il nome commerciale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota (""). Questo campo NON deve cambiare durante il ciclo di vita del prodotto.
SOC&lowbar;MANUFACTURER	Il nome commerciale del produttore del system on chip (SOC) principale utilizzato nel prodotto. I dispositivi con lo stesso produttore di SOC devono utilizzare lo stesso valore costante. Chiedi al produttore del SOC la costante corretta da utilizzare. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit, DEVE corrispondere all'espressione regolare `^([0-9A-Za-z ]+)`, NON DEVE iniziare o terminare con spazi bianchi e NON DEVE essere uguale a "unknown". Questo campo NON DEVE cambiare durante la durata del prodotto.
SOC&lowbar;MODEL	Il nome del modello del system on a chip (SOC) principale utilizzato nel prodotto. I dispositivi con lo stesso modello di SOC devono utilizzare lo stesso valore costante. Chiedi al produttore del SoC la costante corretta da utilizzare. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `^([0-9A-Za-z ._/+-]+)$`, NON DEVE iniziare o terminare con spazi bianchi e NON DEVE essere uguale a "unknown". Questo campo NON DEVE cambiare per tutta la durata del prodotto.
MODEL	Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo noto all'utente finale. Questo 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 che NON deve essere nullo o la stringa vuota (""). È VIVAMENTE CONSIGLIATO di NON modificare questo campo 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 (SKU) specifico 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.
ODM&lowbar;SKU	Un valore facoltativo scelto dall'implementatore del dispositivo che contiene il codice identificativo dell'articolo (Stock Keeping Unit) utilizzato per monitorare configurazioni specifiche del dispositivo, ad esempio eventuali periferiche incluse con il dispositivo al momento della vendita. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare `^([0-9A-Za-z.,_-]+)$`.
SERIAL	DEVE restituire "UNKNOWN".
TAG	Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che distinguono ulteriormente la build. I tag DEVONO essere codificabili come ASCII a 7 bit e corrispondere all'espressione regolare `^[a-zA-Z0-9._-]+` e DEVONO avere uno dei valori corrispondenti alle tre configurazioni di firma tipiche della piattaforma Android: release-keys, dev-keys e test-keys.
TEMPO	Un valore che rappresenta il timestamp della build.
TIPO	Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni tipiche di Android Runtime: user, userdebug o eng.
UTENTE	Un nome o un ID utente dell'utente (o utente automatico) che ha generato la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota ("").
SECURITY&lowbar;PATCH	Un valore che indica il livello patch di sicurezza di una build. DEVE indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti fino al Bollettino pubblico sulla sicurezza di Android designato. Deve essere nel formato [AAAA-MM-GG], corrispondente a una stringa definita documentata nel bollettino sulla sicurezza pubblica di Android o nell' avviso di sicurezza di Android, ad esempio "2015-11-01".
BASE&lowbar;OS	Un valore che rappresenta il parametro FINGERPRINT della build che è altrimenti identica a questa build, ad eccezione delle patch fornite nel Bollettino sulla sicurezza pubblica di Android. DEVE segnalare il valore corretto e, se non esiste una build di questo tipo, segnalare 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 interno utilizzato nel dispositivo, in formato leggibile. Se un dispositivo non ha alcuna radio/modem interno, 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._-,]+$`.
getSerial()	DEVE (essere o restituire) un numero di serie hardware, che DEVE essere disponibile e univoco tra 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]+$`.
STRONGBOX&lowbar;MANUFACTURER	Il nome commerciale del produttore del chip StrongBox utilizzato nel prodotto. Il fornitore di StrongBox fornisce la costante corretta. I dispositivi con lo stesso fornitore StrongBox devono utilizzare lo stesso valore costante. Il valore di questo campo DEVE corrispondere all'espressione regolare `^([0-9A-Za-z ]+)` e NON DEVE essere uguale a "unsupported". Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.
STRONGBOX&lowbar;MODEL	Il nome del modello del chip StrongBox utilizzato nel prodotto. Il fornitore di StrongBox fornisce la costante corretta. I dispositivi con lo stesso fornitore StrongBox DEVONO utilizzare lo stesso valore costante. Il valore di questo campo DEVE corrispondere all'espressione regolare `^([0-9A-Za-z ._/+-]+)$` e NON DEVE essere uguale a "unsupported". Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.

3.2.3. Compatibilità degli intent

3.2.3.1. Intent comuni delle applicazioni

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 che implementano diversi pattern di intent per eseguire azioni comuni.

Implementazioni del dispositivo:

[C-SR-1] È FORTEMENTE CONSIGLIATO precaricare uno o più componenti di applicazioni o servizi con un gestore di intent, per tutti i pattern di filtri per intent pubblici definiti dagli intent delle applicazioni elencati qui e fornire l'esecuzione, ovvero soddisfare le aspettative degli sviluppatori per questi intent comuni delle applicazioni, come descritto nell'SDK.

Per gli intent di applicazione obbligatori per ogni tipo di dispositivo, consulta la Sezione 2.

3.2.3.2. Risoluzione dell'intent

[C-0-1] Poiché Android è una piattaforma estensibile, le implementazioni dei dispositivi DEVONO consentire l'override di ogni pattern di intent a cui viene fatto riferimento nella sezione 3.2.3.1, ad eccezione delle Impostazioni, da parte di applicazioni di terze parti. L'implementazione open source di Android upstream lo consente per impostazione predefinita.
[C-0-2] Gli implementatori di dispositivi NON DEVONO assegnare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema né impedire alle applicazioni di terze parti di eseguire il binding e assumere il controllo di questi pattern. Questo divieto include, a titolo esemplificativo ma non esaustivo, 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 dei dati. Ad esempio, un pattern di filtro per intent che specifica l'URI di dati"http://www.android.com" è più specifico del pattern di intent principale del browser per "http://".

Android include anche un meccanismo che consente alle app di terze parti di dichiarare un comportamento di collegamento delle app predefinito autorevole per determinati tipi di intent URI web. Quando queste dichiarazioni autorevoli vengono definite nei pattern di filtri per intent di un'app, le implementazioni del dispositivo:

[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 da Package Manager nel progetto Android Open Source Project upstream.
[C-0-5] DEVE tentare la convalida dei filtri di intent durante l'installazione dell'applicazione e impostare tutti i filtri di intent URI convalidati correttamente come gestori di app predefiniti per i relativi URI.
POSSONO impostare filtri per intent URI specifici come gestori di app predefiniti per i propri URI, se vengono verificati correttamente, ma la verifica di altri filtri URI candidati non va a buon fine. Se un'implementazione del dispositivo lo fa, DEVE fornire override del pattern per URI appropriati per l'utente nel menu delle impostazioni.
DEVE fornire all'utente controlli dei link dell'app per app in Impostazioni come segue:
- [C-0-6] L'utente DEVE essere in grado di ignorare in modo olistico il comportamento predefinito dei link dell'app per un'app da: aprire sempre, chiedere sempre o non aprire mai, che deve essere applicato a tutti i filtri per intent URI candidati in egual misura.
- [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 eseguire l'override di filtri per intent URI candidati specifici che sono stati verificati correttamente, in base al filtro per intent.
- [C-0-8] L'implementazione del dispositivo DEVE fornire agli utenti la possibilità di visualizzare e ignorare filtri di intent URI candidati specifici se l'implementazione del dispositivo consente la verifica di alcuni filtri di intent URI candidati, mentre altri non riescono.

3.2.3.3. Spazi dei nomi degli intent

[C-0-1] Le implementazioni dei dispositivi NON DEVONO includere componenti Android che rispettino 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 rispettino nuovi intent o pattern di intent di trasmissione utilizzando un'ACTION, una CATEGORY o un'altra stringa chiave in uno spazio di pacchetti appartenente a un'altra organizzazione.
[C-0-3] Gli implementatori di dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent elencati nella sezione 3.2.3.1.
Le implementazioni dei dispositivi POSSONO includere pattern di intent utilizzando spazi dei nomi chiaramente e ovviamente associati alla propria organizzazione. Questo divieto è analogo a quello specificato per le classi di linguaggio Java nella sezione 3.6.

3.2.3.4. Broadcast Intents

Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent per notificare loro le modifiche nell'ambiente hardware o software.

Implementazioni del dispositivo:

[C-0-1] DEVE trasmettere gli intent di trasmissione pubblica elencati qui in risposta agli eventi di sistema appropriati, come descritto nella documentazione dell'SDK. Tieni presente che questo requisito non è in conflitto con la sezione 3.5, in quanto la limitazione per le applicazioni in background è descritta anche nella documentazione dell'SDK. Inoltre, alcuni intent di trasmissione sono condizionati dal supporto hardware. Se il dispositivo supporta l'hardware necessario, DEVE trasmettere gli intent e fornire il comportamento in linea con la documentazione dell'SDK.

3.2.3.5. Intent di applicazione condizionali

Android include impostazioni che consentono agli utenti di selezionare facilmente le proprie applicazioni predefinite, ad esempio per la schermata Home o gli SMS.

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

Se le implementazioni dei dispositivi segnalano android.software.home_screen, significa che:

[C-1-1] DEVE rispettare l'intent android.settings.HOME_SETTINGS di mostrare un menu delle impostazioni dell'app predefinita per la schermata Home.

Se le implementazioni dei dispositivi segnalano android.hardware.telephony.calling, significa che:

[C-2-1] DEVE fornire un menu delle impostazioni che richiami l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT per mostrare una finestra di dialogo per cambiare l'applicazione SMS predefinita.
[C-2-2] DEVE rispettare l'intent android.telecom.action.CHANGE_DEFAULT_DIALER di mostrare una finestra di dialogo per consentire all'utente di modificare l'applicazione Telefono predefinita.
- DEVE utilizzare l'interfaccia utente dell'app Telefono predefinita selezionata dall'utente per le chiamate in entrata e in uscita, ad eccezione delle chiamate di emergenza, che utilizzano l'app Telefono preinstallata.
[C-2-3] DEVE rispettare l'intent android.telecom.action.CHANGE_PHONE_ACCOUNTS per fornire all'utente la possibilità di configurare ConnectionServices associato a 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 Account chiamate" nel menu delle impostazioni "Chiamate".
[C-2-4] DEVE consentire android.telecom.CallRedirectionService per un'app che detiene il ruolo android.app.role.CALL_REDIRECTION.
[C-2-5] DEVE fornire all'utente la possibilità di scegliere un'app che detiene il ruolo android.app.role.CALL_REDIRECTION.
[C-2-6] DEVE rispettare gli intent android.intent.action.SENDTO e android.intent.action.VIEW e fornire un'attività per inviare/visualizzare messaggi SMS.
[C-SR-1] È VIVAMENTE CONSIGLIATO di rispettare gli intent android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL con un'applicazione di composizione precaricata in grado di gestire questi intent e fornire il completamento come descritto nell'SDK.

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

[C-3-1] DEVE rispettare l'intent android.settings.NFC_PAYMENT_SETTINGS per mostrare un menu delle impostazioni dell'app predefinita per i pagamenti contactless.
[C-3-2] DEVE rispettare l'intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT per mostrare un'attività che apre una finestra di dialogo per chiedere all'utente di modificare il servizio di emulazione della carta predefinito per una determinata categoria, come descritto nell'SDK.

Se le implementazioni dei dispositivi segnalano android.hardware.nfc, significa che:

[C-4-1] DEVE rispettare questi intent android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED, per mostrare un'attività che soddisfi le aspettative degli sviluppatori per questi intent come descritto nell'SDK.

Se le implementazioni dei dispositivi segnalano android.hardware.bluetooth, significa che:

[C-5-1] DEVE rispettare l'intent 'android.bluetooth.adapter.action.REQUEST_ENABLE' e mostrare un'attività di sistema per consentire all'utente di attivare il Bluetooth.
[C-5-2] DEVE rispettare l'intent "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" e mostrare un'attività di sistema che richiede la modalità rilevabile.

Se le implementazioni del dispositivo supportano la funzionalità Non disturbare:

[C-6-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 DND.

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

[C-7-1] DEVE fornire un meccanismo accessibile all'utente per aggiungere e configurare metodi di immissione di terze parti in risposta all'intent android.settings.INPUT_METHOD_SETTINGS.

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

[C-8-1] DEVE rispettare l'intenzione di fornire un meccanismo accessibile agli utenti per attivare e disattivare i servizi di accessibilità di terze parti insieme ai servizi di accessibilità precaricati.android.settings.ACCESSIBILITY_SETTINGS

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Easy Connect ed espongono la funzionalità ad app di terze parti, queste:

[C-9-1] DEVE implementare le API Intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI come descritto nella documentazione dell'SDK.

Se le implementazioni del dispositivo forniscono la modalità Risparmio dati:

[C-10-1] DEVE fornire un'interfaccia utente nelle impostazioni che gestisca l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, consentendo agli utenti di aggiungere o rimuovere applicazioni dalla lista consentita.

Se le implementazioni del dispositivo non forniscono la modalità Risparmio dati:

[C-11-1] DEVE avere un'attività che gestisce l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ma PUÒ implementarlo come no-op.

Se le implementazioni dei dispositivi dichiarano il supporto della videocamera tramite android.hardware.camera.any:

[C-12-3] DEVE gestire e DEVE consentire solo alle applicazioni Android preinstallate di gestire i seguenti intent MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, e MediaStore.ACTION_VIDEO_CAPTURE come descritto nel documento SDK.

Se le implementazioni dei dispositivi segnalano android.software.device_admin, significa che:

[C-13-1] DEVE rispettare l'intent android.app.action.ADD_DEVICE_ADMIN per richiamare una UI per guidare l'utente nell'aggiunta dell'amministratore del dispositivo al sistema (o consentirgli di rifiutarla).
[C-13-2] MUST honor the intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION and have an activity to provide fulfillment for these intents as described in SDK here.

Se le implementazioni del dispositivo dichiarano il flag di funzionalità android.software.autofill,

[C-14-1] DEVE implementare completamente le API AutofillService e AutofillManager e rispettare l'intent android.settings.REQUEST_SET_AUTOFILL_SERVICE per mostrare un menu delle impostazioni dell'app predefinito per attivare e disattivare la compilazione automatica e modificare il servizio di compilazione automatica predefinito per l'utente.

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-SR-2] È VIVAMENTE CONSIGLIATO fornire un meccanismo accessibile agli utenti per concedere o revocare l'accesso alle statistiche sull'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 intendono impedire a qualsiasi app, incluse quelle preinstallate, di accedere alle statistiche di utilizzo:

[C-15-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'accesso viene negato all'utente.

Se le implementazioni del dispositivo mostrano link alle attività specificate da AutofillService_passwordsActivity in Impostazioni o link alle password utente tramite un meccanismo simile, queste:

[C-16-1] MUST surface such links for all installed autofill services.

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

[C-18-1] DEVE rispettare l'intent android.settings.ACTION_VOICE_INPUT_SETTINGS di mostrare un menu delle impostazioni dell'app predefinito per l'input vocale e l'assistenza.

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

[C-SR-3] È FORTEMENTE CONSIGLIATO rispettare gli intent android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA e android.speech.tts.engine.GET_SAMPLE_TEXT che hanno un'attività per fornire l'evasione di questi intent come descritto nell'SDK qui.

Android include il supporto per i salvaschermo interattivi, in precedenza chiamati Dreams. I salvaschermo consentono agli utenti di interagire con le applicazioni quando un dispositivo collegato a una fonte di alimentazione è inattivo o agganciato a una base da scrivania. Implementazioni del dispositivo:

DEVE includere il supporto per i salvaschermo e fornire un'opzione di impostazione per consentire agli utenti di configurare i salvaschermo in risposta all'intent android.settings.DREAM_SETTINGS.

Se le implementazioni dei dispositivi segnalano android.hardware.nfc.uicc o android.hardware.nfc.ese, questi:

[C-19-1] DEVE implementare l'API Intent NfcAdapter.ACTION_TRANSACTION_DETECTED (come "EVT_TRANSACTION" definita dalla specifica tecnica TS.26 - NFC Handset Requirements della GSM Association).

3.2.4. Attività su display secondari/multipli

Se le implementazioni dei dispositivi consentono l'avvio di attività Android normali su più di un display, queste:

[C-1-1] DEVE impostare il flag funzionalità android.software.activities_on_secondary_displays.
[C-1-2] DEVE garantire la compatibilità dell'API simile a un'attività in esecuzione sul display principale.
[C-1-3] DEVE visualizzare la nuova attività sullo stesso display dell'attività che l'ha avviata, quando la nuova attività viene avviata senza specificare un display di destinazione tramite l'API ActivityOptions.setLaunchDisplayId().
[C-1-4] DEVE eliminare tutte le attività quando viene rimosso un display con il flag Display.FLAG_PRIVATE.
[C-1-5] DEVE nascondere in modo sicuro i contenuti su tutte le schermate quando il dispositivo è bloccato con una schermata di blocco sicura, a meno che l'app non scelga di mostrare i contenuti sopra la schermata di blocco utilizzando l'API Activity#setShowWhenLocked().
DEVE avere android.content.res.Configuration che corrisponde a quel display per essere visualizzata, funzionare correttamente e mantenere la compatibilità se un'attività viene avviata sul display secondario.

Se le implementazioni del dispositivo consentono l'avvio di Android Activities normali su 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. Tutti possono avviare una visualizzazione con il flag android.view.Display.FLAG_PUBLIC.

3.3. Compatibilità con l'API nativa

La compatibilità del codice nativo è difficile. Per questo motivo, gli implementatori di dispositivi:

[C-SR-1] VIVAMENTE CONSIGLIATO di utilizzare le implementazioni delle librerie elencate di seguito dal progetto Android Open Source Project upstream.

3.3.1. Application Binary Interfaces

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 dipende molto dalla tecnologia del processore sottostante, Android definisce una serie di interfacce Application Binary Interface (ABI) nell'Android NDK.

Implementazioni del dispositivo:

[C-0-1] DEVE essere compatibile con una o più ABI NDK per Android definite.
[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 l'origine (ovvero con l'intestazione) e compatibile a livello binario (per l'ABI) con ogni libreria richiesta nell'elenco di seguito.
[C-0-5] DEVE segnalare con precisione l'Application Binary Interface (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, ognuno dei quali è un elenco di ABI separati da virgole e ordinati da quello preferito a quello meno preferito.
[C-0-6] DEVE segnalare, tramite i parametri sopra indicati, un sottoinsieme del seguente elenco di ABI e NON DEVE segnalare ABI non presenti nell'elenco.
- armeabi (non più supportato come target dall'NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
- riscv64
[C-0-7] DEVE rendere disponibili alle app che includono codice nativo tutte le seguenti librerie, che forniscono API native:
- libaaudio.so (supporto audio nativo AAudio)
- libamidi.so (supporto MIDI nativo, se la funzionalità android.software.midi è rivendicata come descritto nella Sezione 5.9)
- libandroid.so (supporto dell'attività Android nativa)
- libc (libreria C)
- libcamera2ndk.so
- libdl (dynamic linker)
- libEGL.so (gestione nativa della superficie OpenGL)
- 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 media native)
- libm (libreria matematica)
- libneuralnetworks.so (API Neural Networks)
- 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] DEVE 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 superiore, in quanto sono riservate.
[C-0-11] DEVE esportare tutti i simboli di funzione OpenGL ES 3.1 e Android Extension Pack, come definiti nell'NDK, tramite la libreria libGLESv3.so. Tieni presente che, sebbene tutti i simboli DEBBANO essere presenti, la sezione 7.1.4.1 descrive in modo più dettagliato i requisiti per quando è prevista l'implementazione completa di ciascuna funzione corrispondente.
[C-0-12] MUST export function symbols for the core Vulkan 1.1 function symbols, as well as the VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, and VK_KHR_get_physical_device_properties2 extensions through the libvulkan.so library. Tieni presente che, sebbene tutti i simboli DEBBANO essere presenti, la sezione 7.1.4.2 descrive in modo più dettagliato i requisiti per quando è prevista l'implementazione completa di ciascuna funzione corrispondente.
DEVE essere creato utilizzando il codice sorgente e i file di intestazione disponibili nel progetto Android Open Source Project upstream.

Tieni presente che le versioni future di Android potrebbero introdurre il supporto per ABI aggiuntive.

3.3.2. Compatibilità del codice nativo ARM a 32 bit

Se le implementazioni dei dispositivi segnalano il supporto dell'ABI armeabi:

[C-3-1] DEVE supportare anche armeabi-v7a e segnalare il relativo supporto, in quanto armeabi è solo per la compatibilità con le versioni precedenti delle app.

Se le implementazioni dei dispositivi segnalano il supporto dell'ABI armeabi-v7a, per le app che utilizzano questa ABI:

[C-2-1] MUST include the following lines in /proc/cpuinfo, and SHOULD NOT alter the values on the same device, even when they are read by other ABIs.
- Features:, seguito da un elenco di eventuali funzionalità della CPU ARMv7 opzionali supportate dal dispositivo.
- CPU architecture:, seguito da un numero intero che descrive l'architettura ARM più elevata supportata dal dispositivo (ad es. "8" per i dispositivi ARMv8).
[C-2-2] DEVE sempre mantenere disponibili le seguenti operazioni, anche nel caso in cui l'ABI sia implementata su un'architettura ARMv8, tramite il supporto della CPU nativa o l'emulazione software:
- Istruzioni per SWP e SWPB.
- Operazioni di barriera CP15ISB, CP15DSB e CP15DMB.
[C-2-3] DEVE includere il supporto dell'estensione Advanced SIMD (nota anche come NEON).

3.4. Compatibilità web

3.4.1. Compatibilità di WebView

Se le implementazioni del dispositivo forniscono un'implementazione completa dell'API android.webkit.Webview:

[C-1-1] MUST report android.software.webview.
[C-1-2] DEVE utilizzare la build del progetto Chromium dal progetto Android Open Source Project upstream nel ramo Android 17 per l'implementazione dell'API android.webkit.WebView.
[C-1-3] La stringa user agent segnalata da WebView per le app che hanno come target il livello SDK 35 e precedenti DEVE essere nel seguente formato:

Mozilla/5.0 (Linux; Android $(VERSION); \[$(MODEL)\] \[Build/$(BUILD)\]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- Il valore della stringa $(VERSION) DEVE essere uguale al valore di android.os.Build.VERSION.RELEASE.
- La stringa $(MODEL) PUÒ essere vuota, ma se non lo è DEVE avere lo stesso valore di android.os.Build.MODEL.
- "Build/$(BUILD)" PUÒ essere omesso, ma se presente la 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 Android Open Source Project upstream.
- Le implementazioni del dispositivo POSSONO omettere Mobile nella stringa user agent.
Il componente WebView DEVE includere il supporto per il maggior numero possibile di funzionalità HTML5 e, se supporta la funzionalità, DEVE essere conforme alla specifica HTML5.
[C-1-4] DEVE eseguire il rendering dei contenuti forniti o dei contenuti dell'URL remoto in un processo distinto dall'applicazione che crea l'istanza di WebView. In particolare, il processo di rendering separato DEVE avere privilegi inferiori, essere eseguito come ID utente separato, non avere accesso alla directory dei dati dell'app, non avere accesso diretto alla rete e avere accesso solo ai servizi di sistema minimi richiesti tramite Binder. L'implementazione AOSP di WebView soddisfa questo requisito.

[C-1-5] La stringa user agent predefinita del sistema segnalata da WebView per le app che hanno come target il livello SDK 36 e versioni successive DEVE avere il seguente formato:
```
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) ; wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
$(CHROMIUM_MAJOR_VER).0.0.0 Mobile Safari/537.36
```
- $(VERSION) DEVE essere il valore statico 10.
- $(MODEL) DEVE essere la lettera statica K.
- $(CHROMIUM_MAJOR_VER) DEVE essere la versione principale di Chromium nell'Android Open Source Project upstream.
- Le implementazioni del dispositivo POSSONO omettere Mobile nella stringa user agent.

Tieni presente che se le implementazioni del dispositivo sono a 32 bit o dichiarano il flag di funzionalità android.hardware.ram.low, sono esenti da C-1-3.

3.4.2. Compatibilità dei browser

Se le implementazioni dei dispositivi includono un'applicazione browser autonoma per la navigazione generale sul web:

[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 passando a favorire IndexedDB rispetto a webstorage, IndexedDB dovrebbe diventare un componente obbligatorio in una versione futura di Android.
POTREBBE spedire una stringa user agent personalizzata nell'applicazione browser autonoma.
DEVE implementare il supporto per la maggior parte di HTML5 possibile nell'applicazione browser autonoma (basata sull'applicazione browser WebKit upstream o su una sostituzione di terze parti).

Tuttavia, se le implementazioni del dispositivo non includono un'applicazione browser autonoma,

[C-2-1] DEVE comunque supportare i pattern di intent pubblici descritti nella sezione 3.2.3.1.

3.5. Compatibilità comportamentale delle API

Implementazioni del dispositivo:

[C-0-9] DEVE garantire che la compatibilità comportamentale delle API venga applicata a tutte le app installate, a meno che non siano limitate come descritto nella Sezione 3.5.1.
[C-0-10] NON DEVE implementare l'approccio di allowlisting che garantisce la compatibilità comportamentale dell'API solo per le app selezionate dagli implementatori di dispositivi.

I comportamenti di ciascun tipo di API (gestita, soft, nativa e web) devono essere coerenti con l'implementazione preferita del progetto Android Open Source Project. Alcune aree specifiche di compatibilità sono:

[C-0-1] I dispositivi NON DEVONO modificare il comportamento o la semantica di un intent standard.
[C-0-2] I dispositivi NON DEVONO alterare il ciclo di vita o la semantica del ciclo di vita di un particolare 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 alterare le limitazioni imposte 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 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 ricevitori di trasmissioni per le trasmissioni implicite di intent standard di Android nel 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, come se l'app avesse chiamato il metodo stopSelf() dei servizi, a meno che l'app non sia inserita in un elenco consentito temporaneo 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 che detiene.
[C-0-11] I dispositivi DEVONO restituire i seguenti provider di sicurezza come primi sette valori dell'array del metodo Security.getProviders(), nell'ordine indicato e con i nomi indicati (come restituiti da Provider.getName()) e le classi, a meno che l'app non abbia modificato l'elenco tramite insertProviderAt() o removeProvider(). I dispositivi POTREBBERO restituire fornitori aggiuntivi dopo l'elenco specificato di fornitori di seguito.
1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
3. CertPathProvider - sun.security.provider.CertPathProvider
4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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

3.5.1. Limitazione dell'applicazione

Se le implementazioni dei dispositivi implementano un meccanismo proprietario per limitare le app (ad es. modificando o limitando i comportamenti delle API descritti nell'SDK) e questo meccanismo è più restrittivo del bucket di standby delle app con limitazioni, le implementazioni:

[C-1-1] DEVE consentire all'utente di visualizzare l'elenco delle app con limitazioni.
[C-1-2] DEVE fornire all'utente la possibilità di attivare / disattivare tutte queste limitazioni proprietarie su ogni app.
[C-1-3] NON DEVE applicare automaticamente queste limitazioni proprietarie senza prove di un comportamento di integrità del sistema scadente, ma PUÒ applicare le limitazioni alle app al rilevamento di un comportamento di integrità del sistema scadente, come wakelock bloccati, servizi a esecuzione prolungata e altri criteri. I criteri POSSONO essere determinati dagli implementatori del dispositivo, ma DEVONO essere correlati all'impatto dell'app sulla salute del sistema. Altri criteri non puramente correlati all'integrità del sistema, come la mancanza di popolarità dell'app sul mercato, NON DEVONO essere utilizzati come criteri.
[C-1-4] NON DEVE applicare automaticamente queste limitazioni proprietarie per le app quando un utente ha disattivato manualmente le limitazioni delle app e PUÒ suggerire all'utente di applicare queste limitazioni proprietarie.
[C-1-5] DEVE informare gli utenti se queste limitazioni proprietarie vengono applicate automaticamente a un'app. Queste informazioni DEVONO essere fornite nel periodo di 24 ore precedente l'applicazione di queste limitazioni proprietarie.
[C-1-6] DEVE restituire true per il metodo ActivityManager.isBackgroundRestricted() per qualsiasi chiamata API da un'app.
[C-1-7] NON DEVE limitare l'app in primo piano principale utilizzata esplicitamente dall'utente.
[C-1-8] DEVE sospendere queste restrizioni proprietarie su un'app ogni volta che un utente inizia a utilizzare esplicitamente l'app, rendendola l'applicazione in primo piano principale.
[C-1-10] DEVE fornire un documento o un sito web pubblico e chiaro che descriva come vengono applicate le limitazioni proprietarie. Questo documento o sito web DEVE essere collegabile dai documenti dell'SDK Android e DEVE includere:
- Condizioni di attivazione per le limitazioni proprietarie.
- Cosa e come può essere limitata un'app.
- Come un'app può essere esentata da queste limitazioni.
- Come un'app può richiedere un'esenzione dalle limitazioni proprietarie, se supporta tale esenzione per le app che l'utente può installare.

Se un'app è preinstallata sul dispositivo e non è mai stata utilizzata esplicitamente da un utente per più di 30 giorni, [C-1-3] [C-1-5] sono esenti.

Se le implementazioni dei dispositivi estendono le limitazioni delle app implementate in AOSP:

[C-2-1]DEVE seguire l'implementazione descritta in questo documento.

3.5.2. Ibernazione delle applicazioni

Se le implementazioni del dispositivo includono la funzionalità di ibernazione delle app inclusa in AOSP o estendono la funzionalità inclusa in AOSP, allora:

[C-1-1] DEVE soddisfare tutti i requisiti della sezione 3.5.1, ad eccezione di [C-1-6] e [C-1-3].
[C-1-2] DEVE applicare la limitazione all'app per un utente solo quando esiste la prova che l'utente non ha utilizzato l'app per un determinato periodo di tempo. È VIVAMENTE CONSIGLIATO che questa durata sia di almeno un mese. L'utilizzo DEVE essere definito dall'interazione utente esplicita tramite l'API UsageStats#getLastTimeVisible() o da qualsiasi azione che farebbe uscire un'app dallo stato di arresto forzato, inclusi i binding di servizi, i binding di provider di contenuti, le trasmissioni esplicite e così via, che verranno monitorati da una nuova API UsageStats#getLastTimeAnyComponentUsed().
[C-1-3] DEVE applicare restrizioni che interessano tutti gli utenti del dispositivo solo quando è dimostrato che il pacchetto non è stato utilizzato da NESSUN utente per un determinato periodo di tempo. È VIVAMENTE CONSIGLIATO che questa durata sia di almeno un mese.
[C-1-4] NON DEVE impedire all'app di rispondere a intent di attività, binding di servizi, richieste di fornitori di contenuti o trasmissioni esplicite.

La funzionalità di ibernazione delle app in AOSP soddisfa i requisiti sopra indicati.

3.6. API Namespaces

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

java.*
javax.*
sun.*
android.*
androidx.*
com.android.*

ovvero:

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

Gli implementatori di dispositivi POSSONO modificare l'implementazione sottostante delle API, ma tali 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 di 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 allo spazio dei nomi com.google.* o a uno simile: solo Google può farlo. Allo stesso modo, Google NON DEVE aggiungere API agli spazi dei nomi di altre società.
[C-0-6] DEVE essere incluso in una libreria condivisa Android in modo che solo le app che le utilizzano esplicitamente (tramite il meccanismo <uses-library>) siano interessate dall'aumento della memoria utilizzata di queste API.

Gli implementatori di dispositivi POSSONO aggiungere API personalizzate in linguaggi nativi, al di fuori delle API NDK, ma le API personalizzate:

[C-1-1] NON DEVE trovarsi in una libreria NDK o in una libreria di proprietà di un'altra organizzazione, come descritto qui.

Se un implementatore di dispositivi propone di migliorare uno degli spazi dei nomi dei pacchetti sopra (ad esempio aggiungendo una nuova funzionalità utile a un'API esistente o aggiungendo una nuova API), l'implementatore DOVREBBE visitare source.android.com e iniziare la procedura per contribuire con modifiche e codice, in base alle informazioni presenti sul sito.

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

3.7. Compatibilità del runtime

Implementazioni del dispositivo:

[C-0-1] DEVE supportare il formato Dalvik Executable (DEX) completo e la specifica e la semantica del bytecode Dalvik.
[C-0-2] MUST configure Dalvik runtimes to allocate memory in accordance with the upstream Android platform, and as specified by the following table. (Consulta la sezione 7.1.1 per le definizioni di dimensioni e 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 fuzz in varie modalità di esecuzione e architetture di destinazione per garantire la stabilità del runtime. Consulta JFuzz e DexFuzz nel 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 POSSONO allocare più memoria per applicazione.

Layout schermo	Densità schermo	Memoria minima dell'applicazione
Orologio Android	120 dpi (ldpi)	32 MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)	36MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)	48MB
	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)	32 MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)	48MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)	80MB
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128 MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256 MB
grande	120 dpi (ldpi)	32 MB
	140 dpi (140dpi)	48MB
	160 dpi (mdpi)	48MB
	180 dpi (180dpi)	80MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi (xhdpi)	128 MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256 MB
	560 dpi (560dpi)	384 MB
	640 dpi (xxxhdpi)	512 MB
xlarge	120 dpi (ldpi)	48MB
	140 dpi (140dpi)	80MB
	160 dpi (mdpi)	80MB
	180 dpi (180dpi)	96MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	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)	384 MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768 MB

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

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

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

[C-1-1] DEVE 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 blocco delle scorciatoie in-app, queste:

[C-2-1] DEVE segnalare true per ShortcutManager.isRequestPinShortcutSupported().
[C-2-2] DEVE avere un'opzione che chiede all'utente prima di aggiungere una scorciatoia richiesta dalle app tramite il metodo API ShortcutManager.requestPinShortcut().
[C-2-3] DEVE supportare le scorciatoie bloccate e quelle dinamiche e statiche come documentato nella pagina Scorciatoie app.

Al contrario, se le implementazioni del dispositivo non supportano il blocco in-app delle scorciatoie:

[C-3-1] DEVE segnalare false per ShortcutManager.isRequestPinShortcutSupported().

Se le implementazioni dei dispositivi implementano un launcher predefinito che fornisce un accesso rapido alle scorciatoie aggiuntive fornite da app di terze parti tramite l'API ShortcutManager, queste:

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

Se le implementazioni del dispositivo includono un'app di avvio predefinita che mostra i badge per le icone delle app, queste:

[C-5-1] DEVE rispettare il metodo API NotificationChannel.setShowBadge(). In altre parole, mostra un ausilio visivo associato all'icona dell'app se il valore è impostato su true e non mostrare alcuno schema di badge dell'icona dell'app quando tutti i canali di notifica dell'app hanno impostato il valore su false.
POSSONO 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 DEVONO 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().

Se le implementazioni dei dispositivi supportano le icone monocromatiche, queste icone:

[C-6-1] MUST be used only when a user explicitly enables them (e.g., via Settings or wallpaper picker menu).

3.8.2. Widget

Android supporta i widget delle app di terze parti definendo un tipo di componente e l'API e il 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] DEVE dichiarare il supporto per la funzionalità della piattaforma android.software.app_widgets.
[C-1-2] DEVE includere il supporto integrato per gli AppWidget ed esporre le funzionalità dell'interfaccia utente per aggiungere, configurare, visualizzare l'anteprima, rimuovere, visualizzare e ridimensionare gli AppWidget a meno che non sia a rischio la sicurezza dell'utente (ad esempio,distrazione del conducente).

[C-1-3] DEVE essere in grado di eseguire il rendering di widget di dimensioni 4 x 4 nella dimensione della griglia standard. Per ulteriori dettagli, consulta le linee guida per la progettazione dei widget per app nella documentazione dell'SDK Android.

[C-1-4] DEVE supportare le anteprime dei widget generate dinamicamente.
[C-1-5] DEVE avere un'interfaccia utente con l'anteprima che chiede all'utente prima di aggiungere un widget richiesto dalle app tramite AppWidgetManager.requestPinAppWidget().
[C-1-6] DEVE supportare l'aggiunta dei widget in-app.
[C-1-7] DEVE segnalare true per AppWidgetManager.html.isRequestPinAppWidgetSupported().

POTREBBE supportare i widget delle applicazioni nella schermata di blocco.

Se le implementazioni dei dispositivi supportano i widget delle app di terze parti e il blocco delle scorciatoie nelle app:

[C-2-1] DEVE segnalare true per AppWidgetManager.html.isRequestPinAppWidgetSupported().
[C-2-2] DEVE avere un'interfaccia utente che chieda all'utente prima di aggiungere una scorciatoia richiesta dalle app tramite il metodo API AppWidgetManager.requestPinAppWidget().

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. suono, vibrazione e luce) e le funzionalità software (ad es. area 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 notificare agli utenti eventi importanti, queste:

[C-1-1] DEVE supportare le notifiche che utilizzano le funzionalità hardware, come descritto nella documentazione dell'SDK e nella misura possibile con l'hardware di implementazione del dispositivo. Ad esempio, se l'implementazione di un dispositivo include un vibratore, DEVE implementare correttamente le API di vibrazione. Se un'implementazione di un dispositivo non dispone di hardware, le API corrispondenti DEVONO essere implementate come no-op. Questo comportamento è descritto in dettaglio nella sezione 7.
[C-1-2] DEVE eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) fornite nelle API o nella guida di stile delle icone della barra di stato/di sistema, anche se PUÒ fornire 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 documentata nell'SDK.
[C-1-5] DEVE fornire un'opzione per bloccare e modificare la notifica di una determinata app di terze parti per ogni canale e livello di pacchetto applicativo.
[C-1-6] DEVE inoltre fornire un'interfaccia utente per visualizzare i canali di notifica eliminati.
[C-1-7] DEVE eseguire il rendering corretto di tutte le risorse (immagini, adesivi, icone e così via) fornite tramite Notification.MessagingStyle insieme al testo della notifica senza interazione aggiuntiva dell'utente. Ad esempio, DEVONO mostrare tutte le risorse, incluse le icone fornite tramite android.app.Person in una conversazione di gruppo impostata tramite setGroupConversation.
[C-SR-1] È VIVAMENTE CONSIGLIATO di fornire all'utente uno strumento per controllare le notifiche esposte alle app a cui è stata concessa l'autorizzazione di ascolto delle notifiche. La granularità DEVE essere tale che l'utente possa controllare per ogni listener di notifiche quali tipi di notifiche vengono trasferiti a questo listener. I tipi DEVONO includere le notifiche "conversazioni", "avvisi", "silenziose" e "costanti importanti".
[C-SR-2] È VIVAMENTE CONSIGLIATO fornire agli utenti la possibilità di specificare le app da escludere dalla notifica di qualsiasi listener di notifiche specifico.
[C-SR-3] È VIVAMENTE CONSIGLIATO di mostrare automaticamente una funzionalità utente per bloccare la notifica di una determinata app di terze parti per ogni canale e livello di pacchetto dell'app dopo che l'utente ha chiuso la notifica più volte.
DEVE supportare le notifiche avanzate.
DOVREBBE presentare alcune notifiche con priorità più elevata come notifiche di avviso.
DOVREBBE avere un'opzione per posticipare le notifiche.
PUÒ gestire solo la visibilità e la tempistica di quando le app di terze parti possono notificare agli utenti eventi importanti per mitigare problemi di sicurezza come la distrazione del conducente.

Android 11 introduce il supporto per le notifiche di conversazione, ovvero notifiche che utilizzano MessagingStyle e forniscono un ID scorciatoia Persone pubblicato.

Implementazioni del dispositivo:

[C-SR-4] È FORTEMENTE CONSIGLIATO raggruppare e visualizzare conversation notifications prima delle notifiche non di conversazione, ad eccezione delle notifiche di servizi in primo piano in corso e delle notifiche importance:high.

Se le implementazioni del dispositivo supportano conversation notifications e l'app fornisce i dati richiesti per bubbles,

[C-SR-5] È FORTEMENTE CONSIGLIATO di visualizzare questa conversazione come bolla. L'implementazione AOSP soddisfa questi requisiti con l'UI di sistema, le impostazioni e il launcher predefiniti.

Se le implementazioni dei dispositivi supportano le notifiche avanzate:

[C-2-1] DEVE utilizzare le risorse esatte fornite tramite la classe API Notification.Style e le relative sottoclassi per gli elementi risorsa presentati.
DEVE presentare ogni elemento risorsa (ad es. icona, titolo e testo di riepilogo) definito nella classe API Notification.Style e nelle relative sottoclassi.

Le notifiche di avviso sono notifiche che vengono presentate all'utente man mano che arrivano, indipendentemente dalla superficie su cui si trova. Se le implementazioni dei dispositivi supportano le notifiche in primo piano, queste:

[C-3-1] DEVE utilizzare la visualizzazione e le risorse delle notifiche in evidenza come descritto nella classe API Notification.Builder quando vengono presentate le notifiche in evidenza.
[C-3-2] DEVE mostrare le azioni fornite tramite Notification.Builder.addAction() insieme ai contenuti della notifica senza ulteriori interazioni dell'utente come descritto nell'SDK.

3.8.3.2. Servizio listener di notifiche

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

Implementazioni del dispositivo:

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

Se le implementazioni dei dispositivi prevedono una funzionalità per posticipare le notifiche, queste:

[C-1-1] DEVE riflettere correttamente lo stato della notifica posticipata tramite le API standard come NotificationListenerService.getSnoozedNotifications().
[C-1-2] DEVE 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 (Do Not Disturb, Non disturbare) / Modalità Priorità

Se le implementazioni dei dispositivi supportano la funzionalità Non disturbare (chiamata anche modalità Priorità):

[C-1-1] DEVE, quando l'implementazione del dispositivo ha fornito un mezzo per l'utente di concedere o negare alle app di terze parti l'accesso alla configurazione delle norme DND, mostrare le regole DND automatiche create dalle applicazioni insieme alle regole create dall'utente e predefinite.
[C-1-3] DEVE rispettare i valori di suppressedVisualEffects trasmessi tramite NotificationManager.Policy e, se un'app ha impostato uno dei flag SUPPRESSED_EFFECT_SCREEN_OFF o SUPPRESSED_EFFECT_SCREEN_ON, DOVREBBE indicare all'utente che gli effetti visivi sono disattivati nel menu delle impostazioni Non disturbare.

3.8.3.4. Protezione delle notifiche sensibili

Le informazioni sensibili delle notifiche includono contenuti come password monouso, codici di conferma monouso e codici di autenticazione o reimpostazione simili che possono essere visualizzati nelle notifiche agli utenti.

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

[C-1-1] DEVONO essere oscurate le informazioni sensibili delle notifiche prima di essere trasmesse ai listener di notifiche, a meno che il servizio listener non sia uno dei seguenti:
- App firmate dal sistema con un uid < 10000
- UI di sistema
- Shell
- App complementare designata (definita da CompanionDeviceManager)
- Ruolo SYSTEM_AUTOMOTIVE_PROJECTION
- Ruolo SYSTEM_NOTIFICATION_INTELLIGENCE
- Ruolo HOME

L'implementazione AOSP di NotificationAssistantServices esemplifica e soddisfa questi requisiti. Per un esempio, vedi android.ext.services.notification.

3.8.4. API Assist

Android include le API Assist per consentire alle applicazioni di scegliere la quantità di informazioni del contesto attuale da condividere con l'assistente sul dispositivo.

Se le implementazioni dei dispositivi supportano l'azione Assist,

[C-2-1] DEVE indicare chiaramente all'utente finale quando il contesto viene condiviso, tramite:
- Ogni volta che l'app di assistenza accede al contesto, viene visualizzata una luce bianca intorno ai bordi dello schermo che soddisfano o superano la durata e la luminosità dell'implementazione di Android Open Source Project.
- Per l'app di assistenza preinstallata, fornire un'agevolazione per l'utente a meno di due navigazioni di distanza dal menu delle impostazioni dell'app di assistenza e dell'input vocale predefinito, e condividere il contesto solo quando l'app di assistenza viene richiamata esplicitamente dall'utente tramite una hotword o un input del tasto di navigazione dell'assistente.

[C-2-1] DEVE condividere il contesto con l'app di assistenza solo quando l'app viene richiamata esplicitamente dall'utente tramite l'input del tasto di navigazione dell'assistente, una hotword o un altro punto di accesso designato.

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

3.8.5. Avvisi e notifiche di tipo toast

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

Se le implementazioni del dispositivo includono uno schermo o un'uscita video:

[C-1-1] DEVE fornire un'opzione per impedire a un'app di visualizzare finestre di avviso che utilizzano TYPE_APPLICATION_OVERLAY. L'implementazione AOSP soddisfa questo requisito disponendo di controlli nell'area notifiche.
[C-1-2] DEVE rispettare l'API Toast e mostrare i toast delle applicazioni agli utenti finali in modo ben 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 l'aspetto del tema Holo come definito dall'SDK Android.

Se le implementazioni del dispositivo includono uno schermo o un'uscita video:

[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 delle relative risorse esposte alle applicazioni.
[C-1-3] DEVE impostare la famiglia di caratteri "sans-serif" su Roboto versione 2.x per le lingue supportate da Roboto oppure fornire un'agevolazione per l'utente per modificare il carattere utilizzato per la famiglia di caratteri "sans-serif" in Roboto versione 2.x per le lingue supportate da Roboto.
[C-1-4] DEVE generare tavolozze di tonalità di colore dinamiche come specificato nella documentazione AOSP di Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (vedi android.theme.customization.system_palette e android.theme.customization.theme_style).
[C-1-5] DEVE generare tavolozze di tonalità di colore dinamiche utilizzando gli stili del tema cromatico enumerati nella documentazione di Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (vedi android.theme.customization.theme_styles), ovvero TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD eMONOCHROMATIC.

"Colore di origine" utilizzato per generare tavolozze di tonalità di colore dinamiche se inviato con android.theme.customization.system_palette (come documentato in Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).
[C-1-6] DEVE avere un valore di croma CAM16 pari o superiore a 5.
- DEVE essere derivato dallo sfondo tramite com.android.systemui.monet.ColorScheme#getSeedColors, che fornisce più colori di origine validi tra cui scegliere.
- DEVE utilizzare il valore 0xFF1B6EF3 se nessuno dei colori forniti soddisfa il requisito del colore di origine sopra indicato.

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 definito dall'implementatore del dispositivo.

Le implementazioni del dispositivo POSSONO modificare gli attributi del tema predefinito del dispositivo esposti alle applicazioni.

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

Se le implementazioni del dispositivo includono una barra di stato del sistema:

[C-2-1] DEVE utilizzare il bianco per le icone di stato del sistema (ad esempio intensità del segnale e livello batteria) e le notifiche emesse dal sistema, a meno che l'icona non indichi uno stato problematico o un'app richieda una barra di stato chiara utilizzando il flag WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
[C-2-2] Le implementazioni dei dispositivi Android DEVONO cambiare il colore delle icone di stato del sistema in nero (per i dettagli, consulta R.style) quando un'app richiede una barra di stato chiara.

3.8.7. Sfondi animati

Android definisce un tipo di componente e API e 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 visualizzati 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 di funzionalità, a un frame rate ragionevole senza effetti negativi su altre applicazioni. Se le limitazioni dell'hardware causano arresti anomali, malfunzionamenti, consumo eccessivo di CPU o batteria o esecuzione a frame rate inaccettabilmente bassi di sfondi e/o applicazioni, l'hardware è considerato incapace di eseguire sfondi animati. Ad esempio, alcuni sfondi animati potrebbero utilizzare un contesto OpenGL 2.0 o 3.x per eseguire il rendering dei contenuti. Lo sfondo animato non verrà eseguito in modo affidabile su hardware che non supporta più contesti OpenGL perché l'utilizzo di un contesto OpenGL da parte dello sfondo animato potrebbe entrare in conflitto con altre applicazioni che utilizzano anch'esse un contesto OpenGL.

Le implementazioni del dispositivo in grado di eseguire sfondi animati in modo affidabile come descritto sopra DEVONO implementare sfondi animati.

Se le implementazioni dei dispositivi implementano sfondi animati:

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

3.8.8. Passaggio da un'attività all'altra

Il codice sorgente Android upstream include la schermata Panoramica, un'interfaccia utente a livello di sistema per il cambio di attività e la visualizzazione di attività e task a cui è stato eseguito l'accesso di recente utilizzando un'immagine in miniatura dello stato grafico dell'applicazione nel momento in cui l'utente l'ha lasciata l'ultima volta.

Le implementazioni del dispositivo, inclusa la chiave di navigazione della funzione Recenti, come descritto nella sezione 7.2.3, POSSONO alterare l'interfaccia.

Se le implementazioni del dispositivo, inclusa la chiave di navigazione della funzione Recenti, come descritto nella sezione 7.2.3, alterano l'interfaccia,

[C-1-1] DEVE supportare almeno fino a 7 attività visualizzate.
DOVREBBE mostrare almeno il titolo di 4 attività alla volta.
DOVREBBE mostrare il colore di evidenziazione, l'icona e il titolo della schermata in Recenti.
DEVE mostrare un indicatore di chiusura ("x"), ma PUÒ ritardare questa operazione finché l'utente non interagisce con le schermate.
DEVE implementare una scorciatoia per passare facilmente all'attività precedente.
DEVE attivare il cambio rapido tra le due app utilizzate più di recente quando il tasto funzione Recenti viene toccato due volte.
DOVREBBE attivare la modalità multi-finestra a schermo diviso, se supportata, quando viene premuto a lungo il tasto delle funzioni recenti.
POTREBBE mostrare i recenti affiliati come un gruppo che si sposta insieme.
[C-SR-1] È FORTEMENTE CONSIGLIATO di utilizzare l'interfaccia utente Android upstream (o un'interfaccia simile basata su miniature) per la schermata di panoramica.

3.8.9. Input Management

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

Se le implementazioni dei dispositivi 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.

3.8.10. Controllo dei contenuti multimediali nella schermata di blocco

L'API Remote Control Client è ritirata da Android 5.0 a favore del modello di notifica multimediale che consente alle applicazioni multimediali di integrarsi con i controlli di riproduzione visualizzati nella schermata di blocco.

3.8.11. Salvaschermi (precedentemente chiamati Sogni)

Consulta la sezione 3.2.3.5 per le impostazioni dell'intent per configurare i salvaschermo.

3.8.12. Località

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

[C-1-2] DEVE mostrare lo stato attuale della posizione nel menu Posizione all'interno delle Impostazioni.
[C-1-3] NON DEVE mostrare le modalità di localizzazione nel menu Posizione all'interno delle Impostazioni.

3.8.13. Unicode e carattere

Android include il supporto per i caratteri emoji definiti in Unicode 10.0.

Se le implementazioni del dispositivo includono uno schermo o un'uscita video:

[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 pesi: 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 i caratteri latini, greci e cirillici, inclusi gli intervalli Latin Extended A, B, C e D e tutti i glifi nel blocco dei simboli di valuta di Unicode 7.0.
[C-1-3] NON DEVE rimuovere o modificare NotoColorEmoji.tff nell'immagine di sistema. È accettabile aggiungere un nuovo carattere emoji per eseguire l'override delle emoji in NotoColorEmoji.tff.
DEVE supportare le emoji con tonalità della pelle e delle diverse famiglie come specificato nel Unicode Technical Report #51.

Se le implementazioni dei dispositivi includono un IME:

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

Android include il supporto per il rendering dei caratteri del Myanmar. Il Myanmar ha diversi caratteri non conformi a Unicode, comunemente noti come "Zawgyi", per il rendering delle lingue del Myanmar.

Se le implementazioni dei dispositivi includono il supporto del birmano:

[C-2-1] DEVE eseguire il rendering del testo con un carattere conforme a Unicode come predefinito; un carattere non conforme a Unicode NON DEVE essere impostato come predefinito a meno che l'utente non lo scelga nel selettore lingua.
[C-2-2] DEVE supportare un carattere Unicode e un carattere non conforme a Unicode se quest'ultimo è supportato sul dispositivo. Il carattere non conforme a Unicode NON DEVE rimuovere o sovrascrivere il carattere Unicode.
[C-2-3] DEVE eseguire il rendering del testo con un carattere non conforme a Unicode SOLO SE è specificato un codice lingua con codice script Qaag (ad es. my-Qaag). Nessun altro codice ISO per lingua o regione (assegnato, non assegnato o riservato) può essere utilizzato per fare riferimento a un carattere non conforme a Unicode per il Myanmar. Gli sviluppatori di app e gli autori di pagine web possono specificare my-Qaag come codice di lingua designato come farebbero per qualsiasi altra lingua.

3.8.14. Multi-finestra

Se le implementazioni dei dispositivi sono in grado di visualizzare più attività contemporaneamente,

[C-1-1] DEVE implementare una o più modalità multi-finestra in conformità con i comportamenti e le API delle applicazioni descritti nell'SDK Android documentazione sul supporto della modalità multi-finestra e soddisfare i seguenti requisiti:
[C-1-2] Requisito rimosso in Android 16.
[C-1-3] NON DEVE offrire la modalità Split Screen o Freeform se l'altezza dello schermo è inferiore a 440 dp e la larghezza dello schermo è inferiore a 440 dp.
[C-1-4] Un'attività NON DEVE essere ridimensionata a una dimensione inferiore a 220 dp nelle modalità multi-finestra diverse da Picture in Picture.

[C-1-5] DEVONO mostrare le attività con la proprietà selfMovable in piena opacità, con una decorazione persistente distinguibile (ad es. la barra delle didascalie) e un metodo per chiudere queste attività dalle loro decorazioni persistenti.

Le implementazioni del dispositivo con dimensioni dello schermo xlarge DEVONO supportare la modalità a forma libera.

Se le implementazioni dei dispositivi supportano la modalità multi-finestra e la modalità schermo diviso,

[C-2-2] DEVE ritagliare l'attività agganciata di una Multi-finestra in modalità split-screen, ma DEVE mostrare alcuni contenuti se l'app Avvio app è la finestra selezionata.
[C-2-3] DEVE rispettare i valori dichiarati di AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight dell'applicazione di avvio di terze parti e non sostituirli durante la visualizzazione di alcuni contenuti dell'attività agganciata.

Se le implementazioni dei dispositivi supportano la modalità multi-finestra e la modalità multi-finestra Picture in Picture,

[C-3-1] MUST launch activities in picture-in-picture multi-window mode when the app is:
- Targeting del livello API 26 o versioni successive e dichiarazione di android:supportsPictureInPicture
- Targeting del livello API 25 o inferiore e dichiara sia android:resizeableActivity che android:supportsPictureInPicture.
[C-3-2] DEVE esporre le azioni nella SystemUI 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, il tasto DEVE essere disponibile per l'attività in primo piano.
[C-3-5] DEVE fornire un'interfaccia utente per impedire a un'app di essere visualizzata in modalità PIP; l'implementazione AOSP soddisfa questo requisito disponendo di controlli nell'area notifiche.
[C-3-6] DEVE allocare la larghezza e l'altezza minime seguenti per la finestra PIP quando un'applicazione non dichiara alcun valore per AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight:
- I dispositivi con Configuration.uiMode impostato su un valore diverso da UI_MODE_TYPE_TELEVISION DEVONO allocare una larghezza e un'altezza minime di 108 dp.
- I dispositivi con Configuration.uiMode impostato su UI_MODE_TYPE_TELEVISION DEVONO allocare una larghezza minima di 240 dp e un'altezza minima di 135 dp.

Se le implementazioni dei dispositivi includono più aree di visualizzazione compatibili con Android e rendono disponibili queste aree per le app,

[C-4-1] DEVE supportare la modalità multi-finestra.

Se le implementazioni dei dispositivi supportano una o più modalità multi-finestra:

[C-5-1] DEVE implementare la versione corretta del livello API delle estensioni di Window Manager come descritto in WindowManager Estensioni.

3.8.15. Ritaglio display

Android supporta un'area di visualizzazione ritagliata come descritto nel documento SDK. L'API DisplayCutout definisce un'area sul bordo del display che potrebbe non essere funzionale per un'applicazione a causa di un ritaglio display o di un display curvo sui bordi.

Se le implementazioni del dispositivo includono uno o più ritagli display:

[C-1-5] NON DEVE avere intagli se le proporzioni del dispositivo sono 1:1.
[C-1-2] NON DEVE avere più di un intaglio per bordo.
[C-1-3] DEVE rispettare i flag di ritaglio display impostati dall'app tramite l'API WindowManager.LayoutParams come descritto nell'SDK.
[C-1-4] DEVE segnalare i valori corretti per tutte le metriche di ritaglio definite nell'API DisplayCutout.

3.8.16. Controllo dei dispositivi

Android include le API ControlsProviderService e Control per consentire alle applicazioni di terze parti di pubblicare i controlli del dispositivo per lo stato e l'azione rapidi per gli utenti.

Per i requisiti specifici per dispositivo, consulta la sezione 2_2_3.

3.8.17. Appunti

Implementazioni del dispositivo:

[C-0-1] NON DEVE inviare dati degli appunti a nessun componente, attività, servizio o tramite qualsiasi connessione di rete, senza un'azione esplicita dell'utente (ad es. premendo un pulsante sull'overlay) o indicazione dell'invio di contenuti, ad eccezione dei servizi menzionati nella sezione 9.8.6 Acquisizione di contenuti e ricerca di app.

Se le implementazioni del dispositivo generano un'anteprima visibile all'utente quando i contenuti vengono copiati negli appunti per qualsiasi elemento ClipData in cui ClipData.getDescription().getExtras() contiene android.content.extra.IS_SENSITIVE, questi:

[C-1-1] MUST redact the user visible preview

L'implementazione di riferimento AOSP soddisfa questi requisiti degli appunti.

3.8.18. Pulsante Posizione

Il pulsante posizione è un elemento dell'interfaccia utente di Android che gli sviluppatori di app possono incorporare nelle loro app per ottenere una concessione dell'autorizzazione di accesso alla posizione esatta per la sessione dell'app.

Implementazioni del dispositivo:

[C-0-1] NON DEVE aggiungere, modificare o rimuovere le opzioni di personalizzazione fornite agli sviluppatori di app per il pulsante posizione.

3.9. Amministrazione dispositivo

Android include funzionalità che consentono ai controller di policy dei dispositivi di eseguire funzioni di amministrazione dei dispositivi a livello di sistema, come l'applicazione di criteri per le password o l'esecuzione della cancellazione da remoto, tramite le API Device Policy Manager.

3.9.1. Provisioning dispositivo

3.9.1.1. Provisioning del proprietario del dispositivo

Se le implementazioni dei dispositivi dichiarano android.software.device_admin:

[C-1-1] DEVE supportare la registrazione di un controller di policy dei dispositivi (DPC) come app proprietario del dispositivo come descritto di seguito:
- Quando l'implementazione del dispositivo non ha configurato né utenti né dati utente,
  - [C-1-5] DEVE registrare l'applicazione DPC come app Proprietario del dispositivo o consentire all'app DPC di scegliere se diventare Proprietario del dispositivo o Proprietario del profilo, se il dispositivo dichiara il supporto della tecnologia Near Field Communication (NFC) tramite il flag di funzionalità android.hardware.nfc e riceve un messaggio NFC contenente un record con tipo MIME MIME_TYPE_PROVISIONING_NFC.
  - [C-1-8] DEVE inviare l'intent ACTION_GET_PROVISIONING_MODE dopo l'attivazione del provisioning del proprietario del dispositivo, in modo che l'app DPC possa scegliere se diventare proprietario del dispositivo o proprietario del profilo, a seconda dei valori di android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, a meno che non sia possibile determinare dal contesto che esiste una sola opzione valida.
  - [C-1-9] DEVE inviare l'intent ACTION_ADMIN_POLICY_COMPLIANCE all'app Proprietario del dispositivo se viene stabilito un proprietario del dispositivo durante il provisioning, indipendentemente dal metodo di provisioning utilizzato. L'utente non deve poter procedere nella configurazione guidata finché l'app Proprietario del dispositivo non viene completata.
- Quando l'implementazione del dispositivo include utenti o dati utente:
  - [C-1-7] NON deve registrare più alcuna applicazione DPC come app proprietario del dispositivo.
[C-1-2] Requisito rimosso in Android 15.
[C-2-1] Requisito rimosso in Android 15.
[C-2-2] Requisito rimosso in Android 15.
[C-2-3] Requisito rimosso in Android 15.

3.9.1.2. Provisioning dei profili gestiti

Se le implementazioni dei dispositivi dichiarano android.software.managed_users:

[C-1-1] DEVE dichiarare android.software.device_admin e implementare le API che consentono a un'applicazione controller di policy dei dispositivi (DPC) di diventare il proprietario di un nuovo profilo gestito.
[C-1-2] Requisito rimosso in Android 16.
[C-1-3] DEVE fornire i seguenti inviti per l'utente all'interno delle Impostazioni per indicare all'utente quando una particolare funzione di sistema è stata disattivata dal controller di policy dei dispositivi (DPC):
- Un'icona coerente o un altro elemento di interazione con l'utente (ad esempio l'icona delle informazioni AOSP upstream) per indicare quando una determinata impostazione è limitata da un amministratore del dispositivo.
- Un breve messaggio di spiegazione, fornito dall'amministratore del dispositivo tramite setShortSupportMessage.
- L'icona dell'applicazione DPC.
[C-1-4] DEVE avviare il gestore per l'intent ACTION_PROVISIONING_SUCCESSFUL nel profilo di lavoro se viene stabilito un proprietario del profilo quando il provisioning viene avviato dall'intent android.app.action.PROVISION_MANAGED_PROFILE e il DPC ha implementato il gestore.
[C-1-5] DEVE inviare ACTION_PROFILE_PROVISIONING_COMPLETE trasmissione al DPC del profilo di lavoro quando il provisioning viene avviato dall'intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] DEVE inviare l'intent ACTION_GET_PROVISIONING_MODE dopo l'attivazione del provisioning del proprietario del profilo in modo che l'app DPC possa scegliere se diventare proprietario del dispositivo o proprietario del profilo, tranne quando il provisioning viene attivato dall'intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] DEVE inviare l'intent ACTION_ADMIN_POLICY_COMPLIANCE al profilo di lavoro quando viene stabilito un proprietario del profilo durante il provisioning, indipendentemente dal metodo di provisioning utilizzato, tranne quando il provisioning viene attivato dall'intent android.app.action.PROVISION_MANAGED_PROFILE. L'utente non deve poter procedere nella procedura guidata di configurazione finché l'app Proprietario del profilo non viene completata.
[C-1-8] DEVE inviare ACTION_MANAGED_PROFILE_PROVISIONED trasmissione al DPC del profilo personale quando viene stabilito un proprietario del profilo, indipendentemente dal metodo di provisioning utilizzato.

3.9.2. Supporto dei profili gestiti

Se le implementazioni dei dispositivi dichiarano android.software.managed_users:

[C-1-1] MUST support managed profiles via the android.app.admin.DevicePolicyManager APIs.
[C-1-2] DEVE consentire la creazione di un solo profilo gestito.
[C-1-3] DEVE utilizzare un badge icona (simile al badge aziendale 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 mostrare un'icona di notifica (simile al badge di lavoro upstream AOSP) per indicare quando l'utente si trova all'interno di un'applicazione del profilo gestito.
[C-1-5] DEVE mostrare una notifica toast 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 all'interno del profilo gestito.
[C-1-6] Se esiste un profilo gestito, DEVE mostrare un ausilio visivo 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, DEVONO essere esposte le seguenti funzionalità per l'utente sia per l'utente principale sia per il profilo gestito:
- Contabilità separata per l'utilizzo di batteria, posizione, dati mobili e spazio di archiviazione per l'utente principale e il profilo gestito.
- Gestione indipendente delle applicazioni VPN installate nell'utente principale o nel profilo gestito.
- Gestione indipendente delle applicazioni installate nell'utente principale o nel profilo gestito.
- Gestione indipendente degli account all'interno dell'utente principale o del profilo gestito.
[C-1-8] DEVE garantire che le applicazioni preinstallate di Telefono, contatti e messaggistica possano cercare e consultare le informazioni del chiamante dal profilo gestito (se esistente) insieme a quelle del profilo principale, se il controller di policy dei dispositivi lo consente.
[C-1-9] DEVE garantire di soddisfare 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 garantire che i dati dello screenshot vengano salvati nello spazio di archiviazione del profilo di lavoro quando uno screenshot viene acquisito con una finestra topActivity che ha il focus (quella con cui l'utente ha interagito per ultima tra tutte le attività) e appartiene a un'app del profilo di lavoro.
[C-1-11] NON DEVE acquisire altri contenuti dello schermo (barra di sistema, notifiche o contenuti di profili personali) ad eccezione della finestra/finestre dell'applicazione del profilo di lavoro quando si salva uno screenshot nel profilo di lavoro (per garantire che i dati del profilo personale non vengano salvati nel profilo di lavoro).

Se le implementazioni del dispositivo dichiarano android.software.managed_users e android.software.secure_lock_screen, queste:

[C-2-1] DEVE supportare la possibilità di specificare una schermata di blocco separata che soddisfi i seguenti requisiti per concedere l'accesso solo 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 gestione e archiviazione delle credenziali del profilo genitore, come documentato sul sito del progetto Android Open Source.
- I criteri per le password del DPC DEVONO essere applicati solo alle credenziali della schermata di blocco del profilo gestito, a meno che non venga chiamata l'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 senza risposta, nelle app di messaggistica e contatti, DEVONO essere contrassegnati con lo stesso badge utilizzato per indicare le applicazioni del profilo gestito.

3.9.3. Assistenza per gli utenti gestiti

Se le implementazioni dei dispositivi dichiarano android.software.managed_users:

[C-1-1] DEVE fornire un'opzione per disconnettersi dall'utente corrente e tornare all'utente principale in una sessione multiutente quando isLogoutEnabled restituisce true. L'affordance utente DEVE essere accessibile dalla schermata di blocco senza sbloccare il dispositivo.

Se le implementazioni dei dispositivi dichiarano android.software.device_admin e forniscono un'interfaccia utente sul dispositivo per aggiungere utenti secondari, questi:

[C-SR-1] È VIVAMENTE CONSIGLIATO mostrare le stesse informative sul consenso del proprietario del dispositivo AOSP mostrate nel flusso avviato da android.app.action.PROVISION_MANAGED_DEVICE, prima di consentire l'aggiunta di account nel nuovo utente secondario, in modo che gli utenti comprendano che il dispositivo è gestito.

3.9.4. Requisiti del ruolo di gestione delle norme relative ai dispositivi

Se le implementazioni dei dispositivi dichiarano android.software.device_admin:

[C-1-1] DEVE supportare il ruolo di gestione dei criteri del dispositivo come definito nella sezione 9.1. L'applicazione che detiene il ruolo di gestione dei criteri del dispositivo PUÒ essere definita impostando config_devicePolicyManagement sul nome del pacchetto. Il nome del pacchetto DEVE essere seguito dai due punti (:) e dal certificato di firma, a meno che l'applicazione non sia precaricata.

Se un nome di pacchetto non è definito per config_devicePolicyManagement come descritto sopra:

[C-2-1] Le implementazioni del dispositivo DEVONO supportare il provisioning senza un'applicazione con ruolo di gestione delle norme del dispositivo (AOSP fornisce un'implementazione di riferimento).

Se è definito un nome pacchetto per config_devicePolicyManagement come descritto sopra:

[C-3-1] L'applicazione DEVE essere installata su tutti i profili di un utente.
[C-3-2] Le implementazioni del dispositivo POSSONO definire un'applicazione che aggiorna il titolare del ruolo di gestione delle policy del dispositivo prima del provisioning impostando config_devicePolicyManagementUpdater.

Se per config_devicePolicyManagementUpdater è definito un nome di pacchetto come descritto sopra:

[C-4-1] L'applicazione DEVE essere preinstallata sul dispositivo.
[C-4-2] L'applicazione DEVE implementare un filtro per intent che risolva android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

3.9.5. Framework di risoluzione dei criteri relativi ai dispositivi

Se le implementazioni dei dispositivi dichiarano android.software.device_admin:

[C-1-1] DEVE risolvere i conflitti tra criteri relativi ai dispositivi come descritto nel framework di risoluzione dei criteri relativi ai dispositivi.

3.10. Accessibilità

Android fornisce un livello di accessibilità che aiuta gli utenti con disabilità a navigare più facilmente sui loro dispositivi. Inoltre, Android fornisce API della piattaforma che consentono alle implementazioni dei servizi di accessibilità di ricevere callback per eventi utente e di sistema e generare meccanismi di feedback alternativi, come sintesi vocale, feedback aptico e 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à Android come descritto nella documentazione dell'SDK delle API Accessibility.
[C-1-2] DEVE generare eventi di accessibilità e fornire l'AccessibilityEvent appropriato a tutte le implementazioni AccessibilityService registrate, come documentato nell'SDK.
[C-1-4] DEVE fornire un'interfaccia utente per controllare i servizi di accessibilità che dichiarano AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Tieni presente che per le implementazioni del dispositivo con una barra di navigazione di sistema, gli utenti DEVONO avere la possibilità di utilizzare un pulsante nella barra di navigazione di sistema per controllare questi servizi.

Se le implementazioni dei dispositivi includono servizi di accessibilità preinstallati:

[C-2-1] DEVE implementare questi servizi di accessibilità preinstallati come app compatibili con l'avvio diretto quando l'archiviazione dei dati è criptata con la crittografia basata su file (FBE).
DEVE fornire un meccanismo nel flusso di configurazione predefinito per consentire agli utenti di attivare i servizi di accessibilità pertinenti, nonché opzioni per regolare le dimensioni del carattere, le dimensioni di visualizzazione e i gesti di ingrandimento.

3.11. Text-to-Speech

Android include API che consentono alle applicazioni di utilizzare servizi di sintesi vocale (TTS) e ai fornitori di servizi di fornire implementazioni di servizi TTS.

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

[C-1-1] DEVE supportare le API del framework Android TTS.

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. N/D

3.13. Impostazioni rapide

Android fornisce un componente UI Impostazioni rapide che consente di accedere rapidamente ad azioni utilizzate di frequente o necessarie con urgenza.

Se le implementazioni del dispositivo includono un componente UI Impostazioni rapide e supportano le Impostazioni rapide di terze parti,

[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 da 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 fornite dal sistema.

3.14. UI dei contenuti multimediali

Se le implementazioni del dispositivo includono applicazioni non attivate tramite comandi vocali (le App) che interagiscono con applicazioni di terze parti tramite MediaBrowser o MediaSession, le App:

[C-1-2] DEVONO mostrare chiaramente le icone ottenute tramite getIconBitmap() o getIconUri() e i titoli ottenuti tramite getTitle() come descritto in MediaDescription. Potrebbe abbreviare i titoli per rispettare le normative di sicurezza (ad es. distrazione del conducente).
[C-1-3] DEVE mostrare l'icona dell'applicazione di terze parti ogni volta che vengono visualizzati contenuti forniti da questa applicazione di terze parti.
[C-1-4] DEVE consentire all'utente di interagire con l'intera gerarchia di MediaBrowser. POTREBBE limitare l'accesso a parte della gerarchia per rispettare le norme di sicurezza (ad es. distrazione del conducente), ma NON DEVE dare un trattamento preferenziale in base ai contenuti o al fornitore di contenuti.
[C-1-5] DEVE considerare il doppio tocco di KEYCODE_HEADSETHOOK o KEYCODE_MEDIA_PLAY_PAUSE come KEYCODE_MEDIA_NEXT per MediaSession.Callback#onMediaButtonEvent.

3.15. App istantanee

Se le implementazioni dei dispositivi supportano le app istantanee, DEVONO soddisfare i seguenti requisiti:

[C-1-1] Alle app istantanee DEVONO essere concesse solo autorizzazioni con android:protectionLevel impostato su "instant".
[C-1-2] Le app istantanee NON DEVONO interagire con le app installate tramite intent impliciti a meno che non si verifichi una delle seguenti condizioni:
- Il filtro del pattern di intent del componente è esposto e ha CATEGORY_BROWSABLE
- L'azione è una delle seguenti: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- Il target è esposto in modo esplicito con android:visibleToInstantApps
[C-1-3] Le app istantanee NON DEVONO interagire esplicitamente con le app installate, a meno che il componente non sia esposto tramite android:visibleToInstantApps.
[C-1-4] Le app installate NON DEVONO visualizzare i dettagli sulle app istantanee sul dispositivo, a meno che l'app istantanea non si connetta esplicitamente all'applicazione installata.
Le implementazioni del dispositivo DEVONO fornire le seguenti funzionalità per l'interazione con le app istantanee. L'AOSP soddisfa i requisiti con l'UI di sistema, le impostazioni e l'Avvio app predefiniti. Implementazioni del dispositivo:
- [C-1-5] DEVE fornire un'opzione per visualizzare ed eliminare le app istantanee memorizzate nella cache locale per ogni singolo pacchetto applicativo.
- [C-1-6] DEVE fornire una notifica utente persistente che può essere compressa mentre un'app istantanea è in esecuzione in primo piano. Questa notifica DEVE includere l'informazione che le app istantanee non richiedono l'installazione e fornire un invito che indirizzi l'utente alla schermata delle informazioni sull'applicazione in Impostazioni. Per le app istantanee avviate tramite intent web, come definito dall'utilizzo di un intent con azione impostata su Intent.ACTION_VIEW e con uno schema "http" o "https", un'ulteriore funzionalità per l'utente DEVE consentire all'utente di non avviare l'app istantanea e di avviare il link associato con il browser web configurato, se un browser è disponibile sul dispositivo.
- [C-1-7] DEVE consentire l'accesso alle app istantanee dalla funzione Recenti se questa è disponibile sul dispositivo.
[C-1-8] DEVE precaricare uno o più componenti di applicazioni o servizi con un gestore di intent per gli intent elencati nell'SDK qui e rendere gli intent visibili per le app istantanee.

3.16. Accoppiamento di dispositivi complementari

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 di dispositivi complementari:

[C-1-1] DEVE dichiarare il flag della funzionalità FEATURE_COMPANION_DEVICE_SETUP.
[C-1-2] DEVE garantire che le API nel pacchetto android.companion siano completamente implementate.
[C-1-3] DEVE fornire all'utente la possibilità di selezionare/confermare la presenza e il funzionamento di un dispositivo complementare, che DEVE utilizzare lo stesso messaggio implementato in AOSP senza aggiunte o modifiche.

3.17. App pesanti

Se le implementazioni del dispositivo dichiarano la funzionalità FEATURE_CANT_SAVE_STATE, allora:

[C-1-1] DEVE avere una sola app installata che specifichi cantSaveState in esecuzione nel sistema alla volta. Se l'utente esce da un'app di questo tipo senza chiuderla esplicitamente (ad esempio premendo il tasto Home mentre lascia un'attività attiva nel sistema, anziché premere Indietro senza altre attività attive nel sistema), le implementazioni del dispositivo DEVONO dare la priorità a questa app nella RAM come fanno per altre cose che devono rimanere in esecuzione, come i servizi in primo piano. Mentre un'app di questo tipo è in background, il sistema può comunque applicare funzionalità di gestione dell'alimentazione, come la limitazione dell'accesso alla CPU e alla rete.
[C-1-2] DEVE fornire un'interfaccia utente per scegliere l'app che non parteciperà al normale meccanismo di salvataggio/ripristino dello stato una volta che l'utente avvia una seconda app dichiarata con l'attributo cantSaveState.
[C-1-3] NON DEVE applicare altre modifiche alle norme alle app che specificano cantSaveState, ad esempio la modifica delle prestazioni della CPU o della priorità di pianificazione.

Se le implementazioni del dispositivo non dichiarano la funzionalità FEATURE_CANT_SAVE_STATE, allora:

[C-1-1] DEVE ignorare l'attributo cantSaveState impostato dalle app e NON DEVE modificare il comportamento dell'app in base a questo attributo.

3.18. Contatti

Android include Contacts Provider API per consentire alle applicazioni di gestire le informazioni di contatto memorizzate sul dispositivo. I dati di contatto inseriti direttamente nel dispositivo vengono in genere sincronizzati con un servizio web, ma i dati POSSONO anche risiedere solo localmente sul dispositivo. I contatti memorizzati solo sul dispositivo sono chiamati contatti locali.

RawContacts sono "associati a" o "memorizzati in" un Account quando le colonne ACCOUNT_NAME, e ACCOUNT_TYPE, per i raw contact corrispondono ai campi Account.name e Account.type dell'account.

Account locale predefinito: un account per i contatti non elaborati archiviati solo sul dispositivo e non associati a un account in AccountManager, creati con valori null per le colonne ACCOUNT_NAME e ACCOUNT_TYPE.

Account locale personalizzato: un account per i contatti non elaborati memorizzati solo sul dispositivo e non associati a un account in AccountManager, creati con valori non nulli per le colonne ACCOUNT_NAME e ACCOUNT_TYPE.

Implementazioni del dispositivo:

[C-SR-1] È FORTEMENTE CONSIGLIATO di non creare account locali personalizzati.

Se le implementazioni dei dispositivi utilizzano un account locale personalizzato:

[C-1-1] Il ACCOUNT_NAME, dell'account locale personalizzato DEVE essere restituito entro ContactsContract.RawContacts.getLocalAccountName
[C-1-2] Il ACCOUNT_TYPE, dell'account locale personalizzato DEVE essere restituito da ContactsContract.RawContacts.getLocalAccountType
[C-1-3] I contatti non elaborati inseriti da applicazioni di terze parti senza specificare un account DEVONO essere inseriti nell'account contatti predefinito del dispositivo. Se l'account contatti predefinito è DEFAULT_ACCOUNT_STATE_LOCAL o DEFAULT_ACCOUNT_STATE_NOT_SET, questi contatti non elaborati DEVONO essere archiviati nell'account locale personalizzato.
[C-1-4] I contatti non elaborati inseriti nell'account locale personalizzato NON DEVONO essere rimossi quando gli account vengono aggiunti o rimossi.
[C-1-5] Le operazioni di eliminazione eseguite sull'account locale personalizzato DEVONO comportare l'eliminazione immediata dei contatti grezzi (come se il parametro CALLER_IS_SYNCADAPTER fosse impostato su true), anche se il parametro CALLER_IS_SYNCADAPTER è stato impostato su false o non è stato specificato.

Account SIM: account per i contatti non elaborati sottoposti a mirroring da una o più schede SIM fisiche inserite nel dispositivo e non associati a un account in AccountManager.

Implementazioni del dispositivo:

Se le implementazioni dei dispositivi utilizzano uno o più account SIM:

[C-1-6] Gli account SIM DEVONO essere restituiti entro il giorno ContactsContract.SimContacts.getSimAccounts.

3.18.2. Selettore contatti di sistema

Android include il supporto di un selettore di contatti di sistema che consente alle app di accedere a informazioni di contatto limitate senza richiedere autorizzazioni di accesso estese.

Se le implementazioni dei dispositivi supportano i contatti Android:

[C-1-1] DEVE implementare il Selettore di contatti di sistema (com.android.contactspicker) per le app che hanno come target il livello API 37 o versioni successive.
[C-1-2] DEVE implementare l'intent Intent.ACTION_PICK_CONTACTS.

3.19. Impostazioni lingua

Implementazioni del dispositivo:

[C-0-1] NON DEVE fornire alcuna funzionalità per consentire all'utente di selezionare un trattamento linguistico specifico per il genere per le lingue che non supportano traduzioni specifiche per il genere. Per saperne di più, consulta le risorse grammaticali.

3.20. Esperienze basate sull'assistente

Il framework di sviluppo dell'assistente Android consente il controllo vocale delle app per Android. Con l'assistente, gli utenti possono usare la voce per avviare app, svolgere attività, accedere a contenuti e altro ancora.

Per questa sezione, fai riferimento alle seguenti classificazioni per implementazioni di dispositivi specializzati:

Volume fisso:un dispositivo a volume fisso è un dispositivo con controlli del volume, ma impedisce alle app di modificare il livello del flusso audio utilizzando metodi AudioManagerstandard (ad esempio, le auto con Android Automotive OS).
Volume massimo: un dispositivo a volume massimo è un dispositivo il cui volume è bloccato a un livello massimo e non attenuato e in cui il controllo software è impedito (ad esempio, una TV con altoparlanti esterni).
Volume singolo:un dispositivo a volume singolo è un dispositivo che mappa tutti i flussi audio su un unico flusso di volume, con conseguenti regolazioni del volume che interessano tutti i flussi audio in modo uniforme (ad esempio, una TV).

3.20.1. Requisiti per lo stream audio dell'assistente

Un'applicazione che dispone dell'autorizzazione MANAGE_ASSISTANT_AUDIO:

[C-0-1] DEVE essere consentito modificare il volume di STREAM_ASSISTANT in modo programmatico.

Se le implementazioni del dispositivo non dichiarano android.hardware.type.watch, e non sono a volume fisso, a volume singolo o a volume massimo,

[C-1-1] DEVE implementare STREAM_ASSISTANT come stream audio disaccoppiato e NON DEVE avere alias con altri stream.
[C-1-2] DEVE garantire che la riproduzione audio tramite AudioAttributes con USAGE_ASSISTANT abbia il volume di riproduzione controllato da STREAM_ASSISTANT.
[C-1-3] DEVE garantire che per un determinato headset Bluetooth, l'indice di volume STREAM_ASSISTANT rimanga lo stesso quando l'headset passa dai profili audio A2DP e HFP.
[C-1-4] DEVE impedire a qualsiasi stream diverso da STREAM_ASSISTANT di modificare il volume di STREAM_ASSISTANT o l'attenuazione applicata alla riproduzione di USAGE_ASSISTANT, mentre MODE_ASSISTANT_CONVERSATION è attivo.
[C-1-5] DEVE modificare il volume dello stream STREAM_ASSISTANT e nessun altro volume dello stream quando il volume viene regolato tramite i tasti del volume del dispositivo o della periferica (ad esempio un headset Bluetooth) e quando:
- MODE_ASSISTANT_CONVERSATION è attivo e
- Non sono presenti personalizzazioni specifiche per le app o riproduzione remota attiva.
[C-1-6] DEVE riflettere qualsiasi modifica al volume dell'assistente nell'interfaccia utente.

3.21. Supporto delle funzionalità di sincronizzazione dei dispositivi complementari

Android include il supporto per le funzionalità di sincronizzazione dei dati su tutti i dispositivi complementari.

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

[C-1-1] DEVE implementare l'API ContextualModeManager#isModeSyncSupported.
[C-1-2] DEVE sincronizzare l'impostazione che indica che la modalità Non disturbare è attivata tramite il canale sicuro CompanionDeviceManager utilizzando un formato di dati compatibile con l'implementazione CompanionDeviceManagerService predefinita.
[C-1-3] DEVE abilitare questa sincronizzazione se ContextualModeManager#isModeSyncEnabled restituisce true.

Se le implementazioni dei dispositivi supportano la funzionalità di sincronizzazione della modalità aereo:

[C-1-4] DEVE sincronizzare l'impostazione che indica che la modalità aereo è attivata tramite il canale sicuro CompanionDeviceManager utilizzando un formato dei dati compatibile con l'implementazione CompanionDeviceManagerService predefinita.
[C-1-5] DEVE attivare questa sincronizzazione se Settings.Global.AIRPLANE_MODE_SYNC è attivato.

3.22. API ComputerControls

L'API ComputerControls consente agli agenti supportati di intraprendere azioni autonome e non pianificate per conto dell'utente per completare le attività su un dispositivo Android.

[C-1-1] Se le implementazioni del dispositivo precaricano la libreria di estensioni com.android.extensions.computercontrol per supportare ComputerControl, allora:

DEVI attivare android.software.activities_on_secondary_display.
DEVE mostrare la funzionalità di sistema com.android.extensions.computercontrol come disponibile.
DEVI attivare VirtualDeviceManager.
DEVE includere com.android.extensions.computercontrol nell'elenco restituito da PackageManager#getSharedLibraries().
DEVE precaricare l'applicazione della piattaforma com.android.virtualdevicemanager (target di build VirtualDeviceManager).

4. Compatibilità con la creazione di pacchetti di 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 precedente potrebbe essere difficile da soddisfare, è CONSIGLIATO che le implementazioni dei dispositivi utilizzino il 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 v3.2, lo schema di firma dell'APK v3.1, lo schema di firma dell'APK v3, 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 tale 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'"installer of record" attuale per il pacchetto di disinstallare l'app automaticamente senza alcuna conferma dell'utente, come documentato nell'SDK per l'autorizzazione DELETE_PACKAGE. Le uniche eccezioni sono l'app di verifica dei pacchetti di sistema che gestisce l'intent PACKAGE_NEEDS_VERIFICATION e l'app Gestione archiviazione che gestisce l'intent ACTION_MANAGE_STORAGE.
[C-0-5] DEVE avere un'attività che gestisce l'intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.
[C-0-6] NON DEVE installare pacchetti di applicazioni da fonti sconosciute, a meno che l'app che richiede l'installazione soddisfi tutti i seguenti requisiti:
- DEVE dichiarare l'autorizzazione REQUEST_INSTALL_PACKAGES o avere il valore di android:targetSdkVersion impostato su 24 o inferiore.
- L'utente DEVE aver concesso l'autorizzazione per installare app da origini sconosciute.
DEVE fornire un'interfaccia utente per concedere/revocare l'autorizzazione a installare app da origini sconosciute per applicazione, ma PUÒ 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 avere questa scelta. Tuttavia, anche in questi casi, DEVONO indicare all'utente il motivo per cui non viene presentata una scelta di questo tipo.
[C-0-7] DEVE mostrare una finestra di dialogo di avviso con la stringa di avviso fornita tramite l'API di sistema PackageManager.setHarmfulAppWarning all'utente prima di avviare un'attività in un'applicazione che è stata contrassegnata dalla stessa API di sistema PackageManager.setHarmfulAppWarning come potenzialmente dannosa.
DEVE fornire un'opzione per scegliere di disinstallare o avviare un'applicazione nella finestra di dialogo di avviso.
[C-0-8] DEVE implementare il supporto per il file system incrementale come documentato qui.
[C-0-9] DEVE supportare la verifica dei file .apk utilizzando lo schema di firma dell'APK v4 e lo schema di firma dell'APK v4.1.

5. Compatibilità multimediale

Implementazioni del dispositivo:

[C-0-1] DEVE supportare i formati multimediali, i codificatori, i decodificatori, i tipi di file e i formati contenitore definiti nella sezione 5.1 per ogni codec dichiarato da MediaCodecList.
[C-0-2] DEVE dichiarare e segnalare il supporto dei codificatori e decodificatori disponibili per le applicazioni di terze parti tramite MediaCodecList.
[C-0-3] DEVE essere in grado di decodificare correttamente e rendere disponibili alle app di terze parti tutti i formati che può codificare. Sono inclusi tutti i bitstream generati dai relativi encoder e i profili riportati nel relativo CamcorderProfile.

Implementazioni del dispositivo:

SHOULD aim for minimum codec latency, in others words, they
- NON deve utilizzare e archiviare i buffer di input e restituirli solo una volta elaborati.
- NON DEVE conservare i buffer decodificati per un periodo di tempo superiore a quello 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 seguente sono forniti come implementazioni software nell'implementazione Android preferita di Android Open Source Project.

Tieni presente che né Google né la Open Handset Alliance dichiarano che questi codec siano esenti da brevetti di terze parti. Coloro che intendono utilizzare questo codice sorgente in prodotti hardware o software sono invitati a considerare che le implementazioni di questo codice, anche in software open source o shareware, potrebbero richiedere licenze di brevetto dai titolari dei brevetti pertinenti.

5.1. Codec multimediali

5.1.1. Codifica audio

Per saperne di più, consulta la sezione 5.1.3. Dettagli codec audio.

Se le implementazioni del dispositivo dichiarano android.hardware.microphone, DEVONO supportare la codifica dei seguenti formati audio e renderli disponibili ad app di terze parti:

[C-1-1] PCM/WAVE
[C-1-2] FLAC
[C-1-3] Opus

[C-1-4] MPEG-D USAC con MPEG-D DRC (Extended High Efficiency AAC)

Tutti i codificatori audio DEVONO supportare:

[C-3-1] Frame audio PCM a 16 bit con ordine dei byte nativo tramite l'API android.media.MediaCodec.

Quando codifichi MPEG-D USAC con audio MPEG-D DRC (Extended High Efficiency AAC):

[C-3-2] Tutti i bitstream DEVONO contenere i set di metadati conformi al profilo di controllo del volume MPEG-D o al profilo di controllo della gamma dinamica MPEG-D, livello 1 o superiore, in conformità con ISO/IEC 23003-4.

5.1.2. Decodifica audio

Per saperne di più, consulta la sezione 5.1.3. Dettagli codec audio.

Se le implementazioni del dispositivo dichiarano il supporto della funzionalità android.hardware.audio.output, devono supportare la decodifica dei seguenti formati audio:

[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+ avanzato)
[C-1-4] AAC ELD (enhanced low delay AAC)
[C-1-5] FLAC
[C-1-6] MP3
[C-1-7] MIDI
[C-1-8] Vorbis
[C-1-9] PCM/WAVE, inclusi formati audio ad alta risoluzione fino a 24 bit, frequenza di campionamento di 192 kHz e 8 canali. Tieni presente che questo requisito riguarda solo la decodifica e che un dispositivo può eseguire il downsampling e il downmix durante la fase di riproduzione.
[C-1-10] Opus
[C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, che include il profilo di baseline USAC e ISO/IEC 23003-4 Dynamic Range Control Profile)

Se le implementazioni dei dispositivi supportano la decodifica dei buffer di input AAC di stream multicanale (ovvero più di due canali) in PCM tramite il decoder audio AAC predefinito nell'API android.media.MediaCodec, devono essere supportati i seguenti elementi:

[C-2-1] La decodifica DEVE essere eseguita senza downmix (ad es. un flusso AAC 5.0 deve essere decodificato in cinque canali PCM, un flusso AAC 5.1 deve essere decodificato in sei canali PCM).
[C-2-2] I metadati dell'intervallo dinamico DEVONO essere definiti in "Dynamic Range Control (DRC)" nella norma 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.
[C-SR-1] È VIVAMENTE CONSIGLIATO che i requisiti C-2-1 e C-2-2 sopra siano soddisfatti da tutti i decoder audio AAC.

Durante la decodifica dell'audio USAC, MPEG-D (ISO/IEC 23003-4):

[C-3-1] I metadati relativi a volume e DRC DEVONO essere interpretati e applicati in base al profilo di controllo della gamma dinamica MPEG-D DRC di livello 1.
[C-3-2] Il decoder DEVE comportarsi in base alla configurazione impostata con i seguenti tasti android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_DRC_EFFECT_TYPE.

Decoder dei profili MPEG-4 AAC, HE AAC e HE AACv2:

POTREBBE supportare il controllo del volume e della gamma dinamica utilizzando il profilo di controllo della gamma dinamica ISO/IEC 23003-4.

Se ISO/IEC 23003-4 è supportato e se sia i metadati ISO/IEC 23003-4 sia quelli ISO/IEC 14496-3 sono presenti in un bitstream decodificato, allora:

I metadati ISO/IEC 23003-4 DEVONO avere la precedenza.

Tutti i decoder audio DEVONO supportare l'output di:

[C-6-1] Frame audio PCM a 16 bit con ordine dei byte nativo tramite l'API android.media.MediaCodec.

[C-7-1] DEVE poter essere configurato dall'applicazione utilizzando la decodifica con la chiave KEY_MAX_OUTPUT_CHANNEL_COUNT per controllare se i contenuti vengono mixati in stereo (quando si utilizza un valore pari a 2) o vengono riprodotti utilizzando il numero nativo di canali (quando si utilizza un valore pari o superiore a questo numero). Ad esempio, un valore pari o superiore a 6 configurerebbe un decoder per l'output di 6 canali quando viene fornito un contenuto 5.1.
[C-7-2] Durante la decodifica, il decodificatore DEVE pubblicizzare la maschera del canale utilizzata nel formato di output con la chiave KEY_CHANNEL_MASK, utilizzando le costanti android.media.AudioFormat (esempio: CHANNEL_OUT_5POINT1).

Tutti i dispositivi portatili o tablet con effetto spazializzatore e tutti i dispositivi automobilistici e televisivi:

[C-8-1] DEVE supportare la decodifica di IAMF v1.0 contenente flussi audio codificati in AAC, FLAC, Opus o PCM e DEVE presentare un decoder IAMF tramite l'API android.media.MediaCodec.
[C-8-2] DEVE garantire che il decodificatore IAMF rispetti la maschera del canale utilizzata per configurarlo tramite la chiave KEY_CHANNEL_MASK, utilizzando costanti android.media.AudioFormat come CHANNEL_OUT_5POINT1.
[C-8-3] DEVE assicurarsi che il decodificatore IAMF pubblicizzi la maschera del canale attivo nel formato di output tramite la chiave KEY_CHANNEL_MASK, utilizzando costanti android.media.AudioFormat come CHANNEL_OUT_5POINT1.

Se le implementazioni del dispositivo supportano decodificatori audio diversi da quello AAC predefinito e sono in grado di riprodurre audio multicanale (ovvero più di 2 canali) quando vengono forniti contenuti multicanale compressi, allora:

[C-SR-2] È FORTEMENTE CONSIGLIATO che il decodificatore possa essere configurato dall'applicazione utilizzando la decodifica con la chiave KEY_MAX_OUTPUT_CHANNEL_COUNT per controllare se i contenuti vengono mixati in stereo (quando si utilizza un valore di 2) o vengono riprodotti utilizzando il numero nativo di canali (quando si utilizza un valore maggiore o uguale a questo numero). Ad esempio, un valore pari o superiore a 6 configurerebbe un decoder per l'output di 6 canali quando viene fornito un contenuto 5.1.
[C-SR-3] Durante la decodifica, è FORTEMENTE CONSIGLIATO che il decoder pubblicizzi la maschera del canale utilizzata nel formato di output con la chiave KEY_CHANNEL_MASK, utilizzando le costanti android.media.AudioFormat (ad esempio: CHANNEL_OUT_5POINT1).

5.1.3. Dettagli sui codec audio

Formato/codec	Dettagli	Tipi di file/formati contenitore da supportare
G.711 μ-law e A-law	Supporto di contenuti mono/stereo/5.1 campionati a 8 kHz	WAVE (.wav)
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 elaborato ADTS (.aac, ADIF non supportato) MPEG-TS (.ts, non ricercabile, solo decodifica) Matroska (.mkv, solo decodifica)
Profilo MPEG-4 HE AAC (AAC+)	Supporto di contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profilo (AAC+ avanzato)	Supporto di contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (enhanced low delay AAC)	Supporto di contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC MPEG-D USAC con MPEG-D DRC (Extended High Efficiency AAC)	Decodifica:supporto di contenuti mono/stereo con frequenze di campionamento standard da 7,35 a 48 kHz. Codifica: supporto di contenuti mono/stereo con frequenze di campionamento di 44,1 e 48 kHz.	MPEG-4 (.mp4, .m4a)
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, come definito in AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec	3GPP (.3gp)
FLAC	Per l'encoder e il decoder: devono essere supportate almeno le modalità mono e stereo. Devono essere supportate frequenze di campionamento fino a 192 kHz; devono essere supportate risoluzioni a 16 e 24 bit. La gestione dei dati audio FLAC a 24 bit DEVE essere disponibile con la configurazione audio in virgola mobile.	FLAC (.flac) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (.mkv, solo decodifica)
MP3	Mono/stereo 8-320 Kbps costante (CBR) o velocità in bit variabile (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (.mkv, solo decodifica)
MIDI	MIDI di tipo 0 e 1. DLS versione 1 e 2. XMF e Mobile XMF. Supporto dei formati RTTTL/RTX, OTA e iMelody per le suonerie	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	Decodifica: supporto di contenuti mono, stereo, 5.0 e 5.1 con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz. Codifica: supporto di contenuti mono e stereo con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (.mkv) Webm (.webm)
PCM/WAVE	Il codec PCM DEVE supportare PCM lineare a 16 bit e float a 16 bit. L'estrattore WAVE deve supportare PCM lineare a 16 bit, 24 bit e 32 bit e virgola mobile a 32 bit (frequenze fino al limite dell'hardware). Le frequenze di campionamento DEVONO essere supportate da 8 kHz a 192 kHz.	WAVE (.wav)
Opus	Decodifica: supporto di contenuti mono, stereo, 5.0 e 5.1 con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz. Codifica: supporto di contenuti mono e stereo con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (.mkv) Webm (.webm)

5.1.4. Codifica dell'immagine

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

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

[C-0-1] JPEG
[C-0-2] PNG
[C-0-3] WebP
[C-0-4] AVIF
- I dispositivi devono supportare BITRATE_MODE_CQ e il profilo di baseline.

Se le implementazioni dei dispositivi supportano la codifica HEIC tramite android.media.MediaCodec per il tipo di media MIMETYPE_IMAGE_ANDROID_HEIC, devono:

[C-1-1] DEVE fornire un codec encoder HEVC con accelerazione hardware che supporti BITRATE_MODE_CQ la modalità di controllo della velocità in bit, il profilo HEVCProfileMainStill e le dimensioni del frame di 512 x 512 px.

5.1.5. Decodifica dell'immagine

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

Le implementazioni dei dispositivi DEVONO supportare la decodifica della seguente codifica 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] Raw
[C-0-7] AVIF (profilo di base)

Se le implementazioni dei dispositivi supportano la decodifica video HEVC:

[C-1-1] DEVE supportare la decodifica delle immagini HEIF (HEIC).

Decoder di immagini che supportano un formato ad alta profondità di bit (9 o più bit per canale):

[C-2-1] DEVE supportare l'output di un formato equivalente a 8 bit se richiesto dall'applicazione, ad esempio tramite la configurazione ARGB_8888 di android.graphics.Bitmap.

5.1.6. Dettagli sui codec immagine

Formato/codec	Dettagli	Tipi di file/formati contenitore supportati
JPEG	Base+progressive	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Dati		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Immagine, raccolta di immagini, sequenza di immagini	HEIF (.heif), HEIC (.heic)
AVIF (profilo di baseline)	Profilo di baseline per immagine, raccolta di immagini e sequenza di immagini	Contenitore HEIF (.avif)

Encoder e decoder di immagini esposti tramite l'API MediaCodec

[C-1-1] DEVE supportare il formato colore flessibile YUV420 8:8:8 (COLOR_FormatYUV420Flexible) tramite CodecCapabilities.
[C-SR-1] VIVAMENTE CONSIGLIATO di supportare il formato di colore RGB888 per la modalità Surface di input.
[C-1-3] DEVE supportare almeno uno dei formati di colore YUV420 8:8:8 planare o semiplanare: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). È VIVAMENTE CONSIGLIATO supportarli entrambi.

5.1.7. Codec video

Per una qualità accettabile dei servizi di streaming video sul 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 codificatore o decodificatore video:

[C-1-1] I codec video DEVONO supportare dimensioni di bytebuffer di output e input che contengano il frame compresso e non compresso più grande possibile come previsto dallo standard e dalla configurazione, ma senza allocare risorse in eccesso.
[C-1-2] I codificatori e decodificatori video DEVONO supportare i formati di colore flessibili YUV420 8:8:8 (COLOR_FormatYUV420Flexible) tramite CodecCapabilities.
[C-1-3] I codificatori e decodificatori video DEVONO supportare almeno uno dei formati di colore YUV420 8:8:8 planare o semiplanare: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). È FORTEMENTE CONSIGLIATO supportarli entrambi.
[C-SR-1] È FORTEMENTE CONSIGLIATO che i codificatori e decodificatori video supportino almeno uno dei formati di colore YUV420 8:8:8 planare o semiplanare ottimizzati per l'hardware (YV12, NV12, NV21 o formato equivalente ottimizzato per il fornitore).
[C-1-5] I decoder video che supportano un formato ad alta profondità di bit (9+ bit per canale) DEVONO supportare l'output di un formato equivalente a 8 bit se richiesto dall'applicazione. Ciò DEVE essere rispecchiato dal supporto di un formato colore YUV420 8:8:8 tramite android.media.MediaCodecInfo.

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

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

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

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

A meno che l'applicazione non specifichi diversamente utilizzando la chiave di formato KEY_COLOR_FORMAT, le implementazioni del decodificatore video:

[C-4-1] DEVE utilizzare per impostazione predefinita il formato colore ottimizzato per il display hardware se configurato utilizzando l'output di Surface.
[C-4-2] DEVE utilizzare per impostazione predefinita un formato colore YUV420 8:8:8 ottimizzato per la lettura della CPU se è configurato per non utilizzare l'output della superficie.

Per le implementazioni di dispositivi che includono un codificatore o un decodificatore video:

[C-5-1] I decoder video che utilizzano una tecnologia di codifica del 2003 o successiva (come AV1, AVC, HEVC, VP8, VP9 o VVC) DEVONO:
- Supportare una dimensione minima di 144 x 144 px e
- Pubblicizza questo supporto tramite l'API VideoCapabilities, ad esempio i metodi getSupportedWidths() e getSupportedHeightsFor().
[C-5-2] I codificatori video che utilizzano una tecnologia di codifica del 2003 o successiva (ad esempio AV1, AVC, HEVC, VP8, VP9 o VVC) DEVONO:
- Supporta l'input di Surface con le seguenti dimensioni minime per ogni codificatore:
  - AVC: 160x160 px
  - VP8, HEVC, VP9 (se il codificatore è fornito): 160 x 160 px
  - AV1 (se fornito encoder): 256 x 256 px
- POTREBBE produrre un bitstream con una dimensione del frame maggiore di quella minima, a condizione che codifichi la dimensione corretta utilizzando le informazioni sul rettangolo di ritaglio.

5.1.8. Elenco dei codec video

Formato/codec	Dettagli	Tipi di file/formati contenitore da supportare
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, solo decodifica)
H.264 AVC	Per ulteriori dettagli, consulta le sezioni 5.2 e 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, non ricercabile) Matroska (.mkv, solo decodifica)
H.265 HEVC	Per informazioni dettagliate, consulta la sezione 5.3.	MPEG-4 (.mp4) Matroska (.mkv, solo decodifica)
MPEG-2	Profilo principale	MPEG2-TS (.ts, non ricercabile) MPEG-4 (.mp4, solo decodifica) Matroska (.mkv, solo decodifica)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, solo decodifica)
VP8	Per ulteriori dettagli, consulta le sezioni 5.2 e 5.3.	WebM (.webm) Matroska (.mkv)
VP9	Per informazioni dettagliate, consulta la sezione 5.3.	WebM (.webm) Matroska (.mkv)
AV1	Per ulteriori dettagli, consulta la sezione 5.2 e la sezione 5.3.	MPEG-4 (.mp4) Matroska (.mkv, solo decodifica)

5.1.9. Sicurezza del codec multimediale

Le implementazioni dei dispositivi DEVONO garantire la conformità alle funzionalità di sicurezza dei codec multimediali come descritto di seguito.

Android include il supporto per OMX, un'API di accelerazione multimediale multipiattaforma, nonché per Codec 2.0, un'API di accelerazione multimediale a basso overhead.

Se le implementazioni dei dispositivi supportano i contenuti multimediali:

[C-1-1] DEVE fornire supporto per i codec multimediali tramite le API OMX o Codec 2.0 (o entrambe) come in Android Open Source Project e non disattivare o aggirare le protezioni di sicurezza. Ciò non significa che ogni codec DEVE utilizzare l'API OMX o Codec 2.0, ma solo che il supporto di almeno una di queste API DEVE essere disponibile e il supporto delle API disponibili DEVE includere le protezioni di sicurezza presenti.
[C-SR-1] È VIVAMENTE CONSIGLIATO di includere il supporto per l'API Codec 2.0.

Se le implementazioni dei dispositivi non supportano l'API Codec 2.0:

[C-2-1] DEVE includere il codec software OMX corrispondente dal progetto Android Open Source (se disponibile) per ogni formato e tipo di media (codificatore o decodificatore) supportato dal dispositivo.
[C-2-2] Codec con nomi che iniziano con "OMX.google." DEVE essere basato sul codice sorgente di Android Open Source Project.
[C-SR-2] È FORTEMENTE CONSIGLIATO che i codec software OMX vengano eseguiti in un processo di codec che non ha accesso a driver hardware diversi dai mapper di memoria.

Se le implementazioni dei dispositivi supportano l'API Codec 2.0:

[C-3-1] DEVE includere il codec software Codec 2.0 corrispondente dal progetto Android Open Source (se disponibile) per ogni formato multimediale e tipo (encoder o decoder) supportato dal dispositivo.
[C-3-2] DEVE ospitare i codec software Codec 2.0 nel processo del codec software come fornito nell'Android Open Source Project per consentire di concedere l'accesso ai codec software in modo più specifico.
[C-3-3] Codec con nomi che iniziano con "c2.android." DEVE essere basato sul codice sorgente di Android Open Source Project.

5.1.10. Caratterizzazione del codec multimediale

Se le implementazioni dei dispositivi supportano i codec multimediali:

[C-1-1] DEVE restituire i valori corretti della caratterizzazione del codec multimediale tramite l'API MediaCodecInfo.

In particolare:

[C-1-2] Codec con nomi che iniziano con "OMX." DEVE utilizzare le API OMX e avere nomi conformi alle linee guida per la denominazione OMX IL.
[C-1-3] Codec con nomi che iniziano con "c2." DEVE utilizzare l'API Codec 2.0 e avere nomi conformi alle linee guida per la denominazione di Codec 2.0 per Android.
[C-1-4] Codec con nomi che iniziano con "OMX.google." o "c2.android." NON deve essere caratterizzato come fornitore o come accelerato dall'hardware.
[C-1-5] I codec eseguiti in un processo codec (fornitore o sistema) che hanno accesso a driver hardware diversi da allocatori e mapper di memoria NON DEVONO essere caratterizzati come solo software.
[C-1-6] I codec non presenti in Android Open Source Project o non basati sul codice sorgente di questo progetto DEVONO essere caratterizzati come fornitori.
[C-1-7] I codec che utilizzano l'accelerazione hardware DEVONO essere caratterizzati come accelerati dall'hardware.
[C-1-8] I nomi dei codec NON DEVONO essere fuorvianti. Ad esempio, i codec denominati "decoders" DEVONO supportare la decodifica, mentre quelli denominati "encoders" DEVONO supportare la codifica. I codec con nomi contenenti formati multimediali DEVONO supportare questi formati.

Se le implementazioni del dispositivo supportano i codec video:

[C-2-1] Tutti i codec video DEVONO pubblicare i dati relativi alla frequenza fotogrammi raggiungibile per le seguenti dimensioni, se supportate dal codec:

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p	UHD
Risoluzione video	176 x 144 px (H263, MPEG2, MPEG4) 352 x 288 px (codificatore MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 px (altro)	704 x 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 px (codificatore MPEG4) 720 x 480 px (altro, AV1)	1408 x 1152 px (H263) 1280 x 720 px (altro, AV1)	1920 x 1080 px (diverso da MPEG4, AV1)	3840 x 2160 px (HEVC, VP9, AV1)

[C-2-2] I codec video caratterizzati come accelerati hardware DEVONO pubblicare informazioni sui punti di rendimento. Devono elencare tutti i punti di rendimento standard supportati (elencati nell'API PerformancePoint), a meno che non siano coperti da un altro punto di rendimento standard supportato.
Inoltre, DEVONO pubblicare punti di rendimento del video estesi se supportano prestazioni video sostenute diverse da quelle standard elencate.

5.2. Codifica video

Se le implementazioni del dispositivo supportano un codificatore video e lo rendono disponibile ad app di terze parti e impostano
MediaFormat.KEY_BITRATE_MODE su BITRATE_MODE_VBR in modo che il codificatore funzioni in modalità a velocità in bit variabile, allora, finché non influisce sul livello minimo di qualità, la velocità in bit codificata :

NON DEVE superare, in una finestra mobile, più del 15% della velocità in bit tra gli intervalli intraframe (I-frame).
NON DEVE superare il 100% del bitrate in una finestra mobile di 1 secondo.

Se le implementazioni del dispositivo supportano un codificatore video e lo rendono disponibile alle app di terze parti e impostano MediaFormat.KEY_BITRATE_MODE su BITRATE_MODE_CBR in modo che il codificatore funzioni in modalità a bitrate costante, il bitrate codificato:

[C-SR-2] è FORTEMENTE CONSIGLIATO di NON superare di oltre il 15% la velocità in bit target in una finestra mobile di 1 secondo.

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

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

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

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

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

DEVE supportare bit rate configurabili dinamicamente per il codificatore supportato.

Se le implementazioni dei dispositivi forniscono codificatori video o immagini con accelerazione hardware e supportano una o più videocamere hardware collegate o collegabili esposte tramite le API android.camera:

[C-4-1] tutti i codificatori video e immagini con accelerazione hardware DEVONO supportare la codifica dei frame dalle videocamere hardware.
DEVE supportare la codifica dei frame dalle videocamere hardware tramite tutti i codificatori video o di immagini.

Se le implementazioni dei dispositivi forniscono la codifica HDR:

[C-SR-1] È VIVAMENTE CONSIGLIATO fornire un plug-in per l'API di transcodifica senza interruzioni per la conversione dal formato HDR al formato SDR.

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:

[C-1-1] DEVE supportare la risoluzione QCIF (176 x 144) utilizzando il profilo di baseline di livello 45. La risoluzione SQCIF è facoltativa.

5.2.2. H.264

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

[C-1-1] DEVE supportare il profilo di baseline di livello 3. Tuttavia, il supporto per ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) e RS (Redundant Slices) è FACOLTATIVO. Inoltre, per mantenere la compatibilità con altri dispositivi Android, è CONSIGLIATO che ASO, FMO e RS non vengano utilizzati per il profilo di baseline dai codificatori.
[C-1-2] DEVONO supportare i profili di codifica video SD (definizione standard) 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 video con risoluzione 720p o 1080p tramite le API multimediali:

[C-2-1] DEVE supportare i profili di codifica 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).
[C-1-2] DEVE supportare la scrittura di file Matroska WebM.
DEVE fornire 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 e videoconferenza web.

Se le implementazioni del dispositivo segnalano il supporto della codifica VP8 per video con risoluzione 720p o 1080p tramite le API multimediali,

[C-2-1] DEVE supportare i profili di codifica 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:

[C-1-2] DEVE supportare il profilo 0 livello 3.
[C-1-1] DEVE supportare la scrittura di file Matroska WebM.
[C-1-3] DEVE generare dati CodecPrivate.
DEVE supportare i profili di decodifica HD indicati nella tabella seguente.
[C-SR-1] sono FORTEMENTE CONSIGLIATI per supportare i profili di decodifica HD come indicato nella tabella seguente se è presente un codificatore hardware.

	SD	HD 720p	HD 1080p	UHD
Risoluzione video	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 fps
Velocità in bit video	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se le implementazioni dei dispositivi dichiarano di supportare il profilo 2 o il profilo 3 tramite le API Media:

Il supporto del formato a 12 bit è FACOLTATIVO.

5.2.5. H.265

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

[C-1-1] DEVE supportare il profilo Main Level 3 fino a una risoluzione di 512 x 512.
[C-SR-1] è FORTEMENTE CONSIGLIATO per supportare il profilo SD 720 x 480 e i profili di codifica HD indicati nella tabella seguente se è presente un codificatore hardware.

	SD	HD 720p	HD 1080p	UHD
Risoluzione video	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 fps
Velocità in bit video	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.2.6. AV1

Se le implementazioni dei dispositivi supportano il codec AV1, allora:

[C-1-1] DEVE supportare il profilo principale, inclusi contenuti a 8 e 10 bit.
[C-1-2] DEVE pubblicare i dati sul rendimento, ovvero segnalarli tramite le API getSupportedFrameRatesFor() o getSupportedPerformancePoints() per le risoluzioni supportate nella tabella seguente.
[C-1-3] DEVE accettare i metadati HDR e inviarli al bitstream

Se il codificatore AV1 è accelerato dall'hardware:

[C-2-1] DEVE supportare il profilo di codifica HD1080p e quelli inferiori della tabella seguente:

	SD	HD 720p	HD 1080p	UHD
Risoluzione video	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 fps
Velocità in bit video	5 Mbps	8 Mbps	16 Mbps	50 Mbps

5.3. Decodifica video

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

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

5.3.1. MPEG-2

Se le implementazioni dei dispositivi supportano i decoder 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 decoder H.263:

[C-1-1] DEVE supportare il profilo di baseline livello 30 (risoluzioni CIF, QCIF e SQCIF a 30 fps 384 kbps) e il livello 45 (risoluzioni QCIF e SQCIF a 30 fps 128 kbps).

5.3.3. MPEG-4

Se le implementazioni del dispositivo con decoder 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 decoder H.264:

[C-1-1] DEVE supportare il profilo principale di livello 3.1 e il profilo di baseline. Il supporto per ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) e RS (Redundant Slices) è FACOLTATIVO.
[C-1-2] DEVE essere in grado di decodificare video con i profili SD (Standard Definition) elencati nella tabella seguente e codificati con il profilo di baseline e il profilo Main 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 segnalata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, le implementazioni del dispositivo:

[C-2-1] DEVE supportare i profili di decodifica video HD 720p nella tabella seguente.
[C-2-2] DEVE supportare i profili di decodifica video HD 1080p 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 f/s	30 fps (60 fps^Televisione)
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 profilo principale, livello 3, livello principale e i profili di decodifica video SD come indicato nella tabella seguente.
DEVE supportare i profili di decodifica HD indicati nella tabella seguente.
[C-1-2] DEVE supportare i profili di decodifica HD indicati nella tabella seguente se è presente un decoder hardware.

Se l'altezza segnalata dal metodo Display.getSupportedModes() è uguale o maggiore della risoluzione del video, allora:

[C-2-1] Le implementazioni dei dispositivi DEVONO supportare almeno una delle decodifiche 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 fps (60 fps^{Televisione con decodifica hardware H.265})	60 f/s
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se le implementazioni dei dispositivi dichiarano di supportare un profilo HDR tramite le API Media:

[C-3-1] Le implementazioni dei dispositivi DEVONO accettare i metadati HDR richiesti dall'applicazione, nonché supportare l'estrazione e l'output dei metadati HDR richiesti dal bitstream e/o dal contenitore.
[C-3-2] Le implementazioni del dispositivo DEVONO visualizzare correttamente i contenuti HDR sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

5.3.6. VP8

Se le implementazioni dei dispositivi supportano il codec VP8:

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

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

[C-2-1] Le implementazioni dei dispositivi DEVONO supportare i profili 720p nella tabella seguente.
[C-2-2] Le implementazioni del dispositivo DEVONO supportare i profili 1080p 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 fps^Televisione)	30 (60 fps^Televisione)
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 indicati nella tabella seguente.

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

[C-2-1] DEVE supportare i profili di decodifica HD indicati nella tabella seguente.

Se l'altezza segnalata dal metodo Display.getSupportedModes() è uguale o maggiore della risoluzione del video, allora:

[C-3-1] Le implementazioni dei dispositivi DEVONO supportare almeno una delle decodifiche 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 fps^{TV con decodifica hardware VP9})	60 f/s
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se le implementazioni dei dispositivi dichiarano di supportare VP9Profile2 o VP9Profile3 tramite le API multimediali 'CodecProfileLevel':

Il supporto del formato a 12 bit è FACOLTATIVO.

Se le implementazioni dei dispositivi dichiarano di supportare un profilo HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) tramite le API Media:

[C-4-1] Le implementazioni dei dispositivi DEVONO accettare i metadati HDR richiesti (KEY_HDR_STATIC_INFO per tutti i profili HDR, nonché 'KEY_HDR10_PLUS_INFO' per i profili HDR10Plus) dall'applicazione. Devono inoltre supportare l'estrazione e l'output dei metadati HDR richiesti dal bitstream e/o dal contenitore.
[C-4-2] Le implementazioni del dispositivo DEVONO visualizzare correttamente i contenuti HDR sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

5.3.8. Dolby Vision

Se le implementazioni del dispositivo dichiarano il supporto del decodificatore Dolby Vision tramite HDR_TYPE_DOLBY_VISION, devono:

[C-1-1] DEVE fornire un estrattore compatibile con Dolby Vision.
[C-1-2] DEVE visualizzare correttamente i contenuti Dolby Vision sullo schermo del dispositivo o su un display esterno collegato tramite una porta di uscita video standard (ad esempio HDMI).
[C-1-3] DEVE impostare l'ID traccia del livello o dei livelli di base compatibili con le versioni precedenti (se presenti) in modo che sia uguale all'ID traccia del livello Dolby Vision combinato.

5.3.9. AV1

Se le implementazioni dei dispositivi supportano il codec AV1 e lo rendono disponibile per applicazioni di terze parti:

[C-1-1] DEVE supportare il profilo principale, inclusi contenuti a 8 e 10 bit.

Se le implementazioni dei dispositivi forniscono il supporto per il codec AV1 con un decoder accelerato hardware, allora:

[C-2-1] DEVE essere in grado di decodificare almeno i profili di decodifica video HD 720p dalla tabella seguente quando l'altezza segnalata dal metodo Display.getSupportedModes() è uguale o superiore a 720p.
[C-2-2] DEVE essere in grado di decodificare almeno i profili di decodifica video HD 1080p della tabella seguente quando l'altezza segnalata dal metodo Display.getSupportedModes() è uguale o superiore a 1080p.

	SD	HD 720p	HD 1080p	UHD
Risoluzione video	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 fps
Velocità in bit video	5 Mbps	8 Mbps	16 Mbps	50 Mbps

Se le implementazioni dei dispositivi supportano il profilo HDR tramite le API Media, allora:

[C-3-1] DEVE supportare l'estrazione e l'output dei metadati HDR dal bitstream e/o dal contenitore.
[C-3-2] DEVE visualizzare correttamente i contenuti HDR sullo schermo del dispositivo o su una porta di uscita video standard (ad esempio HDMI).

5.4. Registrazione audio

Sebbene alcuni dei requisiti descritti in questa sezione siano elencati come SHOULD a partire da Android 4.3, la definizione di compatibilità per le versioni future prevede di modificarli in MUST. È FORTEMENTE CONSIDERATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti elencati come SHOULD, altrimenti non potranno ottenere la compatibilità con Android quando verranno aggiornati alla versione futura.

5.4.1. Acquisizione audio grezzo e informazioni sul microfono

Se le implementazioni dei dispositivi dichiarano android.hardware.microphone:

[C-1-1] DEVE consentire l'acquisizione di contenuti audio non elaborati per qualsiasi flusso di INPUT AudioRecord o AAudio aperto correttamente. Come minimo, devono essere supportate le seguenti caratteristiche:
- Formato: PCM lineare, 16 bit
- Frequenze di campionamento: 8000, 11025, 16000, 44100, 48000 Hz
- Canali: mono
- Fonti audio: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, o VOICE_PERFORMANCE. Ciò vale anche per i preset di input equivalenti in AAudio, ad esempio AAUDIO_INPUT_PRESET_CAMCORDER.
DOVREBBE consentire l'acquisizione di contenuti audio non elaborati con le seguenti caratteristiche:
- Formato: PCM lineare, 16 bit e 24 bit
- Frequenze di campionamento: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
- Canali: tanti canali quanti sono i microfoni sul dispositivo
[C-1-2] DEVE 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 grezzi con qualità radio AM e DVD, il che significa le seguenti caratteristiche:
- Formato: PCM lineare, 16 bit
- Frequenze di campionamento: 22050, 48000 Hz
- Canali: stereo
[C-1-4] DEVE rispettare l'API MicrophoneInfo e compilare correttamente le informazioni per i microfoni disponibili sul dispositivo accessibili alle applicazioni di terze parti tramite l'API AudioManager.getMicrophones(), per AudioRecord attivo utilizzando MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED o VOICE_PERFORMANCE. Se le implementazioni del dispositivo consentono la radio AM e l'acquisizione di contenuti audio grezzi di qualità DVD,
[C-2-1] DEVE 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. Acquisizione per il riconoscimento vocale

Se le implementazioni dei dispositivi dichiarano android.hardware.microphone:

[C-1-1] DEVE acquisire la sorgente audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION a una delle frequenze di campionamento, 44100 e 48000.
[C-1-2] DEVE, per impostazione predefinita, disattivare qualsiasi elaborazione audio di riduzione del rumore durante la registrazione di un flusso audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
[C-1-3] DEVE, per impostazione predefinita, disattivare qualsiasi controllo automatico del guadagno durante la registrazione di un flusso audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
DEVE mostrare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte nella gamma di frequenza media: in particolare ±3 dB da 100 Hz a 4000 Hz per ogni microfono utilizzato per registrare la sorgente audio del riconoscimento vocale.
[C-SR-1] è FORTEMENTE CONSIGLIATO di mostrare livelli di ampiezza nella gamma di basse frequenze: in particolare da ±20 dB da 30 Hz a 100 Hz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio del riconoscimento vocale.
[C-SR-2] è VIVAMENTE CONSIGLIATO di mostrare livelli di ampiezza nella gamma di alte frequenze: in particolare da ±30 dB da 4000 Hz a 22 kHz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio del riconoscimento vocale.
DEVE impostare la sensibilità dell'ingresso audio in modo che una sorgente di tono sinusoidale a 1000 Hz riprodotta a un livello di pressione sonora (SPL) di 90 dB (misurato vicino al microfono) produca una risposta ideale di RMS 2500 in un intervallo compreso tra 1770 e 3530 per 16 bit-sample (o -22,35 dB ±3 dB a fondo scala per campioni in virgola mobile/a doppia precisione) per ogni microfono utilizzato per registrare la sorgente audio di riconoscimento vocale.
DEVE registrare il flusso audio del riconoscimento vocale in modo che i livelli di ampiezza PCM traccino linearmente le variazioni del livello di pressione sonora di ingresso in un intervallo di almeno 30 dB da -18 dB a +12 dB rispetto a 90 dB SPL sul microfono.
DEVE registrare il flusso audio del riconoscimento vocale con distorsione armonica totale (THD) inferiore all'1% per 1 kHz a un livello di ingresso di 90 dB SPL al microfono.

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

[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 eliminazione dei rumori tramite il campo AudioEffect.Descriptor.uuid.

5.4.3. Acquisizione per il reindirizzamento della riproduzione

La classe android.media.MediaRecorder.AudioSource include la sorgente audio REMOTE_SUBMIX.

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

[C-1-1] DEVE implementare correttamente la sorgente audio REMOTE_SUBMIX in modo che quando un'applicazione utilizza l'API android.media.AudioRecord per registrare da questa sorgente audio, acquisisca un mix di tutti i flussi audio, ad eccezione dei seguenti:
- AudioManager.STREAM_RING
- AudioManager.STREAM_ALARM
- AudioManager.STREAM_NOTIFICATION

5.4.4. Cancellatore dell'eco acustica

Se le implementazioni dei dispositivi dichiarano android.hardware.microphone:

DEVE implementare una tecnologia Acoustic Echo Canceler (AEC) ottimizzata per la comunicazione vocale e applicata al percorso di acquisizione durante l'acquisizione tramite AudioSource.VOICE_COMMUNICATION.

Se le implementazioni dei dispositivi forniscono un Acoustic Echo Canceler inserito nel percorso audio di acquisizione quando è selezionato AudioSource.VOICE_COMMUNICATION, queste:

[C-SR-1] [C-1-1] are STRONGLY_RECOMMENDED MUST declare this via AcousticEchoCanceler API method AcousticEchoCanceler.isAvailable() returning true.

[C-1-2] DEVE riflettere l'abilitazione dell'AEC sul percorso audio tramite il metodo API AcousticEchoCanceler AcousticEchoCanceler.getEnabled(), che deve restituire true quando è attivo e false quando è inattivo.

[C-SR-2] [C-SR-1] sono STRONGLY_RECOMMENDED per consentire il controllo di questo effetto audio con l'API AcousticEchoCanceler.
[C-SR-3] [C-SR-2] sono FORTEMENTE CONSIGLIATI per identificare in modo univoco ogni implementazione della tecnologia AEC tramite il campo AudioEffect.Descriptor.uuid.

5.4.5. Acquisizione simultanea

Se le implementazioni del dispositivo dichiarano android.hardware.microphone, DEVONO implementare l'acquisizione simultanea come descritto in questo documento. In particolare:

[C-1-1] DEVE consentire l'accesso simultaneo al microfono da parte di un servizio di accessibilità che acquisisce con AudioSource.VOICE_RECOGNITION e di almeno un'applicazione che acquisisce con qualsiasi AudioSource.
[C-1-2] DEVE consentire l'accesso simultaneo al microfono da parte di un'applicazione preinstallata che ha un ruolo di assistente e di almeno un'applicazione che acquisisce con qualsiasi AudioSource, ad eccezione di AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER.
[C-1-3] DEVE disattivare l'acquisizione audio per qualsiasi altra applicazione, ad eccezione di un servizio di accessibilità, mentre un'applicazione acquisisce con AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER. Tuttavia, quando un'app acquisisce tramite AudioSource.VOICE_COMMUNICATION, un'altra app può acquisire la chiamata vocale se è un'app privilegiata (preinstallata) con l'autorizzazione CAPTURE_AUDIO_OUTPUT.
[C-1-4] Se due o più applicazioni acquisiscono contemporaneamente e se nessuna delle due app ha un'interfaccia utente in primo piano, quella che ha avviato l'acquisizione più di recente riceve l'audio.

5.5. Riproduzione audio

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

5.5.1. Riproduzione audio grezzo

Se le implementazioni dei dispositivi dichiarano android.hardware.audio.output:

[C-1-1] DEVE consentire la riproduzione di contenuti audio non elaborati con le seguenti caratteristiche:
- Formati sorgente: PCM lineare, 16 bit, 8 bit, virgola mobile
- Canali: mono, stereo, configurazioni multicanale valide con un massimo di 8 canali
- Frequenze di campionamento (in Hz):
  - 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 nelle configurazioni dei canali elencate sopra
  - 96000 in mono e stereo

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, devono:

[C-1-1] DEVE supportare le implementazioni EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controllabili tramite le sottoclassi AudioEffect Equalizer e LoudnessEnhancer.
[C-1-2] DEVE supportare l'implementazione dell'API visualizzatore, controllabile tramite la classe Visualizer.
[C-1-3] DEVE supportare l'implementazione di EFFECT_TYPE_DYNAMICS_PROCESSING controllabile tramite la sottoclasse AudioEffect DynamicsProcessing.
[C-1-4] DEVE supportare effetti audio con input e output in virgola mobile, quando i risultati dell'effetto vengono restituiti alla pipeline audio del framework. Si riferisce ai tipici effetti di inserto o aux come l'equalizzatore. È consigliato vivamente un comportamento equivalente quando i risultati dell'effetto non sono visibili dalla pipeline audio del framework, ad esempio effetti di post-elaborazione o scaricati.
[C-1-5] DEVE assicurarsi che gli effetti audio supportino più canali fino al numero di canali del mixer, noto anche come FCC_LIMIT, quando i risultati dell'effetto vengono restituiti alla pipeline audio del framework. Si riferisce ai tipici effetti di inserto o ausiliari, ma esclude effetti speciali come downmix, upmix o effetti di spazializzazione che modificano il numero di canali. È consigliato un comportamento equivalente quando gli effetti non sono visibili dalla pipeline audio del framework, ad esempio effetti di post-elaborazione o scaricati.
DEVE 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.
[C-SR-1] Sono VIVAMENTE CONSIGLIATI per supportare gli effetti in rappresentazione in virgola mobile e multicanale.

5.5.3. Volume di uscita audio

Implementazioni di dispositivi per il settore automotive:

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

5.5.4. Trasferimento audio

Se le implementazioni del dispositivo supportano la riproduzione con offload audio, devono:

[C-SR-1] È FORTEMENTE CONSIGLIATO tagliare i contenuti audio gapless riprodotti tra due clip con lo stesso formato se specificato dall'API gapless AudioTrack e dal contenitore multimediale per MediaPlayer.
[C-SR-2] È VIVAMENTE CONSIGLIATO implementare la riproduzione in offload per i formati AAC, MP3, OPUS e PCM.

Se le implementazioni dei dispositivi dichiarano il supporto dell'offload MMAP PCM (dichiarato da una porta mix con flag contenenti AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD e AUDIO_OUTPUT_FLAG_MMAP_NOIRQ), queste:

[C-1-1] DEVE supportare almeno AUDIO_FORMAT_PCM_16_BIT, a 44,1 kHz e 48 kHz per lo stereo e il mono.
[C-1-2] DEVE avere una dimensione del buffer in grado di memorizzare un minimo di 5 secondi di audio a 48 kHz stereo PCM a 16 bit per campione.

5.5.5. Parametri di riproduzione

Se le implementazioni del dispositivo supportano l'API PlaybackParams, i parametri di riproduzione:

[C-1-1] DEVE supportare velocità comprese tra 0,5 e 2,0 con un tono di 1,0.

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 della presente sezione, utilizza le seguenti definizioni:

latenza di output. L'intervallo tra il momento in cui un'applicazione scrive un frame di dati codificati in PCM e il momento in cui il suono corrispondente viene presentato all'ambiente a un trasduttore sul dispositivo o il segnale esce dal dispositivo tramite una porta e può essere osservato esternamente.
Latenza di output a freddo. Il tempo che intercorre tra l'avvio di un flusso di output e il tempo di presentazione del primo frame in base ai timestamp, quando il sistema di uscita audio è rimasto inattivo e spento prima della richiesta.
latenza di output continua. La latenza di output per i frame successivi, dopo che il dispositivo riproduce l'audio.
Latenza input. L'intervallo tra il momento in cui un suono viene presentato dall'ambiente al dispositivo in un trasduttore sul dispositivo o il momento in cui un segnale entra nel dispositivo tramite una porta e il momento in cui un'applicazione legge il frame corrispondente di dati codificati in PCM.
input perso. La parte iniziale di un segnale di ingresso inutilizzabile o non disponibile.
Latenza di input a freddo. Il tempo che intercorre tra l'avvio dello stream e il momento in cui viene ricevuto il primo frame valido, quando il sistema di input audio è rimasto inattivo e spento prima della richiesta.
latenza input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.
latenza di andata e ritorno 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 ridurre la differenza di fase tra i flussi di input e output.
API OpenSL ES coda di buffer PCM. Il set di API OpenSL ES correlate a PCM all'interno di Android NDK.
API audio nativa AAudio. Il set di API AAudio all'interno di Android NDK.
Timestamp. Una coppia costituita da una posizione relativa del frame all'interno di un flusso e dall'ora stimata in cui il frame entra o esce dalla pipeline di elaborazione audio sull'endpoint associato. Vedi anche AudioTimestamp.
glitch. Un'interruzione temporanea o un valore di campionamento errato nel segnale audio, in genere causato da un buffer underrun per l'output, un buffer overrun per l'input o qualsiasi altra fonte di rumore digitale o analogico.
deviazione media assoluta (MAD). La media del valore assoluto degli scostamenti dalla media per un insieme di valori.
La latenza tap-to-tone (TTL), misurata da CTS Verifier, è il tempo che intercorre tra il tocco dello schermo e l'ascolto di un suono generato a seguito del tocco sull'altoparlante. Questo valore è la media di 5 misurazioni utilizzando l'API audio nativa AAudio per l'output.
La latenza di andata e ritorno (RTL), misurata da CTS Verifier, è la latenza continua media su 5 misurazioni, misurata su un percorso di loopback che riporta l'output all'input, utilizzando l'API audio nativa AAudio.

I percorsi di loopback sono:
- Altoparlante/microfono: altoparlante integrato al microfono integrato.
- Analogico: jack analogico da 3,5 mm e un adattatore loopback.
- USB: adattatore da USB a 3,5 mm e adattatore loopback o interfaccia audio USB e cavi loopback.
FEATURE_AUDIO_LOW_LATENCY. La funzionalità android.hardware.audio.low_latency è dichiarata.
FEATURE_AUDIO_PRO. La funzionalità android.hardware.audio.pro è dichiarata.
MPC. Classe di rendimento media.
Latenza del rilevamento della testa. Il tempo che intercorre tra il movimento della testa acquisito dall'unità di misura inerziale (IMU) e il rilevamento da parte dei trasduttori delle cuffie della variazione del suono causata da questo movimento.

Implementazioni del dispositivo:

[C-0-1] DEVE garantire che quando un'applicazione chiama android.media.AudioManager.setCommunicationDevice() con un device supportato (ad esempio cuffie con cavo, altoparlanti o auricolari integrati o cuffie USB), il callback android.media.AudioManager.OnCommunicationDeviceChangedListener.onCommunicationDeviceChanged() venga richiamato con quel dispositivo audio entro 1500 ms dalla restituzione di true della chiamata setCommunicationDevice().

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

[C-1-1] Requisito rimosso in Android 15.
[C-1-2] Latenza dell'output a freddo pari o inferiore a 500 millisecondi.
[C-1-3] L'apertura di un flusso di output utilizzando AAudioStreamBuilder_openStream() DEVE richiedere meno di 1000 millisecondi.
[C-1-4] Le latenze di round trip calcolate in base ai timestamp di input e output restituiti da AAudioStream_getTimestamp DEVONO rientrare in un intervallo di 200 ms rispetto alla latenza di round trip misurata per AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY per altoparlanti, cuffie con cavo e cuffie wireless.
[C-SR-1] Requisito rimosso in Android 15.
[C-SR-2] Requisito rimosso in Android 15.
[C-SR-4] Requisito rimosso in Android 15.
[C-SR-5] Requisito rimosso in Android 15.
[C-SR-6] Requisito rimosso in Android 15.
[C-SR-7] Requisito rimosso in Android 15.
[C-2-1] Requisito rimosso in Android 15.

Se le implementazioni dei dispositivi includono android.hardware.microphone, devono soddisfare questi requisiti audio di input:

[C-3-1] Requisito rimosso in Android 15.
[C-3-2] Latenza dell'input a freddo pari o inferiore a 500 millisecondi.
[C-3-3] L'apertura di un flusso di input utilizzando AAudioStreamBuilder_openStream() DEVE richiedere meno di 1000 millisecondi.
[C-SR-8] Requisito rimosso in Android 15.
[C-SR-11] Requisito rimosso in Android 15.
[C-SR-12] Requisito rimosso in Android 15.

La seguente tabella definisce i requisiti per RTL per le implementazioni di dispositivi palmari come definito in 2.2.1 che dichiarano android.hardware.audio.output e android.hardware.microphone.

Dispositivo e dichiarazioni	RTL (ms)	MAD (ms)	Percorsi di loopback
A mano	200	25	speaker/mic, analog 3.5mm (if supported), USB (if supported)
MPC_C (17) e versioni successive	65	10	tutti i percorsi dei dati supportati
>= MPC_T (13) fino a MPC_B (16)	80	15	almeno un percorso
FEATURE_AUDIO_LOW_LATENCY	50	10	almeno un percorso
FEATURE_AUDIO_PRO	25	5	almeno un percorso
FEATURE_AUDIO_PRO	20	5	analogico (se supportato)
FEATURE_AUDIO_PRO	25	5	USB (se l'analogico non è supportato)

La seguente tabella definisce i requisiti per il TTL per le implementazioni di dispositivi palmari come definito in 2.2.1 che dichiarano android.hardware.audio.output e android.hardware.microphone.

Dispositivo e dichiarazioni	TTL (ms)
A mano	250
MPC_C (17) e versioni successive	65
>= MPC_T (13) fino a MPC_B (16)	80
MPC_S (12)	100
FEATURE_AUDIO_PRO	80

Se le implementazioni del dispositivo includono il supporto di spatial audio con head tracking e dichiarano il flag PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, i dispositivi:

[C-4-1] DEVE presentare una latenza massima di aggiornamento audio di 300 ms.

5.7. Protocolli di rete

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

Per ogni codec e formato contenitore che un'implementazione del dispositivo deve supportare, l'implementazione del dispositivo:

[C-1-1] DEVE supportare il codec o il contenitore tramite HTTP e HTTPS.
[C-1-2] DEVE supportare i formati dei segmenti multimediali corrispondenti, come mostrato nella tabella dei formati dei segmenti multimediali di seguito, tramite il protocollo bozza HTTP Live Streaming, versione 7.
[C-1-3] DEVE supportare i formati di payload RTSP corrispondenti, come mostrato nella tabella RTSP di seguito. Per le eccezioni, consulta le note a piè di pagina della tabella nella sezione 5.1.

Formati dei segmenti multimediali

Formati dei segmenti	Riferimento/i	Supporto codec richiesto
Stream di trasporto MPEG-2	ISO 13818	Codec video: H264 AVC MPEG-4 SP MPEG-2 Per informazioni dettagliate su H264 AVC, MPEG2-4 SP e MPEG-2,consulta la sezione 5.1.8. Codec audio: AAC Per informazioni dettagliate su AAC e sulle relative varianti, consulta la sezione 5.1.3.
AAC con framing ADTS e tag ID3	ISO 13818-7	Per maggiori dettagli su AAC e sulle relative varianti, consulta la sezione 5.1.1 .
WebVTT	WebVTT

Formati dei segmenti

Riferimento/i

Supporto codec richiesto

Stream di trasporto MPEG-2

ISO 13818

Codec video:

H264 AVC
MPEG-4 SP
MPEG-2

Per informazioni dettagliate su H264 AVC, MPEG2-4 SP e MPEG-2,consulta la sezione 5.1.8.

Codec audio:

Per informazioni dettagliate su AAC e sulle relative varianti, consulta la sezione 5.1.3.

AAC con framing ADTS e tag ID3

ISO 13818-7

Per maggiori dettagli su AAC e sulle relative varianti, consulta la sezione 5.1.1 .

WebVTT

RTSP (RTP, SDP)

Nome del profilo	Riferimento/i	Supporto codec richiesto
H264 AVC	RFC 6184	Consulta la sezione 5.1.8 per i dettagli su H264 AVC
MP4A-LATM	RFC 6416	Per informazioni dettagliate su AAC e sulle relative varianti, consulta la sezione 5.1.3.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Per informazioni dettagliate su H263, consulta la sezione 5.1.8.
H263-2000	RFC 4629	Per informazioni dettagliate su H263, consulta la sezione 5.1.8.
AMR	RFC 4867	Per informazioni dettagliate su AMR-NB, consulta la sezione 5.1.3.
AMR-WB	RFC 4867	Per informazioni dettagliate su AMR-WB, consulta la sezione 5.1.3.
MP4V-ES	RFC 6416	Per informazioni dettagliate su MPEG-4 SP, consulta la sezione 5.1.8.
mpeg4-generic	RFC 3640	Per informazioni dettagliate su AAC e sulle relative varianti, consulta la sezione 5.1.3.
MP2T	RFC 2250	Per i dettagli, consulta Flusso di trasporto MPEG-2 in HTTP Live Streaming.

5.8. Secure Media

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

[C-1-1] DEVE dichiarare il supporto di Display.FLAG_SECURE.

Se le implementazioni dei dispositivi dichiarano il supporto di Display.FLAG_SECURE e supportano il protocollo di visualizzazione wireless:

[C-2-1] DEVE proteggere il collegamento con un meccanismo crittograficamente sicuro, ad esempio 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 un display esterno cablato:

[C-3-1] DEVE supportare HDCP 1.2 o versioni successive per tutti i display esterni collegati tramite una porta cablata accessibile all'utente.

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 MIDI su tutti i trasporti hardware compatibili con MIDI per i quali fornisce connettività generica non MIDI, dove questi trasporti sono:
- Modalità host USB, sezione 7.7
- MIDI su Bluetooth LE che funge da ruolo centrale, sezione 7.4.3
[C-1-2] DEVE supportare il trasporto software MIDI tra app (dispositivi MIDI virtuali)
[C-1-3] DEVE includere libamidi.so (supporto MIDI nativo)
DEVE supportare la modalità periferica MIDI su USB, sezione 7.7

5.10. Audio professionale

Se le implementazioni dei dispositivi segnalano il supporto della funzionalità android.hardware.audio.pro tramite la classe android.content.pm.PackageManager,

[C-1-1] DEVE segnalare il supporto per la funzionalità android.hardware.audio.low_latency.
[C-1-2] DEVE soddisfare i requisiti di latenza per FEATURE_AUDIO_PRO come definito nella sezione 5.6 Latenza audio .
[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 per la funzionalità android.software.midi.
[C-1-5] DEVE soddisfare i requisiti di latenza audio USB utilizzando l'API AAudio native audio e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
[C-1-6] DEVE avere una latenza di output a freddo pari o inferiore a 200 millisecondi.
[C-1-7] DEVE avere una latenza di input a freddo pari o inferiore a 200 millisecondi.

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

[C-2-2] DEVE essere conforme alla sezione Specifiche del dispositivo mobile (jack) della Wired Audio Headset Specification (v1.1).

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, devono:

[C-3-1] DEVE implementare la classe audio USB.

5.11. Acquisizione 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 l'impostazione predefinita di registrazione SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

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

[C-1-1] DEVE 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 nella gamma di frequenza media: in particolare ±10 dB da 100 Hz a 7000 Hz per ogni microfono utilizzato per registrare la sorgente audio non elaborata.
[C-1-3] DEVE mostrare livelli di ampiezza nella gamma di basse frequenze: in particolare da ±20 dB da 5 Hz a 100 Hz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio non elaborata.
[C-1-4] DEVE mostrare livelli di ampiezza nella gamma di alte frequenze, in particolare da ±30 dB da 7000 Hz a 22 kHz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio non elaborata.
[C-1-5] DEVE impostare la sensibilità dell'ingresso audio in modo che una sorgente di tono sinusoidale a 1000 Hz riprodotta a un livello di pressione sonora (SPL) di 94 dB produca una risposta con un valore RMS di 520 per campioni a 16 bit (o -36 dB a fondo scala per campioni in virgola mobile/a doppia precisione) per ogni microfono utilizzato per registrare la sorgente audio non elaborata.
[C-1-6] DEVE avere un rapporto segnale/rumore (SNR) pari o superiore a 60 dB per ogni microfono utilizzato per registrare la sorgente audio non elaborata. mentre il rapporto segnale/rumore viene misurato come la differenza tra 94 dB SPL e il livello 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 SPL di 90 dB per ogni microfono utilizzato per registrare la sorgente audio non elaborata.
[C-1-8] NON DEVE avere nessun altro trattamento del segnale (ad es. controllo automatico del guadagno, filtro passa alto o cancellazione dell'eco) nel percorso diverso da un moltiplicatore di livello per portare il livello all'intervallo desiderato. In altre parole:
- [C-1-9] Se nell'architettura è presente un'elaborazione del segnale per qualsiasi motivo, questa deve essere disattivata e non deve introdurre ritardi o latenza aggiuntiva nel percorso del segnale.
- [C-1-10] Il moltiplicatore di livello, sebbene sia consentito nel percorso, NON DEVE introdurre ritardo o latenza nel percorso del segnale.

Tutte le misurazioni SPL vengono effettuate direttamente accanto al microfono in fase di test. Per le configurazioni con più microfoni, questi requisiti si applicano a ciascun microfono.

Se le implementazioni dei dispositivi dichiarano android.hardware.microphone ma non supportano la sorgente audio non elaborata:

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

5.12. Video HDR

Android 13 supporta le tecnologie HDR come descritto in un documento in uscita.

Formato pixel

Se un decoder video dichiara di supportare COLOR_FormatYUVP010:

[C-1-1] DEVE supportare il formato P010 per la lettura della CPU (ImageReader, MediaImage, ByteBuffer). In Android 13, P010 è rilassato per consentire un passo arbitrario per i piani Y e UV.
[C-1-2] Il buffer di output P010 DEVE poter essere campionato dalla GPU (se allocato con utilizzo GPU_SAMPLING). Ciò consente la composizione della GPU e la mappatura tonale personalizzata da parte delle app.

Se un decoder video dichiara di supportare COLOR_Format32bitABGR2101010:

[C-2-1] DEVE supportare il formato RGBA_1010102 per la superficie di output e l'output ByteBuffer leggibile dalla CPU.

Se un codificatore video dichiara di supportare COLOR_FormatYUVP010:

[C-3-1] DEVE supportare il formato P010 per la superficie di input e l'input scrivibile dalla CPU (ImageWriter, MediaImage, ByteBuffer).

Se un codificatore video dichiara di supportare COLOR_Format32bitABGR2101010:

[C-4-1] DEVE supportare il formato RGBA_1010102 per la superficie di input e l'input scrivibile dalla CPU (ImageWriter, ByteBuffer). Nota: la conversione tra varie curve di trasferimento NON è richiesta per i codificatori.

Requisiti di acquisizione HDR

Per tutti i codificatori video che supportano i profili HDR, implementazioni del dispositivo:

[C-5-1] NON DEVE presumere che i metadati HDR siano precisi. Ad esempio, il frame codificato potrebbe avere pixel oltre il livello di luminanza di picco oppure l'istogramma potrebbe non essere rappresentativo del frame.
DEVE aggregare i metadati dinamici HDR per generare metadati statici HDR appropriati per gli stream codificati e deve restituirli alla fine di ogni sessione di codifica.

Se le implementazioni dei dispositivi supportano l'acquisizione HDR utilizzando le API CamcorderProfile, devono:

[C-6-1] DEVE supportare l'acquisizione HDR anche tramite le API Camera2.
[C-6-2] DEVE supportare almeno un codificatore video con accelerazione hardware per ogni tecnologia HDR supportata.
[C-6-3] DEVE supportare (almeno) l'acquisizione HLG.
[C-6-4] DEVE supportare la scrittura dei metadati HDR (se applicabile alla tecnologia HDR) nel file video acquisito. Per AV1, HEVC e DolbyVision questo significa includere i metadati nel bitstream codificato.
[C-6-5] DEVE supportare P010 e COLOR_FormatYUVP010.
[C-6-6] DEVE supportare la mappatura tonale HDR-SDR nel decoder accelerato dall'hardware predefinito per il profilo acquisito. In altre parole, se un dispositivo può acquisire HEVC HDR10+, il decodificatore HEVC predefinito DEVE essere in grado di decodificare lo stream acquisito in SDR.

Requisiti di editing HDR

Se le implementazioni dei dispositivi includono codificatori video che supportano la modifica HDR:

DEVE utilizzare una latenza minima per generare i metadati HDR quando non sono presenti e DEVE gestire correttamente le situazioni in cui i metadati sono presenti per alcuni frame e non per altri. Questi metadati DEVONO essere precisi (ad esempio, rappresentare la luminanza di picco e l'istogramma effettivi del frame).

Se l'implementazione del dispositivo include codec che supportano FEATURE_HdrEditing, questi codec:

[C-7-1] DEVE supportare almeno un profilo HDR.
[C-7-2] DEVE supportare FEATURE_HdrEditing per tutti i profili HDR pubblicizzati da questo codec. In altre parole, DEVE supportare la generazione di metadati HDR quando non sono presenti per tutti i profili HDR supportati che utilizzano metadati HDR.
[C-7-3] DEVE supportare i seguenti formati di input del codificatore video che preservano completamente il segnale decodificato HDR:
- RGBA_1010102 (già nella curva di trasferimento target) sia per la superficie di input che per ByteBuffer e DEVE pubblicizzare il supporto di COLOR_Format32bitABGR2101010.

Se l'implementazione del dispositivo include codec che supportano FEATURE_HdrEditing, allora il dispositivo:

[C-7-4] DEVE pubblicizzare il supporto dell'estensione OpenGL EXT_YUV_target.

Requisiti di visualizzazione HDR

Se le implementazioni dei dispositivi ricevono contenuti del buffer codificati con ADATASPACE_TRANSFER_HLG e questi contenuti vengono inviati al display tramite SurfaceControl.Transaction#setBuffer, i dispositivi:

[C-8-1] DEVE seguire il consiglio relativo al bianco grafico in BT. 2408-7, e visualizzare solo i contenuti che siano al massimo 4,926 volte più grandi dei contenuti SDR.

6. Compatibilità di strumenti e opzioni per sviluppatori

6.1. Strumenti per sviluppatori

Implementazioni del dispositivo:

[C-0-1] DEVE supportare gli strumenti per sviluppatori Android forniti nell'SDK Android.
Android Debug Bridge (ADB)
[C-0-2] DEVE supportare adb come documentato nell'SDK Android e i comandi della shell forniti in AOSP, che possono essere utilizzati dagli sviluppatori di app, tra cui dumpsys, cmd stats e Simpleperf.
[C-0-11] DEVE supportare il comando shell cmd testharness. L'upgrade delle implementazioni dei dispositivi da una versione precedente di Android senza un blocco di dati persistente POTREBBE essere esentato da C-0-11.
[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 il comando dumpsys.
[C-0-10] DEVE registrare, senza omissioni, e rendere accessibili e disponibili i seguenti eventi al comando shell cmd stats e alla classe API di sistema StatsManager.
- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- InputDeviceUsageReported
- JobStateChanged
- KeyboardConfigured
- KeyboardSystemsEventReported
- PluggedStateChanged
- PressureStallInformation
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- TouchpadUsage
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
[C-0-4] Il daemon ADB lato dispositivo DEVE essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivare Android Debug Bridge.
[C-0-5] DEVE supportare adb sicuro. Android include il supporto di adb sicuro. Secure adb consente adb su host autenticati noti.
[C-0-6] DEVE fornire un meccanismo che consenta la connessione di adb da una macchina host. In particolare:

Se le implementazioni dei dispositivi senza porta USB supportano la modalità periferica:

[C-3-1] DEVE implementare adb tramite rete locale (ad esempio Ethernet o Wi-Fi).
[C-3-2] DEVE fornire driver per Windows 7, 8 e 10, consentendo agli sviluppatori di connettersi al dispositivo utilizzando il protocollo ADB.

Se le implementazioni dei dispositivi supportano le connessioni adb a una macchina host tramite Wi-Fi o Ethernet:

[C-4-1] MUST have the AdbManager#isAdbWifiSupported() method return true.

Se le implementazioni dei dispositivi supportano le connessioni adb a una macchina host tramite Wi-Fi o Ethernet e includono almeno una videocamera, queste:

[C-5-1] MUST have the AdbManager#isAdbWifiQrSupported() method return true.
Dalvik Debug Monitor Service (ddms)
- [C-0-7] DEVE supportare tutte le funzionalità di ddms come documentato nell'SDK Android. Poiché ddms utilizza adb, il supporto di ddms DEVE essere inattivo per impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato Android Debug Bridge, come sopra.
SysTrace
- [C-0-9] DEVE supportare lo strumento systrace come documentato nell'SDK Android. Systrace deve essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivarlo.
Perfetto
- [C-SR-1] È VIVAMENTE CONSIGLIATO di esporre un binario /system/bin/perfetto all'utente della shell la cui riga di comando è conforme alla documentazione di Perfetto.
- [C-SR-2] È VIVAMENTE CONSIGLIATO che il binario perfetto accetti come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
- [C-SR-3] È VIVAMENTE CONSIGLIATO scrivere il binario perfetto come output una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
- [C-SR-4] È FORTEMENTE CONSIGLIATO fornire, tramite il binario perfetto, almeno le origini dati descritte nella documentazione di perfetto.
Low Memory Killer
- [C-0-12] DEVE scrivere un LMK_KILL_OCCURRED_FIELD_NUMBER Atom nel log statsd quando un'app viene terminata da Low Memory Killer.
Modalità test harness

Se le implementazioni dei dispositivi supportano il comando shell cmd testharness ed eseguono cmd testharness enable,
- [C-2-1] MUST return true for ActivityManager.isRunningInUserTestHarness()
- [C-2-2] DEVE implementare la modalità test harness come descritto nella documentazione della modalità test harness.
Informazioni sul lavoro della GPU

Implementazioni del dispositivo:
- [C-0-13] DEVE implementare il comando shell dumpsys gpu --gpuwork per visualizzare i dati di lavoro della GPU aggregati restituiti dal tracepoint del kernel power/gpu_work_period o non visualizzare alcun dato se il tracepoint non è supportato. L'implementazione AOSP è frameworks/native/services/gpuservice/gpuwork/.

Se le implementazioni dei dispositivi segnalano il supporto di Vulkan 1.0 o versioni successive tramite i flag delle funzionalità android.hardware.vulkan.version:

[C-1-1] DEVE fornire un'opzione per consentire allo sviluppatore di app di attivare/disattivare i livelli di debug della GPU.
[C-1-2] DEVE, quando i livelli di debug della GPU sono attivati, enumerare i livelli nelle librerie fornite da strumenti esterni (ovvero non parte della piattaforma o del pacchetto dell'applicazione) trovate nella directory di base delle applicazioni sottoponibili a debug per supportare i metodi API vkEnumerateInstanceLayerProperties() e vkCreateInstance().

Se le implementazioni del dispositivo impostano entrambe le proprietà di sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_frequency su true,

[C-6-1] DEVE segnalare un punto di traccia della frequenza della GPU come specificato dal formato power/gpu_frequency, come definito in power.proto.

Se le implementazioni del dispositivo impostano entrambe le proprietà di sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_counters su true,

[C-7-1] DEVE fornire un produttore di dati Perfetto per un'origine dati denominata gpu.counters, interrogabile utilizzando: perfetto --query.
[C-7-2] MUST report GPU counters descriptions in compliance with the GPU counter trace packet proto.
[C-7-3] MUST report conformant values for the device's GPU counters following the gpu counter trace packet proto.
[C-7-4] MUST record the text descriptions for all enabled GPU Counters with no timestamp to perfetto trace.
[C-7-6] DEVE fornire un insieme predefinito non vuoto di contatori delle prestazioni della GPU per la profilazione, come specificato in GpuCounterSpec#select_by_default.
- DEVE essere possibile attivare tutti questi contatori predefiniti contemporaneamente.
- Devono tutti emettere valori in Perfetto quando sono attivati.
[C-7-7] DEVE riflettere l'utilizzo della GPU per almeno un contatore selezionato per impostazione predefinita, utilizzando GpuCounterSpec#select_by_default.

Se le implementazioni del dispositivo impostano entrambe le proprietà di sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_counters.period su true,

[C-8-1] DEVE rispettare counter_period_ns per la frequenza di campionamento dei contatori GPU. La frequenza di campionamento supportata DEVE essere di 1 ms o più veloce.
[C-SR-1] Sono FORTEMENTE CONSIGLIATI per supportare una frequenza di campionamento di 0,2 ms o superiore.

Se le implementazioni del dispositivo impostano entrambe le proprietà di sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_counters.groups su true,

[C-9-1] DEVE avere almeno un contatore in ciascuno dei seguenti gruppi di contatori GPU, come specificato da GpuCounterSpec: COMPUTE, FRAGMENTS, MEMORY, PRIMITIVES e VERTICES.

Se le implementazioni del dispositivo impostano entrambe le proprietà di sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_counters.groups su true e il dispositivo supporta il ray tracing:

[C-10-1] DEVE avere un contatore nel gruppo RAY_TRACING.

Se le implementazioni del dispositivo impostano entrambe le proprietà di sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_counters.zeroes_optimization su true,
[C-11-1] All'interno della stessa sessione di traccia Perfetto, i contatori della GPU DEVONO segnalare solo valori pari a zero se il valore precedente o successivo segnalato è diverso da zero.

Se le implementazioni del dispositivo impostano entrambe le proprietà di sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.render_stages su true,

[C-12-1] DEVE fornire un produttore di dati Perfetto per un'origine dati denominata gpu.renderstages, eseguibile tramite query utilizzando perfetto --query.
[C-12-2] DEVE segnalare valori conformi per le fasi di rendering della GPU seguendo il proto dell'evento di fase di rendering della GPU.

Se le implementazioni del dispositivo impostano entrambe le proprietà di sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.render_stages.queue_submit su true,

[C-13-1] Per ogni chiamata di invio della coda Vulkan, il driver Vulkan DEVE emettere un evento di traccia Perfetto in base alla specifica del messaggio di evento dell'API Vulkan.
- Questo evento DEVE contenere un submission_id univoco e monotonicamente crescente che corrisponda al submission_id nell'evento della fase di rendering della GPU corrispondente.

6.2. Opzioni sviluppatore

Android include il supporto per consentire agli sviluppatori di configurare le impostazioni relative allo sviluppo di applicazioni.

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

[C-0-1] DEVE rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo di applicazioni. L'implementazione Android upstream nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avviare le opzioni sviluppatore dopo aver premuto sette (7) volte la voce di menu Impostazioni > Informazioni sul dispositivo > Numero build.
[C-0-2] MUST hide Developer Options by default.
[C-0-3] DEVE fornire un meccanismo chiaro che non dia un trattamento preferenziale a un'app di terze parti rispetto a un'altra per attivare le Opzioni sviluppatore. DEVE fornire un documento o un sito web visibile pubblicamente che descriva come attivare le opzioni sviluppatore. Questo documento o sito web DEVE essere collegabile dai documenti dell'SDK Android.
DEVE avere una notifica visiva continua per l'utente quando le opzioni sviluppatore sono attive e la sicurezza dell'utente è a rischio.
POTREBBE limitare temporaneamente l'accesso al menu Opzioni sviluppatore, nascondendo o disattivando visivamente il menu, per evitare distrazioni in scenari in cui la sicurezza dell'utente è motivo di preoccupazione.

7. Compatibilità hardware

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

[C-0-1] L'implementazione del dispositivo DEVE implementare questa 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 possiede questo componente:

[C-0-2] Le definizioni complete delle classi (come documentato dall'SDK) per le API dei componenti DEVONO comunque essere presentate.
[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 laddove 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 API NON DEVONO generare eccezioni non documentate dalla documentazione dell'SDK.
[C-0-7] Le implementazioni del dispositivo DEVONO segnalare in modo coerente informazioni accurate sulla configurazione hardware tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) nella classe android.content.pm.PackageManager per la stessa impronta di build.

Un esempio tipico di scenario in cui si applicano questi requisiti è l'API telefonia: anche sui dispositivi non telefonici, queste API devono essere implementate come no-op ragionevoli.

7.1. Display e grafica

Android include funzionalità che regolano automaticamente gli asset e i layout dell'interfaccia utente dell'applicazione in modo appropriato per il dispositivo per garantire che le applicazioni di terze parti vengano eseguite correttamente su una varietà di display e configurazioni hardware. Un display compatibile con Android è uno schermo che implementa tutti i comportamenti e le API descritti in Android Developers - Screen compatibility overview, in questa sezione (7.1) e nelle relative sottosezioni, nonché tutti i comportamenti specifici per tipo di dispositivo documentati nella sezione 2 di questo CDD.

Implementazioni del dispositivo:

[C-0-1] DEVE, per impostazione predefinita, eseguire il rendering di applicazioni di terze parti solo su display compatibili con Android.

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.
density. Il numero di pixel compresi in un intervallo lineare orizzontale o verticale di 1", espresso in pixel per pollice (ppi o dpi). Se sono elencati i valori ppi e dpi, sia il dpi orizzontale che quello verticale devono rientrare nell'intervallo indicato.
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 sarebbe 854 / 480 = 1,779, ovvero circa "16:9".
pixel indipendenti dalla densità (dp). Un'unità di pixel virtuale normalizzata a una densità dello schermo di 160. Per una determinata densità d e un numero di pixel p, il numero di pixel indipendenti dalla densità dp viene calcolato come segue: dp = (160 / d) * p.

7.1.1. Configurazione dello schermo

7.1.1.1. Dimensioni e forma dello schermo

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

Implementazioni del dispositivo:

[C-0-1] DEVE 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 in pixel indipendenti dalla densità (dp) logici corretti 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 xlarge per Configuration.screenLayout, DEVONO avere almeno 960 dp x 720 dp.
[C-0-2] DEVE rispettare correttamente il supporto dichiarato dalle applicazioni per le dimensioni dello schermo tramite l'attributo <supports-screens> nel file AndroidManifest.xml, come descritto nella documentazione dell'SDK Android.
POTREBBE avere uno o più display compatibili con Android con angoli arrotondati.

Se le implementazioni dei dispositivi supportano schermi in grado di configurare le dimensioni UI_MODE_TYPE_NORMAL e utilizzano display fisici con angoli arrotondati per il rendering di questi schermi:

[C-1-1] DEVE garantire che almeno uno dei seguenti requisiti sia soddisfatto per ogni display:
- Il raggio degli angoli arrotondati è inferiore o uguale a 38 dp.
- Quando una casella di 18 dp x 18 dp è ancorata a ogni angolo del display logico, almeno un pixel di ogni casella è visibile sullo schermo.
DEVE includere la possibilità per l'utente di passare alla modalità di visualizzazione con gli angoli rettangolari.

Se le implementazioni dei dispositivi sono in grado di eseguire solo la configurazione della tastiera NO_KEYS e intendono segnalare il supporto della configurazione della modalità UI UI_MODE_TYPE_NORMAL, devono:

[C-4-1] DEVE avere una dimensione del layout, esclusi eventuali ritagli del display, di almeno 596 dp x 384 dp o superiore.

Per informazioni dettagliate sull'implementazione corretta delle API sidecar o di estensione, consulta la documentazione pubblica di Window Manager Jetpack.

[C-4-1] Requisito rimosso in Android 15.

7.1.1.2. Proporzioni dello schermo

Questa sezione è stata rimossa in Android 14.

7.1.1.3. Densità schermo

Il framework UI di Android definisce un insieme di densità logiche standard per aiutare gli sviluppatori di applicazioni a scegliere come target le risorse delle applicazioni.

Implementazioni del dispositivo:

[C-0-1] DEVE segnalare una delle densità del framework Android elencate su DisplayMetrics tramite l'API DENSITY_DEVICE_STABLE e questo valore deve essere statico per ogni display fisico. Tuttavia, il dispositivo POTREBBE segnalare un DisplayMetrics.density diverso in base alle modifiche alla configurazione del display apportate dall'utente (ad esempio, dimensioni di visualizzazione) impostate dopo l'avvio iniziale.
DEVE definire la densità standard del framework Android numericamente più vicina alla densità fisica dello schermo o un valore che corrisponda alle stesse misurazioni equivalenti del campo visivo angolare di un dispositivo portatile.

Se le implementazioni del dispositivo forniscono un'agevolazione per modificare le dimensioni di visualizzazione del dispositivo,

[C-1-1] NON DEVE scalare la visualizzazione a più di 1,5 volte DENSITY_DEVICE_STABLE o produrre una dimensione minima effettiva dello schermo inferiore a 320 dp (equivalente al qualificatore delle risorse sw320dp), a seconda di quale si verifica per prima.
[C-1-2] NON DEVE ridurre la scala del display a meno di 0,85 volte la DENSITY_DEVICE_STABLE.
Per garantire una buona usabilità e dimensioni dei caratteri coerenti, è CONSIGLIATO fornire il seguente ridimensionamento delle opzioni di visualizzazione nativa (rispettando i limiti specificati sopra):
- Piccola: 0,85x
- Predefinito: 1x (scala di visualizzazione nativa)
- Large: 1,15x
- Più grande: 1,3x
- Più grande 1,45x

7.1.2. Metriche display

Se le implementazioni del dispositivo includono il display o i display compatibili con Android o l'uscita video sullo schermo o sugli schermi del display compatibili con Android, queste:

[C-1-1] DEVE segnalare i valori corretti per tutte le metriche di visualizzazione compatibili con Android definite nell'API android.util.DisplayMetrics.

Se le implementazioni del dispositivo non includono uno schermo o un'uscita video incorporati, devono:

[C-2-1] DEVE segnalare i valori corretti del display compatibile con Android come definito nell'API android.util.DisplayMetrics per view.Display emulato predefinito.

7.1.3. Orientamento schermo

Implementazioni del dispositivo:

[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 con orientamento orizzontale fisso, come una televisione o un laptop, DOVREBBE segnalare solo android.hardware.screen.landscape.
[C-0-2] DEVE segnalare il valore corretto per l'orientamento attuale del dispositivo, ogni volta che viene eseguita una query tramite le API android.content.res.Configuration.orientation, android.view.Display.getOrientation() o altre.

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

[C-1-1] Requisito rimosso in Android 16.
[C-1-2] NON DEVE modificare le dimensioni o la densità dello schermo segnalate quando cambia l'orientamento.
PUÒ selezionare l'orientamento verticale o orizzontale come predefinito.

7.1.4. Accelerazione grafica 2D e 3D

7.1.4.1. OpenGL ES

Implementazioni del dispositivo:

[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 per tutte le API gestite e native corrispondenti per ogni versione di OpenGL ES che è stato identificato per il supporto.

Se le implementazioni del dispositivo includono uno schermo o un'uscita video:

[C-1-1] DEVE supportare OpenGL ES 1.1, 2.0, 3.0 e 3.1, come descritto e dettagliato nella documentazione dell'SDK Android.
[C-SR-1] Requisito rimosso in Android 15.
DEVE supportare OpenGL ES 3.2.

I test dEQP OpenGL ES sono suddivisi in un numero di elenchi di test, ciascuno con un numero di versione/data associato. Questi si trovano nell'albero delle origini Android in external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Un dispositivo che supporta OpenGL ES a un livello auto-dichiarato indica che può superare i test dEQP in tutti gli elenchi di test di questo livello e di quelli precedenti.

Se le implementazioni dei dispositivi supportano una delle versioni di OpenGL ES:

[C-2-1] DEVE segnalare tramite le API gestite OpenGL ES e le API native qualsiasi altra estensione OpenGL ES che ha implementato e, viceversa, NON DEVE segnalare 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, EGL_ANDROID_recordable e EGL_ANDROID_GLES_layers.
[C-2-3] DEVE segnalare la versione massima dei test OpenGL ES dEQP supportata tramite il flag di funzionalità android.software.opengles.deqp.level.
[C-2-4] DEVE supportare almeno la versione 132383489 (dal 1° marzo 2020) come indicato nel flag di funzionalità android.software.opengles.deqp.level.
[C-2-5] DEVE superare tutti i test OpenGL ES dEQP negli elenchi di test tra la versione 132383489 e la versione specificata nel flag funzionalità android.software.opengles.deqp.level, per ogni versione OpenGL ES supportata.
[C-SR-2] Sono VIVAMENTE CONSIGLIATE per supportare le estensioni EGL_KHR_partial_update e OES_EGL_image_external.
DEVE segnalare con precisione tramite il metodo getString() qualsiasi formato di compressione delle texture supportato, che in genere è specifico del fornitore.
DEVE supportare le estensioni EGL_IMG_context_priority e EGL_EXT_protected_content.

Se le implementazioni dei dispositivi dichiarano il supporto di OpenGL ES 3.0, 3.1 o 3.2:

[C-3-1] DEVE esportare i simboli di funzione corrispondenti per queste versioni oltre ai simboli di funzione OpenGL ES 2.0 nella libreria libGLESv2.so.
[C-SR-3] È FORTEMENTE CONSIGLIATO supportare l'estensione OES_EGL_image_external_essl3.

Se le implementazioni dei dispositivi supportano OpenGL ES 3.2:

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

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

[C-5-1] DEVE identificare il supporto tramite il flag di 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 grafica 3D ad alte prestazioni.

Se le implementazioni dei dispositivi supportano OpenGL ES 3.1:

[C-SR-1] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3.
[C-4-1] NON DEVE supportare una versione variante di Vulkan (ovvero la parte variante della versione core di Vulkan DEVE essere zero).

Se le implementazioni del dispositivo includono uno schermo o un'uscita video:

[C-SR-2] È FORTEMENTE CONSIGLIATO includere il supporto per Vulkan 1.3.

I test Vulkan dEQP sono suddivisi in un numero di elenchi di test, ognuno con una data/versione associata. Questi si trovano nell'albero delle origini Android in external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Un dispositivo che supporta Vulkan a un livello auto-dichiarato indica che può superare i test dEQP in tutti gli elenchi di test di questo livello e dei livelli precedenti.

Se le implementazioni dei dispositivi includono il supporto di Vulkan:

[C-1-1] DEVE segnalare il valore intero corretto con i flag delle funzionalità android.hardware.vulkan.level e android.hardware.vulkan.version.
[C-1-2] DEVE enumerare almeno un VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices().
[C-1-3] DEVE implementare completamente le API Vulkan 1.1 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 Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties().

[C-1-5] NON DEVE enumerare i livelli forniti dalle librerie al di fuori del pacchetto dell'applicazione né fornire altri modi per tracciare o intercettare l'API Vulkan, a meno che l'applicazione non abbia l'attributo android:debuggable impostato su true o i metadati com.android.graphics.injectLayers.enable impostati su true , ad eccezione dei livelli OEM e della piattaforma, come indicato nella documentazione Implementare Vulkan.

[C-1-6] DEVE segnalare tutte le stringhe di estensione che supporta tramite le API native Vulkan e, viceversa, NON DEVE segnalare le stringhe di estensione che non supporta correttamente.

[C-1-7] DEVE supportare le seguenti estensioni:
- VK_EXT_present_mode_fifo_latest_ready
- VK_KHR_present_wait2
- VK_KHR_android_surface
- VK_KHR_incremental_present
- VK_KHR_present_id
- VK_KHR_present_id2
- VK_KHR_surface
- VK_KHR_swapchain

[C-1-8] DEVE segnalare la versione massima dei test Vulkan dEQP supportata tramite il flag di funzionalità android.software.vulkan.deqp.level.
[C-1-9] DEVE supportare almeno la versione 132317953 (dal 1° marzo 2019) come indicato nel flag della funzionalità android.software.vulkan.deqp.level.
[C-1-10] DEVE superare tutti i test dEQP Vulkan negli elenchi di test tra la versione 132317953 e la versione specificata nel flag funzionalità android.software.vulkan.deqp.level.
[C-1-11] NON DEVE elencare il supporto per le estensioni VK_KHR_video_queue, VK_KHR_video_decode_queue o VK_KHR_video_encode_queue.

[C-SR-3] È VIVAMENTE CONSIGLIATO supportare le seguenti estensioni:
- VK_EXT_present_timing
- VK_GOOGLE_display_timing
- VK_KHR_driver_properties

[C-1-12] NON DEVE enumerare il supporto per l'estensione VK_KHR_performance_query.
[C-SR-4] Sono FORTEMENTE CONSIGLIATI per soddisfare i requisiti specificati dal profilo Android Baseline 2022.
[C-SR-5] Sono VIVAMENTE CONSIGLIATI per supportare VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory e VK_EXT_global_priority.
[C-SR-6] È VIVAMENTE CONSIGLIATO di utilizzare SkiaVk con HWUI.

Se le implementazioni dei dispositivi includono il supporto di Vulkan:

[C-SR-8] È VIVAMENTE CONSIGLIATO di non modificare il caricatore Vulkan.
[C-1-14] NON DEVE enumerare le estensioni del dispositivo Vulkan di tipo "KHR", "GOOGLE" o "ANDROID", a meno che queste estensioni non siano incluse nel flag di funzionalità android.software.vulkan.deqp.level.

Se le implementazioni dei dispositivi 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 enumerare alcun VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices().

Se le implementazioni dei dispositivi includono il supporto di Vulkan 1.1 e dichiarano uno qualsiasi dei flag delle funzionalità Vulkan descritti qui o versioni successive, devono:

[C-3-1] DEVE esporre il supporto per i tipi di semaforo e handle esterni SYNC_FD e per l'estensione VK_ANDROID_external_memory_android_hardware_buffer.
[C-SR-7] È FORTEMENTE CONSIGLIATO di rendere l'estensione VK_KHR_external_fence_fd disponibile per le applicazioni di terze parti e consentire all'applicazione di esportare il payload della recinzione e importarlo dai descrittori di file POSIX come descritto qui.

7.1.4.3. RenderScript

Implementazioni del dispositivo:

[C-0-1] DEVE supportare Android RenderScript, come descritto nella documentazione dell'SDK Android.

7.1.4.4. Accelerazione grafica 2D

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

Implementazioni del dispositivo:

[C-0-1] DEVE attivare l'accelerazione hardware per impostazione predefinita e DEVE disattivarla se lo sviluppatore lo richiede impostando android:hardwareAccelerated="false" o disattivandola direttamente tramite le API Android View.
[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 texture OpenGL ES con accelerazione hardware come target di rendering in una gerarchia dell'interfaccia utente.

Implementazioni del dispositivo:

[C-0-3] DEVE supportare l'API TextureView e DEVE mostrare un comportamento coerente con l'implementazione Android upstream.

7.1.4.5. Display ad ampia gamma

Se le implementazioni dei dispositivi dichiarano il supporto dei display wide gamut tramite Configuration.isScreenWideColorGamut(), devono:

[C-1-1] DEVE avere un display con calibrazione del colore.
[C-1-2] DEVE avere un display la cui gamma copre interamente la gamma di colori sRGB nello spazio CIE 1931 xyY.
[C-1-3] DEVE avere un display la cui gamma ha un'area di almeno il 90% di DCI-P3 nello spazio CIE 1931 xyY.
[C-1-4] DEVE supportare OpenGL ES 3.1 o 3.2 e segnalarlo correttamente.
[C-1-5] DEVE pubblicizzare il supporto per le estensioni EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, e EGL_EXT_gl_colorspace_display_p3_passthrough.
[C-SR-1] Sono FORTEMENTE CONSIGLIATI per supportare GL_EXT_sRGB.

Al contrario, se le implementazioni dei dispositivi non supportano i display ad ampia gamma,

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

7.1.5. Modalità di compatibilità con le applicazioni precedenti

Android specifica una "modalità di compatibilità" in cui il framework funziona in una modalità di dimensioni dello schermo "normale" equivalente (larghezza di 320 dp) a vantaggio di applicazioni legacy non sviluppate per 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 su un display compatibile con Android. I dispositivi DEVONO supportare tutte queste API come definito dall'SDK Android, a meno che non sia specificamente consentito in questo documento.

Tutti i display compatibili con Android di un'implementazione del dispositivo:

[C-0-1] MUST be capable of rendering 16-bit color graphics.
DOVREBBE supportare display in grado di visualizzare grafica a 24 bit.
[C-0-2] DEVE essere in grado di eseguire il rendering delle animazioni.
[C-0-3] DEVE avere proporzioni pixel (PAR) comprese tra 0,9 e 1,15. ovvero le proporzioni pixel DEVONO essere quasi quadrate (1.0) con una tolleranza del 10-15%.

7.1.7. Display secondari

Android include il supporto per display secondari compatibili con Android per attivare le funzionalità di condivisione dei contenuti multimediali e le API per sviluppatori per l'accesso a display esterni.

Se le implementazioni dei dispositivi supportano un display esterno tramite una connessione cablata, wireless o una connessione di visualizzazione aggiuntiva incorporata,

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

7.2. Dispositivi di immissione

Implementazioni del dispositivo:

[C-0-1] DEVE includere un meccanismo di input, ad esempio un touchscreen o una navigazione non touch, per spostarsi tra gli elementi della UI.

7.2.1. Tastiera

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

[C-1-1] DEVE dichiarare il flag funzionalità android.software.input_methods.
[C-1-2] DEVE implementare completamente Input Management Framework
[C-1-3] DEVE avere una tastiera su schermo preinstallata.

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).
DEVE includere implementazioni aggiuntive della tastiera su schermo.
POTREBBE includere una tastiera hardware.

7.2.2. Navigazione non touch

Android include il supporto per D-pad, trackball e rotella come meccanismi per la navigazione non touch.

Implementazioni del dispositivo:

[C-0-1] DEVE segnalare il valore corretto per android.content.res.Configuration.navigation.

Se le implementazioni dei dispositivi non prevedono navigazioni non touch:

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

7.2.3. Tasti di navigazione

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

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

Se vengono fornite le funzioni Home, Recenti o Indietro:

[C-1-1] DEVE essere accessibile con una singola azione (ad es. tocco, doppio clic o gesto) quando una qualsiasi di queste azioni è accessibile.
[C-1-2] DEVE fornire un'indicazione chiara di quale singola azione attiverebbe ogni funzione. Un'indicazione di questo tipo può essere un'icona visibile impressa sul pulsante, un'icona software nella sezione della barra di navigazione dello schermo o una procedura guidata passo passo durante la configurazione iniziale.

Implementazioni del dispositivo:

[C-SR-1] è FORTEMENTE CONSIGLIATO di non fornire il meccanismo di input per la funzione Menu in quanto è deprecata a favore della barra delle azioni a partire da Android 4.0.
[C-SR-2] È FORTEMENTE CONSIGLIATO fornire tutte le funzioni di navigazione come annullabili. "Annullabile" è definito come la capacità dell'utente di impedire l'esecuzione della funzione di navigazione (ad es. tornare alla home page, tornare indietro e così via) se lo scorrimento non viene rilasciato oltre una determinata soglia.

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

[C-2-1] DEVE mostrare il pulsante del menu extra ogni volta che il popup del menu extra 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 del menu extra nella barra delle azioni, ma PUÒ eseguire il rendering del 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 alle applicazioni quando targetSdkVersion è inferiore a 10, tramite un pulsante fisico, un tasto software o gesti. Questa funzione del menu deve essere accessibile, a meno che non sia nascosta insieme ad altre funzioni di navigazione.

Se le implementazioni dei dispositivi forniscono la funzione Assist, questi:

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

Se le implementazioni dei dispositivi utilizzano una parte distinta dello schermo per visualizzare i tasti di navigazione, devono:

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

Se la funzione di navigazione viene fornita come azione sullo schermo basata su gesti:

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() DEVE essere utilizzato solo per segnalare l'area di riconoscimento del gesto Home.
[C-6-2] I gesti che iniziano all'interno di un rettangolo di esclusione fornito dall'applicazione in primo piano tramite View#setSystemGestureExclusionRects(), ma al di fuori di WindowInsets#getMandatorySystemGestureInsets(), NON DEVONO essere intercettati per la funzione di navigazione, a condizione che il rettangolo di esclusione sia consentito entro il limite massimo di esclusione specificato nella documentazione di View#setSystemGestureExclusionRects().
[C-6-3] DEVE inviare all'app in primo piano un evento MotionEvent.ACTION_CANCEL una volta che i tocchi iniziano a essere intercettati per un gesto di sistema, se all'app in primo piano è stato precedentemente inviato un evento MotionEvent.ACTION_DOWN.
[C-6-4] DEVE fornire un'interfaccia utente per passare a una navigazione sullo schermo basata su pulsanti (ad esempio, nelle Impostazioni).
DEVE fornire la funzione Home come scorrimento verso l'alto dal bordo inferiore dell'orientamento corrente dello schermo.
DEVE fornire la funzionalità Recenti come scorrimento verso l'alto e mantenimento prima del rilascio, dalla stessa area del gesto Home.
I gesti che iniziano entro WindowInsets#getMandatorySystemGestureInsets() NON DEVONO essere interessati dai rettangoli di esclusione forniti dall'applicazione in primo piano tramite View#setSystemGestureExclusionRects().

Se una funzione di navigazione viene fornita da un punto qualsiasi dei bordi sinistro e destro dell'orientamento attuale dello schermo:

[C-7-1] La funzione di navigazione DEVE essere Indietro e fornita come scorrimento dai bordi sinistro e destro dell'orientamento attuale dello schermo.
[C-7-2] Se vengono forniti pannelli di sistema personalizzati scorrevoli sui bordi sinistro o destro, questi DEVONO essere posizionati nel terzo superiore dello schermo con un'indicazione visiva chiara e persistente che il trascinamento verso l'interno richiama i pannelli sopra menzionati e quindi non Indietro. Un pannello di sistema PUÒ essere configurato da un utente in modo che si trovi sotto il terzo superiore del bordo o dei bordi dello schermo, ma NON DEVE utilizzare più di un terzo del bordo o dei bordi.
[C-7-3] Quando l'app in primo piano ha impostato i flag View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, lo scorrimento dai bordi DEVE comportarsi come implementato in AOSP, ovvero come documentato nell'SDK.
[C-7-4] Quando l'app in primo piano ha impostato i flag View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, i pannelli di sistema personalizzati scorrevoli DEVONO essere nascosti finché l'utente non visualizza o non ripristina la luminosità delle barre di sistema (ovvero la barra di navigazione e la barra di stato) come implementato in AOSP.

Se viene fornita la funzione di navigazione a ritroso e l'utente annulla il gesto Indietro, allora:

[C-8-1] È necessario chiamare OnBackInvokedCallback.onBackCancelled().
[C-8-2] OnBackInvokedCallback.onBackInvoked() NON DEVE essere chiamato.
[C-8-3] L'evento KEYCODE_BACK NON DEVE essere inviato.

Se la funzione di navigazione a ritroso è fornita, ma l'applicazione in primo piano NON ha un OnBackInvokedCallback registrato, allora:

Il sistema DEVE fornire un'animazione per l'applicazione in primo piano che suggerisca all'utente che sta tornando indietro, come fornito in AOSP.

Se le implementazioni dei dispositivi forniscono supporto per l'API di sistema setNavBarMode per consentire a qualsiasi app di sistema con l'autorizzazione android.permission.STATUS_BAR di impostare la modalità della barra di navigazione, allora:

[C-9-1] DEVE fornire supporto per icone adatte ai bambini o navigazione basata su pulsanti come fornito nel codice AOSP.

7.2.4. Input touchscreen

Android include il supporto per una serie di sistemi di input del puntatore, come touchscreen, touchpad e dispositivi di input touch simulato. Le implementazioni di 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 ulteriori inviti per indicare gli oggetti manipolati.

Implementazioni del dispositivo:

DEVE avere un sistema di input del puntatore di qualche tipo (simile al mouse o al tocco).
DEVE supportare puntatori tracciati in modo completamente indipendente.

Se le implementazioni del dispositivo includono un touchscreen (single-touch o migliore) su un display principale compatibile con Android, devono:

[C-1-1] DEVE segnalare TOUCHSCREEN_FINGER per il campo API Configuration.touchscreen.
[C-1-2] DEVE segnalare i flag delle funzionalità android.hardware.touchscreen e android.hardware.faketouch.

Se le implementazioni del dispositivo includono un touchscreen in grado di rilevare più di un tocco su un display principale compatibile con Android, devono:

[C-2-1] DEVE segnalare i flag delle 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 si basano su un dispositivo di input esterno come il mouse o la trackball (ovvero non toccano direttamente lo schermo) per l'input su un display principale compatibile con Android e soddisfano i requisiti di tocco simulato nella sezione 7.2.5,

[C-3-1] NON DEVE segnalare alcun flag funzionalità che inizia con android.hardware.touchscreen.
[C-3-2] DEVE segnalare solo android.hardware.faketouch.
[C-3-3] MUST report TOUCHSCREEN_NOTOUCH for the Configuration.touchscreen API field.

7.2.5. Input tocco simulato

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

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

DEVE dichiarare il supporto per il flag della funzionalità android.hardware.faketouch.

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

[C-1-1] DEVE segnalare le posizioni X e Y assolute dello schermo della posizione del puntatore e visualizzare un puntatore visivo sullo schermo.
[C-1-2] DEVE segnalare l'evento touch con il codice azione che specifica la modifica dello stato che si verifica sul puntatore che si sposta verso il basso o verso l'alto sullo schermo.
[C-1-3] DEVE supportare il puntatore verso il basso e verso l'alto su un oggetto sullo schermo, il che consente agli utenti di emulare il tocco di un oggetto sullo schermo.
[C-1-4] DEVE supportare il puntatore verso il basso, il puntatore verso l'alto, il puntatore verso il basso e poi verso l'alto nello stesso punto di 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 puntatore verso il basso su un punto arbitrario dello schermo, il movimento del puntatore verso un altro punto arbitrario dello schermo, seguito da un puntatore verso l'alto, che consente agli utenti di emulare un trascinamento con il tocco.
[C-1-6] DEVE supportare il puntatore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in una posizione diversa sullo schermo e poi il puntatore verso l'alto sullo schermo, il che consente agli utenti di lanciare un oggetto sullo schermo.

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

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

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

[C-3-1] DEVE dichiarare il supporto per android.hardware.faketouch.
[C-3-2] DEVE supportare il tracciamento distinto di 5 (tracciamento di una mano di dita) o più input del puntatore in modo completamente indipendente.

7.2.6. Supporto del controller di gioco

7.2.6.1. Mappature dei pulsanti

Implementazioni del dispositivo:

[C-1-1] DEVE essere in grado di mappare gli eventi HID alle costanti InputEvent corrispondenti elencate nelle tabelle seguenti. L'implementazione Android upstream soddisfa questo requisito.

Se le implementazioni dei dispositivi incorporano un controller o vengono spedite con un controller separato nella confezione che fornirebbe i mezzi per inserire tutti gli eventi elencati nelle tabelle seguenti, queste:

[C-2-1] DEVE dichiarare il flag funzionalità android.hardware.gamepad

Pulsante	Utilizzo HID²	Pulsante Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad su¹ D-pad giù¹	0x01 0x0039³	AXIS_HAT_Y⁴
D-pad - Sinistra1 D-pad - Destra¹	0x01 0x0039³	AXIS_HAT_X⁴
Pulsante dorsale sinistro¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Pulsante dorsale destro¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic su levetta analogica sinistra¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic su levetta analogica destra¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Indietro¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Gli utilizzi HID precedenti devono essere dichiarati all'interno di una CA Game pad (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 rispetto all'asse verticale. Ad esempio, un valore logico pari a 0 non rappresenta alcuna rotazione e indica la pressione del pulsante Su, mentre un valore logico pari a 1 rappresenta una rotazione di 45 gradi e la pressione dei tasti Su e Sinistra.

4 MotionEvent

Controlli analogici¹	Utilizzo HID	Pulsante Android
Grilletto sinistro	0x02 0x00C5	AXIS_LTRIGGER
Grilletto 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 del dispositivo, consulta la sezione 2.3.1.

7.3. Sensori

Se le implementazioni del dispositivo includono un particolare tipo di sensore con un'API corrispondente per sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare questa API come descritto nella documentazione dell'SDK Android e nella documentazione Android Open Source sui sensori.

Implementazioni del dispositivo:

[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 dei sensori (ad esempio, restituendo true o false a seconda dei casi quando le applicazioni tentano di registrare listener, non chiamando i listener dei sensori quando i sensori corrispondenti non sono presenti e così via).

Se le implementazioni del dispositivo includono un particolare tipo di sensore che dispone di un'API corrispondente per sviluppatori di terze parti,

[C-1-1] DEVE segnalare tutte le misurazioni dei sensori utilizzando i valori pertinenti del Sistema internazionale di unità di misura (metriche) per ogni tipo di sensore, come definito nella documentazione dell'SDK Android.
[C-1-2] DEVE segnalare i dati dei sensori con una latenza massima di 100 millisecondi + 2 * sample_time nel caso di un flusso di sensori con una latenza massima richiesta di 0 ms quando il processore dell'applicazione è attivo. Questo ritardo non include eventuali ritardi di filtraggio.
[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 un'accuratezza pari a 0.
[C-1-4] Per qualsiasi API indicata dalla documentazione dell'SDK Android come sensore continuo, le implementazioni del dispositivo DEVONO fornire continuamente campioni di dati periodici che DOVREBBERO avere un jitter inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori timestamp segnalati tra eventi consecutivi.
[C-1-5] DEVE garantire che il flusso 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.
[C-1-6] DEVE segnalare l'ora dell'evento in nanosecondi, come definito nella documentazione dell'SDK Android, che rappresenta l'ora in cui si è verificato l'evento e sincronizzata con l'orologio SystemClock.elapsedRealtimeNano().
[C-SR-1] È FORTEMENTE CONSIGLIATO che l'errore di sincronizzazione del timestamp sia inferiore a 100 millisecondi e DOVREBBE essere inferiore a 1 millisecondo.
Quando vengono attivati più sensori, il consumo energetico NON DEVE superare la somma del consumo energetico segnalato di ogni sensore.

L'elenco riportato sopra non è esaustivo. Il comportamento documentato dell'SDK Android e le documentazioni open source di Android sui sensori devono essere considerati autorevoli.

Se le implementazioni del dispositivo includono un particolare tipo di sensore che dispone di un'API corrispondente per sviluppatori di terze parti,

[C-1-6] DEVE impostare una risoluzione diversa da zero per tutti i sensori e segnalare il valore tramite il metodo API Sensor.getResolution().

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

Implementazioni del dispositivo:

DEVE implementare questi tipi di sensori, quando includono i sensori fisici prerequisiti come descritto in Tipi di sensori.

Se le implementazioni dei dispositivi includono un sensore composito:

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

Se le implementazioni del dispositivo includono un particolare tipo di sensore con un'API corrispondente per sviluppatori di terze parti e il sensore segnala un solo valore, le implementazioni del dispositivo:

[C-3-1] DEVE impostare la risoluzione su 1 per il sensore e segnalare il valore tramite il metodo API Sensor.getResolution().

Se le implementazioni del dispositivo includono un particolare tipo di sensore che supporta SensorAdditionalInfo#TYPE_VEC3_CALIBRATION e il sensore è esposto a sviluppatori di terze parti, questi:

[C-4-1] NON DEVE includere parametri di calibrazione fissi e determinati in fabbrica nei dati forniti.

Se le implementazioni dei dispositivi includono una combinazione di accelerometro a 3 assi, un sensore giroscopio a 3 assi o un sensore magnetometro, sono:

[C-SR-2] VIVAMENTE CONSIGLIATO per garantire che l'accelerometro, il giroscopio e il magnetometro abbiano una posizione relativa fissa, in modo che se il dispositivo è trasformabile (ad es. pieghevole), gli assi del sensore rimangano allineati e coerenti con il sistema di coordinate del sensore in tutti i possibili stati di trasformazione del dispositivo.

7.3.1. Accelerometro

Implementazioni del dispositivo:

[C-SR-1] È VIVAMENTE CONSIGLIATO includere un accelerometro a 3 assi.

Se le implementazioni del dispositivo includono un accelerometro:

[C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
[C-1-3] DEVE rispettare il sistema di coordinate dei sensori Android come descritto nelle API Android.
[C-1-4] DEVE essere in grado di misurare dalla caduta libera fino a quattro volte il valore di gravity(4g) 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 per asse su campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più rapida.
DEVE segnalare eventi fino ad almeno 200 Hz.
DOVREBBE avere una risoluzione di almeno 16 bit.
DEVE essere calibrato durante l'uso se le caratteristiche cambiano nel corso del ciclo di vita e compensato e conservare i parametri di compensazione tra i riavvii del dispositivo.
DEVE essere compensato in base alla temperatura.

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

[C-2-1] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER.
[C-SR-4] È VIVAMENTE CONSIGLIATO di implementare il sensore composito TYPE_SIGNIFICANT_MOTION.
[C-SR-5] Sono FORTEMENTE CONSIGLIATI per l'implementazione e la segnalazione del sensore TYPE_ACCELEROMETER_UNCALIBRATED. È FORTEMENTE CONSIGLIATO che i dispositivi Android soddisfino questo requisito, in modo da poter eseguire l'upgrade alla versione futura della piattaforma in cui questo potrebbe diventare OBBLIGATORIO.
DEVE implementare i sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento SDK Android.

Se le implementazioni del dispositivo includono un accelerometro con meno di 3 assi:

[C-3-1] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER_LIMITED_AXES.
[C-SR-6] Sono FORTEMENTE CONSIGLIATI per l'implementazione e la segnalazione del sensore TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

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

[C-4-1] La somma del loro consumo energetico DEVE sempre essere inferiore a 4 mW.
DOVREBBE essere inferiore a 2 mW e 0,5 mW quando il dispositivo si trova in una condizione dinamica o statica.

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

[C-5-1] DEVE implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
[C-SR-7] È VIVAMENTE CONSIGLIATO di implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

Se le implementazioni dei dispositivi includono un accelerometro a 3 assi, un giroscopio a 3 assi e un sensore magnetometro,

[C-6-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

7.3.2. Magnetometro

Implementazioni del dispositivo:

[C-SR-1] È FORTEMENTE CONSIGLIATO includere un magnetometro a 3 assi (bussola).

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

[C-1-1] DEVE implementare il sensore TYPE_MAGNETIC_FIELD.
[C-1-2] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 10 Hz e DOVREBBE segnalare eventi fino ad almeno 50 Hz.
[C-1-3] DEVE rispettare il sistema di coordinate dei sensori 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 di saturarsi.
[C-1-5] DEVE avere un valore di compensazione del ferro dolce 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 della polarizzazione del ferro duro e conservare i parametri di compensazione tra i riavvii del dispositivo.
[C-1-8] DEVE essere applicata la compensazione del ferro dolce. La calibrazione può essere eseguita durante l'uso o la produzione del dispositivo.
[C-1-9] DEVE avere una deviazione standard, calcolata per asse sui campioni raccolti in un periodo di almeno 3 secondi alla velocità di campionamento più rapida, non superiore a 1,5 µT; DOVREBBE avere una deviazione standard non superiore a 0,5 µT.
[C-1-10] DEVE implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED.

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

[C-2-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

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

POTREBBE 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:

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

7.3.3. GPS

Implementazioni del dispositivo:

[C-SR-1] È VIVAMENTE CONSIGLIATO includere un ricevitore GPS/GNSS.

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

[C-1-1] DEVE supportare gli output di posizione a una velocità di almeno 1 Hz quando richiesto 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 rapido per il primo fix), quando è connesso a una connessione a internet con velocità dati pari o superiore a 0,5 Mbps. Questo requisito viene in genere soddisfatto utilizzando una tecnica GPS/GNSS assistita o predittiva per ridurre al minimo il tempo di acquisizione del segnale GPS/GNSS (i dati di assistenza includono ora di riferimento, posizione di riferimento ed effemeridi/orologio del satellite).
- [C-1-6] Dopo aver eseguito questo calcolo della posizione, le implementazioni del dispositivo DEVONO determinare la propria posizione, in cielo aperto, entro 5 secondi, quando le richieste di localizzazione vengono riavviate, fino a un'ora dopo il calcolo iniziale della posizione, anche quando la richiesta successiva viene effettuata senza una connessione dati e/o dopo un ciclo di accensione.
In condizioni di cielo aperto dopo aver determinato la posizione, da 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 tracciare e segnalare simultaneamente tramite GnssStatus.Callback almeno 8 satelliti di una costellazione.
- DOVREBBE essere in grado di monitorare simultaneamente almeno 24 satelliti, da più costellazioni (ad es. GPS + almeno una tra Glonass, Beidou, Galileo).
[C-SR-2] È FORTEMENTE CONSIGLIATO continuare a fornire normali output di posizione GPS/GNSS tramite le API del fornitore di servizi di localizzazione GNSS durante una chiamata di emergenza.
[C-SR-3] È FORTEMENTE CONSIGLIATO segnalare le misurazioni GNSS di tutte le costellazioni monitorate (come riportato nei messaggi GnssStatus), ad eccezione di SBAS.
[C-SR-4] È FORTEMENTE CONSIGLIATO segnalare il controllo automatico del guadagno (AGC) e la frequenza della misurazione GNSS.
[C-SR-5] È FORTEMENTE CONSIGLIATO segnalare tutte le stime di accuratezza (inclusi Bearing, Speed e Vertical) come parte di ogni posizione GPS/GNSS.
[C-SR-6] È FORTEMENTE CONSIGLIATO segnalare le misurazioni GNSS non appena vengono trovate, anche se una posizione calcolata da GPS/GNSS non è ancora stata segnalata.
[C-SR-7] È FORTEMENTE CONSIGLIATO segnalare le pseudodistanze GNSS e le velocità delle pseudodistanze che, in condizioni di cielo aperto dopo aver determinato la posizione, da fermo o in movimento con un'accelerazione inferiore a 0, 2 metri al secondo al quadrato, sono sufficienti per calcolare la posizione entro 20 metri e la velocità entro 0, 2 metri al secondo, almeno il 95% delle volte.

7.3.4. Giroscopio

Implementazioni del dispositivo:

[C-SR-1] Sono VIVAMENTE CONSIGLIATI per includere un sensore giroscopico.

Se le implementazioni del dispositivo includono un giroscopio:

[C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
[C-1-4] DEVE avere una risoluzione di almeno 12 bit.
[C-1-5] DEVE essere compensato in temperatura.
[C-1-6] DEVE essere calibrato e compensato durante l'uso e 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 in base alla 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.
[C-SR-2] Si CONSIGLIA VIVAMENTE che l'errore di calibrazione sia inferiore a 0,01 rad/s quando il dispositivo è fermo a temperatura ambiente.
[C-SR-3] Sono FORTEMENTE CONSIGLIATI con una risoluzione di almeno 16 bit.
DEVE segnalare eventi fino ad almeno 200 Hz.

Se le implementazioni del dispositivo includono un giroscopio a 3 assi:

[C-2-1] DEVE implementare il sensore TYPE_GYROSCOPE.
[C-SR-4] Sono vivamente consigliati per l'implementazione TYPE_GYROSCOPE_UNCALIBRATED sensore.

Se le implementazioni del dispositivo includono un giroscopio con meno di 3 assi:

[C-3-1] DEVE implementare e segnalare il sensore TYPE_GYROSCOPE_LIMITED_AXES.
[C-SR-5] Sono FORTEMENTE CONSIGLIATI per l'implementazione e la segnalazione del sensore TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

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

[C-4-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

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

[C-5-1] DEVE implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
[C-SR-6] È FORTEMENTE CONSIGLIATO di implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometro

Implementazioni del dispositivo:

[C-SR-1] È VIVAMENTE CONSIGLIATO includere un barometro (sensore di pressione dell'aria ambiente).

Se le implementazioni del dispositivo includono un barometro:

[C-1-1] DEVE implementare e segnalare il sensore TYPE_PRESSURE.
[C-1-2] DEVE essere in grado di fornire eventi a 5 Hz o più.
[C-1-3] DEVE essere compensato in temperatura.
[C-SR-2] VIVAMENTE CONSIGLIATO per poter segnalare misurazioni della pressione nell'intervallo da 300 hPa a 1100 hPa.
DOVREBBE avere una precisione assoluta di 1 hPa.
DOVREBBE avere una precisione relativa di 0,12 hPa in un intervallo di 20 hPa (equivalente a una precisione di circa 1 m su una variazione di circa 200 m a livello del mare).

Implementazioni del dispositivo che dichiarano la proprietà di sistema sensor.barometer.high_quality.implemented:

[C-2-1] DEVE segnalare le misurazioni della pressione nell'intervallo compreso tra 300 hPa e 1100 hPa, con una precisione assoluta di +/- 1 hPa.
[C-2-2] DEVE avere una precisione relativa di 0,15 hPa in un intervallo di 100 hPa, equivalente a una precisione di circa 1 m su una variazione di circa 1000 m a livello del mare.
[C-2-3] DEVE essere stabile entro +/- 0, 5 hPa quando l'utente tocca, preme o stringe il dispositivo.
[C-2-4] DEVE essere stabile entro +/- 0,15 hPa quando l'utente cammina con il dispositivo in mano o in tasca.
[C-2-5] NON DEVE essere smussato con una costante di tempo superiore a 300 ms per le attivazioni superiori a 5 Hz e lo smussamento NON DEVE propagarsi tra le attivazioni dei sensori.
[C-2-6] DEVE essere stabile entro +/- 0, 15 hPa quando è esposto all'illuminazione e alle frequenze radio quotidiane introdotte da fonti comuni come Bluetooth, rete cellulare o Wi-Fi.

7.3.6. Termometro

Se le implementazioni dei dispositivi includono un termometro ambientale (sensore di temperatura), questi:

[C-1-1] DEVE definire SENSOR_TYPE_AMBIENT_TEMPERATURE per il sensore di temperatura ambiente e il sensore DEVE misurare la temperatura (abitacolo del veicolo/stanza) ambiente da dove l'utente interagisce con il dispositivo in gradi Celsius.

Se le implementazioni dei dispositivi includono un sensore termometro che misura una temperatura diversa da quella ambiente, ad esempio la temperatura della CPU:

[C-2-1] NON DEVE definire SENSOR_TYPE_AMBIENT_TEMPERATURE per il sensore di temperatura.

Se le implementazioni del dispositivo includono un sensore per il monitoraggio della temperatura cutanea, questi:

[C-SR-1] Sono FORTEMENTE CONSIGLIATI per supportare l'API PowerManager.getThermalHeadroom.

7.3.7. Fotometro

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

7.3.8. Sensore di prossimità

Le implementazioni del dispositivo POSSONO includere un sensore di prossimità.

Se le implementazioni dei dispositivi includono un sensore di prossimità e segnalano solo una lettura binaria "vicino" o "lontano",

[C-1-1] DEVE misurare la prossimità di un oggetto nella stessa direzione dello schermo. ovvero il sensore di prossimità DEVE essere orientato per rilevare oggetti vicini allo schermo, in quanto lo scopo principale di questo tipo di sensore è rilevare un telefono in uso da parte dell'utente. Se le implementazioni del dispositivo includono un sensore di prossimità con un orientamento diverso, NON deve essere accessibile tramite questa API.
[C-1-2] DEVE avere una precisione di almeno 1 bit.
[C-1-3] DEVE utilizzare 0 centimetri come lettura da vicino e 5 centimetri come lettura da lontano.
[C-1-4] DEVE segnalare un intervallo massimo e una risoluzione di 5.

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 ad app di terze parti,

[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, devono:

[C-2-1] DEVE avere un sensore TYPE_ACCELEROMETER che:
- DEVE avere un intervallo di misurazione compreso tra almeno -8 g e +8 g ed è FORTEMENTE CONSIGLIATO che abbia un intervallo di misurazione compreso tra almeno -16 g e +16 g.
- DEVE avere una risoluzione di misurazione di almeno 2048 LSB/g.
- DEVE avere una frequenza di misurazione minima di 12,5 Hz o inferiore.
- DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DEVE supportare SensorDirectChannel RATE_VERY_FAST.
- DEVE avere un rumore di misurazione non superiore a 400 μg/√Hz.
- DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore.
- DEVE avere un consumo energetico di batch non superiore a 3 mW.
- [C-SR-1] È FORTEMENTE CONSIGLIATO avere una larghezza di banda di misurazione di 3 dB di almeno l'80% della frequenza di Nyquist e uno spettro di rumore bianco all'interno di questa larghezza di banda.
- DEVE avere una passeggiata casuale di accelerazione inferiore a 30 μg √Hz testata a temperatura ambiente.
- DOVREBBE avere una variazione della distorsione rispetto alla temperatura di ≤ +/- 1 mg/°C.
- DOVREBBE avere una non linearità della retta di migliore adattamento ≤ 0,5% e una variazione della sensibilità rispetto alla temperatura ≤ 0,03%/°C.
- DEVE avere una sensibilità all'asse trasversale < 2,5 % e una variazione della sensibilità all'asse trasversale < 0,2% nell'intervallo di temperature di funzionamento del dispositivo.
[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 di 12,5 Hz o inferiore.
- DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DEVE supportare SensorDirectChannel RATE_VERY_FAST.
- DEVE avere un rumore di misurazione non superiore a 0,014 °/s/√Hz.
- [C-SR-2] È FORTEMENTE CONSIGLIATO avere una larghezza di banda di misurazione di 3 dB di almeno l'80% della frequenza di Nyquist e uno spettro di rumore bianco all'interno di questa larghezza di banda.
- DEVE avere una passeggiata casuale della velocità inferiore a 0,001 °/s √Hz testata a temperatura ambiente.
- DOVREBBE avere una variazione di bias rispetto alla temperatura ≤ +/- 0,05 °/ s / °C.
- DOVREBBE avere una variazione di sensibilità rispetto alla temperatura ≤ 0,02% / °C.
- DEVE avere una non linearità della linea di miglior adattamento ≤ 0,2%.
- DEVE avere una densità di rumore ≤ 0,007 °/s/√Hz.
- DOVREBBE avere un errore di calibrazione inferiore a 0,002 rad/s nell'intervallo di temperatura 10 ~ 40 °C quando il dispositivo è fermo.
- DOVREBBE avere una sensibilità all'accelerazione inferiore a 0,1 °/s/g.
- DEVE avere una sensibilità all'asse trasversale < 4,0 % e una variazione della sensibilità all'asse trasversale < 0,3% nell'intervallo di temperature di funzionamento del dispositivo.
[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 μT.
- DEVE avere una risoluzione di misurazione di almeno 5 LSB/uT.
- DEVE avere una frequenza di misurazione minima di 5 Hz o inferiore.
- DEVE avere una frequenza di misurazione massima di 50 Hz o superiore.
- DEVE avere un rumore di misurazione non superiore a 0,5 μT.
[C-2-6] DEVE avere un TYPE_MAGNETIC_FIELD_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GEOMAGNETIC_FIELD e, in aggiunta:
- DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 600 eventi del sensore.
- [C-SR-3] È VIVAMENTE CONSIGLIATO avere uno spettro di rumore bianco da 1 Hz ad almeno 10 Hz quando la frequenza di report è 50 Hz o superiore.
[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 di 1 Hz o inferiore.
- DEVE avere una frequenza di misurazione massima di 10 Hz o superiore.
- DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz.
- DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
- DEVE avere un consumo energetico di batching non superiore a 2 mW.
[C-2-8] DEVE avere un sensore TYPE_GAME_ROTATION_VECTOR.
[C-2-9] DEVE avere un sensore TYPE_SIGNIFICANT_MOTION che:
- DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
[C-2-10] DEVE avere un sensore TYPE_STEP_DETECTOR che:
- DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 100 eventi del sensore.
- DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
- DEVE avere un consumo energetico di batch non superiore a 4 mW.
[C-2-11] DEVE avere un sensore TYPE_STEP_COUNTER che:
- DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
[C-2-12] DEVE avere un sensore TILT_DETECTOR che:
- DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
[C-2-13] Il timestamp dell'evento fisico riportato da accelerometro, giroscopio e magnetometro DEVE essere compreso in un intervallo di 2, 5 millisecondi l'uno dall'altro. Il timestamp dell'evento fisico riportato dall'accelerometro e dal giroscopio DOVREBBE essere entro 0,25 millisecondi l'uno dall'altro.
[C-2-14] MUST have Gyroscope sensor event timestamps on the same time base as the camera subsystem and within 1 milliseconds of error.
[C-2-15] DEVE fornire campioni alle applicazioni entro 5 millisecondi dal momento in cui i dati sono disponibili su uno qualsiasi dei sensori fisici sopra indicati.
[C-2-16] NON DEVE avere un consumo energetico superiore a 0,5 mW quando il dispositivo è statico e a 2,0 mW quando il dispositivo è in movimento quando è attivata una qualsiasi combinazione dei seguenti sensori:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] POTREBBE 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 del processore dell'applicazione. È inclusa la potenza assorbita dall'intera catena di sensori: il sensore, qualsiasi circuito di supporto, qualsiasi sistema di elaborazione dei sensori dedicato e così via.

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

[C-3-1] DEVE dichiarare correttamente il supporto dei tipi di canali diretti e del livello di tassi di segnalazione 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
DEVE supportare la generazione di report sugli eventi tramite il canale diretto del sensore per il sensore primario (variante non di riattivazione) dei seguenti tipi:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensori biometrici

Per ulteriori informazioni sulla misurazione della sicurezza dello sblocco biometrico, consulta la documentazione sulla misurazione della sicurezza biometrica.

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

DEVE includere un sensore biometrico

I sensori biometrici possono essere classificati come Classe 3 (in precedenza Forte),

Classe 2 (in precedenza Debole) o Classe 1 (in precedenza Comodità) in base ai tassi di accettazione di spoofing e impostori e alla sicurezza della pipeline biometrica. Questa classificazione determina le funzionalità che il sensore biometrico deve interfacciare con la piattaforma e con le applicazioni di terze parti. I sensori devono soddisfare requisiti aggiuntivi, come descritto di seguito, se vogliono essere classificati come Classe 1, Classe 2 o Classe 3. Le biometrie di Classe 2 e Classe 3 ottengono funzionalità aggiuntive come descritto di seguito.

Se le implementazioni dei dispositivi rendono disponibile un sensore biometrico ad applicazioni di terze parti tramite android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, queste:

[C-4-1] DEVE soddisfare i requisiti per la biometria di classe 3 o classe 2 come definito in questo documento.
[C-4-2] DEVE riconoscere e rispettare ogni nome di parametro definito come costante nella classe Authenticators e qualsiasi combinazione. Al contrario, NON DEVE onorare o riconoscere le costanti intere passate ai metodi canAuthenticate(int) e setAllowedAuthenticators(int) diversi da quelli documentati come costanti pubbliche in Authenticators e qualsiasi loro combinazione.
[C-4-3] DEVE implementare l'intent ACTION_BIOMETRIC_ENROLL sui dispositivi con biometria di classe 3 o classe 2. Questa azione DEVE presentare solo i punti di accesso alla registrazione per la biometria di classe 3 o di classe 2.
[C-4-4] DEVONO consentire alle applicazioni di aggiungere contenuti personalizzati a BiometricPrompt utilizzando i formati di visualizzazione dei contenuti PromptContentView. I formati di visualizzazione dei contenuti NON DEVONO essere estesi per consentire immagini, link, contenuti interattivi o altre forme di media che non fanno già parte dell'API BiometricPrompt. È possibile apportare modifiche stilistiche che non alterino, oscurino o tronchino questi contenuti (ad esempio modificando posizione, spaziatura interna, margini e tipografia).

Se le implementazioni dei dispositivi supportano la biometria passiva:

[C-5-1] DEVE richiedere per impostazione predefinita un passaggio di conferma aggiuntivo (ad es. la pressione di un pulsante).
[C-SR-1] È FORTEMENTE CONSIGLIATO di disporre di un'impostazione che consenta agli utenti di ignorare le preferenze dell'applicazione e richiedere sempre un passaggio di conferma aggiuntivo.
[C-SR-2] È FORTEMENTE CONSIGLIATO che l'azione di conferma sia protetta in modo che non possa essere falsificata da una compromissione del sistema operativo o del kernel. Ad esempio, ciò significa che l'azione di conferma basata su un pulsante fisico viene indirizzata tramite un pin di input/output (GPIO) per uso generico solo di input di un Secure Element (SE) che non può essere azionato in altro modo se non tramite la pressione di un pulsante fisico.
[C-5-2] DEVE inoltre implementare un flusso di autenticazione implicita (senza passaggio di conferma) corrispondente a setConfirmationRequired(boolean), che le applicazioni possono impostare per l'utilizzo per i flussi di accesso.

Se le implementazioni dei dispositivi hanno più sensori biometrici:

[C-7-1] DEVE, quando una biometria è bloccata (ovvero la biometria è disattivata finché l'utente non sblocca con l'autenticazione principale) o blocco temporaneo (ovvero la biometria è disattivata temporaneamente finché l'utente non attende un intervallo di tempo) a causa di troppi tentativi non riusciti, bloccare anche tutte le altre biometrie di una classe biometrica inferiore. In caso di blocco temporaneo, il tempo di backoff per la verifica biometrica DEVE essere il tempo di backoff massimo di tutte le biometrie nel blocco temporaneo.
[C-SR-12] Sono FORTEMENTE CONSIGLIATE, quando una biometria è bloccata (ovvero la biometria è disattivata finché l'utente non sblocca con l'autenticazione principale) o blocco temporaneo (ovvero la biometria è disattivata temporaneamente finché l'utente non attende un intervallo di tempo) a causa di troppi tentativi non riusciti, per bloccare anche tutte le altre biometrie della stessa classe. In caso di blocco temporaneo, il tempo di backoff per la verifica biometrica è FORTEMENTE CONSIGLIATO per essere il tempo di backoff massimo di tutte le biometrie nel blocco temporaneo.
[C-7-2] DEVE richiedere all'utente l'autenticazione principale consigliata (ad esempio PIN, sequenza o password) per reimpostare il contatore dei blocchi per una biometria bloccata. Le biometriche di Classe 3 POSSONO essere autorizzate a reimpostare il contatore di blocco per una biometria bloccata della stessa classe o di una classe inferiore. Le biometrie di Classe 2 o Classe 1 NON DEVONO essere consentite per completare un'operazione di blocco del ripristino per qualsiasi biometria.
[C-SR-3] È FORTEMENTE CONSIGLIATO richiedere la conferma di una sola biometria per autenticazione (ad es. se sul dispositivo sono disponibili sia il sensore di impronta che quello facciale, onAuthenticationSucceeded deve essere inviato dopo la conferma di uno dei due).

Affinché le implementazioni dei dispositivi consentano l'accesso alle chiavi del keystore ad applicazioni di terze parti, devono:

[C-6-1] DEVE soddisfare i requisiti per la classe 3 definiti in questa sezione di seguito.
[C-6-2] DEVE presentare solo dati biometrici di classe 3 quando l'autenticazione richiede BIOMETRIC_STRONG o quando l'autenticazione viene richiamata con un CryptoObject.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 1 (in precedenza Comodità), devono:

[C-1-1] DEVE avere un tasso di falsa accettazione inferiore allo 0,002%.
[C-1-2] DEVE comunicare che questa modalità potrebbe essere meno sicura di un PIN, una sequenza o una password efficaci ed elencare chiaramente i rischi della sua attivazione, se i tassi di accettazione di spoofing e impostori sono superiori al 7%, come misurato dai protocolli di test biometrici di Android.
[C-1-9] DEVE richiedere all'utente l'autenticazione primaria consigliata (ad es. PIN, sequenza, password) dopo non più di venti tentativi errati e non meno di novanta secondi di tempo di attesa per la verifica biometrica, dove un tentativo errato è uno con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a una biometria registrata.
[C-SR-4] Sono FORTEMENTE CONSIGLIATI per ridurre il numero totale di prove false per la verifica biometrica specificata in [C-1-9] se i tassi di accettazione di spoofing e impostori sono superiori al 7%, come misurato dai protocolli di test biometrici di Android.
[C-1-3] MUST rate limit attempts for biometric verification - where a false trial is one with an adequate capture quality (BIOMETRIC_ACQUIRED_GOOD) that does not match an enrolled biometric.
[C-SR-5] È FORTEMENTE CONSIGLIATO di limitare la frequenza dei tentativi per almeno 30 secondi dopo cinque tentativi errati di verifica biometrica per il numero massimo di tentativi errati per [C-1-9]. Un tentativo errato è un tentativo con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a una biometria registrata.
[C-SR-6] È FORTEMENTE CONSIGLIATO di avere tutta la logica di limitazione della frequenza in TEE.
[C-1-10] DEVE disattivare la biometria una volta che il backoff dell'autenticazione principale è stato attivato per la prima volta, come descritto in [C-0-2] della sezione 9.11.
[C-1-11] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 30%, con (1) un tasso di accettazione di spoofing e impostori per le specie di strumenti di attacco di presentazione (PAI) di livello A non superiore al 30% e (2) un tasso di accettazione di spoofing e impostori per le specie di PAI di livello B non superiore al 40%, come misurato dai protocolli di test biometrici di Android.
[C-1-4] DEVE impedire l'aggiunta di nuove biometrie senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare le credenziali esistenti o di aggiungere nuove credenziali del dispositivo (PIN/sequenza/password) protette da TEE; l'implementazione di Android Open Source Project fornisce il meccanismo nel framework per farlo.
[C-1-5] DEVE rimuovere completamente tutti i dati biometrici identificabili di un utente quando l'account dell'utente viene rimosso (anche tramite un ripristino dei dati di fabbrica) o quando viene rimossa l'autenticazione principale consigliata (ad esempio PIN, sequenza, password).
[C-1-6] DEVE rispettare il flag individuale per quella biometria (ad es. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE, o DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
[C-1-7] DEVE richiedere all'utente l'autenticazione principale consigliata (ad esempio PIN, sequenza, password) una volta ogni 24 ore o meno.
[C-1-8] DEVE richiedere all'utente l'autenticazione primaria consigliata (ad esempio PIN, sequenza, password) o biometrica di Classe 3 (FORTE) dopo che si è verificato uno dei seguenti eventi:
- Un periodo di timeout di inattività di 4 ore.
- 3 tentativi di autenticazione biometrica non riusciti.
- Il periodo di timeout di inattività e il conteggio dei tentativi di autenticazione non riusciti vengono reimpostati dopo qualsiasi conferma riuscita delle credenziali del dispositivo.
[C-SR-7] È VIVAMENTE CONSIGLIATO di utilizzare la logica nel framework fornito da Android Open Source Project per applicare i vincoli specificati in [C-1-7] e [C-1-8] per i nuovi dispositivi.
[C-SR-8] È FORTEMENTE CONSIGLIATO che abbiano un tasso di falsi rifiuti inferiore al 10%, misurato sul dispositivo.
[C-SR-9] È FORTEMENTE CONSIGLIATO che abbiano una latenza inferiore a 1 secondo, misurata dal momento in cui viene rilevata la biometria fino allo sblocco dello schermo, per ogni biometria registrata.
[C-1-12] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 40% per specie di strumento di attacco di presentazione (PAI), misurato dai protocolli di test biometrici di Android.
[C-SR-13] È FORTEMENTE CONSIGLIATO che abbiano un tasso di accettazione di spoofing e impostori non superiore al 30% per specie di strumento di attacco di presentazione (PAI), misurato dai protocolli di test biometrici di Android.
[C-SR-8] È FORTEMENTE CONSIGLIATO che abbiano un tasso di falsi rifiuti inferiore al 10%, misurato sul dispositivo.
[C-1-15] DEVE consentire agli utenti di rimuovere una o più registrazioni biometriche.
[C-SR-14] Sono FORTEMENTE CONSIGLIATI di divulgare la classe biometrica del sensore biometrico e i rischi corrispondenti della sua attivazione.
[C-SR-17] È VIVAMENTE CONSIGLIATO di implementare le nuove interfacce AIDL (ad esempio IFace.aidl e IFingerprint.aidl).

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 2 (in precedenza Debole), devono:

[C-2-1] DEVE soddisfare tutti i requisiti per la classe 1 sopra indicati.
[C-2-2] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 20%, con (1) un tasso di accettazione di spoofing e impostori per specie di strumenti di attacco di presentazione (PAI) di livello A non superiore al 20%, e (2) un tasso di accettazione di spoofing e impostori di specie di PAI di livello B non superiore al 30%, misurato dai protocolli di test biometrici di Android.
[C-SR-15] È FORTEMENTE CONSIGLIATO che abbiano un tasso di accettazione di spoofing e impostori non superiore al 20% per specie di strumento di attacco di presentazione (PAI), misurato dai protocolli di test biometrici di Android.
[C-2-3] DEVE eseguire la corrispondenza biometrica in un ambiente di esecuzione isolato al di fuori dello spazio utente o del kernel di Android, ad esempio il Trusted Execution Environment (TEE), su un chip con un canale sicuro per l'ambiente di esecuzione isolato o su una macchina virtuale protetta che soddisfi i requisiti della sezione 9.17.
[C-2-4] DEVE avere tutti i dati identificabili criptati e autenticati crittograficamente in modo che non possano essere acquisiti, letti o alterati al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro per l'ambiente di esecuzione isolato, come documentato nelle linee guida per l'implementazione sul sito del progetto Android Open Source Project o in una macchina virtuale protetta controllata da un hypervisor che soddisfi i requisiti della sezione 9.17.
[C-2-5] Per la biometria basata sulla videocamera, durante l'autenticazione o la registrazione biometrica:
- DEVE utilizzare la videocamera in una modalità che impedisca la lettura o l'alterazione dei frame della videocamera al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro per l'ambiente di esecuzione isolato o di una macchina virtuale protetta controllata dall'hypervisor che soddisfa i requisiti della sezione 9.17.
- Per le soluzioni RGB a singola videocamera, i frame della videocamera POSSONO essere leggibili al di fuori dell'ambiente di esecuzione isolato per supportare operazioni come l'anteprima per la registrazione, ma NON DEVONO comunque essere modificabili.
[C-2-6] NON DEVE consentire ad applicazioni di terze parti di distinguere tra registrazioni biometriche individuali.
[C-2-7] NON DEVE consentire l'accesso non criptato a dati biometrici identificabili o a qualsiasi dato derivato da questi (come gli incorporamenti) al processore dell'applicazione al di fuori del contesto del TEE o della macchina virtuale protetta controllata dall'hypervisor che soddisfa i requisiti della sezione 9.17. L'upgrade dei dispositivi lanciati con Android 9 o versioni precedenti non è esente da [C-2-7].
[C-2-8] DEVE disporre di una pipeline di elaborazione sicura in modo che la compromissione di un sistema operativo o di un kernel non possa consentire l'inserimento diretto di dati per l'autenticazione fraudolenta come utente.

Nota: se le implementazioni dei dispositivi sono già state lanciate su Android 9 o versioni precedenti e non soddisfano il requisito [C-2-8] tramite un aggiornamento del software di sistema, POTREBBERO essere esentate dal requisito.
[C-SR-10] È FORTEMENTE CONSIGLIATO includere il rilevamento della vitalità per tutte le modalità biometriche e il rilevamento dell'attenzione per la biometria del volto.
[C-2-9] DEVE rendere disponibile il sensore biometrico ad applicazioni di terze parti.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 3 (in precedenza Efficace), devono:

[C-3-1] DEVE soddisfare tutti i requisiti della Classe 2 sopra indicati, ad eccezione di [C-1-7] e [C-1-8].
[C-3-2] DEVE avere un'implementazione di un archivio chiavi basato su crittografia hardware.
[C-3-3] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 7%, con (1) un tasso di accettazione di spoofing e impostori per specie di strumenti di attacco alla presentazione (PAI) di livello A non superiore al 7% e (2) un tasso di accettazione di spoofing e impostori di specie di PAI di livello B non superiore al 20%, misurato dai protocolli di test biometrici di Android.
[C-3-4] DEVE richiedere all'utente l'autenticazione principale consigliata (ad esempio PIN, sequenza, password) una volta ogni 72 ore o meno.
[C-3-5] DEVE rigenerare l'ID autenticatore per tutte le biometrie di classe 3 supportate sul dispositivo se una di queste viene registrata nuovamente.
[C-3-6] È necessario attivare le chiavi del keystore supportate dalla biometria per le applicazioni di terze parti.
[C-SR-16] È FORTEMENTE CONSIGLIATO che abbiano un tasso di accettazione di spoofing e impostori non superiore al 7% per specie di strumento di attacco di presentazione (PAI), misurato dai protocolli di test biometrici di Android.

Se le implementazioni del dispositivo contengono un sensore di impronte digitali integrato nel display (UDFPS), devono:

[C-SR-11] Sono VIVAMENTE CONSIGLIATI per evitare che l'area sensibile al tocco di UDFPS interferisca con la navigazione con tre pulsanti (che alcuni utenti potrebbero richiedere per motivi di accessibilità).

7.3.11. Sensore di postura

Implementazioni del dispositivo:

POTREBBE supportare il sensore di postura con 6 gradi di libertà.

Se le implementazioni dei dispositivi supportano il sensore di postura con 6 gradi di libertà:

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

7.3.12. Sensore dell'angolo della cerniera

Se le implementazioni dei dispositivi supportano un sensore dell'angolo della cerniera:

[C-1-1] MUST implement and report TYPE_HINGE_ANGLE.
[C-1-2] DEVE supportare almeno due letture tra 0 e 360 gradi (inclusi 0 e 360 gradi).
[C-1-3] MUST return a wakeup sensor for getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Se le implementazioni dei dispositivi includono il supporto di 802.1.15.4 ed espongono la funzionalità a un'applicazione di terze parti, queste:

[C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.uwb.
[C-1-3] DEVE supportare tutti i seguenti set di configurazione (combinazioni predefinite di parametri FIRA UCI) definiti nell'implementazione AOSP.
- CONFIG_ID_1: ranging unicast STATIC STS DS-TWR definito da FiRa, modalità differita, intervallo di ranging 240 ms.
- CONFIG_ID_2: misurazione della distanza da uno a molti definita da FiRa STATIC STS DS-TWR, modalità differita, intervallo di misurazione della distanza di 200 ms. Caso d'uso tipico: lo smartphone interagisce con molti dispositivi smart.
- CONFIG_ID_3: come CONFIG_ID_1, tranne che i dati sull'angolo di arrivo (AoA) non vengono segnalati.
- CONFIG_ID_4: come CONFIG_ID_1, tranne per il fatto che la modalità di sicurezza P-STS è attivata.
- CONFIG_ID_5: come CONFIG_ID_2, tranne per il fatto che la modalità di sicurezza P-STS è attivata.
- CONFIG_ID_6: come CONFIG_ID_3, tranne per il fatto che la modalità di sicurezza P-STS è attivata.
- CONFIG_ID_7: come CONFIG_ID_2, tranne per il fatto che è attivata la modalità di chiave di controllo individuale P-STS.
[C-1-4] DEVE fornire un'interfaccia utente che consenta all'utente di attivare/disattivare la radio UWB.
[C-1-5] DEVE imporre che le app che utilizzano la radio UWB dispongano dell'autorizzazione UWB_RANGING (nel gruppo di autorizzazioni NEARBY_DEVICES).

Il superamento dei test di conformità e certificazione pertinenti definiti dalle organizzazioni di standardizzazione, tra cui FIRA, CCC e CSA, contribuisce a garantire il corretto funzionamento di 802.1.15.4.

7.3.14. Sensori personalizzati

Per contribuire a fornire un'esperienza differenziata, le implementazioni dei dispositivi POSSONO includere sensori aggiuntivi non coperti da Android o Wear OS, a cui le app precaricate possono accedere.

Per questi sensori, l'ID sensore:

[C-0-1] MUST be higher than 65536.

Se il sensore personalizzato è destinato a scopi correlati alla salute o al fitness:

[C-0-2] DEVE essere protetto da un'autorizzazione della piattaforma o del sistema.

7.4. Connettività dei dati

7.4.1. Telefonia

Il termine "telefonia" utilizzato dalle API Android e in questo documento si riferisce specificamente all'hardware correlato all'effettuazione di chiamate vocali e all'invio di messaggi SMS o all'attivazione dei dati mobili tramite una rete mobile (ad es. GSM, CDMA, LTE, NR) GSM o CDMA. Un dispositivo che supporta la "telefonia" può scegliere di offrire alcuni o tutti i servizi di chiamata, messaggistica e dati in base al prodotto.

Android PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. ovvero Android è compatibile con dispositivi diversi dagli smartphone.

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

[C-1-1] DEVE dichiarare il flag della funzionalità android.hardware.telephony e altri flag delle funzionalità secondarie in base alla tecnologia.
[C-1-2] DEVE implementare il supporto completo per l'API per quella tecnologia.
DEVE consentire tutti i tipi di servizi di telefonia mobile disponibili (2G, 3G, 4G, 5G e così via) durante le chiamate di emergenza (indipendentemente dai tipi di rete impostati da SetAllowedNetworkTypeBitmap()).

Se le implementazioni dei dispositivi non includono hardware di telefonia:

[C-2-1] MUST implement the full APIs as no-ops.

Se le implementazioni dei dispositivi supportano eUICCs o eSIM/SIM integrate e includono un meccanismo proprietario per rendere disponibile la funzionalità eSIM per sviluppatori di terze parti,

[C-3-1] DEVE dichiarare il flag funzionalità android.hardware.telephony.euicc.

Se le implementazioni del dispositivo non impostano la proprietà di sistema ro.telephony.iwlan_operation_mode su legacy:

[C-4-1] NON DEVE segnalare NETWORK_TYPE_IWLAN tramite NetworkRegistrationInfo#getAccessNetworkTechnology() quando NetworkRegistrationInfo#getTransportType() viene segnalato come TRANSPORT_TYPE_WWAN per la stessa istanza NetworkRegistrationInfo.

Se le implementazioni dei dispositivi supportano una singola registrazione IP Multimedia Subsystem (IMS) sia per il servizio di telefonia multimediale (MMTEL) sia per le funzionalità di Rich Communication Services (RCS) e devono rispettare i requisiti degli operatori di telefonia mobile relativi all'utilizzo di una singola registrazione IMS per tutto il traffico di segnalazione IMS:

[C-5-1] DEVE dichiarare il android.hardware.telephony.ims flag della funzionalità e fornire un'implementazione completa dell'API ImsService sia per MMTEL che per RCS API User Capability Exchange.
[C-5-2] DEVE dichiarare il flag di funzionalità android.hardware.telephony.ims.singlereg e fornire un'implementazione completa dell'API SipTransport, dell'API GbaService, delle indicazioni di bearer dedicati utilizzando IRadio 1.6 HAL e del provisioning tramite Auto Configuration Server (ACS) o altro meccanismo di provisioning proprietario utilizzando l'API IMS Configuration.

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

[C-6-1] SmsManager#sendTextMessage e SmsManager#sendMultipartTextMessage DEVONO comportare chiamate corrispondenti a CarrierMessagingService per fornire la funzionalità di messaggistica. SmsManager#sendMultimediaMessage e SmsManager#downloadMultimediaMessage DEVONO comportare chiamate corrispondenti a CarrierMessagingService per fornire funzionalità di messaggistica multimediale.
[C-6-2] L'applicazione designata da android.provider.Telephony.Sms#getDefaultSmsPackage DEVE utilizzare le API SmsManager per l'invio e la ricezione di messaggi SMS e MMS. L'implementazione di riferimento AOSP in packages/apps/Messaging soddisfa questo requisito.
[C-6-3] L'applicazione che risponde a Intent#ACTION_DIAL DEVE supportare l'inserimento di codici del dialer arbitrari formattati come *#*#CODE#*#* e attivare una trasmissione TelephonyManager#ACTION_SECRET_CODE corrispondente.
[C-6-4] L'applicazione che risponde a Intent#ACTION_DIAL DEVE utilizzare VoicemailContract.Voicemails#TRANSCRIPTION per mostrare agli utenti la trascrizione della segreteria trascritta, se la supporta.
[C-6-5] DEVE rappresentare tutte le SubscriptionInfo con UUID di gruppo equivalenti come un unico abbonamento in tutte le funzionalità visibili agli utenti che mostrano e controllano le informazioni della scheda SIM. Esempi di queste funzionalità includono interfacce di impostazioni che corrispondono a Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS o EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
[C-6-6] NON DEVE mostrare o consentire il controllo di alcun SubscriptionInfo con un UUID gruppo non nullo e un bit opportunistico in qualsiasi funzionalità visibile all'utente che consente la configurazione o il controllo delle impostazioni della scheda SIM.

Se i report sulle implementazioni del dispositivo segnalano la funzionalità android.hardware.telephony e forniscono una barra di stato del sistema, allora:

[C-7-1] DEVE selezionare un abbonamento attivo rappresentativo per un determinato UUID gruppo da mostrare all'utente in qualsiasi funzionalità che fornisca informazioni sullo stato della SIM. Alcuni esempi di tali inviti includono l'icona del segnale cellulare nella barra di stato o il riquadro Impostazioni rapide.
[C-SR-1] È VIVAMENTE CONSIGLIATO scegliere l'abbonamento rappresentativo come abbonamento dati attivo a meno che il dispositivo non sia in una chiamata vocale, durante la quale è VIVAMENTE CONSIGLIATO che l'abbonamento rappresentativo sia l'abbonamento vocale attivo.

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

[C-6-7] DEVE essere in grado di aprire e utilizzare contemporaneamente il numero massimo di canali logici (20 in totale) per ogni UICC secondo ETSI TS 102 221.
[C-6-8] NON DEVE applicare nessuno dei seguenti comportamenti alle app dell'operatore attive (come indicato da TelephonyManager#getCarrierServicePackageName) automaticamente o senza la conferma esplicita dell'utente:
- Revocare o limitare l'accesso alla rete
- Revoca delle autorizzazioni
- Limitare l'esecuzione delle app in background o in primo piano oltre alle funzionalità di gestione dell'alimentazione esistenti incluse in AOSP
- Disattivare o disinstallare l'app

Se le implementazioni del dispositivo segnalano la funzionalità android.hardware.telephony e tutti gli abbonamenti non opportunistici che condividono un UUID di gruppo sono disattivati, rimossi fisicamente dal dispositivo o contrassegnati come opportunistici, il dispositivo:

[C-8-1] DEVE disattivare automaticamente tutti gli abbonamenti opportunistici attivi rimanenti nello stesso gruppo.

Se le implementazioni dei dispositivi includono la telefonia GSM, ma non la telefonia CDMA:

[C-9-1] MUST NOT declare PackageManager#FEATURE_TELEPHONY_CDMA.
[C-9-2] DEVE generare un IllegalArgumentException in caso di tentativi di impostazione di tipi di rete 3GPP2 in maschere di bit di tipi di rete preferiti o consentiti.
[C-9-3] DEVE restituire una stringa vuota da TelephonyManager#getMeid.

Se le implementazioni del dispositivo supportano eUICC con più porte e profili, questi:

[C-10-1] DEVE dichiarare il flag funzionalità android.hardware.telephony.euicc.mep.

Se le implementazioni dei dispositivi supportano la connettività dati cellulare:

[C-SR-11] È FORTEMENTE CONSIGLIATO dichiarare la funzionalità android.hardware.telephony.data.

Se le implementazioni dei dispositivi segnalano android.hardware.telephony.data, significa che:

[C-12-1] DEVE supportare almeno due connessioni di rete dati cellulare simultanee, ad esempio contesti PDP, connessioni PDN e connessioni DN.

7.4.1.1. Compatibilità con il blocco dei numeri

Se le implementazioni dei dispositivi segnalano la funzionalità android.hardware.telephony.calling,

[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 provenienti da un numero di telefono in BlockedNumberProvider senza alcuna interazione con le app. L'unica eccezione è quando il blocco dei numeri viene temporaneamente rimosso come descritto nella documentazione dell'SDK.
[C-1-4] DEVE scrivere al provider del registro chiamate della piattaforma per una chiamata bloccata e DEVE filtrare le chiamate con BLOCKED_TYPE dalla visualizzazione predefinita del registro chiamate nell'app Telefono preinstallata.
[C-1-5] NON DEVE scrivere al provider di telefonia per un messaggio bloccato.
[C-1-6] DEVE implementare un'interfaccia utente di 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 pieno controllo 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 bloccati DEVE comunque essere rispettato.
DOVREBBE eseguire la migrazione dei numeri bloccati nel provider quando un dispositivo viene aggiornato ad Android 7.0.
DEVE fornire un'interfaccia utente per mostrare le chiamate bloccate nell'app di composizione preinstallata.

7.4.1.2. API Telecom

Se le implementazioni del dispositivo dichiarano android.hardware.microphone e android.hardware.audio.output e non dichiarano android.hardware.type.television,

[7.4.1.2/C-0-1] DEVE dichiarare il flag funzionalità android.software.telecom.
[7.4.1.2/C-0-2] DEVE implementare il framework per le telecomunicazioni.

Se le implementazioni dei dispositivi segnalano android.hardware.telephony.calling, significa che:

[C-1-1] DEVE supportare le API ConnectionService descritte nell'SDK.
[C-1-2] DEVE mostrare una nuova chiamata in arrivo e fornire all'utente la possibilità di accettare o rifiutare la chiamata in arrivo quando l'utente è impegnato in una chiamata in corso effettuata da un'app di terze parti che non supporta la funzionalità di attesa specificata tramite CAPABILITY_SUPPORT_HOLD.
[C-1-3] DEVE avere un'applicazione che implementi InCallService.
[C-SR-1] È FORTEMENTE CONSIGLIATO notificare all'utente che rispondere a una chiamata in arrivo interromperà una chiamata in corso.

L'implementazione AOSP soddisfa questi requisiti tramite una notifica in evidenza che indica all'utente che rispondere a una chiamata in arrivo comporterà l'interruzione dell'altra chiamata.
[C-SR-2] È FORTEMENTE CONSIGLIATO precaricare l'app Telefono predefinita che mostra una voce di log del registro chiamate e il nome di un'app di terze parti nel registro chiamate quando l'app di terze parti imposta la chiave EXTRA_LOG_SELF_MANAGED_CALLS extras nel relativo PhoneAccount su true.
[C-SR-3] Sono FORTEMENTE CONSIGLIATI per gestire gli eventi KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK delle cuffie audio per le API android.telecom come indicato di seguito:
- Chiamata Connection.onDisconnect() quando viene rilevata una pressione breve dell'evento chiave durante una chiamata in corso.
- Chiama Connection.onAnswer() quando viene rilevata una pressione breve 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 di CallAudioState.

7.4.1.3. Cellular NAT-T Keepalive Offload

Implementazioni del dispositivo:

DEVE includere il supporto per l'offload di Cellular keepalive.

Se le implementazioni del dispositivo includono il supporto per il trasferimento di Cellular keepalive e espongono la funzionalità ad app di terze parti, queste:

[C-1-1] DEVE supportare l'API SocketKeepAlive.
[C-1-2] DEVE supportare almeno uno slot keepalive simultaneo sulla rete cellulare.
[C-1-3] DEVE supportare il maggior numero possibile di slot keepalive cellulare simultanei supportati dall'HAL radio cellulare.
[C-SR-1] È VIVAMENTE CONSIGLIATO di supportare almeno tre slot keepalive cellulari per istanza radio.

Se le implementazioni dei dispositivi non includono il supporto per l'offload di keepalive cellulare, questi:

[C-2-1] MUST return ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementazioni del dispositivo:

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

Se le implementazioni del dispositivo includono il supporto di 802.11 ed espongono la funzionalità a un'applicazione di terze parti, devono:

[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 mDNS e NON DEVE filtrare i pacchetti mDNS (224.0.0.251 o ff02::fb) in qualsiasi momento del funzionamento, anche quando lo schermo non è in stato attivo, a meno che il blocco multicast non sia attivo e i pacchetti vengano filtrati da APF. I pacchetti non sono tenuti a soddisfare alcuna operazione mDNS attualmente richiesta dalle applicazioni tramite le API NsdManager. Tuttavia, il dispositivo POTREBBE filtrare i pacchetti mDNS se necessario per rimanere entro gli intervalli di consumo energetico richiesti dai requisiti normativi applicabili al mercato di destinazione.
[C-1-5] NON DEVE trattare la chiamata al metodo API WifiManager.enableNetwork() come indicazione sufficiente per cambiare l'Network attualmente attivo utilizzato per impostazione predefinita per il traffico dell'applicazione e restituito dai metodi API ConnectivityManager come getActiveNetwork e registerDefaultNetworkCallback. In altre parole, POSSONO disattivare l'accesso a internet fornito da qualsiasi altro provider di rete (ad es. dati mobili) solo se convalidano correttamente che la rete Wi-Fi fornisce l'accesso a internet.
[C-1-6] È FORTEMENTE CONSIGLIATO di, quando viene chiamato il metodo API ConnectivityManager.reportNetworkConnectivity(), rivalutare l'accesso a internet sul Network e, una volta che la valutazione determina che l'attuale Network non fornisce più l'accesso a internet, passare a qualsiasi altra rete disponibile (ad es. dati mobili) che fornisca l'accesso a internet.
[C-1-7] DEVE randomizzare l'indirizzo MAC di origine e il numero di sequenza dei frame di richiesta di probe, una volta all'inizio di ogni scansione, mentre la STA è disconnessa.
[C-1-8] DEVE utilizzare un indirizzo MAC coerente (NON DEVE randomizzare l'indirizzo MAC a metà scansione).
[C-1-9] DEVE iterare il numero di sequenza della richiesta di probe normalmente (in sequenza) tra le richieste di probe in una scansione.
[C-1-10] DEVE randomizzare il numero di sequenza della richiesta di probe tra l'ultima richiesta di probe di una scansione e la prima richiesta di probe della scansione successiva.
[C-SR-1] È FORTEMENTE CONSIGLIATO randomizzare l'indirizzo MAC di origine utilizzato per tutte le comunicazioni STA a un punto di accesso (AP) durante l'associazione e dopo l'associazione.
- Il dispositivo DEVE utilizzare un indirizzo MAC casuale diverso per ogni SSID (FQDN per Passpoint) con cui comunica.
- Il dispositivo DEVE fornire all'utente un'opzione per controllare la randomizzazione per SSID (FQDN per Passpoint) con opzioni non randomizzate e randomizzate e DEVE impostare la modalità predefinita per le nuove configurazioni Wi-Fi in modo che siano randomizzate.
[C-SR-2] È VIVAMENTE CONSIGLIATO di utilizzare un BSSID casuale per qualsiasi AP creato.
- L'indirizzo MAC DEVE essere randomizzato e reso persistente per SSID utilizzato dal punto di accesso.
- Il DISPOSITIVO potrebbe offrire all'utente un'opzione per disattivare questa funzionalità. Se viene fornita un'opzione di questo tipo, la randomizzazione DEVE essere abilitata per impostazione predefinita.

Se le implementazioni dei dispositivi includono il supporto della modalità di risparmio energetico Wi-Fi come definita nello standard IEEE 802.11, esse:

DEVE disattivare la modalità di risparmio energetico del Wi-Fi ogni volta che un'app acquisisce il blocco WIFI_MODE_FULL_HIGH_PERF o il blocco WIFI_MODE_FULL_LOW_LATENCY tramite le API WifiManager.createWifiLock() eWifiManager.WifiLock.acquire() e il blocco è attivo.
[C-3-2] La latenza media nel tempo di andata e ritorno tra il dispositivo e un punto di accesso mentre il dispositivo è in modalità di blocco Wi-Fi a bassa latenza (WIFI_MODE_FULL_LOW_LATENCY) DEVE essere inferiore alla latenza in modalità di blocco Wi-Fi ad alte prestazioni (WIFI_MODE_FULL_HIGH_PERF).
[C-SR-3] Sono VIVAMENTE CONSIGLIATI per ridurre al minimo la latenza di andata e ritorno del Wi-Fi ogni volta che viene acquisita una serratura a bassa latenza (WIFI_MODE_FULL_LOW_LATENCY) e ha effetto.

Se le implementazioni dei dispositivi supportano il Wi-Fi e lo utilizzano per la scansione della posizione, devono:

[C-2-1] DEVE fornire un'interfaccia utente per attivare/disattivare la lettura del valore tramite il metodo API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementazioni del dispositivo:

DEVE includere il supporto per 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.
[C-1-4] DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Direct.
[C-SR-1] È FORTEMENTE CONSIGLIATO di randomizzare l'indirizzo MAC di origine per tutte le connessioni Wi-Fi Direct appena create.

7.4.2.2. Configurazione di Wi-Fi Tunneled Direct Link

Implementazioni del dispositivo:

DEVE includere il supporto per Wi-Fi Tunneled Direct Link Setup (TDLS) come descritto nella documentazione dell'SDK Android.

Se le implementazioni del dispositivo includono il supporto di TDLS e TDLS è abilitato dall'API WiFiManager,

[C-1-1] DEVE dichiarare il supporto di TDLS tramite WifiManager.isTdlsSupported.
DEVE utilizzare TDLS solo quando è possibile E vantaggioso.
DOVREBBE utilizzare alcune euristiche e NON utilizzare TDLS quando le sue prestazioni potrebbero essere peggiori rispetto a quelle che si ottengono passando per il punto d'accesso Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementazioni del dispositivo:

DEVE includere il supporto per Wi-Fi Aware.

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Aware ed espongono la funzionalità ad app di terze parti, queste:

[C-1-1] DEVE implementare le API WifiAwareManager come descritto nella documentazione dell'SDK.
[C-1-2] DEVE 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 è abilitato a meno che non sia in corso un'operazione di ranging Aware o un percorso dati Aware sia attivo (la randomizzazione non è prevista finché il percorso dati è attivo).

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Aware e della posizione Wi-Fi come descritto nella sezione 7.4.2.5 ed espongono queste funzionalità ad app di terze parti, queste:

[C-2-1] DEVE implementare le API di rilevamento basate sulla posizione: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm, e onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

Se le implementazioni dei dispositivi includono il supporto di 802.11 (Wi-Fi):

DEVE includere il supporto per Wi-Fi Passpoint.

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

[C-1-2] DEVE implementare le API WifiManager correlate a Passpoint come descritto nella documentazione dell'SDK.
[C-1-3] DEVE supportare lo standard IEEE 802.11u, in particolare per quanto riguarda la selezione e l'individuazione della rete, ad esempio il servizio di pubblicità generica (GAS) e il protocollo di query della rete di accesso (ANQP).
[C-1-4] DEVE dichiarare il flag funzionalità android.hardware.wifi.passpoint.
[C-1-5] DEVE seguire l'implementazione AOSP per rilevare, abbinare e associare alle reti Passpoint.
[C-1-6] DEVE supportare almeno il seguente sottoinsieme di protocolli di provisioning dei dispositivi come definito in Wi-Fi Alliance Passpoint R2: autenticazione EAP-TTLS e SOAP-XML.
[C-1-7] DEVE elaborare il certificato del server AAA come descritto nella specifica Hotspot 2.0 R3.
[C-1-8] DEVE supportare il controllo dell'utente del provisioning tramite il selettore Wi-Fi.
[C-1-9] MUST keep Passpoint configurations persistent across reboots.
[C-SR-1] Sono FORTEMENTE CONSIGLIATI per supportare la funzionalità di accettazione dei termini e condizioni.
[C-SR-2] Sono FORTEMENTE CONSIGLIATI per supportare la funzionalità Informazioni sul luogo.

Se viene fornito un interruttore di controllo utente per la disattivazione globale di Passpoint, le implementazioni:

[C-3-1] DEVE abilitare Passpoint per impostazione predefinita.

7.4.2.5. Posizione Wi-Fi (tempo di round trip - RTT - del Wi-Fi)

Implementazioni del dispositivo:

DEVE includere il supporto per la posizione Wi-Fi.

Se le implementazioni dei dispositivi includono il supporto della localizzazione Wi-Fi ed espongono la funzionalità ad app di terze parti, queste:

[C-1-1] DEVE implementare le API WifiRttManager come descritto nella documentazione dell'SDK.
[C-1-2] DEVE dichiarare il flag funzionalità android.hardware.wifi.rtt.
[C-1-3] DEVE randomizzare l'indirizzo MAC di origine per ogni burst RTT eseguito mentre l'interfaccia Wi-Fi su cui viene eseguito l'RTT non è associata a un punto di accesso.
[C-1-4] DEVE essere preciso entro 2 metri con una larghezza di banda di 80 MHz al 68° percentile (come calcolato con la funzione di distribuzione cumulativa).
[C-SR-1] È VIVAMENTE CONSIGLIATO di segnalarlo con una precisione di 1,5 metri con una larghezza di banda di 80 MHz al 68° percentile (come calcolato con la funzione di distribuzione cumulativa).

7.4.2.6. Wi-Fi Keepalive Offload

Implementazioni del dispositivo:

DEVE includere il supporto per l'offload di Wi-Fi Keepalive.

Se le implementazioni del dispositivo includono il supporto per l'offload di Wi-Fi keepalive ed espongono la funzionalità ad app di terze parti, queste:

[C-1-1] DEVE supportare l'API SocketKeepAlive.
[C-1-2] DEVE supportare almeno tre slot keepalive simultanei tramite Wi-Fi

Se le implementazioni dei dispositivi non includono il supporto per l'offload di Wi-Fi keepalive, questi:

[C-2-1] MUST return ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocollo di provisioning dei dispositivi)

Implementazioni del dispositivo:

DEVE includere il supporto per Wi-Fi Easy Connect (DPP).

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Easy Connect ed espongono la funzionalità ad app di terze parti, queste:

[C-1-1] DEVE avere il WifiManager#isEasyConnectSupported() metodo restituisce true.

7.4.2.8. Convalida del certificato del server Wi-Fi aziendale

Se il certificato del server Wi-Fi non viene convalidato o il nome di dominio del server Wi-Fi non è impostato, le implementazioni del dispositivo:

[C-SR-1] È FORTEMENTE CONSIGLIATO di non fornire all'utente un'opzione per aggiungere manualmente una rete Wi-Fi aziendale nell'app Impostazioni.

7.4.2.9. Considera attendibile al primo utilizzo (TOFU)

Se le implementazioni dei dispositivi supportano la funzionalità Trust on first use (TOFU) e consentono all'utente di definire configurazioni WPA/WPA2/WPA3-Enterprise, devono:

[C-4-1] DEVE fornire all'utente un'opzione per selezionare l'utilizzo di TOFU.

7.4.2.10. Rilevamento di prossimità Wi-Fi

Se le implementazioni dei dispositivi includono il supporto per il rilevamento di prossimità Wi-Fi, allora:

[C-1-1] DEVE includere il supporto per il rilevamento di prossimità.
[C-1-2] DEVE dichiarare il flag funzionalità android.hardware.wifi.rtt.
[C-1-3] DEVE avere il metodo WifiRttManager#getProximityDetectionCharacteristics() che restituisce un valore non nullo.
[C-1-4] DEVE implementare le API di misurazione continua WifiRttManager.
[C-1-5] DEVE supportare contemporaneamente le operazioni di rilevamento di prossimità Wi-Fi e Wi-Fi.
[C-1-6] DEVE essere preciso entro 2 metri con una larghezza di banda di 80 MHz al 68° percentile (come calcolato con la funzione di distribuzione cumulativa).
[C-1-7] DEVE eseguire la misurazione del raggio di rilevamento della prossimità (PD) nella banda di frequenza più alta disponibile (6 GHz, 5 GHz o 2,4 GHz) utilizzando la larghezza di banda massima supportata nel seguente ordine di priorità: 160 MHz, 80 MHz, 40 MHz e 20 MHz.
[C-SR-1] È FORTEMENTE CONSIGLIATO di segnalarlo con precisione entro 1,5 metri a una larghezza di banda di 80 MHz al 68° percentile (come calcolato con la funzione di distribuzione cumulativa).
[C-SR-2] È VIVAMENTE CONSIGLIATO supportare il ranging NTB 802.11az.

7.4.3. Bluetooth

Se le implementazioni dei dispositivi supportano il profilo audio Bluetooth:

DEVE supportare i codec audio avanzati e i codec audio Bluetooth (ad es. LDAC).

Se le implementazioni dei dispositivi supportano HFP, A2DP e AVRCP:

DEVE supportare almeno 5 dispositivi connessi in totale.

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 supporta Bluetooth e Bluetooth Low Energy.

Se le implementazioni del dispositivo includono il supporto di Bluetooth e Bluetooth Low Energy, queste:

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

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

[C-3-1] DEVE dichiarare la funzionalità hardware android.hardware.bluetooth_le.
[C-3-2] DEVE abilitare le API Bluetooth basate su GATT (generic attribute profile) come descritto nella documentazione dell'SDK e in android.bluetooth.
[C-3-3] DEVE segnalare il valore corretto per BluetoothAdapter.isOffloadedFilteringSupported() per indicare se la logica di filtraggio per le classi API ScanFilter è implementata.
[C-3-4] DEVE segnalare il valore corretto per BluetoothAdapter.isMultipleAdvertisementSupported() per indicare se la pubblicità a basso consumo energetico è supportata.
[C-3-5] DEVE implementare un timeout per l'indirizzo privato risolvibile (RPA) non superiore a 15 minuti e ruotare l'indirizzo al timeout per proteggere la privacy dell'utente quando il dispositivo utilizza attivamente il Bluetooth Low Energy per la scansione o la pubblicità. Per evitare attacchi di temporizzazione, gli intervalli di timeout DEVONO essere randomizzati tra 5 e 15 minuti.
DEVE supportare l'offload della logica di filtraggio al chipset Bluetooth quando implementa l'API ScanFilter.
DEVE supportare l'offload della scansione batch al chipset Bluetooth.
DEVE supportare più pubblicità con almeno 4 spazi.

Se le implementazioni dei dispositivi supportano Bluetooth LE e lo utilizzano per la scansione della posizione,

[C-4-1] DEVE fornire un'interfaccia utente per attivare/disattivare la lettura del valore tramite l'API di sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se le implementazioni del dispositivo includono il supporto per Bluetooth LE e il profilo per apparecchi acustici, come descritto in Supporto audio per apparecchi acustici tramite Bluetooth LE, queste:

[C-5-1] MUST return true for BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

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

[C-6-1] DEVE limitare l'accesso a tutti i metadati Bluetooth (come i risultati della scansione) che potrebbero essere utilizzati per ricavare la posizione del dispositivo, a meno che l'app richiedente non superi correttamente un controllo delle autorizzazioni android.permission.ACCESS_FINE_LOCATION in base al suo attuale stato in primo piano/in background.

Se le implementazioni del dispositivo includono il supporto di Bluetooth o Bluetooth Low Energy e il manifest dell'app non include una dichiarazione dello sviluppatore che attesti che non deriva la posizione dal Bluetooth,

[C-6-2] L'accesso al Bluetooth DEVE essere controllato tramite l'android.permission.ACCESS_FINE_LOCATION.

Se le implementazioni dei dispositivi restituiscono true per l'API BluetoothAdapter.isLeAudioSupported():

[C-7-1] DEVE supportare il client unicast.
[C-7-2] DEVE supportare PHY 2M.
[C-7-3] DEVE supportare la pubblicità estesa LE.
[C-7-4] DEVE supportare almeno due connessioni CIS in un CIG.
[C-7-5] DEVE abilitare contemporaneamente il client unicast BAP, il coordinatore del set CSIP, il server MCP, il controller VCP e il server CCP.
[C-SR-1] È VIVAMENTE CONSIGLIATO abilitare il client unicast HAP.

Se le implementazioni dei dispositivi restituiscono true per l'API BluetoothAdapter.isLeAudioBroadcastSourceSupported():

[C-8-1] DEVE supportare almeno due collegamenti BIS in un BIG.
[C-8-2] MUST enable BAP broadcast source, BAP broadcast assistant simultaneously.
[C-8-3] DEVE supportare la pubblicità periodica LE.

Se le implementazioni dei dispositivi restituiscono true per l'API BluetoothAdapter.isLeAudioBroadcastAssistantSupported():

[C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
[C-9-2] DEVE supportare la pubblicità periodica LE.

Se le implementazioni dei dispositivi dichiarano FEATURE_BLUETOOTH_LE:

[C-10-1] Le misurazioni RSSI DEVONO rientrare in un intervallo di +/-9 dB per il 95% delle misurazioni a 1 m di distanza da un dispositivo di riferimento che trasmette a ADVERTISE_TX_POWER_HIGH in un ambiente in linea di vista.
[C-10-2] DEVE includere correzioni Rx/Tx per ridurre le deviazioni per canale in modo che le misurazioni su ciascuno dei tre canali, su ciascuna delle antenne (se ne vengono utilizzate più di una), rientrino in un intervallo di +/-3 dB l'una dall'altra per il 95% delle misurazioni.

Se le implementazioni dei dispositivi dichiarano FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING:

[C-11-1] DEVE segnalare il flag della funzionalità hardware android.hardware.bluetooth_le.channel_sounding.
[C-11-2] DEVE segnalare l'intervallo con una precisione di +/- 0,5 m al 90° percentile, calcolato con la funzione di distribuzione cumulativa, alla distanza di 1 m.

Se le implementazioni dei dispositivi dichiarano FEATURE_BLUETOOTH_LE:

[C-SR-2] Sono FORTEMENTE CONSIGLIATI per misurare e compensare l'offset Rx per garantire che l'RSSI BLE mediano sia -60 dBm +/-10 dB a 1 m di distanza da un dispositivo di riferimento che trasmette a ADVERTISE_TX_POWER_HIGH, dove i dispositivi sono orientati in modo da trovarsi su "piani paralleli" con gli schermi rivolti nella stessa direzione.
[C-SR-3] È FORTEMENTE CONSIGLIATO misurare e compensare l'offset di trasmissione per garantire che l'RSSI BLE mediano sia pari a -60 dBm +/-10 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e che trasmette a ADVERTISE_TX_POWER_HIGH, dove i dispositivi sono orientati in modo da trovarsi su "piani paralleli" con gli schermi rivolti nella stessa direzione.

È VIVAMENTE CONSIGLIATO seguire i passaggi di configurazione della misurazione specificati in Requisiti di calibrazione della presenza.

7.4.4. Near Field Communication

Implementazioni del dispositivo:

DEVE includere un ricetrasmettitore e hardware correlato per la tecnologia Near Field Communication (NFC).
[C-0-1] MUST implement android.nfc.NdefMessage and android.nfc.NdefRecord APIs even if they do not include support for NFC or declare the android.hardware.nfc feature as the classes represent a protocol-independent data representation format.

Se le implementazioni dei dispositivi includono hardware NFC e prevedono di renderlo disponibile per 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 come indicato di seguito:
[C-1-2] DEVE essere in grado di fungere da 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 2, 3, 4, 5 (definiti da NFC Forum)
[C-SR-1] 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, la definizione di compatibilità per una versione futura prevede di modificarli 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 fortemente incoraggiati a soddisfare questi requisiti ora in modo da poter eseguire l'upgrade alle versioni future della piattaforma.
[C-1-13] DEVE eseguire il polling di tutte le tecnologie supportate in modalità di rilevamento NFC.
DEVE essere in modalità di rilevamento NFC mentre il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.
DEVE 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à Host Card Emulation (HCE) NFC.

Se le implementazioni del dispositivo includono un chipset del controller NFC in grado di eseguire l'emulazione della carta (per NfcA e/o NfcB) e supportano il routing dell'ID applicazione (AID), allora:

[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 dei dispositivi includono un chipset del controller NFC in grado di supportare HCE per NfcF e implementano la funzionalità per applicazioni di terze parti, queste:

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

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

[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à Android standard e pertanto non viene visualizzata come costante nella classe android.content.pm.PackageManager.

7.4.5. API e protocolli di rete

7.4.5.1. Capacità di rete minima

Implementazioni del dispositivo:

[C-0-1] DEVE includere il supporto per una o più forme di rete di dati. Nello specifico, le implementazioni del dispositivo DEVONO includere il supporto di almeno uno standard di dati in grado di raggiungere una velocità di 200 Kbit/sec o superiore. Esempi di tecnologie che soddisfano questo requisito includono EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
DOVREBBE includere anche il supporto di almeno uno standard comune per i dati wireless, ad esempio 802.11 (Wi-Fi), quando uno standard di rete fisico (ad esempio Ethernet) è la connessione dati principale.
PUÒ implementare più di una forma di connettività dei dati.

7.4.5.2. IPv6

Implementazioni del dispositivo:

[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 i socket AF_INET6.
[C-0-3] DEVE abilitare IPv6 per impostazione predefinita.
DEVE garantire che la comunicazione IPv6 sia affidabile quanto IPv4, ad esempio:
[C-0-4] DEVE mantenere la connettività IPv6 in modalità Doze.
[C-0-5] La limitazione della velocità NON DEVE causare la perdita della connettività IPv6 del dispositivo su qualsiasi rete compatibile con IPv6 che utilizzi durate RA di almeno 180 secondi.
[C-0-6] DEVE fornire alle applicazioni di terze parti connettività IPv6 diretta alla rete quando è connesso a una rete IPv6, senza alcuna forma di traduzione di indirizzi o porte a livello locale sul dispositivo. Sia le API gestite come Socket#getLocalAddress o Socket#getLocalPort sia le API NDK come getsockname() o IPV6_PKTINFO DEVONO restituire l'indirizzo IP e la porta effettivamente utilizzati per inviare e ricevere pacchetti sulla rete e visibili come IP e porta di origine ai server internet (web).

Il livello di supporto IPv6 richiesto dipende dal tipo di rete, come mostrato nei requisiti seguenti.

Se le implementazioni dei dispositivi supportano il Wi-Fi:

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

Se le implementazioni dei dispositivi supportano Ethernet:

[C-2-1] DEVE supportare il funzionamento a doppio stack e solo IPv6 su Ethernet.

Se le implementazioni dei dispositivi supportano la rete dati:

[C-3-1] DEVE supportare il funzionamento di IPv6 (solo IPv6 e possibilmente doppio stack) sulla rete cellulare.

Se le implementazioni dei dispositivi supportano più di un tipo di rete (ad es. Wi-Fi e dati cellulari):

[C-4-1] DEVE soddisfare contemporaneamente i requisiti di cui sopra su ogni rete quando il dispositivo è connesso contemporaneamente a più di un tipo di rete.

7.4.5.3. Captive portal

Un captive portal è una rete che richiede l'accesso per ottenere l'accesso a internet.

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

[C-1-1] DEVE fornire un'applicazione captive portal per gestire l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN e visualizzare la pagina di accesso al captive portal, inviando l'intent, alla chiamata all'API di sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] DEVE eseguire il rilevamento dei captive portal e supportare l'accesso tramite l'applicazione captive portal quando il dispositivo è connesso a qualsiasi tipo di rete, inclusa rete cellulare/mobile, Wi-Fi, Ethernet o Bluetooth.
[C-1-3] DEVE supportare l'accesso ai captive portal utilizzando il DNS in testo normale quando il dispositivo è configurato per utilizzare la modalità rigida del DNS privato.
[C-1-4] DEVE utilizzare DNS crittografato come da documentazione SDK per android.net.LinkProperties.getPrivateDnsServerName e android.net.LinkProperties.isPrivateDnsActive per tutto il traffico di rete che non comunica esplicitamente con il captive portal.
[C-1-5] DEVE garantire che, mentre l'utente esegue l'accesso a un captive portal, la rete predefinita utilizzata dalle applicazioni (restituita da ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback, e utilizzata per impostazione predefinita dalle API di rete Java come java.net.Socket, e dalle API native come connect()) sia qualsiasi altra rete disponibile che fornisca l'accesso a internet, se disponibile.

7.4.6. Impostazioni di sincronizzazione

Implementazioni del dispositivo:

[C-0-1] DEVE avere l'impostazione di sincronizzazione automatica principale 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 a consumo, sono:

[C-SR-1] VIVAMENTE CONSIGLIATO di fornire la modalità Risparmio dati.

Se le implementazioni del dispositivo forniscono la modalità Risparmio dati:

[C-1-1] DEVE supportare tutte le API nella classe ConnectivityManager come descritto nella documentazione dell'SDK

Se le implementazioni del dispositivo non forniscono la modalità Risparmio dati:

[C-2-1] MUST return the value RESTRICT_BACKGROUND_STATUS_DISABLED for ConnectivityManager.getRestrictBackgroundStatus()
[C-2-2] MUST NOT broadcast ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Secure Element

Se le implementazioni dei dispositivi supportano elementi sicuri compatibili con l'API Open Mobile e li rendono disponibili per app di terze parti,

[C-1-1] DEVE enumerare i lettori di elementi sicuri disponibili tramite l'API android.se.omapi.SEService.getReaders().
[C-1-2] DEVE dichiarare i flag delle funzionalità corretti tramite android.hardware.se.omapi.uicc per il dispositivo con elementi sicuri basati su UICC, android.hardware.se.omapi.ese per il dispositivo con elementi sicuri basati su eSE e android.hardware.se.omapi.sd per il dispositivo con elementi sicuri basati su SD.

7.4.9. UWB

Se le implementazioni del dispositivo includono il supporto per 802.1.15.4 ed espongono la funzionalità a un'applicazione di terze parti, devono:

[C-1-1] DEVE implementare l'API Android corrispondente in android.uwb.
[C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.uwb.
[C-1-3] DEVE supportare tutti i profili UWB pertinenti definiti nell'implementazione di Android.
[C-1-4] DEVE fornire un'interfaccia utente che consenta all'utente di attivare/disattivare la radio UWB.
[C-1-5] DEVE garantire che le app che utilizzano la radio UWB dispongano dell'autorizzazione UWB_RANGING (nel gruppo di autorizzazioni NEARBY_DEVICES).
[C-SR-1] Sono FORTEMENTE CONSIGLIATI per superare i test di conformità e certificazione pertinenti definiti dalle organizzazioni di standardizzazione, tra cui FIRA, CCC e CSA.
[C-1-6] DEVE garantire che le misurazioni della distanza rientrino in un intervallo di +/-15 cm per il 95% delle misurazioni nell'ambiente in linea di visuale a 1 m di distanza in una camera non riflettente.
[C-1-7] DEVE garantire che la mediana delle misurazioni della distanza a 1 m dal dispositivo di riferimento sia compresa tra [0,75 m, 1,25 m], dove la distanza reale viene misurata dal bordo superiore del DUT.
[C-SR-2] È FORTEMENTE CONSIGLIATO seguire i passaggi di configurazione della misurazione specificati nei Requisiti di calibrazione della presenza.

7.5. Videocamere

Se le implementazioni dei dispositivi includono almeno una videocamera:

[C-1-1] DEVE dichiarare il flag funzionalità android.hardware.camera.any.
[C-1-2] DEVE essere possibile per un'applicazione allocare simultaneamente 3 bitsmap RGBA_8888 pari alle dimensioni delle immagini prodotte dal sensore della fotocamera con la risoluzione più alta sul dispositivo, mentre la fotocamera è aperta per lo scopo di anteprima di base e acquisizione di immagini fisse.
[C-1-3] DEVE garantire che l'applicazione fotocamera preinstallata predefinita che gestisce gli intent MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, o MediaStore.ACTION_VIDEO_CAPTURE, sia responsabile della rimozione della posizione dell'utente nei metadati dell'immagine prima di inviarla all'applicazione ricevente quando quest'ultima non dispone di ACCESS_FINE_LOCATION.

Se le implementazioni del dispositivo includono almeno una fotocamera e l'applicazione fotocamera preinstallata gestisce gli intent MediaStore.ACTION_MOTION_PHOTO_CAPTURE o MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, queste:

[C-1-4] DEVE assicurarsi che, durante la gestione di questi intent, l'app fotocamera preinstallata rimuova la posizione dell'utente nei metadati dell'immagine prima di inviarla alle applicazioni riceventi che non dispongono di ACCESS_FINE_LOCATION.
[C-1-5] DEVE garantire che la foto in movimento restituita utilizzi la specifica del formato foto in movimento 1.0.

[C-1-6] DEVE etichettare ogni tipo di dispositivo di videocamera utilizzando il campo CameraCharacteristics.INFO_DEVICE_TYPE come BUILT_IN, EXTERNAL o VIRTUAL. DEVE anche etichettare ogni frame di output della videocamera utilizzando il campo CaptureResult.INFO_DEVICE_TYPE.
Assicurarsi che CaptureResult.INFO_DEVICE_TYPE sia etichettato correttamente è particolarmente importante nelle situazioni in cui un ID videocamera viene rimappato dinamicamente a un'altra origine videocamera.

Se le implementazioni dei dispositivi supportano la funzionalità di output HDR a 10 bit:

[C-2-1] DEVE supportare almeno il profilo HDR HLG per ogni dispositivo videocamera che supporta l'output a 10 bit.
[C-2-2] DEVE supportare l'output a 10 bit per la fotocamera posteriore principale o per la fotocamera anteriore principale.
[C-SR-1] Sono FORTEMENTE CONSIGLIATE per supportare l'output a 10 bit per entrambe le videocamere principali.
[C-2-3] DEVE supportare gli stessi profili HDR per tutte le sotto-videocamere fisiche con funzionalità BACKWARD_COMPATIBLE di una videocamera logica e per la videocamera logica stessa.

Per i dispositivi con fotocamera logica che supportano l'HDR a 10 bit che implementano l'API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO:

[C-3-1] DEVE supportare il passaggio tra tutte le fotocamere fisiche compatibili con le versioni precedenti tramite il controllo CONTROL_ZOOM_RATIO sulla fotocamera logica.

7.5.1. Fotocamera posteriore

Una fotocamera posteriore è una fotocamera rivolta verso l'esterno che riprende scene sul lato opposto del dispositivo, come una fotocamera tradizionale; sui dispositivi portatili, è una fotocamera situata sul lato del dispositivo opposto al display.

Implementazioni del dispositivo:

DOVREBBE includere una fotocamera posteriore.

Se le implementazioni dei dispositivi includono almeno una videocamera posteriore:

[C-1-1] DEVE segnalare il flag della funzionalità android.hardware.camera e android.hardware.camera.any.

~~[C-1-2] DEVE avere una risoluzione di almeno 2 megapixel.~~

DOVREBBE avere implementato la messa a fuoco automatica hardware o software nel driver della videocamera (trasparente per il software applicativo).
POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
POTREBBE includere un flash.

Se la videocamera include un flash:

[C-2-1] la lampada flash NON DEVE essere accesa mentre è stata registrata un'istanza android.hardware.Camera.PreviewCallback su una superficie di anteprima della videocamera, 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 fotocamera di sistema integrata nel dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

Una fotocamera frontale è una fotocamera rivolta verso l'utente, in genere utilizzata per riprendere l'utente, ad esempio per videoconferenze e applicazioni simili; sui dispositivi portatili, è una fotocamera situata sullo stesso lato del dispositivo del display.

Implementazioni del dispositivo:

POTREBBE includere una fotocamera anteriore.

Se le implementazioni dei dispositivi includono almeno una videocamera frontale:

[C-1-1] DEVE segnalare il flag della funzionalità android.hardware.camera.any e android.hardware.camera.front.
[C-1-2] DEVE avere una risoluzione di almeno VGA (640x480 pixel).
[C-1-3] NON DEVE utilizzare una fotocamera frontale come predefinita per l'API Camera e NON DEVE configurare l'API in modo che tratti una fotocamera frontale come fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
[C-1-4] L'anteprima della videocamera DEVE essere specchiata orizzontalmente rispetto all'orientamento specificato dall'applicazione quando l'applicazione corrente ha richiesto esplicitamente la rotazione del display della videocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation(). Al contrario, l'anteprima DEVE essere specchiata lungo l'asse orizzontale predefinito del dispositivo quando l'applicazione corrente non richiede esplicitamente la rotazione del display della videocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation().
[C-1-5] NON DEVE eseguire il mirroring dei flussi video o delle immagini statiche acquisite finali restituiti ai callback dell'applicazione o salvati nello spazio di archiviazione multimediale.
[C-1-6] DEVE rispecchiare l'immagine visualizzata dall'anteprima nello stesso modo del flusso di immagini di anteprima della videocamera.
POSSONO 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 del dispositivo possono essere ruotate dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente):

[C-2-1] L'anteprima della videocamera DEVE essere specchiata orizzontalmente rispetto all'orientamento attuale del dispositivo.

7.5.3. Videocamera esterna

Una videocamera esterna è una videocamera che può essere collegata o scollegata fisicamente dall'implementazione del dispositivo in qualsiasi momento e può essere orientata in qualsiasi direzione, ad esempio le videocamere USB.

Implementazioni del dispositivo:

POTREBBE includere il supporto di una videocamera esterna che non è necessariamente sempre connessa.

Se le implementazioni dei dispositivi includono il supporto di una videocamera esterna:

[C-1-1] DEVE dichiarare il flag della funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any.
[C-1-2] DEVE supportare USB Video Class (UVC 1.0 o versioni successive) se la videocamera esterna si connette tramite la porta host USB.
[C-1-3] DEVE superare i test CTS della fotocamera con un dispositivo fotocamera esterno fisico collegato. I dettagli dei test CTS della videocamera sono disponibili all'indirizzo source.android.com.
DEVE supportare compressioni video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ad es. stream di immagini raw o compressi in modo indipendente).
POTREBBE supportare più videocamere.
POTREBBE supportare la codifica video basata sulla videocamera.

Se la codifica video basata sulla videocamera è supportata:

[C-2-1] Un flusso MJPEG / non codificato 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 nuova API android.hardware.camera2 espone il controllo della fotocamera di livello inferiore all'app, inclusi flussi di streaming/scatto a raffica efficienti senza copia e controlli per frame 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 comunque essere disponibile per l'utilizzo da parte delle app. Le implementazioni dei dispositivi Android DEVONO garantire il supporto continuo dell'API come descritto in questa sezione e nell'SDK Android.

Tutte le funzionalità comuni tra la classe android.hardware.Camera deprecata e il pacchetto android.hardware.camera2 più recente DEVONO avere prestazioni e qualità equivalenti in entrambe le API. Ad esempio, con impostazioni equivalenti, la velocità e la precisione dell'autofocus devono essere identiche e la qualità delle immagini acquisite deve essere la stessa. Le funzionalità che dipendono dalle diverse semantiche delle due API non devono avere velocità o qualità corrispondenti, ma DEVONO corrispondere il più possibile.

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API correlate alla fotocamera, per tutte le fotocamere disponibili. Implementazioni del dispositivo:

[C-0-1] DEVE 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] MUST further be in the NV21 encoding format when an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method and the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame(). ovvero 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 videocamera sia per le videocamere anteriore e posteriore per android.hardware.Camera. (Il codificatore video hardware e la videocamera possono utilizzare qualsiasi formato 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'intera API Camera inclusa nella documentazione dell'SDK Android, indipendentemente dal fatto che il dispositivo includa la messa a fuoco automatica hardware o altre funzionalità. Ad esempio, le videocamere che non hanno la messa a fuoco automatica DEVONO comunque chiamare tutte le istanze di android.hardware.Camera.AutoFocusCallback registrate (anche se questo non ha alcuna rilevanza per una videocamera senza messa a fuoco automatica). Tieni presente che questo vale per le fotocamere anteriori; ad esempio, anche se la maggior parte delle fotocamere anteriori non supporta la messa a fuoco automatica, i callback API devono comunque essere "falsificati" come descritto.
[C-0-6] DEVE riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters e nella classe android.hardware.camera2.CaptureRequest. Al contrario, le implementazioni del dispositivo NON DEVONO rispettare o riconoscere le costanti stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. ovvero le implementazioni dei dispositivi DEVONO supportare tutti i parametri standard della fotocamera se l'hardware lo consente e NON DEVONO supportare tipi di parametri della fotocamera personalizzati. Ad esempio, le implementazioni del dispositivo 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 i flag delle funzionalità del framework appropriati.
[C-0-8] DEVE anche dichiarare le funzionalità della singola videocamera di android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag delle funzionalità appropriati; DEVE definire il flag della funzionalità se uno qualsiasi 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 all'archivio multimediale.
[C-0-10] DEVE trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e la voce dell'immagine è stata aggiunta all'archivio multimediale.
[C-0-11] DEVE avere tutte le videocamere accessibili tramite l'API android.hardware.Camera deprecata, accessibile anche tramite l'API android.hardware.camera2.
[C-0-12] DEVE garantire che l'aspetto del volto NON venga alterato, inclusi, a titolo esemplificativo, la geometria del volto, la tonalità della pelle del volto o la levigatura della pelle del volto per qualsiasi API android.hardware.camera2 o android.hardware.Camera.
[C-SR-1] Per i dispositivi con più videocamere RGB molto vicine e rivolte nella stessa direzione, è VIVAMENTE CONSIGLIATO supportare un dispositivo videocamera logico che elenca la funzionalità CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, costituita da tutte le videocamere RGB rivolte in quella direzione come sottodispositivi fisici.

Se le implementazioni dei dispositivi forniscono un'API Camera proprietaria ad app di terze parti,

[C-1-1] DEVE implementare un'API fotocamera di questo tipo utilizzando l'API android.hardware.camera2.
POSSONO fornire tag e/o estensioni del fornitore all'API android.hardware.camera2.

Se le implementazioni dei dispositivi regolano la pipeline della fotocamera di terze parti in modo che sia alla pari con la pipeline della fotocamera integrata per la fotocamera anteriore principale e la fotocamera posteriore principale,

[C-2-1] DEVE dichiarare la proprietà di sistema ro.camera.default_app_social_media_parity_enabled.

7.5.5. Orientamento della videocamera

Se le implementazioni del dispositivo hanno una fotocamera anteriore o posteriore, queste fotocamere:

[C-1-1] DEVE essere orientata in modo che la dimensione lunga della videocamera sia allineata alla dimensione lunga dello schermo. ovvero, quando il dispositivo è tenuto in orientamento orizzontale, le fotocamere DEVONO acquisire immagini in orientamento orizzontale. Ciò vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica sia ai dispositivi con orientamento orizzontale principale sia a quelli con orientamento verticale principale.

I dispositivi che soddisfano uno dei seguenti criteri sono esenti da questo requisito:
- Il dispositivo implementa schermi a geometria variabile, come display pieghevoli o articolati E quando lo stato di piegatura o dell'articolazione del dispositivo cambia, il dispositivo passa dall'orientamento verticale principale a quello orizzontale principale (o viceversa).
- Implementazioni di dispositivi che non possono essere ruotati dall'utente, ad esempio i dispositivi per auto.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

Implementazioni del dispositivo:

[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 almeno 100 MB nella posizione "cache" predefinita.

7.6.2. Spazio di archiviazione condiviso dell'applicazione

Implementazioni del dispositivo:

[C-0-1] DEVE offrire uno spazio di archiviazione da condividere tra le applicazioni, spesso chiamato anche "spazio di archiviazione esterno condiviso", "spazio di archiviazione condiviso dell'applicazione" 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 "pronto all'uso", indipendentemente dal fatto che lo spazio di archiviazione sia implementato su un componente di memoria interna o su un supporto di archiviazione rimovibile (ad es. slot per schede Secure Digital).
[C-0-3] DEVE 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] DEVE abilitare lo spazio di archiviazione isolato per impostazione predefinita per tutte le app che hanno come target il livello API 29 o versioni successive, tranne nella seguente situazione:
- Quando l'app ha richiesto android:requestLegacyExternalStorage="true" nel manifest.
[C-0-5] DEVE oscurare i metadati sulla posizione, come i tag EXIF GPS, archiviati nei file multimediali quando questi file vengono accessibili tramite MediaStore, tranne quando l'app di chiamate dispone dell'autorizzazione ACCESS_MEDIA_LOCATION.

Le implementazioni dei dispositivi POSSONO soddisfare i requisiti di cui sopra utilizzando uno dei seguenti metodi:

Memoria rimovibile accessibile all'utente, ad esempio uno slot per schede Secure Digital (SD).
Una parte della memoria interna (non rimovibile) come implementata in Android Open Source Project (AOSP).

Se le implementazioni dei dispositivi utilizzano supporti di archiviazione rimovibili per soddisfare i requisiti sopra indicati:

[C-1-1] DEVE implementare un'interfaccia utente di tipo toast o popup che avvisi l'utente quando non è inserito alcun supporto di archiviazione nello slot.
[C-1-2] DEVE includere un supporto di archiviazione formattato FAT (ad es. scheda SD) o mostrare 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 di cui sopra:

DEVE utilizzare l'implementazione AOSP dell'archivio condiviso dell'applicazione interna.
POTREBBE condividere lo spazio di archiviazione con i dati privati dell'applicazione.

Se le implementazioni dei dispositivi hanno una porta USB con supporto della modalità periferica USB, devono:

[C-3-1] DEVE fornire un meccanismo per accedere ai dati sullo spazio di archiviazione condiviso dell'applicazione da un computer host.
DEVE esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione dei contenuti multimediali di Android e android.provider.MediaStore.
PUÒ utilizzare l'archivio di massa USB, ma DEVE utilizzare il protocollo di trasferimento multimediale per soddisfare questo requisito.

Se le implementazioni del dispositivo hanno una porta USB con modalità periferica USB e supportano il protocollo di trasferimento multimediale,

DEVE essere compatibile con l'host MTP Android di riferimento, ovvero Android File Transfer.
DEVE segnalare una classe di dispositivo USB pari a 0x00.
DEVE segnalare il nome dell'interfaccia USB "MTP".

7.6.3. Spazio di archiviazione utilizzabile

Se il dispositivo è mobile per natura, a differenza della televisione, le implementazioni del dispositivo sono:

[C-SR-1] È FORTEMENTE CONSIGLIATO implementare la memoria adottabile in una posizione stabile a lungo termine, poiché la disconnessione accidentale può causare la perdita di dati/il danneggiamento.

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:

[C-SR-2] VIVAMENTE CONSIGLIATO di implementare lo spazio di archiviazione utilizzabile.

7.7. USB

Definizioni

La modalità host USB si verifica quando l'implementazione di un dispositivo funge da host USB, fornisce alimentazione al bus e comunica con le periferiche.
La modalità dispositivo USB (nota anche come modalità periferica USB) si verifica quando l'implementazione di un dispositivo funge da periferica USB, si connette a un host tramite una porta upstream e risponde alle richieste dell'host.
Una porta USB è definita come un meccanismo per fornire connettività USB, ovvero una presa USB fisica o un'interfaccia non standard (ad esempio, pogo pin).

Se le implementazioni del dispositivo hanno una porta USB:

DEVE supportare la modalità dispositivo USB.
DEVE supportare la modalità host USB.
DEVE supportare la disattivazione della trasmissione di dati tramite USB.

7.7.1. Modalità dispositivo USB

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità periferica� �:

[C-1-1] La porta DEVE essere collegabile a un host USB dotato di una porta USB standard di tipo A o di tipo C.
[C-1-2] DEVE segnalare il valore corretto di iSerialNumber nel descrittore del dispositivo standard USB tramite android.os.Build.SERIAL.
[C-1-3] DEVE rilevare caricabatterie da 1,5 A e 3 A in base allo standard di resistenza Type-C e DEVE rilevare le modifiche alla pubblicità se supportano USB Type-C.

[C-SR-1] La porta DOVREBBE utilizzare il fattore di forma USB micro-B, micro-AB o Type-C. È VIVAMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti in modo da poter eseguire l'upgrade alle future versioni della piattaforma.

[C-SR-2] La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o abilitare 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. È VIVAMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti in modo da poter eseguire l'upgrade alle versioni future della piattaforma.
[C-SR-3] DOVREBBE implementare il supporto per assorbire una corrente di 1,5 A durante il segnale acustico HS e il traffico come specificato nella specifica di ricarica della batteria USB, revisione 1.2. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti in modo da poter eseguire l'upgrade alle versioni future della piattaforma.
[C-SR-4] È FORTEMENTE CONSIGLIATO di non supportare metodi di ricarica proprietari che modificano la tensione Vbus oltre i livelli predefiniti o alterano i ruoli di sink/source, in quanto ciò potrebbe causare problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard USB Power Delivery. Sebbene sia indicato come "FORTEMENTE CONSIGLIATO", nelle future versioni di Android potremmo RICHIEDERE che tutti i dispositivi di tipo C supportino la piena interoperabilità con i caricabatterie di tipo C standard.
[C-SR-5] Sono FORTEMENTE CONSIGLIATI per supportare Power Delivery per lo scambio di ruoli di alimentazione e dati quando supportano USB Type-C e la modalità host USB.
DEVE supportare Power Delivery per la ricarica ad alta tensione e le modalità alternative come l'uscita display.
DEVE implementare l'API e la specifica Android Open Accessory (AOA) come documentato 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 per la 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 di 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:

[C-1-1] DEVE implementare l'API host USB di Android come documentato nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host.
[C-1-2] DEVE implementare il supporto per la connessione di periferiche USB standard. Devono avere uno dei seguenti requisiti:
- Una porta USB Type-C sul dispositivo o spedito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB Type-C standard (dispositivo USB Type-C).
- Una porta USB di tipo A sul dispositivo o fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB di tipo A standard.
- Una porta micro-AB USB sul dispositivo, che DEVE essere fornita con un cavo di adattamento a una porta USB Type-A standard.
[C-1-3] NON DEVE essere spedito con un adattatore che converte le porte USB Type-A o micro-AB in una porta USB Type-C (presa).
[C-SR-1] È FORTEMENTE CONSIGLIATO implementare la classe audio USB come documentato nella documentazione dell'SDK Android.
DEVE supportare la ricarica del dispositivo periferico USB collegato in modalità host; pubblicizzare una corrente di alimentazione di almeno 1,5 A come specificato nella sezione Termination Parameters (Parametri di terminazione) della specifica del cavo e del connettore USB Type-C, revisione 1.2 per i connettori USB Type-C o utilizzare l'intervallo di corrente di uscita della porta di ricarica downstream (CDP) come specificato nelle specifiche di ricarica della batteria USB, revisione 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,

[C-2-1] DEVE supportare la classe USB HID.
[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),:

[C-3-1] DEVE riconoscere qualsiasi dispositivo MTP (Media Transfer Protocol) connesso 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à Dual Role Power (DRP) come definita dalla specifica USB Type-C (sezione 4.5.1.3.3). Per le porte DRP, sui dispositivi che includono un jack audio da 3,5 mm, il rilevamento del sink di alimentazione USB (modalità host) POTREBBE essere disattivato per impostazione predefinita, ma l'utente DEVE poterlo attivare.
[C-SR-2] Are STRONGLY RECOMMENDED to support DisplayPort.
- DEVE supportare velocità di trasferimento dati USB SuperSpeed.
- Sono VIVAMENTE CONSIGLIATI per supportare Power Delivery per lo scambio di ruoli di dati e alimentazione.
[C-SR-3] È VIVAMENTE CONSIGLIATO di NON supportare la modalità accessorio adattatore audio come descritto nell'appendice A della specifica del cavo e del connettore USB Type-C, revisione 1.2.
DEVE 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.7.3. USB Power delivery

Se le implementazioni dei dispositivi includono una porta USB Type-C:

[C-SR-1] è FORTEMENTE CONSIGLIATO di implementare la classe di connettori USB Type-C del kernel e i nodi necessari che descrivono le connessioni USB Type-C e i ruoli di alimentazione e dati. Per informazioni dettagliate sull'implementazione, consulta la documentazione relativa a USB Type-C per Android.

Se le implementazioni dei dispositivi includono una porta USB Type-C e supportano l'alimentazione,

[C-SR-2] È FORTEMENTE CONSIGLIATO implementare tutti i nodi che descrivono USB Power Delivery. Per i dettagli di implementazione, consulta la documentazione USB PD di Android.

Se le implementazioni dei dispositivi includono una porta USB Type-C e supportano modalità alternative:

[C-SR-3] È FORTEMENTE CONSIGLIATO implementare le modalità alternative e le proprietà correlate all'identità della classe di connettori USB Type-C del kernel. Per informazioni dettagliate sull'implementazione, consulta la documentazione relativa a USB Type-C per Android.

Se le implementazioni dei dispositivi includono una porta USB Type-C e supportano la modalità alternativa Thunderbolt 3:

[C-SR-4] È VIVAMENTE CONSIGLIATO implementare la possibilità di ignorare la modalità alternativa corrente tramite la classe del connettore di tipo C.

7.8. Audio

7.8.1. Microfono

Se le implementazioni del dispositivo includono un microfono:

[C-1-1] DEVE segnalare la costante della funzionalità android.hardware.microphone.
[C-1-2] DEVE soddisfare i requisiti di registrazione audio indicati nella sezione 5.4.
[C-1-3] DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
[C-SR-1] È FORTEMENTE CONSIGLIATO supportare la registrazione di suoni quasi impercettibili 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] DEVE implementare l'API di registrazione audio almeno come no-ops, come indicato nella sezione 7.

7.8.2. Uscita audio

Se le implementazioni dei dispositivi includono un altoparlante o una porta di output audio/multimediale per una periferica di output audio come un jack audio da 3,5 mm a 4 conduttori o una porta in modalità host USB che utilizza la classe audio USB, queste:

[C-1-1] DEVE segnalare la costante della funzionalità android.hardware.audio.output.
[C-1-2] DEVE soddisfare i requisiti di riproduzione audio nella sezione 5.5.
[C-1-3] DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
[C-SR-1] VIVAMENTE CONSIGLIATO supportare la riproduzione di suoni quasi ultrasonici come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono un altoparlante o una porta di uscita audio:

[C-2-1] NON DEVE segnalare la funzionalità android.hardware.audio.output.
[C-2-2] DEVE implementare almeno le API correlate all'output audio come no-op.

Ai fini di questa sezione, una "porta di uscita" è un'interfaccia fisica, ad esempio un jack audio da 3,5 mm, una porta HDMI o una porta in modalità host USB con classe audio USB. Il supporto dell'uscita audio tramite protocolli basati su segnale radio come Bluetooth, Wi-Fi o rete mobile non è considerato un "output port".

7.8.2.1. Porte audio analogiche

Per essere compatibili con le cuffie e altri accessori audio che utilizzano la spina audio da 3,5 mm nell'ecosistema Android, se le implementazioni del dispositivo includono una o più porte audio analogiche, queste:

[C-SR-1] È FORTEMENTE CONSIGLIATO includere almeno una delle porte audio come jack audio da 3,5 mm a 4 conduttori.

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

[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 dei codici chiave per i seguenti 3 intervalli di impedenza equivalente tra il microfono e i conduttori di terra sul connettore audio:
- 70 ohm o meno: KEYCODE_HEADSETHOOK
- 210-290 ohm: KEYCODE_VOLUME_UP
- 360-680 ohm: KEYCODE_VOLUME_DOWN
[C-1-4] DEVE attivare ACTION_HEADSET_PLUG all'inserimento di una spina, ma solo dopo che tutti i contatti della spina toccano i segmenti pertinenti sul jack.
[C-1-5] DEVE essere in grado di pilotare almeno 150 mV ± 10% della tensione di uscita su un'impedenza dell'altoparlante di 32 ohm.
[C-1-6] DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V e 2,9 V.
[C-1-7] DEVE rilevare e mappare il codice tasto per il seguente intervallo di impedenza equivalente tra il microfono e i conduttori di terra sul connettore audio:
- 110-180 ohm: KEYCODE_VOICE_ASSIST
[C-SR-2] Sono FORTEMENTE CONSIGLIATI per supportare i jack audio con l'ordine dei pin OMTP.
[C-SR-3] Sono FORTEMENTE CONSIGLIATE per supportare la registrazione audio da cuffie stereo con microfono.

Se le implementazioni dei dispositivi 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 aggiuntivo del microfono impostato su 1, allora:

[C-2-1] DEVE supportare il rilevamento del microfono sull'accessorio audio collegato.

7.8.2.2. Porte audio digitali

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

7.8.3. Near-Ultrasound

L'audio quasi ultrasonico è la banda da 18,5 kHz a 20 kHz.

Implementazioni del dispositivo:

DEVE segnalare correttamente il supporto della funzionalità audio quasi ultrasonica tramite l'API AudioManager.getProperty come segue:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND è "true", le seguenti condizioni DEVONO essere soddisfatte dalle sorgenti audio VOICE_RECOGNITION e UNPROCESSED:

[C-1-1] La risposta di potenza media del microfono nella banda da 18,5 kHz a 20 kHz NON DEVE essere inferiore di più di 15 dB rispetto alla risposta a 2 kHz.
[C-1-2] Il rapporto segnale/rumore non ponderato del microfono nell'intervallo da 18,5 kHz a 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 a 18,5 kHz - 20 kHz NON DEVE essere inferiore di 40 dB rispetto alla risposta a 2 kHz.

7.8.4. Integrità del segnale

Implementazioni del dispositivo:

DEVE fornire un percorso del segnale audio privo di problemi per i flussi di input e output sui dispositivi portatili, come definito da zero problemi misurati durante un test di un minuto per percorso. Esegui il test utilizzando OboeTester "Automated Glitch Test".

Il test richiede un dongle di loopback audio, utilizzato direttamente in un jack da 3,5 mm e/o in combinazione con un adattatore da USB-C a 3,5 mm. Tutte le porte di uscita audio DEVONO essere testate.

OboeTester attualmente supporta i percorsi AAudio, pertanto le seguenti combinazioni DEVONO essere testate per rilevare problemi utilizzando AAudio:

Modalità Prestazioni	Condivisione	Frequenza di campionamento in uscita	In Chans	Out Chans
LOW_LATENCY	ESCLUSIVO	NON SPECIFICATO	1	2
LOW_LATENCY	ESCLUSIVO	NON SPECIFICATO	2	1
LOW_LATENCY	CONDIVISO	NON SPECIFICATO	1	2
LOW_LATENCY	CONDIVISO	NON SPECIFICATO	2	1
NESSUNO	CONDIVISO	48000	1	2
NESSUNO	CONDIVISO	48000	2	1
NESSUNO	CONDIVISO	44100	1	2
NESSUNO	CONDIVISO	44100	2	1
NESSUNO	CONDIVISO	16000	1	2
NESSUNO	CONDIVISO	16000	2	1

Un flusso affidabile DEVE soddisfare i seguenti criteri per il rapporto segnale/rumore (SNR) e la distorsione armonica totale (THD) per una sinusoide a 2000 Hz.

Trasduttore	THD	SNR
altoparlante integrato principale, misurato utilizzando un microfono di riferimento esterno	< 3,0%	>= 50 dB
microfono integrato principale, misurato utilizzando un altoparlante di riferimento esterno	< 3,0%	>= 50 dB
Jack analogici da 3,5 mm integrati, testati utilizzando l'adattatore loopback	< 1%	>= 60 dB
Adattatori USB forniti con lo smartphone, testati utilizzando l'adattatore loopback	< 1,0%	>= 60 dB

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 per la modalità VR, una funzionalità che gestisce il rendering stereoscopico delle notifiche e disattiva i componenti dell'interfaccia utente di sistema monoculare mentre un'applicazione VR è in primo piano.

7.9.2. Modalità Realtà virtuale - Alte prestazioni

Se le implementazioni dei dispositivi supportano la modalità VR:

[C-1-1] DEVE avere almeno 2 core fisici.
[C-1-2] DEVE dichiarare la funzionalità android.hardware.vr.high_performance.
[C-1-3] DEVE supportare la modalità Prestazioni sostenute.
[C-1-4] DEVE supportare OpenGL ES 3.2.
[C-1-5] MUST support android.hardware.vulkan.level 0.
DEVE supportare android.hardware.vulkan.level 1 o versioni successive.
[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, EGL_EXT_image_gl_colorspace, e mostrare le estensioni nell'elenco delle estensioni EGL disponibili.
[C-1-8] DEVE implementare GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures e mostrare le estensioni nell'elenco delle estensioni GL disponibili.
[C-SR-1] È FORTEMENTE CONSIGLIATO implementare GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
[C-SR-2] È VIVAMENTE CONSIGLIATO supportare Vulkan 1.1.
[C-SR-3] È FORTEMENTE CONSIGLIATO implementare VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image ed esporlo nell'elenco delle estensioni Vulkan disponibili.
[C-SR-4] È FORTEMENTE CONSIGLIATO esporre almeno una famiglia di code Vulkan in cui flags contenga sia VK_QUEUE_GRAPHICS_BIT sia VK_QUEUE_COMPUTE_BIT, e queueCount sia almeno 2.
[C-1-7] La GPU e il display DEVONO essere in grado di sincronizzare l'accesso al buffer frontale condiviso in modo che il rendering alternato per occhio dei contenuti VR a 60 fps con due contesti di rendering venga visualizzato senza artefatti di tearing visibili.
[C-1-9] DEVE implementare il supporto dei flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT come descritto nell'NDK.
[C-1-10] DEVE implementare il supporto per i AHardwareBuffer con qualsiasi combinazione dei flag di utilizzo AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT per almeno i seguenti formati: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR-5] Sono FORTEMENTE CONSIGLIATI per supportare l'allocazione di AHardwareBuffer con più di un livello e flag e formati specificati in C-1-10.
[C-1-11] DEVE supportare la decodifica H.264 almeno a 3840 x 2160 a 30 fps, compressa a una media di 40 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps - 10 Mbps o 2 istanze di 1920 x 1080 a 60 fps - 20 Mbps).
[C-1-12] DEVE supportare HEVC e VP9, DEVE essere in grado di decodificare almeno 1920 x 1080 a 30 fps compresso a una media di 10 Mbps e DOVREBBE essere in grado di decodificare 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps-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 1920 x 1080.
[C-SR-6] Sono FORTEMENTE CONSIGLIATI per una risoluzione dello schermo di almeno 2560 x 1440.
[C-1-15] Il display DEVE aggiornarsi almeno a 60 Hz in modalità VR.
[C-1-17] Il display DEVE supportare una modalità a bassa persistenza con persistenza ≤ 5 millisecondi, dove la persistenza è definita come il periodo di tempo in 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-SR-7] Sono FORTEMENTE CONSIGLIATI per supportare il tipo di canale diretto TYPE_HARDWARE_BUFFER per tutti i tipi di canali diretti elencati sopra.
[C-1-21] DEVE soddisfare i requisiti relativi a giroscopio, accelerometro e magnetometro per android.hardware.hifi_sensors, come specificato nella sezione 7.3.9.
[C-SR-8] Sono FORTEMENTE CONSIGLIATI per supportare la funzionalità android.hardware.sensor.hifi_sensors.
[C-1-22] DEVE avere una latenza end-to-end dal movimento al fotone non superiore a 28 millisecondi.
[C-SR-9] È FORTEMENTE CONSIGLIATO che la latenza end-to-end dal movimento al fotone non superi i 20 millisecondi.
[C-1-23] DEVE avere un rapporto del primo fotogramma, ovvero il rapporto tra la luminosità dei pixel del primo fotogramma dopo una transizione dal nero al bianco e la luminosità dei pixel bianchi in stato stazionario, di almeno l'85%.
[C-SR-10] È FORTEMENTE CONSIGLIATO che abbiano un rapporto tra il primo frame e il totale di almeno il 90%.
PUÒ fornire un core esclusivo all'applicazione in primo piano e PUÒ supportare l'API Process.getExclusiveCores per restituire il numero di core della CPU esclusivi per l'applicazione in primo piano principale.

Se il core esclusivo è supportato, il core:

[C-2-1] NON DEVE consentire l'esecuzione di altri processi dello spazio utente (ad eccezione dei driver di dispositivo utilizzati dall'applicazione), ma PUÒ consentire l'esecuzione di alcuni processi del kernel se necessario.

7.10. Tecnologia aptica

I dispositivi portatili o indossabili possono includere un attuatore aptico generico, disponibile per le applicazioni per scopi quali attirare l'attenzione tramite suonerie, sveglie, notifiche e feedback tattile generale.

Se le implementazioni del dispositivo NON includono un attuatore aptico generico, queste:

[7.10/C] MUST return false for Vibrator.hasVibrator().

Se le implementazioni del dispositivo includono almeno un attuatore aptico per uso generale,

[C-1-1] MUST return true for Vibrator.hasVibrator().
NON DEVE utilizzare un attuatore aptico (vibratore) con massa rotante eccentrica (ERM).
DEVE implementare tutte le costanti pubbliche per l'aptica chiara in android.view.HapticFeedbackConstants ovvero (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START e GESTURE_END).
DEVE implementare tutte le costanti pubbliche per l'feedback aptico chiaro in android.os.VibrationEffect, ovvero (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK e EFFECT_DOUBLE_CLICK) e tutte le costanti pubbliche PRIMITIVE_* fattibili per l'feedback aptico avanzato in android.os.VibrationEffect.Composition, ovvero (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Alcune di queste primitive, come LOW_TICK e SPIN, potrebbero essere fattibili solo se il vibratore supporta frequenze relativamente basse.
DEVE seguire le indicazioni per la mappatura delle costanti pubbliche in android.view.HapticFeedbackConstants alle costanti android.os.VibrationEffect consigliate, con le relazioni di ampiezza corrispondenti.
DEVONO utilizzare queste mappature costanti aptiche collegate.
DEVE seguire la valutazione della qualità per le API createOneShot() e createWaveform().
DEVE verificare che il risultato dell'API android.os.Vibrator.hasAmplitudeControl() pubblica rifletta correttamente le funzionalità del vibratore.
DEVE verificare le funzionalità per la scalabilità dell'ampiezza eseguendo android.os.Vibrator.hasAmplitudeControl().

Se le implementazioni dei dispositivi seguono la mappatura delle costanti aptiche,

DEVE verificare lo stato di implementazione eseguendo le API android.os.Vibrator.areAllEffectsSupported() e android.os.Vibrator.arePrimitivesSupported().
DEVE eseguire una valutazione della qualità per le costanti aptiche.
DEVE verificare e aggiornare, se necessario, la configurazione di riserva per i primitivi non supportati, come descritto nelle indicazioni per l'implementazione per le costanti.
DEVE fornire un supporto di fallback per mitigare il rischio di errore come descritto qui.

7.11. Media Performance Class

La classe di prestazioni multimediali dell'implementazione del dispositivo può essere ottenuta dall'API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. I requisiti per la classe di prestazioni multimediali sono definiti per ogni versione di Android a partire da R (versione 30). Il valore speciale 0 indica che il dispositivo non appartiene a una classe di prestazioni multimediali.

Se le implementazioni del dispositivo restituiscono un valore diverso da zero per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

[C-1-1] DEVE restituire almeno un valore pari a android.os.Build.VERSION_CODES.R.
[C-1-2] DEVE essere un'implementazione di un dispositivo portatile.
[C-1-3] DEVE soddisfare tutti i requisiti per la "Classe di rendimento dei contenuti multimediali" descritti nella sezione 2.2.7.

In altre parole, la classe di prestazioni multimediali in Android T è definita solo per i dispositivi portatili con versione T, S o R.

Per i requisiti specifici per dispositivo, consulta la sezione 2.2.7.

8. Prestazioni e potenza

Alcuni criteri minimi di prestazioni e potenza sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di base che gli sviluppatori avrebbero durante lo sviluppo di un'app.

8.1. Coerenza dell'esperienza utente

È possibile fornire un'interfaccia utente fluida all'utente finale se sono presenti determinati requisiti minimi per garantire una frequenza fotogrammi e tempi di risposta coerenti per applicazioni e giochi. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POSSONO avere requisiti misurabili per la latenza dell'interfaccia utente e il cambio di attività come descritto nella sezione 2.

8.2. Prestazioni di accesso I/O di file

Fornire una base di riferimento comune per prestazioni di accesso ai file coerenti nell'archivio privato dei dati dell'applicazione (partizione /data) consente agli sviluppatori di app di impostare un'aspettativa adeguata che aiuti la progettazione del software. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POSSONO 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.
Prestazioni di scrittura casuale. Misurata scrivendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.
Prestazioni di lettura sequenziale. Misurato leggendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
Rendimento di lettura casuale. Misurata leggendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.

8.3. Modalità di risparmio energetico

Se le implementazioni dei dispositivi includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo che sono incluse in AOSP (ad es. Bucket di standby delle app, Doze) o estendono le funzionalità per applicare limitazioni più rigide rispetto al bucket di standby delle app con limitazioni, queste:

[C-1-1] NON DEVE discostarsi dall'implementazione AOSP per l'attivazione, la manutenzione, gli algoritmi di riattivazione e l'utilizzo delle impostazioni di sistema globali o DeviceConfig delle modalità di risparmio energetico Standby delle app e Sospensione.
[C-1-2] NON DEVE discostarsi dall'implementazione AOSP per l'utilizzo di impostazioni globali o DeviceConfig per gestire la limitazione di job, sveglie e rete per le app in ogni bucket per la funzionalità App in standby.
[C-1-3] NON DEVE discostarsi dall'implementazione AOSP per il numero di bucket di standby delle app utilizzati per lo standby delle app.
[C-1-4] DEVE implementare i bucket di standby delle app e Doze come descritto in Gestione dell'alimentazione.
[C-1-5] DEVE restituire true per PowerManager.isPowerSaveMode() quando il dispositivo è in modalità di risparmio energetico.
[C-1-6] DEVE fornire all'utente la possibilità di visualizzare tutte le app esentate dalle modalità di risparmio energetico Standby delle app e Sospensione o da qualsiasi ottimizzazione della batteria e DEVE implementare l'intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS per chiedere all'utente di consentire a un'app di ignorare le ottimizzazioni della batteria.
[C-SR-1] Sono FORTEMENTE CONSIGLIATI per fornire all'utente la possibilità di attivare e disattivare la funzionalità di risparmio energetico.
[C-SR-2] È FORTEMENTE CONSIGLIATO fornire agli utenti la possibilità di visualizzare tutte le app esentate dalle modalità di risparmio energetico Standby delle app e Sospensione.

Se le implementazioni dei dispositivi estendono le funzionalità di gestione dell'alimentazione incluse in AOSP e questa estensione applica restrizioni più rigorose rispetto al bucket di standby delle app rare, fai riferimento alla sezione 3.5.1.

Oltre alle modalità di risparmio energetico, le implementazioni dei dispositivi Android POSSONO implementare uno o tutti e quattro gli stati di alimentazione in sospensione definiti da Advanced Configuration and Power Interface (ACPI).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S4 come definiti da ACPI,

[C-1-1] DEVE entrare in questo stato solo dopo che l'utente ha intrapreso un'azione esplicita per mettere il dispositivo in uno stato inattivo (ad es. chiudendo un coperchio che fa fisicamente parte del dispositivo o spegnendo un veicolo o una televisione) e prima che l'utente riattivi il dispositivo (ad es. aprendo il coperchio o riaccendendo il veicolo o la televisione).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S3 come definiti da ACPI,

[C-2-1] DEVE soddisfare il requisito C-1-1 sopra indicato oppure DEVE entrare nello stato S3 solo quando le applicazioni di terze parti non necessitano delle risorse di sistema (ad es. lo schermo, la CPU).

Al contrario, DEVE uscire dallo stato S3 quando le applicazioni di terze parti hanno bisogno delle risorse di sistema, come descritto in questo SDK.

Ad esempio, mentre le applicazioni di terze parti richiedono di mantenere lo schermo acceso tramite FLAG_KEEP_SCREEN_ON o di mantenere la CPU in esecuzione tramite PARTIAL_WAKE_LOCK, il dispositivo NON DEVE entrare nello stato S3 a meno che, come descritto in C-1-1, l'utente non abbia intrapreso un'azione esplicita per mettere il dispositivo in uno stato inattivo. Al contrario, quando viene attivata un'attività che le app di terze parti implementano tramite JobScheduler o quando Firebase Cloud Messaging viene distribuito alle app di terze parti, il dispositivo DEVE uscire dallo stato S3, a meno che l'utente non abbia messo il dispositivo in uno stato inattivo. Questi non sono esempi esaustivi e AOSP implementa ampi segnali di riattivazione che attivano la riattivazione da questo stato.

8.4. Contabilizzazione del consumo energetico

Una contabilizzazione e una generazione di report più accurate del consumo energetico forniscono allo sviluppatore di app sia gli incentivi che gli strumenti per ottimizzare il modello di utilizzo dell'energia dell'applicazione.

Implementazioni del dispositivo:

[C-SR-1] È FORTEMENTE CONSIGLIATO fornire un profilo di alimentazione per componente che definisca il valore di consumo di corrente per ogni componente hardware e il consumo eccessivo della batteria causato dai componenti nel tempo, come documentato nel sito del Android Open Source Project.
[C-SR-2] VIVAMENTE CONSIGLIATO di segnalare tutti i valori di consumo energetico in milliampere ora (mAh).
[C-SR-3] VIVAMENTE CONSIGLIATO di segnalare il consumo energetico della CPU per ogni UID del processo. L'Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
[C-SR-4] VIVAMENTE CONSIGLIATO di rendere disponibile questo consumo energetico tramite il comando shell adb shell dumpsys batterystats allo sviluppatore di app.
DEVE essere attribuito al componente hardware stesso se non è possibile attribuire l'utilizzo di energia del componente hardware a un'applicazione.

8.5. Prestazioni costanti

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

Implementazioni del dispositivo:

[C-0-1] DEVE segnalare con precisione il supporto della modalità Prestazioni sostenute tramite il metodo API PowerManager.isSustainedPerformanceModeSupported().
DEVE supportare la modalità Prestazioni sostenute.

Se le implementazioni dei dispositivi segnalano il supporto della modalità 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 dei dispositivi supportano la prenotazione di un core esclusivo per l'applicazione in primo piano principale:

[C-2-1] DEVE segnalare tramite il metodo 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 dello spazio utente, ad eccezione dei driver del 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:

[C-3-1] DEVE restituire un elenco vuoto tramite il metodo API Process.getExclusiveCores().

8.6. Limiti di memoria delle app

MemoryLimiter, un nuovo componente di ActivityManagerService, e i limiti di memoria predefiniti delle app, derivati dalla memoria fisica disponibile, imporranno limiti alla quantità di DRAM utilizzata per ogni processo dell'app. Questa limitazione si applica a tutta la memoria allocata all'interno del processo dell'app, garantendo che i limiti funzionino come comportamento contrattuale fondamentale con gli sviluppatori di app.

Implementazioni del dispositivo:

[C-0-1] NON DEVE utilizzare metodi, liste consentite o norme per aggirare i limiti di memoria di runtime impostati per le applicazioni.

9. Compatibilità del modello di sicurezza

Implementazioni del dispositivo:

[C-0-1] DEVE implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento su sicurezza e autorizzazioni nelle API nella documentazione per sviluppatori Android.
[C-0-2] DEVE supportare l'installazione di applicazioni autofirmate senza richiedere autorizzazioni/certificati aggiuntivi da terze parti/autorità.

Se le implementazioni del dispositivo dichiarano la funzionalità android.hardware.security.model.compatible,

[C-1-1] DEVE supportare i requisiti elencati nelle seguenti sottosezioni.

9.1. Autorizzazioni

Implementazioni del dispositivo:

[C-0-1] DEVE supportare il modello di autorizzazioni Android e il modello di ruoli Android come definito nella documentazione per gli sviluppatori Android. In particolare, DEVONO applicare ogni autorizzazione e ruolo definito come descritto nella documentazione dell'SDK; nessuna autorizzazione e nessun ruolo può essere omesso, modificato o ignorato.
POSSONO aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe ID autorizzazione non si trovino nello spazio dei nomi android.\*.
[C-0-2] Le autorizzazioni con un protectionLevel di PROTECTION_FLAG_PRIVILEGED DEVONO essere concesse solo alle app preinstallate nei percorsi privilegiati dell'immagine di sistema (nonché ai file APEX) e rientrare nel sottoinsieme delle 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.
[C-SR-1] Le autorizzazioni con un protectionLevel di PROTECTION_SIGNATURE sono FORTEMENTE CONSIGLIATE solo per:
- App preinstallate nell'immagine di sistema (nonché file APEX).
- App inserite nella lista consentita con autorizzazioni consentite se non sono incluse nell'immagine di sistema.
Nota: l'implementazione AOSP soddisfa questo requisito leggendo e rispettando le autorizzazioni consentite per ogni app dai file nel percorso etc/permissions/.

Le autorizzazioni con un livello di protezione pericoloso sono autorizzazioni di runtime. Le applicazioni con targetSdkVersion > 22 le richiedono al runtime.

Implementazioni del dispositivo:

[C-0-3] DEVE mostrare un'interfaccia dedicata all'utente per decidere se concedere le autorizzazioni di runtime richieste e fornire un'interfaccia per la gestione delle autorizzazioni di runtime.
[C-0-5] NON DEVE concedere autorizzazioni di runtime alle app, a meno che:
- Vengono installate al momento della spedizione del dispositivo E
- Il consenso dell'utente può essere ottenuto prima che l'applicazione utilizzi l'autorizzazione,
OPPURE
- Le autorizzazioni di runtime vengono concesse dai criteri di concessione delle autorizzazioni predefiniti o per la detenzione di un ruolo della piattaforma.
[C-0-6] DEVE concedere l'autorizzazione android.permission.RECOVER_KEYSTORE solo alle app di sistema che registrano un agente di recupero adeguatamente protetto. Un agente di recupero adeguatamente protetto è definito come un agente software sul dispositivo che si sincronizza con uno spazio di archiviazione remoto esterno al dispositivo, dotato di hardware sicuro con protezione equivalente o superiore a quella descritta nel servizio Google Cloud Key Vault per impedire attacchi brute force al fattore di conoscenza della schermata di blocco.

Implementazioni del dispositivo:

[C-0-7] DEVE rispettare le proprietà dell'autorizzazione di accesso alla posizione di Android quando un'app richiede i dati di posizione o i dati delle attività fisiche tramite l'API Android standard o un meccanismo proprietario. Questi dati includono, a titolo esemplificativo:
- Posizione del dispositivo (ad es. latitudine e longitudine) come descritto nella Sezione 9.8.8.
- Informazioni che possono essere utilizzate per determinare o stimare la posizione del dispositivo (ad es. SSID, BSSID, ID cella o posizione della rete a cui è connesso il dispositivo).
- Attività fisica dell'utente o classificazione dell'attività fisica.

Più nello specifico, le implementazioni dei dispositivi:

[C-0-8] DEVE ottenere il consenso dell'utente per consentire a un'app di accedere ai dati di posizione o ai dati delle attività fisiche.
[C-0-9] DEVE concedere un'autorizzazione di runtime SOLO all'app che dispone di un'autorizzazione sufficiente come descritto nell'SDK. Ad esempio, TelephonyManager#getServiceState richiede android.permission.ACCESS_FINE_LOCATION.

Le uniche eccezioni alle proprietà dell'autorizzazione di accesso alla posizione di Android sopra indicate riguardano le app che non accedono alla posizione per derivare o identificare la posizione dell'utente, in particolare:

Quando le app dispongono dell'autorizzazione RADIO_SCAN_WITHOUT_LOCATION.
Per la configurazione e l'impostazione del dispositivo, in cui le app di sistema dispongono dell'autorizzazione NETWORK_SETTINGS o NETWORK_SETUP_WIZARD.

Le autorizzazioni possono essere contrassegnate come limitate, modificandone il comportamento.

[C-0-10] Le autorizzazioni contrassegnate dal flag hardRestricted NON DEVONO essere concesse a un'app, a meno che:
- Un file APK dell'app si trova nella partizione di sistema.
- L'utente assegna a un'app un ruolo associato alle autorizzazioni hardRestricted.
- Il programma di installazione concede hardRestricted a un'app.
- A un'app viene concesso hardRestricted in una versione precedente di Android.
[C-0-11] Le app che dispongono di un'autorizzazione softRestricted DEVONO ottenere solo un accesso limitato e NON DEVONO ottenere l'accesso completo finché non vengono inserite nella lista consentita come descritto nell'SDK, in cui l'accesso completo e limitato è definito per ogni autorizzazione softRestricted (ad esempio, READ_EXTERNAL_STORAGE).
[C-0-12] NON DEVE fornire API o funzioni personalizzate per aggirare le limitazioni delle autorizzazioni definite nelle API setPermissionPolicy e setPermissionGrantState.
[C-0-13] DEVE utilizzare le API AppOpsManager per registrare e monitorare ogni accesso programmatico ai dati protetti da permessi pericolosi da attività e servizi Android.
[C-0-14] DEVE assegnare ruoli solo ad applicazioni con funzionalità che soddisfano i requisiti del ruolo.
[C-0-15] NON DEVE definire ruoli che duplicano o includono funzionalità di ruoli definiti dalla piattaforma.

Se i dispositivi includono sensori di dati che espongono dati biometrici correlati alla salute come la frequenza cardiaca o la temperatura cutanea, questi dati biometrici:

[C-0-16] DEVE essere protetto dalle autorizzazioni della piattaforma di android.permission-group.HEALTH, se esiste un'autorizzazione corrispondente in HealthPermissions.
[C-0-17] MUST, if no platform permission matches the desired data type, be guarded by a custom system permission. Ad esempio ELECTROCARDIOGRAM.

Se i dispositivi segnalano android.software.managed_users, significa che:

[C-1-1] NON DEVE avere le seguenti autorizzazioni concesse automaticamente dall'amministratore:
- Località (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Fotocamera (CAMERA)
- Microfono (RECORD_AUDIO)
- Sensore del corpo (BODY_SENSORS)
- Salute (HealthPermissions)
- Attività fisica (ACTIVITY_RECOGNITION)

Se i dispositivi segnalano android.software.managed_users, significa che:

[C-1-1] NON DEVE avere le seguenti autorizzazioni concesse automaticamente dall'amministratore:
- Località (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Fotocamera (CAMERA)
- Microfono (RECORD_AUDIO)
- Sensore del corpo (BODY_SENSORS)
- Attività fisica (ACTIVITY_RECOGNITION)

Se le implementazioni del dispositivo forniscono un'opzione per scegliere quali app possono disegnarsi sopra altre app con un'attività che gestisce l'intent ACTION_MANAGE_OVERLAY_PERMISSION, queste:

[C-2-1] DEVE garantire che tutte le attività con filtri di intent per l'intent ACTION_MANAGE_OVERLAY_PERMISSION abbiano la stessa schermata dell'interfaccia utente, indipendentemente dall'app di avvio o dalle informazioni che fornisce.

Se le implementazioni dei dispositivi segnalano android.software.device_admin, significa che:

[C-3-1] DEVE mostrare un disclaimer durante la configurazione del dispositivo completamente gestito (configurazione del proprietario del dispositivo) che indica che l'amministratore IT avrà la possibilità di consentire alle app di controllare le impostazioni dello smartphone, tra cui microfono, fotocamera e posizione, con opzioni per l'utente per continuare o uscire dalla configurazione, A MENO CHE l'amministratore non abbia disattivato il controllo delle autorizzazioni sul dispositivo.

Se le implementazioni del dispositivo preinstallano pacchetti che contengono uno dei ruoli Intelligence UI di sistema, Intelligence audio ambientale di sistema, Intelligence audio di sistema, Intelligence notifiche di sistema, Intelligence testo di sistema, o Intelligence visiva di sistema, i pacchetti:

[C-4-1] DEVE soddisfare tutti i requisiti descritti per le implementazioni dei dispositivi nelle sezioni 9.8.6. dati a livello di sistema operativo e ambientali e 9.8.15. Implementazioni delle API Sandboxed.

9.2. UID e isolamento dei processi

Implementazioni del dispositivo:

[C-0-1] DEVE supportare il modello di sandbox delle app per Android, in cui ogni applicazione viene eseguita come UID in stile 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 nel riferimento a sicurezza e autorizzazioni.

9.3. Autorizzazioni del file system

Implementazioni del dispositivo:

[C-0-1] DEVE supportare il modello di autorizzazioni di accesso ai file Android come definito nel riferimento a sicurezza e autorizzazioni.

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 software o tecnologie diversi dal formato eseguibile Dalvik o dal codice nativo. In altre parole:

[C-0-1] Gli ambienti di runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella sezione 9.
[C-0-2] I runtime alternativi NON DEVONO avere 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 dalla Protezione Android limitate alle applicazioni di sistema.
[C-0-4] Gli ambienti di runtime alternativi DEVONO rispettare il modello di sandbox di Android e le applicazioni installate utilizzando un ambiente di runtime alternativo NON DEVONO riutilizzare la sandbox di qualsiasi altra app installata sul dispositivo, tranne che tramite i meccanismi standard di Android di ID utente condiviso e certificato di firma.
[C-0-5] Gli ambienti di runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso alle sandbox corrispondenti ad altre applicazioni per Android.
[C-0-6] I runtime alternativi NON DEVONO essere avviati con, ricevere o concedere ad altre applicazioni privilegi di superutente (root) o di qualsiasi altro ID utente.
[C-0-7] Quando i file .apk di runtime alternativi sono inclusi nell'immagine di sistema delle implementazioni del dispositivo, DEVONO essere firmati con una chiave distinta da quella utilizzata per firmare 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), l'ambiente di 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, DEVE elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che utilizza quel runtime.
I runtime alternativi DEVONO 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 utilizzano il runtime alternativo.

9.5. Supporto multiutente

Android include il supporto multiutente e fornisce il supporto per l'isolamento completo degli utenti e la clonazione dei profili utente con isolamento parziale (ovvero un singolo profilo utente aggiuntivo di tipo android.os.usertype.profile.CLONE).

Le implementazioni dei dispositivi POSSONO, ma NON DEVONO, attivare il multiutente se utilizzano supporti rimovibili per l'archiviazione esterna principale.

Se le implementazioni dei dispositivi includono il supporto di più utenti:

[C-1-2] DEVE implementare, per ogni utente, un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento su sicurezza e autorizzazioni nelle API.
[C-1-3] DEVE disporre di directory di archiviazione delle applicazioni condivise separate e isolate (ovvero /sdcard) per ogni istanza utente.
[C-1-4] DEVE garantire che le applicazioni di proprietà di un utente e in esecuzione per suo conto non possano elencare, leggere o scrivere nei file di proprietà di qualsiasi altro utente, 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 è attivato il multiutente utilizzando una chiave archiviata 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 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 del dispositivo includono il supporto di più utenti, per tutti gli utenti, ad eccezione di quelli creati appositamente per l'esecuzione di due istanze della stessa app:

[C-2-1] DEVE avere directory di archiviazione delle applicazioni condivise separate e isolate (ovvero /sdcard) per ogni istanza utente.
[C-2-2] 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 qualsiasi altro utente, anche se i dati di entrambi gli utenti sono archiviati nello stesso volume o file system.

Le implementazioni del dispositivo POSSONO creare un singolo profilo utente aggiuntivo di tipo android.os.usertype.profile.CLONE rispetto all'utente principale (e solo rispetto all'utente principale) allo scopo di eseguire due istanze della stessa app. Queste due istanze condividono uno spazio di archiviazione parzialmente isolato, vengono presentate all'utente finale nel launcher contemporaneamente e vengono visualizzate nella stessa visualizzazione Recenti. Ad esempio, questo potrebbe essere utilizzato per supportare l'installazione da parte dell'utente di due istanze separate di una singola app su un dispositivo dual SIM.

Se le implementazioni dei dispositivi creano il profilo utente aggiuntivo descritto sopra, devono:

[C-3-1] DEVE fornire l'accesso solo allo spazio di archiviazione o ai dati già accessibili al profilo utente principale o di proprietà diretta di questo profilo utente aggiuntivo.
[C-3-2] NON DEVE avere questo profilo come profilo di lavoro.
[C-3-3] MUST have isolated private app data directories from the parent user account.
[C-3-4] NON DEVE consentire la creazione del profilo utente aggiuntivo se è stato eseguito il provisioning di un proprietario del dispositivo (vedi sezione 3.9.1) o consentire il provisioning di un proprietario del dispositivo senza prima rimuovere il profilo utente aggiuntivo.

Se le implementazioni dei dispositivi creano il profilo utente aggiuntivo descritto sopra, devono:

[C-4-1] DEVE consentire la gestione degli intent riportati di seguito provenienti dal profilo aggiuntivo da parte delle applicazioni dell'utente principale sul dispositivo:
- Intent.ACTION_VIEW
- Intent.ACTION_SENDTO
- Intent.ACTION_SEND
- Intent.ACTION_EDIT
- Intent.ACTION_INSERT
- Intent.ACTION_INSERT_OR_EDIT
- Intent.ACTION_SEND_MULTIPLE
- Intent.ACTION_PICK
- Intent.ACTION_GET_CONTENT
- MediaStore.ACTION_IMAGE_CAPTURE
- MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] DEVE ereditare tutte le limitazioni utente dei criteri del dispositivo e le restrictions(list below) non utente selezionate applicate all'utente principale del dispositivo a questo profilo utente aggiuntivo.
[C-4-3] DEVE consentire la scrittura di contatti da questo profilo aggiuntivo solo tramite i seguenti intent:
[C-4-4] NON DEVE avere sincronizzazioni dei contatti in esecuzione per le applicazioni in esecuzione in questo profilo utente aggiuntivo.
[C-4-5] DEVONO consentire solo alle applicazioni nel profilo aggiuntivo che hanno un'attività di avvio di accedere ai contatti già accessibili al profilo utente principale.

Se le implementazioni dei dispositivi creano il profilo utente aggiuntivo descritto sopra, includono almeno una videocamera e l'applicazione della videocamera preinstallata gestisce gli intent MediaStore.ACTION_MOTION_PHOTO_CAPTURE o MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, allora:

[C-5-1] DEVE consentire alle applicazioni dell'utente principale di gestire questi intent provenienti da quel profilo utente aggiuntivo.

9.6. Avviso SMS premium

Android include il supporto per avvisare gli utenti di eventuali messaggi SMS premium in uscita. Gli SMS premium sono messaggi di testo inviati a un servizio registrato presso un operatore che potrebbe 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 a numeri identificati da 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. Security Features

Le implementazioni dei dispositivi DEVONO garantire la conformità alle funzionalità di sicurezza sia nel kernel sia nella piattaforma, come descritto di seguito.

La sandbox Android include funzionalità che utilizzano il sistema di controllo dell'accesso obbligatorio (MAC) Security-Enhanced Linux (SELinux), il sandboxing seccomp e altre funzionalità di sicurezza nel kernel Linux. Implementazioni del dispositivo:

[C-0-1] DEVE mantenere la compatibilità con le applicazioni esistenti, anche quando SELinux o altre funzionalità di sicurezza vengono implementate al di sotto del framework Android.
[C-0-2] NON DEVE avere un'interfaccia utente visibile quando viene rilevata e bloccata correttamente una violazione della sicurezza 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 comporta un exploit riuscito.
[C-0-3] NON DEVE rendere configurabili per l'utente o lo sviluppatore di app SELinux o qualsiasi altra funzionalità di sicurezza implementata 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 Device Administration) di configurare un criterio che compromette la compatibilità.
[C-0-5] DEVE dividere il framework multimediale in più processi in modo che sia possibile concedere l'accesso in modo più specifico per ogni processo come descritto nel sito Android Open Source Project.
[C-0-6] DEVE implementare un meccanismo di sandboxing delle applicazioni del kernel che consenta il filtraggio delle chiamate di sistema utilizzando un criterio configurabile da programmi multithread. L'Android Open Source Project upstream soddisfa questo requisito attivando seccomp-BPF con la sincronizzazione di threadgroup (TSYNC) come descritto nella sezione Configurazione del kernel di source.android.com.

L'integrità del kernel e le funzionalità di autoprotezione sono parte integrante della sicurezza di Android. Implementazioni del dispositivo:

[C-0-7] MUST implement kernel stack buffer overflow protection mechanisms. Esempi di questi meccanismi sono CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] DEVE 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 esempio, sono attivati sia rodata che CONFIG_STRICT_KERNEL_RWX).
[C-0-9] DEVE implementare il controllo dei limiti delle dimensioni degli oggetti statici e dinamici delle copie tra lo spazio utente e lo spazio kernel (ad es. CONFIG_HARDENED_USERCOPY) sui dispositivi originariamente forniti con livello API 28 o superiore.
[C-0-10] NON DEVE eseguire la memoria dello spazio utente durante l'esecuzione in modalità kernel (ad es. PXN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi originariamente spediti con il livello API 28 o versioni successive.
[C-0-11] NON DEVE leggere o scrivere nella 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) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
[C-0-12] DEVE implementare l'isolamento della tabella delle pagine del kernel se l'hardware è vulnerabile a CVE-2017-5754 su tutti i dispositivi originariamente forniti con livello API 28 o superiore (ad es. CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] DEVE implementare la protezione della predizione dei rami se l'hardware è vulnerabile alla CVE-2017-5715 su tutti i dispositivi originariamente forniti con livello API 28 o superiore (ad es. CONFIG_HARDEN_BRANCH_PREDICTOR).
[C-SR-1] È 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).
[C-SR-2] Sono FORTEMENTE CONSIGLIATI per randomizzare il layout del codice kernel e della memoria ed evitare esposizioni che comprometterebbero la randomizzazione (ad es. CONFIG_RANDOMIZE_BASE con l'entropia del bootloader tramite /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).
[C-SR-3] È VIVAMENTE CONSIGLIATO di attivare l'integrità del flusso di controllo (CFI) nel kernel per fornire una protezione aggiuntiva contro gli attacchi di riutilizzo del codice (ad es. CONFIG_CFI_CLANG e CONFIG_SHADOW_CALL_STACK).
[C-SR-4] È FORTEMENTE CONSIGLIATO di non disattivare l'integrità del flusso di controllo (CFI), lo stack di chiamate shadow (SCS) o la sanificazione dell'overflow di interi (IntSan) sui componenti su cui è attivata.
[C-SR-5] È VIVAMENTE CONSIGLIATO di attivare CFI, SCS e IntSan per qualsiasi componente userspace aggiuntivo sensibile alla sicurezza, come spiegato in CFI e IntSan.
[C-SR-6] È FORTEMENTE CONSIGLIATO attivare l'inizializzazione dello stack nel kernel per evitare l'utilizzo di variabili locali non inizializzate (CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO). Inoltre, le implementazioni dei dispositivi NON DEVONO presupporre il valore utilizzato dal compilatore per inizializzare le variabili locali.
[C-SR-7] È FORTEMENTE CONSIGLIATO di attivare l'inizializzazione dell'heap nel kernel per impedire l'utilizzo di allocazioni dell'heap non inizializzate (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) e NON DEVONO presupporre il valore utilizzato dal kernel per inizializzare queste allocazioni.

Se le implementazioni dei dispositivi utilizzano un kernel Linux in grado di supportare SELinux, devono:

[C-1-1] MUST implement SELinux.
[C-1-2] DEVE impostare SELinux sulla modalità di applicazione globale.
[C-1-3] MUST configure all domains in enforcing mode. Non sono consentiti domini in modalità permissiva, inclusi i domini specifici di un dispositivo/fornitore.

[C-1-4] NON DEVE:
- Modifica, ometti o sostituisci le regole neverallow presenti nella cartella system/sepolicy fornita nel progetto Android Open Source Project (AOSP) upstream
- Aggiunta errata di etichette SELinux AOSP a componenti non AOSP
Il criterio DEVE essere conforme a tutte le regole neverallow presenti, sia per i domini SELinux AOSP sia per i domini specifici del dispositivo/fornitore.

[C-1-5] DEVONO eseguire applicazioni di terze parti che hanno come target il livello API 28 o superiore in sandbox SELinux per applicazione con restrizioni SELinux per app nella directory dei dati privati di ogni applicazione.
DEVE conservare i criteri SELinux predefiniti forniti nella cartella system/sepolicy dell'Android Open Source Project e aggiungere solo questi criteri per la propria configurazione specifica del dispositivo.

Se le implementazioni dei dispositivi utilizzano un kernel diverso da Linux o Linux senza SELinux, devono:

[C-2-1] DEVE utilizzare un sistema di controllo dell'accesso obbligatorio equivalente a SELinux.

Se le implementazioni dei dispositivi utilizzano dispositivi I/O in grado di DMA, questi:

[C-SR-9] È VIVAMENTE CONSIGLIATO isolare ogni dispositivo I/O in grado di DMA, utilizzando una IOMMU (ad es. ARM SMMU).

Android include diverse funzionalità di difesa in profondità che sono parte integrante della sicurezza del dispositivo. Inoltre, Android si concentra sulla riduzione delle classi chiave di bug comuni che contribuiscono a una scarsa qualità e sicurezza.

Per ridurre i bug di memoria, le implementazioni dei dispositivi:

[C-SR-10] È FORTEMENTE CONSIGLIATO eseguire il test utilizzando strumenti di rilevamento degli errori di memoria dello spazio utente come MTE per i dispositivi ARMv9, HWASan per i dispositivi ARMv8+ o ASan per altri tipi di dispositivi.
[C-SR-11] È VIVAMENTE CONSIGLIATO di eseguire il test utilizzando strumenti di rilevamento degli errori di memoria del kernel come KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS per i dispositivi ARMv9, CONFIG_KASAN_SW_TAGS per i dispositivi ARMv8 o CONFIG_KASAN_GENERIC per altri tipi di dispositivi).
[C-SR-12] È FORTEMENTE CONSIGLIATO utilizzare strumenti di rilevamento degli errori di memoria in produzione come MTE, GWP-ASan e KFENCE.

Se le implementazioni del dispositivo utilizzano un TEE basato su Arm TrustZone:

[C-SR-13] È FORTEMENTE CONSIGLIATO utilizzare un protocollo standard per la condivisione della memoria tra Android e TEE, come Arm Firmware Framework for Armv8-A (FF-A).
[C-SR-14] È FORTEMENTE CONSIGLIATO limitare le applicazioni attendibili all'accesso alla memoria che è stata esplicitamente condivisa con loro tramite il protocollo sopra indicato. Se il dispositivo supporta il livello di eccezione Arm S-EL2, questo deve essere applicato dal gestore delle partizioni sicure. In caso contrario, questa operazione deve essere applicata dal sistema operativo TEE.

Una tecnologia di sicurezza della memoria è una tecnologia che mitiga almeno le seguenti classi di bug con un'alta probabilità (> 90%) nelle applicazioni che utilizzano l'opzione manifest android:memtagMode:

overflow del buffer heap
use-after-free
double free
wild free (libero da un puntatore non malloc)

Implementazioni del dispositivo:

[C-SR-15] Are STRONGLY RECOMMENDED to set ro.arm64.memtag.bootctl_supported.

Se le implementazioni del dispositivo impostano la proprietà di sistema ro.arm64.memtag.bootctl_supported su true:

[C-3-1] DEVE consentire alla proprietà di sistema arm64.memtag.bootctl di accettare un elenco separato da virgole dei seguenti valori, con l'effetto desiderato applicato al successivo riavvio:
- memtag: è attivata una tecnologia Memory Safety come definita sopra
- memtag-once: una tecnologia di sicurezza della memoria come definita sopra è abilitata temporaneamente e viene disabilitata automaticamente al successivo riavvio
- memtag-off: una tecnologia di sicurezza della memoria come definita sopra è disattivata
[C-3-2] DEVE consentire all'utente della shell di impostare arm64.memtag.bootctl.
[C-3-3] DEVE consentire a qualsiasi processo di leggere arm64.memtag.bootctl.
[C-3-4] DEVE impostare arm64.memtag.bootctl sullo stato attualmente richiesto all'avvio e DEVE anche aggiornare la proprietà, se l'implementazione del dispositivo consente di modificare lo stato senza modificare la proprietà di sistema.
[C-SR-16] È VIVAMENTE CONSIGLIATO mostrare un'impostazione sviluppatore che imposti memtag-once e riavvii il dispositivo. Con un bootloader compatibile, l'Android Open Source Project soddisfa i requisiti sopra indicati tramite il protocollo bootloader MTE.

Se un dispositivo dichiara android.hardware.telephony, supporta la funzionalità radio CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK e include un modem cellulare che supporta le connessioni 2G, l'implementazione del dispositivo:

[C-SR-17] È VIVAMENTE CONSIGLIATO fornire all'utente la possibilità di disattivare e attivare il 2G.
[C-SR-18] È FORTEMENTE CONSIGLIATO di non ignorare la possibilità per l'utente di disattivare e attivare il 2G tramite qualsiasi altra entità dispositivo, ad eccezione di un amministratore del dispositivo che utilizza UserManager.DISALLOW_CELLULAR_2G.
[C-SR-19] È VIVAMENTE CONSIGLIATO chiamare TelephonyManager.setAllowedNetworkTypesForReason con il motivo ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G per soddisfare questo requisito.
[C-SR-20] È FORTEMENTE CONSIGLIATO di determinare il supporto del modem cellulare per il 2G chiamando il numero TelephonyManager.getSupportedRadioAccessFamily. Per maggiori dettagli, consulta Disattivare il 2G.

9.8. Privacy

9.8.1. Cronologia di utilizzo

Android memorizza la cronologia delle scelte dell'utente e la gestisce tramite UsageStatsManager.

Implementazioni del dispositivo:

[C-0-1] DEVE mantenere un periodo di conservazione ragionevole di questa cronologia utente.
[C-SR-1] È FORTEMENTE CONSIGLIATO di mantenere il periodo di conservazione di 14 giorni configurato per impostazione predefinita nell'implementazione AOSP.

Android memorizza gli eventi di sistema utilizzando gli identificatori StatsLog e gestisce la cronologia tramite l'API di sistema StatsManager e IncidentManager.

Implementazioni del dispositivo:

[C-0-2] DEVONO includere solo i campi contrassegnati con DEST_AUTOMATIC nella segnalazione di un problema creata dalla classe API di sistema IncidentManager.
[C-0-3] NON DEVE utilizzare gli identificatori di eventi di sistema per registrare eventi diversi da quelli descritti nei documenti dell'SDK StatsLog. Se vengono registrati eventi di sistema aggiuntivi, questi POTREBBERO utilizzare un identificatore atomo diverso nell'intervallo compreso tra 100.000 e 200.000.

9.8.2. Registrazione

Implementazioni del dispositivo:

[C-0-1] NON DEVE precaricare o distribuire componenti software out-of-box che inviano informazioni private dell'utente (ad es. sequenze di tasti, testo visualizzato sullo schermo, report bug) dal dispositivo senza il consenso dell'utente o senza notifiche chiare e continue.
[C-0-2] DEVE mostrare un avviso all'utente e ottenere il consenso dell'utente esplicito per consentire l'acquisizione di qualsiasi informazione sensibile visualizzata sullo schermo dell'utente ogni volta che viene attivata una sessione per acquisire la trasmissione dello schermo o la registrazione dello schermo tramite MediaProjection.createVirtualDisplay() o API proprietarie.
[C-0-3] DEVE avere una notifica continua per l'utente mentre la trasmissione dello schermo o la registrazione dello schermo è attiva. AOSP soddisfa questo requisito mostrando un'icona di notifica continua nella barra di stato.
[C-SR-1] È FORTEMENTE CONSIGLIATO visualizzare un avviso per l'utente che sia esattamente lo stesso messaggio implementato in AOSP, ma PUÒ essere modificato a condizione che il messaggio avvisi chiaramente l'utente che vengono acquisite eventuali informazioni sensibili sullo schermo dell'utente.
[C-0-4] Requisito rimosso in Android 16.

Implementazioni del dispositivo:

[C-0-7] NON DEVE registrare, proiettare o trasmettere informazioni sensibili, ad esempio:
- Contenuti sensibili delle notifiche elencati nella sezione 3.8.3.4 Protezione delle notifiche sensibili
- Finestre di attività delle app contenenti password monouso
- Contenuti sensibili come nome utente, password e informazioni della carta di credito

Se le implementazioni del dispositivo includono funzionalità nel sistema che acquiscono i contenuti visualizzati sullo schermo e/o registrano lo stream audio riprodotto sul dispositivo in modo diverso dall'API di sistema ContentCaptureService o altri mezzi proprietari descritti nella Sezione 9.8.6 Dati a livello di sistema operativo e ambientali, devono:

[C-1-1] DEVE mostrare una notifica continua all'utente ogni volta che questa funzionalità è attiva e acquisisce/registra attivamente.

Se le implementazioni del dispositivo includono un componente abilitato out-of-box, in grado di registrare l'audio ambientale e/o registrare l'audio riprodotto sul dispositivo per dedurre informazioni utili sul contesto dell'utente, devono:

[C-2-1] NON DEVE archiviare in modo permanente nella memoria del dispositivo o trasmettere al di fuori del dispositivo l'audio grezzo registrato o qualsiasi formato che possa essere riconvertito nell'audio originale o in una copia quasi identica, se non con il consenso esplicito dell'utente.

Un "indicatore del microfono" si riferisce a una visualizzazione sullo schermo, costantemente visibile all'utente e non oscurabile, che gli utenti interpretano come un microfono in uso(tramite testo, colore, icona o una combinazione unici).

Un "indicatore fotocamera" si riferisce a una visualizzazione sullo schermo, costantemente visibile all'utente e non oscurabile, che gli utenti interpretano come una fotocamera in uso (tramite testo, colore, icona o una combinazione unici).

Dopo il primo secondo visualizzato, un indicatore può cambiare visivamente, ad esempio diventare più piccolo, e non è necessario che venga visualizzato come originariamente presentato e compreso.

L'indicatore del microfono può essere unito a un indicatore della videocamera visualizzato attivamente, a condizione che testo, icone o colori indichino all'utente che l'uso del microfono è iniziato.

L'indicatore fotocamera può essere unito a un indicatore del microfono visualizzato attivamente, a condizione che testo, icone o colori indichino all'utente che l'utilizzo della fotocamera è iniziato.

Se le implementazioni dei dispositivi dichiarano android.hardware.microphone:

[C-SR-1] Sono FORTEMENTE CONSIGLIATI per mostrare l'indicatore del microfono quando un'app accede ai dati audio dal microfono, ma non quando il microfono viene utilizzato solo da HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o dalle app che ricoprono i ruoli indicati nella sezione 9.1 Autorizzazioni con identificatore CDD [C-3-X].
[C-SR-2] È FORTEMENTE CONSIGLIATO visualizzare l'elenco delle app recenti e attive che utilizzano il microfono restituito da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.
[C-SR-3] È FORTEMENTE CONSIGLIATO di non nascondere l'indicatore del microfono per le app di sistema che hanno interfacce utente visibili o interazione diretta con l'utente.

Se le implementazioni dei dispositivi dichiarano android.hardware.camera.any:

[C-SR-4] Sono FORTEMENTE CONSIGLIATI per mostrare l'indicatore fotocamera quando un'app accede ai dati della fotocamera in tempo reale, ma non quando la fotocamera viene utilizzata solo da app che detengono i ruoli indicati nella sezione 9.1 Autorizzazioni con identificatore CDD [C-3-X].
[C-SR-5] È FORTEMENTE CONSIGLIATO di mostrare le app recenti e attive che utilizzano la videocamera come restituita da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.
[C-SR-6] È FORTEMENTE CONSIGLIATO di non nascondere l'indicatore fotocamera per le app di sistema che hanno interfacce utente visibili o interazione utente.

9.8.3. Connettività

Se le implementazioni dei dispositivi hanno una porta USB con supporto della modalità periferica USB, devono:

[C-1-1] DEVE presentare un'interfaccia utente che chieda 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 del dispositivo:

[C-0-1] DEVE preinstallare gli stessi certificati radice per l'archivio dell'autorità di certificazione (CA) attendibile dal sistema forniti nel progetto Android Open Source upstream.
[C-0-2] MUST ship with an empty user root CA store.
[C-0-3] DEVE mostrare un avviso all'utente che indica che il traffico di rete potrebbe essere monitorato, quando viene aggiunta una CA radice utente.

Se il traffico del dispositivo viene indirizzato tramite una VPN, le implementazioni del dispositivo:

[C-1-1] DEVE mostrare all'utente un avviso 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 hanno un meccanismo, attivato 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), allora:

[C-2-1] DEVE chiedere il consenso dell'utente prima di attivare questo meccanismo, a meno che la VPN non sia attivata dal controller di policy dei dispositivi tramite DevicePolicyManager.setAlwaysOnVpnPackage(), nel qual caso l'utente non deve fornire un consenso separato, ma DEVE solo ricevere una notifica.

Se le implementazioni del dispositivo implementano una funzionalità utente per attivare/disattivare la funzione "VPN sempre attiva" di un'app VPN di terze parti, queste:

[C-3-1] DEVE disattivare questa funzionalità 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.8.5. Identificatori dei dispositivi

Implementazioni del dispositivo:

[C-0-1] DEVE impedire l'accesso al numero di serie del dispositivo e, se applicabile, al codice IMEI/MEID, al numero di serie della SIM e all'International Mobile Subscriber Identity (IMSI) da un'app, a meno che non soddisfi uno dei seguenti requisiti:
- è un'app dell'operatore firmata e verificata dai produttori di dispositivi.
- è stata concessa l'autorizzazione READ_PRIVILEGED_PHONE_STATE.
- dispone dei privilegi dell'operatore come definiti in UICC Carrier Privileges.
- è un proprietario del dispositivo o del profilo a cui è stata concessa l'autorizzazione READ_PHONE_STATE.
- (Solo per il numero di serie della SIM/ICCID) ha il requisito delle normative locali che l'app rilevi le modifiche all'identità dell'abbonato.

9.8.6. Protezione a livello di sistema operativo e dati ambientali

Android, tramite le API di sistema, supporta un meccanismo per le implementazioni dei dispositivi per acquisire i seguenti dati sensibili:

Testo e grafica visualizzati sullo schermo, inclusi, a titolo esemplificativo, notifiche e dati di assistenza tramite AssistStructure API, attività di acquisizione del buffer dello schermo e registrazione dei contenuti dello schermo di un dispositivo.

Dati multimediali, come audio o video, registrati o riprodotti dal dispositivo.
Eventi di input (ad es. tastiera, mouse, gesti, voce, video e accessibilità).
Qualsiasi schermata o altro dato inviato tramite AugmentedAutofillService al sistema.
Qualsiasi schermata o altri dati accessibili tramite Content Capture API.
Qualsiasi dato dell'applicazione passato al sistema tramite l'API AppSearchManager e accessibile tramite AppSearchGlobalManager.query.
Qualsiasi testo o altro dato inviato tramite TextClassifier API al classificatore di testo di sistema, ovvero al servizio di sistema per comprendere il significato del testo, nonché per generare le azioni successive previste in base al testo.
Dati indicizzati dall'implementazione della piattaforma AppSearch, inclusi, a titolo esemplificativo, testo, grafica, dati multimediali o altri dati simili.
Dati audio ottenuti a seguito dell'utilizzo di SpeechRecognizer#onDeviceSpeechRecognizer() dall'implementazione del sistema di riconoscimento vocale.
Dati audio ottenuti in background (in modo continuo) tramite AudioRecord, SoundTrigger o altre API audio e che non comportano un indicatore visibile all'utente
Dati della fotocamera ottenuti in background (in modo continuo) tramite CameraManager o altre API della fotocamera e che non comportano un indicatore visibile all'utente

Tutti i dati acquisiti da DynamicInstrumentationEventService

Se le implementazioni del dispositivo acquisiscono o condividono uno qualsiasi dei dati sensibili sopra indicati,:senza un intento dell'utente chiaro e discreto o un indicatore della privacy visibile all'utente, i dati DEVONO essere elaborati in un ambiente di esecuzione protetto. Questo ambiente:

[C-1-1] DEVE criptare tutti questi dati quando vengono memorizzati nel dispositivo o in transito. Questa crittografia PUÒ essere eseguita utilizzando la crittografia basata su file di Android o uno qualsiasi dei cifrari elencati come versione API 26+ descritti in Cipher SDK.
[C-1-2] NON DEVE eseguire il backup di dati non elaborati o criptati utilizzando metodi di backup di Android o altri metodi di backup dati sensibili, come descritto sopra.

[C-1-3] NON DEVE inviare questi dati dal dispositivo, tranne in una delle seguenti condizioni:
- Quando viene avviata esplicitamente dall'intento dell'utente ^* per il calcolo specifico ogni volta che i dati vengono condivisi.
- Quando utilizzi un meccanismo che tutela la privacy, ad esempio tecnologie di privacy differenziale come RAPPOR o calcoli federati confidenziali.
- Quando i dati vengono elaborati in un ambiente di esecuzione protetto che li protegge dal fornitore di servizi e dall'infrastruttura, ad esempio nessun accesso amministrativo, VM confidenziale, attestazione remota, nessuna uscita di dati privati, logging disattivato, offuscamento dell'IP e crittografia.
  - Qualsiasi implementazione che utilizzi questo metodo deve fornire agli utenti la possibilità di disattivare la funzionalità.

[C-1-3] PUÒ trattare i dati tramite un ambiente cloud di base di calcolo attendibile che li protegge dal fornitore di servizi e dall'infrastruttura (ad es. nessun accesso amministratore, VM confidenziale, attestazione remota, nessuna uscita di dati privati, logging disattivato, offuscamento dell'IP e crittografia). Qualsiasi implementazione che utilizza questo metodo:
- DEVE fornire agli utenti la possibilità di disattivare la funzionalità e
- DEVE fornire agli utenti un metodo per generare log accessibili e completi che descrivano in dettaglio l'ingresso e l'uscita dei dati dall'ambiente.

[C-1-4] NON DEVE associare questi dati a un'identità utente (ad esempio Account) sul dispositivo, tranne con il consenso esplicito dell'utente ogni volta che i dati vengono associati.

[C-1-4] POTREBBE mostrare questi dati sulle piattaforme dell'interfaccia utente di proprietà del sistema.

[C-1-5] NON DEVE condividere associare questi dati a qualsiasi identità utente (ad esempio Account), tranne con il consenso dell'utente esplicito ogni volta che vengono condivisi, ogni volta che i dati vengono associati, altrimenti l'associazione non verrà trasferita ad altri componenti del sistema operativo che non rispettano i requisiti descritti nella sezione attuale (9.8.6 Dati a livello di sistema operativo e ambientali), ogni volta che vengono condivisi. a meno che tale funzionalità non sia integrata come API SDK Android (AmbientContext, HotwordDetectionService).
[C-1-6] DEVE fornire all'utente la possibilità di cancellare i dati che l'implementazione o i mezzi proprietari raccolgono quando i dati vengono memorizzati in qualsiasi forma sul dispositivo o nell'ambiente cloud della base di calcolo attendibile. Se l'utente sceglie di cancellare i dati, TUTTI i dati storici raccolti DEVONO essere rimossi.

[C-1-7] DEVE fornire un'opzione per disattivare la visualizzazione dei dati raccolti tramite AppSearch o mezzi proprietari nella piattaforma Android (ad es. il launcher).

[C-1-8] DEVE fornire un metodo per generare log accessibili e completi che descrivano in dettaglio l'ingresso e l'uscita dei dati dall'ambiente.
[C-1-9] NON DEVE avere accesso diretto a internet.
[C-1-10] PUÒ mostrare l'UI da remoto, a condizione che nessun dato venga reso visibile all'APK host che mostra l'UI.
[C-1-11] DEVE mantenere i servizi separati dagli altri componenti del sistema (ad es. non collegare il servizio o condividere gli ID processo con implementazioni non presenti nell'ambiente di esecuzione protetto).
[C-1-12] MUST only allow sensitive data to exit when:
- Avviata esplicitamente dall'intento dell'utente* per il calcolo specifico ogni volta che i dati vengono condivisi; OPPURE
- Utilizzo di un meccanismo che tutela la privacy (ad es. tecnologie di privacy differenziale come RAPPOR / calcoli federati riservati).
[C-1-13] DEVE consentire l'esfiltrazione di dati sensibili solo tramite:
- Un servizio di sistema incluso nella lista consentita del servizio di sistema PCCSandbox E che rispetta i requisiti per un ambiente di esecuzione protetto (9.8.6), OPPURE
- Un APK gateway Private Compute Core (PCC) designato (definito in 9.8.15).
[C-1-14] NON DEVE eseguire backup sul cloud di dati dedotti da dati sensibili, a meno che non siano criptati end-to-end (ad es. utilizzando Android Backup Service).

[C-SR-1] È FORTEMENTE CONSIGLIATO di NON richiedere l'autorizzazione INTERNET.
[C-SR-2] È FORTEMENTE CONSIGLIATO di accedere a internet solo tramite API strutturate supportate da implementazioni open source disponibili pubblicamente.
[C-SR-4] È VIVAMENTE CONSIGLIATO di implementare l'API SDK Android o un repository open source simile di proprietà dell'OEM e / o di eseguire l'implementazione in un ambiente protetto (vedi 9.8.15 Implementazioni API protette).

Se le implementazioni del dispositivo includono un servizio che implementa l'API di sistema ContentCaptureService, AppSearchManager.index, DynamicInstrumentationEventService, o qualsiasi servizio proprietario che acquisisce i dati come descritto sopra, devono:

[C-2-1] NON DEVE consentire agli utenti di sostituire i servizi con un'applicazione o un servizio installabile dall'utente e DEVE consentire solo ai servizi preinstallati di acquisire tali dati.
[C-2-2] NON DEVE consentire ad app diverse dal meccanismo dei servizi preinstallati di acquisire questi dati.
[C-2-3] DEVE fornire un'interfaccia utente chiara e accessibile per disattivare i servizi.
[C-2-4] NON DEVE omettere la funzionalità per la gestione delle autorizzazioni Android detenute dai servizi e deve seguire il modello di autorizzazioni Android descritto nella Sezione 9.1. Autorizzazione.
[C-SR-3] Sono FORTEMENTE CONSIGLIATI per mantenere i servizi separati dagli altri componenti di sistema (ad es. non vincolare il servizio o condividere gli ID processo) ad eccezione di quanto segue:
- Telefonia, Contatti, UI di sistema e contenuti multimediali

9.8.7. Accesso agli appunti

Implementazioni del dispositivo:

[C-0-1] NON DEVE restituire dati tagliati dagli appunti (ad es. tramite l'API ClipboardManager) a meno che l'app di terze parti non sia l'IME predefinito o l'app attualmente selezionata.
[C-0-2] DEVE cancellare i dati degli appunti al massimo 60 minuti dopo l'ultima volta che sono stati inseriti o letti.

9.8.8. Località

La posizione include informazioni nella classe Android Location( come latitudine, longitudine, altitudine), nonché identificatori che possono essere convertiti in posizione. La posizione può essere precisa come il DGPS (Differential Global Positioning System) o approssimativa come le posizioni a livello di paese (ad esempio il codice paese - MCC - Mobile Country Code).

Di seguito è riportato un elenco di tipi di località che derivano direttamente dalla posizione di un utente o che possono essere convertiti nella posizione di un utente. Questo non è un elenco esaustivo, ma deve essere utilizzato come esempio di ciò da cui la posizione può essere derivata direttamente o indirettamente:

GPS/GNSS/DGPS/PPP
- Soluzione di posizionamento globale o sistema satellitare di navigazione globale o soluzione di posizionamento globale differenziale
- Sono inclusi anche Raw GNSS Measurements e GNSS Status
  - La posizione esatta può essere derivata dalle misurazioni GNSS non elaborate
Tecnologie wireless con identificatori univoci, ad esempio:
- Punti di accesso Wi-Fi (MAC, BSSID, nome o SSID)
- Bluetooth/BLE (MAC, BSSID, nome o SSID)
- UWB (MAC, BSSID, nome o SSID)
- ID torre cellulare (3G, 4G, 5G e così via, incluse tutte le future tecnologie di modem cellulare che hanno identificatori unici)

Come punto di riferimento principale, consulta le API Android che richiedono le autorizzazioni ACCESS_FINE_Location o ACCESS_COARSE_Location.

Implementazioni del dispositivo:

[C-0-1] NON DEVE attivare/disattivare l'impostazione della posizione del dispositivo e le impostazioni di scansione Wi-Fi/Bluetooth senza il consenso esplicito dell'utente o l'avvio da parte dell'utente.
[C-0-2] DEVE fornire all'utente la possibilità di accedere alle informazioni relative alla posizione, incluse le richieste di posizione recenti, le autorizzazioni a livello di app e l'utilizzo della scansione Wi-Fi/Bluetooth per determinare la posizione.
[C-0-3] DEVE garantire che l'applicazione che utilizza l'API Emergency Location Bypass LocationRequest.setLocationSettingsIgnored() sia una sessione di emergenza avviata dall'utente (ad es. chiamata al 911 o invio di un messaggio al 911). Per Automotive, invece, un veicolo PUÒ avviare una sessione di emergenza senza interazione utente attiva nel caso in cui venga rilevato un incidente (ad esempio per soddisfare i requisiti di eCall).
[C-0-4] DEVE preservare la capacità delle API di bypass della posizione di emergenza di bypassare le impostazioni di localizzazione del dispositivo senza modificarle.
[C-0-5] DEVE pianificare una notifica che ricordi all'utente che un'app in background ha avuto accesso alla sua posizione utilizzando l'autorizzazione ACCESS_BACKGROUND_LOCATION.

Quando un'app non di sistema in primo piano accede alla posizione esatta di un dispositivo, il dispositivo:

[C-SR-1] VIVAMENTE CONSIGLIATO di mostrare un indicatore visibile all'utente

9.8.9. App installate

Le app per Android che hanno come target il livello API 30 o versioni successive non possono visualizzare i dettagli di altre app installate per impostazione predefinita (vedi Visibilità dei pacchetti nella documentazione dell'SDK Android).

Implementazioni del dispositivo:

[C-0-1] NON DEVE esporre a nessuna app che ha come target il livello API 30 o superiore dettagli su qualsiasi altra app installata, a meno che l'app non sia già in grado di visualizzare i dettagli sull'altra app installata tramite le API gestite. Sono inclusi, a titolo esemplificativo, i dettagli esposti da qualsiasi API personalizzata aggiunta dall'implementatore del dispositivo o accessibile tramite il file system.
[C-0-2] NON DEVE concedere a nessuna app l'accesso in lettura o scrittura ai file in qualsiasi altra directory dedicata e specifica dell'app all'interno dell'archivio esterno. Le uniche eccezioni sono le seguenti:
- L'autorità del fornitore di spazio di archiviazione esterno (ad es. app come DocumentsUI).
- Download Provider, che utilizza l'autorità del provider "downloads" per scaricare i file nello spazio di archiviazione dell'app.
- App con protocollo di trasferimento multimediale (MTP) firmato dalla piattaforma che utilizzano l'autorizzazione con privilegi ACCESS_MTP per consentire il trasferimento di file a un altro dispositivo.
- Le app che installano altre app e dispongono dell'autorizzazione INSTALL_PACKAGES possono accedere solo alle directory "obb" allo scopo di gestire i file di espansione APK.

9.8.10. Segnalazione di bug relativi alla connettività

Se le implementazioni dei dispositivi dichiarano il flag di funzionalità android.hardware.telephony, devono:

[C-1-1] DEVE supportare la generazione di segnalazioni di bug di connettività tramite BUGREPORT_MODE_TELEPHONY con BugreportManager.
[C-1-2] DEVE ottenere il consenso dell'utente ogni volta che BUGREPORT_MODE_TELEPHONY viene utilizzato per generare un report e NON DEVE chiedere all'utente di acconsentire a tutte le richieste future dell'applicazione.
[C-1-3] NON DEVE restituire il report generato all'app richiedente senza il consenso esplicito dell'utente.
[C-1-4] I report generati utilizzando BUGREPORT_MODE_TELEPHONY DEVONO contenere almeno le seguenti informazioni:
- TelephonyDebugService dump
- TelephonyRegistry dump
- WifiService dump
- ConnectivityService dump
- Un dump dell'istanza CarrierService del pacchetto chiamante (se associata)
- Buffer log del segnale radio
- SubscriptionManagerService dump
[C-1-5] NON DEVE includere quanto segue nei report generati:
- Qualsiasi tipo di informazione non direttamente correlata al debug della connettività.
- Log del traffico o profili dettagliati di applicazioni/pacchetti installati dall'utente (gli UID sono accettabili, i nomi dei pacchetti no).
POSSONO includere informazioni aggiuntive non associate ad alcuna identità utente. (ad es. log del fornitore).

Se le implementazioni dei dispositivi includono informazioni aggiuntive (ad es. log del fornitore) nelle segnalazioni di bug e queste informazioni hanno un impatto su privacy/sicurezza/batteria/spazio di archiviazione/memoria, queste:

[C-SR-1] È FORTEMENTE CONSIGLIATO che un'impostazione sviluppatore sia disattivata per impostazione predefinita. L'implementazione di riferimento AOSP soddisfa questo requisito fornendo l'opzione Enable verbose vendor logging nelle impostazioni sviluppatore per includere log fornitori aggiuntivi specifici del dispositivo nelle segnalazioni di bug.

9.8.11. Condivisione dei blob di dati

Android, tramite BlobStoreManager consente alle app di contribuire con blob di dati al sistema da condividere con un insieme selezionato di app.

Se le implementazioni dei dispositivi supportano i blob di dati condivisi come descritto nella documentazione dell'SDK, questi:

[C-1-1] NON DEVE condividere i blob di dati appartenenti alle app oltre a quanto intendevano consentire (ovvero l'ambito di accesso predefinito e le altre modalità di accesso che possono essere specificate utilizzando BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess(), o BlobStoreManager.session#allowPublicAccess() NON DEVE essere modificato). L'implementazione di riferimento AOSP soddisfa questi requisiti.
[C-1-2] NON DEVE inviare al di fuori del dispositivo o condividere con altre app gli hash sicuri dei blob di dati (che vengono utilizzati per controllare l'accesso).

9.8.12. Riconoscimento della musica

Android, tramite l'API di sistema MusicRecognitionManager, supporta un meccanismo per le implementazioni dei dispositivi per richiedere il riconoscimento musicale, dato un record audio, e delegare il riconoscimento musicale a un'app privilegiata che implementa l'API MusicRecognitionService.

Se le implementazioni del dispositivo includono un servizio che implementa l'API di sistema MusicRecognitionManager o qualsiasi servizio proprietario che trasmette dati audio in streaming come descritto sopra, essi:

[C-1-1] DEVE garantire che il chiamante di MusicRecognitionManager disponga dell'autorizzazione MANAGE_MUSIC_RECOGNITION
[C-1-2] DEVE garantire che una singola applicazione di riconoscimento musicale preinstallata implementi MusicRecognitionService.
[C-1-3] NON DEVE consentire agli utenti di sostituire MusicRecognitionManagerService o MusicRecognitionService con un'applicazione o un servizio installabile dall'utente.
[C-1-4] DEVE garantire che quando MusicRecognitionManagerService accede alla registrazione audio e la inoltra all'applicazione che implementa MusicRecognitionService, l'accesso all'audio venga monitorato tramite le chiamate di AppOpsManager.noteOp / startOp.

Se le implementazioni del dispositivo di MusicRecognitionManagerService o MusicRecognitionService memorizzano i dati audio acquisiti:

[C-2-1] NON DEVE archiviare alcun audio grezzo o impronta audio su disco, o in memoria per più di 14 giorni.
[C-2-2] NON DEVE condividere questi dati al di fuori di MusicRecognitionService, se non con il consenso esplicito dell'utente ogni volta che vengono condivisi.

9.8.13. SensorPrivacyManager

Se le implementazioni del dispositivo forniscono all'utente un'opzione software per disattivare l'input della videocamera e/o del microfono per l'implementazione del dispositivo, queste:

[C-1-1] DEVE restituire con precisione "true" per il metodo API supportsSensorToggle() pertinente.
[C-1-2] DEVE, quando un'app tenta di accedere a un microfono o a una videocamera bloccati, presentare all'utente un'interfaccia utente non chiudibile che indichi chiaramente che il sensore è bloccato e richiede una scelta per continuare a bloccarlo o sbloccarlo in base all'implementazione AOSP che soddisfa questo requisito.
[C-1-3] DEVE trasmettere alle app solo dati audio e della videocamera vuoti (o falsi) e non segnalare un codice di errore perché l'utente non ha attivato la videocamera né il microfono tramite la funzionalità presentata in [C-1-2] sopra.

9.8.14. N/D

9.8.15. Implementazioni di Private Compute Core e dell'applicazione gateway

Android, tramite un insieme di API delegate, fornisce un meccanismo per elaborare dati sicuri a livello di sistema operativo e ambientali. L'elaborazione può essere delegata a un APK preinstallato con accesso privilegiato e funzionalità di comunicazione ridotte, noto come implementazione dell'API Sandbox.

Le implementazioni di dispositivi che includono applicazioni che eseguono l'elaborazione sul dispositivo di dati sensibili descritti nella sezione 9.8.6 (dati a livello di sistema operativo e ambientali) sono FORTEMENTE CONSIGLIATE di utilizzare il framework Private Compute Core (PCC) descritto di seguito.

Qualsiasi componente di implementazione dell'API Sandbox nell'ambiente PCC:

[C-0-1] NON DEVE richiedere l'autorizzazione INTERNET.

[C-0-1] DEVE essere dichiarato con un attributo android:isPrivateComputeCoreProcess="true" nella dichiarazione del manifest.

[C-0-2] DEVE accedere a internet solo tramite API strutturate supportate da implementazioni open source disponibili pubblicamente utilizzando meccanismi che tutelano la privacy o indirettamente tramite le API SDK Android. Il meccanismo che tutela la privacy è definito come "quello che consente solo l'analisi aggregata e impedisce la corrispondenza degli eventi registrati o dei risultati derivati con i singoli utenti", per impedire che i dati utente siano ispezionabili (ad es. implementati utilizzando una tecnologia di privacy differenziale come RAPPOR).

[C-0-2] DEVE essere precaricata sull'immagine di sistema del dispositivo.

[C-0-3] I servizi DEVONO essere tenuti separati dagli altri componenti del sistema (ad es. non eseguire il binding del servizio o condividere gli ID processo ad eccezione di quanto segue:
- Telefonia, Contatti, UI di sistema e contenuti multimediali con implementazioni non eseguite come UID PCC).
[C-0-4] NON DEVE consentire agli utenti di sostituire i servizi con un'applicazione o un servizio installabile dall'utente
[C-0-5] DEVE consentire solo ai servizi preinstallati nominati dall'OEM (con un ruolo di sistema appropriato definito nel servizio di sistema PCC Manager) e con le autorizzazioni appropriate, di acquisire questi dati. A meno che la funzionalità di sostituzione non sia integrata in AOSP (ad es. per le app assistente digitale) dati ambientali sensibili come descritto in 9.8.6.
[C-0-6] NON DEVE consentire ad app diverse dal meccanismo dei servizi preinstallati di acquisire questi dati. a meno che tale funzionalità di acquisizione non sia implementata con un'API SDK Android.
[C-0-7] DEVE fornire all'utente la possibilità di disattivare i servizi.
[C-0-8] NON DEVE omettere la possibilità per l'utente di gestire le autorizzazioni Android detenute dai servizi e seguire il modello di autorizzazioni Android descritto nella Sezione 9.1. Autorizzazione.

[C-0-9] DEVE essere eseguito in un processo dedicato con un UID univoco assegnato dal framework, separato dal processo dell'applicazione principale e da altri componenti in sandbox.

Qualsiasi accesso alla rete richiesto dai componenti dell'ambiente PCC DEVE essere eseguito tramite proxy tramite un APK designato che funge da applicazione gateway PCC. I componenti designati:

[C-1-1] DEVE essere concessa l'autorizzazione con privilegi android.permission.PROVIDE_PRIVATE_COMPUTE_SERVICES. Questa autorizzazione designa l'applicazione come applicazione gateway PCC.
[C-1-2] DEVE rendere disponibile il proprio codice sorgente per la verifica pubblica.
[C-1-3] DEVE utilizzare meccanismi che tutelano la privacy per qualsiasi uscita dei dati, come definito nella sezione 9.8.6
[C-1-4] DEVE supportare la modalità di controllo del framework PCC, che include la registrazione delle richieste di rete, degli endpoint del server e di altri dati pertinenti per la verifica del comportamento che tutela la privacy quando è attivata

9.8.16. Dati audio e della videocamera continui

Se le implementazioni del dispositivo acquisiscono uno qualsiasi dei dati descritti nella sezione 9.8.2 o nella sezione 9.8.6 e se tali implementazioni utilizzano dati audio ottenuti in background (in modo continuo) tramite AudioRecord, SoundTrigger o altre API audio OPPURE dati della videocamera ottenuti in background (in modo continuo) tramite CameraManager o altre API della videocamera, queste:

[C-0-1] DEVE applicare un indicatore corrispondente (fotocamera e/o microfono come da sezione 9.8.2 Registrazione), a meno che:
- Questo accesso viene eseguito in un'implementazione con sandbox (vedi 9.8.15 Implementazione dell'API con sandbox), tramite un pacchetto che contiene uno o più dei seguenti ruoli: UI di sistema Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, o System Visual Intelligence.
- L'accesso viene eseguito tramite una sandbox, implementata e applicata tramite meccanismi in AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).
- L'accesso all'audio viene eseguito a scopo assistivo dall'applicazione assistente digitale, che fornisce SOURCE_HOTWORD come sorgente audio.
- L'accesso viene eseguito dal sistema e implementato con codice open source.
[C-SR-1] È FORTEMENTE CONSIGLIATO richiedere il consenso dell'utente per ogni funzionalità che utilizza questi dati e disabilitarla per impostazione predefinita.
[C-SR-2] FORTEMENTE CONSIGLIATO di applicare lo stesso trattamento (ovvero seguire le limitazioni descritte in 9.8.2 Registrazione, 9.8.6 Dati a livello di sistema operativo e ambientali, 9.8.15 Implementazioni API in sandbox e 9.8.16 Dati audio e della videocamera continui) ai dati della videocamera provenienti da un dispositivo indossabile remoto.

Se le implementazioni dei dispositivi ricevono dati della videocamera o del microfono da un dispositivo indossabile remoto e i dati vengono accessibili in forma non criptata al di fuori del sistema operativo Android, dell'implementazione in sandbox o di una funzionalità in sandbox creata da WearableSensingManager, queste:

[C-1-1] DEVE indicare al dispositivo indossabile remoto di visualizzare un indicatore aggiuntivo.

Se i dispositivi offrono la possibilità di interagire con un'applicazione di assistente digitale senza la parola chiave assegnata (gestendo query generiche degli utenti o analizzando la presenza dell'utente tramite la videocamera), devono:

[C-2-1] DEVE garantire che l'implementazione sia fornita da un pacchetto con il ruolo android.app.role.ASSISTANT.
[C-2-2] DEVE assicurarsi che l'implementazione utilizzi le API Android HotwordDetectionService e/o VisualQueryDetectionService.

9.8.17. Telemetria

Android archivia i log di sistema e delle app utilizzando le API StatsLog. Questi log vengono gestiti tramite le API StatsManager, che possono essere utilizzate dalle applicazioni di sistema privilegiate.

StatsManager fornisce anche un modo per raccogliere dati classificati come sensibili per la privacy dai dispositivi con un meccanismo di protezione della privacy. In particolare, l'API StatsManager::query consente di eseguire query sulle categorie di metriche con limitazioni definite in StatsLog.

Qualsiasi implementazione che esegue query e raccoglie metriche con limitazioni da StatsManager:

[C-0-1] DEVE essere l'unica applicazione/implementazione sul dispositivo e disporre dell'autorizzazione READ_RESTRICTED_STATS.
[C-0-2] DEVE inviare solo i dati di telemetria e il log del dispositivo utilizzando un meccanismo che tutela la privacy. Il meccanismo che tutela la privacy è definito come "quello che consente solo l'analisi aggregata e impedisce la corrispondenza di eventi registrati o risultati derivati con i singoli utenti", per impedire che i dati per utente siano ispezionabili (ad es. implementati utilizzando una tecnologia di privacy differenziale come RAPPOR).
[C-0-3] NON DEVE associare questi dati a nessuna identità utente (ad esempio Account) sul dispositivo.
[C-0-4] NON DEVE condividere questi dati con altri componenti del sistema operativo che non rispettano i requisiti descritti nella sezione corrente (9.8.17. Telemetria).
[C-0-5] DEVE fornire un'interfaccia utente per attivare/disattivare la raccolta, l'utilizzo e la condivisione della telemetria che tutela la privacy.
[C-0-6] DEVE fornire all'utente la possibilità di cancellare i dati raccolti dall'implementazione se sono archiviati in qualsiasi forma sul dispositivo. Se l'utente ha scelto di cancellare i dati, DEVE rimuovere tutti i dati attualmente memorizzati sul dispositivo.
[C-0-7] DEVE divulgare l'implementazione del protocollo sottostante che tutela la privacy in un repository open source.
[C-0-8] DEVE applicare i criteri di uscita dei dati in questa sezione per controllare la raccolta dei dati nelle categorie di metriche con limitazioni definite in StatsLog.

9.8.18. Privacy delle funzioni agentiche

Implementazioni del dispositivo:

[C-0-1] DEVE garantire che tutti i componenti che eseguono AppFunctions dispongano dell'autorizzazione EXECUTE_APP_FUNCTIONS o EXECUTE_APP_FUNCTIONS_SYSTEM.
[C-0-2] DEVE richiamare una chiamata AppFunction solo come risultato diretto di un'azione esplicita dell'utente e questo DEVE indicare chiaramente all'utente sia l'applicazione richiamata sia l'azione principale da eseguire all'interno di quell'applicazione.
[C-0-3] NON DEVE fungere da proxy o modificare la richiesta di un'app di terze parti per rilevare o eseguire AppFunctions, a meno che non siano soddisfatti i requisiti [C-0-1] e [C-0-2].
[C-0-4] NON DEVE consentire l'utilizzo di dati sensibili a livello di sistema operativo o ambientali (come definiti in 9.8.6 Protezioni a livello di sistema operativo e ambientali) o dei relativi derivati da parte dei componenti di sistema per generare o parametrizzare i nudge, a meno che i componenti di sistema non operino in un ambiente di esecuzione protetto, come definito in 9.8.6.

Termine chiave: "Sollecito" è definito come un punto di accesso generato in modo proattivo a un'app da una superficie di sistema avviata senza un'azione utente precedente diretta. I nudge suggeriscono o guidano un utente verso un'azione senza limitare la libertà di scelta.

9.9. Crittografia dell'archiviazione dei dati

Tutti i dispositivi DEVONO soddisfare i requisiti della sezione 9.9.1. I dispositivi lanciati con un livello API precedente a quello di questo documento sono esenti dai requisiti delle sezioni 9.9.2 e 9.9.3; devono invece soddisfare i requisiti della sezione 9.9 del documento Android Compatibility Definition corrispondente al livello API con cui è stato lanciato il dispositivo.

9.9.1. Avvio diretto

Implementazioni del dispositivo:

[C-0-1] DEVE implementare le API della modalità Avvio diretto anche se non supportano la crittografia dell'archiviazione.
[C-0-2] Gli intent ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED DEVONO comunque essere trasmessi per segnalare alle applicazioni compatibili con l'avvio diretto che le posizioni di archiviazione con crittografia dispositivo (DE) e crittografia delle credenziali (CE) sono disponibili per l'utente.

9.9.2. Requisiti di crittografia

Implementazioni del dispositivo:

[C-0-1] DEVE criptare i dati privati dell'applicazione (partizione /data), nonché la partizione di archiviazione condivisa dell'applicazione (partizione /sdcard) se è una parte permanente e non rimovibile del dispositivo.
[C-0-2] DEVE abilitare la crittografia dell'archiviazione dei dati per impostazione predefinita al momento in cui l'utente ha completato l'esperienza di configurazione predefinita.
[C-0-3] DEVE soddisfare il requisito di crittografia dell'archiviazione dei dati sopra indicato implementando uno dei due metodi di crittografia seguenti:
- Crittografia basata su file (FBE) e crittografia dei metadati come descritto nella sezione 9.9.3.1.
- Crittografia a livello di blocco per utente, come descritto nella sezione 9.9.3.2.

9.9.3. Metodi di crittografia

Se le implementazioni dei dispositivi sono criptate:

[C-1-1] DEVE avviarsi senza richiedere le credenziali all'utente e consentire alle app compatibili con l'avvio diretto di accedere allo spazio di archiviazione con crittografia del dispositivo (DE) dopo la trasmissione del messaggio ACTION_LOCKED_BOOT_COMPLETED.
[C-1-2] NON DEVE consentire l'accesso all'archivio Credential Encrypted (CE) finché non si verificano entrambe le condizioni seguenti:
- L'utente sblocca il dispositivo utilizzando un metodo di autenticazione principale (come password, sequenza o PIN).
- Il messaggio ACTION_USER_UNLOCKED viene trasmesso.
[C-1-13] NON DEVE offrire alcun metodo per sbloccare lo spazio di archiviazione protetto da CE senza le credenziali fornite dall'utente, una chiave di deposito a garanzia registrata o un'implementazione di ripristino al riavvio che soddisfi i requisiti della sezione 9.9.4.
[C-1-4] DEVE utilizzare l'avvio verificato.

9.9.3.1. Crittografia basata su file con crittografia dei metadati

Se le implementazioni dei dispositivi utilizzano la crittografia basata su file con crittografia dei metadati, devono:

[C-1-5] DEVE criptare i contenuti dei file e i metadati del file system utilizzando AES-256-XTS o Adiantum. AES-256-XTS si riferisce all'Advanced Encryption Standard con una lunghezza della chiave di cifratura di 256 bit, utilizzato in modalità XTS; la lunghezza totale della chiave è di 512 bit.Adiantum si riferisce ad Adiantum-XChaCha12-AES, come specificato all'indirizzo https://github.com/google/adiantum. I metadati del file system sono dati come dimensioni, proprietà, modalità e attributi estesi (xattr) dei file.
[C-1-6] I nomi dei file DEVONO essere criptati utilizzando AES-256-CBC-CTS, AES-256-HCTR2 o Adiantum.
[C-1-12] Se il dispositivo dispone di istruzioni Advanced Encryption Standard (AES) (come le estensioni di crittografia ARMv8 su dispositivi basati su ARM o AES-NI su dispositivi basati su x86), devono essere utilizzate le opzioni basate su AES sopra indicate per la crittografia di nome file, contenuto del file e metadati del file system, non Adiantum.
[C-1-13] DEVE utilizzare una funzione di derivazione delle chiavi (ad es. HKDF-SHA512) crittograficamente efficace e non reversibile per derivare le eventuali sottochiavi necessarie (ad es. chiavi per file) dalle chiavi CE e DE. "Crittograficamente forte e non reversibile" significa che la funzione di derivazione della chiave ha una forza di sicurezza di almeno 256 bit e si comporta come una famiglia di funzioni pseudocasuali sui suoi input.
[C-1-14] NON DEVE utilizzare le stesse chiavi o sottochiavi di crittografia basata su file (FBE) per scopi crittografici diversi (ad es. sia per la crittografia che per la derivazione delle chiavi o per due algoritmi di crittografia diversi).
[C-1-15] DEVE garantire che tutti i blocchi non eliminati dei contenuti dei file criptati sull'archiviazione permanente siano stati criptati utilizzando combinazioni di chiave di crittografia e vettore di inizializzazione (IV) che dipendono sia dal file sia dall'offset all'interno del file. Inoltre, tutte queste combinazioni DEVONO essere distinte, tranne nei casi in cui la crittografia viene eseguita utilizzando hardware di crittografia inline che supporta solo una lunghezza IV di 32 bit.
[C-1-16] DEVE garantire che tutti i nomi file criptati non eliminati nell'archiviazione permanente in directory distinte siano stati criptati utilizzando combinazioni distinte di chiave di crittografia e vettore di inizializzazione (IV).
[C-1-17] DEVE garantire che tutti i blocchi di metadati del file system criptati sull'archiviazione permanente siano stati criptati utilizzando combinazioni distinte di chiave di crittografia e vettore di inizializzazione (IV).
Chiavi che proteggono le aree di archiviazione CE e DE e i metadati del file system:
- [C-1-7] DEVE essere associato in modo crittografico a un keystore basato su hardware. Questo keystore DEVE essere associato all'Avvio verificato e alla radice di attendibilità hardware del dispositivo.
- [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 una password predefinita quando l'utente non ha specificato le credenziali della schermata di blocco.
- [C-1-10] DEVE essere univoco e distinto, in altre parole la chiave CE o DE di nessun utente corrisponde alle chiavi CE o DE di un altro utente.
- [C-1-11] DEVE utilizzare le cifrature, le lunghezze delle chiavi e le modalità supportate obbligatoriamente.
- [C-1-12] DEVE essere cancellato in modo sicuro durante lo sblocco e il blocco del bootloader come descritto qui.
DEVONO rendere le app essenziali preinstallate (ad es. Sveglia, Telefono, Messenger) compatibili con l'avvio diretto.

Il progetto Android Open Source upstream fornisce un'implementazione preferita della crittografia basata su file basata sulla funzionalità di crittografia "fscrypt" del kernel Linux e della crittografia dei metadati basata sulla funzionalità "dm-default-key" del kernel Linux.

9.9.3.2. Crittografia a livello di blocco per utente

Se le implementazioni dei dispositivi utilizzano la crittografia a livello di blocco per utente:

[C-1-1] DEVE attivare il supporto multiutente come descritto nella sezione 9.5.
[C-1-2] DEVE fornire partizioni per utente, utilizzando partizioni non elaborate o volumi logici.
[C-1-3] DEVE utilizzare chiavi di crittografia uniche e distinte per utente per la crittografia dei dispositivi a blocchi sottostanti.
[C-1-4] DEVE utilizzare AES-256-XTS per la crittografia a livello di blocco delle partizioni utente.
Le chiavi che proteggono i dispositivi criptati a livello di blocco per utente:
- [C-1-5] DEVE essere associato in modo crittografico a un keystore basato su hardware. Questo keystore DEVE essere associato all'Avvio verificato e alla radice di attendibilità hardware del dispositivo.
- [C-1-6] DEVE essere vincolato alle credenziali della schermata di blocco dell'utente corrispondente.

La crittografia a livello di blocco per utente può essere implementata utilizzando la funzionalità "dm-crypt" del kernel Linux sulle partizioni per utente.

9.9.4. Riprendi al riavvio

Riprendi dopo il riavvio consente di sbloccare l'archivio CE di tutte le app, incluse quelle che non supportano ancora l'avvio diretto, dopo un riavvio avviato da un aggiornamento OTA. Questa funzionalità consente agli utenti di ricevere notifiche dalle app installate dopo il riavvio.

Un'implementazione di Resume-on-Reboot deve continuare a garantire che, quando un dispositivo finisce nelle mani di un malintenzionato, sia estremamente difficile per quest'ultimo recuperare i dati dell'utente criptati con CE, anche se il dispositivo è acceso, l'archivio CE è sbloccato e l'utente ha sbloccato il dispositivo dopo aver ricevuto un aggiornamento OTA. Per la resistenza agli attacchi interni, presupponiamo anche che l'attaccante ottenga l'accesso alle chiavi di firma crittografiche di trasmissione.

In particolare:

[C-0-1] L'archivio CE NON DEVE essere leggibile nemmeno per l'utente malintenzionato che ha fisicamente il dispositivo e quindi ha queste funzionalità e limitazioni:
- Può utilizzare la chiave di firma di qualsiasi fornitore o azienda per firmare messaggi arbitrari.
- Può causare la ricezione di un aggiornamento OTA da parte del dispositivo.
- Può modificare il funzionamento di qualsiasi hardware (AP, flash ecc.) ad eccezione di quanto dettagliato di seguito, ma tale modifica comporta un ritardo di almeno un'ora e un ciclo di accensione che distrugge i contenuti della RAM.
- Non è possibile modificare il funzionamento dell'hardware antimanomissione (ad es. Titan M).
- Impossibile leggere la RAM del dispositivo live.
- Non è possibile ottenere le credenziali dell'utente (PIN, sequenza, password) o far sì che vengano inserite.

Ad esempio, un'implementazione del dispositivo che implementa e rispetta tutte le descrizioni riportate qui sarà conforme a [C-0-1].

9.10. Integrità del dispositivo

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

[C-0-1] DEVE segnalare correttamente tramite il metodo API di sistema PersistentDataBlockManager.getFlashLockState() se il bootloader consente il flashing dell'immagine di sistema.
[C-0-2] DEVE supportare l'avvio verificato per l'integrità del dispositivo.

Se le implementazioni dei dispositivi sono già state lanciate senza supportare l'Avvio verificato su una versione precedente di Android e non è possibile aggiungere il supporto per questa funzionalità con un aggiornamento del software di sistema, POTREBBERO essere esentate dal requisito.

L'Avvio verificato è una funzionalità che garantisce l'integrità del software del dispositivo. Se le implementazioni dei dispositivi supportano la funzionalità:

[C-1-1] DEVE dichiarare il flag della funzionalità della piattaforma android.software.verified_boot.
[C-1-2] DEVE eseguire la verifica a ogni sequenza di avvio.
[C-1-3] DEVE iniziare la verifica da una chiave hardware immutabile che sia la radice di 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] DEVE utilizzare algoritmi di verifica efficaci quanto le attuali raccomandazioni 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 acconsenta a tentare comunque l'avvio, nel qual caso i dati di qualsiasi blocco di archiviazione non verificato 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.
[C-1-8] MUST use tamper-evident storage: for storing whether the bootloader is unlocked. L'archiviazione a prova di manomissione significa che il bootloader può rilevare se l'archiviazione è stata manomessa dall'interno di Android.
[C-1-9] DEVE chiedere all'utente, durante l'utilizzo del dispositivo, e richiedere una conferma fisica prima di consentire una transizione dalla modalità bootloader bloccato alla modalità bootloader sbloccato.
[C-1-10] DEVE implementare la protezione dal rollback per le partizioni utilizzate da Android (ad es. partizioni di avvio e di sistema) e utilizzare un archivio a prova di manomissione per memorizzare i metadati utilizzati per determinare la versione minima consentita del sistema operativo.
[C-1-11] DEVE cancellare in modo sicuro tutti i dati utente durante lo sblocco e il blocco del bootloader, come indicato nella sezione "9.12. Data Deletion' (eliminazione dei dati), inclusa la partizione userdata e gli spazi NVRAM.
[C-1-14] DEVE verificare la firma almeno una volta per avvio per i pacchetti consentiti elencati come require-strict-signature nella configurazione di sistema.
[C-SR-2] È FORTEMENTE CONSIGLIATO verificare tutti i file APK delle app con privilegi con una catena di attendibilità basata su partizioni protette da Avvio verificato.
[C-SR-3] È VIVAMENTE CONSIGLIATO verificare gli artefatti eseguibili caricati da un'app con privilegi dall'esterno del file APK (ad esempio codice caricato dinamicamente o codice compilato) prima di eseguirli o È VIVAMENTE CONSIGLIATO non eseguirli affatto.
DEVE implementare la protezione dal rollback per qualsiasi componente con firmware persistente (ad es. modem, fotocamera) e DEVE utilizzare un archivio a prova di manomissione 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 caricare Android.

Se le implementazioni dei dispositivi sono in grado di verificare i contenuti dei file in base alla pagina, allora:

[C-2-1] supporta la verifica crittografica dei contenuti dei file senza leggere l'intero file.
[C-2-2] NON DEVE consentire la riuscita delle richieste di lettura su un file protetto quando il contenuto letto non è verificato in base a [C-2-1] sopra.
[C-2-4] DEVE restituire il checksum del file in O(1) per i file abilitati.

Se le implementazioni dei dispositivi sono già state lanciate senza la possibilità di verificare il contenuto dei file rispetto a una chiave attendibile in una versione precedente di Android e non è possibile aggiungere il supporto di questa funzionalità con un aggiornamento del software di sistema, POTREBBERO essere esentate dal requisito. Il progetto Android Open Source upstream fornisce un'implementazione preferita di questa funzionalità basata sulla funzionalità fs-verity del kernel Linux.

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

[C-0-1] DEVE consentire l'importazione o la generazione di almeno 8192 chiavi.
[C-0-2] L'autenticazione della schermata di blocco DEVE implementare un intervallo di tempo tra i tentativi non riusciti. Se n è il numero di tentativi non riusciti, l'intervallo di tempo DEVE essere di almeno 30 secondi per 9 < n < 30. Per n > 29, il valore dell'intervallo di tempo DEVE essere almeno 30*2^floor((n-30)/10) secondi o almeno 24 ore, a seconda di quale sia il valore più piccolo.
Non DOVREBBE limitare il numero di chiavi che possono essere generate.

Quando l'implementazione del dispositivo supporta una schermata di blocco sicura:

[C-1-1] DEVE eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.

[C-1-2] DEVE avere implementazioni di algoritmi di crittografia RSA, AES, ECDSA, ECDH (se IKeyMintDevice è supportato), 3DES e HMAC e funzioni hash MD5, SHA-1 e SHA-2 gli algoritmi di crittografia e le funzioni hash richiesti dalla versione di IKeyMintDevice o IKeymasterDevice supportata 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 mediante i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto open source Android (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura 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 in caso di esito positivo consentire l'utilizzo delle chiavi associate 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 Project upstream fornisce il Gatekeeper Hardware Abstraction Layer (HAL) 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 NON DEVONO essere utilizzate come identificatori permanenti del dispositivo.

Nota :per soddisfare questo requisito, devi condividere la stessa chiave di attestazione per un determinato SKU,a meno che non vengano prodotte almeno 100.000 unità di questo SKU. Se vengono prodotte più di 100.000 unità di questo SKU, dopo questo numero potrebbe essere utilizzata una chiave diversa per ogni gruppo di 100.000 unità. In alternativa, è possibile utilizzare la soluzione di provisioning delle chiavi remoto per eseguire il provisioning delle chiavi di attestazione di breve durata sul dispositivo.

[C-1-5] DEVE consentire all'utente di scegliere il timeout di sospensione per la transizione dallo stato sbloccato a quello bloccato, con un timeout minimo consentito fino a 15 secondi. I dispositivi per auto, che bloccano lo schermo ogni volta che l'unità principale viene spenta o l'utente viene cambiato, POTREBBERO NON avere la configurazione del timeout di sospensione.
[C-1-6] DEVE supportare IKeymasterDevice 3.0 o versioni successive oppure IKeyMintDevice versione 1 o successive.

[C-SR-1] È FORTEMENTE CONSIGLIATO di applicare un intervallo di tempo minimo tra tentativi non riusciti unici per i metodi di autenticazione principali (come PIN, sequenza o password), in base a quanto segue:

Numero di tentativi non riusciti univoci	Timeout minimo
0-4	0
5	1 minuto
6	5 minuti
7	15 minuti
8	30 minuti
9	90 minuti
10	4 ore
11	12 ore
12	24 ore
13	4 giorni
14	13 giorni
15	41 giorni
16	123 giorni
17	1 anno
18	3 anni
19	9 anni

9.11.1. Schermata di blocco sicura, autenticazione e dispositivi virtuali

L'implementazione AOSP segue un modello di autenticazione a più livelli in cui un'autenticazione primaria basata su fattori di conoscenza può essere supportata da una biometria secondaria forte o da modalità terziarie più deboli.

Implementazioni del dispositivo:

[C-SR-1] È FORTEMENTE CONSIGLIATO impostare solo uno dei seguenti metodi come metodo di autenticazione principale:
- Un PIN numerico
- Una password alfanumerica
- Un pattern di scorrimento su una griglia di esattamente 3x3 punti
Tieni presente che i metodi di autenticazione sopra indicati sono considerati i metodi di autenticazione primari consigliati in questo documento.
[C-0-1] DEVE limitare il numero di tentativi di autenticazione principale non riusciti.
[C-SR-5] È VIVAMENTE CONSIGLIATO di implementare un limite superiore di 20 tentativi di autenticazione principale non riusciti e, se gli utenti acconsentono e attivano la funzionalità, eseguire un "Ripristino dei dati di fabbrica" dopo aver superato il limite di tentativi di autenticazione principale non riusciti.

Se le implementazioni dei dispositivi impostano un PIN numerico come metodo di autenticazione principale consigliato, allora:

[C-SR-6] È VIVAMENTE CONSIGLIATO che un PIN abbia almeno 6 cifre o un'entropia di 20 bit.
[C-SR-7] È VIVAMENTE CONSIGLIATO di NON consentire l'inserimento automatico senza interazione dell'utente per un PIN di lunghezza inferiore a 6 cifre per evitare di rivelare la lunghezza del PIN.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione principali consigliati e utilizzano un nuovo metodo di autenticazione come modo sicuro per bloccare lo schermo, il nuovo metodo di autenticazione:

[C-2-1] DEVE essere il metodo di autenticazione dell'utente descritto in Richiedere l'autenticazione dell'utente per l'utilizzo delle chiavi.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco se basati su un segreto noto e utilizzano un nuovo metodo di autenticazione da trattare come un modo sicuro per bloccare lo schermo:

[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] Il nuovo metodo di autenticazione NON DEVE sostituire nessuno dei metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) implementati e forniti in AOSP.
[C-3-4] Il nuovo metodo di autenticazione DEVE essere disattivato quando l'applicazione controller di policy dei dispositivi (DPC) ha impostato il criterio dei requisiti della password tramite DevicePolicyManager.setRequiredPasswordComplexity() con una costante di complessità più restrittiva di PASSWORD_COMPLEXITY_NONE o tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-3-5] I nuovi metodi di autenticazione DEVONO ripristinare i metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) una volta ogni 72 ore o meno OPPURE comunicare chiaramente all'utente che alcuni dati non verranno sottoposti a backup per preservare la privacy dei dati.

Se le implementazioni dei dispositivi aggiungono o modificano i metodi di autenticazione principali consigliati per sbloccare la schermata di blocco e utilizzare un nuovo metodo di autenticazione basato sulla biometria da considerare un modo sicuro per bloccare lo schermo, il nuovo metodo:

[C-4-1] DEVE soddisfare tutti i requisiti descritti nella sezione 7.3.10 per la classe 1 (precedentemente Convenienza).
[C-4-2] DEVE disporre di un meccanismo di fallback per utilizzare uno dei metodi di autenticazione principale consigliati basato su un segreto noto.
[C-4-3] DEVE essere disattivato e consentire solo l'autenticazione primaria consigliata per sbloccare lo schermo quando l'applicazione controller di policy dei dispositivi (DPC) ha impostato il criterio della funzionalità Keyguard chiamando il metodo DevicePolicyManager.setKeyguardDisabledFeatures(), con uno qualsiasi dei flag biometrici associati (ad es. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE o KEYGUARD_DISABLE_IRIS).

Se i metodi di autenticazione biometrica non soddisfano i requisiti per la classe 3 (in precedenza forte) come descritto nella sezione 7.3.10:

[C-5-1] I metodi DEVONO essere disattivati se l'applicazione controller di policy dei dispositivi (DPC) ha impostato il criterio di qualità dei requisiti della password tramite DevicePolicyManager.setRequiredPasswordComplexity() con un bucket di complessità più restrittivo di PASSWORD_COMPLEXITY_LOW o utilizzando il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] All'utente DEVE essere richiesta l'autenticazione principale consigliata (ad esempio PIN, sequenza o password), come descritto in [C-1-7] e [C-1-8] nella sezione 7.3.10.
[C-5-3] I metodi NON DEVONO essere trattati come una schermata di blocco sicura e DEVONO soddisfare i requisiti che iniziano con C-8 nella sezione seguente.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco e un nuovo metodo di autenticazione si basa su un token fisico o sulla posizione:

[C-6-1] DEVE disporre di un meccanismo di fallback per utilizzare uno dei metodi di autenticazione principale consigliati, basato su un segreto noto e soddisfare i requisiti per essere trattato come una schermata di blocco sicura.
[C-6-2] Il nuovo metodo DEVE essere disattivato e deve consentire solo a uno dei metodi di autenticazione principale consigliati di sbloccare lo schermo quando l'applicazione controller di policy dei dispositivi (DPC) ha impostato il criterio con:
- Il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS).
- Il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva rispetto a PASSWORD_QUALITY_NONE.
- Il metodo DevicePolicyManager.setRequiredPasswordComplexity() con un bucket di complessità più restrittivo rispetto a PASSWORD_COMPLEXITY_NONE.
[C-6-3] All'utente DEVE essere richiesta l'autenticazione con uno dei metodi di autenticazione principali consigliati (ad esempio PIN, sequenza o password) almeno una volta ogni 4 ore o meno. Quando un token fisico soddisfa i requisiti per le implementazioni di TrustAgent in C-X, si applicano invece le limitazioni di timeout definite in [C-9-5].
[C-6-4] Il nuovo metodo NON DEVE essere trattato come una schermata di blocco sicura e DEVE rispettare i vincoli elencati in C-8 di seguito.

[C-7-1] DEVE essere presente un'indicazione chiara nel menu delle impostazioni e nella schermata di blocco quando il blocco del dispositivo è posticipato o può essere sbloccato da uno o più agenti di attendibilità. Ad esempio, AOSP soddisfa questo requisito mostrando una descrizione testuale per le impostazioni "Blocco automatico" e "Tasto di accensione blocca istantaneamente" nel menu delle impostazioni e un'icona distinguibile nella schermata di blocco.
[C-7-2] DEVE rispettare e implementare completamente tutte le API dell'agente di attendibilità nella classe DevicePolicyManager, ad esempio la costante KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] NON DEVE implementare completamente la funzione TrustAgentService.addEscrowToken() su un dispositivo utilizzato come dispositivo personale principale (ad es. dispositivo portatile), ma PUÒ implementare completamente la funzione su implementazioni di dispositivi che vengono in genere condivise (ad es. Android TV o dispositivo per auto).
[C-7-4] MUST encrypt all stored tokens added by TrustAgentService.addEscrowToken().
[C-7-5] NON DEVE archiviare la chiave di crittografia o il token di deposito a garanzia sullo stesso dispositivo in cui viene utilizzata la chiave. Ad esempio, è consentito che una chiave memorizzata su uno smartphone sblocchi un account utente su una TV. Per i dispositivi Automotive, non è consentito memorizzare il token di garanzia in nessuna parte del veicolo.
[C-7-6] DEVE informare l'utente delle implicazioni per la sicurezza prima di attivare il token di deposito a garanzia per decriptare l'archiviazione dei dati.
[C-7-7] DEVE disporre di un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principale consigliati.
[C-7-9] All'utente DEVE essere richiesta l'autenticazione primaria consigliata (ad esempio PIN, sequenza o password) come descritto in [C-1-7] e [C-1-8] nella sezione 7.3.10, a meno che non sia a rischio la sicurezza dell'utente (ad es. distrazione del conducente).
[C-7-10] NON DEVE essere trattato come una schermata di blocco sicura e DEVE rispettare i vincoli elencati in C-8 di seguito.
[C-7-11] NON DEVE consentire a Trust Agents sui dispositivi personali principali (ad es.portatili) di sbloccare il dispositivo e può utilizzarli solo per mantenere un dispositivo già sbloccato nello stato sbloccato per un massimo di 4 ore. L'implementazione predefinita di TrustManagerService in AOSP soddisfa questo requisito.
[C-7-12] DEVE utilizzare un canale di comunicazione con protezione criptata (ad es.UKEY2) per trasferire il token di deposito a garanzia dal dispositivo di archiviazione al dispositivo di destinazione.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco che non è una schermata di blocco sicura come descritto sopra e utilizzano un nuovo metodo di autenticazione per sbloccare il keyguard:

[C-8-1] Il nuovo metodo DEVE essere disattivato quando l'applicazione controller di policy dei dispositivi (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_NONE o tramite il metodo DevicePolicyManager.setRequiredPasswordComplexity() con una costante di complessità più restrittiva di PASSWORD_COMPLEXITY_NONE.
[C-8-2] NON DEVONO reimpostare i timer di scadenza della password impostati da DevicePolicyManager.setPasswordExpirationTimeout().
[C-8-3] NON DEVONO esporre un'API per l'utilizzo da parte di app di terze parti per modificare lo stato della serratura.

Se le implementazioni dei dispositivi consentono alle applicazioni di creare display virtuali secondari e non supportano eventi di input associati, ad esempio tramite VirtualDeviceManager, questi:

[C-9-1] DEVE bloccare questi display virtuali secondari quando il display predefinito del dispositivo è bloccato e sbloccarli quando il display predefinito del dispositivo è sbloccato.

Se le implementazioni dei dispositivi consentono alle applicazioni di creare display virtuali secondari e supportano eventi di input associati, ad esempio tramite VirtualDeviceManager, questi:

[C-10-1] DEVE supportare stati di chiusura separati per dispositivo virtuale
[C-10-2] Requisito rimosso in Android 16.
[C-10-3] Requisito rimosso in Android 16.
[C-10-4] DEVE bloccare tutti i display quando l'utente avvia un lockdown, anche tramite l'interfaccia utente di lockdown richiesta per i dispositivi portatili (vedi Sezione 2.2.5[9.11/H-1-2])
[C-10-5] MUST have separate virtual device instances per user
[C-10-6] DEVE disattivare lo streaming di app come indicato da DevicePolicyManager.setNearbyAppStreamingPolicy.
[C-10-7] Requisito rimosso in Android 16.
[C-10-11] DEVE disattivare la UI di autenticazione sui dispositivi virtuali, inclusi l'inserimento del fattore di conoscenza e la richiesta biometrica
[C-10-12] Requisito rimosso in Android 16.
[C-10-13] NON DEVE utilizzare uno stato di blocco del dispositivo virtuale come autorizzazione di autenticazione dell'utente con Android Keystore System. Vedi KeyGenParameterSpec.Builder.setUserAuthentication*.
[C-10-14] DEVE fornire un'opzione utente per attivare la condivisione degli appunti tra dispositivi prima di condividere i dati degli appunti tra dispositivi fisici e virtuali se il dispositivo implementa appunti condivisi.
[C-10-15] DEVE mostrare le notifiche quando si accede ai dati degli appunti sia sul dispositivo da cui è stato effettuato l'accesso sia sul dispositivo da cui hanno avuto origine gli appunti.

Quando le implementazioni dei dispositivi consentono all'utente di trasferire il fattore di conoscenza di autenticazione principale da un dispositivo di origine a un dispositivo di destinazione, ad esempio per la configurazione iniziale del dispositivo di destinazione:

[C-11-1] DEVE criptare il fattore di conoscenza con garanzie di protezione simili a quelle descritte nel white paper sulla sicurezza del servizio Google Cloud Key Vault durante il trasferimento del fattore di conoscenza dal dispositivo di origine al dispositivo di destinazione in modo che il fattore di conoscenza non possa essere decriptato da remoto o utilizzato per sbloccare da remoto uno dei due dispositivi.
[C-11-2] DEVE, sul dispositivo di origine , chiedere all'utente di confermare il fattore di conoscenza del dispositivo di origine prima di trasferirlo al dispositivo di destinazione.
[C-11-3] DEVE, su un dispositivo di destinazione privo di qualsiasi fattore di conoscenza di autenticazione principale impostato, chiedere all'utente di confermare un fattore di conoscenza trasferito sul dispositivo di destinazione prima di impostarlo come fattore di conoscenza di autenticazione principale per il dispositivo di destinazione e prima di rendere disponibili i dati trasferiti da un dispositivo di origine.

Se le implementazioni del dispositivo hanno una schermata di blocco sicura e includono uno o più trust agent, che chiamano l'API di sistema TrustAgentService.grantTrust() con il flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, questi:

[C-12-1] DEVE chiamare grantTrust() con il flag solo quando è connesso a un dispositivo fisico vicino con una schermata di blocco propria e quando l'utente ha autenticato la propria identità rispetto a quella schermata di blocco. I dispositivi nelle vicinanze possono utilizzare meccanismi di rilevamento sul polso o Dispositivo con te dopo uno sblocco una tantum dell'utente per soddisfare il requisito di autenticazione dell'utente.
[C-12-2] DEVE impostare l'implementazione del dispositivo nello stato TrustState.TRUSTABLE quando lo schermo è spento (ad esempio tramite la pressione di un pulsante o lo spegnimento del display) e TrustAgent non ha revocato l'attendibilità. AOSP soddisfa questo requisito.
[C-12-3] DEVE spostare il dispositivo dallo stato TrustState.TRUSTABLE allo stato TrustState.TRUSTED solo se TrustAgent continua a concedere l'attendibilità in base ai requisiti indicati in [C-12-1].

[C-12-4] DEVE chiamare TrustManagerService.revokeTrust() se le implementazioni non utilizzano una misurazione accurata e crittograficamente sicura come definito in [C-12-5]:
- Dopo un massimo di 24 ore dalla concessione dell'attendibilità oppure
- Dopo un periodo di inattività di 8 ore o
- Se le implementazioni non utilizzano una misurazione accurata e sicura dal punto di vista crittografico come definito in [C-12-5], quando la connessione sottostante al dispositivo fisico nelle vicinanze viene persa.

[C-12-5] Le implementazioni che si basano su una misurazione sicura e accurata per soddisfare i requisiti di [C-12-4] DEVONO utilizzare una delle seguenti soluzioni:
- Implementazioni che utilizzano UWB:
  - DEVE soddisfare i requisiti di conformità, certificazione, precisione e calibrazione per l'UWB descritti nella sezione 7.4.9.
  - DEVE utilizzare una delle modalità di sicurezza P-STS elencate nella sezione 7.4.9.
- Implementazioni che utilizzano il Neighbor Awareness Networking (NAN) Wi-Fi:
  - DEVE soddisfare i requisiti di accuratezza indicati in 2.2.1 [7.4.2.5/H-SR-1], utilizzare la larghezza di banda di 160 MHz (o superiore) e seguire i passaggi di configurazione della misurazione specificati in Calibrazione della presenza.
  - DEVE utilizzare Secure LTF come definito in IEEE 802.11az.

Se le implementazioni dei dispositivi consentono alle applicazioni di creare display virtuali secondari e supportano eventi di input associati, ad esempio tramite VirtualDeviceManager e i display non sono contrassegnati con VIRTUAL_DISPLAY_FLAG_SECURE, allora:

[C-13-8] DEVE bloccare l'avvio sul dispositivo virtuale delle attività con l'attributo android:canDisplayOnRemoteDevices o i metadati android.activity.can_display_on_remote_devices impostati su false.
[C-13-9] DEVE bloccare le attività che non attivano esplicitamente lo streaming e che indicano di mostrare contenuti sensibili, anche tramite SurfaceView#setSecure e FLAG_SECURE dall'avvio sul dispositivo virtuale.

Se le implementazioni dei dispositivi supportano stati di alimentazione del display separati tramite DeviceStateManager E supportano stati di blocco del display separati tramite KeyguardDisplayManager,

[C-SR-2] È FORTEMENTE CONSIGLIATO utilizzare una credenziale che soddisfi i requisiti definiti nella sezione 9.11.1 o una credenziale biometrica che soddisfi almeno le specifiche di Classe 1 definite nella sezione 7.3.10 per consentire lo sblocco indipendente dal display del dispositivo predefinito.
[C-SR-3] È FORTEMENTE CONSIGLIATO di limitare lo sblocco del display separato tramite un timeout del display definito.
[C-SR-4] Sono FORTEMENTE CONSIGLIATI per consentire all'utente di bloccare globalmente tutti i display tramite il blocco dal dispositivo portatile principale.

9.11.2. StrongBox

Il sistema Android Keystore consente agli sviluppatori di app di archiviare le chiavi di crittografia in un processore sicuro dedicato e nell'ambiente di esecuzione isolato descritto in precedenza. Un processore sicuro dedicato di questo tipo è chiamato "StrongBox". I requisiti da C-1-3 a C-1-11 di seguito definiscono i requisiti che un dispositivo deve soddisfare per essere considerato StrongBox.

Implementazioni del dispositivo con un processore sicuro dedicato:

[C-SR-1] Sono VIVAMENTE CONSIGLIATI per supportare StrongBox. StrongBox diventerà probabilmente un requisito in una release futura.

Se le implementazioni dei dispositivi supportano StrongBox:

[C-1-1] MUST declare FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] DEVE fornire hardware sicuro dedicato utilizzato per eseguire il backup del keystore e l'autenticazione utente sicura. L'hardware sicuro dedicato può essere utilizzato anche per altri scopi.
[C-1-3] DEVE avere una CPU discreta che non condivida cache, DRAM, coprocessori o altre risorse di core con il processore dell'applicazione (AP).
[C-1-4] DEVE garantire che qualsiasi periferica condivisa con l'AP non possa alterare in alcun modo l'elaborazione di StrongBox o ottenere informazioni da StrongBox. Il fornitore di servizi potrebbe disattivare o bloccare l'accesso a StrongBox.
[C-1-5] DEVE avere un orologio interno con una precisione ragionevole (+/- 10%) che non possa essere manipolato dal PA.
[C-1-6] DEVE avere un generatore di numeri casuali che produca un output distribuito in modo uniforme e imprevedibile.
[C-1-7] DEVE essere resistente alla manomissione, inclusa la resistenza a penetrazione fisica e glitch.
[C-1-8] DEVE avere resistenza ai canali collaterali, inclusa la resistenza alla perdita di informazioni tramite canali collaterali di alimentazione, temporizzazione, radiazioni elettromagnetiche e radiazioni termiche.
[C-1-9] DEVE disporre di un archivio sicuro che garantisca la riservatezza, l'integrità, l'autenticità, la coerenza e l'aggiornamento dei contenuti. L'archivio NON deve essere leggibile o modificabile, tranne come consentito dalle API StrongBox.

Per convalidare la conformità ai requisiti da [C-1-3] a [C-1-9], implementazioni del dispositivo:

[C-1-10] DEVE includere l'hardware certificato in base al profilo di protezione IC sicuro BSI-CC-PP-0084-2014 o BSI-CC-PP-0117-2022, o è valutato da un laboratorio di test accreditato a livello nazionale che incorpora la valutazione delle vulnerabilità con potenziale di attacco elevato in base ai Common Criteria Application of Attack Potential to Smartcards.
[C-1-11] DEVE includere il firmware valutato da un laboratorio di test accreditato a livello nazionale che incorpora la valutazione della vulnerabilità con potenziale di attacco elevato in base ai Common Criteria Application of Attack Potential to Smartcards.
[C-SR-2] Sono FORTEMENTE CONSIGLIATI per includere l'hardware che è valutato utilizzando un target di sicurezza, un livello di garanzia di valutazione (EAL) 5, aumentato da AVA_VAN.5. È probabile che la certificazione EAL 5 diventerà un requisito in una release futura.
[C-SR-3] È FORTEMENTE CONSIGLIATO fornire resistenza agli attacchi interni (IAR), il che significa che un insider con accesso alle chiavi di firma del firmware non può produrre firmware che causino la perdita di segreti da parte di StrongBox, che aggirino i requisiti di sicurezza funzionale o che consentano in altro modo l'accesso a dati utente sensibili. Il modo consigliato per implementare IAR è consentire gli aggiornamenti firmware solo quando la password dell'utente principale viene fornita tramite l'HAL IAuthSecret.

9.11.3. Credenziali di identità

Il sistema di credenziali di identità viene definito e ottenuto implementando tutte le API nel pacchetto android.security.identity.*. Queste API consentono agli sviluppatori di app di archiviare e recuperare i documenti di identità degli utenti. Implementazioni del dispositivo:

[C-SR-1] è FORTEMENTE CONSIGLIATO di implementare l'Identity Credential System.

Se le implementazioni dei dispositivi implementano il sistema di credenziali dell'identità:

[C-1-1] DEVE restituire un valore non nullo per il metodo IdentityCredentialStore#getInstance().
[C-1-2] DEVE implementare il sistema di credenziali di identità (ad es. le API android.security.identity.*) con codice che comunica con un'applicazione attendibile in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi con cui il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA.
[C-1-3] Le operazioni crittografiche necessarie per implementare l'Identity Credential System (ad es. le API android.security.identity.*) DEVONO essere eseguite interamente nell'applicazione attendibile e il materiale della chiave privata NON deve mai uscire dall'ambiente di esecuzione isolato, a meno che non sia specificamente richiesto da API di livello superiore (ad es. il metodo createEphemeralKeyPair()).
[C-1-4] L'applicazione attendibile DEVE essere implementata in modo che le sue proprietà di sicurezza non siano interessate (ad esempio, i dati delle credenziali non vengono rilasciati a meno che non siano soddisfatte le condizioni di controllo dell'accesso, i MAC non possono essere prodotti per dati arbitrari) anche se Android non funziona correttamente o è compromesso.

Il progetto Android Open Source upstream fornisce un'implementazione di riferimento di un'applicazione attendibile (libeic) che può essere utilizzata per implementare il sistema di credenziali dell'identità.

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] DEVE eliminare tutti i dati nel file system userdata quando esegue un "Ripristino dei dati di fabbrica".
[C-0-3] DEVE eliminare i dati in modo da soddisfare gli standard di settore pertinenti, ad esempio NIST SP800-88, quando esegue un "Ripristino dei dati di fabbrica".
[C-0-4] DEVE attivare la procedura di "Ripristino dei dati di fabbrica" di cui sopra quando l'API DevicePolicyManager.wipeData() viene chiamata dall'app controller di policy dei dispositivi dell'utente principale.
POTREBBE fornire un'opzione di cancellazione rapida dei dati che esegue solo un'eliminazione logica dei dati.

9.13. Modalità di avvio sicuro

Android fornisce la modalità provvisoria, che consente agli utenti di avviare il dispositivo 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", offre all'utente la possibilità di disinstallare app di terze parti potenzialmente dannose.

Le implementazioni dei dispositivi sono:

[C-SR-1] VIVAMENTE CONSIGLIATO di implementare la modalità provvisoria.

Se le implementazioni dei dispositivi implementano la modalità di avvio sicuro:

[C-1-1] DEVE fornire all'utente un'opzione per entrare in modalità provvisoria in modo non interrompibile da app di terze parti installate sul dispositivo, tranne quando l'app di terze parti è un controller di policy dei dispositivi 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.
DEVE 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 avvio normale.

9.14. Isolamento del sistema del veicolo

I dispositivi Android Automotive dovrebbero scambiare dati con i sottosistemi critici del veicolo utilizzando l'Vehicle HAL 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 al di sotto dei livelli del framework Android per impedire l'interazione dannosa o involontaria con questi sottosistemi.

9.15. Piani di abbonamento

I "piani di abbonamento" si riferiscono ai dettagli del piano di fatturazione forniti da un operatore di telefonia mobile tramite SubscriptionManager.setSubscriptionPlans().

Tutte le implementazioni dei dispositivi:

[C-0-1] MUST return subscription plans only to the mobile carrier app that has originally provided them.
[C-0-2] NON DEVE eseguire il backup o caricare da remoto i piani di abbonamento.
[C-0-3] DEVE consentire solo gli override, ad esempio SubscriptionManager.setSubscriptionOverrideCongested(), dall'app dell'operatore di telefonia mobile che attualmente fornisce piani in abbonamento validi.

9.16. Migrazione dei dati delle applicazioni

Se le implementazioni dei dispositivi includono una funzionalità per eseguire la migrazione dei dati da un dispositivo a un altro e non limitano i dati dell'applicazione che copia a quelli configurati dallo sviluppatore dell'applicazione nel manifest tramite l'attributo android:fullBackupContent, queste:

[C-1-1] NON DEVE avviare trasferimenti di dati delle applicazioni da dispositivi su cui l'utente non ha impostato un'autenticazione principale come descritto in 9.11.1 Schermata di blocco e autenticazione sicure.
[C-1-2] DEVE confermare in modo sicuro l'autenticazione principale sul dispositivo di origine e confermare l'intenzione dell'utente di copiare i dati sul dispositivo di origine prima che vengano trasferiti.
[C-1-3] DEVE utilizzare l'attestazione di chiavi di sicurezza per garantire che sia il dispositivo di origine sia il dispositivo di destinazione nella migrazione da dispositivo a dispositivo siano dispositivi Android legittimi e abbiano un bootloader bloccato.
[C-1-4] DEVE eseguire la migrazione dei dati dell'applicazione solo alla stessa applicazione sul dispositivo di destinazione, con lo stesso nome del pacchetto E certificato di firma.
[C-1-5] DEVE mostrare un'indicazione che i dati del dispositivo di origine sono stati migrati da un'operazione di migrazione dei dati da dispositivo a dispositivo nel menu delle impostazioni. Un utente NON DEVE essere in grado di rimuovere questa indicazione.

9.17. Framework di virtualizzazione di Android

Le API Framework di virtualizzazione di Android (AVF) (android.system.virtualmachine.*) consentono alle applicazioni di creare macchine virtuali (VM) on-device, protette (pVM) e non protette (non pVM) che caricano ed eseguono binari nativi come payload.

Se le implementazioni dei dispositivi impostano FEATURE_VIRTUALIZATION_FRAMEWORK su true, questi:

[C-1-1] DEVE garantire che android.system.virtualmachine.VirtualMachineManager.getCapabilities() restituisca uno dei seguenti valori:
- CAPABILITY_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. Verifica dello sviluppatore

Implementazioni del dispositivo che dichiarano il livello API 36.1 o versioni successive:

POTREBBE includere il supporto di un servizio di verifica dello sviluppatore per certificare che le applicazioni provengono da uno sviluppatore noto.

Implementazioni del dispositivo che dichiarano il livello API 36.1 o superiore e configurano un programma di verifica per sviluppatori definendo config_developerVerificationServiceProviderPackageName in config.xml:

[9.18/C-1-1] DEVE richiamare android.content.pm.verify.developer.DeveloperVerifierService configurato per ogni installazione di pacchetto dell'applicazione, incluse le nuove installazioni e gli aggiornamenti delle applicazioni esistenti.

Implementazioni del dispositivo che dichiarano il livello API 36.1 o versioni successive:

MAY può anche configurare un delegato per l'impostazione della policy attiva definendo config_developerVerificationPolicyDelegatePackageName in config.xml.

Se è configurato un verificatore sviluppatore, le implementazioni del dispositivo:

[9.18/C-2-1] DEVE consentire solo al verificatore sviluppatore o al suo delegato configurato di impostare la policy di installazione come definito in android.content.pm.PackageInstaller.

Se un programma di verifica viene richiamato nell'ambito di una sessione di installazione del pacchetto, le implementazioni del dispositivo:

[9.18/C-3-1] DEVE impedire l'installazione di un pacchetto di applicazioni se:
- L'installazione non supera la verifica dell'identità dello sviluppatore.
- Il criterio di verifica dello sviluppatore per la sessione di installazione è impostato su un valore diverso da DEVELOPER_VERIFICATION_POLICY_NONE.
- A meno che non si applichi la sezione 9.18/C-3-2 o 9.18/C-3-3.

[9.18/C-3-2] NON DEVE impedire l'installazione di un pacchetto dell'applicazione indipendentemente dallo stato dei criteri o della verifica quando:
- Il pacchetto viene installato tramite Android Debug Bridge (ADB).
- Il pacchetto è lo strumento di verifica sviluppatore configurato o il relativo programma di installazione.

[9.18/C-3-3] NON DEVE impedire l'installazione di un pacchetto dell'applicazione quando sono soddisfatte tutte le seguenti condizioni:
- Il criterio è impostato su DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN o DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN.
- La verifica è segnalata come incompleta.
- Il programma di installazione indica che l'utente ha richiesto esplicitamente di continuare l'installazione segnalando DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY.

POTREBBE consentire l'installazione di un pacchetto dell'applicazione indipendentemente dallo stato dei criteri o della verifica per le installazioni avviate dal proprietario del dispositivo su un dispositivo gestito o dal proprietario del profilo su un profilo gestito, ma è VIVAMENTE CONSIGLIATO di impedire le installazioni come descritto in 9.18/C-3-1.

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 esaustivo. Per questo motivo, è FORTEMENTE CONSIGLIATO agli implementatori di dispositivi di apportare il minor numero possibile di modifiche all'implementazione di riferimento e preferita di Android disponibile da Android Open Source Project. In questo modo, il rischio di introdurre bug che creano incompatibilità che richiedono rielaborazioni e potenziali aggiornamenti del dispositivo sarà ridotto al minimo.

10.1. Compatibility Test Suite (CTS)

Implementazioni del dispositivo:

[C-0-1] DEVE superare la suite di test di compatibilità Android (CTS) disponibile nell'Android Open Source Project, utilizzando il software di spedizione finale sul dispositivo.
[C-0-2] DEVE garantire la compatibilità in caso di ambiguità in CTS e per qualsiasi reimplementazione di parti del codice sorgente di riferimento.

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi software, il CTS potrebbe contenere bug. Il CTS avrà una versione indipendente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni del CTS per Android 17.

Implementazioni del dispositivo:

[C-0-3] DEVE superare l'ultima versione di CTS disponibile al momento del completamento del software del dispositivo.
DEVE utilizzare l'implementazione di riferimento nell'albero Android Open Source il più possibile.

10.2. Strumento di verifica CTS

CTS Verifier è incluso in Compatibility Test Suite e deve essere eseguito da un operatore umano per testare funzionalità che non possono essere testate da un sistema automatizzato, come il corretto funzionamento di una fotocamera e dei sensori.

Implementazioni del dispositivo:

[C-0-1] DEVE eseguire correttamente tutti i casi applicabili nel programma di verifica CTS.

CTS Verifier include test per molti tipi di hardware, tra cui alcuni hardware opzionali.

Implementazioni del dispositivo:

[C-0-2] DEVE superare tutti i test per l'hardware in suo possesso; ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente lo scenario di test dell'accelerometro in CTS Verifier.

Gli scenari di test per le funzionalità indicate come facoltative in questo documento di definizione della compatibilità POSSONO essere ignorati o omessi.

[C-0-2] Ogni dispositivo e ogni build DEVE eseguire correttamente CTS Verifier, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori di dispositivi eseguano esplicitamente CTS Verifier su build che differiscono solo in modo banale. In particolare, le implementazioni del dispositivo che differiscono da un'implementazione che ha superato CTS Verifier solo per l'insieme di impostazioni internazionali, branding e così via INCLUDONO il test CTS Verifier.

11. Software aggiornabile

[C-0-1] Le implementazioni del dispositivo DEVONO includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire upgrade "live", ovvero potrebbe essere necessario riavviare il dispositivo. Può essere utilizzato qualsiasi metodo, purché possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, uno dei seguenti approcci soddisferà questo requisito:
- Download "over-the-air (OTA)" con aggiornamento offline tramite riavvio.
- Aggiornamenti "in tethering" tramite USB da un PC host.
- Aggiornamenti "offline" tramite riavvio e aggiornamento da un file su un dispositivo di archiviazione rimovibile.
[C-0-2] Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. ovvero il meccanismo di aggiornamento DEVE preservare i dati privati dell'applicazione e i dati condivisi dell'applicazione. Tieni presente che il software Android upstream include un meccanismo di aggiornamento che soddisfa questo requisito.
[C-0-3] L'intero aggiornamento DEVE essere firmato e il meccanismo di aggiornamento sul dispositivo DEVE verificare l'aggiornamento e la firma rispetto a una chiave pubblica memorizzata sul dispositivo.
[C-SR-1] Il meccanismo di firma è FORTEMENTE CONSIGLIATO per eseguire l'hashing dell'aggiornamento con SHA-256 e convalidare l'hash rispetto alla chiave pubblica utilizzando ECDSA NIST P-256.

Se le implementazioni del dispositivo includono il supporto di una connessione dati senza limiti, ad esempio 802.11 o il profilo PAN (Personal Area Network) Bluetooth, allora:

[C-1-1] DEVE supportare i download OTA con aggiornamento offline tramite riavvio.

Le implementazioni del dispositivo DEVONO verificare che l'immagine di sistema sia identica a livello binario al risultato previsto dopo un aggiornamento OTA. L'implementazione OTA basata su blocchi nel progetto Android Open Source upstream, aggiunta a partire 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 dell'avvio.

Se viene rilevato un errore nell'implementazione di un dispositivo dopo il suo rilascio, ma entro la sua ragionevole durata del prodotto, determinata in consultazione con il team di compatibilità Android per influire sulla compatibilità di applicazioni di terze parti, allora:

[C-2-1] 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 del dispositivo (se presente) di controllare l'installazione degli aggiornamenti di sistema. Se il sottosistema di aggiornamento di sistema per i dispositivi segnala android.software.device_admin, allora:

[C-3-1] DEVE implementare il comportamento descritto nella classe SystemUpdatePolicy.

12. Log delle modifiche del documento

A partire da Android 16, non esiste un changelog gestito separatamente. Tutte le modifiche rispetto alla versione precedente sono evidenziate in questo documento.

13. Contattaci

Puoi partecipare al forum sulla compatibilità di Android e chiedere chiarimenti o segnalare eventuali problemi che ritieni non siano coperti dal documento.

Definizione di compatibilità di Android 17 [ANTEPRIMA] Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

1. Introduzione

1.1 Struttura del documento

1.1.1. Requisiti per tipo di dispositivo

1.1.2. ID requisito

1.1.3. ID requisito nella sezione 2

2. Tipi di dispositivi

2.1 Configurazioni dispositivo

2.2. Requisiti per dispositivi portatili

2.2.1. Hardware

2.2.2. Multimediali

2.2.3. Software

2.2.3. Software

2.2.4. Prestazioni e potenza

2.2.5. Modello di sicurezza

Impostazioni limitate

2.2.6. Compatibilità di strumenti e opzioni per sviluppatori

2.2.7. Classe di prestazioni multimediali portatili

2.2.7.1. Media

2.2.7.2. Fotocamera

2.2.7.3. Hardware

2.2.7.4. Rendimento

2.2.7.5. Grafica

2.3. Requisiti della TV

2.3.1. Hardware

2.3.2. Multimediali

2.3.3. Software

2.3.4. Prestazioni e potenza

2.3.5. Modello di sicurezza

2.3.6. Compatibilità di strumenti e opzioni per sviluppatori

2.4. Requisiti dell'orologio

2.4.1. Hardware

2.4.2. Multimediali

2.4.3. Software

2.4.4. Prestazioni e potenza

2.4.5. Modello di sicurezza

2.5. Requisiti per il settore automobilistico

2.5.1. Hardware

2.5.2. Multimediali

2.5.3. Software

2.5.4. Prestazioni e potenza

2.5.5. Modello di sicurezza

2.5.6. Compatibilità di strumenti e opzioni per sviluppatori

2.6. Requisiti per i tablet

2.6.1. Hardware

2.6.2. Modello di sicurezza

2.6.2. Software

3. Software

3.1. Compatibilità API gestita

3.1.1. Estensioni Android

3.1.2. Libreria Android

3.2. Compatibilità API soft

3.2.1. Autorizzazioni

3.2.2. Parametri di creazione

3.2.3. Compatibilità degli intent

3.2.3.1. Intent comuni delle applicazioni

3.2.3.2. Risoluzione dell'intent

3.2.3.3. Spazi dei nomi degli intent

3.2.3.4. Broadcast Intents

3.2.3.5. Intent di applicazione condizionali

3.2.4. Attività su display secondari/multipli

3.3. Compatibilità con l'API nativa

3.3.1. Application Binary Interfaces

3.3.2. Compatibilità del codice nativo ARM a 32 bit

3.4. Compatibilità web

3.4.1. Compatibilità di WebView

3.4.2. Compatibilità dei browser

3.5. Compatibilità comportamentale delle API

3.5.1. Limitazione dell'applicazione

3.5.2. Ibernazione delle applicazioni

3.6. API Namespaces

3.7. Compatibilità del runtime

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

3.8.2. Widget

3.8.3. Notifiche

3.8.3.1. Presentazione delle notifiche

3.8.3.2. Servizio listener di notifiche

3.8.3.3. DND (Do Not Disturb, Non disturbare) / Modalità Priorità

3.8.3.4. Protezione delle notifiche sensibili

Definizione di compatibilità di Android 17 [ANTEPRIMA]