Definizione di compatibilità con Android 15

1. Introduzione

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

L'uso di "DEVE", "NON DEVE", "OBBLIGATORIO", "DEVE", "NON DEVE", "DEVE", "NON DEVE", "CONSIGLIATO", "PUÒ" e "FACOLTATIVO" è 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 con Android 15. Un'"implementazione del dispositivo" o "implementazione" è la soluzione hardware/software così sviluppata.

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

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

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

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

1.1 Struttura del documento

1.1.1. Requisiti per tipo di dispositivo

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

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

1.1.2. ID requisito

L'ID requisito viene assegnato per i requisiti MUST.

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

Ogni ID è definito come segue:

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

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.

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 serie di tipi di dispositivi e fattori di forma. Per supportare la sicurezza sui dispositivi, lo stack software, inclusi eventuali sistemi operativi sostitutivi o un'implementazione del kernel alternata, deve essere eseguito in un ambiente sicuro come descritto nella sezione 9 e altrove in 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 di dispositivo.

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

2.1 Configurazioni del dispositivo

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

2.2. Requisiti del dispositivo portatile

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

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

• Avere una fonte di alimentazione che offra mobilità, ad esempio una batteria.
• Avere una dimensione dello schermo in diagonale fisica compresa tra 10 e 20 cm.
• Avere un'interfaccia di input touchscreen.

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

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

2.2.1. Hardware

Implementazioni dei dispositivi portatili:

• [7.1.1.1/H-0-1] DEVE avere almeno un display compatibile con Android di almeno 5,6 cm sul lato corto e 8,6 cm sul lato lungo.

• [7.1.1.3/H-SR-1] È FORTEMENTE CONSIGLIATO fornire agli utenti un'opzione per modificare le dimensioni del display (densità dello schermo).

• [7.1.1.1/H-0-2] DEVE supportare la composizione GPU di buffer grafici di dimensioni almeno pari alla risoluzione più alta di qualsiasi display integrato.

• [7.1.1.1/H-0-3]* DEVE mappare ogni UI_MODE_NORMAL display reso disponibile per le applicazioni di terze parti su un'area di visualizzazione fisica senza ostacoli di almeno 5,6 cm sul lato corto e 8,6 cm sul lato lungo.

• [7.1.1.3/H-0-1]* È NECESSARIO impostare il valore di 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 dei dispositivi portatili dichiarano di supportare i display HDR tramite Configuration.isScreenHdr() , devono:

• [7.1.4.5/H-1-1] È OBBLIGATORIO 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 dei dispositivi portatili:

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

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

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

Implementazioni dei dispositivi portatili:

• [7.1.5/H-0-1] DEVE includere il supporto per la modalità di compatibilità delle applicazioni precedenti, come implementata dal codice open source di Android upstream. In altre parole, le implementazioni dei dispositivi NON DEVONO modificare gli attivatori o le soglie a cui viene attivata la modalità di compatibilità e NON DEVONO modificare il comportamento della modalità di compatibilità stessa.
• [7.2.1/H-0-1] È NECESSARIO includere il supporto per le applicazioni Input Method Editor (IME) di terze parti.
• [7.2.3/H-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. Questi eventi NON DEVONO essere utilizzati dal sistema e POSSONO essere attivati dall'esterno 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 di questi display.
• [7.2.4/H-0-1] DEVE supportare l'input touchscreen.
• [7.2.4/H-SR-1] È FORTEMENTE CONSIGLIATO di avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService, o un'attività che gestisce ACTION_ASSIST con 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] È MOLTO CONSIGLIATO includere un accelerometro a 3 assi.

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

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

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

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

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

• [7.3.4/H-3-1] DEVE essere in grado di registrare eventi fino a una frequenza minima di 100 Hz.
• [7.3.4/H-3-2] DEVE essere in grado di misurare le variazioni di orientamento fino a 1000 gradi al secondo.

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

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

Implementazioni dei dispositivi portatili:

• [7.3.11/H-SR-1] È MOLTO CONSIGLIATO supportare il sensore di posizione con 6 gradi di libertà.

Inizio dei nuovi requisiti per Android 15

• [7.4.3/H] DEVE includere il supporto per Bluetooth e Bluetooth LE.

Implementazioni di dispositivi portatili che includono il supporto del Bluetooth LE:

• [7.4.3/H-SR-1] È MOLTO CONSIGLIATO supportare l'estensione della lunghezza del pacchetto di dati Bluetooth LE.

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

Fine dei nuovi requisiti

Se i dispositivi supportano il protocollo Wi-Fi Neighbor Awareness Networking (NAN) dichiarando PackageManager.FEATURE_WIFI_AWARE e la posizione Wi-Fi (Wi-Fi Round Trip Time - RTT) dichiarando PackageManager.FEATURE_WIFI_RTT, allora:

• [7.4.2.5/H-1-1] DEVE indicare con precisione l'intervallo con un margine di +/-1 metro a una larghezza di banda di 160 MHz al 68° percentile (come calcolato con la funzione di distribuzione cumulativa), +/-2 metri a una larghezza di banda di 80 MHz al 68° percentile, +/-4 metri a una larghezza di banda di 40 MHz al 68° percentile e +/-8 metri a 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] È FORTEMENTE CONSIGLIATO di indicare la copertura con precisione entro +/-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 Android WifiRttManager#startRanging.

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

Se le implementazioni dei dispositivi palmari dichiarano FEATURE_BLUETOOTH_LE:

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

Se le implementazioni dei dispositivi portatili includono una fotocamera logica che elenca le funzionalità che utilizzano CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA:

• [7.5.4/H-1-1] PER IMPOSTAZIONE PREDEFINITA DEVE avere un campo visivo (FOV) normale e DEVE essere compreso tra 50 e 60 gradi.

Implementazioni dei dispositivi portatili:

• [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 è disponibile meno di 1 GB di memoria per il kernel e lo spazio utente.

Se le implementazioni dei dispositivi palmari dichiarano il supporto di un'ABI solo 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 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 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 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 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 di 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 di almeno 944 MB se il display predefinito utilizza risoluzioni 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 di almeno 1280 MB se il display predefinito utilizza risoluzioni 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 di almeno 1824 MB se il display predefinito utilizza risoluzioni framebuffer fino a QHD (ad es. QWXGA).

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

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

• [7.6.1/H-9-1] È OBBLIGATORIO 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 dei dispositivi palmari includono più di 1 GB di memoria disponibile per il kernel e lo spazio utente, devono:

• [7.6.1/H-10-1] DEVE avere almeno 4 GB 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 dei dispositivi palmari includono più di 2 GB e meno di 4 GB di memoria disponibile per il kernel e lo spazio utente, devono:

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

Se le implementazioni dei dispositivi palmari includono meno di 2 GB di memoria a disposizione del kernel e dello spazio utente,

• [7.6.1/H-1-1] DEVE supportare un solo ABI (solo 64 bit o solo 32 bit).

Implementazioni dei dispositivi portatili:

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

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi portatili includono una porta USB supportata con un controller in modalità periferica, devono:

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

Fine dei nuovi requisiti

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

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

Implementazioni dei dispositivi portatili:

• [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 dei dispositivi portatili sono in grado di soddisfare tutti i requisiti di prestazioni per supportare la modalità VR e includono il supporto per questa modalità, devono:

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

Se le implementazioni dei dispositivi portatili 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 software dei codici HID:

Funzione	Mappature	Contesto	Comportamento
A	Pagina di utilizzo HID: 0x0C Utilizzo HID: 0x0CD Chiave del kernel: KEY_PLAYPAUSE Chiave Android: KEYCODE_MEDIA_PLAY_PAUSE	Riproduzione di contenuti multimediali	Input: pressione breve Output: riproduzione o messa in pausa
			Input: pressione prolungata Output: avvia il comando vocale Invia:android.speech.action.VOICE_SEARCH_HANDS_FREE se il dispositivo è bloccato o lo schermo è spento. Inviaandroid.speech.RecognizerIntent.ACTION_WEB_SEARCH in caso contrario
		Chiamata in arrivo	Input: pressione breve Output: accetta chiamata
			Input: pressione prolungata Output: Rifiuta chiamata
		Chiamata in corso	Input: pressione breve Output: termina chiamata
			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 prolungata 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 prolungata Output: riduce il volume del sistema o delle cuffie
D	Pagina di utilizzo HID: 0x0C Utilizzo HID: 0x0CF Chiave del kernel: KEY_VOICECOMMAND Chiave Android: KEYCODE_VOICE_ASSIST	Tutti. Può essere attivato in qualsiasi istanza.	Input: pressione breve o prolungata Output: avvia il comando vocale

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

Quando vengono rilevati i tipi di terminali audio USB 0x0302:

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

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

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

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

• [7.8.2.2/H-4-1] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e il ruolo isSink() se il campo del tipo di terminale audio USB è 0x0302.

• [7.8.2.2/H-4-2] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e il 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 il ruolo isSource() se il campo del tipo di terminale audio USB è 0x0402.

• [7.8.2.2/H-4-4] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_DEVICE e il 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 il 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 il ruolo isSink() se il campo del tipo di terminale audio USB è 0x400.

• [7.8.2.2/H-4-7] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_DEVICE e il 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.

Inizio dei nuovi requisiti per Android 15

Se per le implementazioni su dispositivi palmari che dichiarano android.hardware.audio.output e android.hardware.microphone, devono: consultare i requisiti RTL e TTL nella sezione 5.6.

• [5.6/H-1-1] DEVE avere una latenza media di andata e ritorno continua di 300 millisecondi o meno su 5 misurazioni, con una deviazione assoluta media inferiore a 30 ms, sui seguenti percorsi dati: "altoparlante a microfono", adattatore loopback da 3,5 mm (se supportato), loopback USB (se supportato).

• [5.6/H-1-2] DEVE avere una latenza media Tap-to-tone di 300 millisecondi o meno su almeno 5 misurazioni sul percorso di dati dall'altoparlante al microfono.

Fine dei nuovi requisiti

Un attuatore a risonanza lineare (LRA) è un sistema a molla monomassa con una frequenza di risonanza dominante in cui la massa si traduce nella direzione del movimento desiderato.

Se le implementazioni dei dispositivi palmari includono almeno un attuatore resonante lineare 7.10 per uso generale, devono:

• [7.10/H] L'attuatore DEVE essere posizionato vicino al punto in cui il dispositivo viene solitamente tenuto o toccato con le mani.

• [7.10/H] DEVE spostare l'attuatore aptico sull'asse X (da sinistra a destra) dell'orientamento naturale del dispositivo.

Se le implementazioni dei dispositivi portatili dispongono di un attuatore aptico generico che è un attuatore a risonanza lineare (LRA) sull'asse X, devono:

• [7.10/H] LA frequenza di risonanza dell'LRA sull'asse X DEVE essere inferiore a 200 Hz.

Se le implementazioni dei dispositivi portatili seguono la mappatura delle costanti di aptica, queste:

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

• [7.10/H]* DEVE verificare e aggiornare, se necessario, la configurazione di riserva per le primitive non supportate come descritto nelle linee guida per l'implementazione per le costanti.

2.2.2. Multimediale

Le implementazioni dei dispositivi portatili 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 (AAC a basso ritardo migliorato)

Le implementazioni dei dispositivi portatili 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 portatili 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 dei dispositivi portatili:

• [3.2.3.1/H-0-1] DEVE avere un'app che gestisce 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 una o più applicazioni o componenti di servizio con un gestore di intent per tutti i pattern di filtri di intent pubblici definiti dai seguenti intent di applicazione elencati qui.
• [3.2.3.1/H-SR-1] È FORTEMENTE consigliato di precaricare un'applicazione email che possa gestire gli intent ACTION_SENDTO, ACTION_SEND o ACTION_SEND_MULTIPLE per inviare un'email.
• [3.4.1/H-0-1] È NECESSARIO 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 degli utenti generici.
• [3.8.1/H-SR-1] È FORTEMENTE CONSIGLIATO implementare un Avvio app predefinito che supporti il bloccaggio in-app di scorciatoie, widget e widgetFeatures.
• [3.8.1/H-SR-2] È FORTEMENTE CONSIGLIATO implementare un programma di avvio predefinito che fornisca accesso rapido alle scorciatoie aggiuntive fornite dalle app di terze parti tramite l'API ShortcutManager.
• [3.8.1/H-SR-3] È FORTEMENTE CONSIGLIATO includere un'app di avvio predefinita che mostri i badge per le icone delle app.
• [3.8.2/H-SR-1] È MOLTO CONSIGLIATO supportare i widget di 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 dinamiche.
• [3.8.3/H-0-3] DEVE supportare le notifiche heads-up.
• [3.8.3/H-0-4] DEVE includere una schermata di notifica, che offra all'utente la possibilità di controllare direttamente (ad es. rispondere, posticipare, ignorare, bloccare) le notifiche tramite elementi come pulsanti di azione o il pannello di controllo, come implementato in AOSP.
• [3.8.3/H-0-5] DEVE mostrare le scelte fornite tramite RemoteInput.Builder setChoices() nell'area notifiche.
• [3.8.3/H-SR-1] È FORTEMENTE CONSIGLIATO di mostrare la prima scelta fornita tramite RemoteInput.Builder setChoices() nella barra delle notifiche senza ulteriore interazione dell'utente.
• [3.8.3/H-SR-2] È FORTEMENTE CONSIGLIATO di mostrare tutte le opzioni 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] È FORTEMENTE CONSIGLIATO mostrare le azioni per le quali Notification.Action.Builder.setContextual è impostato su true in linea con le risposte visualizzate da Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR-1] È MOLTO CONSIGLIATO implementare un assistente sul dispositivo per gestire l'azione di assistenza.

Se le implementazioni dei dispositivi palmari supportano le notifiche MediaStyle:

• [3.8.3.1/H-SR-2] È FORTEMENTE CONSIGLIATO fornire un'affordance utente (ad esempio, un selettore di output) a cui accedere dall'UI di sistema che consenta agli utenti di passare da un percorso di media disponibile all'altro (ad esempio, dispositivi Bluetooth e percorsi forniti a MediaRouter2Manager) quando un'app pubblica una notifica MediaStyle con un token MediaSession.

Se le implementazioni del dispositivo, incluso il tasto di navigazione della funzione Recenti come dettagliato 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 dei dispositivi palmari supportano l'azione di assistenza, 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 mobili supportano conversation notifications e le raggruppano in una sezione separata dalle notifiche di avviso e silenziose non relative alle conversazioni, devono:

• [3.8.4/H-1-1]* DEVE mostrare le notifiche delle conversazioni prima di quelle non relative alle conversazioni, con l'eccezione delle notifiche dei servizi in primo piano in esecuzione e delle notifiche con importance:high.

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

• [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 mobili supportano una schermata di blocco sicura:

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

Se le implementazioni dei dispositivi mobili includono il supporto per le API ControlsProviderService e Control e consentono alle applicazioni di terze parti di pubblicare controlli dei dispositivi, devono:

• [3.8.16/H-1-1] È OBBLIGATORIO dichiarare il flag della funzionalità android.software.controls e impostarlo su true.
• [3.8.16/H-1-2] DEVE fornire all'utente un'affordance che gli consenta di aggiungere, modificare, selezionare e utilizzare i controlli del dispositivo preferiti tra quelli 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à per l'utente entro tre interazioni da un Avvio app predefinito.

• [3.8.16/H-1-4] DEVE mostrare con precisione in questa funzionalità per l'utente il nome e l'icona di ogni app di terze parti che fornisce controlli tramite l'API ControlsProviderService nonché eventuali campi specificati forniti dalle API Control.

• [3.8.16/H-1-5] DEVE fornire all'utente la possibilità di disattivare i controlli dei dispositivi per l'autenticazione non significativa designati dall'app tra i controlli registrati dalle applicazioni di terze parti tramite le API ControlsProviderService e Control Control.isAuthRequired.

• [3.8.16/H-1-6] Le implementazioni dei dispositivi devono rappresentare con precisione l'affordance utente come segue:

  • Se il dispositivo ha impostato config_supportsMultiWindow=true e l'app dichiara i metadati META_DATA_PANEL_ACTIVITY nella dichiarazione ControlsProviderService, incluso ComponentName di un'attività valida (come definito dall'API), l'app DEVE incorporare detta attività in questa funzionalità per l'utente.
  • Se l'app non dichiara i metadati META_DATA_PANEL_ACTIVITY, deve visualizzare i campi specificati forniti dall'API ControlsProviderService e 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 passare il valore dell'impostazione definito in [3.8.16/H-1-5] utilizzando EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS al momento dell'avvio dell'attività incorporata.

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

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

Se le implementazioni dei dispositivi palmari non sono in esecuzione in modalità di blocco delle attività, quando i contenuti vengono copiati nella clipboard:

• [3.8.17/H-1-1] È OBBLIGATORIO mostrare all'utente una conferma che i dati sono stati copiati nella clipboard (ad es. una miniatura o un avviso "Contenuti copiati"). Inoltre, includi qui un'indicazione se i dati degli appunti verranno sincronizzati tra i dispositivi.

Implementazioni dei dispositivi portatili:

• [3.10/H-0-1] DEVE supportare i servizi di accessibilità di terze parti.
• [3.10/H-SR-1] È FORTEMENTE CONSIGLIATO di precaricare sul dispositivo servizi di accessibilità paragonabili o superiori alla funzionalità dei servizi di accessibilità Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato) come indicato nel progetto open source talkback.
• [3.11/H-0-1] DEVE supportare l'installazione di motori di sintesi vocale 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 delle Impostazioni rapide.

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

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

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

• [7.2.3/H] La zona di riconoscimento dei gesti per la funzione Casa NON DEVE essere più alta di 32 dp dal fondo dello schermo.

Se le implementazioni dei dispositivi portatili 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 ciascun lato. L'area dei gesti DEVE avere una larghezza di 24 dp per impostazione predefinita.

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

• [3.9/H-1-2] È OBBLIGATORIO dichiarare il supporto dei profili gestiti tramite il android.software.managed_usersfeature flag.

Se le implementazioni dei dispositivi 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à di immagine fissa come descritto nell'SDK.
• [7.5.4/H-1-2] DEVE rispettare l'intent android.media.action.VIDEO_CAMERA per avviare la fotocamera in modalità video come descritto nell'SDK.

Se l'applicazione delle impostazioni dell'implementazione del dispositivo implementa una funzionalità divisa, utilizzando l'inserimento di attività, allora:

• [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 suddivisione è 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] È OBBLIGATORIO dichiarare il flag funzionalità android.software.telecom.
• [7.4.1.2/H-0-2] È OBBLIGATORIO implementare il framework per le telecomunicazioni.

2.2.4. Prestazioni e potenza

• [8.1/H-0-1] Latenza dei fotogrammi costante. La latenza dei frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più spesso di 5 frame al secondo e DEVE essere inferiore a 1 frame al secondo.
• [8.1/H-0-2] Latenza dell'interfaccia utente. Le implementazioni dei dispositivi DEVONO garantire un'esperienza utente a bassa latenza scorrendo un elenco di 10.000 voci come definito dal Compatibility Test Suite (CTS) di Android in meno di 36 secondi.
• [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 DOVESSE richiedere meno di 1 secondo.

Implementazioni dei dispositivi portatili:

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

Se le implementazioni dei dispositivi portatili includono funzionalità per migliorare la gestione della potenza del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP, devono:

• [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 esenti dalle modalità di risparmio energetico App Standby e Sospensione.

Implementazioni dei dispositivi portatili:

• [8.4/H-0-1] È NECESSARIO fornire un profilo di alimentazione per componente che definisce il valore di consumo corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto Android Open Source.
• [8.4/H-0-2] È OBBLIGATORIO segnalare tutti i valori di consumo di corrente in milliampere ora (mAh).
• [8.4/H-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID del processo. 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 di energia tramite il comando shell adb shell dumpsys batterystats per lo sviluppatore dell'app.
• [8,4/H] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.

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

• [8.4/H-1-1] DEVE rispettare lo scopo android.intent.action.POWER_USAGE_SUMMARY e mostrare un menu delle impostazioni che mostri questo consumo di energia.

Implementazioni dei dispositivi portatili:

• [8.5/H-0-1] DEVE fornire un'affordance 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'avvio, come descritto nel documento dell'SDK.

• [8.5/H-0-2]DEVE fornire all'utente un'opzione per interrompere un'app in cui è in esecuzione un servizio in primo piano o un job avviato dall'utente.

2.2.5. Modello di sicurezza

Implementazioni dei dispositivi portatili:

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

Inizio dei nuovi requisiti per Android 15

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

• [9/H-0-2] DEVE rispettare l'intent android.settings.CREDENTIAL_PROVIDER per consentire la selezione di un fornitore preferito per Credential Manager. 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 2 fornitori di credenziali contemporaneamente e fornire un'affordance utente nell'app Impostazioni per attivare o disattivare i fornitori.

Fine dei nuovi requisiti

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.telephony,

• [9.5/H-1-1] NON DEVE impostare UserManager.isHeadlessSystemUserMode su true.

Implementazioni dei dispositivi portatili:

• [9.11/H-0-2] È NECESSARIO eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
• [9.11/H-0-3] DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni hash di famiglie 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 sui livelli superiori. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi tramite i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto Android Open Source (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti 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 se l'autenticazione è andata a buon fine, deve consentire l'utilizzo delle chiavi legate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto open source Android upstream fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.

Inizio dei nuovi requisiti per Android 15

• [9.11/H-0-5] DEVE supportare l'attestazione della chiave in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficiente di dispositivi per impedire che le chiavi siano utilizzate come identificatori di dispositivi permanenti. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

  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, potrebbe essere utilizzata una chiave diversa per ogni gruppo di 100.000 unità. In alternativa, la soluzione di provisioning delle chiavi da remoto può essere utilizzata per eseguire il provisioning di chiavi di attestazione di breve durata sul dispositivo.

Fine dei nuovi requisiti

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione delle chiavi, a meno che non dichiari la funzionalità android.hardware.fingerprint che richiede un keystore supportato da un ambiente di esecuzione isolato.

Quando le implementazioni dei dispositivi mobili 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 o inferiore a 15 secondi.
• [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 dei dispositivi dispongono di una schermata di blocco sicura e includono uno o più agenti di attendibilità che implementano l'API di sistema TrustAgentService:

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

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

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

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

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

Se le implementazioni dei dispositivi palmari impostano UserManager.isHeadlessSystemUserMode su true,

• [9.5/H-4-1] NON DEVE includere il supporto per le eUICC né per le eSIM con funzionalità di chiamata.
• [9.5/H-4-2] NON DEVE dichiarare il supporto per android.hardware.telephony.

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

Inizio dei nuovi requisiti per Android 15

Impostazioni con limitazioni

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

• Essere installate dopo essere state scaricate 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.
• È stata installata da un file locale (ad esempio, l'applicazione è stata caricata lateralmente) identificata da PackageManager come PACKAGE_SOURCE_LOCAL_FILE.

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

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

Implementazioni dei dispositivi:

• [9.8/H-0-1] È OBBLIGATORIO implementare le impostazioni con limitazioni come descritto sopra per quanto segue:

  • 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 in base all'utilizzo (AppOpsManager.OPSTR_GET_USAGE_STATS)
  • Ruoli (app predefinite)
    • Telefono (RoleManager.ROLE_DIALER)
    • SMS (RoleManager.ROLE_SMS)
  • Autorizzazioni di runtime
    • Tempo di esecuzione dell'SMS (Manifest.permission_group.SMS)

• [9.8/H-0-2] È OBBLIGATORIO attivare le Impostazioni limitate come impostazione predefinita ed è MOLTO CONSIGLIATO di non avere alcuna funzionalità che consenta all'utente di disattivare le Impostazioni limitate per tutte le applicazioni.

• [9.8/H-0-3] È NECESSARIO assicurarsi di ottenere la conferma dell'utente per ogni applicazione coperta prima che sia possibile concedere una delle autorizzazioni applicate.

• [9.8/H-0-4] DEVE consentire solo la conferma dell'utente per attivare le impostazioni con limitazioni da ottenere dalla pagina AppInfo dell'applicazione coperta, utilizzando l'API EnhancedConfirmationManager.

• [9.8/H-0-5] È FORTEMENTE CONSIGLIATO di eseguire l'integrazione e chiamare EnhancedConfirmationManager per tutte le autorizzazioni speciali per determinare dinamicamente se si tratta di un'impostazione limitata.

  • 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 i contenuti multimediali: AppOpsManager.OPSTR_MANAGE_MEDIA
  • Modifica le impostazioni di 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 in base all'utilizzo: AppOpsManager.OPSTR_GET_USAGE_STATS
  • Amministratore dispositivo: Manifest.permission.BIND_DEVICE_ADMIN
  • Non disturbare: Manifest.permission.MANAGE_NOTIFICATIONS

Nota: il progetto Android Open Source (AOSP) upstream soddisfa questo requisito impostando config_enhancedConfirmationModeEnabled su true nel file di configurazione, e integrandosi con l'API EnhancedConfirmationManager.

Fine dei nuovi requisiti

Se le implementazioni dei dispositivi palmari supportano l'API SystemHotwordDetectionService o un altro meccanismo per il rilevamento della hotword senza indicare l'accesso al microfono:

• [9.8/H-1-1] DEVE assicurarsi che il servizio di rilevamento hotword possa trasmettere dati solo al Sistema, a 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 hotword possa trasmettere al server di sistema solo i dati audio del microfono o i dati derivati 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 della hotword.
• [9.8/H-1-4] NON DEVE fornire audio del microfono in buffer precedente a 8 secondi per una singola richiesta al servizio di rilevamento hotword.
• [9.8/H-1-5] NON DEVE fornire audio del microfono in buffer precedente a 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 gli stream audio) dal servizio di rilevamento hotword per ogni risultato positivo dell'hotword.
• [9.8/H-1-7] NON DEVE consentire la trasmissione di più di 5 bit di dati al di fuori del servizio di rilevamento hotword per ogni risultato di hotword negativa.
• [9.8/H-1-8] DEVE consentire la trasmissione di dati dal servizio di rilevamento delle hotword solo su una richiesta di convalida dell'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 hotword.
• [9.8/H-1-10] NON DEVONO essere visualizzati nell'interfaccia utente i dati quantitativi sull'utilizzo del microfono da parte del servizio di rilevamento della hotword.
• [9.8/H-1-11] È OBBLIGATORIO registrare il numero di byte inclusi in ogni trasmissione dal servizio di rilevamento hotword per consentire l'ispezione da parte dei ricercatori di sicurezza.
• [9.8/H-1-12] DEVE supportare una modalità di debug che registri i contenuti non elaborati di ogni trasmissione dal servizio di rilevamento delle hotword per consentire l'ispezione da parte dei ricercatori in materia 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 corretto viene trasmesso al servizio di interazione vocale o a un'entità simile.

• [9.8/H-1-15] DEVE garantire che gli stream audio forniti in base ai risultati positivi della hotword vengono trasmessi in un'unica direzione dal servizio di rilevamento di hotword al servizio di interazione vocale.

• [9.8/H-SR-1] È FORTEMENTE CONSIGLIATO di informare gli utenti prima di impostare un'applicazione come fornitore del servizio di rilevamento della hotword.

• [9.8/H-SR-2] È FORTEMENTE CONSIGLIATO di non consentire la trasmissione di dati non strutturati dal servizio di rilevamento della hotword.

• [9.8/H-SR-3] È FORTEMENTE CONSIGLIATO riavviare il processo che ospita il servizio di rilevamento hotword almeno una volta ogni ora o ogni 30 eventi di attivazione hardware, a seconda del caso.

Se le implementazioni del dispositivo includono un'applicazione che utilizza l'API SystemHotwordDetectionService o un meccanismo simile per il rilevamento delle hotword senza indicare l'utilizzo del microfono, l'applicazione:

• [9.8/H-2-1] È OBBLIGATORIO fornire all'utente una notifica esplicita per ogni frase hotword supportata.
• [9.8/H-2-2] NON DEVE conservare i dati audio non elaborati o i dati derivati tramite il servizio di rilevamento hotword.
• [9.8/H-2-3] NON DEVONO essere trasmessi dal servizio di rilevamento della hotword dati audio, dati che possono essere utilizzati per ricostruire (totalmente o parzialmente) l'audio o contenuti audio non correlati alla hotword stessa, tranne che al servizio di riconoscimento vocale ContentCaptureService o on-device.

Se le implementazioni dei dispositivi palmari supportano l'API SystemVisualQueryDetectionService o un altro meccanismo per il rilevamento delle query senza indicazione dell'accesso al microfono e/o alla fotocamera:

• [9.8/H-3-1] DEVE assicurarsi che il servizio di rilevamento delle query possa trasmettere i 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 a un servizio di riconoscimento vocale sul dispositivo.
• [9.8/H-3-3] DEVE mostrare una notifica utente nell'interfaccia utente di sistema quando il dispositivo rileva l'intenzione dell'utente di interagire con l'applicazione di assistente digitale (ad es.rilevando la presenza dell'utente tramite la videocamera).
• [9.8/H-3-4] DEVE mostrare un indicatore del microfono e la query dell'utente rilevata nell'interfaccia utente subito dopo il rilevamento della query dell'utente.
• [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 dei 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 del 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 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 con interfacce utente visibili o interazione diretta con l'utente.
• [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 dei dispositivi palmari dichiarano android.hardware.camera.any:

• [9.8.2/H-5-1] DEVE mostrare l'indicatore della videocamera quando un'app accede ai dati in tempo reale della videocamera, ma non quando la videocamera viene acceduta solo dalle 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 fotocamera come restituito 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 diretta con l'utente.

Inizio dei nuovi requisiti per Android 15

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] È NECESSARIO verificare tutte le partizioni di sola lettura mounted durante la sequenza di avvio di Android e il digest VBMeta deve includere tutte queste partizioni verificate nel calcolo.

Nota: se le implementazioni dei dispositivi sono già state lanciate su una versione precedente di Android e non è possibile aggiungere il supporto per questi requisiti con un aggiornamento del software di sistema, i dispositivi POTREBBERO essere esentati dai requisiti.

Fine dei nuovi requisiti

2.2.6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori

Implementazioni di dispositivi portatili (* non applicabile ai tablet):

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

Inizio dei nuovi requisiti per Android 15

Implementazioni di dispositivi portatili (* Non applicabile per i tablet):

• Perfetto
  • [6.1/H-0-2]* DEVE esporre un file /system/bin/perfetto binario all'utente della shell la cui cmdline sia conforme a la documentazione di perfetto.
  • [6.1/H-0-3]* Il file binario di perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
  • [6.1/H-0-4]* Il file binario di 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 codice binario di perfetto, almeno le origini dati descritte nella documentazione di perfetto.
  • [6.1/H-0-6]* Il daemon di monitoraggio di perfetto DEVE essere attivato per impostazione predefinita (proprietà di sistema persist.traced.enable).

Fine dei nuovi requisiti

2.2.7. Classe di rendimento multimediale per dispositivi portatili

Consulta la sezione 7.11 per la definizione della classe di rendimento medio.

2.2.7.1. Contenuti multimediali

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.U per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• DEVE soddisfare i requisiti relativi ai contenuti multimediali elencati nella sezione 2.2.7.1 del CDD di Android 14.

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.V per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS,

Fine dei nuovi requisiti

• [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().

Inizio dei nuovi requisiti per Android 15

• [5.1/H-1-2] DEVE supportare 6 istanze di sessioni di decodifica video hardware a 8 bit (SDR) (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente con 3 sessioni a una risoluzione di 1080p a 30 fps e 3 sessioni a una risoluzione di 4K a 30 fps. Per tutte le sessioni, NON DEVONO essere persi più di 1 frame al secondo. I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30fps.

Fine dei nuovi requisiti

• [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().

Inizio dei nuovi requisiti per Android 15

• [5.1/H-1-4] DEVE supportare 6 istanze di sessioni di codifica video hardware a 8 bit (SDR) (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente con 4 sessioni a una risoluzione di 1080p a 30 fps e 2 sessioni a una risoluzione di 4K a 30 fps. Per tutte le sessioni, NON DEVONO essere persi più di 1 frame al secondo. I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30fps.

Fine dei nuovi requisiti

• [5.1/H-1-5] DEVE pubblicizzare il numero massimo di sessioni di codifica e decodifica video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().

Inizio dei nuovi requisiti per Android 15

• [5.1/H-1-6] DEVE supportare 6 istanze di decodificatore video hardware a 8 bit (SDR) e sessioni di codifica video hardware (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 3 sessioni a una risoluzione di 4K a 30 fps, di cui al massimo 2 sono sessioni di codifica e 3 sessioni a una risoluzione di 1080p. Per tutte le sessioni, NON DEVONO essere persi più di 1 frame al secondo. I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30fps.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

• [5.1/H-1-19] DEVE supportare 3 istanze di decodifica video hardware a 10 bit (HDR) e sessioni di codifica video hardware (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a una risoluzione di 4K a 30 fps di cui al massimo 1 è una sessione di codifica, che può essere configurata in formato di input RGBA_1010102 tramite una superficie GL. Per tutte le sessioni, NON DEVONO essere persi più di 1 fotogramma al secondo. La generazione di metadati HDR da parte dell'encoder non è necessaria se la codifica avviene dalla superficie GL. Le sessioni del codec AV1 devono supportare solo la risoluzione 1080p, anche se questo requisito prevede il 4K.

Fine dei nuovi requisiti

• [5.1/H-1-7] DEVE avere una latenza di inizializzazione del codec pari o inferiore a 40 ms per una sessione di codifica video a 1080p o inferiore per tutti i codificatori video hardware sotto carico. Per carico si intende una sessione di transcodifica simultanea da 1080p a 720p solo video che utilizza codec video hardware insieme all'inizializzazione della registrazione audio-video a 1080p. Per il codec Dolby Vision, la latenza di inizializzazione del codec DEVE essere pari o inferiore a 50 ms.
• [5.1/H-1-8] DEVE avere una latenza di inizializzazione del codec non superiore a 30 ms per una sessione di codifica audio con una velocità in bit di 128 Kbps o inferiore per tutti i codificatori audio in caso di carico. Per carico si intende una sessione di transcodifica simultanea da 1080p a 720p solo video che utilizza codec video hardware insieme all'inizializzazione della registrazione audio-video a 1080p.

Inizio dei nuovi requisiti per Android 15

• [5.1/H-1-9] DEVE supportare 2 istanze di sessioni di decodifica video hardware sicure (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a una risoluzione di 1080p a 30 fps sia per i contenuti a 8 bit (SDR) sia per quelli HDR a 10 bit. Per tutte le sessioni, NON DEVONO essere persi più di 1 frame al secondo.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

• [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) in qualsiasi combinazione di codec in esecuzione contemporaneamente con 3 sessioni a una risoluzione di 4K a 30 fps, che include una sessione di decodifica sicura e una sessione non sicura a una risoluzione di 1080p a 30 fps, in cui al massimo 2 sessioni possono essere in HDR a 10 bit. Per tutte le sessioni, NON DEVONO essere persi più di 1 frame al secondo. Le sessioni del codec AV1 devono supportare la risoluzione 1080p anche se questo requisito prevede il 4K.

Fine dei nuovi requisiti

• [5.1/H-1-11] DEVE supportare un decodificatore sicuro per ogni decodificatore hardware AVC, HEVC, VP9 o AV1 sul dispositivo.
• [5.1/H-1-12] DEVE avere una latenza di inizializzazione del codec pari o inferiore a 40 ms per una sessione di decodifica video di 1080p o inferiore per tutti i decodificatori video hardware quando sotto carico. Per carico si intende una sessione di transcodifica solo video da 1080p a 720p in contemporanea che utilizza codec video hardware insieme all'inizializzazione della riproduzione audio-video a 1080p. Per il codec Dolby Vision, la latenza di inizializzazione del codec DEVE essere pari o inferiore a 50 ms.
• [5.1/H-1-13] DEVE avere una latenza di inizializzazione del codec non superiore a 30 ms per una sessione di decodifica audio con una velocità in bit di 128 Kbps o inferiore per tutti i decodificatori audio in caso di carico. Per carico si intende una sessione di transcodifica simultanea da 1080p a 720p solo video che utilizza codec video hardware insieme all'inizializzazione della riproduzione audio-video a 1080p.

Inizio dei nuovi requisiti per Android 15

• [5.1/H-1-14] DEVE supportare il decodificatore hardware AV1 Main 10, Livello 4.1 e la grana della pellicola con l'effetto grana della pellicola sulla composizione GPU.

Fine dei nuovi requisiti

• [5.1/H-1-15] DEVE avere almeno 1 decodificatore video hardware che supporti 4K60.
• [5.1/H-1-16] È NECESSARIO avere almeno 1 codificatore video hardware che supporti 4K60.

Inizio dei nuovi requisiti per Android 15

• [5.1/H-1-21] DEVE supportare FEATURE_DynamicColorAspect per tutti i decodificatori video hardware (AVC, HEVC, VP9, AV1 o versioni successive). Nota: ciò significa che le applicazioni possono aggiornare gli aspetti cromatici dei contenuti video durante la sessione di decodifica. I decodificatori che supportano contenuti a 10 e 8 bit DEVONO supportare il passaggio dinamico tra contenuti a 8 e 10 bit in modalità Surface. I decodificatori che supportano la funzione di trasferimento HDR DEVONO supportare il passaggio dinamico tra contenuti SDR e HDR.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

• [5.1/H-1-22] DEVE supportare la codifica, la decodifica, l'editing con GPU e la visualizzazione di contenuti video in formato verticale, indipendentemente dai metadati di rotazione, per la risoluzione massima supportata dalla videocamera o per il 4K, a seconda del valore più basso. Nota: sono inclusi i profili HDR se il codec supporta l'HDR. I codec AV1 devono supportare solo la risoluzione 1080p. Questo requisito riguarda solo i codec hardware, la GPU e la DPU.

Fine dei nuovi requisiti

• [5.3/H-1-1] NON DEVE perdere più di 1 fotogramma in 10 secondi (ovvero meno del 0,167% di perdita di fotogrammi) per una sessione video 4K a 60 fps sotto carico.
• [5.3/H-1-2] NON DEVE perdere più di 1 fotogramma in 10 secondi durante una variazione della risoluzione video in una sessione video a 60 fps sotto carico per una sessione 4K.
• [5.6/H-1-1] DEVE avere una latenza tap-to-tone di massimo 80 millisecondi utilizzando il test tap-to-tone di CTS Verifier.
• [5.6/H-1-2] DEVE avere una latenza audio di andata e ritorno non superiore a 80 millisecondi su almeno un percorso dati supportato.
• [5.6/H-1-3] DEVE supportare audio >= 24 bit per l'uscita stereo tramite jack audio da 3,5 mm, se presenti, e tramite audio USB, se supportato, nell'intero percorso dei dati per configurazioni di streaming e bassa latenza. Per la configurazione a bassa latenza, AAudio deve essere utilizzato dall'app in modalità di callback a bassa latenza. Per la configurazione di streaming, l'app deve utilizzare un AudioTrack Java. Sia nelle configurazioni a bassa latenza che in quelle di streaming, l'output sink HAL deve accettare AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT o AUDIO_FORMAT_PCM_FLOAT come formato di output target.

Inizio dei nuovi requisiti per Android 15

• [5.6/H-1-4] DEVE supportare dispositivi audio USB con almeno 4 canali. (viene utilizzato dai controller DJ per ascoltare l'anteprima dei brani).

Fine dei nuovi requisiti

• [5.6/H-1-5] DEVE supportare i dispositivi MIDI conformi alla classe e dichiarare il flag della funzionalità MIDI.
• [5.6/H-1-9] DEVE supportare il missaggio di almeno 12 canali. Ciò implica la possibilità di aprire un AudioTrack con una maschera di canali 7.1.4 e di eseguire correttamente la spatializzazione o il downmix di tutti i canali in stereo.
• [5.6/H-SR] È FORTEMENTE CONSIGLIATO supportare il missaggio a 24 canali con almeno il supporto delle maschere di canale 9.1.6 e 22.2.
• [5.7/H-1-2] DEVE supportare MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL con le seguenti funzionalità di decrittografia dei contenuti.

Dimensione minima del campione	4 MiB
Numero minimo di sottocampioni - H264 o HEVC	32
Numero minimo di sottocampioni - VP9	9
Numero minimo di sottocampioni - AV1	288
Dimensioni minime del buffer del sottocampione	1 MiB
Dimensione minima del buffer di crittografia generica	500 KiB
Numero minimo di sessioni simultanee	30
Numero minimo di chiavi per sessione	20
Numero totale minimo di chiavi (tutte le sessioni)	80
Numero totale minimo di chiavi DRM (tutte le sessioni)	6
Dimensioni del messaggio	16 KiB
Frame al secondo decriptati	60 fps

• [5.1/H-1-17] DEVE avere almeno 1 decodificatore di immagini hardware che supporti il profilo di base AVIF.
• [5.1/H-1-18] DEVE supportare il codificatore AV1 che può codificare fino a una risoluzione di 480p a 30 fps e 1 Mbps.

Inizio dei nuovi requisiti per Android 15

• [5.1/H-1-20] DEVE supportare la funzionalità Feature_HdrEditing per tutti i codificatori hardware AV1 e HEVC presenti sul dispositivo a una risoluzione 4K o alla risoluzione massima supportata dalla fotocamera, a seconda del valore più basso.

Fine dei nuovi requisiti

• [5.12/H-SR] Sono vivamente consigliati per supportare la funzionalità Feature_HdrEditing per tutti i codificatori AV1 e HEVC hardware presenti sul dispositivo.
• [5.12/H-1-2] DEVE supportare il formato di colore RGBA_1010102 per tutti i codificatori hardware AV1 e HEVC presenti sul dispositivo.
• [5.12/H-1-3] È OBBLIGATORIO pubblicizzare il supporto dell'estensione EXT_YUV_target per eseguire il campionamento dalle texture YUV sia a 8 che a 10 bit.
• [7.1.4/H-1-1] DEVE avere almeno 6 overlay hardware nell'unità di elaborazione display (DPU), di cui almeno 2 in grado di visualizzare contenuti video a 10 bit.

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi portatili restituiscono android.os.Build.VERSION_CODES.V per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS e includono il supporto di un codificatore hardware AVC o HEVC, devono:

Fine dei nuovi requisiti

• [5.2/H-2-1] DEVE soddisfare il target di qualità minimo definito dalle curve di rapporto di distorsione del codificatore video per i codec hardware AVC e HEVC, come definito in Esegui test di classe di prestazioni 14 (PC14) - Qualità di codifica video (VEQ).

2.2.7.2. Fotocamera

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.U per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• DEVE soddisfare i requisiti relativi ai contenuti multimediali elencati nella sezione 2.2.7.2 del CDD di Android 14.

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.V per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS,

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

• [7.5/H-1-1] DEVE avere una fotocamera posteriore principale con una risoluzione di almeno 12 megapixel che supporti l'acquisizione video a 4K@30fps, 1080p@60fps e 720p@60fps. La fotocamera posteriore principale è la fotocamera posteriore con l'ID più basso.

Fine dei nuovi requisiti

• [7.5/H-1-2] DEVE avere una fotocamera anteriore principale con una risoluzione di almeno 6 megapixel e supportare l'acquisizione video a 1080p a 30 fps. La fotocamera anteriore principale è la fotocamera anteriore con l'ID più basso.
• [7.5/H-1-3] DEVE supportare la proprietà android.info.supportedHardwareLevel come FULL o superiore per la fotocamera principale posteriore e LIMITED o superiore per la fotocamera principale anteriore.
• [7.5/H-1-4] DEVE supportareCameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME per entrambe le camere principali.
• [7.5/H-1-5] DEVE avere una latenza di acquisizione JPEG della fotocamera 2 inferiore a 1000 ms per una risoluzione di 1080p, misurata dal test di prestazioni della fotocamera CTS in condizioni di illuminazione ITS (3000 K) per entrambe le fotocamere principali.
• [7.5/H-1-6] È NECESSARIO che la latenza di avvio della fotocamera 2 (dall'apertura della fotocamera al primo frame di anteprima) sia inferiore a 500 ms, misurata dal test di prestazioni della fotocamera CTS in condizioni di illuminazione ITS (3000 K) per entrambe le fotocamere principali.
• [7.5/H-1-8] DEVE supportare CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW e android.graphics.ImageFormat.RAW_SENSOR per la fotocamera posteriore principale.
• [7.5/H-1-9] DEVE avere una fotocamera principale posteriore che supporti 720p o 1080p a 240 f/s.
• [7.5/H-1-10] È NECESSARIO che ZOOM_RATIO minimo sia inferiore a 1,0 per le fotocamere principali se è presente una fotocamera RGB ultrawide rivolta nella stessa direzione.
• [7.5/H-1-11] È OBBLIGATORIO implementare lo streaming simultaneo anteriore e posteriore sulle fotocamere principali.
• [7.5/H-1-12] DEVE supportareCONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION sia per la fotocamera frontale sia per la fotocamera posteriore principale.
• [7.5/H-1-13] DEVE supportare la funzionalità LOGICAL_MULTI_CAMERA per la fotocamera posteriore principale se sono presenti più di una fotocamera RGB posteriore.
• [7.5/H-1-14] DEVE supportare la funzionalità STREAM_USE_CASE sia per la fotocamera frontale principale sia per la fotocamera posteriore principale.
• [7.5/H-1-15] DEVE supportare le estensioni della modalità Notte sia tramite le estensioni CameraX sia tramite le estensioni Camera2 per le fotocamere principali.
• [7.5/H-1-16] DEVE supportare la funzionalità DYNAMIC_RANGE_TEN_BIT per le camere principali.
• [7.5/H-1-17] DEVE supportare CONTROL_SCENE_MODE_FACE_PRIORITY e il rilevamento dei volti (STATISTICS_FACE_DETECT_MODE_SIMPLE o STATISTICS_FACE_DETECT_MODE_FULL) per le fotocamere principali.

Inizio dei nuovi requisiti per Android 15

• [7.5/H-1-18] DEVE supportare JPEG_R per le fotocamere anteriori e posteriori principali.
• [7.5/H-1-19] DEVE supportare CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION per l'anteprima HLG10 1080p con JPEG con proporzioni 16:9 di dimensioni massime e per l'anteprima HLG10 720p con JPEG con proporzioni 16:9 di dimensioni massime per la fotocamera posteriore principale.
• [7.5/H-1-20] PER IMPOSTAZIONE PREDEFINITA DEVE produrre JPEG_R per le fotocamere frontale e posteriore principali nell'app Fotocamera nativa.

Fine dei nuovi requisiti

2.2.7.3. Hardware

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.U per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS,

• DEVE soddisfare i requisiti relativi ai contenuti multimediali elencati nella sezione 2.2.7.3 del CDD di Android 14.

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.V per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS,

Fine dei nuovi requisiti

• [7.1.1.1/H-2-1] DEVE avere una risoluzione dello schermo di almeno 1080p.

Inizio dei nuovi requisiti per Android 15

• [7.1.1.3/H-2-1] DEVE avere una densità dello schermo di almeno 400 dpi se la larghezza dello schermo del dispositivo è inferiore a 600 dp.

Fine dei nuovi requisiti

• [7.1.1.3/H-3-1] DEVE avere un display HDR che supporti almeno 1000 nits in media.

Inizio dei nuovi requisiti per Android 15

• [7.6.1/H-2-1] DEVE avere almeno 8 GB di memoria fisica, con almeno 6,64 GB disponibili per il kernel come indicato da android.app.ActivityManager.MemoryInfo.totalMem.

Fine dei nuovi requisiti

2.2.7.4. Prestazioni

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.U per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS,

• DEVE soddisfare i requisiti di rendimento elencati nella sezione 2.2.7.4 del CDD di Android 14.

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.V per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS,

Fine dei nuovi requisiti

• [8.2/H-1-1] DEVE garantire prestazioni di scrittura sequenziale di almeno 150 MB/s.
• [8.2/H-1-2] DEVE garantire prestazioni di scrittura casuale di almeno 10 MB/s.
• [8.2/H-1-3] DEVE garantire un rendimento di lettura sequenziale di almeno 250 MB/s.
• [8.2/H-1-4] DEVE garantire un rendimento di lettura casuale di almeno 100 MB/s.
• [8.2/H-1-5] DEVE garantire prestazioni di lettura e scrittura sequenziali parallele con prestazioni di lettura doppie e di scrittura pari a 1 di almeno 50 MB/s.

Inizio dei nuovi requisiti per Android 15

2.2.7.5. Grafica

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.V per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• [7.1.4.1/H-1-2] DEVE supportare le estensioni EGL_IMG_context_priority e EGL_EXT_protected_content.
• [7.1.4.1/H-1-3] DEVE supportare VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory e VK_KHR_global_priority.

Fine dei nuovi requisiti

2.3. Requisiti della TV

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

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

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

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

2.3.1. Hardware

Implementazioni dei 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 della funzionalità android.hardware.gamepad.
• [7.2.7/T] È necessario fornire un telecomando da cui gli utenti possono accedere ai comandi di navigazione non tocco e alle funzioni di navigazione di base.

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

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

Implementazioni dei 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:

• [7.5.3/T-1-1] DEVE includere il supporto di 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 extra large

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 extra large

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 del dispositivo.

Implementazioni dei 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. Multimediale

Le implementazioni dei dispositivi TV 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] Profilo MPEG-4 HE AAC (AAC+)
• [5.1/T-0-3] AAC ELD (AAC a basso ritardo migliorato)

Le implementazioni dei dispositivi TV 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 dei 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 TV 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 TV DEVONO supportare la decodifica MPEG-2, come descritto nella sezione 5.3.1, a frequenze fotogrammi e risoluzioni video standard fino a:

• [5.3.1/T-1-1] HD 1080p a 29,97 fotogrammi al secondo con profilo principale di livello elevato.
• [5.3.1/T-1-2] HD 1080i a 59,94 fotogrammi al secondo con profilo principale di alto livello. Devono deinterlacciare il video MPEG-2 interlacciato e renderlo disponibile per le applicazioni di terze parti.

Le implementazioni dei dispositivi TV DEVONO supportare la decodifica H.264, come descritto nella sezione 5.3.4, a frequenze fotogrammi e risoluzioni video standard fino a:

• [5.3.4/T-1-1] HD 1080p a 60 fotogrammi al secondo con profilo di base
• [5.3.4/T-1-2] HD 1080p a 60 fotogrammi al secondo con profilo principale
• [5.3.4/T-1-3] HD 1080p a 60 fotogrammi al secondo con livello High Profile 4.2

Le implementazioni di dispositivi TV con decodificatori hardware H.265 DEVONO supportare la decodifica H.265, come descritto nella Sezione 5.3.5, a frequenze frame video standard e risoluzioni fino a:

• [5.3.5/T-1-1] 1080p HD a 60 frame al secondo con livello del profilo principale 4.1

Se le implementazioni dei dispositivi TV con decodificatori 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 di livello 5 del livello principale

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

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

Le implementazioni di dispositivi TV con decodificatori hardware VP9 DEVONO supportare la decodifica VP9, come descritto nella Sezione 5.3.7, a frequenze frame video standard e risoluzioni fino a:

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

Se le implementazioni dei dispositivi TV con decodificatori 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 fotogrammi al secondo con il profilo 0 (profondità colore di 8 bit).
• [5.3.7/T-SR1] È FORTEMENTE CONSIGLIATO supportare il profilo di decodifica UHD a 60 fotogrammi al secondo con il profilo 2 (profondità di colore di 10 bit).

Implementazioni dei dispositivi TV:

• [5.5/T-0-1] DEVE includere il supporto per il volume master del sistema e l'attenuazione del volume dell'uscita audio digitale sulle uscite supportate, tranne per l'uscita passthrough audio compresso (dove non viene eseguita alcuna decodifica audio sul dispositivo).

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

• [5.8/T-0-1] È NECESSARIO impostare la modalità di uscita HDMI sulla risoluzione più elevata per il formato pixel scelto che funzioni 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] È FORTEMENTE CONSIGLIATO di 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 TV non hanno un display integrato, ma supportano un display esterno collegato tramite HDMI, devono:

• [5.8/T-1-1] DEVE supportare HDCP 2.2.

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

• [5.8/T-2-1] DEVE supportare HDCP 1.4

2.3.3. Software

Implementazioni dei dispositivi TV:

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

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

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

Implementazioni dei dispositivi TV:

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

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

Inizio dei nuovi requisiti per Android 15

Implementazioni dei dispositivi TV:

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

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

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

Implementazioni dei dispositivi TV:

• [3/T-0-2] È OBBLIGATORIO 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 di terze parti basati su TIF possa essere installata e utilizzata sul dispositivo.

Il Android Television Tuner Framework (TF) uniforma la gestione dei contenuti dal vivo 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 Android Television Tuner.

Se le implementazioni dei dispositivi supportano Tuner:

• [3/T-1-1] DEVE supportare tutte le API di Tuner Framework in modo che un'app che utilizza queste API possa essere installata e utilizzata sul dispositivo.

Fine dei nuovi requisiti

2.3.4. Prestazioni e potenza

• [8.1/T-0-1] Latenza dei frame costante. La latenza dei frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più spesso di 5 frame al secondo e DEVE essere inferiore a 1 frame al secondo.
• [8.2/T-0-1] DEVE garantire prestazioni di scrittura sequenziale di almeno 5 MB/s.
• [8.2/T-0-2] DEVE garantire prestazioni di scrittura random di almeno 0,5 MB/s.
• [8.2/T-0-3] DEVE garantire un rendimento di lettura sequenziale di almeno 15 MB/s.
• [8.2/T-0-4] DEVE garantire un rendimento di lettura random di almeno 3,5 MB/s.

Se le implementazioni dei dispositivi TV includono funzionalità per migliorare la gestione della potenza del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP, devono:

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

Se le implementazioni dei dispositivi TV non hanno una batteria:

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

Se le implementazioni dei dispositivi TV dispongono di una batteria:

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

Implementazioni dei dispositivi TV:

• [8.4/T-0-1] DEVE fornire un profilo di alimentazione per componente che definisce il valore di consumo corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
• [8.4/T-0-2] È OBBLIGATORIO segnalare tutti i valori di consumo di corrente in milliampere ora (mAh).
• [8.4/T-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID del processo. 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 il consumo di energia del componente hardware a un'applicazione.
• [8.4/T-0-4] È OBBLIGATORIO rendere disponibile questo utilizzo di energia tramite il comando shell adb shell dumpsys batterystats per lo sviluppatore dell'app.

2.3.5. Modello di sicurezza

Implementazioni dei dispositivi TV:

• [9/T-0-1] DEVE dichiarare la funzionalità android.hardware.security.model.compatible.
• [9.11/T-0-1] È NECESSARIO eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
• [9.11/T-0-2] DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni hash di famiglie 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 sui livelli superiori. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi tramite i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto Android Open Source (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura 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 se l'autenticazione è andata a buon fine, deve consentire l'utilizzo delle chiavi legate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto open source Android upstream fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.

Inizio dei nuovi requisiti per Android 15

• [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 DEVONO essere condivise su un numero sufficiente di dispositivi per impedire che le chiavi siano utilizzate come identificatori di dispositivi permanenti. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

  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, potrebbe essere utilizzata una chiave diversa per ogni gruppo di 100.000 unità. In alternativa, la soluzione di provisioning delle chiavi da remoto può essere utilizzata per eseguire il provisioning di chiavi di attestazione di breve durata sul dispositivo.

Fine dei nuovi requisiti

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione delle chiavi, a meno che non dichiari la funzionalità android.hardware.fingerprint che richiede un keystore supportato da un ambiente di esecuzione isolato.

Se le implementazioni dei dispositivi TV 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 TV includono più utenti e non dichiarano il flag della funzionalità android.hardware.telephony,

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

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

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

Se le implementazioni dei dispositivi TV 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 con interfacce utente visibili o interazione diretta con l'utente.

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

• [9.8.2/T-5-1] DEVE mostrare l'indicatore della videocamera quando un'app accede ai dati della videocamera in diretta, ma non quando la videocamera è solo accessa dalle 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 della fotocamera per le app di sistema con interfacce utente visibili o interazione diretta con l'utente.

2.3.6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori

Inizio dei nuovi requisiti per Android 15

Implementazioni dei dispositivi TV:

• Perfetto
  • [6.1/T-0-1] DEVE esporre un file /system/bin/perfetto binario all'utente della shell la cui cmdline sia conforme alla documentazione di perfetto.
  • [6.1/T-0-2] Il file binario di perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
  • [6.1/T-0-3] Il file binario di 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 codice binario di perfetto, almeno le origini dati descritte nella documentazione di perfetto.
  • [6.1/T-0-5] Il daemon di monitoraggio di perfetto deve essere attivato per impostazione predefinita (proprietà di sistema persist.traced.enable).

Fine dei nuovi requisiti

2.4. Requisiti dell'orologio

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

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

• Avere uno schermo con una diagonale fisica compresa tra 28 e 64 mm.
• Disporre di un meccanismo che consenta di indossarlo sul corpo.

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

2.4.1. Hardware

Guarda le implementazioni dei dispositivi:

• [7.1.1.1/W-0-1] DEVE avere uno schermo con le dimensioni diagonali fisiche comprese tra 2,8 e 6,35 cm.

• [7.2.3/W-0-1] DEVE avere la funzione Home disponibile per l'utente e la funzione Indietro, tranne quando è in UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] DEVE supportare l'input touchscreen.

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

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

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

Se le implementazioni dei dispositivi indossabili includono un giroscopio a 3 assi, devono:

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

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

Nessun altro requisito.

2.4.3. Software

Guarda le implementazioni dei dispositivi:

• [3/W-0-1] È OBBLIGATORIO 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] È obbligatorio caricare in anteprima una o più applicazioni o componenti di servizio con un gestore intent per tutti i pattern di filtri per intent pubblici definiti dai seguenti intent di applicazione elencati qui.

Guarda le implementazioni dei dispositivi:

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

Guarda le implementazioni dei dispositivi che dichiarano il flag della 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 di precaricare sul dispositivo servizi di accessibilità paragonabili o superiori alla funzionalità dei servizi di accessibilità Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato) come indicato nel talkback open source project.

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

• [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 smartwatch includono funzionalità per migliorare la gestione della potenza del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP, devono:

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

Guarda le implementazioni dei dispositivi:

• [8.4/W-0-1] È OBBLIGATORIO fornire un profilo di alimentazione per componente che definisce il valore di consumo corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
• [8.4/W-0-2] È OBBLIGATORIO segnalare tutti i valori di consumo di corrente in milliampere ora (mAh).
• [8.4/W-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID del processo. 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 utilizzo di energia tramite il comando shell adb shell dumpsys batterystats per lo sviluppatore dell'app.
• [8,4/W] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia 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 dei dispositivi indossabili includono più utenti e non dichiarano il flag della funzionalità android.hardware.telephony,

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

Se le implementazioni dei dispositivi indossabili includono più utenti e dichiarano il flag della funzionalità android.hardware.telephony,

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

Se le implementazioni dei dispositivi dispongono di una schermata di blocco sicura e includono uno o più agenti di attendibilità che implementano l'API di sistema TrustAgentService:

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

2.5. Requisiti per il settore auto e motori

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

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

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

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

2.5.1. Hardware

Implementazioni di dispositivi per auto e motori:

• [7.1.1.1/A-0-1] DEVE avere uno schermo con dimensioni fisiche diagonali di almeno 15,2 cm.
• [7.1.1.1/A-0-2] DEVE avere un layout delle dimensioni dello schermo almeno di 750 dp x 480 dp.

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi per auto e motori supportano il multiutente simultaneo (in cui più utenti Android possono interagire con il dispositivo contemporaneamente, ciascuno utilizzando il proprio display quando config_multiuserVisibleBackgroundUsers è abilitato), devono:

• [7.1.1.1/A-1-1] DEVE avere uno schermo separato di almeno 15 cm di diagonale fisica per ogni zona per il display principale. Deve essere contrassegnato come CarOccupantZoneManager.DISPLAY_TYPE_MAIN per ogni zona occupante.
• [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.

Fine dei nuovi requisiti

Se le implementazioni dei dispositivi per auto e motori supportano OpenGL ES 3.1:

• [7.1.4.1/A-0-1] È OBBLIGATORIO 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.

Implementazioni di dispositivi per auto e motori:

Inizio dei nuovi requisiti per Android 15

• [7.1.7/A-0-1] È OBBLIGATORIO configurare display secondari nel campo visivo del conducente come FLAG_PRIVATE.

Fine dei nuovi requisiti

• [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 NIGHT_MODE flag DEVE essere coerente con la modalità giorno/notte della dashboard e DEVE essere basato sull'input del sensore di luce ambientale. Il sensore di luce ambientale sottostante POTREBBE essere lo stesso del fotometro.

• [7.3/A-0-3] È OBBLIGATORIO fornire il campo delle informazioni aggiuntive del sensore TYPE_SENSOR_PLACEMENT all'interno di SensorAdditionalInfo per ogni sensore fornito.

• [7.3/A-SR1] PUÒ calcolare la posizione mediante il calcolo approssimativo combinando il GPS/GNSS con sensori aggiuntivi. Se la posizione viene calcolata in base alla navigazione stimata, è FORTEMENTE CONSIGLIATO di implementare e registrare i tipi di sensore corrispondenti e/o gli ID proprietà del veicolo 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 dei sensori auto di Android.

• [7.3/A-SR-1] È MOLTO_CONSIGLIATO includere un accelerometro e un giroscopio a tre assi.

• [7.3/A-SR-2] È MOLTO_CONSIGLIATO implementare e segnalare il sensoreTYPE_HEADING.

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi per auto e motori supportano il multiutente simultaneo (in cui più utenti Android possono interagire con il dispositivo contemporaneamente, ciascuno utilizzando il proprio display quando config_multiuserVisibleBackgroundUsers è abilitato), devono:

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

Fine dei nuovi requisiti

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

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

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

• [7.3.1/A-SR-1] È VIVAMENTE CONSIGLIATO di implementare il sensore composito per accelerometro ad assi limitati.

Se le implementazioni dei dispositivi per auto e motori includono un accelerometro con meno di 3 assi:

• [7.3.1/A-1-3] È OBBLIGATORIO implementare e segnalare il sensoreTYPE_ACCELEROMETER_LIMITED_AXES.
• [7.3.1/A-1-4] È OBBLIGATORIO implementare e segnalare il sensoreTYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Se le implementazioni dei dispositivi per auto includono un giroscopio:

• [7.3.4/A-2-1] DEVE essere in grado di registrare eventi fino a una frequenza minima di 100 Hz.
• [7.3.4/A-2-3] DEVE essere in grado di misurare le variazioni di orientamento fino a 250 gradi al secondo.
• [7.3.4/A-SR-1] È FORTEMENTE CONSIGLIATO configurare l'intervallo di misurazione del giroscopio su +/-250 giri/s per massimizzare la risoluzione possibile.

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

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

Se le implementazioni dei dispositivi per auto e motori includono un giroscopio con meno di 3 assi:

• [7.3.4/A-4-1] È OBBLIGATORIO implementare e segnalare il sensoreTYPE_GYROSCOPE_LIMITED_AXES.
• [7.3.4/A-4-2] È OBBLIGATORIO implementare e segnalare il sensoreTYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Se le implementazioni dei dispositivi per auto e motori includono un ricevitore GPS/GNSS, ma non includono la connettività dati basata su rete mobile, devono:

• [7.3.3/A-3-1] DEVE determinare la posizione la prima volta che il ricevitore GPS/GNSS viene acceso o dopo più di 4 giorni entro 60 secondi.
• [7.3.3/A-3-2] DEVE soddisfare i criteri di tempo di risposta iniziale come descritto in 7.3.3/C-1-2 e 7.3.3/C-1-6 per tutte le altre richieste di posizione (ovvero le richieste che non sono la prima volta o dopo più di 4 giorni). Il requisito 7.3.3/C-1-2 viene solitamente soddisfatto nei veicoli senza connettività dati basata su rete mobile, utilizzando le previsioni dell'orbita GNSS calcolate sul ricevitore o utilizzando l'ultima posizione nota del veicolo insieme alla possibilità di eseguire la navigazione stimata per almeno 60 secondi con una precisione della posizione che soddisfa 7.3.3/C-1-3 o una combinazione di entrambi.

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

• [7.3.4/A-4-3] DEVE essere in grado di registrare eventi con una frequenza minima di 1 Hz.
• [7.3.4/A-SR-3] È MOLTO_CONSIGLIATO registrare gli eventi fino a una frequenza di almeno 10 Hz.
• DEVE fare riferimento al nord geografico.
• DOVREBBE essere disponibile anche quando il veicolo è fermo.
• DEVE avere una risoluzione di almeno 1 grado.

Implementazioni di dispositivi per auto e motori:

• [7.4.3/A-0-1] DEVE supportare il Bluetooth e DEVE 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 Audio Distribution (A2DP).
  • Controllo della riproduzione multimediale tramite il profilo di controllo remoto (AVRCP).
  • Condivisione dei contatti tramite il profilo Phonebook Access (PBAP).

Inizio dei nuovi requisiti per Android 15

• [7.4.3/A-SR-1] È FORTEMENTE CONSIGLIATO supportare il profilo di accesso ai messaggi (MAP) se il dispositivo ha la zona occupante del conducente.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi per auto e motori supportano il multiutente simultaneo (in cui più utenti Android possono interagire con il dispositivo contemporaneamente, ciascuno utilizzando il proprio display quando config_multiuserVisibleBackgroundUsers è abilitato), devono:

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

Fine dei nuovi requisiti

Implementazioni di dispositivi per auto e motori:

• [7.4.5/A] DEVE includere il supporto per la connettività dati basata sulla rete cellulare.
• [7.4.5/A] PUO' utilizzare la costante NetworkCapabilities#NET_CAPABILITY_OEM_PAID dell'API System 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, devono:

• [7.4/A-1-1] È OBBLIGATORIO dichiarare il supporto di FEATURE_BROADCAST_RADIO.

Per fotocamera posteriore si intende una fotocamera rivolta verso l'esterno che può essere posizionata in qualsiasi punto del veicolo ed è rivolta verso l'esterno dell'abitacolo, ovvero acquisisce immagini delle scene sul lato opposto della carrozzeria, come la fotocamera di retrovisione.

Per fotocamera anteriore si intende una fotocamera rivolta verso l'utente che può essere posizionata in qualsiasi punto del veicolo ed è rivolta verso l'interno dell'abitacolo, ovvero acquisisce le immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.

Implementazioni di dispositivi per auto e motori:

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

Se le implementazioni dei dispositivi per auto e motori includono almeno una fotocamera rivolta verso l'esterno, per questa fotocamera:

• [7.5/A-1-1] DEVE essere orientato in modo che la dimensione lunga della fotocamera sia allineata con il piano XY degli assi del sensore Android Automotive.
• [7.5/A-SR-3] È FORTEMENTE CONSIGLIATO avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
• [7.5/A-1-2] DEVE avere la fotocamera posteriore principale come fotocamera con ID più basso.

Se le implementazioni dei dispositivi per auto e motori includono almeno una videocamera rivolta all'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 più basso.
• Può essere orientata in modo che la dimensione lunga della fotocamera sia allineata al piano X-Y degli assi del sensore Android Automotive.

Se le implementazioni dei dispositivi per auto e motori includono una videocamera accessibile tramite l'API android.hardware.Camera o android.hardware.camera2, devono:

• [7.5/A-3-1] DEVE essere conforme ai requisiti di base della fotocamera riportati nella sezione 7.5.

Se le implementazioni dei dispositivi per auto e motori includono una fotocamera non accessibile tramite l'API android.hardware.Camera o android.hardware.camera2, devono:

• [7.5/A-4-1] DEVE essere accessibile tramite il servizio del sistema di visualizzazione estesa.

Se le implementazioni dei dispositivi per auto e motori includono una o più videocamere accessibili tramite il servizio di sistema di visualizzazione estesa, per queste videocamere:

• [7.5/A-5-1] NON deve ruotare o rispecchiare orizzontalmente l'anteprima della fotocamera.
• [7.5/A-SR-4] È FORTEMENTE CONSIGLIATO avere una risoluzione di almeno 1,3 megapixel.

Se le implementazioni dei dispositivi per auto e motori includono una o più videocamere accessibili sia tramite il Servizio di sistema di visualizzazione estesa sia tramite l'API android.hardware.Camera o android.hardware.Camera2, per una videocamera di questo tipo:

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

Se le implementazioni dei dispositivi per auto e motori forniscono un'API di fotocamera proprietaria:

• [7.5/A-7-1] DEVE implementare un'API di questo tipo utilizzando l'API android.hardware.camera2 o l'API Extended View System.

Implementazioni di dispositivi per auto e motori:

• [7.6.1/A-0-1] DEVE avere almeno 4 GB di archiviazione non volatile a disposizione per i dati privati dell'applicazione (partizione /data).

• [7.6.1/A] DEVE formattare la partizione dei dati per offrire prestazioni e longevità migliorate sullo spazio di archiviazione flash (ad esempio, utilizzando il file system f2fs).

Se le implementazioni dei dispositivi Automotive forniscono spazio di archiviazione esterno condiviso tramite una parte dello spazio di archiviazione interno non rimovibile:

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

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi per auto e motori supportano il multiutente simultaneo (in cui più utenti Android possono interagire con il dispositivo contemporaneamente, ciascuno utilizzando il proprio display quando config_multiuserVisibleBackgroundUsers è abilitato), devono:

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

Fine dei nuovi requisiti

Se le implementazioni dei dispositivi per auto e motori sono a 64 bit:

Inizio dei nuovi requisiti per Android 15

• [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 extra large
  • 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 extra large

• [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 extra large

• [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 di grandi dimensioni
  • xhdpi o superiore su schermi extra large

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

Fine dei nuovi requisiti

Implementazioni di dispositivi per auto e motori:

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

Implementazioni di dispositivi per auto e motori:

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

Implementazioni di dispositivi per auto e motori:

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

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi per auto e motori supportano il multiutente simultaneo (in cui più utenti Android possono interagire con il dispositivo contemporaneamente, ciascuno utilizzando il proprio display quando config_multiuserVisibleBackgroundUsers è abilitato), devono:

• [7.8.2/A-1-1] DEVE essere presente un dispositivo di output audio per ogni display principale per i sistemi con più utenti contemporaneamente.
• [7.8.2/A-1-2] È OBBLIGATORIO avere una zona audio del conducente che copra lo speaker della cabina globale. La zona del passeggero anteriore può condividere la zona audio del conducente o avere una propria uscita audio.

Fine dei nuovi requisiti

2.5.2. Multimediale

Le implementazioni dei dispositivi per auto e motori 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 (AAC a basso ritardo migliorato)

Le implementazioni dei dispositivi per auto e motori 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 dei dispositivi per auto e motori 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

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

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

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi per auto e motori supportano il multiutente simultaneo (in cui più utenti Android possono interagire con il dispositivo contemporaneamente, ciascuno utilizzando il proprio display quando config_multiuserVisibleBackgroundUsers è abilitato), devono:

• [5.5.3/A-1-1] È OBBLIGATORIO definire curve di volume identiche per tutti gli stream di output audio che mappano allo stesso gruppo di volume come definito nel file di configurazione dell'impianto audio dell'auto.

Fine dei nuovi requisiti

2.5.3. Software

Implementazioni di dispositivi per auto e motori:

• [3/A-0-1] È OBBLIGATORIO dichiarare la funzionalitàandroid.hardware.type.automotive.

• [3/A-0-2] DEVE supportare uiMode = UI_MODE_TYPE_CAR.

• [3/A-0-3] DEVE supportare tutte le API pubbliche nello spazio dei nomi android.car.*.

Se le implementazioni dei dispositivi per auto e motori forniscono un'API proprietaria che utilizza android.car.CarPropertyManager con android.car.VehiclePropertyIds:

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

Implementazioni di dispositivi per auto e motori:

• [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 auto e motori.

• [3.2.3.1/A-0-1] È obbligatorio precaricare una o più applicazioni o componenti di servizio con un gestore degli intent per tutti i pattern di filtro degli intent pubblici definiti dai seguenti intent di applicazione elencati qui.

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

Inizio dei nuovi requisiti per Android 15

• [3.8/A-0-1] NON DEVE consentire agli utenti secondari completi che non sono l'utente corrente in primo piano di avviare attività e avere accesso all'interfaccia utente su tutti i display.

Se le implementazioni dei dispositivi per auto e motori supportano il multiutente simultaneo (in cui più utenti Android possono interagire con il dispositivo contemporaneamente, ciascuno utilizzando il proprio display quando config_multiuserVisibleBackgroundUsers è abilitato), devono:

• [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 che hanno accesso all'interfaccia utente del display assegnato. L'elenco di UserRestrictions è costituito da: DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE e DISALLOW_MICROPHONE_TOGGLE.

• [3.8/A-1-2] NON DEVONO consentire agli utenti secondari con accesso completo che non sono l'utente in primo piano corrente, ma 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 (incluse Luminosità, Luce notturna, Scala di grigi di Benessere digitale e Riduci colori brillanti) per qualsiasi altro utente tramite Impostazioni o da un'API.

Fine dei nuovi requisiti

Implementazioni di dispositivi per auto e motori:

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

• [3.8.4/A-SR-1] È vivamente consigliato implementare un assistente sul dispositivo per gestire l'azione di assistenza.

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

• [3.8.4/A-1-1] È OBBLIGATORIO utilizzare una breve pressione del pulsante push-to-talk come interazione designata per avviare l'app di assistenza selezionata dall'utente, in altre parole l'app che implementa VoiceInteractionService.

Implementazioni di dispositivi per auto e motori:

• [3.8.3.1/A-0-1] DEVE visualizzare correttamente le risorse come descritto nella documentazione dell'SDK Notifications on Automotive OS.
• [3.8.3.1/A-0-2] DEVE mostrare FUNZIONA e SILENZIA per le azioni di notifica al posto di quelle fornite tramite Notification.Builder.addAction()
• [3.8.3.1/A] DEVE limitare l'uso di attività di gestione avanzate come i controlli per canale di notifica. PUO' utilizzare l'affordance utente per applicazione per ridurre i controlli.

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

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

Implementazioni di dispositivi per auto e motori:

• [3.14/A-0-1] DEVE includere un framework UI per supportare le app di terze parti che utilizzano le API multimediali come descritto nella sezione 3.14.
• [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 Intent implicita CAR_INTENT_ACTION_MEDIA_TEMPLATE con l'extra CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] DEVE fornire un'affordance per accedere all'attività di preferenze di un'applicazione multimediale, ma DEVE attivarla solo quando le limitazioni dell'esperienza utente dell'auto non sono in vigore.
• [3.14/A-0-5] DEVE mostrare messaggi di errore impostati da Media Applications e DEVE supportare gli extra facoltativi ERROR_RESOLUTION_ACTION_LABEL e ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] DEVE supportare un'affordance 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 mostra la gerarchia di MediaBrowser.

Se le implementazioni dei dispositivi per auto e motori includono un'app Avvio app predefinita:

• [3.14/A-1-1] DEVE includere i servizi multimediali e aprirli con l'intent CAR_INTENT_ACTION_MEDIA_TEMPLATE.

Implementazioni di dispositivi per auto e motori:

• [3.8/A] PUÒ limitare le richieste di applicazioni per passare a una modalità a schermo intero come descritto in immersive documentation.
• [3.8/A] PUO' mantenere sempre visibili la barra di stato e la barra di navigazione.
• [3.8/A] PUO' limitare le richieste di applicazione per modificare i colori dietro gli elementi dell'interfaccia utente di sistema, per garantire che questi elementi siano sempre chiaramente visibili.

2.5.4. Prestazioni e potenza

Implementazioni di dispositivi per auto e motori:

• [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 Systemandroid.car.storagemonitoring.CarStorageMonitoringManager. Android Open Source Project soddisfa il requisito tramite il modulo kernel uid_sys_stats.
• [8.3/A-1-3] DEVE supportare la modalità Garage.
• [8.3/A] DOVREBBE essere in modalità Garage per almeno 15 minuti dopo ogni viaggio, a meno che:
  • La batteria è scarica.
  • Non sono pianificati job inattivi.
  • Il conducente esce dalla modalità Garage.
• [8.4/A-0-1] È obbligatorio fornire un profilo di alimentazione per componente che definisce il valore di consumo corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
• [8.4/A-0-2] È OBBLIGATORIO segnalare tutti i valori di consumo di corrente in milliampere ora (mAh).
• [8.4/A-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID del processo. 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 il consumo di energia del componente hardware a un'applicazione.
• [8.4/A-0-4] DEVE rendere questo utilizzo di energia disponibile tramite il comando shell adb shell dumpsys batterystats allo sviluppatore dell'app.

2.5.5. Modello di sicurezza

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

• [9.5/A-1-1] NON DEVE consentire agli utenti di interagire con o di passare all'utente del sistema headless, tranne che per il 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 auto e motori dichiarano android.hardware.microphone,

• [9.8.2/A-1-1] DEVE mostrare l'indicatore del microfono quando un'app accede ai dati audio del 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 con identificatore CDD [C-4-X].
• [9.8.2/A-1-2] NON deve nascondere l'indicatore del microfono per le app di sistema con interfacce utente visibili o interazione diretta con l'utente.
• [9.8.2/A-1-3] DEVE fornire all'utente la possibilità di attivare/disattivare il microfono nell'app Impostazioni.

Se le implementazioni dei dispositivi per auto e motori dichiarano android.hardware.camera.any,

• [9.8.2/A-2-1] DEVE mostrare l'indicatore della videocamera quando un'app accede ai dati della videocamera in tempo reale, ma non quando la videocamera viene acceduta solo dalle app che detengono i ruoli come definiti nella Sezione 9.1 Autorizzazioni con identificatore CDD [C-4-X].
• [9.8.2/A-2-2] NON deve nascondere l'indicatore della fotocamera per le app di sistema con interfacce utente visibili o interazione diretta con l'utente.
• [9.8.2/A-2-3] È obbligatorio fornire all'utente un'affordance 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 auto e motori:

• [9/A-0-1] DEVE dichiarare la funzionalità android.hardware.security.model.compatible.
• [9.11/A-0-1] È NECESSARIO eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
• [9.11/A-0-2] DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni hash di famiglie 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 sui livelli superiori. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi tramite i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto Android Open Source (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti 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 se l'autenticazione è andata a buon fine, deve consentire l'utilizzo delle chiavi legate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto open source Android upstream fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.

Inizio dei nuovi requisiti per Android 15

• [9.11/A-0-4] DEVE supportare l'attestazione della chiave in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficiente di dispositivi per impedire che le chiavi siano utilizzate come identificatori di dispositivi permanenti. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

  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, potrebbe essere utilizzata una chiave diversa per ogni gruppo di 100.000 unità. In alternativa, la soluzione di provisioning delle chiavi da remoto può essere utilizzata per eseguire il provisioning di chiavi di attestazione di breve durata sul dispositivo.

Fine dei nuovi requisiti

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione delle chiavi, a meno che non dichiari la funzionalità android.hardware.fingerprint che richiede un keystore supportato da un ambiente di esecuzione isolato.

Implementazioni di dispositivi per auto e motori:

• [9.14/A-0-1] DEVE controllare i messaggi provenienti dai sottosistemi del veicolo del framework Android, ad esempio inserendo nella lista consentita i tipi di messaggi e le origini dei messaggi consentiti.
• [9.14/A-0-2] È obbligatorio il monitoraggio per difendersi dagli attacchi di denial of service dal framework Android o da app di terze parti. In questo modo, viene protetto il veicolo dal software dannoso che inonda la rete con traffico, il che potrebbe causare il malfunzionamento dei sottosistemi del veicolo.

2.5.6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori

Inizio dei nuovi requisiti per Android 15

Implementazioni di dispositivi per auto e motori:

• Perfetto
  • [6.1/A-0-1] DEVE esporre un file /system/bin/perfetto binario all'utente della shell la cui cmdline sia conforme alla documentazione di perfetto.
  • [6.1/A-0-2] Il file binario di perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
  • [6.1/A-0-3] Il file binario di 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 codice binario di perfetto, almeno le origini dati descritte nella documentazione di perfetto.
  • [6.1/A-0-5] Il daemon di monitoraggio di perfetto deve essere attivato per impostazione predefinita (proprietà di sistema persist.traced.enable).

Fine dei nuovi requisiti

2.6. Requisiti del tablet

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

• Da tenere con entrambe le mani.
• Non ha una configurazione a conchiglia o convertibile.
• Le implementazioni di tastiere fisiche utilizzate con il dispositivo si connettono tramite una connessione standard (ad es. USB, Bluetooth).

• Ha una fonte di alimentazione che offre mobilità, ad esempio una batteria.

• Ha uno schermo con dimensioni superiori a 7" e inferiori a 18", misurate in diagonale.

Le implementazioni dei tablet hanno requisiti simili a quelli dei dispositivi portatili. Le eccezioni sono indicate da un asterisco nella sezione corrispondente e riportate per riferimento in questa sezione.

2.6.1. Hardware

Giroscopio

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

• [7.3.4/Tab-1-1] DEVE essere in grado di misurare le variazioni 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 palmari non sono applicabili ai tablet.

Inizio dei nuovi requisiti per Android 15

Modalità periferica USB (sezione 7.7.1)

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

• [7.7.1/scheda] PUO' implementare l'API Android Open Accessory (AOA).

Fine dei nuovi requisiti

Modalità Realtà virtuale (sezione 7.9.1)

Realtà virtuale ad alte prestazioni (sezione 7.9.2)

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

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 della funzionalità android.hardware.telephony,

• [9.5/T-1-1] DEVE supportare i profili con limitazioni, una funzionalità che consente ai proprietari di dispositivi di gestire utenti aggiuntivi e le relative funzionalità sul dispositivo. Con i profili con limitazioni, i proprietari di dispositivi possono configurare rapidamente ambienti separati in cui lavorare per 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 della funzionalità android.hardware.telephony,

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

2.6.2. Software

• [3.2.3.1/Tab-0-1] DEVE precaricare una o più applicazioni o componenti di servizio con un gestore degli intent per tutti i pattern di filtro degli intent pubblici definiti dai seguenti intent di applicazione elencati qui.

3. Software

3.1. Compatibilità con le API gestite

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

Implementazioni dei dispositivi:

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

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

• [C-0-3] NON DEVE omettere API gestite, modificare interfacce o firme dell'API, discostarsi dal comportamento documentato o includere no-op, tranne dove specificamente consentito da questa definizione di compatibilità.

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

• [C-0-5] NON DEVE consentire alle app di terze parti di utilizzare interfacce non SDK, che sono definite come metodi e campi nei pacchetti di linguaggi Java presenti nel percorso di classe di avvio in AOSP e che non fanno parte dell'SDK pubblico. Sono incluse le API decorate con l'annotazione @hide, ma non con un @SystemAPI, come descritto nella documentazione dell'SDK e i membri di classe privati e privati del pacchetto.

• [C-0-6] DEVE essere fornito con ogni interfaccia non SDK negli stessi elenchi con limitazioni forniti tramite i flag provvisori e della lista negativa nel percorso prebuilts/runtime/appcompat/hiddenapi-flags.csv per il ramo del livello API appropriato in 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:

  • Può essere che, se un'API nascosta non è presente o è implementata in modo diverso nell'implementazione del dispositivo, l'API nascosta venga inserita nella lista negativa o omessa da tutti gli elenchi con limitazioni.
  • Può, se un'API nascosta non esiste già in AOSP, aggiungere l'API nascosta a uno degli elenchi con limitazioni.

Inizio dei nuovi requisiti per Android 15

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

Fine dei nuovi requisiti

3.1.1. Estensioni Android

Android supporta l'estensione dell'interfaccia 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 sono presenti estensioni per quel livello API.

Implementazioni dei dispositivi Android:

• [C-0-1] È NECESSARIO 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 dei dispositivi Android 7.0 con livello API 24 DEVONO includere almeno la versione 1.

• [C-0-2] DEVE restituire solo il numero di versione dell'estensione valido definito dall'AOSP.

• [C-0-3] DEVE supportare tutte le API definite dalle versioni dell'estensione riportate da android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) nello stesso modo in cui sono supportate le altre API gestite, seguendo i requisiti riportati nella sezione 3.1.

3.1.2. Libreria Android

A causa del ritiro del client HTTP Apache, le implementazioni dei dispositivi:

• [C-0-1] NON DEVE inserire la libreria org.apache.http.legacy nel bootclasspath.
• [C-0-2] È NECESSARIO aggiungere la libreria org.apache.http.legacy al percorso di classe dell'applicazione solo quando l'app soddisfa una delle seguenti condizioni:
  • Ha come target il livello API 28 o versioni precedenti.
  • Dichiara nel manifest di aver 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à soft delle API

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

3.2.1. Autorizzazioni

• [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 compilazione

Le API Android includono una serie di costanti nella classe android.os.Build destinate a descrivere il dispositivo corrente.

• [C-0-1] Per fornire valori coerenti e significativi per tutte le implementazioni dei dispositivi, la tabella seguente include ulteriori limitazioni relative ai formati di questi valori a cui le implementazioni dei dispositivi DEVONO essere conformi.

Parametro	Dettagli
VERSION.RELEASE	La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE avere uno dei valori di stringa definiti in Stringhe di versione consentite per Android 15.
VERSION.SDK	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 15, questo campo DEVE avere il valore intero 15_INT.
VERSION.SDK_INT	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 15, questo campo DEVE avere il valore intero 15_INT.
VERSION.INCREMENTAL	Un valore scelto dall'implementatore del dispositivo che designa la build specifica del sistema Android attualmente in esecuzione, in formato leggibile. Questo valore NON DEVE essere riutilizzato per build diverse rese disponibili agli utenti finali. Un uso tipico di questo campo è indicare il numero di build o l'identificatore della 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 deve corrispondere all'espressione regolare ^[a-zA-Z0-9_-]+$.
BRAND	Un valore che riflette il nome del brand associato al dispositivo, come noto agli utenti finali. DEVE essere in un formato leggibile e DEVE rappresentare il produttore del dispositivo o il brand dell'azienda con cui viene comercializado. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare ^[a-zA-Z0-9_-]+$.
ABI_SUPPORTATI	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con API native.
ABI_32_BIT_SUPPORTATI	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con API native.
ABI_64_BIT_SUPPORTATI	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con API native.
CPU_ABI	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con API native.
CPU_ABI2	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con API native.
DISPOSITIVO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice che identifica la configurazione delle funzionalità hardware e il design industriale del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare ^[a-zA-Z0-9_-]+$. Questo nome del dispositivo NON DEVE cambiare durante la vita utile del prodotto.
FINGERPRINT	Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile da una persona. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ad esempio: acme/myproduct/     mydevice:15/LMYXX/3359:userdebug/test-keys L'impronta NON DEVE includere caratteri di spazio vuoto. 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 da una persona. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare ^[a-zA-Z0-9_-]+$.
HOST	Una stringa che identifica in modo univoco l'host su cui è stata eseguita la compilazione della build, in formato leggibile. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
ID	Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica in formato leggibile da una persona. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere le build software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare^[a-zA-Z0-9._-]+$.
PRODUTTORE	La denominazione commerciale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota (""). Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.
SOC_MANUFACTURER	La denominazione commerciale del produttore del system on chip (SoC) principale utilizzato nel prodotto. I dispositivi dello stesso produttore di SoC devono utilizzare lo stesso valore costante. Rivolgiti al produttore del SoC per conoscere 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 e NON DEVE essere uguale a "unknown". Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.
SOC_MODEL	Il nome del modello del SoC (System on a Chip) principale utilizzato nel prodotto. I dispositivi con lo stesso modello 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 deve corrispondere all'espressione regolare ^([0-9A-Za-z ._/+-]+)$, NON DEVE iniziare o terminare con spazi e NON DEVE essere uguale a "unknown". Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.
MODELLO	Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo noto all'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota (""). Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.
PRODOTTO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice del prodotto specifico (SKU) che DEVE essere univoco all'interno dello stesso brand. DEVE essere leggibile, ma non necessariamente destinato alla visualizzazione da parte degli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e deve corrispondere all'espressione regolare ^[a-zA-Z0-9_-]+$. Il nome di questo prodotto NON DEVE cambiare durante la vita del prodotto.
ODM_SKU	Un valore facoltativo scelto dall'implementatore del dispositivo che contiene SKU (codice identificativo dell'articolo) utilizzato per monitorare configurazioni specifiche del dispositivo, ad esempio eventuali periferiche incluse 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.,_-]+)$.
SERIALE	DEVE restituire "UNKNOWN".
TAG	Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che consente di distinguere 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 della piattaforma Android tipicamente utilizzate: release-keys, dev-keys e test-keys.
DURATA	Un valore che rappresenta il timestamp della compilazione.
MACCHINA	Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondente alle tre configurazioni di runtime Android tipiche: user, userdebug o eng.
UTENTE	Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la compilazione. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
SECURITY_PATCH	Un valore che indica il livello della patch di sicurezza di una build. DEVE indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti nel Bollettino pubblico sulla sicurezza di Android designato. DEVE essere nel formato [AAAA-MM-GG], corrispondente a una stringa definita documentata nel Android Public Security Bulletin o nell' Android Security Advisory, ad esempio "2015-11-01".
BASE_OS	Un valore che rappresenta il parametro FINGERPRINT della build, che è altrimenti identico a questa build, tranne per le patch fornite nel bollettino Android Public Security. DEVE riportare il valore corretto e, se una build di questo tipo non esiste, deve riportare una stringa vuota ("").
BOOTLOADER	Un valore scelto dall'implementatore del dispositivo che identifica la versione specifica del bootloader interno utilizzata nel dispositivo, in formato leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare ^[a-zA-Z0-9._-]+$.
getRadioVersion()	DEVE (essere o restituire) un valore scelto dall'implementatore del dispositivo che identifica la versione specifica della radio/del modem interna utilizzata nel dispositivo, in formato leggibile. Se un dispositivo non ha radio/modem 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 per 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]+$.

3.2.3. Compatibilità con gli intent

3.2.3.1. Intent comuni delle applicazioni

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

Implementazioni dei dispositivi:

• [C-SR-1] È FORTEMENTE CONSIGLIATO di precaricare una o più applicazioni o componenti di servizio con un gestore degli intent per tutti i pattern di filtro degli intent pubblici definiti dai seguenti intent di applicazione elencati qui e fornire il completamento, ovvero soddisfare le aspettative degli sviluppatori per questi intent di applicazione comuni come descritto nell'SDK.

Consulta la Sezione 2 per gli intent di applicazione obbligatori per ciascun tipo di dispositivo.

3.2.3.2. Risoluzione dell'intent

• [C-0-1] Poiché Android è una piattaforma estensibile, le implementazioni dei dispositivi DEVONO consentire a ogni pattern di intent a cui si fa riferimento nella sezione 3.2.3.1, tranne per Impostazioni, di essere sostituito da applicazioni di terze parti. L'implementazione open source di Android upstream lo consente per impostazione predefinita.

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

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

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

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

• [C-0-4] DEVE tentare di convalidare tutti i filtri per intent eseguendo i passaggi di convalida definiti nella specifica Digital Asset Links come implementato dal gestore pacchetti nel progetto Android Open Source di 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.
• PUO' impostare filtri di intent URI specifici come gestori di app predefiniti per i propri URI, se vengono verificati correttamente, ma altri filtri URI candidati non superano la verifica. Se un'implementazione del dispositivo esegue questa operazione, DEVE fornire all'utente le sostituzioni dei pattern per URI appropriati nel menu delle impostazioni.
• DEVE fornire all'utente i controlli dei link dell'app per app nelle Impostazioni come segue:
  • [C-0-6] L'utente DEVE essere in grado di sostituire in modo olistico il comportamento predefinito dei link alle app per un'app: sempre aperto, sempre chiedi o mai aperto, che deve essere applicato allo stesso modo a tutti i filtri di intent URI candidati.
  • [C-0-7] L'utente DEVE essere in grado di visualizzare un elenco dei filtri di intent per URI candidati.
  • L'implementazione del dispositivo PUÒ fornire all'utente la possibilità di eseguire l'override di filtri di intent URI candidati specifici che sono stati verificati correttamente, in base al filtro di intent.
  • [C-0-8] L'implementazione del dispositivo DEVE fornire agli utenti la possibilità di visualizzare e sostituire filtri di intent URI candidati specifici se l'implementazione del dispositivo consente a alcuni filtri di intent URI candidati di superare la verifica, mentre altri possono non riuscirci.

3.2.3.3. Spazi dei nomi degli intent

• [C-0-1] Le implementazioni dei dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando un'azione, una categoria o un'altra stringa chiave nello spazio dei nomi android.* o com.android.*.
• [C-0-2] Gli implementatori di dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando ACTION, CATEGORY o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione.
• [C-0-3] Gli implementatori dei dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent elencati nella sezione 3.2.3.1.
• Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano spazi dei nomi associati chiaramente e in modo evidente alla propria organizzazione. Questo divieto è analogo a quello specificato per le classi di lingua Java nella sezione 3.6.

3.2.3.4. Intent di trasmissione

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

Implementazioni dei dispositivi:

• [C-0-1] DEVE trasmettere gli intent di trasmissione pubblica elencati qui in risposta a eventi di sistema appropriati come descritto nella documentazione dell'SDK. Tieni presente che questo requisito non è in conflitto con la sezione 3.5, poiché la limitazione per le applicazioni in background è descritta anche nella documentazione dell'SDK. 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 offrono agli utenti un modo semplice per selezionare le applicazioni predefinite, ad esempio per la schermata Home o gli SMS.

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

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

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

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

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

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

  • DEVE utilizzare l'interfaccia utente dell'app Telefono predefinita selezionata dall'utente per le chiamate in arrivo e in uscita, ad eccezione delle chiamate di emergenza, per le quali verrà utilizzata 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 il ConnectionServices associato al PhoneAccounts, nonché un PhoneAccount predefinito che il fornitore di servizi di telecomunicazioni utilizzerà per effettuare chiamate in uscita. L'implementazione AOSP soddisfa questo requisito includendo un menu "Opzione per gli account chiamate" nel menu delle impostazioni "Chiamate".

• [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 abbia 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] È FORTEMENTE CONSIGLIATO di gestire 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 tastiera precaricata in grado di gestire questi intent e fornire l'aggiornamento come descritto nell'SDK.

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

• [C-3-1] DEVE rispettare l'intent android.settings.NFC_PAYMENT_SETTINGS per mostrare un menu delle impostazioni dell'app predefinite per il pagamento 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 delle carte predefinito per una determinata categoria, come descritto nell'SDK.

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

• [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:

• [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 dei dispositivi 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 dei criteri di modalità Non disturbare.

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

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

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

• [C-8-1] DEVE rispettare l'android.settings.ACCESSIBILITY_SETTINGS 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.

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

• [C-9-1] È OBBLIGATORIO implementare le API di intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI come descritto nella documentazione dell'SDK.

Se le implementazioni dei dispositivi forniscono la modalità Risparmio dati, devono:

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

Se le implementazioni dei dispositivi non forniscono la modalità Risparmio dati, devono:

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

Se le implementazioni del dispositivo 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 dell'SDK.

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

• [C-13-1] DEVE rispettare l'intent android.app.action.ADD_DEVICE_ADMIN per richiamare un'interfaccia utente che guidi l'utente nell'aggiunta dell'amministratore del dispositivo al sistema (o per consentirgli di rifiutarlo).

• [C-13-2] DEVE rispettare gli intent 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 e avere un'attività per fornire il completamento di questi intent come descritto nell'SDK qui.

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

• [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 alle app di terze parti di accedere alle statistiche di utilizzo, devono:

• [C-SR-2] È FORTEMENTE 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 non vogliono consentire ad alcuna app, incluse quelle preinstallate, di accedere alle statistiche di utilizzo, devono:

• [C-15-1] DEVE comunque avere un'attività che gestisca il pattern di intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, ma DEVE implementarlo come un'operazione non eseguita, ovvero avere un comportamento equivalente a quello che si verifica quando all'utente viene negato l'accesso.

Se le implementazioni dei dispositivi mostrano link alle attività specificate da AutofillService_passwordsActivity in Impostazioni o link alle password utente tramite un meccanismo simile, devono:

• [C-16-1] DEVE mostrare questi link per tutti i servizi di compilazione automatica installati.

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'intenzione di android.settings.ACTION_VOICE_INPUT_SETTINGS di mostrare un menu delle impostazioni predefinite dell'app per l'input vocale e l'assistente.

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

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

Android include il supporto per i salvaschermo interattivi, precedentemente noti come Sogni. I salvaschermo consentono agli utenti di interagire con le applicazioni quando un dispositivo collegato a una fonte di alimentazione è inattivo o agganciato alla base di ricarica. Implementazioni del dispositivo:

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

Se le implementazioni dei dispositivi registrano 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" definito dalla specifica tecnica GSM Association TS.26 - NFC Handset Requirements).

3.2.4. Attività su display secondari/multipli

Se le implementazioni dei dispositivi consentono di avviare normali attività Android su più di un display, devono:

• [C-1-1] È NECESSARIO impostare il flag funzionalità android.software.activities_on_secondary_displays.
• [C-1-2] DEVE garantire la compatibilità con le API simile a un'attività in esecuzione sul display principale.
• [C-1-3] DEVE indirizzare la nuova attività sulla stessa visualizzazione dell'attività che lo ha avviato, quando la nuova attività viene avviata senza specificare una visualizzazione di destinazione tramite l'API ActivityOptions.setLaunchDisplayId().
• [C-1-4] DEVE distruggere tutte le attività quando viene rimosso un display con il flag Display.FLAG_PRIVATE.
• [C-1-5] 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 decida di essere visualizzata sopra la schermata di blocco utilizzando l'API Activity#setShowWhenLocked().
• DEVE avere android.content.res.Configuration che corrisponde a quel display per essere visualizzato, funzionare correttamente e mantenere la compatibilità se un'attività viene avviata sul display secondario.

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

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

3.3. Compatibilità con le API native

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

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

3.3.1. Application Binary Interface

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

Implementazioni dei dispositivi:

• [C-0-1] DEVE essere compatibile con una o più ABI Android NDK 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 dell'interfaccia nativa Java (JNI).
• [C-0-3] DEVE essere compatibile con il codice sorgente (ovvero con gli intestazioni) e con il codice binario (per l'ABI) di ogni libreria richiesta nell'elenco riportato di seguito.
• [C-0-5] DEVE segnalare con precisione l'interfaccia a bit di applicazione (ABI) nativa supportata dal dispositivo tramite i parametri android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, ciascuno costituito da un elenco di ABI separati da virgola ordinati dal più preferito al meno preferito.

Inizio dei nuovi requisiti per Android 15

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

Fine dei nuovi requisiti

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

  • libaaudio.so (supporto audio nativo AAudio)
  • libamidi.so (supporto MIDI nativo, se la funzionalità android.software.midi viene dichiarata come descritto nella Sezione 5.9)
  • libandroid.so (supporto delle attività native di Android)
  • libc (libreria C)
  • libcamera2ndk.so
  • libdl (linker dinamico)
  • libEGL.so (gestione delle superfici OpenGL native)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (logging Android)
  • libmediandk.so (supporto delle API multimediali native)
  • libm (libreria matematica)
  • 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] È OBBLIGATORIO elencare le librerie non AOSP aggiuntive esposte direttamente alle app di terze parti in /vendor/etc/public.libraries.txt.

• [C-0-10] NON DEVE esporre altre librerie native, implementate e fornite in AOSP come librerie di sistema, ad app di terze parti che hanno come target il livello API 24 o versioni successive, in quanto sono riservate.

• [C-0-11] DEVI esportare tutti i simboli delle funzioni OpenGL ES 3.1 e del pacchetto di estensioni Android, come definiti in NDK, tramite la libreria libGLESv3.so. Tieni presente che, anche se tutti i simboli DEVONO essere presenti, la sezione 7.1.4.1 descrive in modo più dettagliato i requisiti per l'implementazione completa di ciascuna funzione corrispondente.

• [C-0-12] È OBBLIGATORIO esportare i simboli di funzione per i simboli di funzione di base di Vulkan 1.1, nonché le estensioni VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 tramite la libreria libvulkan.so. Tieni presente che, sebbene tutti i simboli debbano essere presenti, la sezione 7.1.4.2 descrive in modo più dettagliato i requisiti per l'implementazione completa di ogni funzione corrispondente.

• DEVE essere compilato utilizzando il codice sorgente e i file di intestazione disponibili nel progetto Android Open Source upstream.

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

3.3.2. Compatibilità con il 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 segnalarne il supporto, poiché 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] DEVE includere le seguenti righe in /proc/cpuinfo e NON DEVE alterare i valori sullo stesso dispositivo, anche quando vengono letti da altri ABI.

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

• [C-2-2] DEVE mantenere sempre disponibili le seguenti operazioni, anche nel caso in cui l'ABI sia implementato su un'architettura ARMv8, tramite il supporto della CPU nativa o tramite l'emulazione software:

  • Istruzioni per SWP e SWPB.
  • Operazioni di barriere 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à con WebView

Se le implementazioni dei dispositivi forniscono un'implementazione completa dell'APIandroid.webkit.Webview, devono:

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

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

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

  • Il valore della stringa $(VERSION) DEVE essere uguale al valore di android.os.Build.VERSION.RELEASE.
  • La stringa $(MODEL) PUÒ essere vuota, ma se non è vuota 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 open source Android upstream.
  • Le implementazioni dei dispositivi POSSONO omettere Mobile nella stringa dello user agent.

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

• [C-1-4] DEVE eseguire il rendering dei contenuti forniti o dei contenuti dell'URL remoto in un processo distinto dall'applicazione che esegue l'istanza di WebView. Nello specifico, il processo del renderer separato DEVE avere un privilegio inferiore, 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 obbligatori tramite Binder. L'implementazione di WebView in AOSP soddisfa questo requisito.

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à del browser

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

• [C-1-1] DEVE supportare ciascuna di queste API associate a HTML5:
  • cache dell'applicazione/operazione offline
  • Tag<video>
  • geolocalizzazione
• [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 per lo sviluppo web stanno adottando IndexedDB al posto di webstorage, IndexedDB dovrebbe diventare un componente obbligatorio in una versione futura di Android.
• PUÒ includere una stringa user agent personalizzata nell'applicazione Browser autonoma.
• DOVREBBE implementare il supporto per il maggior numero possibile di elementi di HTML5 nell'applicazione Browser autonoma (in base all'applicazione Browser WebKit di upstream o a una sostituzione di terze parti).

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

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

3.5. Compatibilità comportamentale dell'API

Implementazioni dei dispositivi:

• [C-0-9] DEVE garantire che la compatibilità comportamentale dell'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 della lista consentita che garantisce la compatibilità del comportamento dell'API solo per le app selezionate dagli implementatori dei dispositivi.

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

• [C-0-1] I dispositivi NON DEVONO modificare il comportamento o la semantica di un intento standard.
• [C-0-2] I dispositivi NON DEVONO alterare il ciclo di vita o la semantica del ciclo di vita di un determinato tipo di componente di sistema (come Service, Activity, ContentProvider e così via).
• [C-0-3] I dispositivi NON DEVONO modificare la semantica di un'autorizzazione standard.
• I dispositivi NON DEVONO modificare le limitazioni applicate alle applicazioni in background. Più nello specifico, per le app in background:
  • [C-0-4] DEVONO interrompere l'esecuzione dei callback registrati dall'app per ricevere gli output da GnssMeasurement e GnssNavigationMessage.
  • [C-0-5] DEVONO limitare la frequenza degli aggiornamenti forniti all'app tramite la classe API LocationManager o il metodo WifiManager.startScan().
  • [C-0-6] Se l'app ha come target il livello API 25 o versioni successive, NON deve consentire di registrare i broadcast receiver per le emittenti implicite degli intent Android standard nel file manifest dell'app, a meno che l'intent di trasmissione non richieda un'autorizzazione "signature" o "signatureOrSystem" protectionLevel o non sia 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 una lista consentita temporanea per gestire un'attività visibile all'utente.
  • [C-0-8] Se l'app ha come target il livello API 25 o versioni successive, DEVE liberare i wakelock detenuti dall'app.
• [C-0-11] I dispositivi DEVONO restituire i seguenti fornitori di sicurezza come primi sette valori dell'array del metodo Security.getProviders(), nell'ordine specificato e con i nomi specificati (come restituito da Provider.getName()) e le classi, a meno che l'app non abbia modificato l'elenco tramite insertProviderAt() o removeProvider(). I dispositivi possono restituire fornitori aggiuntivi dopo l'elenco di fornitori specificato 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 Compatibility Test Suite (CTS) testa la compatibilità comportamentale di parti significative della piattaforma, ma non di tutte. È responsabilità dell'implementatore garantire la compatibilità del comportamento 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é implementare nuovamente parti significative del sistema.

3.5.1. Limitazione delle applicazioni

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 attesa delle app con limitazioni, devono:

• [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 di proprietà su ogni app.

• [C-1-3] NON deve applicare automaticamente queste limitazioni proprietarie senza evidenze di un cattivo comportamento di integrità del sistema, ma PUÒ applicare le limitazioni alle app al rilevamento di un cattivo comportamento di integrità del sistema, come wakelock bloccati, servizi a lungo termine e altri criteri. I criteri POSSONO essere determinati dagli implementatori del dispositivo, ma DEVONO essere correlati all'impatto dell'app sull'integrità del sistema. Altri criteri che non sono strettamente correlati allo stato di salute del sistema, come la mancata 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 per le 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 all'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 limitazioni proprietarie su un'app ogni volta che un utente inizia a utilizzarla esplicitamente, rendendola l'applicazione in primo piano.

• [C-1-10] È OBBLIGATORIO fornire un documento o un sito web pubblico e chiaro che descriva come vengono applicate le limitazioni di proprietà. Questo documento o sito web DEVE essere collegabile dalla documentazione dell'SDK Android e DEVE includere:

  • Condizioni di attivazione per le limitazioni di proprietà.
  • Che cosa e in che modo un'app può essere limitata.
  • In che modo un'app può essere esentata da queste limitazioni.
  • In che modo un'app può richiedere un'esenzione dalle limitazioni proprietarie, se supporta un'esenzione del genere 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 del dispositivo estendono le limitazioni delle app implementate in AOSP, devono:

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

3.5.2. Ibernazione dell'applicazione

Se le implementazioni del dispositivo includono la sospensione delle app inclusa in AOSP o estendono la funzionalità inclusa in AOSP, devono:

• [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] È OBBLIGATORIO applicare la limitazione all'app per un utente solo se esistono prove che l'utente non ha utilizzato l'app per un determinato periodo di tempo. È FORTEMENTE CONSIGLIATO che la durata sia di almeno un mese. L'utilizzo DEVE essere definito tramite l'interazione esplicita dell'utente tramite l'API UsageStats#getLastTimeVisible() o qualsiasi elemento che potrebbe causare l'uscita di un'app dallo stato di arresto forzato, tra cui associazioni di servizi, associazioni di fornitori di contenuti, trasmissioni esplicite e così via, che verranno monitorate da una nuova API UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] È OBBLIGATORIO applicare le limitazioni che interessano tutti gli utenti del dispositivo solo se esistono prove che il pacchetto non è stato utilizzato da NESSUN utente per un determinato periodo di tempo. È FORTEMENTE CONSIGLIATO che la durata sia di almeno un mese.
• [C-1-4] NON DEVE rendere l'app incapace di rispondere a intent di attività, associazioni di servizi, richieste di fornitori di contenuti o trasmissioni esplicite.

La modalità Sospensione app in AOSP soddisfa i requisiti sopra indicati.

3.6. Spazi dei nomi API

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

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

ovvero:

• [C-0-1] NON DEVE modificare le API esposte pubblicamente sulla piattaforma Android modificando le firme di metodi o classi o rimuovendo classi o campi di classi.
• [C-0-2] NON DEVE aggiungere elementi esposti pubblicamente (ad esempio 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 precedenti. Un "elemento esposto pubblicamente" è qualsiasi costrutto non decorato con l'indicatore "@hide" come utilizzato nel codice sorgente di Android upstream.

Gli implementatori dei dispositivi POSSONO modificare l'implementazione sottostante delle API, ma 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 dei dispositivi POSSONO aggiungere API personalizzate al di fuori dello spazio dei nomi Android standard, ma le API personalizzate:

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

Gli implementatori dei dispositivi POSSONO aggiungere API personalizzate nelle lingue native, 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 del pacchetto sopra indicati (ad esempio aggiungendo nuove funzionalità utili a un'API esistente o aggiungendo una nuova API), l'implementatore DEVE visitare source.android.com e avviare la procedura per apportare modifiche e codice, in base alle informazioni riportate su quel sito.

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

3.7. Compatibilità di runtime

Implementazioni dei dispositivi:

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

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

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

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

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

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

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

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

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

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

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

• [C-2-1] È OBBLIGATORIO segnalare true per ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] È OBBLIGATORIO chiedere all'utente prima di aggiungere una scorciatoia richiesta dalle app tramite il metodo dell'API ShortcutManager.requestPinShortcut().
• [C-2-3] DEVE supportare le scorciatoie bloccate e le scorciatoie dinamiche e statiche come descritto nella pagina Scorciatoie app.

Al contrario, se le implementazioni dei dispositivi non supportano il bloccaggio in-app delle scorciatoie,

• [C-3-1] È OBBLIGATORIO segnalare false per ShortcutManager.isRequestPinShortcutSupported().

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

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

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

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

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

• [C-6-1] DEVE essere utilizzato solo quando un utente lo attiva esplicitamente (ad es. tramite il menu Impostazioni o il selettore di sfondi).

3.8.2. Widget

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

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

• [C-1-1] DEVE dichiarare il supporto della funzionalità della piattaforma android.software.app_widgets.
• [C-1-2] DEVE includere il supporto integrato per gli AppWidget e mettere a disposizione funzionalità dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere gli AppWidget
• [C-1-3] DEVE essere in grado di eseguire il rendering di widget di dimensioni 4 x 4 nelle dimensioni della griglia standard. Per maggiori dettagli, consulta le linee guida per la progettazione di widget per app nella documentazione dell'SDK Android.
• POTREBBE supportare i widget delle app nella schermata di blocco.

Se le implementazioni dei dispositivi supportano i widget di app di terze parti e l'aggancio delle scorciatoie in-app, devono:

• [C-2-1] È OBBLIGATORIO segnalare true per AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] È OBBLIGATORIO chiedere all'utente prima di aggiungere una scorciatoia richiesta dalle app tramite il metodo dell'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. suoni, vibrazioni e illuminazione) e le funzionalità software (ad es. barra delle notifiche, barra di sistema) del dispositivo.

3.8.3.1. Presentazione delle notifiche

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

• [C-1-1] DEVE supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK e, nella misura del possibile, con l'implementazione hardware del dispositivo. Ad esempio, se un'implementazione del dispositivo include un vibratore, DEVE implementare correttamente le API di vibrazione. Se l'implementazione di un dispositivo è priva di hardware, le API corrispondenti DEVONO essere implementate come no-op. Questo comportamento è approfondito nella sezione 7.
• [C-1-2] DEVE eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) previste nelle API o nella guida allo stile delle icone della barra di stato/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 documentato nell'SDK.
• [C-1-5] DEVE fornire all'utente la possibilità di bloccare e modificare la notifica di una determinata app di terze parti per ogni livello di canale e pacchetto di app.
• [C-1-6] DEVE anche fornire all'utente la possibilità di 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 ulteriore interazione dell'utente. Ad esempio, DEVE mostrare tutte le risorse, incluse le icone fornite tramite android.app.Person, in una conversazione di gruppo impostata tramite setGroupConversation.

• [C-SR-1] È FORTEMENTE CONSIGLIATO fornire all'utente un'opzione per controllare le notifiche esposte alle app a cui è stata concessa l'autorizzazione di ascoltatore di notifiche. La granularità DEVE essere tale che l'utente possa controllare per ogni ascoltatore di notifiche quali tipi di notifiche vengono collegati a questo ascoltatore. I tipi DEVONO includere "conversazioni", "allerte", "silenziose" e "costanti importanti".

• [C-SR-2] È MOLTO CONSIGLIATO fornire agli utenti la possibilità di specificare le app da escludere dall'invio di notifiche a un ascoltatore di notifiche specifico.

• [C-SR-3] È FORTEMENTE CONSIGLIATO mostrare automaticamente un'affordance per l'utente per bloccare la notifica di una determinata app di terze parti per ogni canale e livello del pacchetto di app dopo che l'utente ha ignorato la notifica più volte.

• DOVREBBE supportare le notifiche avanzate.

• DOVREBBE presentare alcune notifiche con priorità più elevata come notifiche in evidenza.

• DOVREBBE avere un'affordance per consentire all'utente di posticipare le notifiche.

• PUO' gestire solo la visibilità e la tempistica in cui le app di terze parti possono notificare agli utenti eventi importanti per mitigare i 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 dei dispositivi:

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

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

• [C-SR-5] È MOLTO CONSIGLIATO mostrare questa conversazione come una bolla. L'implementazione AOSP soddisfa questi requisiti con la UI di sistema, le Impostazioni e Avvio predefiniti.

Se le implementazioni dei dispositivi supportano le notifiche avanzate:

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

Le notifiche in primo piano sono notifiche che vengono comunicate all'utente man mano che arrivano, indipendentemente dalla piattaforma in uso. Se le implementazioni dei dispositivi supportano le notifiche in primo piano, devono:

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

3.8.3.2. Servizio di listener di notifiche

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

Implementazioni dei dispositivi:

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

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

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

3.8.3.3. DND (Non disturbare) / Modalità Priorità

Se le implementazioni dei dispositivi supportano la funzionalità di modalità silenzioso (chiamata anche modalità Priorità), devono:

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

Inizio dei nuovi requisiti per Android 15

3.8.3.4. Protezione delle notifiche sensibili

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

Se le implementazioni dei dispositivi consentono ad app di terze parti di informare gli utenti di eventi importanti, queste:

• [C-1-1] È obbligatorio oscurare le informazioni sensibili delle notifiche per impedire che vengano trasmesse ai visualizzatori di notifiche, a meno che il servizio di visualizzatore non sia uno dei seguenti:

  • App di sistema firmate con un valore uid < 10000
  • UI di sistema
  • Shell
  • App del dispositivo complementare designato (definita da CompanionDeviceManager)
  • Ruolo SYSTEM_AUTOMOTIVE_PROJECTION
  • Ruolo SYSTEM_NOTIFICATION_INTELLIGENCE
  • Ruolo HOME

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

Fine dei nuovi requisiti

3.8.4. API di assistenza

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

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

• [C-2-1] DEVE indicare chiaramente all'utente finale quando il contesto viene condiviso, tramite:
  • Ogni volta che l'app di assistenza accede al contesto, viene visualizzata una luce bianca attorno ai bordi dello schermo che soddisfa o supera la durata e la luminosità dell'implementazione del progetto open source Android.
  • Per l'app di assistenza preinstallata, fornire all'utente un'affordance a meno di due navigazioni dal menu delle impostazioni dell'app di assistenza e dell'input vocale predefinito e condividere il contesto solo quando l'app di assistenza viene invocata esplicitamente dall'utente tramite una hotword o l'inserimento di una chiave di navigazione di assistenza.
• [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, in altre parole l'app che implementa VoiceInteractionService, o un'attività che gestisce l'intent ACTION_ASSIST.

3.8.5. Avvisi e popup

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

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

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

• [C-1-2] DEVE rispettare l'API Toast e mostrare i toast dalle applicazioni agli utenti finali in modo molto visibile.

3.8.6. Temi

Android fornisce i "temi" come meccanismo per consentire alle applicazioni di applicare stili a un'intera attività o applicazione.

Android include una famiglia di temi "Holo" e "Material" come insieme di stili definiti da utilizzare per gli sviluppatori di applicazioni che vogliono avere lo stesso aspetto e la stessa sensazione del tema Holo come definito dall'SDK Android.

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

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

• [C-1-3] È obbligatorio impostare la famiglia di caratteri "sans-serif" su Roboto versione 2.x per le lingue supportate da Roboto oppure fornire un'affordance per consentire all'utente di cambiare il carattere utilizzato per la famiglia di caratteri "sans-serif" su 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 di temi a colori elencati nella documentazione di Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (vedi android.theme.customization.theme_styles), ovvero TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD e MONOCHROMATIC.

  "Colore di origine" utilizzato per generare tavolozze di tonalità di colore dinamiche quando inviate con android.theme.customization.system_palette (come descritto in Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

• [C-1-6] DEVE avere un valore di crominanza CAM16 pari o superiore a 5.

  • DEVE essere ricavato dallo sfondo tramite com.android.systemui.monet.ColorScheme#getSeedColors, che fornisce diversi colori di origine validi tra cui scegliere.

  • DEBBA utilizzare il valore 0xFF1B6EF3 se nessuno dei colori forniti soddisfa il requisito di colore di origine riportato sopra.

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

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

Android supporta un tema con barre di sistema traslucide, che consente agli sviluppatori di app di riempire l'area dietro la barra di stato e la barra di navigazione con i contenuti delle app. Per consentire un'esperienza omogenea per gli sviluppatori in questa configurazione, è importante che lo stile delle icone della barra di stato venga mantenuto nelle implementazioni di dispositivi diversi.

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

• [C-2-1] È obbligatorio utilizzare il bianco per le icone di stato del sistema (ad esempio l'intensità del segnale e il livello della batteria) e le notifiche 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 maggiori dettagli, fai riferimento a R.style) quando un'app richiede una barra di stato chiara.

3.8.7. Sfondi animati

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

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

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

Se le implementazioni dei dispositivi implementano sfondi animati:

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

3.8.8. Cambio attività

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

Le implementazioni dei dispositivi, tra cui la chiave di navigazione della funzionalità Recenti descritta nella sezione 7.2.3, POTREBBERO alterare l'interfaccia.

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

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

3.8.9. Gestione dell'input

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

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

• [C-1-1] DEVE dichiarare la funzionalità della piattaforma android.software.input_methods e supportare le API IME come definito nella documentazione dell'SDK Android.

3.8.10. Controllo dei contenuti multimediali nella schermata di blocco

L'API Remote Control Client è deprecata in Android 5.0 a favore del Modello di notifica multimediale che consente alle applicazioni multimediali di integrarsi con i controlli di riproduzione visualizzati sulla schermata di blocco.

3.8.11. Salvaschermo (in precedenza Sogni)

Consulta la sezione 3.2.3.5 per le impostazioni informazioni sull'intent per configurare gli screen saver.

3.8.12. Posizione

Se le implementazioni dei dispositivi includono un sensore hardware (ad es. GPS) in grado di fornire le coordinate della posizione,

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

3.8.13. Unicode e carattere

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

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

• [C-1-1] DEVE essere in grado di visualizzare questi caratteri emoji in un glifo a colori.
• [C-1-2] DEVE includere il supporto per:
  • Carattere Roboto 2 con diversi spessori: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light per le lingue disponibili sul dispositivo.
  • Copertura completa di Unicode 7.0 per latino, greco e cirillico, inclusi gli intervalli A, B, C e D del latino esteso e tutti i glifi nel blocco dei simboli monetari 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 sostituire le emoji in NotoColorEmoji.tff
• DOVREBBE supportare la tonalità della pelle e diverse emoji di famiglia come specificato nel report tecnico Unicode n. 51.

Se le implementazioni del dispositivo includono un IME, devono:

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

Android include il supporto per il rendering dei caratteri birmani. In Birmania sono disponibili diversi caratteri non conformi a Unicode, comunemente noti come "Zawgyi", per il rendering delle lingue birmane.

Se le implementazioni dei dispositivi includono il supporto del birmano:

• [C-2-1] DEVE visualizzare il testo con un carattere conforme a Unicode come predefinito; il carattere non conforme a Unicode NON DEVE essere impostato come carattere predefinito, a meno che l'utente non lo scelga nel selettore della lingua.
• [C-2-2] DEVE supportare un carattere Unicode e un carattere non conforme a Unicode se sul dispositivo è supportato un carattere non conforme a Unicode. 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 lingua o regione ISO (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 lingua designato, come farebbe per qualsiasi altra lingua.

3.8.14. Multi-finestra

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

• [C-1-1] DEVE implementare queste modalità multi-finestra in conformità con i comportamenti e le API delle applicazioni descritti nella documentazione di supporto della modalità multi-finestra dell'SDK Android e soddisfare i seguenti requisiti:
• [C-1-2] DEVE rispettare android:resizeableActivity impostato da un'app nel file AndroidManifest.xml come descritto in questo SDK.
• [C-1-3] NON DEVE offrire la modalità schermo diviso o a forma libera se l'altezza dello schermo è inferiore a 440 dp e la larghezza dello schermo è inferiore a 440 dp.
• [C-1-4] Le dimensioni di un'attività NON DEVONO essere ridotte a meno di 220 dp nelle modalità con più finestre diverse da Picture-in-Picture.
• Le implementazioni dei dispositivi con dimensioni dello schermo xlarge DEVONO supportare la modalità freeform.

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

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

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

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

• [C-3-6] È OBBLIGATORIO allocare la larghezza e l'altezza minime riportate di seguito 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.

Inizio dei nuovi requisiti per Android 15

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

• [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 del gestore delle finestre come descritto in WindowManager Estensioni.

Fine dei nuovi requisiti

3.8.15. Ritaglio display

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

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

• [C-1-5] NON DEVONO essere presenti ritagli se le proporzioni del dispositivo sono 1,0 (1:1).
• [C-1-2] NON DEVE avere più di un ritaglio per bordo.
• [C-1-3] DEVE rispettare i flag di ritaglio del display impostati dall'app tramite l'API WindowManager.LayoutParams come descritto nell'SDK.
• [C-1-4] DEVE riportare 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 controlli dei dispositivi per fornire agli utenti informazioni rapide sullo stato e sulle azioni.

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

3.8.17. Appunti

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE inviare dati della clipboard a componenti, attività, servizi o su qualsiasi connessione di rete senza un'azione esplicita dell'utente (ad es. la pressione di un pulsante nell'overlay) o l'indicazione dell'invio di contenuti, ad eccezione dei servizi menzionati in 9.8.6 Raccolta 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, devono:

• [C-1-1] È OBBLIGATORIO oscurare l'anteprima visibile all'utente

L'implementazione di riferimento AOSP soddisfa questi requisiti della clipboard.

3.9. Amministrazione dispositivo

Inizio dei nuovi requisiti per Android 15

Android include funzionalità che consentono di attivare applicazioni di controller dei criteri dei dispositivi per eseguire funzioni di amministrazione del dispositivo a livello di sistema, come l'applicazione di criteri per le password o l'esecuzione di reset dei dati di fabbrica da remoto, tramite l'API Android Device Administration le API Device Policy Manager.

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

• [C-1-1] È OBBLIGATORIO dichiarare android.software.device_admin.
• [C-1-2] DEVE supportare il provisioning del proprietario del dispositivo come descritto nella sezione 3.9.1 e sezione 3.9.1.1.

Fine dei nuovi requisiti

3.9.1. Provisioning del dispositivo

3.9.1.1. Provisioning del proprietario del dispositivo

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

• [C-1-1] DEVE supportare la registrazione di un client Device Policy (DPC) come app di proprietà del dispositivo come descritto di seguito:
  • Quando l'implementazione del dispositivo non ha configurato né utenti né dati utente, avviene quanto segue:
    • [C-1-5] DEVE registrare l'applicazione DPC come app Proprietario dispositivo o consentire all'app DPC di scegliere se diventare un Proprietario dispositivo o un Proprietario 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 un proprietario del dispositivo o un 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 un'unica opzione valida.
    • [C-1-9] DEVE inviare l'intent ACTION_ADMIN_POLICY_COMPLIANCE all'app Proprietario dispositivo se un proprietario dispositivo viene stabilito durante il provisioning, indipendentemente dal metodo di provisioning utilizzato. L'utente non deve essere in grado di procedere nella configurazione guidata finché l'app Proprietario dispositivo non è terminata.
  • Quando l'implementazione del dispositivo ha utenti o dati utente, deve:
    • [C-1-7] NON deve più registrare alcuna applicazione DPC come app di proprietà del dispositivo.

Inizio dei nuovi requisiti per Android 15

• [C-1-2] DEVE mostrare un'informativa appropriata (come riferito in AOSP) e ottenere il consenso dell'utente finale prima che un'app venga impostata come proprietario del dispositivo, a meno che il dispositivo non sia configurato programmaticamente per la modalità demo per la vendita al dettaglio prima dell'interazione sullo schermo dell'utente finale. Se le implementazioni dei dispositivi dichiarano android.software.device_admin, ma includono anche una soluzione di gestione dei dispositivi proprietaria e forniscono un meccanismo per promuovere un'applicazione configurata nella loro soluzione come "equivalente del proprietario del dispositivo" al "proprietario del dispositivo" standard riconosciuto dalle API Android standard DevicePolicyManager, devono:

• [C-2-1] DEVE essere implementato un processo per verificare che l'app specifica promossa appartenga a una soluzione di gestione dei dispositivi aziendali legittima ed è stata configurata nella soluzione proprietaria in modo da avere i diritti equivalenti a quelli di un "proprietario del dispositivo".

• [C-2-2] DEVE mostrare la stessa informativa per il consenso del proprietario del dispositivo AOSP del flusso avviato da android.app.action.PROVISION_MANAGED_DEVICE prima di registrare l'applicazione DPC come "proprietario del dispositivo".

• [C-2-3] NON DEVE codificare il consenso o impedire l'utilizzo di altre app del proprietario del dispositivo.

Fine dei nuovi requisiti

3.9.1.2. Provisioning dei profili gestiti

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

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

Inizio dei nuovi requisiti per Android 15

• [C-1-2] La procedura di provisioning del profilo gestito (il flusso avviato dal DPC utilizzando android.app.action.PROVISION_MANAGED_PROFILE) o dalla piattaforma), la schermata del consenso e l'esperienza utente DEVONO essere in linea con l'implementazione AOSP.

Fine dei nuovi requisiti

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

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

• [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 un'emissione ACTION_PROFILE_PROVISIONING_COMPLETE 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 un proprietario del dispositivo o un 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 essere in grado di procedere nella configurazione guidata finché l'app Proprietario del profilo non è terminata.

• [C-1-8] È OBBLIGATORIO inviare ACTION_MANAGED_PROFILE_PROVISIONED in trasmissione al DPC del profilo personale quando viene stabilito un proprietario del profilo, indipendentemente dal metodo di provisioning utilizzato.

3.9.2. Assistenza per i profili gestiti

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

• [C-1-1] DEVE supportare i profili gestiti tramite le API android.app.admin.DevicePolicyManager.
• [C-1-2] DEVE consentire la creazione di un solo profilo gestito.
• [C-1-3] DEVE utilizzare un badge icona (simile al badge di lavoro in upstream AOSP) per rappresentare le applicazioni e i widget gestiti e altri elementi dell'interfaccia utente con badge come Recenti e Notifiche.
• [C-1-4] DEVE essere visualizzata un'icona di notifica (simile al badge di lavoro upstream AOSP) per indicare quando l'utente si trova in un'applicazione con profilo gestito.
• [C-1-5] DEVE mostrare un messaggio che indica che l'utente è nel profilo gestito se e quando il dispositivo si riattiva (ACTION_USER_PRESENT) e l'applicazione in primo piano si trova nel profilo gestito.
• [C-1-6] Se esiste un profilo gestito, DEVE essere mostrata un'affordance visiva nel "selettore" di intent per consentire all'utente di inoltrare l'intent dal profilo gestito all'utente principale o viceversa, se abilitato dal Controller dei criteri del dispositivo.
• [C-1-7] Se esiste un profilo gestito, DEVE esporre le seguenti funzionalità per l'utente sia per l'utente principale sia per il profilo gestito:
  • Contabilità separata per batteria, posizione, dati mobili e utilizzo dello 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 nel profilo dell'utente principale o gestito.
  • Gestione indipendente degli account all'interno del profilo dell'utente principale o gestito.
• [C-1-8] DEVE garantire che le applicazioni di tastiera, contatti e messaggistica preinstallate possano cercare e recuperare le informazioni sull'autore della chiamata dal profilo gestito (se esistente) insieme a quelle del profilo principale, se il Controller dei criteri del dispositivo lo consente.
• [C-1-9] DEVE garantire che soddisfi tutti i requisiti di sicurezza applicabili per 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 viene acquisito uno screenshot con una finestra in primo piano (quella con cui l'utente ha interagito per ultima tra tutte le attività) e appartiene a un'app del profilo di lavoro.topActivity
• [C-1-11] NON DEVE acquisire altri contenuti dello schermo (barra di sistema, notifiche o contenuti del profilo personale), ad eccezione della finestra/delle 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:

• [C-2-1] DEVE supportare la possibilità di specificare una schermata di blocco separata che soddisfi i seguenti requisiti per concedere l'accesso alle app in esecuzione solo in un profilo gestito.
  • Le implementazioni dei dispositivi DEVONO rispettare l'intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrare un'interfaccia per configurare una credenziale sulla schermata di blocco separata per il profilo gestito.
  • Le credenziali della schermata di blocco del profilo gestito DEVONO utilizzare gli stessi meccanismi di archiviazione e gestione delle credenziali del profilo principale, come descritto sul sito del progetto open source Android.
  • I criteri delle password del DPC devono essere applicati solo alle credenziali della schermata di blocco del profilo gestito, a meno che non vengano richiamati nell'istanza DevicePolicyManager restituita da getParentProfileInstance.
• Quando i contatti del profilo gestito vengono visualizzati nel registro chiamate preinstallato, nell'interfaccia utente durante la chiamata, nelle notifiche di chiamate in corso e perse, nelle app di contatti e messaggistica, DEVONO essere contrassegnati con lo stesso badge utilizzato per indicare le applicazioni del profilo gestito.

3.9.3. Assistenza utenti gestiti

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

• [C-1-1] DEVE fornire un'affordance utente per uscire dall'utente corrente e tornare all'utente principale nella sessione con più utenti quando isLogoutEnabled restituisce true. L'affordance dell'utente DEVE essere accessibile dalla schermata di blocco senza sbloccare il dispositivo.

Se le implementazioni del dispositivo dichiarano android.software.device_admin e forniscono un'affordance utente sul dispositivo per aggiungere altri utenti secondari, devono:

• [C-SR-1] È MOLTO CONSIGLIATO mostrare le stesse informative per il 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 dei ruoli di gestione delle norme dei dispositivi

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

• [C-1-1] DEVE supportare il ruolo di gestione dei criteri dei dispositivi 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 da : e dal certificato di firma, a meno che l'applicazione non sia precaricata.

Se per config_devicePolicyManagement non è definito un nome di pacchetto come описано sopra:

• [C-2-1] Le implementazioni dei dispositivi DEVONO supportare il provisioning senza un'applicazione di detentore del 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 profili per un utente.
• [C-3-2] Le implementazioni dei dispositivi POSSONO definire un'applicazione che aggiorna il detentore del ruolo di gestione dei criteri dei dispositivi prima del provisioning impostando config_devicePolicyManagementUpdater.

Se per config_devicePolicyManagementUpdater è definito un nome del pacchetto come описано 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 problemi relativi ai criteri dei dispositivi

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

• [C-1-1] È OBBLIGATORIO risolvere i conflitti dei criteri relativi ai dispositivi come descritto nel Device Policy Resolution Framework.

3.10. Accessibilità

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

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 per le API di accessibilità.
• [C-1-2] DEVE generare eventi di accessibilità e inviare il valore AccessibilityEvent appropriato a tutte le implementazioni AccessibilityService registered come descritto nell'SDK.
• [C-1-4] DEVE fornire un'affordance utente per controllare i servizi di accessibilità che dichiarano AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Tieni presente che per le implementazioni dei dispositivi con una barra di navigazione di sistema, queste DEVONO consentire all'utente di avere la possibilità di inserire un pulsante nella barra di navigazione del 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 Direct Boot Aware quando lo spazio di archiviazione dei dati è criptato con la crittografia basata su file (FBE).
• DOVREBBE fornire un meccanismo nel flusso di configurazione out-of-box per consentire agli utenti di attivare i servizi di accessibilità pertinenti, nonché opzioni per regolare le dimensioni dei caratteri, le dimensioni del display e i gesti di ingrandimento.

3.11. Sintesi vocale

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

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

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

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.

Inizio dei nuovi requisiti per Android 15

3.12. TV Input Framework

Android Television Input Framework (TIF) semplifica la pubblicazione di contenuti in diretta sui dispositivi Android TV. TIF fornisce un'API standard per creare moduli di input che controllano i dispositivi Android TV.

Se le implementazioni del dispositivo supportano TIF:

• [C-1-1] È OBBLIGATORIO dichiarare la funzionalità della piattaforma android.software.live_tv.
• [C-1-2] DEVE 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.

Fine dei nuovi requisiti

3.13. Impostazioni rapide

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

Se le implementazioni del dispositivo includono un componente dell'interfaccia utente di Impostazioni rapide e supportano le Impostazioni rapide di terze parti, devono:

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

3.14. UI multimediale

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

• [C-1-2] DEVE mostrare chiaramente le icone ottenute tramite getIconBitmap() o getIconUri() e i titoli ottenuti tramite getTitle() come descritto in MediaDescription. I titoli possono essere abbreviati 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 i contenuti forniti da questa applicazione di terze parti.

• [C-1-4] DEVE consentire all'utente di interagire con l'intera gerarchia MediaBrowser. PUÒ limitare l'accesso a parte della gerarchia per rispettare le normative di sicurezza (ad es. distrazione del conducente), ma NON DEVE dare un trattamento preferenziale in base ai contenuti o ai fornitori di contenuti.

• [C-1-5] È NECESSARIO 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 le 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 sia vera una delle seguenti condizioni:
  • Il filtro pattern intent del componente è esposto e ha CATEGORY_BROWSABLE
  • L'azione è una di ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
  • Il target è esposto esplicitamente con android:visibleToInstantApps
• [C-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 vedere i dettagli sulle app istantanee sul dispositivo, a meno che l'app istantanea non si colleghi esplicitamente all' applicazione installata.

• Le implementazioni dei dispositivi DEVONO fornire le seguenti funzionalità per l'utente per interagire con le app istantanee. AOSP soddisfa i requisiti con la UI di sistema, le Impostazioni e Avvio predefiniti. Implementazioni dei dispositivi:

  • [C-1-5] DEVE fornire all'utente la possibilità di visualizzare ed eliminare le app istantanee memorizzate nella cache locale per ogni singolo pacchetto dell'app.
  • [C-1-6] DEVE fornire una notifica utente persistente che può essere chiusa quando un'app istantanea è in esecuzione in primo piano. Questa notifica per l'utente DEVE includere il fatto che le app istantanee non richiedono installazione e fornire un'affordance che indirizzi l'utente alla schermata delle informazioni sull'applicazione nelle Impostazioni. Per le app istantanee avviate tramite intent web, come definito utilizzando un intent con azione impostata su Intent.ACTION_VIEW e con uno schema di "http" o "https", un'affordance aggiuntiva per l'utente DOVREA consentire all'utente di non avviare l'app istantanea e 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 in esecuzione dalla funzione Recenti se questa è disponibile sul dispositivo.

• [C-1-8] DEVE precaricare una o più applicazioni o componenti di servizio con un gestore degli intent per gli intent elencati nell'SDK qui e rendere gli intent visibili per le app istantanee.

3.16. Accoppiamento dispositivo complementare

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

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

• [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] DEVI assicurarti che le API nel pacchetto android.companion siano completamente implementate.

Inizio dei nuovi requisiti per Android 15

• [C-1-3] DEVE fornire all'utente la possibilità di selezionare/confermare che un dispositivo complementare è presente e operativo, che DEVE utilizzare lo stesso messaggio implementato in AOSP senza aggiunte o modifiche.

Fine dei nuovi requisiti

3.17. App pesanti

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

• [C-1-1] DEVE essere installata una sola app che specifica cantSaveState in esecuzione nel sistema alla volta. Se l'utente chiude un'app di questo tipo senza uscirne esplicitamente (ad esempio premendo il tasto Home mentre esce da un'attività attiva del sistema, anziché premere Indietro quando non sono presenti attività attive nel sistema), le implementazioni del dispositivo DEVONO dare la priorità a quell'app nella RAM, come per altre attività che dovrebbero rimanere in esecuzione, come i servizi in primo piano. Quando un'app di questo tipo è in background, il sistema può comunque applicare funzionalità di gestione dell'alimentazione, ad esempio limitare l'accesso alla CPU e alla rete.
• [C-1-2] DEVE fornire un'affordance utente per scegliere l'app che non partecipa al normale meccanismo di salvataggio/ripristino dello stato quando l'utente avvia una seconda app dichiarata con l'attributo cantSaveState.
• [C-1-3] NON DEVONO essere applicate altre modifiche alle norme alle app che specificano cantSaveState, ad esempio la modifica del rendimento della CPU o della priorità di pianificazione.

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

• [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 i dati di contatto memorizzati sul dispositivo. I dati di contatto inseriti direttamente nel dispositivo vengono in genere sincronizzati con un servizio web, ma possono anche risiedere solo localmente sul dispositivo. I contatti memorizzati solo sul dispositivo sono chiamati contatti locali.

I RawContacts sono "associati a" o "memorizzati in" un Account quando le colonne ACCOUNT_NAME e ACCOUNT_TYPE per i contatti non elaborati corrispondono ai campi corrispondente Account.name e Account.type dell'account.

Account locale predefinito: un account per i contatti non elaborati memorizzati solo sul dispositivo e non associati a un account in AccountManager, che vengono 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, che vengono creati con almeno un valore non nullo per le colonne ACCOUNT_NAME e ACCOUNT_TYPE.

Implementazioni dei dispositivi:

• [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 valore ACCOUNT_NAME dell'account locale personalizzato DEVE essere restituito da ContactsContract.RawContacts.getLocalAccountName
• [C-1-2] Il valore 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 con l'account locale predefinito (ovvero impostando valori null per ACCOUNT_NAME e ACCOUNT_TYPE) DEVONO essere inseriti 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 non elaborati (come se il parametro CALLER_IS_SYNCADAPTER fosse impostato su true), anche se il parametro CALLER\_IS\_SYNCADAPTER è impostato su false o non è specificato.

Inizio dei nuovi requisiti per Android 15

3.19. Impostazioni della lingua

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE fornire all'utente la possibilità di selezionare un trattamento linguistico specifico per genere per le lingue che non supportano traduzioni specifiche per genere. Per ulteriori informazioni, consulta le risorse grammaticali.

Fine dei nuovi requisiti

4. Compatibilità con il pacchettizzazione delle applicazioni

Implementazioni dei dispositivi:

• [C-0-1] DEVE essere in grado di installare ed eseguire file ".apk" Android come generati dallo strumento "aapt" incluso nell'SDK Android ufficiale.

  • Poiché il requisito sopra indicato può essere impegnativo, per le implementazioni dei dispositivi è consigliato di utilizzare 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.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 bytecode .apk, Android Manifest, Dalvik bytecode o RenderScript in modo da impedire l'installazione e l'esecuzione corretta di questi file su altri dispositivi compatibili.

• [C-0-4] NON DEVE consentire ad app diverse dall'attuale "installatore registrato" del pacchetto di disinstallare l'app in modo silenzioso senza alcuna conferma dell'utente, come documentato nell'SDK per l'autorizzazione DELETE_PACKAGE. Le uniche eccezioni sono l'intent PACKAGE_NEEDS_VERIFICATION per la gestione dell'app di verifica del pacchetto di sistema e l'intent ACTION_MANAGE_STORAGE per la gestione dell'app di gestione dello spazio di archiviazione.

• [C-0-5] DEVE avere un'attività che gestisca 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 non soddisfi tutti i seguenti requisiti:

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

• DOVREBBE fornire all'utente la possibilità di concedere/revocare l'autorizzazione per 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 fare 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 contrassegnata dalla stessa API di sistema PackageManager.setHarmfulAppWarning come potenzialmente dannosa.

• DOVREBBE fornire all'utente la possibilità di scegliere se disinstallare o avviare un'applicazione nella finestra di dialogo di avviso.

• [C-0-8] È OBBLIGATORIO implementare il supporto per il file system incrementale come descritto 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.

Nota: le implementazioni dei dispositivi fornite con Android 10 o versioni precedenti che non possono soddisfare i requisiti [C-0-8] e [C-0-9] tramite un aggiornamento del software di sistema POSSONO essere esenti da questi requisiti.

5. Compatibilità multimediale

Implementazioni dei dispositivi:

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

Implementazioni dei dispositivi:

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

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

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

5.1. Codec multimediali

5.1.1. Codifica audio

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

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

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

Tutti i codificatori audio DEVONO supportare:

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

5.1.2. Decodifica audio

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

Se le implementazioni dei dispositivi dichiarano il supporto della funzionalitàandroid.hardware.audio.output, 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+ migliorato)
• [C-1-4] AAC ELD (AAC a basso ritardo migliorato)
• [C-1-11] xHE-AAC (profilo HE AAC esteso ISO/IEC 23003-3, che include il profilo di base USAC e il profilo di controllo della gamma dinamica ISO/IEC 23003-4)
• [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 è autorizzato a eseguire il downsampling e il downmix durante la fase di riproduzione.
• [C-1-10] Opus

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

• [C-2-1] La decodifica DEVE essere eseguita senza downmixing (ad es. uno stream AAC 5.0 deve essere decodificato in cinque canali PCM, uno stream AAC 5.1 deve essere decodificato in sei canali PCM).
• [C-2-2] I metadati relativi all'intervallo dinamico DEVONO essere come definiti in "Controllo dell'intervallo dinamico (DRC)" in ISO/IEC 14496-3 e le chiavi DRC android.media.MediaFormat per configurare i comportamenti relativi all'intervallo dinamico del decodificatore audio. Le chiavi DRC AAC 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] È MOLTO CONSIGLIATO che i requisiti C-2-1 e C-2-2 di cui sopra siano soddisfatti da tutti i decodificatori audio AAC.

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

• [C-3-1] I metadati di intensità e DRC DEVONO essere interpretati e applicati in base al profilo di controllo dinamico del livello 1 MPEG-D DRC.
• [C-3-2] Il decodificatore DEVE comportarsi in base alla configurazione impostata con le seguenti chiavi android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_DRC_EFFECT_TYPE.

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

• PUO' supportare il controllo dell'intensità e della gamma dinamica utilizzando il profilo di controllo della gamma dinamica ISO/IEC 23003-4.

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

• I metadati ISO/IEC 23003-4 hanno la precedenza.

Tutti i decodificatori audio DEVONO supportare l'output di:

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

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

• [C-7-1] DEVE essere possibile configurarlo dall'applicazione che utilizza la decodifica con la chiave KEY_MAX_OUTPUT_CHANNEL_COUNT per controllare se i contenuti vengono downmixati in stereo (se si utilizza un valore pari a 2) o se vengono emessi utilizzando il numero di canali nativo (se si utilizza un valore uguale o superiore a questo numero). Ad esempio, un valore pari o superiore a 6 configurerebbe un decodificatore in modo da emettere 6 canali quando vengono forniti contenuti 5.1.
• [C-7-2] Durante la decodifica, il decodificatore DEVE pubblicizzare la maschera di canale utilizzata nel formato di output con la chiave KEY_CHANNEL_MASK utilizzando le costanti android.media.AudioFormat (esempio: CHANNEL_OUT_5POINT1).

Se le implementazioni dei dispositivi supportano decodificatori audio diversi dal decodificatore audio AAC predefinito e sono in grado di produrre audio multicanale (ovvero più di 2 canali) quando vengono alimentati con contenuti multicanale compressi:

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

5.1.3. Dettagli sui codec audio

Formato/codec	Dettagli	Tipi di file/formati contenitore da supportare
Profilo MPEG-4 AAC (AAC LC)	Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC non compresso ADTS (.aac, ADIF non supportato) MPEG-TS (.ts, non cercabile, solo decodifica) Matroska (.mkv, solo decodifica)
Profilo MPEG-4 HE AAC (AAC+)	Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
Profilo MPEG-4 HE AACv2 (AAC+ migliorato)	Supporto per 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 (AAC a bassa latenza migliorata)	Supporto per contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	Supporto per contenuti mono/stereo con frequenze di campionamento standard da 7,35 a 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	Da 4,75 a 12,2 Kbps campionati a 8 kHz	3GPP (.3gp)
AMR-WB	9 frequenze 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	Sia per l'encoder che per il decodificatore: devono essere supportate almeno le modalità Mono e Stereo. È OBBLIGATORIO supportare frequenze di campionamento fino a 192 kHz e risoluzione di 16 e 24 bit. La gestione dei dati audio FLAC a 24 bit DEVE essere disponibile con la configurazione audio a virgola mobile.	FLAC (.flac) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (.mkv, solo decodifica)
MP3	Mono/stereo 8-320 Kbps costante (CBR) o con velocità in bit variabile (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (.mkv, solo decodifica)
MIDI	Tipo MIDI 0 e 1. Versioni 1 e 2 di DLS. XMF e Mobile XMF. Supporto per i formati di suoneria RTTTL/RTX, OTA e iMelody	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	Decodifica: supporto per contenuti mono, stereo, 5.0 e 5.1 con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz. Encoding: supporto per 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 a virgola mobile a 16 bit. L'estrattore WAVE deve supportare PCM lineare a 16 bit, 24 bit e 32 bit e float 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 per contenuti mono, stereo, 5.0 e 5.1 con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz. Codifica: supporto per 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 delle immagini

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

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

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

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 HEVC con accelerazione hardware che supporti la modalità di controllo della velocità in bit BITRATE_MODE_CQ, il profilo HEVCProfileMainStill e le dimensioni del frame di 512 x 512 px.

5.1.5. Decodifica delle immagini

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

Le implementazioni dei dispositivi DEVONO supportare la 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] Non elaborato
• [C-0-7] AVIF (profilo di riferimento)

Se le implementazioni dei dispositivi supportano la decodifica video HEVC:

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

Decodificatori di immagini che supportano un formato ad alta profondità di bit (più di 9 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 delle immagini

Formato/codec	Dettagli	Tipi di file/formati contenitore supportati
JPEG	Base+progressiva	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Raw - Una cruda verità		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Immagine, Raccolta di immagini, Sequenza di immagini	HEIF (.heif), HEIC (.heic)
AVIF (profilo di riferimento)	Profilo di riferimento di immagini, raccolte di immagini e sequenze di immagini	Contenitore HEIF (.avif)

Codificatori e decodificatori di immagini esposti tramite l'API MediaCodec

• [C-1-1] DEVE supportare il formato di colore flessibile YUV420 8:8:8 (COLOR_FormatYUV420Flexible) tramite CodecCapabilities.

• [C-SR-1] È FORTEMENTE CONSIGLIATO supportare il formato di colore RGB888 per la modalità di input della superficie.

• [C-1-3] DEVE supportare almeno un formato di colore YUV420 8:8:8 planare o semiplanare: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). È MOLTO CONSIGLIATO supportare entrambi.

5.1.7. Codec video

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

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

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

• [C-1-2] Gli encoder e i decodificatori video DEVONO supportare i formati di colore flessibili YUV420 8:8:8 (COLOR_FormatYUV420Flexible) fino a CodecCapabilities.

• [C-1-3] I codificatori e decodificatori video DEVONO supportare almeno un formato di colore YUV420 8:8:8 planare o semiplanare: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). È FORTEMENTE CONSIGLIATO supportare entrambi.

• [C-SR-1] È FORTEMENTE CONSIGLIATO che gli encoder e i decodificatori video supportino almeno un formato di colore YUV420 8:8:8 planare o semiplanare ottimizzato per l'hardware (YV12, NV12, NV21 o un formato ottimizzato dal fornitore equivalente).

• [C-1-5] I decodificatori video che supportano un formato a profondità di bit elevata (più di 9 bit per canale) DEVONO supportare l'output di un formato equivalente a 8 bit se richiesto dall'applicazione. Questo DEVE essere supportato tramite un formato di 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 interno tramite FEATURE_IntraRefresh nella classe MediaCodecInfo.CodecCapabilities:

• [C-3-1] DEVE supportare i periodi di aggiornamento nell'intervallo di 10-60 frame e deve 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 essere impostato come predefinito il formato colore ottimizzato per il display hardware se configurato utilizzando l'output Surface.
• [C-4-2] DEVE essere impostato per impostazione predefinita su un formato di colore YUV420 8:8:8 ottimizzato per la lettura della CPU se configurato per non utilizzare l'uscita Surface.

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 maggiori dettagli, consulta le sezioni 5.2 e 5.3	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, non cercabile) 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 cercabile) MPEG-4 (.mp4, solo decodifica) Matroska (.mkv, solo decodifica)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, solo decodifica)
VP8	Per maggiori 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 maggiori dettagli, consulta la sezione 5.2 e la sezione 5.3	MPEG-4 (.mp4) Matroska (.mkv, solo decodifica)

5.1.9. Sicurezza dei codec multimediali

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 il supporto per i codec multimediali tramite API OMX o Codec 2.0 (o entrambe) come in Android Open Source Project e non deve disattivare o aggirare le protezioni di sicurezza. Nello specifico, 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 che il supporto delle API disponibili DEVE includere le protezioni di sicurezza presenti.
• [C-SR-1] È FORTEMENTE CONSIGLIATO 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 del progetto open source Android (se disponibile) per ogni formato e tipo di contenuti multimediali (codificatore o decodificatore) supportato dal dispositivo.
• [C-2-2] Codec con nomi che iniziano con "OMX.google." DEVONO essere basate 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 abbia accesso a driver hardware diversi dai mappatori di memoria.

Se le implementazioni del dispositivo supportano l'API Codec 2.0:

• [C-3-1] DEVE includere il codec software Codec 2.0 corrispondente del Progetto open source Android (se disponibile) per ogni formato e tipo di contenuti multimediali (codificatore o decodificatore) supportato dal dispositivo.
• [C-3-2] È NECESSARIO includere i codec software Codec 2.0 nel processo di codec software come indicato nel Progetto open source Android per consentire di concedere l'accesso ai codec software in modo più limitato.
• [C-3-3] Codec con nomi che iniziano con "c2.android." DEVONO essere basate sul codice sorgente di Android Open Source Project.

5.1.10. Caratterizzazione dei codec multimediali

Se le implementazioni dei dispositivi supportano i codec multimediali:

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

In particolare:

• [C-1-2] Codec con nomi che iniziano con "OMX". DEVONO 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". DEVONO 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 con accelerazione hardware.
• [C-1-5] I codec in esecuzione in un processo di codec (del fornitore o di sistema) che hanno accesso a driver hardware diversi da allocatori e mappatori di memoria NON DEVONO essere caratterizzati come solo software.
• [C-1-6] I codec non presenti nell'Android Open Source Project o non basati sul codice sorgente di quel progetto DEVONO essere identificati come di proprietà del fornitore.
• [C-1-7] I codec che utilizzano l'accelerazione hardware DEVONO essere caratterizzati come con accelerazione hardware.
• [C-1-8] I nomi dei codec NON DEVONO ingannare. Ad esempio, i codec denominati "decoder" DEVONO supportare la decodifica e quelli denominati "encoder" 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 sulla frequenza frame 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 (diversi da MPEG4, AV1)	3840 x 2160 px (HEVC, VP9, AV1)

• [C-2-2] I codec video caratterizzati come con accelerazione 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 estesi se supportano un rendimento video duraturo diverso da uno di quelli standard elencati.

5.2. Codifica video

Se le implementazioni del dispositivo supportano qualsiasi codificatore video e lo rendono disponibile per le 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, se non influisce sul livello di qualità minimo, la velocità in bit codificata :

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

Se le implementazioni del dispositivo supportano qualsiasi codificatore video e lo rendono disponibile per le 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, la bitrate codificata:

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

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

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

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

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

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

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

Se le implementazioni del dispositivo forniscono codificatori video o di immagini con accelerazione hardware e supportano una o più videocamere hardware collegate o collegabili esposte tramite le API android.camera:

• [C-4-1] Tutti gli encoder video e di immagini con accelerazione hardware DEVONO supportare la codifica dei frame dalle videocamere hardware.
• DOVREBBE supportare la codifica dei frame dalle videocamere hardware tramite tutti gli codificatori video o di immagini.

Se le implementazioni dei dispositivi forniscono la codifica HDR:

• [C-SR-1] È FORTEMENTE CONSIGLIATO di fornire un plug-in per l'API di transcodifica senza interruzioni per convertire il formato HDR in 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, devono:

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

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

• [C-2-1] DEVE supportare i profili di codifica riportati nella tabella seguente.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p
Risoluzione video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	20 f/s	30 fps	30 fps	30 fps
Velocità in bit video	384 kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

Se le implementazioni dei dispositivi supportano il codec VP8:

• [C-1-1] DEVE supportare i profili di codifica video SD.
• DEVE supportare i seguenti profili di codifica video HD (alta definizione).
• [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 web e di videoconferenza.

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

• [C-2-1] DEVE supportare i profili di codifica riportati nella tabella seguente.

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

5.2.4. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

• [C-1-2] DEVE supportare il profilo 0 di 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 come indicato 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 principale di livello 3 fino a una risoluzione di 512 x 512.
• [C-SR-1] sono FORTEMENTE CONSIGLIATI per supportare il profilo SD 720 x 480 e i profili di codifica 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

5.2.6. AV1

Se le implementazioni dei dispositivi supportano il codec AV1:

• [C-1-1] DEVE supportare il profilo principale, inclusi i contenuti a 8 e 10 bit.

• [C-1-2] DEVE pubblicare i dati sul rendimento, ovvero generare report sui dati sul rendimento tramite le API getSupportedFrameRatesFor() o getSupportedPerformancePoints() per le risoluzioni supportate nella tabella seguente.

• [C-1-3] DEVE accettare i metadati HDR e esportarli nel flusso di dati

Se il codificatore AV1 è con accelerazione hardware, esegue le seguenti operazioni:

• [C-2-1] DEVE supportare fino al profilo di codifica HD1080 incluso nella tabella riportata di seguito:

	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 o H.265:

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

• [C-1-1] DEVE supportare il profilo di base di livello 30 (risoluzioni CIF, QCIF e SQCIF a 30 fps e 384 Kbps) e il livello 45 (risoluzioni QCIF e SQCIF a 30 fps e 128 Kbps).

5.3.3. MPEG-4

Se le implementazioni dei dispositivi con decodificatori MPEG-4:

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

5.3.4. H.264

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

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

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

• [C-2-1] DEVE supportare i profili di decodifica video HD 720p riportati nella tabella seguente.
• [C-2-2] DEVE supportare i profili di decodifica video HD 1080p riportati nella tabella seguente.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p
Risoluzione video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	60 FPS	30 f/s (60 f/s^Televisore)
Velocità in bit video	800 kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

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

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

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

• [C-2-1] Le implementazioni dei dispositivi DEVONO supportare almeno una decodifica H.265 o VP9 per i profili 720, 1080 e UHD.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p	UHD
Risoluzione video	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30/60 f/s (60 f/s^Televisore con decodifica hardware H.265)	60 FPS
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 flusso di bit e/o dal contenitore.
• [C-3-2] Le implementazioni dei dispositivi DEVONO mostrare 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 riportati nella tabella seguente.
• DEBBA utilizzare un codec VP8 hardware che soddisfi i requisiti.
• DEVE supportare i profili di decodifica HD riportati nella tabella seguente.

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

• [C-2-1] Le implementazioni dei dispositivi DEVONO supportare i profili 720p indicati nella tabella seguente.
• [C-2-2] Le implementazioni dei dispositivi DEVONO supportare i profili 1080p indicati nella tabella seguente.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	30 f/s (60 f/s^Televisore)	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 come indicato nella tabella seguente.

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

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

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

• [C-3-1] Le implementazioni dei dispositivi DEVONO supportare almeno una decodifica VP9 o H.265 per i 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^Televisore con decodifica hardware VP9)	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se le implementazioni del dispositivo dichiarano di supportare VP9Profile2 o VP9Profile3 tramite le API multimediali 'CodecProfileLevel':

• Il supporto del formato a 12 bit è FACOLTATIVO.

Se le implementazioni del dispositivo 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. Inoltre, DEVONO supportare l'estrazione e l'output dei metadati HDR richiesti dal flusso di dati e/o dal contenitore.
• [C-4-2] Le implementazioni dei dispositivi DEVONO mostrare 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 dei dispositivi dichiarano il supporto del decodificatore Dolby Vision tramite HDR_TYPE_DOLBY_VISION, devono:

• [C-1-1] È OBBLIGATORIO fornire un'apposita app per l'estrazione di file compatibile con Dolby Vision.

Inizio dei nuovi requisiti per Android 15

• [C-1-2] DEVE mostrare correttamente i contenuti Dolby Vision su lo schermo del dispositivo o su un display esterno collegato tramite una porta di uscita video standard (ad es. HDMI).

Fine dei nuovi requisiti

• [C-1-3] È NECESSARIO impostare l'ID traccia del livello di base compatibile con le versioni precedenti (se presente) 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 le applicazioni di terze parti, devono:

• [C-1-1] DEVE supportare il profilo principale, inclusi i contenuti a 8 e 10 bit.

Se le implementazioni dei dispositivi forniscono il supporto per il codec AV1 con un decodificatore con accelerazione hardware, devono:

• [C-2-1] DEVE essere in grado di decodificare almeno i profili di decodifica video HD 720p riportati nella tabella di seguito quando l'altezza indicata 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 riportati nella tabella seguente quando l'altezza indicata 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 del dispositivo supportano il profilo HDR tramite le API Media, l'implementazione di questi dispositivi:

• [C-3-1] DEVE supportare l'estrazione e l'output dei metadati HDR dal bitstream e/o dal contenitore.
• [C-3-2] DEVE mostrare 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 DOVREBBE da Android 4.3, è previsto di modificare la definizione di compatibilità per le versioni future in DEVE. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti indicati come DOVREBBE, altrimenti non potranno raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

5.4.1. Acquisizione di audio non compresso e informazioni sul microfono

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

• [C-1-1] DEVE consentire l'acquisizione di contenuti audio non elaborati per qualsiasi stream INPUT AudioRecord o AAudio aperto correttamente. Come minimo, le seguenti caratteristiche DEVONO essere supportate:

  • Formato: PCM lineare, 16 bit
  • Frequenze di campionamento: 8000, 11025, 16000, 44100, 48000 Hz
  • Canali: mono
  • Origini audio: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED o VOICE_PERFORMANCE. Questo 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 a 16 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] È OBBLIGATORIO acquisire a frequenze di campionamento superiori senza upsampling.

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

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

  • Formato: PCM lineare, 16 bit
  • Frequenze di campionamento: 22050, 48000 Hz
  • Canali: stereo

• [C-1-4] DEVE rispettare l'API MicrophoneInfo e compilare correttamente le informazioni relative ai microfoni disponibili sul dispositivo accessibili alle applicazioni di terze parti tramite l'API AudioManager.getMicrophones() per AudioRecord attivo che utilizza MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED o VOICE_PERFORMANCE. Se le implementazioni dei dispositivi consentono l'acquisizione di contenuti audio non elaborati con qualità DVD e radio AM, devono:

• [C-2-1] È NECESSARIO acquisire senza upsampling a un rapporto superiore a 16000:22050 o 44100:48000.

• [C-2-2] DEVE includere un filtro anti-aliasing appropriato per qualsiasi upsampling o downsampling.

5.4.2. Acquisisci per il riconoscimento vocale

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

• [C-1-1] È OBBLIGATORIO acquisire android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION la sorgente audio con una delle frequenze di campionamento 44100 e 48000.
• [C-1-2] PER IMPOSTAZIONE PREDEFINITA, deve disattivare qualsiasi elaborazione audio di riduzione del rumore durante la registrazione di uno stream audio dalla fonte audio AudioSource.VOICE_RECOGNITION.

• [C-1-3] PER IMPOSTAZIONE PREDEFINITA, deve essere disattivato qualsiasi controllo automatico del guadagno durante la registrazione di uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.

• DEVE presentare 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 e tutti i microfoni utilizzati per registrare l'origine audio del riconoscimento vocale.

• [C-SR-1] È MOLTO CONSIGLIATO che i livelli di ampiezza nell'intervallo di frequenza basso siano di ±20 dB da 30 Hz a 100 Hz rispetto all'intervallo di frequenza medio per ogni microfono utilizzato per registrare l'audio della sorgente di riconoscimento vocale.

• [C-SR-2] È MOLTO CONSIGLIABILE che mostrino livelli di ampiezza nell'intervallo di frequenza elevato: in particolare da ±30 dB da 4000 Hz a 22 KHz rispetto all'intervallo di frequenza medio per ogni microfono utilizzato per registrare l'audio della sorgente di riconoscimento vocale.

• DEBBA impostare la sensibilità di ingresso audio in modo che un'origine audio sinusoidale di 1000 Hz riprodotta a un livello di pressione sonora (SPL) di 90 dB (misurato accanto al microfono) fornisca una risposta ideale di 2500 RMS in un intervallo compreso tra 1770 e 3530 per campioni a 16 bit (o -22,35 dB ±3 dB Full Scale per campioni a virgola mobile/doppia precisione) per ogni microfono utilizzato per registrare l'origine audio del riconoscimento vocale.

• DEVE registrare lo stream audio di riconoscimento vocale in modo che i livelli di ampiezza PCM monitorino in modo lineare le variazioni di SPL in ingresso in un intervallo di almeno 30 dB da -18 dB a +12 dB rispetto a 90 dB SPL al microfono.

• DEVE registrare lo stream audio di riconoscimento vocale con una distorsione armonica totale (THD) inferiore all'1% per 1 kHz a un livello di ingresso di 90 dB SPL al microfono.

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

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

5.4.3. Acquisizione per il reindirizzamento della riproduzione

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

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

• [C-1-1] DEVE implementare correttamente l'origine audio REMOTE_SUBMIX in modo che, quando un'applicazione utilizza l'API android.media.AudioRecord per registrare da questa origine audio, acquisisca un mix di tutti gli stream audio, ad eccezione di quanto segue:

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

5.4.4. Cancellazione dell'eco acustica

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

• DEBBA implementare una tecnologia di cancellazione dell'eco acustica (AEC) sintonizzata per la comunicazione vocale e applicata al percorso di acquisizione quando si acquisisce con AudioSource.VOICE_COMMUNICATION.

Se le implementazioni del dispositivo forniscono un'opzione di cancellazione eco acustica inserita nel percorso audio di acquisizione quando è selezionata AudioSource.VOICE_COMMUNICATION, queste:

• [C-SR-1] È FORTEMENTE_CONSIGLIATO dichiararlo tramite il metodo dell'API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
• [C-SR-2] sono FORTEMENTE_CONSIGLIATI per consentire il controllo di questo effetto audio con l'API AcousticEchoCanceler.
• [C-SR-3] 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 dei dispositivi dichiarano android.hardware.microphone,devono obbligatoriamente implementare la cattura simultanea come descritto in questo documento. Nello specifico:

• [C-1-1] DEVE consentire l'accesso simultaneo al microfono da parte di un servizio di accessibilità che acquisisce con AudioSource.VOICE_RECOGNITION e almeno un'applicazione che acquisisce con qualsiasi AudioSource.
• [C-1-2] DEVE consentire l'accesso simultaneo al microfono da parte di un'app preinstallata che ha un ruolo di assistente e di almeno un'altra app 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 app ha un'interfaccia utente in alto, 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 l'audio tramite la periferica di output audio come definito nella sezione 7.8.2.

5.5.1. Riproduzione audio non elaborata

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

• [C-1-1] DEVE consentire la riproduzione di contenuti audio non elaborati con le seguenti caratteristiche:

  • Formati di origine: PCM lineare, 16 bit, 8 bit, floating
  • Canali: mono, stereo, configurazioni multicanale valide con fino a 8 canali
  • Frequenze di campionamento (in Hz):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 nelle configurazioni del canale 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,

• [C-1-1] DEVE supportare le implementazioni EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controllabili tramite le classi di sottoclasse AudioEffect Equalizer e LoudnessEnhancer.
• [C-1-2] DEVE supportare l'implementazione dell'API di visualizzazione, controllabile tramite la classe Visualizer.
• [C-1-3] DEVE supportare l'implementazione di EFFECT_TYPE_DYNAMICS_PROCESSING controllabile tramite la sottoclasse AudioEffect DynamicsProcessing.

Inizio dei nuovi requisiti per Android 15

• [C-1-4] DEVE supportare gli effetti audio con input e output a virgola mobile, quando i risultati dell'effetto vengono restituiti alla pipeline audio del framework. Si riferisce ai tipici effetti insert o aux, come l'equalizzatore. Il comportamento equivalente è vivamente consigliato quando i risultati dell'effetto non sono visibili dalla pipeline audio del framework (ad esempio, post-elaborazione o effetti offloaded).

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

• [C-1-5] DEVI assicurarti 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 fa riferimento ai tipici effetti insert o aux, ma sono esclusi gli effetti speciali come downmix, upmix ed effetti di spazializzazione che modificano il numero di canali. Il comportamento equivalente è consigliato quando gli effetti non sono visibili dalla pipeline audio del framework (ad esempio effetti di post-elaborazione o offloaded).

Fine dei nuovi requisiti

• 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] È MOLTO CONSIGLIATO supportare gli effetti in virgola mobile e multicanale.

5.5.3. Volume uscita audio

Implementazioni di dispositivi per auto e motori:

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

5.5.4. Offload audio

Se le implementazioni del dispositivo supportano la riproduzione con trasferimento dell'audio:

• [C-SR-1] È FORTEMENTE CONSIGLIATO tagliare i contenuti audio riprodotti senza interruzioni tra due clip con lo stesso formato quando specificato dall'API AudioTrack gapless e dal contenitore multimediale per MediaPlayer.

5.6. Latenza audio

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

Ai fini di questa sezione, utilizza le seguenti definizioni:

• Latenza in uscita. L'intervallo tra il momento in cui un'applicazione scrive un frame di dati codificati in PCM e il momento in cui l'audio corrispondente viene presentato all'ambiente da un trasduttore on-device o il segnale esce dal dispositivo tramite una porta e può essere osservato esternamente.
• Latenza di output a freddo. Il tempo che intercorre tra l'avvio di uno stream di output e il momento di presentazione del primo frame in base ai timestamp, quando il sistema di output audio è stato inattivo e spento prima della richiesta.
• Latenza di output continua. La latenza di uscita per i frame successivi, dopo che il dispositivo ha iniziato a riprodurre l'audio.
• Latenza di input. L'intervallo tra il momento in cui un suono viene presentato dall'ambiente al dispositivo su un trasduttore on-device o il segnale entra nel dispositivo tramite una porta e il momento in cui un'applicazione legge il frame corrispondente dei dati codificati in PCM.
• Ha perso l'input. La parte iniziale di un segnale di input 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 è inattivo e spento prima della richiesta.
• Latenza di input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.
• latenza di viaggio avanti e indietro continua. La somma della latenza di input continua più la latenza di output continua più un periodo di buffer. Il periodo di buffer consente all'app di elaborare il segnale e di attenuare la differenza di fase tra gli stream di input e di output.
• API OpenSL ES PCM buffer queue. L'insieme di API OpenSL ES correlate al PCM in Android NDK.
• API audio nativa AAudio. L'insieme di API AAudio all'interno di Android NDK.
• Timestamp. Una coppia composta da una posizione relativa del frame all'interno di uno stream e dall'ora stimata in cui il frame entra o esce dalla pipeline di elaborazione audio nell'endpoint associato. Vedi anche AudioTimestamp.
• glitch. Un'interruzione temporanea o un valore del campione errato nel segnale audio, tipicamente causato da un underrun del buffer per l'output, da un overflow del buffer per l'input o da qualsiasi altra fonte di rumore digitale o analogico.
• Deviazione assoluta media (MAD). La media del valore assoluto delle deviazioni dalla media per un insieme di valori.

Inizio dei nuovi requisiti per Android 15

• La latenza tap-to-tone (TTL), misurata da CTS Verifier, è il tempo che intercorre tra il tocco sullo schermo e l'emissione di un suono generato dal tocco sullo speaker. Il valore è calcolato in media su 5 misurazioni utilizzando l'API audio nativa AAudio per l'output.

• La latenza di andata e ritorno (RTL), misurata dallo strumento di convalida CTS, è la latenza media continua su 5 misurazioni, misurata su un percorso di loopback che reimmette l'output nell'input, utilizzando l'API audio nativa AAudio. I percorsi loopback sono:

  • Altoparlante/microfono: dall'altoparlante integrato al microfono integrato.
  • Analogico: jack analogico da 3,5 mm e un adattatore di loopback.
  • USB: adattatore da USB a 3,5 mm e un adattatore loopback o un'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 Rendimento dei media.

• Latenza del monitoraggio della testa. Il tempo necessario dal movimento della testa acquisito dall'unità di misura inerziale (IMU) al rilevamento da parte dei trasduttori delle cuffie della variazione del suono causata da questo movimento.

Fine dei nuovi requisiti

Se le implementazioni del dispositivo dichiarano android.hardware.audio.output, devono soddisfare o superare i seguenti requisiti:

Inizio dei nuovi requisiti per Android 15

• [C-1-1] Il timestamp di output restituito da AudioTrack.getTimestamp e AAudioStream_getTimestamp è preciso con un'accuratezza di +/- 2 ms.

Fine dei nuovi requisiti

• [C-1-2] Latenza dell'output a freddo di massimo 500 millisecondi.

• [C-1-3] L'apertura di uno stream di output utilizzando AAudioStreamBuilder_openStream() DEVE impiegare meno di 1000 millisecondi.

Inizio dei nuovi requisiti per Android 15

• [C-1-4] Le latenze di round trip calcolate in base ai timestamp di input e output restituiti da AAudioStream_getTimestamp DEVONO essere comprese entro 200 ms dalla latenza di round trip misurata per AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY per altoparlanti e cuffie con cavo e wireless.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

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

• [C-SR-1] Latenza di uscita a freddo di massimo 100 millisecondi sul percorso di dati dell'altoparlante.

• [C-SR-2] Latenza da tocco a tono pari o inferiore a 80 millisecondi.

• [C-SR-4] È FORTEMENTE CONSIGLIATO che le latenze di andata e ritorno calcolate in base ai timestamp di input e output restituiti da AAudioStream_getTimestamp rientrino nel raggio di 30 ms della latenza di andata e ritorno misurata per AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY per altoparlanti e cuffie con cavo e wireless.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi soddisfano i requisiti sopra indicati, dopo la calibrazione iniziale, quando si utilizza l'API audio nativa AAudio, la latenza di uscita continua e la latenza di uscita a freddo su almeno un dispositivo di output audio supportato sono:

• [C-SR-5] È FORTEMENTE CONSIGLIATO segnalare l'audio a bassa latenza dichiarando il flag funzionalità android.hardware.audio.low_latency.
• [C-SR-6] È MOLTO CONSIGLIATO soddisfare i requisiti per l'audio con bassa latenza tramite l'API AAudio.
• [C-SR-7] È FORTEMENTE CONSIGLIATO assicurarsi che per gli stream che restituiscono AAUDIO_PERFORMANCE_MODE_LOW_LATENCY da AAudioStream_getPerformanceMode(), il valore restituito da AAudioStream_getFramesPerBurst() sia minore o uguale al valore restituito da android.media.AudioManager.getProperty(String) per la chiave della proprietà AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi non soddisfano i requisiti per l'audio a bassa latenza tramite l'API audio nativa AAudio,

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

Fine dei nuovi requisiti

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

Inizio dei nuovi requisiti per Android 15

• [C-3-1] Limita l'errore nei timestamp di input, come restituito da AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 2 ms. Per "errore" si intende la deviazione dal valore corretto.

Fine dei nuovi requisiti

• [C-3-2] Latenza dell'input a freddo di massimo 500 millisecondi.
• [C-3-3] L'apertura di uno stream di input utilizzando AAudioStreamBuilder_openStream() DEVE impiegare meno di 1000 millisecondi.

Inizio dei nuovi requisiti per Android 15

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

• [C-SR-8] Latenza di input a freddo non superiore a 100 millisecondi sul percorso dei dati del microfono.
• [C-SR-11] Limita l'errore nei timestamp di input, restituito da AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 1 ms.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

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

• [C-SR-12] È FORTEMENTE CONSIGLIATO avere una latenza media nel tempo di round trip continua di massimo 50 millisecondi su 5 misurazioni, con una deviazione assoluta media inferiore a 10 ms su almeno un percorso supportato.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

La tabella seguente definisce i requisiti per RTL per le implementazioni di dispositivi portatili come definito in 2.2.1 che dichiarano android.hardware.audio.output e android.hardware.microphone.

Dispositivo e dichiarazioni	RTL (ms)	MAD (ms)	Percorsi loopback
A mano	250	30	altoparlante/microfono, 3,5 mm analogico (se supportato), USB (se supportato)
>= MPC_T (14)	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	analog (se supportato)
FEATURE_AUDIO_PRO	25	5	USB (se l'analogico non è supportato)

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

La tabella seguente definisce i requisiti per il TTL per le implementazioni dei 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_T (14)	80
MPC_S (13)	100
FEATURE_AUDIO_PRO	80

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi includono il supporto di spatial audio con il monitoraggio della testa e dichiarano il flag PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, devono:

• [C-4-1] DEVE avere una latenza massima dal monitoraggio della testa all'aggiornamento audio di 300 ms.

Fine dei nuovi requisiti

5.7. Protocolli di rete

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

Per ogni codec e formato contenitore che un'implementazione del dispositivo deve supportare:

• [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 HTTP Live Streaming nella versione 7.

• [C-1-3] DEVE supportare i formati del 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	Riferimenti	Supporto dei codec obbligatori
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 sull'AAC e sulle sue varianti, consulta la sezione 5.1.3.
AAC con framing ADTS e tag ID3	ISO 13818-7	Consulta la sezione 5.1.1 per i dettagli sull'AAC e sulle sue varianti
WebVTT	WebVTT

RTSP (RTP, SDP)

Nome del profilo	Riferimenti	Supporto dei codec obbligatori
H264 AVC	RFC 6184	Consulta la sezione 5.1.8 per maggiori dettagli su H264 AVC
MP4A-LATM	RFC 6416	Consulta la sezione 5.1.3 per informazioni dettagliate sull'AAC e sulle sue varianti
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	Consulta la sezione 5.1.8 per informazioni dettagliate su MPEG-4 SP
mpeg4-generic	RFC 3640	Consulta la sezione 5.1.3 per informazioni dettagliate sull'AAC e sulle sue varianti
MP2T	RFC 2250	Per maggiori dettagli, consulta Flusso di trasporto MPEG-2 in HTTP Live Streaming

5.8. Contenuti multimediali sicuri

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

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

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

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

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

• [C-3-1] DEVE supportare HDCP 1.2 o versioni successive per tutti gli schermi esterni 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 android.content.pm.PackageManager classe, devono:

• [C-1-1] DEVE supportare il 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 over Bluetooth LE nel ruolo centrale, sezione 7.4.3

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

• [C-1-3] DEVE includere libamidi.so (supporto MIDI nativo)

• DOVREBBE supportare il MIDI in modalità periferica USB, sezione 7.7

5.10. Audio professionale

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

• [C-1-1] È OBBLIGATORIO segnalare il supporto della funzionalitàandroid.hardware.audio.low_latency.

Inizio dei nuovi requisiti per Android 15

• [C-1-2] DEVE avere una latenza audio nel tempo di round trip, soddisfare i requisiti di latenza per FEATURE_AUDIO_PRO come definito nella sezione 5.6 Latenza audio di almeno 25 millisecondi su almeno un percorso supportato.

Fine dei nuovi requisiti

• [C-1-3] DEVE includere una o più porte USB che supportano la modalità host USB e la modalità periferica USB.
• [C-1-4] DEVE segnalare il supporto della funzionalità android.software.midi.

Inizio dei nuovi requisiti per Android 15

• [C-1-5] DEVE soddisfare i requisiti relativi alle latenze e alla latenza dell'audio USB utilizzando l'API audio nativo AAudio e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

Fine dei nuovi requisiti

• [C-1-6] DEVE avere una latenza di output a freddo di massimo 200 millisecondi.
• [C-1-7] DEVE avere una latenza di input a freddo di massimo 200 millisecondi.

Inizio dei nuovi requisiti per Android 15

• [C-1-8] DEVE avere una latenza media Tap-to-tone di massimo 80 millisecondi su almeno 5 misurazioni lungo il percorso dati dallo speaker al microfono.
• [C-SR-1] È FORTEMENTE CONSIGLIATO di soddisfare le latenze come definite nella sezione 5.6 Latenza audio, pari o inferiori a 20 millisecondi, su 5 misurazioni con una deviazione assoluta media inferiore a 5 millisecondi sul percorso dallo speaker al microfono.
• [C-SR-2] È FORTEMENTE CONSIGLIATO soddisfare i requisiti di Pro Audio per la latenza audio in tempo reale, la latenza di entrata a freddo e la latenza di uscita a freddo e i requisiti audio USB utilizzando l'API AAudio native audio sul percorso MMAP.

• [C-SR-3] Sono FORTEMENTE CONSIGLIATI per fornire un livello costante di prestazioni della CPU mentre l'audio è attivo e il carico della CPU varia. Questo deve essere testato utilizzando l'app per Android SynthMark. SynthMark utilizza un sintetizzatore software in esecuzione su un framework audio simulato che misura le prestazioni del sistema. Per una spiegazione dei benchmark, consulta la documentazione di SynthMark. L'app SynthMark deve essere eseguita utilizzando l'opzione "Test automatico" e deve ottenere i seguenti risultati:

  • voicemark.90 >= 32 voci
  • latencymark.fixed.little <= 15 msec
  • latencymark.dynamic.little <= 50 msec

• DOVREBBE ridurre al minimo l'inaccuratezza e lo scostamento dell'orologio audio rispetto all'ora standard.

• DOVREBBE ridurre al minimo lo scostamento dell'orologio audio rispetto alla CPU CLOCK_MONOTONIC quando entrambe sono attive.

• DEVE ridurre al minimo la latenza audio sui trasduttori sul dispositivo.

• DEVE ridurre al minimo la latenza audio tramite l'audio digitale USB.

• DOVREBBE documentare le misurazioni della latenza audio su tutti i percorsi.

• DOVREBBE ridurre al minimo il jitter nei tempi di inserimento del callback di completamento del buffer audio, in quanto influisce sulla percentuale utilizzabile della larghezza di banda completa della CPU dal callback.

• NON DEVE presentare glitch audio durante l'uso normale con la latenza indicata.

• DOVREBBE fornire una differenza di latenza intercanale pari a zero.

• DOVREBBE ridurre al minimo la latenza media MIDI su tutti i trasporti.

• DOVREBBE ridurre al minimo la variabilità della latenza MIDI sotto carico (jitter) su tutti i trasporti.

• DOVREBBE fornire timestamp MIDI accurati su tutti i trasporti.

• DOVREBBE ridurre al minimo il rumore del segnale audio sui trasduttori sul dispositivo, incluso il periodo immediatamente successivo all'avvio a freddo.

• DEVE fornire una differenza di clock audio pari a zero tra i lati di input e di output degli endpoint corrispondenti, quando entrambi sono attivi. Alcuni esempi di endpoint corrispondenti sono il microfono e lo speaker sul dispositivo o l'ingresso e l'uscita del jack audio.

• DEVE gestire i callback di completamento del buffer audio per i lati di input e di output degli endpoint corrispondenti sullo stesso thread quando entrambi sono attivi e deve inserire il callback di output immediatamente dopo il ritorno dal callback di input. In alternativa, se non è possibile gestire i callback nello stesso thread, inserisci il callback di output poco dopo aver inserito il callback di input per consentire all'applicazione di avere una temporizzazione coerente dei lati di input e output.

• DEVE ridurre al minimo la differenza di fase tra il buffering audio HAL per i lati di input e di output degli endpoint corrispondenti.

• DEVE ridurre al minimo la latenza del tocco.

• DOVREBBE ridurre al minimo la variabilità della latenza tocco sotto carico (jitter).

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

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

• [C-SR-4] È MOLTO CONSIGLIATO segnalare il supporto della funzionalità android.hardware.audio.pro tramite la classe android.content.pm.PackageManager.

Fine dei nuovi requisiti

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

Inizio dei nuovi requisiti per Android 15

• [C-2-1] DEVE avere una latenza audio media nel tempo di round trip continuo, come definito nella sezione 5.6 Latenza audio, pari o inferiore a 20 millisecondi, su 5 misurazioni con una deviazione assoluta media inferiore a 5 millisecondi sul percorso del jack audio utilizzando un dongle audio loopback.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

• [C-2-2] [C-SR-5] È FORTEMENTE CONSIGLIATO DEVE rispettare la sezione Specifiche del dispositivo mobile (jack) della Specifica per cuffie audio con cavo (v1.1).

Fine dei nuovi requisiti

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] È NECESSARIO implementare la classe audio USB.

Inizio dei nuovi requisiti per Android 15

• [C-3-2] DEVE avere una latenza audio di andata e ritorno continua media di almeno 25 millisecondi, su 5 misurazioni con una deviazione assoluta media inferiore a 5 millisecondi sulla porta in modalità host USB utilizzando la classe audio USB. Questo valore può essere misurato utilizzando un adattatore USB-3, 5 mm e un dongle Audio Loopback oppure un'interfaccia audio USB con cavi patch che collegano le entrate alle uscite.
• [C-SR-6] È FORTEMENTE CONSIGLIATO supportare l'I/O simultanea fino a 8 canali in ogni direzione, frequenza di campionamento di 96 kHz e profondità di 24 o 32 bit, se utilizzati con periferiche audio USB che supportano anche questi requisiti.
• [C-SR-7] È FORTEMENTE CONSIGLIATO soddisfare questo gruppo di requisiti utilizzando l'API audio nativa AAudio tramite il percorso MMAP.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

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

• DEVE supportare l'uscita in stereo e otto canali a una profondità di 20 o 24 bit e 192 kHz senza perdita di profondità di bit o ricampionamento, in almeno una configurazione.

Fine dei nuovi requisiti

5.11. Acquisisci per non elaborato

Android include il supporto per la registrazione di audio non elaborato tramite la android.media.MediaRecorder.AudioSource.UNPROCESSED sorgente audio. In OpenSL ES, è possibile accedervi con la preimpostazione 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, devono:

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

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

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

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

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

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

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

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

  • [C-1-9] Se per qualsiasi motivo nell'architettura è presente un'elaborazione del segnale, DEVE essere disattivata e deve essere introdotta una latenza aggiuntiva o un ritardo zero 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 prova. Per più configurazioni di 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, devono:

• [C-2-1] DEVE restituire null per il metodo dell'API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) per indicare correttamente la mancanza di supporto.
• [C-SR-1] sono comunque FORTEMENTE CONSIGLIATI per soddisfare il maggior numero possibile di requisiti per il percorso del segnale per l'origine 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 decodificatore video pubblicizza il supporto di COLOR_FormatYUVP010:

• [C-1-1] DEVE supportare il formato P010 per la lettura da CPU (ImageReader, MediaImage, ByteBuffer). In Android 13, la regola P010 è meno restrittiva per consentire uno stride arbitrario per i piani Y e UV.

• [C-1-2] Il buffer di output P010 DEVE essere in grado di essere campionato dalla GPU (quando allocato con l'utilizzo GPU_SAMPLING). In questo modo, le app possono eseguire la composizione GPU e la mappatura tonale personalizzata.

Se un decodificatore video pubblicizza il supporto di COLOR_Format32bitABGR2101010:

• [C-2-1] DEVE supportare il formato RGBA_1010102 per la superficie di output e essere leggibile dalla CPU (output ByteBuffer).

Se un codificatore video pubblicizza il supporto di COLOR_FormatYUVP010:

• [C-3-1] DEVE supportare il formato P010 per l'input della superficie e per l'input scrivibile dalla CPU (ImageWriter, MediaImage, ByteBuffer).

Nota: in Android 13, la regola P010 è stata allentata per consentire uno stride arbitrario per i piani Y e UV. (Questo formato P010 POTREBBE essere ottimizzato e diverso dal formato P010 di Camera2.)

Se un codificatore video pubblicizza il supporto di COLOR_Format32bitABGR2101010:

• [C-4-1] DEVE supportare il formato RGBA_1010102 per l'input della superficie e per l'input scrivibile dalla CPU (ImageWriter, ByteBuffer). Nota: la conversione tra varie curve di trasferimento NON è obbligatoria per gli encoder.

Requisiti per l'acquisizione HDR

Per tutti gli encoder video che supportano i profili HDR, le implementazioni dei dispositivi:

• [C-5-1] NON DEVE dare per scontato che i metadati HDR siano precisi. Ad esempio, il frame codificato potrebbe avere pixel oltre il livello di luminanza di picco o l'istogramma potrebbe non essere rappresentativo del frame.

• DEVONO aggregare i metadati dinamici HDR per generare metadati statici HDR appropriati per gli stream codificati e devono eseguirne l'output al termine di ogni sessione di codifica.

Se le implementazioni dei dispositivi supportano l'acquisizione HDR utilizzando le API CamcorderProfile:

• [C-6-1] DEVE supportare anche l'acquisizione HDR 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 applicabili alla tecnologia HDR) nel file video acquisito. Per AV1, HEVC e DolbyVision, questo significa includere i metadati nel flusso di bit codificato.

• [C-6-5] DEVE supportare P010 e COLOR_FormatYUVP010.

• [C-6-6] DEVE supportare la mappatura tonale HDR-SDR nel decodificatore con accelerazione hardware predefinito per il profilo acquisito. In altre parole, se un dispositivo può acquisire HDR10+ HEVC, il decodificatore HEVC predefinito DEVE essere in grado di decodificare lo stream acquisito in SDR.

Requisiti per l'editing HDR

Se le implementazioni dei dispositivi includono codificatori video che supportano l'editing HDR:

• DOVREBBE utilizzare una latenza minima per generare i metadati HDR quando non sono presenti e DOVREBBE gestire in modo elegante le situazioni in cui i metadati sono presenti per alcuni fotogrammi e non per altri. Questi metadati DEVONO essere precisi (ad esempio, rappresentare la luminanza di picco e l'istogramma effettivi dell'inquadratura).

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] DEVONO supportare FEATURE_HdrEditing per tutti i profili HDR pubblicizzati da quel codec. In altre parole, DEVONO supportare la generazione di metadati HDR se non sono presenti per tutti i profili HDR supportati che li utilizzano.

• [C-7-3] DEVE supportare i seguenti formati di input del codificatore video che preservano completamente il segnale decodificato HDR:

  • RGBA_1010102 (già presente nella curva di trasferimento target) sia per la superficie di input sia per ByteBuffer e DEVE pubblicizzare il supporto di COLOR_Format32bitABGR2101010.

Se l'implementazione del dispositivo include codec che supportano FEATURE_HdrEditing, il dispositivo:

• [C-7-4] DEVE pubblicizzare il supporto dell'estensione OpenGL EXT_YUV_target.

6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori

6.1. Strumenti per sviluppatori

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare gli strumenti per sviluppatori Android forniti nell'SDK Android.
• Android Debug Bridge (ADB)

Inizio dei nuovi requisiti per Android 15

• [C-0-2] DEVE supportare adb come descritto nell'SDK Android e i comandi shell forniti in AOSP, che possono essere utilizzati dagli sviluppatori di app, tra cui dumpsys, cmd stats e Simpleperf.

Fine dei nuovi requisiti

• [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 persistenti POTREBBE essere esente 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.

Inizio dei nuovi requisiti per Android 15

• [C-0-10] DEVE registrare, senza omissioni, e rendere accessibili e disponibili i seguenti eventi al comando cmd stats shell e alla classe dell'API System StatsManager.
  • ActivityForegroundStateChanged
  • AnomalyDetected
  • AppBreadcrumbReported
  • AppCrashOccurred
  • AppStartOccurred
  • BatteryLevelChanged
  • BatterySaverModeStateChanged
  • BleScanResultReceived
  • BleScanStateChanged
  • ChargingStateChanged
  • DeviceIdleModeStateChanged
  • ForegroundServiceStateChanged
  • GpsScanStateChanged
  • InputDeviceUsageReported
  • JobStateChanged
  • KeyboardConfigured
  • KeyboardSystemsEventReported
  • PluggedStateChanged
  • ScheduledJobStateChanged
  • ScreenStateChanged
  • SyncStateChanged
  • SystemElapsedRealtime
  • TouchpadUsage
  • UidProcessStateChanged
  • WakelockStateChanged
  • WakeupAlarmOccurred
  • WifiLockStateChanged
  • WifiMulticastLockStateChanged
  • WifiScanStateChanged

Fine dei nuovi requisiti

• [C-0-4] È obbligatorio che il daemon adb lato dispositivo sia inattivo per impostazione predefinita e deve essere presente un meccanismo accessibile all'utente per attivare Android Debug Bridge.
• [C-0-5] DEVE supportare adb sicuro. Android include il supporto per adb sicuro. adb sicuro attiva adb su host autenticati noti.
• [C-0-6] DEVE fornire un meccanismo che consenta di connettere adb da una macchina host. Nello specifico:

Se le implementazioni dei dispositivi senza porta USB supportano la modalità periferica:

• [C-3-1] È OBBLIGATORIO implementare adb tramite una rete locale (ad esempio Ethernet o Wi-Fi).
• [C-3-2] DEVE fornire i 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, devono:

• [C-4-1] DEVE avere il metodo AdbManager#isAdbWifiSupported() che restituisce true.

Se le implementazioni dei dispositivi supportano le connessioni adb a una macchina host tramite Wi-Fi o Ethernet e includono almeno una videocamera, devono:

• [C-5-1] È OBBLIGATORIO che il metodo AdbManager#isAdbWifiQrSupported() restituisca true.

• Dalvik Debug Monitor Service (ddms)

  • [C-0-7] DEVE supportare tutte le funzionalità ddms come documentato nell'SDK Android. Poiché ddms utilizza adb, il supporto di ddms DOVREBBE essere inattivo per impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato Android Debug Bridge, come sopra.

• SysTrace

  • [C-0-9] DEVE supportare lo strumento systrace come descritto nell'SDK Android. Systrace deve essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile agli utenti per attivarlo.

• Perfetto

  • [C-SR-1] È FORTEMENTE CONSIGLIATO esporre un file /system/bin/perfetto binario all'utente della shell la cui cmdline sia conforme alla documentazione di perfetto.
  • [C-SR-2] È MOLTO CONSIGLIATO che il file binario di perfetto accetti come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
  • [C-SR-3] È MOLTO CONSIGLIATO scrivere come output del file binario di perfetto una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
  • [C-SR-4] È FORTEMENTE CONSIGLIATO di fornire, tramite il file binario perfetto, almeno le origini dati descritte nella documentazione di perfetto.

• Low Memory Killer

  • [C-0-12] È OBBLIGATORIO scrivere un atomo LMK_KILL_OCCURRED_FIELD_NUMBER nel log di statsd quando un'app viene interrotta dal Low Memory Killer.

• Modalità Test Harness Se le implementazioni dei dispositivi supportano il comando shell cmd testharness e eseguono cmd testharness enable, devono:

  • [C-2-1] DEVE restituire true per ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] È NECESSARIO implementare la modalità Test Harness come descritto nella documentazione della modalità Test Harness.

• Informazioni sul lavoro della GPU

  Implementazioni dei dispositivi:

  • [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 di 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 GPU.
• [C-1-2] DEVE, quando i livelli di debug della GPU sono abilitati, enumerare i livelli nelle librerie fornite da strumenti esterni (ovvero non facenti parte della piattaforma o del pacchetto dell'applicazione) trovati nella directory di base delle applicazioni di debug per supportare i metodi dell'API vkEnumerateInstanceLayerProperties() e vkCreateInstance().

6.2. Opzioni sviluppatore

Android include il supporto per la configurazione da parte degli sviluppatori delle impostazioni relative allo sviluppo delle applicazioni.

Le implementazioni dei dispositivi DEVONO fornire un'esperienza coerente per le opzioni sviluppatore:

• [C-0-1] DEVE rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo delle applicazioni. L'implementazione di Android upstream nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avviare le Opzioni sviluppatore dopo aver premuto sette (7) volte l'elemento di menu Impostazioni > Informazioni sul dispositivo > Numero build.
• [C-0-2] DEVE nascondere le Opzioni sviluppatore per impostazione predefinita.
• [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. DEVI fornire un documento o un sito web pubblico visibile che descriva come attivare le Opzioni sviluppatore. Questo documento o sito web DEVE essere collegabile dalla documentazione dell'SDK Android.
• DOVREBBE avere una notifica visiva continua per l'utente quando le Opzioni sviluppatore sono attivate e la sicurezza dell'utente è in discussione.
• PUÒ limitare temporaneamente l'accesso al menu Opzioni sviluppatore nascondendolo o disattivandolo visivamente per evitare distrazioni in scenari in cui la sicurezza dell'utente è in discussione.

7. Compatibilità hardware

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

• [C-0-1] L'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android.

Se un'API nell'SDK interagisce con un componente hardware dichiarato facoltativo e l'implementazione del dispositivo non dispone di questo componente:

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

Un esempio tipico di uno scenario in cui si applicano questi requisiti è l'API di telefonia: anche su dispositivi diversi dai telefoni, queste API devono essere implementate come no-op ragionevoli.

7.1. Display e grafica

Android include funzionalità che regolano automaticamente gli asset dell'applicazione e i layout dell'interfaccia utente in base al dispositivo per garantire il corretto funzionamento delle applicazioni di terze parti su una serie di configurazioni e display hardware. Un display compatibile con Android è uno schermo che implementa tutti i comportamenti e le API descritti nella pagina Android for Developers - Panoramica della compatibilità dello schermo, in questa sezione (7.1) e nelle relative sottosezioni, nonché eventuali comportamenti aggiuntivi specifici per il tipo di dispositivo documentati nella sezione 2 del presente CDD.

Implementazioni dei dispositivi:

• [C-0-1] PER IMPOSTAZIONE PREDEFINITA, DEVE 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 inclusi in un intervallo lineare horizontale o verticale di 2,54 cm, espresso in pixel per pollice (ppi o dpi). Se sono elencati i valori ppi e dpi, i dpi orizzontali e verticali devono rientrare nell'intervallo elencato.
• proporzioni. Il rapporto tra i pixel della dimensione più lunga e la dimensione più corta dello schermo. Ad esempio, un display di 480 x 854 pixel è uguale a 854/480 = 1,779, ovvero approssimativamente "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 schermo

7.1.1.1. Dimensioni e forma dello schermo

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

Implementazioni dei dispositivi:

• [C-0-1] DEVE riportare le dimensioni corrette del layout perConfiguration.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) logiche corrette come indicato di seguito:

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

• [C-0-2] 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 schermate con configurazione delle dimensioni UI_MODE_TYPE_NORMAL e utilizzano display fisici con angoli arrotondati per il rendering di queste schermate, devono:

• [C-1-1] DEVI assicurarti che per ogni visualizzazione sia soddisfatto almeno uno dei seguenti requisiti:

  • Il raggio degli angoli arrotondati è inferiore o uguale a 38 dp.
  • Quando una casella di 18 dp per 18 dp è ancorata a ogni angolo della visualizzazione logica, sullo schermo è visibile almeno un pixel di ogni casella.

• DEVE includere l'affordance per consentire all'utente di passare alla modalità di visualizzazione con gli angoli rettangolari.

Se le implementazioni dei dispositivi sono in grado di supportare solo la configurazione della tastiera NO_KEYS e intendono segnalare il supporto della configurazione della modalità UI UI_MODE_TYPE_NORMAL:

• [C-4-1] DEVE avere dimensioni del layout, esclusi eventuali ritagli del display, di almeno 596 dp x 384 dp o superiori.

Per informazioni dettagliate sull'implementazione corretta delle API sidecar o di estensione, consulta la documentazione pubblica di Window Manager Jetpack.

Inizio dei nuovi requisiti per Android 15

Se le implementazioni dei dispositivi includono una o più aree di visualizzazione compatibili con Android che sono pieghevoli o includono un perno di piegatura tra più aree del pannello di visualizzazione compatibili con Android e rendono queste aree di visualizzazione disponibili per le applicazioni, devono:

• [C-4-1] DEVE implementare la versione corretta del livello API di Window Manager Extensions come descritto in WindowManager Extensions.

Fine dei nuovi requisiti

7.1.1.2. Proporzioni dello schermo

Questa sezione è stata eliminata 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 dell'applicazione.

Implementazioni del dispositivo:

• [C-0-1] DEVE essere indicata una delle densità del framework Android elencate su DisplayMetrics tramite l'API DENSITY_DEVICE_STABLE e questo valore deve essere un valore statico per ogni display fisico. Tuttavia, il dispositivo PUÒ registrare un valore DisplayMetrics.density diverso in base alle modifiche alla configurazione del display apportate dall'utente (ad esempio le dimensioni del display) impostate dopo l'avvio iniziale.

• DOVREBBE definire la densità del framework Android standard numericamente più vicina alla densità fisica dello schermo o un valore che corrisponda alle stesse misurazioni angolari equivalenti del campo visivo di un dispositivo portatile.

Se le implementazioni del dispositivo forniscono un'opzione per cambiare le dimensioni del display, devono:

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

7.1.2. Metriche relative alla visualizzazione

Se le implementazioni dei dispositivi includono uno o più display compatibili con Android o l'output video sugli schermi dei display compatibili con Android, devono:

• [C-1-1] DEVE riportare valori corretti per tutte le metriche di visualizzazione compatibili con Android definite nell'API android.util.DisplayMetrics.

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

• [C-2-1] DEVE riportare i valori corretti del display compatibile con Android come definito nell'API android.util.DisplayMetrics per il valore predefinito view.Display emulato.

7.1.3. Orientamento schermo

Implementazioni dei dispositivi:

• [C-0-1] DEVE indicare gli orientamenti dello schermo supportati (android.hardware.screen.portrait e/o android.hardware.screen.landscape) e DEVE indicare almeno un orientamento supportato. Ad esempio, un dispositivo con uno schermo in orientamento orizzontale fisso, come una TV o un laptop, DOVREBBE registrare solo android.hardware.screen.landscape.
• [C-0-2] DEVE riportare il valore corretto per l'orientamento corrente del dispositivo ogni volta che viene eseguito una query tramite android.content.res.Configuration.orientation, android.view.Display.getOrientation() o altre API.

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

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

7.1.4. Accelerazione grafica 2D e 3D

7.1.4.1. OpenGL ES

Implementazioni dei dispositivi:

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

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

Inizio dei nuovi requisiti per Android 15

• [C-1-1] DEVE supportare sia OpenGL ES 1.1, sia 2.0, 3.0 e 3.1, come descritto e dettagliato nella documentazione dell'SDK Android.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

• [C-SR-1] È VIVAMENTE CONSIGLIATO supportare OpenGL ES 3.1.

Fine dei nuovi requisiti

• DOVREBBE supportare OpenGL ES 3.2.

I test OpenGL ES dEQP sono suddivisi in una serie di elenchi di test, ciascuno con un numero di data/versione associato. Si trovano nella struttura della sorgente di Android in external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Un dispositivo che supporta OpenGL ES a un livello autodichiarato indica che può superare i test dEQP in tutti gli elenchi di test a partire da questo livello e precedenti.

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

• [C-2-1] DEVE segnalare tramite le API OpenGL ES gestite e le API native eventuali altre estensioni OpenGL ES che ha implementato e, al contrario, NON DEVE segnalare le stringhe di estensione che non supporta.
• [C-2-2] DEVE supportare le estensioni EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable e EGL_ANDROID_GLES_layers.
• [C-2-3] DEVE segnalare la versione massima dei test dEQP OpenGL ES 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 riportato nel flag della funzionalità android.software.opengles.deqp.level.
• [C-2-5] DEVE superare tutti i test dEQP OpenGL ES negli elenchi di test tra la versione 132383489 e la versione specificata nel android.software.opengles.deqp.level feature flag, per ogni versione supportata OpenGL ES.
• [C-SR-2] È MOLTO CONSIGLIATO 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 del dispositivo dichiarano il supporto di OpenGL ES 3.0, 3.1 o 3.2:

• [C-3-1] È NECESSARIO esportare i simboli di funzione corrispondenti per queste versioni oltre ai simboli di funzione OpenGL ES 2.0 nella libreria libGLESv2.so.
• [C-SR-3] È MOLTO CONSIGLIATO supportare l'estensione OES_EGL_image_external_essl3.

Se le implementazioni del dispositivo supportano OpenGL ES 3.2:

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

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

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

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

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

7.1.4.2. Vulkan

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

Se le implementazioni del dispositivo supportano OpenGL ES 3.1:

• [C-SR-1] È FORTEMENTE CONSIGLIATO includere il supporto per Vulkan 1.3.
• [C-4-1] NON DEVE supportare una versione della variante Vulkan (ovvero la parte della variante della versione di Vulkan DEVE essere pari a zero).

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

• [C-SR-2] È FORTEMENTE CONSIGLIATO includere il supporto per Vulkan 1.3.

I test Vulkan dEQP sono suddivisi in una serie di elenchi di test, ciascuno con una data/versione associata. Si trovano nella struttura della sorgente di Android in external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Un dispositivo che supporta Vulkan a un livello autodichiarato indica che può superare i test dEQP in tutti gli elenchi di test a partire da questo livello e precedenti.

Se le implementazioni del dispositivo includono il supporto di Vulkan:

• [C-1-1] DEVE riportare il valore intero corretto con i flag di funzionalità android.hardware.vulkan.level e android.hardware.vulkan.version.
• [C-1-2] DEVE elencare almeno un VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices().
• [C-1-3] DEVE implementare completamente le API Vulkan 1.1 per ogni enumeratoVkPhysicalDevice.
• [C-1-4] DEVE enumerare i livelli contenuti nelle librerie native denominate libVkLayer*.so nella directory delle librerie native del pacchetto dell'applicazione, tramite le API native di Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties().
• [C-1-5] NON DEVE enumerare i livelli forniti dalle librerie al di fuori del package dell'applicazione o 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.
• [C-1-6] DEVE segnalare tutte le stringhe di estensione supportate tramite le API native Vulkan e, al contrario, NON DEVE segnalare le stringhe di estensione non supportate correttamente.
• [C-1-7] DEVE supportare le estensioni VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain e VK_KHR_incremental_present.
• [C-1-8] È OBBLIGATORIO 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 riportato nel flag della funzionalità android.software.vulkan.deqp.level.
• [C-1-10] DEVE superare tutti i test Vulkan dEQP negli elenchi di test tra la versione 132317953 e la versione specificata nel flag di 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] È MOLTO CONSIGLIATO supportare le estensioni VK_KHR_driver_properties e VK_GOOGLE_display_timing.
• [C-1-12] NON DEVE elencare il supporto per l'estensione VK_KHR_performance_query.
• [C-SR-4] È FORTEMENTE CONSIGLIATO soddisfare i requisiti specificati dal profilo Android Baseline 2022.
• [C-SR-5] È MOLTO CONSIGLIATO supportare VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory e VK_EXT_global_priority.
• [C-SR-6] È MOLTO CONSIGLIATO utilizzare SkiaVk con HWUI.

Inizio dei nuovi requisiti per Android 15

Se le implementazioni del dispositivo includono il supporto di Vulkan, devono:

• [C-SR-8] È FORTEMENTE CONSIGLIATO di non modificare il caricatore Vulkan.
• [C-1-14] NON DEVE elencare le estensioni del dispositivo Vulkan di tipo "KHR", "GOOGLE" o "ANDROID", a meno che queste estensioni non siano incluse nel android.software.vulkan.deqp.level flag della funzionalità.

Fine dei nuovi requisiti

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 elencare alcun VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices().

Se le implementazioni dei dispositivi includono il supporto per Vulkan 1.1 e dichiarano uno qualsiasi dei flag delle funzionalità di Vulkan descritti qui, questi:

• [C-3-1] DEVE esporre il supporto per i tipi di handle e semafori esterni SYNC_FD e l'estensione VK_ANDROID_external_memory_android_hardware_buffer.

• [C-SR-7] È FORTEMENTE CONSIGLIATO rendere disponibile l'estensione VK_KHR_external_fence_fd alle applicazioni di terze parti e consentire all'applicazione di esportare il payload della recinzione e di importarne uno dai descrittori di file POSIX come descritto qui.

7.1.4.3. RenderScript

Implementazioni dei dispositivi:

• [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 per consentire alle applicazioni di dichiarare di voler attivare l'accelerazione hardware per la grafica 2D a livello di applicazione, attività, finestra o visualizzazione tramite l'utilizzo di un tag manifest android:hardwareAccelerated o di chiamate API dirette.

Implementazioni dei dispositivi:

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

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

Implementazioni dei dispositivi:

• [C-0-3] DEVE supportare l'API TextureView e DEVE mostrare un comportamento coerente con l'implementazione Android a monte.

7.1.4.5. Display con gamma di colori ampliata

Se le implementazioni dei dispositivi dichiarano di supportare i display a gamma estesa tramite Configuration.isScreenWideColorGamut():

• [C-1-1] DEVE avere un display calibrato a colori.
• [C-1-2] DEVE avere un display la cui gamma copra interamente la gamma di colori sRGB nello spazio xyY CIE 1931.
• [C-1-3] DEVE avere un display la cui gamma ha un'area di almeno il 90% di DCI-P3 nello spazio xyY CIE 1931.
• [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] È MOLTO CONSIGLIATO supportare GL_EXT_sRGB.

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

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

7.1.5. Modalità di compatibilità delle applicazioni precedenti

Android specifica una "modalità di compatibilità" in cui il framework opera in una modalità equivalente a una dimensione dello schermo "normale" (larghezza di 320 dp) a vantaggio delle applicazioni precedenti non sviluppate per le versioni precedenti di Android che risalgono a prima dell'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 definite 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] DEVE essere in grado di eseguire il rendering di grafica a colori a 16 bit.
• DOVREBBE supportare i display in grado di gestire la grafica a colori a 24 bit.
• [C-0-2] DEVE essere in grado di eseguire il rendering delle animazioni.
• [C-0-3] DEVE avere un formato pixel (PAR) tra 0,9 e 1,15. In altre parole, 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 i display secondari compatibili con Android per attivare le funzionalità di condivisione dei contenuti multimediali e le API per sviluppatori per accedere ai display esterni.

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

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

7.2. Dispositivi di immissione

Implementazioni dei dispositivi:

• [C-0-1] DEVE includere un meccanismo di input, ad esempio un touchscreen o la navigazione non touch, per spostarsi tra gli elementi dell'interfaccia utente.

7.2.1. Tastiera

Se le implementazioni dei dispositivi includono il supporto di applicazioni di editor di metodi di inserimento (IME) di terze parti, devono:

• [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità android.software.input_methods.
• [C-1-2] DEVE essere implementato completamente Input Management Framework
• [C-1-3] DEVE avere una tastiera software preinstallata.

Implementazioni dei dispositivi:

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

7.2.2. Navigazione non tocco

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

Implementazioni dei dispositivi:

• [C-0-1] DEVE riportare il valore corretto per android.content.res.Configuration.navigation.

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

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

7.2.3. Tasti di navigazione

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

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

Se sono fornite le funzioni Home, Recenti o Indietro:

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

Implementazioni dei dispositivi:

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

• [C-SR-2] È FORTEMENTE CONSIGLIATO di fornire tutte le funzioni di navigazione come annullabili. Per "Annullabile" si intende 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 dei dispositivi forniscono la funzione Menu, devono:

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

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

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

Se le implementazioni dei dispositivi forniscono la funzione di assistenza,

• [C-4-1] 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] È FORTEMENTE CONSIGLIATO di utilizzare la pressione prolungata sulla funzione HOME come interazione designata.

Se le implementazioni del dispositivo utilizzano una parte distinta dello schermo per visualizzare i pulsanti 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 coprire o interferire in altro modo con la parte dello schermo disponibile per le applicazioni.
• [C-5-2] DEVE rendere disponibile una parte del display per le applicazioni chesoddisfano i requisiti definiti nella sezione 7.1.1.
• [C-5-3] DEVE rispettare i flag impostati dall'app tramite il metodo dell'API View.setSystemUiVisibility(), in modo che questa parte distinta della schermata (ovvero la barra di navigazione) sia nascosta correttamente come descritto 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 dei gesti della casa.
• [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 di esclusione massimo specificato nella documentazione per View#setSystemGestureExclusionRects().
• [C-6-3] DEVE inviare all'app in primo piano un MotionEvent.ACTION_CANCEL evento quando i tocchi iniziano a essere intercettati per un gesto di sistema, se all'app in primo piano è stato inviato in precedenza un MotionEvent.ACTION_DOWN evento.
• [C-6-4] DEVE fornire all'utente la possibilità di passare a una navigazione sullo schermo basata su pulsanti (ad esempio nelle Impostazioni).
• DOVREBBE fornire la funzione Home con uno scorrimento verso l'alto dal bordo inferiore dell'orientamento corrente dello schermo.
• DOVREBBE fornire la funzionalità Recenti con uno scorrimento verso l'alto e una pressione prolungata prima del rilascio, dalla stessa area del gesto Home.
• I gesti che iniziano all'interno di 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 corrente dello schermo:

• [C-7-1] La funzione di navigazione DEVE essere Indietro e deve essere fornita come scorrimento dai bordi sinistro e destro dell'orientamento corrente dello schermo.
• [C-7-2] Se sono disponibili pannelli di sistema scorrevoli personalizzati sui bordi sinistro o destro, questi DEVONO essere posizionati nel terzo superiore dello schermo con un'indicazione visiva chiara e persistente che indichi che lo scorrimento verso l'interno attiverà i pannelli sopra menzionati e quindi non Indietro. Un riquadro di sistema PUÒ essere configurato da un utente in modo da apparire sotto il 1/3 superiore dei bordi dello schermo, ma NON deve occupare più di 1/3 dei bordi.
• [C-7-3] Quando nell'app in primo piano sono impostati 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, 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 riquadri di sistema scorrevoli personalizzati DEVONO essere nascosti finché l'utente non attiva o attenua le barre di sistema (ovvero barra di navigazione e barra di stato) come implementato in AOSP.

Se è fornita la funzione di navigazione a ritroso e l'utente annulla il gesto Indietro:

• [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:

• Il sistema DEVE fornire un'animazione per l'applicazione in primo piano che suggerisca all'utente che sta tornando indietro, come previsto in AOSP.

Se le implementazioni dei dispositivi supportano l'API di sistema setNavBarMode per consentire a qualsiasi app di sistema con autorizzazione android.permission.STATUS_BAR di impostare la modalità della barra di navigazione, devono:

• [C-9-1] DEVE fornire il supporto di icone adatte ai bambini o di navigazione basata su pulsanti come indicato nel codice AOSP.

7.2.4. Input touchscreen

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

Implementazioni dei dispositivi:

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

Se le implementazioni del dispositivo includono un touchscreen (monotocco o superiore) su un display principale compatibile con Android, devono:

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

Se le implementazioni del dispositivo includono un touchscreen in grado di rilevare più di un singolo tocco su un display principale compatibile con Android, devono:

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

Se le implementazioni dei dispositivi si basano su un dispositivo di input esterno come mouse o trackball (ovvero non toccano direttamente lo schermo) per l'input su un display principale compatibile con Android e soddisfano i requisiti di tocco falso descritti nella sezione 7.2.5, devono:

• [C-3-1] NON DEVE segnalare alcun flag della funzionalità che inizia con android.hardware.touchscreen.
• [C-3-2] DEVE essere riportato solo android.hardware.faketouch.
• [C-3-3] È OBBLIGATORIO segnalare TOUCHSCREEN_NOTOUCH per il campo dell'API Configuration.touchscreen.

7.2.5. Input tocco simulato

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

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

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

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

• [C-1-1] DEVE indicare le posizioni sullo schermo X e Y assolute della posizione del cursore e mostrare un cursore visivo sullo schermo.
• [C-1-2] È OBBLIGATORIO segnalare l'evento tocco con il codice di azione che specifica la variazione di stato che si verifica sul cursore quando si sposta verso il basso o verso l'alto sullo schermo.
• [C-1-3] DEVE supportare il movimento del cursore verso il basso e verso l'alto su un oggetto sullo schermo, il che consente agli utenti di emulare il tocco di un oggetto sullo schermo.
• [C-1-4] DEVE supportare il cursore verso il basso, il cursore verso l'alto, il cursore verso il basso e poi il cursore verso l'alto nello stesso punto su un oggetto sullo schermo entro una soglia di tempo, il che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo.
• [C-1-5] DEVE supportare il cursore verso il basso su un punto arbitrario dello schermo, il cursore si sposta in un altro punto arbitrario dello schermo, seguito da un cursore verso l'alto, che consente agli utenti di emulare un trascinamento con tocco.
• [C-1-6] DEVE supportare il cursore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in un'altra posizione sullo schermo e poi il cursore verso l'alto sullo schermo, il che consente agli utenti di lanciare un oggetto sullo schermo.

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

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

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

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

7.2.6. Supporto del controller di gioco

7.2.6.1. Mappature dei pulsanti

Implementazioni dei dispositivi:

• [C-1-1] DEVE essere in grado di mappare gli eventi HID alle costanti InputEvent corrispondenti, come elencato nelle tabelle seguenti. L'implementazione Android a monte soddisfa questo requisito.

Se le implementazioni dei dispositivi includono un controller o vengono fornite con un controller separato nella confezione che consenta di inserire tutti gli eventi elencati nelle tabelle seguenti, devono:

• [C-2-1] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.gamepad

Pulsante	Utilizzo HID^2	Pulsante Android
A^1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B^1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X^1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y^1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Pulsante direzionale su^1 Pulsante direzionale giù^1	0x01 0x0039^3	AXIS_HAT_Y^4
D-pad sinistra1 D-pad destra^1	0x01 0x0039^3	AXIS_HAT_X^4
Pulsante del tasto sinistro^1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Pulsante del tasto funzione destro^1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic con il tasto sinistro della levetta^1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic sulla levetta destra^1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Indietro^1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

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

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

4 MotionEvent

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

1 MotionEvent

7.2.7. Telecomando

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

7.3. Sensori

Se le implementazioni del dispositivo includono un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android e nella documentazione Android Open Source sui sensori.

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare con precisione la presenza o l'assenza di sensori in base alla android.content.pm.PackageManager classe.
• [C-0-2] DEVE restituire un elenco accurato dei sensori supportati tramite metodi comeSensorManager.getSensorList().
• [C-0-3] DEVE comportarsi in modo ragionevole per tutte le altre API di sensori (ad esempio, deve restituire true o false a seconda dei casi quando le applicazioni tentano di registrare gli ascoltatori, non deve chiamare gli ascoltatori dei sensori quando i sensori corrispondenti non sono presenti e così via).

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

• [C-1-1] È obbligatorio segnalare tutte le misurazioni del sensore utilizzando i valori pertinenti del Sistema internazionale di unità di misura (metrico) per ogni tipo di sensore, come definito nella documentazione dell'SDK Android.
• [C-1-2] DEVE segnalare i dati del sensore con una latenza massima di 100 millisecondi + 2 * sample_time per il caso di uno stream del sensore con una latenza massima richiesta di 0 ms quando il processore dell'applicazione è attivo. Questo ritardo non include i ritardi dovuti ai filtri.
• [C-1-3] DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time dall'attivazione del sensore. È accettabile che questo campione abbia una precisione pari a 0.
• [C-1-4] Affinché qualsiasi API indicata dalla documentazione dell'SDK Android sia un sensore continuo, le implementazioni dei dispositivi DEVONO fornire continuamente campioni di dati periodici che DEVONO avere un jitter inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori timestamp registrati tra eventi consecutivi.
• [C-1-5] DEVE garantire che lo stream di eventi del sensore NON DEVE impedire alla CPU del dispositivo di entrare in uno stato di sospensione o di riattivarsi da uno stato di sospensione.
• [C-1-6] DEVE registrare l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta l'ora in cui si è verificato l'evento e sincronizzata con il sistema SystemClock.elapsedRealtimeNano().
• [C-SR-1] È FORTEMENTE CONSIGLIATO avere un errore di sincronizzazione del timestamp inferiore a 100 millisecondi e DOVREBBE avere un errore di sincronizzazione del timestamp inferiore a 1 millisecondo.
• Quando sono attivati più sensori, il consumo di energia NON DEVE superare la somma del consumo di energia registrato dal singolo sensore.

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

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

• [C-1-6] È NECESSARIO impostare una risoluzione non pari a zero per tutti i sensori e segnalare il valore tramite il metodo API Sensor.getResolution().

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

Implementazioni dei dispositivi:

• DEVE implementare questi tipi di sensori, se includono i sensori fisici prerequisiti come descritto nei tipi di sensori.

Se le implementazioni del dispositivo includono un sensore composito:

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

Se le implementazioni dei dispositivi includono un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti e il sensore registra un solo valore, le implementazioni dei dispositivi:

• [C-3-1] È NECESSARIO 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 determinato 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 determinati in fabbrica nei dati forniti.

Se le implementazioni del dispositivo includono una combinazione di accelerometro a 3 assi, un sensore giroscopio a 3 assi o un sensore magnetometrico, sono:

• [C-SR-2] È FORTEMENTE CONSIGLIATO assicurarsi 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 dei dispositivi:

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

Se le implementazioni del dispositivo includono un accelerometro:

• [C-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 50 Hz.
• [C-1-3] DEVE essere conforme al sistema di coordinate del sensore Android come descritto nelle API Android.
• [C-1-4] DEVE essere in grado di misurare da 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 in base all'asse su campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più elevata.
• DEVE registrare eventi fino ad almeno 200 Hz.
• DEVE avere una risoluzione di almeno 16 bit.
• DEVE essere calibrato durante l'uso se le caratteristiche cambiano nel corso del ciclo di vita e vengono compensate, nonché 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, devono:

• [C-2-1] È NECESSARIO implementare e segnalare il sensore TYPE_ACCELEROMETER.
• [C-SR-4] È MOLTO CONSIGLIATO implementare il TYPE_SIGNIFICANT_MOTION sensore composito.
• [C-SR-5] È MOLTO CONSIGLIATO implementare e segnalare il sensoreTYPE_ACCELEROMETER_UNCALIBRATED. È FORTEMENTE consigliato ai dispositivi Android di soddisfare questo requisito in modo da poter eseguire l'upgrade alla futura release della piattaforma, quando 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 dell'SDK Android.

Se le implementazioni del dispositivo includono un accelerometro con meno di 3 assi:

• [C-3-1] È NECESSARIO implementare e segnalare il sensore TYPE_ACCELEROMETER_LIMITED_AXES.
• [C-SR-6] È MOLTO_CONSIGLIATO implementare e segnalare il sensoreTYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

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

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

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

• [C-5-1] È NECESSARIO implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [C-SR-7] È FORTEMENTE CONSIGLIATO implementare il TYPE_GAME_ROTATION_VECTOR sensore composito.

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

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

7.3.2. Magnetometro

Implementazioni dei dispositivi:

• [C-SR-1] È FORTEMENTE CONSIGLIATO includere un magnetometro a 3 assi (bussola).

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

• [C-1-1] È OBBLIGATORIO implementare il sensore TYPE_MAGNETIC_FIELD.
• [C-1-2] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 10 Hz e DEVE registrare eventi fino ad almeno 50 Hz.
• [C-1-3] DEVE essere conforme al sistema di coordinate del sensore Android come descritto nelle API Android.
• [C-1-4] DEVE essere in grado di misurare tra -900 µT e +900 µT su ogni asse prima di saturare.
• [C-1-5] DEVE avere un valore di offset del ferro duro inferiore a 700 µT e DEVE avere un valore inferiore a 200 µT, posizionando il magnetometro lontano 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 dell'errore di hard iron e conservare i parametri di compensazione tra i riavvii del dispositivo.
• [C-1-8] È OBBLIGATORIO applicare la compensazione del ferro dolce. La calibrazione può essere eseguita durante l'uso o durante la produzione del dispositivo.
• [C-1-9] DEVE avere una deviazione standard, calcolata in base all'asse su campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più elevata, non superiore a 1,5 µT; DEVE avere una deviazione standard non superiore a 0,5 µT.
• [C-1-10] È NECESSARIO implementare il TYPE_MAGNETIC_FIELD_UNCALIBRATED sensore.

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

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

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

• PUO' implementare il sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

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

7.3.3. GPS

Implementazioni dei dispositivi:

• [C-SR-1] È MOLTO 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:

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

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

  • [C-1-3] DEVE essere in grado di determinare la posizione entro 20 metri e la velocità entro 0, 5 metri al secondo, almeno il 95% delle volte.
  • [C-1-4] DEVE monitorare e generare report contemporaneamente tramite almeno 8 satelliti di una costellazione. GnssStatus.Callback
  • DOVREBBE essere in grado di rilevare contemporaneamente almeno 24 satelliti di più costellazioni (ad es. GPS + almeno uno di Glonass, Beidou, Galileo).

• [C-SR-2] È FORTEMENTE CONSIGLIATO di continuare a fornire output di posizione GPS/GNSS normali tramite le API GNSS Location Provider 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] È MOLTO CONSIGLIATO segnalare l'AGC e la frequenza della misurazione GNSS.

• [C-SR-5] È MOLTO CONSIGLIATO segnalare tutte le stime di accuratezza (inclusi angolo, velocità e verticale) come parte di ogni posizione GPS/GNSS.

• [C-SR-6] È FORTEMENTE CONSIGLIATO segnalare le misurazioni GNSS non appena vengono rilevate, anche se non è stata ancora segnalata una posizione calcolata da GPS/GNSS.

• [C-SR-7] È FORTEMENTE CONSIGLIATO segnalare le pseudoraggianze e le velocità di pseudoraggiunge GNSS che, in condizioni di cielo aperto dopo aver determinato la posizione, mentre sono fermi o si muovono con un'accelerazione inferiore a 0,2 metri al secondo quadrato, sono sufficienti per calcolare la posizione entro 20 metri e la velocità entro 0, 2 metri al secondo, almeno il 95% delle volte.

7.3.4. Giroscopio

Implementazioni dei dispositivi:

• [C-SR-1] È MOLTO CONSIGLIATO includere un sensore giroscopico.

Se le implementazioni del dispositivo includono un giroscopio:

• [C-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 50 Hz.
• [C-1-4] DEVE avere una risoluzione di almeno 12 bit.
• [C-1-5] DEVE essere compensato in base alla temperatura.
• [C-1-6] DEVE essere calibrato e compensato durante l'uso e deve conservare i parametri di compensazione tra i riavvii del dispositivo.
• [C-1-7] DEVE avere una varianza non superiore a 1e-7 rad^2 / s^2 per Hz (varianza per Hz o rad^2 / s). La varianza può variare con la frequenza di campionamento, ma DEVE essere vincolata da questo valore. In altre parole, se misurate 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] È FORTEMENTE CONSIGLIATO che l'errore di calibrazione sia inferiore a 0,01 rad/s quando il dispositivo è fermo a temperatura ambiente.
• [C-SR-3] È FORTEMENTE CONSIGLIATO avere una risoluzione di almeno 16 bit.
• DEVE registrare eventi fino ad almeno 200 Hz.

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

• [C-2-1] È NECESSARIO implementare il sensore TYPE_GYROSCOPE.
• [C-SR-4] È vivamente consigliato di implementare il sensore TYPE_GYROSCOPE_UNCALIBRATED.

Se le implementazioni del dispositivo includono un giroscopio con meno di 3 assi:

• [C-3-1] È NECESSARIO implementare e segnalare il sensore TYPE_GYROSCOPE_LIMITED_AXES.
• [C-SR-5] È MOLTO_CONSIGLIATO implementare e segnalare il sensoreTYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

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

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

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

• [C-5-1] È NECESSARIO implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [C-SR-6] È FORTEMENTE CONSIGLIATO di implementare il TYPE_GAME_ROTATION_VECTOR sensore composito.

7.3.5. Barometro

Implementazioni dei dispositivi:

• [C-SR-1] È FORTEMENTE CONSIGLIATO includere un barometro (sensore di pressione atmosferica ambiente).

Se le implementazioni del dispositivo includono un barometro:

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

7.3.6. Termometro

Se le implementazioni dei dispositivi includono un termometro ambientale (sensore di temperatura), :

• [C-1-1] È obbligatorio definire SENSOR_TYPE_AMBIENT_TEMPERATURE per il sensore di temperatura ambiente e il sensore DEVE misurare la temperatura ambiente (stanza/abitacolo del veicolo) da dove l'utente interagisce con il dispositivo in gradi Celsius.

Se le implementazioni dei dispositivi includono un sensore di temperatura che misura una temperatura diversa da quella ambiente, ad esempio la temperatura della CPU, devono:

• [C-2-1] NON DEVE essere definito SENSOR_TYPE_AMBIENT_TEMPERATURE per il sensore di temperatura.

Se le implementazioni del dispositivo includono un sensore per il monitoraggio della temperatura cutanea, devono:

• [C-SR-1] È MOLTO CONSIGLIATO supportare l'API PowerManager.getThermalHeadroom.

7.3.7. Fotometro

• Le implementazioni del dispositivo POSSONO includere un fotometro (sensore di luce ambientale).

7.3.8. Sensore di prossimità

• Le implementazioni del dispositivo POSSONO includere un sensore di prossimità.

Se le implementazioni dei dispositivi includono un sensore di prossimità e riportano solo una lettura "vicino" o "lontano" binaria, devono:

• [C-1-1] DEVE misurare la prossimità di un oggetto nella stessa direzione dello schermo. In altre parole, il sensore di prossimità DEVE essere orientato in modo da rilevare gli oggetti vicino allo schermo, poiché lo scopo principale di questo tipo di sensore è rilevare uno smartphone in uso dall'utente. Se le implementazioni del dispositivo includono un sensore di prossimità con qualsiasi altro orientamento, NON DEVE essere accessibile tramite questa API.
• [C-1-2] DEVE avere una precisione di almeno 1 bit.
• [C-1-3] DEVE essere utilizzato 0 centimetri come lettura ravvicinata e 5 centimetri come lettura distante.
• [C-1-4] DEVE riportare un intervallo e una risoluzione massimi 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 per le app di terze parti, devono:

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

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

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

  • DEVE avere un intervallo di misurazione compreso tra almeno -8 g e +8 g ed è MOLTO CONSIGLIATO avere 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 pari o inferiore a 12,5 Hz.
  • DEVE avere una frequenza di misurazione massima di almeno 400 Hz; DEVE supportare il canale SensorDirectChannel RATE_VERY_FAST.
  • DEVE avere un rumore di misurazione non superiore a 400 μg/√Hz.
  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore.
  • DEVE avere un consumo energetico per il raggruppamento non superiore a 3 mW.
  • [C-SR-1] È FORTEMENTE CONSIGLIATO di 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 dell'accelerazione inferiore a 30 μg √Hz testata a temperatura ambiente.
  • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 1 mg/°C.
  • DEVE avere una non linearità della linea di adattamento ottimale pari o inferiore allo 0,5% e una variazione di sensibilità rispetto alla temperatura pari o inferiore allo 0,03%/°C.
  • DEVE avere una sensibilità sull'asse trasversale inferiore al 2,5 % e una variazione della sensibilità sull'asse trasversale inferiore allo 0,2% nell'intervallo di temperatura 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 pari o inferiore a 12,5 Hz.
  • DEVE avere una frequenza di misurazione massima di almeno 400 Hz; DEVE supportare il canale 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 frequenza inferiore a 0,001 °/s √Hz testata a temperatura ambiente.
  • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 0,05 °/ s / °C.
  • DOVREBBE avere una variazione di sensibilità rispetto alla temperatura di ≤ 0,02% / °C.
  • DEVE avere una non linearità della linea di miglior adattamento pari o inferiore allo 0,2%.
  • DEVE avere una densità di rumore ≤ 0,007 °/s/√Hz.
  • DEVE avere un errore di calibrazione inferiore a 0,002 rad/s nell'intervallo di temperatura 10 ~ 40 ℃ quando il dispositivo è fermo.
  • DEVE avere una sensibilità g inferiore a 0,1°/s/g.
  • DEVE avere una sensibilità trasversale inferiore al 4,0 % e una variazione della sensibilità trasversale inferiore allo 0,3% nell'intervallo di temperatura 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 pari o inferiore a 5 Hz.
  • DEVE avere una frequenza di misurazione massima di almeno 50 Hz.
  • DEVE avere un rumore di misurazione non superiore a 0,5 uT.

• [C-2-6] DEVE avere un TYPE_MAGNETIC_FIELD_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GEOMAGNETIC_FIELD e, inoltre:

  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 600 eventi del sensore.
  • [C-SR-3] È FORTEMENTE CONSIGLIATO di avere uno spettro di rumore bianco da 1 Hz a almeno 10 Hz quando la frequenza di generazione dei report è pari o superiore a 50 Hz.

• [C-2-7] DEVE avere un sensore TYPE_PRESSURE che:

  • DEVE avere un intervallo di misurazione compreso tra almeno 300 e 1100 hPa.
  • DEVE avere una risoluzione di misurazione di almeno 80 LSB/hPa.
  • DEVE avere una frequenza di misurazione minima pari o inferiore a 1 Hz.
  • DEVE avere una frequenza di misurazione massima di almeno 10 Hz.
  • DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz.
  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
  • DEVE avere un consumo energetico per l'aggregazione non peggiore di 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 di energia non superiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando è in movimento.

• [C-2-10] DEVE avere un sensore TYPE_STEP_DETECTOR che:

  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 100 eventi del sensore.
  • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando è in movimento.
  • DEVE avere un consumo energetico per il raggruppamento non superiore a 4 mW.

• [C-2-11] DEVE avere un sensore TYPE_STEP_COUNTER che:

  • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando è in movimento.

• [C-2-12] DEVE avere un sensore TILT_DETECTOR che:

  • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando è in movimento.

• [C-2-13] Il timestamp dello stesso evento fisico registrato dall'accelerometro, dal giroscopio e dal magnetometro DEVE essere compreso tra 2, 5 millisecondi. Il timestamp dello stesso evento fisico registrato dall'accelerometro e dal giroscopio DEVE essere compreso tra 0,25 millisecondi.

• [C-2-14] DEVE avere i timestamp degli eventi del sensore giroscopico sulla stessa base di tempo del sottosistema della videocamera e con un errore massimo di 1 millisecondo.

• [C-2-15] È OBBLIGATORIO inviare i campioni alle applicazioni entro 5 millisecondi dal momento in cui i dati sono disponibili su uno dei sensori fisici sopra indicati.

• [C-2-16] NON deve avere un consumo di energia superiore a 0,5 mW quando il dispositivo è fermo e 2,0 mW quando il dispositivo è in movimento quando è attiva qualsiasi combinazione dei seguenti sensori:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] PUO' avere un sensore TYPE_PROXIMITY, ma se presente DEVE avere una capacità di buffer minima di 100 eventi del sensore.

Tieni presente che tutti i requisiti di consumo energetico in questa sezione non includono il consumo energetico dell'Application Processor. Sono inclusi i consumi dell'intera catena del sensore: il sensore, eventuali circuiti di supporto, eventuali sistemi di elaborazione dei sensori dedicati e così via.

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

• [C-3-1] DEVE dichiarare correttamente il supporto dei tipi di canali diretti e del livello di frequenza dei report diretti tramite le API isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
• [C-3-2] DEVE supportare almeno uno dei due tipi di canali diretti del sensore per tutti i sensori che dichiarano il supporto del canale diretto del sensore.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DOVREBBE supportare i report sugli eventi tramite il canale diretto del sensore per il sensore primario (variante senza risveglio) 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 relativa alla 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 di classe 3 (in precedenza sicuri), di classe 2 (in precedenza deboli) o di classe 1 (in precedenza comodità) in base ai tassi di accettazione di spoofing e di attacco di impostori e alla sicurezza della pipeline biometrica. Questa classificazione determina le funzionalità del sensore biometrico per interfacciarsi 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. Sia le funzionalità biometriche di classe 2 che quelle di classe 3 dispongono di funzionalità aggiuntive, come illustrato di seguito.

Se le implementazioni del dispositivo rendono disponibile un sensore biometrico per le applicazioni di terze parti tramite android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, devono:

• [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 parametro definito come costante nella classe Authenticators e in qualsiasi combinazione. Al contrario, NON DEVE rispettare o riconoscere costanti intere passate ai metodi canAuthenticate(int) e setAllowedAuthenticators(int) diversi da quelli documentati come costanti pubbliche in Authenticators e qualsiasi combinazione di queste.
• [C-4-3] È OBBLIGATORIO implementare l'azione ACTION_BIOMETRIC_ENROLL su dispositivi con dati biometrici di classe 3 o classe 2. Questa azione DEVE presentare solo i punti di contatto per la registrazione per la biometria di classe 3 o classe 2.

Inizio dei nuovi requisiti per Android 15

• [C-4-4] DEVE 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 in modo da consentire immagini, link, contenuti interattivi o altre forme di contenuti multimediali che non fanno già parte dell'API BiometricPrompt. È possibile apportare modifiche stilistiche che non alterino, oscurino o tronchino questi contenuti (ad esempio, modificare la posizione, i margini, i rientri e la tipografia).

Fine dei nuovi requisiti

Se le implementazioni dei dispositivi supportano la biometria passiva:

• [C-5-1] PER IMPOSTAZIONE PREDEFINITA, deve essere richiesto un ulteriore passaggio di conferma (ad es. la pressione di un pulsante).
• [C-SR-1] È FORTEMENTE CONSIGLIATO di disporre di un'impostazione che consenta agli utenti di override la preferenza dell'applicazione e di richiedere sempre il passaggio di conferma.
• [C-SR-2] È FORTEMENTE CONSIGLIATO di proteggere l'azione di conferma 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 inoltrata tramite un pin GPIO (input/output general purpose) di sola entrata di un elemento sicuro (SE) che non può essere azionato in nessun altro modo se non premendo un pulsante fisico.
• [C-5-2] DEVE implementare inoltre 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 dispongono di più sensori biometrici:

• [C-7-1] DEVE, quando un dato biometrico è bloccato (ovvero è disabilitato fino a quando l'utente non lo sblocca con l'autenticazione principale) o bloccato per un periodo di tempo (ovvero è disabilitato temporaneamente fino a quando l'utente non attende un intervallo di tempo) a causa di troppi tentativi non riusciti, bloccare anche tutti gli altri metodi biometrici di una classe biometrica inferiore. In caso di blocco temporizzato, la durata del backoff per la verifica biometrica DEVE essere la durata massima del backoff di tutti i dati biometrici nel blocco temporizzato.

• [C-SR-12] Sono FORTEMENTE CONSIGLIATI, quando un dato biometrico è bloccato (ad es. il dato biometrico viene disattivato finché l'utente non lo sblocca con l'autenticazione principale) o bloccato per un periodo di tempo (ad es. il dato biometrico viene disattivato temporaneamente finché l'utente non attende un intervallo di tempo) a causa di troppi tentativi non riusciti, per bloccare anche tutti gli altri dati biometrici della stessa classe biometrica. Nel caso di blocco con limite di tempo, è FORTEMENTE consigliato impostare il tempo di backoff per la verifica biometrica come tempo di backoff massimo di tutti i dati biometrici nel blocco con limite di tempo.

• [C-7-2] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) per reimpostare il contatore di blocco per una biometria bloccata. È POSSIBILE che i dati biometrici di classe 3 consentano di reimpostare il contatore di blocco per un dato biometrico bloccato della stessa classe o di una classe inferiore. I dati biometrici di classe 2 o classe 1 NON DEVONO essere autorizzati a completare un'operazione di reimpostazione della serratura per qualsiasi dato biometrico.

• [C-SR-3] È FORTEMENTE CONSIGLIATO di richiedere la conferma di un solo dato biometrico per autenticazione (ad es. se sul dispositivo sono disponibili sia i sensori di impronte digitali che quelli del volto, onAuthenticationSucceeded deve essere inviato dopo la conferma di uno di questi).

Affinché le implementazioni dei dispositivi consentano l'accesso alle chiavi del keystore alle applicazioni di terze parti, devono:

• [C-6-1] DEVE soddisfare i requisiti per la classe 3 come definiti in questa sezione di seguito.
• [C-6-2] DEVE presentare solo dati biometrici di classe 3 quando l'autenticazione richiede BIOMETRIC_STRONG o l'autenticazione viene invocata con un CryptoObject.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come di classe 1 (in precedenza Comodità), devono:

• [C-1-1] DEVE avere un tasso di accettazione errato inferiore allo 0,002%.
• [C-1-2] È OBBLIGATORIO indicare che questa modalità potrebbe essere meno sicura di una sequenza, una password o un PIN efficaci ed elencare chiaramente i rischi della sua attivazione, se i tassi di accettazione di spoofing e furto d'identità sono superiori al 7%, come misurato dai protocolli di test di biometria di Android.
• [C-1-9] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) dopo non più di venti prove false e un tempo di backoff non inferiore a novanta secondi per la verifica biometrica, in cui una prova falsa è una prova con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a un dato biometrico registrato.
• [C-SR-4] È FORTEMENTE CONSIGLIATO di ridurre il numero totale di prove false per la verifica biometrica specificata in [C-1-9] se i tassi di accettazione di spoofing e furto d'identità sono superiori al 7%, come misurato dai protocolli di test biometrici di Android.
• [C-1-3] È obbligatorio limitare la frequenza dei tentativi di verifica biometrica, dove un prova falsa è una con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a un dato biometrico registrato.
• [C-SR-5] È FORTEMENTE CONSIGLIATO di limitare la frequenza dei tentativi per almeno 30 secondi dopo cinque tentativi falsi per la verifica biometrica per il numero massimo di tentativi falsi in base a [C-1-9], dove un tentativo falso è un tentativo con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a un dato biometrico registrato.
• [C-SR-6] È FORTEMENTE CONSIGLIATO di avere tutta la logica di limitazione della frequenza nel TEE.
• [C-1-10] DEVE disattivare la biometria una volta attivato per la prima volta il ritiro dell'autenticazione principale come descritto in [C-0-2] della sezione 9.11.
• [C-1-11] DEVE avere un tasso di accettazione di spoofing e di attacchi di identità rubate non superiore al 30%, con (1) un tasso di accettazione di spoofing e di attacchi di identità rubate 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 di attacchi di identità rubate per le specie di PAI di livello B non superiore al 40%, come misurato dai protocolli di test di biometria di Android.
• [C-1-4] DEVE impedire l'aggiunta di nuove informazioni biometriche senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare l'esistenza o di aggiungere una nuova credenziale del dispositivo (PIN/pattern/password) protetta dal TEE. L'implementazione del progetto Android Open Source fornisce il meccanismo nel framework per farlo.

Inizio dei nuovi requisiti per Android 15

• [C-1-5] È OBBLIGATORIO 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 es. PIN, sequenza, password).

Fine dei nuovi requisiti

• [C-1-6] DEVE rispettare il singolo flag per la biometrica in questione (ad es. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE, o DevicePolicymanager.KEYGUARD_DISABLE_IRIS).

Inizio dei nuovi requisiti per Android 15

• [C-1-7] DEVE richiedere all'utente l'autenticazione principale consigliata (ad esempio PIN, sequenza, password) una volta ogni 24 ore o meno. Nota: per i dispositivi sottoposti ad upgrade che sono stati lanciati con Android 9 o versioni precedenti, È OBBLIGATORIO chiedere all'utente l'autenticazione principale consigliata (ad esempio PIN, sequenza, password) una volta ogni 72 ore o meno.

Fine dei nuovi requisiti

Inizio dei nuovi requisiti per Android 15

• [C-1-8] DEVE richiedere all'utente l'autenticazione primaria consigliata (ad esempio PIN, sequenza, password) o biometrica di classe 3 (ELEVATA) dopo una delle seguenti condizioni:
  • un periodo di timeout di inattività di 4 ore OPPURE
  • 3 tentativi di autenticazione biometrica non riusciti.
  • Il periodo di timeout di inattività e il conteggio delle autenticazioni non riuscite vengono reimpostati dopo ogni conferma delle credenziali del dispositivo. Nota: l'upgrade dei dispositivi lanciati con Android 9 o versioni precedenti PUÒ essere esente da C-1-8.

Fine dei nuovi requisiti

• [C-SR-7] È FORTEMENTE CONSIGLIATO di utilizzare la logica del framework fornito dall'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 di avere un tasso di rifiuto falso inferiore al 10%, misurato sul dispositivo.
• [C-SR-9] È FORTEMENTE CONSIGLIATO di avere una latenza inferiore a 1 secondo, misurata dal momento in cui viene rilevato il dato biometrico fino allo sblocco dello schermo, per ogni dato biometrico registrato.
• [C-1-12] DEVE avere un tasso di accettazione di spoofing e furto d'identità non superiore al 40% per ogni tipo di strumento di attacco di presentazione (PAI), misurato in base ai protocolli di test di biometria Android.
• [C-SR-13] È FORTEMENTE CONSIGLIATO di avere un tasso di accettazione di spoofing e impersonazione non superiore al 30% per ogni tipo di strumento di attacco di presentazione (PAI), misurato in base ai protocolli di test di biometria Android.
• [C-SR-8] È FORTEMENTE CONSIGLIATO di avere un tasso di rifiuto falso inferiore al 10%, misurato sul dispositivo.

Inizio dei nuovi requisiti per Android 15

• [C-1-15] DEVE consentire agli utenti di rimuovere una o più registrazioni biometriche.

Fine dei nuovi requisiti

• [C-SR-14] È FORTEMENTE CONSIGLIATO di divulgare la classe biometrica del sensore biometrico e i rischi corrispondenti della sua attivazione.

• [C-SR-17] È MOLTO CONSIGLIATO implementare le nuove interfacce AIDL (ad esempio IFace.aidl e IFingerprint.aidl).

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come di 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 furto d'identità non superiore al 20%, con (1) un tasso di accettazione di spoofing e furto d'identità per le specie di strumenti di attacco di presentazione (PAI) di livello A non superiore al 20% e (2) un tasso di accettazione di spoofing e furto d'identità per le specie di PAI di livello B non superiore al 30%, misurato in base ai protocolli di test di biometria Android.
• [C-SR-15] È FORTEMENTE CONSIGLIATO di avere un tasso di accettazione di spoofing e impostori non superiore al 20% per ogni tipo di strumento di attacco di presentazione (PAI), misurato in base ai protocolli di test di biometria 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 in un 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] DEVONO avere tutti i dati identificabili criptati e autenticati tramite crittografia 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 di implementazione sul sito del progetto Android Open Source o in una macchina virtuale protetta controllata dall'hypervisor che soddisfa i requisiti della Sezione 9.17.
• [C-2-5] Per i dati biometrici basati sulla videocamera, durante l'autenticazione o la registrazione basata su dati biometrici:
  • DEVE operare 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 VM protetta controllata dall'hypervisor che soddisfi i requisiti della Sezione 9.17.
  • Per le soluzioni RGB con una sola videocamera, i frame della videocamera POSSONO essere scorrevoli al di fuori dell'ambiente di esecuzione isolato per supportare operazioni come l'anteprima per la registrazione, ma NON devono essere alterabili.
• [C-2-6] NON DEVE consentire alle applicazioni di terze parti di distinguere tra singole registrazioni biometriche.
• [C-2-7] NON DEVE consentire l'accesso non criptato a dati biometrici identificabili o a qualsiasi dato dedotto da questi (ad esempio gli embedding) all'Applicatore al di fuori del contesto del TEE o della Macchina Virtuale protetta controllata dall'hypervisor che soddisfa i requisiti della Sezione 9.17. I dispositivi di cui è stato eseguito l'upgrade e che sono stati lanciati con Android 9 o versioni precedenti non sono esenti da C-2-7.

• [C-2-8] DEVE avere una pipeline di elaborazione sicura in modo che un compromesso del sistema operativo o del kernel non possa consentire l'iniezione diretta di dati per autenticarsi falsamente come utente. Nota: se le implementazioni dei dispositivi sono già state lanciate su Android 9 o versioni precedenti e non possono soddisfare il requisito C-2-8 tramite un aggiornamento del software di sistema, POTREBBERO essere esenti dal requisito.

• [C-SR-10] È FORTEMENTE CONSIGLIATO includere il rilevamento della presenza per tutte le modalità biometriche e il rilevamento dell'attenzione per la biometria del volto.

• [C-2-9] DEVE rendere il sensore biometrico disponibile per le applicazioni di terze parti.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come di 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 del keystore basata su hardware.
• [C-3-3] DEVE avere un tasso di accettazione di spoofing e furto d'identità non superiore al 7%, con (1) un tasso di accettazione di spoofing e furto d'identità per le specie di strumenti di attacco di presentazione (PAI) di livello A non superiore al 7% e (2) un tasso di accettazione di spoofing e furto d'identità per le specie di PAI di livello B non superiore al 20%, misurato in base ai protocolli di test di biometria Android.
• [C-3-4] DEVE richiedere all'utente l'autenticazione primaria consigliata (ad esempio PIN, sequenza, password) una volta ogni 72 ore o meno.
• [C-3-5] È NECESSARIO rigenerare l'ID autenticatore per tutti i dati biometrici di classe 3 supportati sul dispositivo se uno di questi viene nuovamente registrato.
• [C-3-6] È necessario attivare le chiavi del keystore basate sulla biometria per le applicazioni di terze parti.

• [C-SR-16] È FORTEMENTE CONSIGLIATO di avere un tasso di accettazione di spoofing e impostori non superiore al 7% per ogni tipo di strumento di attacco di presentazione (PAI), misurato in base ai protocolli di test di biometria Android.

Se le implementazioni del dispositivo contengono un sensore di impronte digitali integrato nel display (UDFPS),

• [C-SR-11] Sono FORTEMENTE CONSIGLIATI per impedire all'area tocabile del UDFPS di interferire con la navigazione a tre pulsanti (che alcuni utenti potrebbero richiedere per motivi di accessibilità).

7.3.11. Sensore di posizione

Implementazioni dei dispositivi:

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

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

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

7.3.12. Sensore dell'angolo della cerniera

Se le implementazioni del dispositivo supportano un sensore dell'angolo della cerniera:

• [C-1-1] DEVE implementare e segnalare TYPE_HINGLE_ANGLE.
• [C-1-2] DEVE supportare almeno due letture tra 0 e 360 gradi (inclusi, ovvero inclusi 0 e 360 gradi).
• [C-1-3] DEVE restituire un sensore di risveglio per 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, devono:

• [C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.uwb.
• [C-1-3] DEVE supportare tutti i seguenti insiemi di configurazione (combinazioni predefinite di parametri FIRA UCI) definiti nell'implementazione AOSP.
  • CONFIG_ID_1: misurazione della distanza STATIC STS DS-TWR unicast definita da FiRa, modalità differita, intervallo di misurazione della distanza 240 ms.
  • CONFIG_ID_2: misurazione della distanza STATIC STS DS-TWR da uno a molti definita da FiRa, in modalità differita, intervallo di misurazione della distanza 200 ms. Caso d'uso tipico: lo smartphone interagisce con molti dispositivi intelligenti.
  • CONFIG_ID_3: come CONFIG_ID_1, tranne per il fatto che i dati sull'angolo di arrivo (AoA) non vengono registrati.
  • 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à della chiave di controllo singolo P-STS.
• [C-1-4] DEVE fornire un'affordance per consentire all'utente di attivare/disattivare la radio UWB.
• [C-1-5] È OBBLIGATORIO applicare le app che utilizzano la radio UWB con l'autorizzazione UWB_RANGING (nel gruppo di autorizzazioni NEARBY_DEVICES).

Il superamento dei test di conformità e certificazione pertinenti definiti dalle organizzazioni di standard, tra cui FIRA, CCC e CSA, contribuisce a garantire il corretto funzionamento di 802.1.15.4.

7.4. Connettività dei dati

7.4.1. Telefonia

"Telefonia" come utilizzato dalle API Android e da questo documento si riferisce specificamente all'hardware relativo all'invio di chiamate vocali e all'invio di messaggi SMS o all'utilizzo di dati mobili tramite una rete mobile (ad es. GSM, CDMA, LTE, NR) GSM o CDMA. Un dispositivo che supporta "Telefonia" può scegliere di offrire alcuni o tutti i servizi di chiamate, messaggistica e dati in base alle esigenze del prodotto.

• Android PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. In altre parole, Android è compatibile con dispositivi diversi dagli smartphone.

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

• [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.telephony e gli altri flag delle sottofunzionalità in base alla tecnologia.
• [C-1-2] DEVE implementare il supporto completo dell'API per la tecnologia in questione.
• DOVREBBE 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, devono:

• [C-2-1] È OBBLIGATORIO implementare le API complete come no-op.

Se le implementazioni dei dispositivi supportano eUICC o eSIM/SIM integrate e includono un meccanismo proprietario per rendere disponibile la funzionalità eSIM per gli sviluppatori di terze parti, devono:

• [C-3-1] È OBBLIGATORIO dichiarare il android.hardware.telephony.euicc flag funzionalità.

Se le implementazioni dei dispositivi non impostano la proprietà di sistema ro.telephony.iwlan\_operation\_mode su "legacy", allora:

• [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 IMS (IP Multimedia Subsystem) sia per le funzionalità del servizio di telefonia multimediale (MMTEL) sia per quelle del servizio di comunicazione avanzata (RCS) e devono essere conformi ai requisiti degli operatori di telefonia cellulare per l'utilizzo di una singola registrazione IMS per tutto il traffico di segnalazione IMS, devono:

• [C-5-1] DEVE dichiarare il flag della funzionalità android.hardware.telephony.ims 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 della funzionalità android.hardware.telephony.ims.singlereg e fornire un'implementazione completa dell'API SipTransport, dell'API GbaService, delle indicazioni del bearer dedicato utilizzando l'HAL IRadio 1.6 e il provisioning tramite Auto Configuration Server (ACS) o un 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 generare chiamate corrispondenti a CarrierMessagingService per fornire la funzionalità di messaggistica. SmsManager#sendMultimediaMessage e SmsManager#downloadMultimediaMessage DEVONO comportare chiamate corrispondenti a CarrierMessagingService per fornire la 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 pacchetti/app/Messaggistica soddisfa questo requisito.
• [C-6-3] L'applicazione che risponde a Intent#ACTION_DIAL DEVE supportare l'inserimento di codici di tastiera arbitrari formattati come *#*#CODE#*#* e attivare una trasmissione corrispondente TelephonyManager#ACTION_SECRET_CODE.
• [C-6-4] L'applicazione che risponde a Intent#ACTION_DIAL DEVE utilizzare VoicemailContract.Voicemails#TRANSCRIPTION per mostrare la trascrizione della segreteria visiva agli utenti se supporta le trascrizioni della segreteria visiva.
• [C-6-5] DEVE rappresentare tutti gli elementi SubscriptionInfo con UUID di gruppo equivalenti come un singolo abbonamento in tutte le funzionalità visibili all'utente che mostrano e controllano le informazioni della scheda SIM. Esempi di queste affordance includono le 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 qualsiasi SubscriptionInfo con un UUID gruppo non nullo e un bit opportunistico in qualsiasi funzionalità visibile all'utente che consenta la configurazione o il controllo delle impostazioni della scheda SIM.

Se le implementazioni del dispositivo segnalano la funzionalità android.hardware.telephony e forniscono una barra di stato di sistema:

• [C-7-1] È NECESSARIO selezionare un abbonamento attivo rappresentativo per un determinato UUID gruppo da mostrare all'utente in qualsiasi funzionalità che fornisca informazioni sullo stato della SIM. Esempi di queste funzionalità includono l'icona del segnale cellulare nella barra di stato o il riquadro delle Impostazioni rapide.
• [C-SR-1] È FORTEMENTE CONSIGLIATO scegliere l'abbonamento rappresentativo come abbonamento dati attivo a meno che il dispositivo non sia in una chiamata vocale, nel qual caso è FORTEMENTE CONSIGLIATO scegliere l'abbonamento rappresentativo come abbonamento voce 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 attivo (come indicato da TelephonyManager#getCarrierServicePackageName) automaticamente o senza la conferma esplicita dell'utente:
  • Revocare o limitare l'accesso alla rete
  • Revocare le autorizzazioni
  • Limitare l'esecuzione delle app in background o in primo piano oltre le funzionalità di gestione dell'alimentazione esistenti incluse in AOSP
  • Disattiva o disinstalla l'app

Se le implementazioni dei dispositivi segnalano la funzionalità android.hardware.telephony e tutti gli abbonamenti non opportunistici attivi 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] NON DEVE dichiarare PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] DEVE generare un IllegalArgumentException al tentativo di impostare qualsiasi tipo di rete 3GPP2 nelle maschere di bit dei 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, devono:

• [C-10-1] È OBBLIGATORIO dichiarare il android.hardware.telephony.euicc.mep flag funzionalità.

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 da un numero di telefono in 'BlockedNumberProvider' senza alcuna interazione con le app. L'unica eccezione avviene quando il blocco dei numeri viene rimosso temporaneamente, come descritto nella documentazione dell'SDK.

• [C-1-4] DEVE scrivere al fornitore del registro chiamate della piattaforma per una chiamata bloccata e DEVE filtrare le chiamate con BLOCKED_TYPE dalla visualizzazione del registro chiamate predefinita nell'app Telefono preinstallata.

• [C-1-5] NON DEVE scrivere al Fornitore di telefonia per un messaggio bloccato.

• [C-1-6] DEVE implementare un'interfaccia utente per la gestione dei numeri bloccati, che viene aperta con l'intent restituito dal metodo TelecomManager.createManageBlockedNumbersIntent().

• [C-1-7] NON DEVE consentire agli utenti secondari di visualizzare o modificare i numeri bloccati sul dispositivo, in quanto la piattaforma Android presuppone che l'utente principale abbia il controllo completo dei servizi di telefonia, una singola istanza, sul dispositivo. Tutta l'interfaccia utente relativa al blocco DEVE essere nascosta per gli utenti secondari e l'elenco bloccato DEVE essere comunque rispettato.

• DOVREBBE eseguire la migrazione dei numeri bloccati nel provider quando un dispositivo si aggiorna ad Android 7.0.

• DOVREBBE fornire all'utente la possibilità di mostrare le chiamate bloccate nell'app Telefono preinstallata.

7.4.1.2. API Telecom

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

• [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 accettarla o rifiutarla quando è in corso una chiamata effettuata da un'app di terze parti che non supporta la funzionalità di messa in attesa specificata tramite CAPABILITY_SUPPORT_HOLD.
• [C-1-3] DEVE avere un'applicazione che implementi InCallService.

• [C-SR-1] È MOLTO CONSIGLIATO informare l'utente che la risposta a una chiamata in arrivo interromperà una chiamata in corso.

  L'implementazione AOSP soddisfa questi requisiti tramite una notifica di tipo heads-up che indica all'utente che, se risponde a una chiamata in arrivo, l'altra chiamata verrà interrotta.

• [C-SR-2] È FORTEMENTE CONSIGLIATO di precaricare l'app Telefono predefinita che mostra una voce del registro chiamate e il nome di un'app di terze parti nel suo registro chiamate quando l'app di terze parti imposta la chiave extras su PhoneAccount su true.EXTRA_LOG_SELF_MANAGED_CALLS

• [C-SR-3] È FORTEMENTE CONSIGLIATO gestire gli eventi KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK dell'audio headset per le API android.telecom come indicato di seguito:

  • Chiama Connection.onDisconnect() quando viene rilevata una breve pressione dell'evento chiave durante una chiamata in corso.
  • Chiama Connection.onAnswer() quando viene rilevata una breve pressione dell'evento chiave durante una chiamata in arrivo.
  • Chiama Connection.onReject() quando viene rilevata una pressione prolungata dell'evento chiave durante una chiamata in arrivo.
  • Attiva/disattiva lo stato di disattivazione dell'audio del CallAudioState.

7.4.1.3. Cellular NAT-T Keepalive Offload

Implementazioni dei dispositivi:

• DEVE includere il supporto per l'offload del keepalive di rete mobile.

Se le implementazioni del dispositivo includono il supporto per lo sgravio del keepalive di rete mobile e espongono la funzionalità ad app di terze parti, devono:

• [C-1-1] DEVE supportare l'API SocketKeepAlive.
• [C-1-2] DEVE supportare almeno uno slot keepalive simultaneo su rete mobile.
• [C-1-3] DEVE supportare tutti gli slot keepalive di rete mobile contemporaneamente supportati dall'HAL Radio cellulare.
• [C-SR-1] È FORTEMENTE CONSIGLIATO supportare almeno tre slot keepalive cellulari per istanza radio.

Se le implementazioni dei dispositivi non includono il supporto per l'offload keepalive della rete cellulare:

• [C-2-1] DEVE restituire ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementazioni dei dispositivi:

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

Se le implementazioni dei dispositivi includono il supporto per 802.11 e mettono a disposizione la funzionalità a un'applicazione di terze parti, 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.

Inizio dei nuovi requisiti per Android 15

• [C-1-4] DEVE supportare il DNS multicast (mDNS) e NON DEVE filtrare i pacchetti mDNS (224.0.0.251 o ff02::fb) in qualsiasi momento di funzionamento, anche quando lo schermo non è attivo, a meno che l'eliminazione o il filtro di questi pacchetti non sia necessario per rispettare gli intervalli di consumo energetico previsti dalle normative applicabili al mercato di destinazione.

• [C-1-4] DEVE supportare mDNS e NON DEVE filtrare i pacchetti mDNS (224.0.0.251 o ff02::fb) in qualsiasi momento di funzionamento, anche quando lo schermo non è attivo, a meno che il blocco multicast non sia attivo e i pacchetti non vengano filtrati dall'APF. I pacchetti non sono necessari per soddisfare eventuali operazioni mDNS attualmente richieste dalle applicazioni tramite le API NsdManager. Tuttavia, il dispositivo PUÒ filtrare i pacchetti mDNS se necessario per rientrare negli intervalli di consumo energetico previsti dai requisiti normativi applicabili al mercato di destinazione.

Fine dei nuovi requisiti

• [C-1-5] NON DEVE trattare la chiamata al metodo dell'API WifiManager.enableNetwork() come un'indicazione sufficiente per cambiare il valore Network attualmente attivo, che viene utilizzato per impostazione predefinita per il traffico delle applicazioni e restituito dai metodi dell'API ConnectivityManager come getActiveNetwork e registerDefaultNetworkCallback. In altre parole, possono disattivare l'accesso a internet fornito da qualsiasi altro fornitore di rete (ad es. dati mobili) solo se verificano correttamente che la rete Wi-Fi fornisce l'accesso a internet.
• [C-1-6] È FORTEMENTE CONSIGLIATO, quando viene chiamato il metodo API ConnectivityManager.reportNetworkConnectivity(), di rivalutare l'accesso a internet su Network e, se la valutazione determina che l'attuale Network non fornisce più accesso a internet, passare a qualsiasi altra rete disponibile (ad es. dati mobili) che fornisca 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 lo STA è disconnesso.
• [C-1-8] DEVE essere utilizzato un indirizzo MAC coerente (NON DEVE essere randomizzato l'indirizzo MAC a metà scansione).
• [C-1-9] DEVE eseguire l'iterazione del numero di sequenza della richiesta di probe come normale (in sequenza) tra le richieste di probe in una scansione.
• [C-1-10] DEVE essere randomizzato 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] È MOLTO CONSIGLIATO randomizzare l'indirizzo MAC di origine utilizzato per tutte le comunicazioni STA con un punto di accesso (AP) durante l'associazione e la connessione.
  • 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 la randomizzazione delle nuove configurazioni Wi-Fi.
• [C-SR-2] È MOLTO CONSIGLIATO utilizzare un BSSID casuale per qualsiasi AP creato.
  • L'indirizzo MAC DEVE essere casuale e persistente per ogni SSID utilizzato dall'AP.
  • Il PRODOTTO POTREBBE fornire all'utente un'opzione per disattivare questa funzionalità. Se viene fornita un'opzione di questo tipo, la randomizzazione DEVE essere attivata 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, devono:

• DOVREBBE disattivare la modalità di risparmio energetico del Wi-Fi ogni volta che un'app acquisisce il blocco WIFI_MODE_FULL_HIGH_PERF o WIFI_MODE_FULL_LOW_LATENCY tramite le API WifiManager.createWifiLock() e WifiManager.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 quando il dispositivo è in modalità di blocco Wi-Fi con bassa latenza (WIFI_MODE_FULL_LOW_LATENCY) DEVE essere inferiore alla latenza durante una modalità di blocco Wi-Fi con prestazioni elevate (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] È MOLTO CONSIGLIATO ridurre al minimo la latenza di andata e ritorno del Wi-Fi ogni volta che viene acquisito e applicato un blocco a bassa latenza (WIFI_MODE_FULL_LOW_LATENCY).

Se le implementazioni dei dispositivi supportano il Wi-Fi e lo utilizzano per la ricerca della posizione,

• [C-2-1] DEVE fornire un'affordance utente per attivare/disattivare la lettura del valore tramite il metodo dell'API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementazioni dei dispositivi:

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

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

• [C-1-1] DEVE implementare l'API Android corrispondente come descritto nella documentazione dell'SDK.
• [C-1-2] DEVE segnalare la funzionalità hardware android.hardware.wifi.direct.
• [C-1-3] DEVE supportare il normale funzionamento del Wi-Fi.
• [C-1-4] DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Direct.
• [C-SR-1] È FORTEMENTE CONSIGLIATO di generare in modo casuale l'indirizzo MAC di origine per tutte le nuove connessioni Wi-Fi Direct.

7.4.2.2. Configurazione del link diretto con tunnel Wi-Fi

Implementazioni dei dispositivi:

• DOVREBBE includere il supporto per la configurazione del link diretto tramite tunnel Wi-Fi (TDLS) come descritto nella documentazione dell'SDK Android.

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

• [C-1-1] È OBBLIGATORIO dichiarare il supporto di TDLS tramite WifiManager.isTdlsSupported.
• DEVI utilizzare TDLS solo quando è possibile E utile.
• DOVREBBE avere qualche euristica e NON utilizzare TDLS quando le sue prestazioni potrebbero essere peggiori rispetto al passaggio tramite il punto di accesso Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementazioni dei dispositivi:

• DEVE includere il supporto di Wi-Fi Aware.

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

• [C-1-1] DEVE implementare le API WifiAwareManager come descritto nella documentazione dell'SDK.
• [C-1-2] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.wifi.aware.
• [C-1-3] DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Aware.
• [C-1-4] DEVE randomizzare l'indirizzo dell'interfaccia di gestione Wi-Fi Aware a intervalli non superiori a 30 minuti e ogni volta che Wi-Fi Aware è abilitato, a meno che non sia in corso un'operazione di Aware Ranging o non sia attivo un percorso dati Aware (la randomizzazione non è prevista finché il percorso dati è attivo).

Se le implementazioni del dispositivo includono il supporto di Wi-Fi Aware e Posizione Wi-Fi come descritto nella sezione 7.4.2.5 e espongono queste funzionalità ad app di terze parti, devono:

• [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 per 802.11 (Wi-Fi), devono:

• [C-1-1] DEVE includere il supporto di Wi-Fi Passpoint.
• [C-1-2] DEVE implementare le API WifiManager relative a Passpoint come описано nella documentazione dell'SDK.
• [C-1-3] DEVE supportare lo standard IEEE 802.11u, in particolare per quanto riguarda la rilevamento e la selezione della rete, come il servizio di annunci generici (GAS) e il protocollo ANQP (Access Network Query Protocol).
• [C-1-4] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.wifi.passpoint.
• [C-1-5] DEVE seguire l'implementazione AOSP per rilevare, associare e associare alle reti Passpoint.
• [C-1-6] DEVE supportare almeno il seguente sottoinsieme di protocolli di provisioning del dispositivo 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 del provisioning da parte dell'utente tramite il selettore Wi-Fi.
• [C-1-9] DEVE mantenere le configurazioni Passpoint persistenti dopo i riavvii.
• [C-SR-1] È FORTEMENTE CONSIGLIATO supportare la funzionalità di accettazione dei termini e delle condizioni.
• [C-SR-2] Sono FORTEMENTE CONSIGLIATI per supportare la funzionalità Informazioni sui luoghi.

Se viene fornito un'opzione di controllo utente per la disattivazione di Passpoint a livello globale, le implementazioni:

• [C-3-1] DEBBA attivare Passpoint per impostazione predefinita.

7.4.2.5. Posizione Wi-Fi (tempo di round trip Wi-Fi - RTT)

Implementazioni dei dispositivi:

• DOVREBBE includere il supporto della località Wi-Fi.

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

• [C-1-1] DEVE implementare le API WifiRttManager come descritto nella documentazione dell'SDK.
• [C-1-2] È OBBLIGATORIO 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] È FORTEMENTE CONSIGLIATO segnalare 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).

7.4.2.6. Offload keepalive Wi-Fi

Implementazioni dei dispositivi:

• DEVE includere il supporto per l'offload del keepalive Wi-Fi.

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

• [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 del keepalive Wi-Fi,

• [C-2-1] DEVE restituire ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (Device Provisioning Protocol)

Implementazioni dei dispositivi:

• DEVE includere il supporto di Wi-Fi Easy Connect (DPP).

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

• [C-1-1] È OBBLIGATORIO che il metodo WifiManager#isEasyConnectSupported() restituisca true.

7.4.2.8. Convalida del certificato del server Wi-Fi aziendale

Se il certificato del server Wi-Fi non è 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 la rete Wi-Fi aziendale nell'app Impostazioni.

7.4.2.9. Considera attendibile al primo utilizzo (TOFU)

Se le implementazioni del dispositivo supportano la funzionalità Trust al primo utilizzo (TOFU) e consentono all'utente di definire le configurazioni WPA/WPA2/WPA3-Enterprise, l'utente:

• [C-4-1] DEVE fornire all'utente un'opzione per selezionare l'utilizzo del TOFU.

7.4.3. Bluetooth

Se le implementazioni dei dispositivi supportano il profilo Bluetooth Audio:

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

Se le implementazioni 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, devono:

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

Android include il supporto per Bluetooth e Bluetooth Low Energy.

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

• [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), devono:

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

• [C-3-5] È OBBLIGATORIO implementare un timeout per gli indirizzi privati risolvibili (RPA) non superiore a 15 minuti e ruotare l'indirizzo al termine del timeout per proteggere la privacy dell'utente quando il dispositivo utilizza attivamente il BLE per la scansione o la pubblicità. Per evitare attacchi di temporizzazione, gli intervalli di timeout DEVONO essere scelti in modo casuale tra 5 e 15 minuti.

• DOVREBBE supportare lo sgravio della logica di filtro sul chipset Bluetooth quando si implementa l'API ScanFilter.

• DOVREBBE supportare lo sgravio della scansione collettiva sul chipset Bluetooth.

• DEVE supportare più annunci con almeno 4 slot.

Se le implementazioni dei dispositivi supportano il Bluetooth LE e lo utilizzano per la ricerca di posizione, devono:

• [C-4-1] DEVE fornire un'affordance utente per attivare/disattivare il valore letto tramite l'API di sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se le implementazioni dei dispositivi includono il supporto di Bluetooth LE e del profilo per le protesi acustiche, come descritto in Supporto audio per le protesi acustiche tramite Bluetooth LE, devono:

• [C-5-1] DEVE restituire true per 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 eventuali metadati Bluetooth (ad esempio i risultati della scansione) che potrebbero essere utilizzati per dedurre la posizione del dispositivo, a meno che l'app richiedente non superi un controllo delle autorizzazioni android.permission.ACCESS_FINE_LOCATION in base al suo stato corrente in primo piano/sfondo.

Se le implementazioni del dispositivo includono il supporto del Bluetooth o del Bluetooth Low Energy e il file manifest dell'app non include una dichiarazione dello sviluppatore che afferma che la posizione non viene ricavata dal Bluetooth, allora:

• [C-6-2] L'accesso al Bluetooth DEVE essere controllato dietro android.permission.ACCESS_FINE_LOCATION.

Se le implementazioni dei dispositivi restituiscono true per l'API BluetoothAdapter.isLeAudioSupported(), significa che:

• [C-7-1] DEVE supportare il client unicast.
• [C-7-2] DEVE supportare PHY 2 M.
• [C-7-3] DEVE supportare la pubblicità estesa LE.
• [C-7-4] DEVE supportare almeno 2 connessioni CIS in un CIG.
• [C-7-5] È NECESSARIO attivare contemporaneamente il client unicast BAP, il coordinatore dell'insieme CSIP, il server MCP, il controller VCP e il server CCP.
• [C-SR-1] È MOLTO CONSIGLIATO abilitare il client unicast HAP.

Se le implementazioni dei dispositivi restituiscono true per l'API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), significa che:

• [C-8-1] DEVE supportare almeno 2 link BIS in un BIG.
• [C-8-2] È NECESSARIO attivare contemporaneamente l'origine di trasmissione BAP e l'assistente alla trasmissione BAP.
• [C-8-3] DEVE supportare la pubblicità periodica LE.

Se le implementazioni dei dispositivi restituiscono true per l'API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), significa che:

• [C-9-1] DEVE supportare PAST (Periodic Advertising Sync Transfer).
• [C-9-2] DEVE supportare la pubblicità periodica LE.

Se le implementazioni del dispositivo dichiarano FEATURE_BLUETOOTH_LE:

• [C-10-1] È NECESSARIO che le misurazioni RSSI rientrino nel range +/-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 3 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.
• [C-SR-2] È FORTEMENTE CONSIGLIATO di misurare e compensare l'offset Rx per assicurarsi che l'RSSI BLE medio sia -60 dBm +/-10 dB a una distanza di 1 m 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] È MOLTO CONSIGLIATO misurare e compensare l'offset di trasmissione per assicurarsi 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.

È FORTEMENTE CONSIGLIATO seguire i passaggi di configurazione della misurazione specificati in Requisiti di calibrazione della presenza.

7.4.4. Near Field Communication

Implementazioni dei dispositivi:

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

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

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

• [C-SR-1] È FORTEMENTE CONSIGLIATO che il dispositivo sia in grado di leggere e scrivere messaggi NDEF nonché dati non elaborati tramite i seguenti standard NFC. Tieni presente che, anche se gli standard NFC sono indicati come FORTEMENTE CONSIGLIATI, è previsto di modificare la definizione di compatibilità per una versione futura in modo che questi standard diventino OBBLIGATORI. Questi standard sono facoltativi in questa versione, ma obbligatori nelle versioni future. I dispositivi esistenti e nuovi che eseguono questa versione di Android sono vivamente invitati a soddisfare questi requisiti ora, in modo da poter eseguire l'upgrade alle release future della piattaforma.

• [C-1-13] DEVE eseguire la ricerca di tutte le tecnologie supportate in modalità di ricerca NFC.

• DOVREBBE essere in modalità di rilevamento NFC quando il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.

• DEVE essere in grado di leggere il codice a barre e l'URL (se codificato) dei prodotti con codice a barre NFC Thinfilm.

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

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

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

• [C-2-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.nfc.hce.
• [C-2-2] DEVE supportare le API NFC HCE come definito 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, devono:

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

Se le implementazioni dei dispositivi includono il supporto 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, devono:

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

7.4.5. Protocolli e API di rete

7.4.5.1. Capacità di rete minima

Implementazioni dei dispositivi:

• [C-0-1] DEVE includere il supporto di una o più forme di reti di dati. Nello specifico, le implementazioni dei dispositivi DEVONO includere il supporto di almeno uno standard di dati in grado di supportare velocità di almeno 200 Kbit/sec. Alcuni esempi di tecnologie che soddisfano questo requisito sono EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
• DEVE includere anche il supporto di almeno uno standard di dati wireless comune, come 802.11 (Wi-Fi), quando uno standard di rete fisica (come Ethernet) è la connessione dati principale.
• PUO' implementare più di una forma di connettività dei dati.

7.4.5.2. IPv6

Implementazioni dei dispositivi:

• [C-0-2] DEVE includere uno stack di rete IPv6 e supportare la comunicazione IPv6 utilizzando le API gestite, come java.net.Socket e java.net.URLConnection, nonché le API native, come le socket AF_INET6.
• [C-0-3] DEVE attivare IPv6 per impostazione predefinita.
  • DEVE garantire che la comunicazione IPv6 sia affidabile quanto quella IPv4, ad esempio:
    • [C-0-4] DEVE mantenere la connettività IPv6 in modalità sospensione.
    • [C-0-5] Il limite di velocità NON DEVE causare la perdita della connettività IPv6 sul dispositivo su qualsiasi rete IPv6 conforme che utilizza durate RA di almeno 180 secondi.
• [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 eseguita localmente 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 ed essere visibili come IP e porta di origine per i server internet (web).

Il livello di supporto IPv6 richiesto dipende dal tipo di rete, come indicato nei seguenti requisiti.

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, devono:

• [C-3-1] DEVE supportare il funzionamento IPv6 (solo IPv6 ed eventualmente dual-stack) su rete cellulare.

Se le implementazioni dei dispositivi supportano più di un tipo di rete (ad es. Wi-Fi e rete dati), devono:

• [C-4-1] DEVE soddisfare contemporaneamente i requisiti sopra indicati 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 del android.webkit.Webview API, devono:

• [C-1-1] DEVE fornire un'applicazione del portale captive per gestire l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN e visualizzare la pagina di accesso al portale captive inviando questo intent al 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 la rete mobile/cellulare, Wi-Fi, Ethernet o Bluetooth.
• [C-1-3] DEVE supportare l'accesso ai portali captive utilizzando il DNS in chiaro quando il dispositivo è configurato per utilizzare la modalità rigorosa del DNS privato.
• [C-1-4] È OBBLIGATORIO utilizzare il DNS criptato come da documentazione dell'SDK per android.net.LinkProperties.getPrivateDnsServerName e android.net.LinkProperties.isPrivateDnsActive per tutto il traffico di rete che non comunica esplicitamente con il portale captive.
• [C-1-5] DEVE garantire che, quando l'utente accede a un portale captive, la rete predefinita utilizzata dalle applicazioni (come 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 accesso a internet, se disponibile.

7.4.6. Impostazioni sincronizzazione

Implementazioni dei dispositivi:

• [C-0-1] L'impostazione di sincronizzazione automatica principale DEVE essere attiva per impostazione predefinita in modo che il metodo getMasterSyncAutomatically() restituisca "true".

7.4.7. Risparmio dati

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

• [C-SR-1] È FORTEMENTE CONSIGLIATO fornire la modalità Risparmio dati.

Se le implementazioni dei dispositivi forniscono la modalità Risparmio dati, devono:

• [C-1-1] DEVE supportare tutte le API della classe ConnectivityManager come descritto nella documentazione dell'SDK

Se le implementazioni dei dispositivi non forniscono la modalità Risparmio dati, devono:

• [C-2-1] DEVE restituire il valore RESTRICT_BACKGROUND_STATUS_DISABLED per ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NON DEVE trasmettere ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Secure Element

Se le implementazioni dei dispositivi supportano elementi sicuri compatibili con l'API Open Mobile e li rendono disponibili per le app di terze parti,

• [C-1-1] DEVE elencare i lettori di elementi sicuri disponibili tramite android.se.omapi.SEService.getReaders() API.

• [C-1-2] È NECESSARIO 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 dei dispositivi includono il supporto per 802.1.15.4 e mettono a disposizione 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'affordance per consentire all'utente di attivare/disattivare la radio UWB.
• [C-1-5] È OBBLIGATORIO applicare le app che utilizzano la radio UWB con l'autorizzazione UWB_RANGING (nel gruppo di autorizzazioni NEARBY_DEVICES).
• [C-SR-1] È FORTEMENTE CONSIGLIATO di superare i test di conformità e certificazione pertinenti definiti dalle organizzazioni di standard, tra cui FIRA, CCC e CSA.
• [C-1-6] È NECESSARIO assicurarsi che le misurazioni della distanza rientrino nei limiti di +/-15 cm per il 95% delle misurazioni nell'ambiente in linea di vista a una distanza di 1 m in una camera non riflettente.
• [C-1-7] È NECESSARIO assicurarsi che la mediana delle misurazioni della distanza a 1 m dal dispositivo di riferimento rientri nell'intervallo [0,75 m, 1,25 m], dove la distanza di verità sulla scena viene misurata dal bordo superiore del DUT.
• [C-SR-2] È FORTEMENTE CONSIGLIATO di seguire i passaggi di configurazione della misurazione specificati in Requisiti di calibrazione della presenza.

7.5. Fotocamere

Se le implementazioni dei dispositivi includono almeno una videocamera:

• [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.camera.any.
• [C-1-2] DEVE essere possibile per un'applicazione allocare contemporaneamente tre bitmap RGBA_8888 uguali alle dimensioni delle immagini prodotte dal sensore della fotocamera con la risoluzione più elevata sul dispositivo, mentre la fotocamera è aperta ai fini di un'anteprima di base e di acquisizione di foto.
• [C-1-3] DEVE assicurarsi che l'applicazione della 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 di destinazione quando quest'ultima non dispone di ACCESS_FINE_LOCATION.

Se le implementazioni dei dispositivi supportano la funzionalità di output HDR a 10 bit, devono:

• [C-2-1] DEVE supportare almeno il profilo HDR HLG per ogni dispositivo di fotocamera che supporta l'uscita a 10 bit.
• [C-2-2] DEVE supportare l'uscita a 10 bit per la fotocamera posteriore principale o per la fotocamera anteriore principale.
• [C-SR-1] È MOLTO CONSIGLIATO supportare l'uscita a 10 bit per entrambe le camere principali.
• [C-2-3] DEVE supportare gli stessi profili HDR per tutte le subunità fisiche compatibili con BACKWARD_COMPATIBLE di una videocamera logica e per la videocamera logica stessa.

Per i dispositivi fotocamera logici che supportano l'HDR a 10 bit e che implementano l'APIandroid.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 acquisisce le scene sul lato opposto del dispositivo, come una fotocamera tradizionale. Sui dispositivi portatili, si tratta di una fotocamera situata sul lato opposto del display.

Implementazioni dei dispositivi:

• DOVREBBE includere una fotocamera posteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera posteriore, devono:

• [C-1-1] È OBBLIGATORIO segnalare i flag delle funzionalità android.hardware.camera e android.hardware.camera.any.
• [C-1-2] DEVE avere una risoluzione di almeno 2 megapixel.
• DEVE avere l'autofocus hardware o l'autofocus software implementato nel driver della fotocamera (trasparente al software dell'applicazione).
• POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
• PUO' includere un flash.

Se la fotocamera include un flash:

• [C-2-1] la spia del flash NON DEVE essere accesa quando è stata registrata un'istanza di android.hardware.Camera.PreviewCallback su una superficie di anteprima della fotocamera, a meno che l'applicazione non abbia attivato esplicitamente il flash attivando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON di un oggetto Camera.Parameters. Tieni presente che questo vincolo non si applica all'applicazione della videocamera di sistema integrata del dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

Una fotocamera anteriore è una fotocamera rivolta verso l'utente che in genere viene utilizzata per acquisire immagini dell'utente, ad esempio per videoconferenze e applicazioni simili. Sui dispositivi portatili, si tratta di una fotocamera situata sullo stesso lato del dispositivo del display.

Implementazioni dei dispositivi:

• PUO' includere una fotocamera anteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera anteriore, devono:

• [C-1-1] È OBBLIGATORIO segnalare i flag delle funzionalità android.hardware.camera.any e android.hardware.camera.front.
• [C-1-2] DEVE avere una risoluzione di almeno VGA (640 x 480 pixel).
• [C-1-3] NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Camera e NON DEVE configurare l'API in modo da trattare una fotocamera anteriore come la fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
• [C-1-4] L'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto all'orientamento specificato dall'applicazione quando l'applicazione corrente ha richiesto esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation(). Al contrario, l'anteprima DEVE essere ribaltata sull'asse orizzontale predefinito del dispositivo quando l'applicazione corrente non richiede esplicitamente di ruotare il display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NON DEVE rispecchiare gli stream di video o immagini acquisiti finali rimessi ai callback dell'applicazione o registrati nello spazio di archiviazione multimediale.
• [C-1-6] L'immagine visualizzata dal postview DEVE essere speculare come lo stream di immagini dell'anteprima della fotocamera.
• PUO' includere funzionalità (come messa a fuoco automatica, flash e così via) disponibili per le fotocamere posteriori come descritto nella sezione 7.5.1.

Se le implementazioni dei dispositivi possono essere ruotate dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente):

• [C-2-1] L'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto all'orientamento corrente 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 rivolta in qualsiasi direzione, ad esempio le videocamere USB.

Implementazioni dei dispositivi:

• PUO' includere il supporto di una videocamera esterna che non è necessariamente sempre collegata.

Se le implementazioni dei dispositivi includono il supporto di una videocamera esterna:

• [C-1-1] È OBBLIGATORIO dichiarare i flag delle funzionalità della piattaformaandroid.hardware.camera.external e android.hardware camera.any.
• [C-1-2] DEVE supportare la classe video USB (UVC 1.0 o successive) se la videocamera esterna si connette tramite la porta host USB.
• [C-1-3] DEVE superare i test CTS della videocamera con un dispositivo di videocamera esterna fisica collegato. I dettagli dei test CTS della videocamera sono disponibili all'indirizzo source.android.com.
• DOVREBBE supportare le compressioni video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ad es. stream di immagini non compressi o compressi in modo indipendente).
• POTREBBE supportare più videocamere.
• POTREBBE supportare la codifica video basata sulla fotocamera.

Se la codifica video basata sulla videocamera è supportata:

• [C-2-1] Un stream non codificato / MJPEG simultaneo (risoluzione QVGA o superiore) DEVE essere accessibile all'implementazione del dispositivo.

7.5.4. Comportamento dell'API Camera

Android include due pacchetti API per accedere alla fotocamera. La più recente API android.hardware.camera2 espone all'app il controllo della fotocamera a livello inferiore, inclusi flussi di streaming/burst a copia zero efficienti e controlli per fotogramma di esposizione, guadagno, guadagni del bilanciamento del bianco, conversione del colore, riduzione del rumore, nitidezza e altro ancora.

Il pacchetto API precedente, android.hardware.Camera, è contrassegnato come deprecato in Android 5.0, ma dovrebbe essere ancora disponibile per le app. Le implementazioni dei dispositivi Android DEVONO garantire il supporto continuo dell'API come descritto in questa sezione e nell'SDK Android.

Tutte le funzionalità comuni tra la classe android.hardware.Camera ritirata 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 dalla diversa semantica delle due API non devono necessariamente avere la stessa velocità o qualità, ma devono essere il più simili possibile.

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API relative alle videocamere, per tutte le videocamere disponibili. Implementazioni dei dispositivi:

• [C-0-1] È OBBLIGATORIO utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione quando un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] DEVE inoltre essere nel formato di codifica NV21 quando un'applicazione registra un'istanza android.hardware.Camera.PreviewCallback e il sistema chiama il metodo onPreviewFrame() e il formato di anteprima è YCbCr_420_SP, i dati in byte[] passati a onPreviewFrame(). In altre parole, NV21 DEVE essere il valore predefinito.
• [C-0-3] DEVE supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia per le fotocamere anteriori che posteriori per android.hardware.Camera. L'hardware Il codificatore video 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 annunciano la funzionalità REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities.
• [C-0-5] DEVE comunque implementare l'API Camera completa inclusa nella documentazione dell'SDK Android, indipendentemente dal fatto che il dispositivo includa l'autofocus hardware o altre funzionalità. Ad esempio, le fotocamere che non dispongono della messa a fuoco automatica DEVONO comunque chiamare le istanze android.hardware.Camera.AutoFocusCallback registrate (anche se questo non è pertinente per una fotocamera senza messa a fuoco automatica). Tieni presente che questo vale per le fotocamere anteriori. Ad esempio, anche se la maggior parte delle fotocamere anteriori non supporta l'autofocus, i callback dell'API devono comunque essere "falsi" come descritto.
• [C-0-6] DEVE riconoscere e rispettare ogni nome parametro definito come costante nella classe android.hardware.Camera.Parameters e nella classe android.hardware.camera2.CaptureRequest. Al contrario, le implementazioni dei dispositivi NON DEVONO rispettare o riconoscere le costanti di stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. In altre parole, le implementazioni dei dispositivi DEVONO supportare tutti i parametri Camera standard se il hardware lo consente e NON DEVONO supportare tipi di parametri Camera personalizzati. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini utilizzando tecniche di imaging HDR (High Dynamic Range) DEVONO supportare il parametro della fotocamera Camera.SCENE_MODE_HDR.
• [C-0-7] DEVE segnalare il livello di supporto appropriato con la proprietà android.info.supportedHardwareLevel come descritto nell'SDK Android e segnalare i flag delle funzionalità del framework appropriati.
• [C-0-8] DEVE anche dichiarare le singole funzionalità della videocamera di android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag di funzionalità appropriati; DEVE definire il flag di funzionalità se uno dei dispositivi videocamera collegati supporta la funzionalità.
• [C-0-9] DEVE trasmettere l'intent Camera.ACTION_NEW_PICTURE ogni volta che la fotocamera scatta una nuova foto e la voce della foto è stata aggiunta al media store.
• [C-0-10] DEVE trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che una nuova videocamera registra un video e la voce della fotografia è stata aggiunta al media store.
• [C-0-11] È OBBLIGATORIO che tutte le videocamere siano accessibili tramite l'API android.hardware.Camera ritirata e anche tramite l'API android.hardware.camera2.
• [C-0-12] È OBBLIGATORIO assicurarsi che l'aspetto del viso NON sia alterato, inclusa, a titolo esemplificativo, la geometria del viso, la tonalità della pelle del viso o la levigatezza della pelle del viso per qualsiasi API android.hardware.camera2 o android.hardware.Camera.
• [C-SR-1] Per i dispositivi con più videocamere RGB vicine e rivolte nella stessa direzione, è FORTEMENTE 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 di fotocamera proprietaria alle app di terze parti,

• [C-1-1] DEVE implementare un'API di questo tipo utilizzando l'API android.hardware.camera2.
• PUO' fornire tag e/o estensioni del fornitore all'API android.hardware.camera2.

7.5.5. Orientamento della fotocamera

Se le implementazioni del dispositivo dispongono di una fotocamera anteriore o posteriore, queste fotocamere:

• [C-1-1] DEVE essere orientata in modo che la dimensione lunga della videocamera sia allineata alla dimensione lunga dello schermo. In altre parole, quando il dispositivo è tenuto in orientamento orizzontale, le fotocamere DEVONO acquisire le immagini in orientamento orizzontale. Questo si applica indipendentemente dall'orientamento naturale del dispositivo, ovvero ai dispositivi con orientamento principale orizzontale e verticale.

I dispositivi che soddisfano tutti i seguenti criteri sono esenti dal requisito riportato sopra:

• Il dispositivo implementa schermi con geometria variabile, ad esempio display pieghevoli o con cerniera.
• Quando cambia lo stato della cerniera o della piega del dispositivo, il dispositivo passa dall'orientamento Ritratto principale a quello Orizzontale principale (o viceversa).
• Implementazioni di dispositivi che non possono essere ruotati dall'utente, come i dispositivi per auto e motori.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

Implementazioni dei dispositivi:

• [C-0-1] DEVE includere un Download Manager che le applicazioni POSSONO utilizzare per scaricare file di dati e DEVE essere in grado di scaricare singoli file di dimensioni di almeno 100 MB nella posizione predefinita "cache".

7.6.2. Spazio di archiviazione condiviso dell'applicazione

Implementazioni dei dispositivi:

• [C-0-1] DEVE offrire spazio di archiviazione da condividere con le applicazioni, spesso indicato anche come "spazio di archiviazione esterno condiviso", "spazio di archiviazione condiviso 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 "out of the box", indipendentemente dal fatto che lo spazio di archiviazione sia implementato su un componente di archiviazione interno o su un supporto di archiviazione rimovibile (ad es. lo slot per schede digitali sicure).
• [C-0-3] È NECESSARIO montare lo spazio di archiviazione condiviso dell'applicazione direttamente sul percorso Linux sdcard o includere un link simbolico Linux da sdcard al punto di montaggio effettivo.
• [C-0-4] È OBBLIGATORIO attivare lo spazio di archiviazione delimitato 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 file manifest.
• [C-0-5] È OBBLIGATORIO oscurare i metadati sulla posizione, ad esempio i tag EXIF GPS, memorizzati nei file multimediali quando si accede a questi file tramite MediaStore, tranne quando l'app chiamante dispone dell'autorizzazione ACCESS_MEDIA_LOCATION.

Le implementazioni dei dispositivi POSSONO soddisfare i requisiti sopra indicati utilizzando uno dei seguenti metodi:

• Spazio di archiviazione rimovibile accessibile all'utente, ad esempio uno slot per schede Secure Digital (SD).
• Una parte della memoria interna (non rimovibile) implementata nell'Android Open Source Project (AOSP).

Se le implementazioni dei dispositivi utilizzano lo spazio di archiviazione rimovibile per soddisfare i requisiti di cui sopra, devono:

• [C-1-1] DEVE implementare un avviso di interfaccia utente popup o popup che avvisa l'utente quando non è inserito alcun supporto di archiviazione nell'alloggiamento.
• [C-1-2] DEVE includere un supporto di archiviazione con formato FAT (ad es. una scheda SD) o indicare sulla confezione e su altro materiale disponibile al momento dell'acquisto che il supporto di archiviazione deve essere acquistato separatamente.

Se le implementazioni dei dispositivi utilizzano una parte dello spazio di archiviazione non rimovibile per soddisfare i requisiti sopra indicati, devono:

• DOVREBBE utilizzare l'implementazione AOSP dello spazio di archiviazione condiviso dell'applicazione interna.
• POTREBBE condividere lo spazio di archiviazione con i dati privati dell'applicazione.

Se le implementazioni dei dispositivi dispongono di una porta USB con supporto della modalità periferica USB,

• [C-3-1] DEVE fornire un meccanismo per accedere ai dati dello spazio di archiviazione condiviso dell'applicazione da un computer host.
• DOVREBBE esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione dei contenuti multimediali di Android e android.provider.MediaStore.
• PUO' utilizzare l'archiviazione di massa USB, ma DEVE utilizzare il protocollo Media Transfer per soddisfare questo requisito.

Se le implementazioni dei dispositivi dispongono di una porta USB con modalità periferica USB e supportano Media Transfer Protocol, devono:

• DEVE essere compatibile con l'host MTP Android di riferimento, Android File Transfer.
• DOVREBBE segnalare una classe di dispositivo USB pari a 0x00.
• DOVREBBE riportare il nome dell'interfaccia USB "MTP".

7.6.3. Spazio di archiviazione utilizzabile

Se il dispositivo è di natura mobile, diversamente dalla televisione, le implementazioni del dispositivo sono:

• [C-SR-1] È FORTEMENTE CONSIGLIATO di implementare lo spazio di archiviazione adottabile in una posizione stabile a lungo termine, poiché la disconnessione accidentale può causare la perdita/corruzione dei dati.

Se la porta del dispositivo di archiviazione rimovibile si trova in una posizione stabile a lungo termine, come all'interno del vano batteria o di un'altra copertura protettiva, le implementazioni del dispositivo sono:

• [C-SR-2] È MOLTO CONSIGLIATO implementare lo spazio di archiviazione utilizzabile.

7.7. USB

Se le implementazioni dei dispositivi dispongono di una porta USB:

• DOVREBBE supportare la modalità periferica USB e la modalità host USB.
• DEVE supportare la disattivazione dell'indicatore dei dati tramite USB.

7.7.1. Modalità periferica USB

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità periferica:

• [C-1-1] La porta DEVE essere connettibile a un host USB con una porta USB di tipo A o C standard.
• [C-1-2] DEVE riportare il valore corretto di iSerialNumber nel descrittore del dispositivo standard USB tramite android.os.Build.SERIAL.
• [C-1-3] DEVE rilevare caricabatterie da 1,5 A e 3,0 A in base allo standard del resistore Type-C e DEVE rilevare le modifiche nell'annuncio se supportano USB Type-C.
• [C-SR-1] La porta DEVE utilizzare il fattore di forma USB micro-B, micro-AB o Type-C. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti in modo da poter eseguire l'upgrade alle release future della piattaforma.
• [C-SR-2] La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o attivare la rotazione dello schermo software per tutte le app (inclusa la schermata Home), in modo che il display venga visualizzato correttamente quando il dispositivo è orientato con la porta in basso. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti in modo da poter eseguire l'upgrade alle release future della piattaforma.
• [C-SR-3] DEVE implementare il supporto per assorbire una corrente di 1,5 A durante il chirp 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 release 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/sorgente, in quanto potrebbero verificarsi problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard di Power Delivery USB. Anche se questo è indicato come "FORTEMENTE CONSIGLIATO", nelle versioni future di Android potremmo obbligherà tutti i dispositivi Type-C a supportare l'interoperabilità completa con i caricabatterie Type-C standard.
• [C-SR-5] È FORTEMENTE CONSIGLIATO supportare Power Delivery per lo scambio di ruoli di alimentazione e dati quando supportano USB Type-C e modalità host USB.
• DOVREBBE supportare Power Delivery per la ricarica ad alta tensione e supportare le modalità alternative come l'uscita display.
• DEVE implementare l'API e le specifiche di 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 della funzionalità hardware android.hardware.usb.accessory.
• [C-2-2] La classe di archiviazione di massa USB DEVE includere la stringa "android" alla fine della stringa iInterface della descrizione dell'interfaccia dell'archiviazione di massa USB

7.7.2. Modalità host USB

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

• [C-1-1] DEVE implementare l'API host USB Android come descritto nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host.
• [C-1-2] DEVONO implementare il supporto per il collegamento di periferiche USB standard, in altre parole DEVONO:
  • Avere una porta di tipo C sul dispositivo o essere fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB Type-C standard (dispositivo USB Type-C).
  • Avere una porta di tipo A sul dispositivo o essere fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB di tipo A standard.
  • Avere una porta micro-AB sul dispositivo, che DOVREBBE essere fornita con un cavo di adattamento a una porta di tipo A standard.
• [C-1-3] NON deve essere fornito con un adattatore che converte da porte USB di tipo A o micro-AB a una porta di tipo C (presa).
• [C-SR-1] È MOLTO CONSIGLIATO implementare la classe audio USB come descritto nella documentazione dell'SDK Android.
• DEVE supportare la ricarica del dispositivo periferico USB collegato in modalità host; deve pubblicizzare una corrente di alimentazione di almeno 1, 5 A come specificato nella sezione Parametri di terminazione della Revisione 1.2 della specifica del cavo e del connettore USB Type-C per i connettori USB Type-C o utilizzare l'intervallo di corrente di uscita della porta di ricarica a valle (CDP) come specificato nella Revisione 1.2 delle specifiche per la ricarica della batteria USB per i connettori Micro-AB.
• DEVE implementare e supportare gli standard USB Type-C.

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e la classe audio USB, devono:

• [C-2-1] DEVE supportare la classe HID USB.
• [C-2-2] DEVE supportare il rilevamento e la mappatura dei seguenti campi di dati HID specificati nelle tabelle di utilizzo USB HID 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 il framework SAF (Storage Access Framework), devono:

• [C-3-1] DEVE riconoscere tutti i dispositivi MTP (Media Transfer Protocol) collegati 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, devono:

• [C-4-1] DEVE implementare la funzionalità della porta con doppio ruolo come definito dalla specifica USB Type-C (sezione 4.5.1.3.3). Per le porte con doppio ruolo, sui dispositivi che includono un jack audio da 3,5 mm, il rilevamento della presa USB (modalità host) PUÒ essere disattivato per impostazione predefinita, ma DEVE essere possibile per l'utente attivarlo.
• [C-SR-2] È MOLTO CONSIGLIATO supportare DisplayPort, DEVE supportare le velocità di trasmissione dati USB SuperSpeed ed È MOLTO CONSIGLIATO supportare Power Delivery per lo scambio di ruoli di alimentazione e dati.
• [C-SR-3] È FORTEMENTE CONSIGLIATO di NON supportare la modalità di accessorio dell'adattatore audio come descritto nell'appendice A della Revisione 1.2 della specifica del cavo e del connettore USB Type-C.
• DOVREBBE implementare il modello Try.* più appropriato per il fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DOVREBBE implementare il modello Try.SNK.

7.8. Audio

7.8.1. Microfono

Se le implementazioni del dispositivo includono un microfono:

• [C-1-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.microphone.
• [C-1-2] DEVE soddisfare i requisiti di registrazione audio riportati nella sezione 5.4.
• [C-1-3] DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
• [C-SR-1] È MOLTO CONSIGLIATO supportare la registrazione in modalità quasi ultrasuoni come descritto nella sezione 7.8.3.

Se le implementazioni del dispositivo omettono un microfono:

• [C-2-1] NON DEVE segnalare la costante della funzionalità android.hardware.microphone.
• [C-2-2] È OBBLIGATORIO implementare l'API di registrazione audio almeno come no-op, come indicato nella sezione 7.

7.8.2. Uscita audio

Se le implementazioni del dispositivo includono uno speaker o una porta di output audio/multimedia 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, devono:

• [C-1-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.audio.output.
• [C-1-2] DEVE soddisfare i requisiti di riproduzione audio riportati nella sezione 5.5.
• [C-1-3] DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
• [C-SR-1] È FORTEMENTE CONSIGLIATO supportare la riproduzione a frequenza quasi ultrasonica come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono uno speaker o una porta di uscita audio, devono:

• [C-2-1] NON DEVE segnalare la funzionalità android.hardware.audio.output.
• [C-2-2] È NECESSARIO implementare le API relative all'output audio almeno come no-op.

Ai fini di questa sezione, una "porta di uscita" è un'interfaccia fisica come un jack audio da 3, 5 mm, HDMI o una porta in modalità host USB con classe audio USB. Il supporto dell'uscita audio tramite protocolli basati su radio, come Bluetooth, Wi-Fi o rete mobile, non è considerato una "porta di uscita".

7.8.2.1. Porte audio analogiche

Per essere compatibili con gli auricolari e altri accessori audio che utilizzano il jack audio da 3,5 mm nell'ecosistema Android, se le implementazioni del dispositivo includono una o più porte audio analogiche, devono:

• [C-SR-1] È FORTEMENTE CONSIGLIATO includere almeno una delle porte audio con un jack audio da 3,5 mm a 4 conduttori.

Se le implementazioni del dispositivo hanno un jack audio da 3,5 mm a 4 conduttori, devono:

• [C-1-1] DEVE supportare la riproduzione audio su cuffie stereo e cuffie stereo con microfono.
• [C-1-2] DEVE supportare i connettori audio TRRS con l'ordine dei pin CTIA.
• [C-1-3] DEVE supportare il rilevamento e la mappatura ai codici a tasti per i seguenti 3 intervalli di impedenza equivalente tra i conduttori del microfono e della 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 del connettore, ma solo dopo che tutti i contatti del connettore toccano i relativi segmenti sul jack.
• [C-1-5] DEVE essere in grado di fornire almeno 150 mV ± 10% di tensione di uscita su un'impedenza dello speaker di 32 ohm.
• [C-1-6] DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V e 2,9 V.
• [C-1-7] DEVE rilevare e mappare al codice a chiave per il seguente intervallo di impedenza equivalente tra i conduttori del microfono e di messa a terra sul connettore audio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR-2] È MOLTO CONSIGLIATO supportare i connettori audio con l'ordine di pin-out OMTP.
• [C-SR-3] Sono FORTEMENTE CONSIGLIATI 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 extra del microfono impostato su 1, devono:

• [C-2-1] DEVE supportare il rilevamento del microfono sull'accessorio audio collegato.

7.8.2.2. Porte audio digitali

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

7.8.3. Near-Ultrasound

L'audio quasi a ultrasuoni è la banda da 18,5 kHz a 20 kHz.

Implementazioni dei dispositivi:

• DEVE segnalare correttamente il supporto della funzionalità audio a ultrasuoni vicini tramite l'API AudioManager.getProperty come segue:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND è "true", le sorgenti audio VOICE_RECOGNITION e UNPROCESSED DEVONO soddisfare i seguenti requisiti:

• [C-1-1] La risposta in 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 pesato del microfono in un intervallo di frequenza compreso tra 18,5 kHz e 20 kHz per un tono a 19 kHz a -26 dBFS NON DEVE essere inferiore a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND è "true":

• [C-2-1] La risposta media dell'altoparlante nella gamma di 18,5 kHz - 20 kHz NON DEVE essere inferiore a 40 dB rispetto alla risposta a 2 kHz.

7.8.4. Integrità del segnale

Implementazioni dei dispositivi:

• DEVE fornire un percorso del segnale audio senza glitch sia per gli stream di input che per quelli di output sui dispositivi portatili, come definito da zero glitch misurati durante un test di un minuto per percorso. Esegui il test utilizzando OboeTester "Test di glitch automatico".

Il test richiede un dongle 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. È NECESSARIO testare tutte le porte di uscita audio.

OboeTester attualmente supporta i percorsi AAudio, pertanto le seguenti combinazioni DOVREBBERO essere testate per verificare la presenza di glitch utilizzando AAudio:

Modalità Perf	Condivisione	Frequenza di campionamento in uscita	In canali	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

Uno stream affidabile DEVE soddisfare i seguenti criteri per il rapporto segnale/rumore (SNR) e la distorsione armonica totale (THD) per un segnale sinusoidale 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 uno speaker di riferimento esterno	< 3,0%	>= 50 dB
Jack da 3,5 mm analogici integrati, testati utilizzando l'adattatore di loopback	< 1%	>= 60 dB
Adattatori USB forniti in dotazione con lo smartphone, testati utilizzando l'adattatore loopback	< 1,0%	>= 60 dB

7.9. Realtà virtuale

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

7.9.1. Modalità realtà virtuale

Android include il supporto della modalità VR, una funzionalità che gestisce il rendering stereoscopico delle notifiche e disattiva i componenti dell'interfaccia utente di sistema monoculare quando un'applicazione VR ha l'attenzione dell'utente.

7.9.2. Modalità realtà virtuale - Prestazioni elevate

Se le implementazioni del dispositivo supportano la modalità VR:

• [C-1-1] DEVE avere almeno 2 core fisici.
• [C-1-2] È OBBLIGATORIO dichiarare la funzionalità android.hardware.vr.high_performance.
• [C-1-3] DEVE supportare la modalità di prestazioni sostenute.
• [C-1-4] DEVE supportare OpenGL ES 3.2.
• [C-1-5] DEVE supportare 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,