Definizione di compatibilità con Android 14

1. Introduzione

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

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 del dispositivo" o "implementatore" è una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 14. Un'"implementazione del dispositivo" o "implementazione" è la soluzione hardware/software così sviluppata.

Per essere considerate compatibili con Android 14, 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 palmari se soddisfano tutti i seguenti criteri:

• Avere una fonte di alimentazione che offra mobilità, ad esempio una batteria.
• Avere una dimensione dello schermo diagonale fisica compresa tra 10 cm 8,4 cm (o 6,3 cm per le implementazioni dei dispositivi con livello API 29 o precedente) 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.

2.2.1. Hardware

Implementazioni dei dispositivi portatili:

• [7.1.1.1/H-0-1] DEVE avere almeno un display compatibile con Android che soddisfi tutti i requisiti descritti in questo documento. display che misura 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ù elevata di qualsiasi display integrato.

Se le implementazioni dei dispositivi mobili dichiarano di supportare i display HDR tramite Configuration.isScreenHdr() :

• [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] È FORTEMENTE 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 pseudo-raggiunge 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à.
• [7.4.3/H] DEVE includere il supporto per Bluetooth e Bluetooth LE.

Se i dispositivi supportano il protocollo NAN (WiFi Neighbor Awareness Networking) dichiarando PackageManager.FEATURE_WIFI_AWARE e la posizione Wi-Fi (tempo di transito Wi-Fi - 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 segnalare 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 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 del framebuffer fino a HD+ (ad es. HD, WSVGA).

• [7.6.1/H-3-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 896 MB se il display predefinito utilizza risoluzioni 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 del framebuffer fino a HD+ (ad es. HD, WSVGA).

• [7.6.1/H-7-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere 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 in aggiunta 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.

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

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

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 lunga 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, viene eseguito 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.

Se le implementazioni dei dispositivi palmari dichiarano android.hardware.audio.output e android.hardware.microphone:

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

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 a risonanza lineare 7.10 generale, devono:

• [7.10/H] DEVE spostare l'attuatore aptico sull'asse X (da sinistra a destra) dell'orientamento naturale verticale 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 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

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

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]* È OBBLIGATORIO precaricare uno o più componenti di servizi o applicazioni 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 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 dei dispositivi 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 complessa designati dall'app tra i controlli registrati dalle applicazioni di terze parti tramite le API ControlsProviderService e Control Control.isAuthRequired.

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 della clipboard 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 a quelli di 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 per le 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.

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 nel menu Impostazioni 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. e la possibilità di interrompere un'app in cui è in esecuzione un servizio in primo piano o un job avviato dall'utente.con la possibilità di interrompere un'app in cui è in esecuzione un servizio in primo piano e visualizzare tutte le app con servizi in primo piano attivi e la durata di ciascuno di questi servizi dall'avvio, come descritto nel documento dell'SDK.
  • Alcune app POTREBBERO essere esenti dall'interruzione o dall'inserimento in un'opzione di questo tipo per l'utente, come descritto nel documento dell'SDK.

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.

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 di crittografia RSA, AES, ECDSA e HMAC e funzioni hash di famiglie MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e sopra. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi 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.
• [9.11/H-0-5] DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori dei dispositivi. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore 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 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.

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 il rilevamento delle query sempre attive, senza indicazione di accesso al microfono o alla videocamera.

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 on-device 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 dal servizio di rilevamento hotword per ogni risultato positivo tranne che per i dati audio trasmessi tramite HotwordAudioStream.
• [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 dei 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-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 (in toto o in parte) 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 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.

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.

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.

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

• Perfetto
  • [6.1/H-0-2]* DEVE esporre un file /system/bin/perfetto binario all'utente della shell la cui cmdline sia conforme alla 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).

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.T per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, allora:

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

2.2.7.2. Fotocamera

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.T per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, allora:

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

2.2.7.3. Hardware

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.T per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, significa che:

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

2.2.7.4. Prestazioni

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.T per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, significa che:

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

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 "10-foot").

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

• Avere fornito un meccanismo per controllare da remoto l'interfaccia utente visualizzata sul display che potrebbe trovarsi a tre metri di distanza dall'utente.
• Avere uno schermo integrato con una diagonale maggiore di 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 principali tasti di navigazione.

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 oltre 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

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

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. DEBBONO 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 dell'audio compresso (in cui 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] È OBBLIGATORIO impostare la modalità di uscita HDMI sulla risoluzione più alta 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. DEVE impostare la modalità di uscita HDMI su selezionare la risoluzione massima che può essere supportata con una frequenza di aggiornamento di 50 Hz o 60 Hz.
• [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] È OBBLIGATORIO 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.

Implementazioni dei dispositivi TV:

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

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 un rendimento 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] DEVE 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 potenza 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 criptici RSA, AES, ECDSA e HMAC e funzioni hash di famiglie MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e 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.
• [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 sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori dei dispositivi. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore 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 Permissions with CDD identifier 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

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.

2.4. Requisiti dell'orologio

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

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

• Avere uno schermo con una lunghezza diagonale fisica compresa tra 28 e 64 mm.
• Avere un meccanismo che 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 non è ancora stata segnalata una posizione calcolata da GPS/GNSS.
• [7.3.3/W-1-2] DEVE segnalare le velocità e i pseudointervalli 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 filtro 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 smartwatch 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:

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

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.
• [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 la fusione del segnale GPS/GNSS con sensori aggiuntivi. Se la posizione viene calcolata in base alla navigazione stimata, è MOLTO CONSIGLIATO 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.

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.

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, devono:

• [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 di almeno 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 di configurare l'intervallo di misurazione del giroscopio su +/-250 giri/min 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 relativi al 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 il calcolo approssimativo della posizione 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 su rete mobile tramite il profilo Hands-Free (HFP).
  • Riproduzione di contenuti multimediali tramite il profilo Audio Distribution (A2DP).
  • Controllo della riproduzione dei contenuti multimediali tramite il profilo di controllo remoto (AVRCP).
  • Condivisione dei contatti tramite il profilo Phonebook Access (PBAP).

• [7.4.3/A-SR-1] È FORTEMENTE CONSIGLIATO supportare il profilo di accesso ai messaggi (MAP).

• [7.4.5/A] DEVE includere il supporto per la connettività dati basata su 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.

Implementazioni di dispositivi per auto e motori:

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

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

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

• [7.6.1/A-2-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 816 MB se vengono utilizzate 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 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 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 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.

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.

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

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.

• [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 Automotive 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 visibili la barra di stato e la barra di navigazione in qualsiasi momento.
• [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 disponibile questo consumo di energia tramite il comando shell adb shell dumpsys batterystats per lo 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.camera.any, then:

• [9.8.2/A-2-1] L'indicatore della videocamera DEVE essere visualizzato quando un'app accede ai dati della videocamera in tempo reale, ma non quando la videocamera è accessibile solo alle app che detengono i ruoli definiti indicati nella sezione 9.1 Autorizzazioni con identificatore CDD [C-4-X][C-3-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.

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, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e sopra. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi 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.
• [9.11/A-0-4] DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori dei dispositivi. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore 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

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.

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.

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

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 è il 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.

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:
  • Hanno 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à API soft

Oltre alle API gestite della sezione 3.1, Android include anche un'API "soft" significativa solo in fase di runtime, sotto forma di elementi quali 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 delle versioni consentite per Android 14.
VERSION.SDK	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 14, questo campo DEVE avere il valore intero 14_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 14, questo campo DEVE avere il valore intero 14_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 deve 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_-]+$".
SUPPORTED_ABIS	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con API native.
SUPPORTED_32_BIT_ABIS	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con API native.
SUPPORTED_64_BIT_ABIS	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con 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_-]+$". Il 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:14/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. 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 ragione sociale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota (""). Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.
SOC_MANUFACTURER	La denominazione commerciale del produttore del sistema 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 la vita utile 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 del prodotto NON DEVE cambiare durante il ciclo di 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 le 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: 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 per le applicazioni

Gli intent di 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, ad eccezione di 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 dei 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 di dati "http://www.android.com" è più specifico del pattern di intent principale del browser per "http://".

Android include anche un meccanismo per consentire alle app di terze parti di dichiarare un comportamento di collegamento delle app predefinito autorevole per determinati tipi di intent URI web. Quando queste dichiarazioni autorevoli sono definite nei pattern di filtro 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 dell'app predefinite 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:

• [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 gestisce 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 l'adempimento 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:

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

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 indicatore con il valore 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.

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

• [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] DEVE esportare i simboli di funzione per i simboli di funzione di base Vulkan 1.0 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 release 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 build del progetto Chromium dal progetto open source Android upstream sul ramo Android 14 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 per il maggior numero possibile di funzionalità HTML5 e, se supporta la funzionalità, DEVE essere conforme alla specifica HTML5.

• [C-1-4] DEVE eseguire il rendering dei contenuti forniti o dei contenuti dell'URL remoto in un processo distinto dall'applicazione che 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 il LocationManager metodo della classe API o il WifiManager.startScan() metodo.
  • [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 alcune parti significative della piattaforma per verificarne la compatibilità di comportamento, ma non 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.*

In altre parole:

• [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 com.google.* o a un ambito simile: solo Google può farlo. Allo stesso modo, Google NON DEVE aggiungere API agli ambiti 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à con il 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] È OBBLIGATORIO 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 (280dpi)
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
piccolo/normale	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)	48MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)
	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 (280dpi)	96MB
	320 dpi (xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512MB
xlarge	120 dpi (ldpi)	48MB
	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 (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

Android include un'applicazione Avvio app (schermata Home) e il supporto 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, 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 piattaformaandroid.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 nella dimensione 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 di 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, queste:

• [C-1-1] DEVE supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK e, nella misura del possibile, con l'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 è carente di hardware, le API corrispondenti DEVONO essere implementate come no-op. Questo comportamento è approfondito nella sezione 7.
• [C-1-2] DEVONO eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) previste nelle API o nella guida allo stile delle icone della barra di stato/sistema, anche se POSSONO offrire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'implementazione di riferimento di Android Open Source.
• [C-1-3] DEVE rispettare e implementare correttamente i comportamenti descritti per le API per aggiornare, rimuovere e raggruppare le notifiche.
• [C-1-4] DEVE fornire il comportamento completo dell'API NotificationChannel documentato nell'SDK.
• [C-1-5] DEVE fornire all'utente la possibilità di bloccare e modificare la notifica di una determinata app di terze parti per ogni livello di canale e pacchetto di app.
• [C-1-6] 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 "notifiche 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 non appena 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 questi 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] DEVE rendere disponibile questa funzionalità per posticipare le notifiche di ogni app di terze parti installata, a meno che non provengano da servizi persistenti/in primo piano.

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

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

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

3.8.4. API Assist

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 delle relative risorse esposte 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, eMONOCHROMATIC.

  "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 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 4 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 usate 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 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] È NECESSARIO 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 le diverse emoji di famiglia come specificato nel report tecnico Unicode n. 51.

Se le implementazioni del dispositivo includono un IME, devono:

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

Android include il supporto per il rendering dei caratteri birmani. In Myanmar esistono 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.

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 sull'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

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

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

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

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

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

3.9.1.2 Provisioning dei profili gestiti

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

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

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

• [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 dell'utente principale o del profilo 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 (consulta la sezione 9.5), anche se il profilo gestito non viene conteggiato come un altro utente oltre all'utente principale.

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 per gli 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 dei criteri 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 del 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 описано выше:

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

3.12. TV Input Framework

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

Se le implementazioni del dispositivo supportano TIF:

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

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] È OBBLIGATORIO 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 delle 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 deve indicare 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 dall'utilizzo di un intent con azione impostata su Intent.ACTION_VIEW e con uno schema di "http" o "https", un'affordance utente aggiuntiva DEVE consentire all'utente di non avviare l'app istantanea e di avviare il link associato con il browser web configurato, se un browser è disponibile sul dispositivo.
  • [C-1-7] DEVE consentire l'accesso alle app istantanee 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 secondario:

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

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 essere memorizzati 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.

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.
  • L'utente DEVE aver 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.

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 quanto segue:

• [C-2-1] La decodifica DEVE essere eseguita senza downmixing (ad es. uno stream AAC 5.0 deve essere decodificato in cinque canali PCM, uno stream AAC 5.1 deve essere decodificato in sei canali PCM).
• [C-2-2] I metadati relativi all'intervallo dinamico DEVONO essere come definiti in "Controllo dell'intervallo dinamico (DRC)" in ISO/IEC 14496-3 e le chiavi DRC android.media.MediaFormat per configurare i comportamenti relativi all'intervallo dinamico del decodificatore audio. Le chiavi 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 DRC e livello di volume DEVONO essere interpretati e applicati in base al profilo di controllo dinamico del livello di DRC MPEG-D 1.
• [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 avranno 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 riprodotti 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, allora:

• [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, è MOLTO CONSIGLIATO che il decoder pubblicizzi 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).

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) ADTS raw AAC (.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+ avanzato)	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

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 di codifica 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 del dispositivo supportano la decodifica video HEVC: * [C-1-1] DEVONO 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 per 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 Android Open Source (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 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.
• DEVE supportare sia i codificatori video VP8 che 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 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 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 profilo di riferimento di Livello 45. La risoluzione SQCIF è facoltativa.
• DEVE supportare le velocità in bit configurabili dinamicamente per il codificatore supportato.

5.2.2. H.264

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

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

Se le implementazioni dei dispositivi segnalano il supporto della codifica H.264 per i video con risoluzione 720p o 1080p tramite le API multimediali, 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.
• DOVREBBE 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.
• DEVE supportare i profili di codifica HD come indicato nella tabella seguente.
• [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.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 all'interno dello stesso stream per tutti i codec VP8, VP9, H.264 e H.265 in tempo reale e fino alla risoluzione massima supportata da ciascun codec sul dispositivo.

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 384 kbps) e il livello 45 (risoluzioni QCIF e SQCIF a 30 fps 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/sTelevisore)
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.
• DOVREBBE 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 fps (60 fpsTelevisore 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/sTelevisore)	30 (60 fpsTelevisione)
Velocità in bit video	800 kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

• [C-1-1] DEVE supportare i profili di decodifica video SD come indicato nella tabella seguente.
• DOVREBBE 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 fpsTelevisore 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:

• [C-1-1] È OBBLIGATORIO fornire un'apposita app per l'estrazione di file compatibile con Dolby Vision.
• [C-1-2] DEVE mostrare correttamente i contenuti Dolby Vision sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).
• [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

5.4. Registrazione audio

Sebbene alcuni dei requisiti descritti in questa sezione siano elencati come DOVREBBE da Android 4.3, la definizione di compatibilità per le versioni future è prevista per modificarli in DEVE. È FORTEMENTE consigliato che i dispositivi Android esistenti e nuovi soddisfino questi requisiti indicati come DOVREBBERO, 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, 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] È OBBLIGATORIO 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 a una distanza di 30 cm da accanto a il microfono) produca una risposta ideale di 2500 RMS in un intervallo compreso tra 1770 e 3530 per campioni di 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. Acquisisci per il reindirizzamento della riproduzione

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

Se le implementazioni del dispositivo dichiarano sia android.hardware.audio.output sia android.hardware.microphone, 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:

• DOVREBBE 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 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'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 sottoclassi 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.

• 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 dei dispositivi 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 è 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. La media del valore assoluto delle deviazioni dalla media per un insieme di valori.

• Latenza tap-to-tone. Il tempo che intercorre tra il tocco dello schermo e il momento in cui viene sentito un suono generato dal tocco sullo speaker.

Se le implementazioni del dispositivo dichiarano android.hardware.audio.output, devono soddisfare o superare i seguenti requisiti:

• [C-1-1] Il timestamp di output restituito da AudioTrack.getTimestamp e AAudioStream_getTimestamp è preciso con una tolleranza di +/- 2 ms.

• [C-1-2] Latenza di 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.

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

• [C-SR-1] Latenza di output a freddo di massimo 100 millisecondi sul percorso dei dati dello speaker.
• [C-SR-2] Latenza da tocco a tono pari o inferiore a 80 millisecondi.

Se le implementazioni dei dispositivi soddisfano i requisiti sopra indicati, dopo la calibrazione iniziale, quando si utilizza l'API audio nativa AAudio, per la latenza di uscita continua e la latenza di uscita a freddo su almeno un dispositivo di output audio supportato, i valori sono:

• [C-SR-5] È MOLTO 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.

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.

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

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

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 di dati del microfono.

• [C-SR-11] Limita l'errore nei timestamp di input, restituiti da AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 1 ms.

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 continuata di massimo 50 millisecondi su 5 misurazioni, con una deviazione assoluta media inferiore a 10 ms, su almeno un percorso supportato.

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.
• [C-1-2] DEVE avere una latenza audio in tempo di round trip continua, come definito nella sezione 5.6 Latenza audio, di massimo 25 millisecondi su almeno un percorso supportato.
• [C-1-3] DEVE includere una o più porte USB che supportano la modalità host USB e la modalità periferica USB.
• [C-1-4] DEVE segnalare il supporto della funzionalità android.software.midi.
• [C-1-5] DEVE soddisfare i requisiti relativi alle latenze e all'audio USB utilizzando l'API audio nativo AAudio e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [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.

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

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.

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

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

• [C-SR-5] È FORTEMENTE CONSIGLIATO di rispettare la sezione Specifiche del jack per dispositivi mobili della Specifica per cuffie audio con cavo (v1.1).

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

• [C-3-1] È NECESSARIO implementare la classe audio USB.
• [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.

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.

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 metterla a disposizione di app di terze parti:

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

• [C-1-2] DEVE presentare caratteristiche di ampiezza 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).

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 essere dato 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 se 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)

  • [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, incluso dumpsys cmd stats
  • [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.
  • [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
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [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 aggregati della GPU 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.
• POTREBBE limitare temporaneamente l'accesso al menu Opzioni sviluppatore nascondendolo o disattivandolo visivamente per evitare distrazioni in scenari in cui la sicurezza dell'utente è in discussione.

7. Compatibilità hardware

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

• [C-0-1] L'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android.

Se un'API nell'SDK interagisce con un componente hardware dichiarato facoltativo e l'implementazione del dispositivo non dispone di questo componente:

• [C-0-2] È comunque necessario presentare definizioni di classi complete (come documentato dall'SDK) per le API dei componenti.
• [C-0-3] I comportamenti dell'API DEVONO essere implementati come no-op in modo ragionevole.
• [C-0-4] I metodi 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 modo appropriato per il dispositivo, in modo da garantire il corretto funzionamento delle applicazioni di terze parti su una varietà di configurazioni hardware. varie tipologie di display e configurazioni 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. Sui display compatibili con Android su cui possono essere eseguite tutte le applicazioni di terze parti compatibili con Android, le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

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

• Dimensioni diagonali fisiche. La distanza in pollici tra due angoli opposti della parte illuminata del display.
• punti per pollice (dpi)densità. 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 dpi ppi e dpi, i valori 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 avrebbe un rapporto di 854/480 = 1,779, ovvero approssimativamente "16:9".
• pixel indipendenti dalla densità (dp). L'unità di pixel virtuale A è stata normalizzata a una densità di 160 dpi sullo schermo. Per una determinata densità d e un numero di pixel p, il numero di pixel indipendenti dalla densità dp viene calcolata come segue: pixel = dps * (densità/160) 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 schermi compatibili con la UI_MODE_TYPE_NORMAL configurazione delle dimensioni e includono display fisici con angoli arrotondati per visualizzare questi schermi, devono:

• [C-1-1] DEVE garantire che almeno uno dei seguenti requisiti sia soddisfatto per ogni visualizzazione:

  • Il raggio degli angoli arrotondati è inferiore o uguale a 38 dp.
  • Quando un riquadro di 1518 dp x 1518 dp è ancorato a ogni angolo della visualizzazione logica, almeno un pixel di ogni riquadro è visibile sullo schermo.

• DEVE includere l'affordance per consentire all'utente di passare alla modalità di visualizzazione con gli angoli rettangolari.

Per informazioni dettagliate sull'implementazione corretta delle API sidecar o di estensione, consulta la documentazione pubblica di Window Manager Jetpack.

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] Per impostazione predefinita, le implementazioni dei dispositivi DEVONO segnalare solo una delle densidade del framework Android elencate su DisplayMetrics tramite l'API DENSITY_DEVICE_STABLE e questo valore deve essere un valore statico per ogni display fisico. NON deve cambiare in nessun momento; tuttavia, tuttavia il dispositivo PUÒ registrare una densità arbitraria distinta DisplayMetrics.density in base alle modifiche alla configurazione del display apportate dall'utente (ad es. dimensioni del display) impostate dopo l'avvio iniziale.

Se le implementazioni dei dispositivi forniscono un'opzione per cambiare le dimensioni del display del dispositivo, devono:

• [C-1-1] Le dimensioni del display NON DEVONO essere scalate NON DEVONO essere scalate più di 1,5 volte la DENSITY_DEVICE_STABLE densità nativa 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] Le dimensioni del display NON DEVONO essere ridimensionate NON DEVONO ridimensionare il display meno di 0,85 volte la DENSITY_DEVICE_STABLE densità nativa.
• Per garantire una buona usabilità e dimensioni dei caratteri coerenti, È CONSIGLIATO fornire la seguente scalabilità delle opzioni di visualizzazione nativa (nel rispetto dei limiti specificati sopra):
  • Piccola: 0,85x
  • Valore predefinito: 1x (scala di visualizzazione nativa)
  • Grande: 1,15x
  • Più grande: 1,3 volte
  • Più grande 1,45x

7.1.2. Metriche relative alla visualizzazione

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

• [C-1-1] DEVE supportare sia OpenGL ES 1.1 che 2.0, come descritto e dettagliato nella documentazione dell'SDK Android.
• [C-SR-1] È VIVAMENTE CONSIGLIATO supportare OpenGL ES 3.1.
• 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 del codice sorgente di Android in external/deqp/android/cts/main/glesXX-main-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 di 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 del codice sorgente di Android in external/deqp/android/cts/main/vk-main-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 1.0 o versioni successive:

• [C-1-1] DEVE riportare il valore intero corretto con i flag di funzionalità android.hardware.vulkan.level e android.hardware.vulkan.version.
• [C-1-2] DEVE elencare almeno un VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices().
• [C-1-3] DEVE implementare completamente le API Vulkan 1.0 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 Vulkan native 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.

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 del dispositivo includono il supporto di Vulkan 1.1 e dichiarano uno dei flag funzionalità Vulkan descritti qui , devono:

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

7.1.4.3 RenderScript

• [C-0-1] Le implementazioni dei dispositivi DEVONO supportare Android RenderScript, come descritto nella documentazione dell'SDK Android.

7.1.4.4 Accelerazione grafica 2D

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

Implementazioni dei dispositivi:

• [C-0-1] DEVE attivare l'accelerazione hardware per impostazione predefinita e DEVE 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 alle dimensioni dello schermo "normali" (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.
• DEVE 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 di sistema e l'API 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] DEVONO essere accessibili con una singola azione (ad es. tocco, doppio clic o gesto) quando sono accessibili.
• [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 del dispositivo forniscono la funzione Menu, devono:

• [C-2-1] DEVE mostrare il pulsante di overflow delle azioni ogni volta che il menu popup di overflow delle azioni non è vuoto e la barra delle azioni è visibile.
• [C-2-2] NON DEVE modificare la posizione del popup 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 deve 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] È MOLTO CONSIGLIATO 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 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 il riquadro di sistema NON DEVE utilizzare 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 inizi 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 segnalare 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 di android.hardware.faketouch.multitouch.distinct:

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

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

• [C-3-1] È OBBLIGATORIO dichiarare il supporto di android.hardware.faketouch.
• [C-3-2] DEVE supportare il 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 HID2	Pulsante Android
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Pulsante direzionale su1 Pulsante direzionale giù1	0x01 0x00393	AXIS_HAT_Y4
D-pad sinistra1 D-pad destra1	0x01 0x00393	AXIS_HAT_X4
Pulsante del tasto sinistro1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Pulsante del tasto funzione destro1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic con la levetta sinistra1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic con il tasto destro della levetta1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Indietro1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

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

3 Questo utilizzo deve avere un valore minimo logico 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 analogici1	Utilizzo HID	Pulsante Android
Triangolo sinistro	0x02 0x00C5	AXIS_LTRIGGER
Trigger destro	0x02 0x00C4	AXIS_RTRIGGER
Joystick sinistro	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick destro	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Telecomando

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

7.3. Sensori

Se le implementazioni del dispositivo includono un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android e nella documentazione Android Open Source relativa ai sensori.

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare con precisione la presenza o l'assenza di sensori in base alla classe android.content.pm.PackageManager.
• [C-0-2] DEVE restituire un elenco accurato dei sensori supportati tramite metodi come SensorManager.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 lo stream di un 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 un'accuratezza 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 la documentazione Android Open Source sui sensori devono essere considerati autorevoli.

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 descritti nella sezione 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 la gravità(4 g) o più su qualsiasi asse.
• [C-1-5] DEVE avere una risoluzione di almeno 12 bit.
• [C-1-6] DEVE avere una deviazione standard non superiore a 0,05 m/s^, dove la deviazione standard deve essere calcolata in base all'asse 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 tre 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 quando richieste tramite LocationManager#requestLocationUpdate.
• [C-1-2] DEVE essere in grado di determinare la posizione in condizioni di cielo aperto (segnali forti, multipath trascurabile, HDOP < 2) entro 10 secondi (tempo di acquisizione della prima correzione rapido), quando connesso a una connessione internet con velocità di 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 continuare a fornire normali output di posizione GPS/GNSS tramite le API GNSS Location Provider durante una chiamata di emergenza.

• [C-SR-3] È MOLTO 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 di almeno 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 una precisione assoluta di 1 hPa.
• DEVE avere una precisione relativa di 0,12 hPa su un intervallo di 20 hPa (equivalente a una precisione di circa 1 m su una variazione di circa 200 m a livello del mare).

7.3.6. Termometro

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:

• [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 di tipo "vicino" o "lontano", 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 superiore a 2 mW.

• [C-2-8] DEVE avere un sensore TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] DEVE avere un sensore TYPE_SIGNIFICANT_MOTION che:

  • DEVE avere un consumo 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 del processore dell'applicazione. 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 soluzioni di autenticazione biometrica di classe 2 sia 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 le biometriche di classe 3 o classe 2 come definiti 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.

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 compromessa da un sistema operativo o dal 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-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 di 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 tentativi falsi e non meno di 90 secondi di tempo di attesa per la verifica biometrica, 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-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 di Android Biometrics.
• [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 furto d'identità non superiore al 30%, 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 30% e (2) un tasso di accettazione di spoofing e furto d'identità 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.

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

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

• [C-1-7] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) una volta ogni 24 ore o meno. Nota: l'upgrade dei dispositivi lanciati con Android 9 o versioni precedenti DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) una volta ogni 72 ore o meno.

• [C-1-8] DEVE richiedere all'utente l'autenticazione primaria consigliata (ad es. 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 POTREBBE essere esente da C-1-8.

• [C-SR-7] È FORTEMENTE CONSIGLIATO di utilizzare la logica del framework fornita 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 falsi rifiuti 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.

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-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), o su un chip con un canale sicuro per l'ambiente di esecuzione isolato o su una macchina virtuale protetta che soddisfa i requisiti della Sezione 9.17.
• [C-2-4] DEVONO essere criptati e autenticati tramite crittografia tutti i dati identificabili 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 descritto nelle linee guida di implementazione sul sito del progetto Android Open Source Project o di una macchina virtuale protetta controllata dall'hypervisor che soddisfi 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 la modifica dei frame della videocamera al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro per l'ambiente di esecuzione isolato o di una macchina virtuale protetta controllata da un 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'Applicativo Processore 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 la versione 9 o precedente di Android 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 es. 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.

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] DEVE 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 e mettono a disposizione la funzionalità a un'applicazione di terze parti, devono:

7.4. Connettività dei dati

7.4.1. Telefonia

"Telefonia", come utilizzato dalle API Android e in questo documento, si riferisce specificamente all'hardware relativo all'invio di chiamate vocali e 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 la "Telefonia" può scegliere di offrire alcuni o tutti i servizi di chiamate, messaggistica e dati in base al prodotto.

tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano o meno essere con commutazione di pacchetti,ai fini di Android sono considerate indipendenti da qualsiasi connettività dati che possa essere implementata utilizzando la stessa rete. In altre parole,le API e la funzionalità "telefonia" di Android si riferiscono specificamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni di dispositivi che non possono effettuare chiamate o inviare/ricevere messaggi SMS non sono considerate dispositivi di telefonia, indipendentemente dal fatto che utilizzino una rete cellulare per la connettività dati.

• Android PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. In altre parole, Android è compatibile con dispositivi diversi dagli smartphone.

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

• [C-1-1] DEVE dichiarare il flag funzionalità android.hardware.telephony e altri flag delle sottofunzionalità in base alla tecnologia.
• [C-1-2] DEVE implementare il supporto completo dell'API per la tecnologia in questione.
• 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] È OBBLIGATORIO 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, allora:

• [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 durante i tentativi 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 la risposta a una chiamata in arrivo comporterà l'interruzione dell'altra chiamata.

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

Avvia nuovi requisiti

• [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 incluso: quando lo schermo non è attivo, a meno che il blocco multicast non sia attivo e i pacchetti non siano 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.

  • Anche quando lo schermo non è attivo.
  • Per le implementazioni dei dispositivi Android TV, anche in stato di standby.

• [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] È FORTEMENTE CONSIGLIATO di 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 in 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:

• DEVE 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 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 di 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 di 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] È NECESSARIO includere le 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 misure.

• [C-SR-2] È FORTEMENTE CONSIGLIATO misurare e compensare l'offset Rx per assicurarsi che l'RSSI BLE mediano 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.

  I requisiti [C-10-3] e [C-10-4] sono stati spostati in 2.2.1. Hardware.

È 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:

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

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

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

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

• DOVREBBE essere in modalità di rilevamento NFC quando il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.

• DEVE essere in grado di 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] DEVE 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 mostrare 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 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, mentre 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 fornisce l'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:

• [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] DEVE dichiarare i flag di 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 imporre che le app che utilizzano la radio UWB debbano disporre dell'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 nel range [0,75 m, 1,25 m], dove la distanza di verità sulla scena viene misurata dal bordo superiore del DUT. tenuto con la parte superiore rivolta verso l'alto e inclinato a 45 gradi.
• [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à videocamera 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

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 fotocamera di sistema integrata del dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

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 del 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 speculare rispetto all'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

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 essere inoltre nel formato di codifica NV21 quando un'applicazione registra un'istanza android.hardware.Camera.PreviewCallback e il sistema chiama il metodo onPreviewFrame() e il formato di anteprima è YCbCr_420_SP, i dati in byte[] passati a onPreviewFrame(). In altre parole, NV21 DEVE essere il valore predefinito.
• [C-0-3] DEVE supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia per le fotocamere anteriori che posteriori per android.hardware.Camera. 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 nuovo 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] DEVE garantire 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 con la 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).

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 nell'interfaccia utente popup o popup 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 i dati e lo scambio di ruoli di alimentazione quando supportano USB Type-C e la 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 lo Storage Access Framework (SAF), 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 dei dispositivi 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 indicati 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] È MOLTO CONSIGLIATO supportare la riproduzione a frequenza quasi ultrasonica come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono uno speaker o una porta di uscita audio, devono:

• [C-2-1] NON DEVE segnalare la funzionalità android.hardware.audio.output.
• [C-2-2] È NECESSARIO implementare le API relative all'output audio almeno come no-op.

Ai fini di questa sezione, una "porta di uscita" è un'interfaccia fisica 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,

• [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 frequenza 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 dei dispositivi 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, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace, e mostrare le estensioni nell'elenco delle estensioni EGL disponibili.
• [C-1-8] DEVE implementare GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures, e mostrare le estensioni nell'elenco delle estensioni GL disponibili.
• [C-SR-1] È FORTEMENTE CONSIGLIATO implementare GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, e mostrare le estensioni nell'elenco delle estensioni GL disponibili.
• [C-SR-2] Sono FORTEMENTE CONSIGLIATI per supportare Vulkan 1.1.
• [C-SR-3] È FORTEMENTE CONSIGLIATO implementare VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, e esporli nell'elenco delle estensioni Vulkan disponibili.
• [C-SR-4] È FORTEMENTE CONSIGLIATO esporre almeno una famiglia di code Vulkan in cui flags contenga sia VK_QUEUE_GRAPHICS_BIT che VK_QUEUE_COMPUTE_BIT e queueCount sia almeno 2.
• [C-1-7] La GPU e il display DEVONO essere in grado di sincronizzare l'accesso al buffer front condiviso in modo che il rendering con alternazione dell'occhio dei contenuti VR a 60 fps con due contesti di rendering venga visualizzato senza artefatti di tearing visibili.
• [C-1-9] DEVE implementare il supporto per i flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT come descritto nell'NDK.
• [C-1-10] DEVE implementare il supporto per i AHardwareBuffer con qualsiasi combinazione di flag di utilizzo AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT,AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE,AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT per almeno i seguenti formati:AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM,AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM,AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM,AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] Sono FORTEMENTE CONSIGLIATI per supportare l'allocazione di AHardwareBuffer con più livelli e flag e formati specificati in C-1-10.
• [C-1-11] DEVE supportare la decodifica H.264 di almeno 3840 x 2160 a 30 fps, compressa a una media di 40 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps - 10 Mbps o 2 istanze di 1920 x 1080 a 60 fps - 20 Mbps).
• [C-1-12] DEVE supportare HEVC e VP9, DEVE essere in grado di decodificare almeno 1920 x 1080 a 30 fps compressi a una media di 10 Mbps e DEVE essere in grado di decodificare 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps-5 Mbps).
• [C-1-13] DEVE supportare l'API HardwarePropertiesManager.getDeviceTemperatures e restituire valori accurati per la temperatura cutanea.
• [C-1-14] DEVE avere uno schermo integrato e la sua risoluzione DEVE essere di almeno 1920 x 1080.
• [C-SR-6] È FORTEMENTE CONSIGLIATO avere una risoluzione del display di almeno 2560 x 1440.
• [C-1-15] Il display DEVE aggiornarsi ad almeno 60 Hz in modalità VR.
• [C-1-17] Il display DEVE supportare una modalità a bassa persistenza con una persistenza inferiore a 5 millisecondi, dove persistenza viene definita come il periodo di tempo per il quale un pixel emette luce.
• [C-1-18] DEVE supportare Bluetooth 4.2 e l'estensione della lunghezza dei dati Bluetooth LE sezione 7.4.3.
• [C-1-19] DEVE supportare e segnalare correttamente Tipo di canale diretto per tutti i seguenti tipi di sensori predefiniti:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] È FORTEMENTE CONSIGLIATO supportare il TYPE_HARDWARE_BUFFER tipo di canale diretto per tutti i tipi di canale diretto elencati sopra.
• [C-1-21] DEVE soddisfare i requisiti relativi a giroscopio, accelerometro e magnetometro per android.hardware.hifi_sensors, come specificato nella sezione 7.3.9.
• [C-SR-8] Sono FORTEMENTE CONSIGLIATI per supportare la funzionalitàandroid.hardware.sensor.hifi_sensors.
• [C-1-22] DEVE avere una latenza end-to-end del movimento al fotone non superiore a 28 millisecondi.
• [C-SR-9] È FORTEMENTE CONSIGLIATO di avere una latenza end-to-end dal movimento al fotone non superiore a 20 millisecondi.
• [C-1-23] DEVE avere un rapporto primo fotogramma, ovvero il rapporto tra la luminosità dei pixel del primo fotogramma dopo una transizione dal nero al bianco e la luminosità dei pixel bianchi in stato stazionario, di almeno l'85%.
• [C-SR-10] È FORTEMENTE CONSIGLIATO avere un rapporto del primo frame di almeno il 90%.
• PUO' fornire un core esclusivo all'applicazione in primo piano e PUO' supportare l'API Process.getExclusiveCores per restituire i numeri dei core della CPU esclusivi dell'applicazione in primo piano principale.

Se il core esclusivo è supportato, il core:

• [C-2-1] NON deve consentire l'esecuzione di altri processi nello spazio utente (tranne i driver di dispositivo utilizzati dall'applicazione), ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

7.10. Tecnologia aptica

7.11. Classe di rendimento dei media

La classe di rendimento dei media dell'implementazione del dispositivo può essere ottenuta dall'API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. I requisiti per la classe di rendimento dei contenuti multimediali sono definiti per ogni versione di Android a partire da R (versione 30). Il valore speciale 0 indica che il dispositivo non appartiene a una classe di prestazioni media.

Se le implementazioni del dispositivo restituiscono un valore diverso da zero per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, devono:

• [C-1-1] DEVE restituire almeno un valore pari a android.os.Build.VERSION_CODES.R.

• [C-1-2] DEVE essere un'implementazione di un dispositivo portatile.

• [C-1-3] DEVE soddisfare tutti i requisiti per la "Classe di rendimento dei contenuti multimediali" descritti nella sezione 2.2.7.

In altre parole, la classe di rendimento dei contenuti multimediali in Android T è definita solo per i dispositivi palmari con versione T, S o R.

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

8. Prestazioni e potenza

Alcuni criteri minimi di prestazioni e potenza sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di riferimento che gli sviluppatori devono fare durante lo sviluppo di un'app.

8.1. Coerenza dell'esperienza utente

È possibile fornire all'utente finale un'interfaccia utente fluida se sono presenti determinati requisiti minimi per garantire una frequenza frame e tempi di risposta coerenti per applicazioni e giochi. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POSSONO avere requisiti misurabili per la latenza dell'interfaccia utente e il cambio di attività come descritto nella sezione 2.

8.2. Prestazioni di accesso I/O file

Fornire una linea di base comune per un rendimento coerente dell'accesso ai file nell'archiviazione dei dati privati dell'applicazione (partizione /data) consente agli sviluppatori di app di impostare un'aspettativa adeguata che possa essere utile per il design del software. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POTREBBERO avere determinati requisiti descritti nella sezione 2 per le seguenti operazioni di lettura e scrittura:

• Prestazioni di scrittura sequenziale. Misurata scrivendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
• Rendimento delle scritture casuali. Misurato scrivendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.
• Rendimento di lettura sequenziale. Misurato leggendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
• Rendimento della lettura casuale. Misurato leggendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.

8.3. Modalità di risparmio energetico

Se le implementazioni del dispositivo includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo incluse in AOSP (ad es. App Standby Bucket, Doze) o estendono le funzionalità per applicare limitazioni più stringenti rispetto al bucket App Standby CON RESTRIZIONI, devono:

• [C-1-1] NON DEVE discostarsi dall'implementazione di AOSP per l'attivazione, la manutenzione, gli algoritmi di risveglio e l'utilizzo delle impostazioni di sistema globali o di DeviceConfig delle modalità di risparmio energetico App Standby e Sospensione.
• [C-1-2] NON DEVE discostarsi dall'implementazione di AOSP per l'utilizzo di impostazioni globali o DeviceConfig per gestire la limitazione di job, sveglie e rete per le app in ogni bucket per il standby delle app.
• [C-1-3] NON DEVE discostarsi dall'implementazione AOSP per il numero di bucket App Standby utilizzati per App Standby.
• [C-1-4] È NECESSARIO implementare i bucket di app in standby e la modalità Sospensione come descritto in Gestione dell'alimentazione.
• [C-1-5] DEVE restituire true per PowerManager.isPowerSaveMode() quando il dispositivo è in modalità di risparmio energetico.
• [C-1-6] DEVE fornire all'utente la possibilità di visualizzare tutte le app esenti dalle modalità di risparmio energetico App Standby e Sospensione o da eventuali ottimizzazioni della batteria e DEVE implementare l'intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS per chiedere all'utente di consentire a un'app di ignorare le ottimizzazioni della batteria.
• [C-SR-1] È MOLTO CONSIGLIATO fornire all'utente la possibilità di attivare e disattivare la funzionalità di risparmio energetico.
• [C-SR-2] È FORTEMENTE CONSIGLIATO fornire all'utente la possibilità di visualizzare tutte le app esenti dalle modalità di risparmio energetico App Standby e Sospensione.

Se le implementazioni del dispositivo estendono le funzionalità di gestione dell'alimentazione incluse in AOSP e questa estensione applica restrizioni più stringenti rispetto al bucket Rare App Standby, consulta la sezione 3.5.1.

Oltre alle modalità di risparmio energetico, le implementazioni dei dispositivi Android POSSONO implementare uno o tutti e quattro gli stati di alimentazione in sospensione come definiti dall'Advanced Configuration and Power Interface (ACPI).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S4 come definiti dall'ACPI, devono:

• [C-1-1] DEVE entrare in questo stato solo dopo che l'utente ha intrapreso un'azione esplicita per mettere il dispositivo in uno stato non attivo (ad es. chiudendo un coperchio che fa parte fisicamente del dispositivo o spegnendo un veicolo o una TV) e prima che l'utente riattivi il dispositivo (ad es. aprendo il coperchio o riaccendendo il veicolo o la TV).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S3 come definiti dall'ACPI, devono:

• [C-2-1] DEVE soddisfare C-1-1 sopra indicato oppure DEVE entrare nello stato S3 solo quando le applicazioni di terze parti non richiedono le risorse di sistema (ad es. lo schermo, la CPU).

  Al contrario, DEVE uscire dallo stato S3 quando le applicazioni di terze parti hanno bisogno delle risorse di sistema, come descritto in questo SDK.

  Ad esempio, mentre le applicazioni di terze parti richiedono di mantenere attivo lo schermo tramite FLAG_KEEP_SCREEN_ON o di mantenere in esecuzione la CPU tramite PARTIAL_WAKE_LOCK, il dispositivo NON DEVE entrare nello stato S3, a meno che, come descritto in C-1-1, l'utente non abbia intrapreso un'azione esplicita per mettere il dispositivo in uno stato di inattività. Al contrario, quando viene attivata un'attività implementata dalle app di terze parti tramite JobScheduler o quando Firebase Cloud Messaging viene inviato alle app di terze parti, il dispositivo DEVE uscire dallo stato S3, a meno che l'utente non lo abbia messo in uno stato inattivo. Questi non sono esempi esaustivi e AOSP implementa indicatori di risveglio estesi che attivano un risveglio da questo stato.

8.4. Contabilità del consumo energetico

Una contabilità e una generazione di report più accurati del consumo di energia forniscono allo sviluppatore di app sia gli incentivi sia gli strumenti per ottimizzare il pattern di utilizzo di energia dell'applicazione.

Implementazioni dei dispositivi:

• [C-SR-1] È FORTEMENTE CONSIGLIATO 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.
• [C-SR-2] È FORTEMENTE CONSIGLIATO di segnalare tutti i valori di consumo di energia in milliampere ore (mAh).
• [C-SR-3] È FORTEMENTE CONSIGLIATO segnalare il consumo di energia della CPU per l'UID di ogni processo. Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
• [C-SR-4] VIVAMENTE CONSIGLIATO di rendere disponibile questo utilizzo di energia tramite il comando shell adb shell dumpsys batterystats allo sviluppatore dell'app.
• DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.

8.5. Prestazioni costanti

Le prestazioni possono variare notevolmente per le app ad alte prestazioni a lungo termine, in base alle altre app in esecuzione in background o al throttling della CPU a causa di limiti di temperatura. Android include interfacce programmatiche in modo che, se il dispositivo è compatibile, l'applicazione in primo piano più importante possa richiedere al sistema di ottimizzare l'allocazione delle risorse per gestire queste fluttuazioni.

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare con precisione il supporto della modalità di prestazioni sostenibili tramite il metodo dell'API PowerManager.isSustainedPerformanceModeSupported().

• DOVREBBE supportare la modalità Rendimento prolungato.

Se le implementazioni dei dispositivi segnalano il supporto della modalità di prestazioni sostenute:

• [C-1-1] DEVE fornire all'applicazione in primo piano un livello costante di prestazioni per almeno 30 minuti, quando l'app lo richiede.
• [C-1-2] DEVE rispettare l'API Window.setSustainedPerformanceMode() e altre API correlate.

Se le implementazioni dei dispositivi includono due o più core della CPU, devono:

• DEVE fornire almeno un core esclusivo che può essere riservato dall'applicazione in primo piano.

Se le implementazioni dei dispositivi supportano la prenotazione di un core esclusivo per l'applicazione in primo piano, devono:

• [C-2-1] DEVE segnalare tramite il metodo API Process.getExclusiveCores() i numeri ID dei core esclusivi che possono essere riservati dall'applicazione in primo piano principale.
• [C-2-2] NON DEVE consentire l'esecuzione di processi nello spazio utente, ad eccezione dei driver di dispositivo utilizzati dall'applicazione, sui core esclusivi, ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

Se le implementazioni dei dispositivi non supportano un core esclusivo:

• [C-3-1] DEVE restituire un elenco vuoto tramite il metodo API Process.getExclusiveCores().

9. Compatibilità del modello di sicurezza

Implementazioni dei dispositivi:

• [C-0-1] DEVE implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API della documentazione per sviluppatori Android.

• [C-0-2] DEVE supportare l'installazione di applicazioni con firma autografata senza richiedere autorizzazioni/certificati aggiuntivi da parte di terze parti/autorità.

Se le implementazioni del dispositivo dichiarano la funzionalità android.hardware.security.model.compatible, devono:

• [C-1-1] DEVE supportare i requisiti elencati nelle seguenti sottosezioni.

9.1. Autorizzazioni

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare il modello di autorizzazioni Android e il modello di ruoli Android come definito nella documentazione per gli sviluppatori Android. Nello specifico, devono applicare ogni autorizzazione e ruolo definito come descritto nella documentazione dell'SDK. Nessuna autorizzazione e nessun ruolo può essere omesso, modificato o ignorato.

• PUO' aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe ID autorizzazione non siano nello spazio dei nomi android.\*.

• [C-0-2] Le autorizzazioni con un valore protectionLevel di PROTECTION_FLAG_PRIVILEGED DEVONO essere concesse solo alle app preinstallate nei percorsi privilegiati dell'immagine di sistema (nonché ai file APEX) ed essere all'interno del sottoinsieme delle autorizzazioni esplicitamente consentite per ogni app. L'implementazione AOSP soddisfa questo requisito leggendo e rispettando le autorizzazioni consentite per ogni app dai file nel percorso etc/permissions/ e utilizzando il percorso system/priv-app come percorso privilegiato.

Le autorizzazioni con un livello di protezione pericoloso sono autorizzazioni di runtime. Le applicazioni con targetSdkVersion > 22 le richiedono in fase di esecuzione.

Implementazioni dei dispositivi:

• [C-0-3] DEVE mostrare un'interfaccia dedicata che consenta all'utente di decidere se concedere le autorizzazioni di runtime richieste e fornire un'interfaccia per gestire le autorizzazioni di runtime.

• [C-0-5] NON DEVE concedere autorizzazioni di runtime alle app, a meno che:

  • Vengono installati al momento della spedizione del dispositivo E

  • Il consenso dell'utente può essere ottenuto prima che l'applicazione utilizzi l'autorizzazione.

    O

  • Le autorizzazioni di runtime vengono concesse dal criterio di concessione delle autorizzazioni predefinite o per l'assegnazione di un ruolo della piattaforma.

• [C-0-6] È NECESSARIO concedere l'autorizzazione android.permission.RECOVER_KEYSTORE solo alle app di sistema che registrano un agente di recupero protetto correttamente. Un Agente di ripristino protetto correttamente è definito come un agente software on-device che si sincronizza con uno spazio di archiviazione remoto off-device, dotato di hardware sicuro con una protezione equivalente o superiore a quella descritta nel servizio Google Cloud Key Vault per impedire attacchi brute-force al fattore di conoscenza della schermata di blocco.

Implementazioni dei dispositivi:

• [C-0-7] DEVE rispettare le proprietà dell'autorizzazione di accesso alla posizione di Android quando un'app richiede i dati sulla posizione o sull'attività fisica tramite l'API Android standard o un meccanismo proprietario. Questi dati includono, a titolo esemplificativo:

  • Posizione del dispositivo (ad es. latitudine e longitudine) come descritto nella sezione 9.8.8.
  • Informazioni che possono essere utilizzate per determinare o stimare la posizione del dispositivo (ad es. SSID, BSSID, ID cella o posizione della rete a cui è connesso il dispositivo).
  • Attività fisica dell'utente o classificazione dell'attività fisica.

Nello specifico, le implementazioni dei dispositivi:

• [C-0-8] DEVE ottenere il consenso dell'utente per consentire a un'app di accedere ai dati sulla posizione o sull'attività fisica.
• [C-0-9] DEVE concedere un'autorizzazione di runtime SOLO all'app che detiene un'autorizzazione sufficiente, come descritto nell'SDK. Ad esempio, TelephonyManager#getServiceState richiede android.permission.ACCESS_FINE_LOCATION).

Le uniche eccezioni alle proprietà dell'autorizzazione di accesso alla posizione di Android riportate sopra riguardano le app che non accedono alla posizione per dedurre o identificare la posizione dell'utente; nello specifico:

• Quando le app dispongono dell'autorizzazione RADIO_SCAN_WITHOUT_LOCATION.
• Per la configurazione e la configurazione del dispositivo, quando le app di sistema dispongono dell'autorizzazione NETWORK_SETTINGS o NETWORK_SETUP_WIZARD.

Le autorizzazioni possono essere contrassegnate come limitate, modificandone il comportamento.

• [C-0-10] Le autorizzazioni contrassegnate con il flag hardRestricted NON DEVONO essere concesse a un'app, a meno che:

  • Un file APK dell'app si trova nella partizione di sistema.
  • L'utente assegna a un'app un ruolo associato alle autorizzazioni hardRestricted.
  • Il programma di installazione concede il hardRestricted a un'app.
  • A un'app viene concesso il hardRestricted su una versione precedente di Android.

• [C-0-11] Le app che detengono un'autorizzazione softRestricted DEVONO ottenere solo accesso limitato e NON DEVONO ottenere accesso completo finché non vengono inserite nella lista consentita come descritto nell'SDK, dove l'accesso completo e limitato è definito per ogni autorizzazione softRestricted (ad esempio READ_EXTERNAL_STORAGE).

• [C-0-12] NON DEVE fornire API o funzioni personalizzate per aggirare le limitazioni delle autorizzazioni definite nelle API setPermissionPolicy e setPermissionGrantState.

• [C-0-13] DEVE utilizzare le API AppOpsManager per registrare e monitorare ogni singolo accesso programmatico ai dati protetti da autorizzazioni pericolose da attività e servizi Android.

• [C-0-14] È NECESSARIO assegnare i ruoli solo alle applicazioni con funzionalità chesoddisfano i requisiti dei ruoli.

• [C-0-15] NON DEVE definire ruoli duplicati o con funzionalità superiori ai ruoli definiti dalla piattaforma.

Se i dispositivi riportano android.software.managed_users:

• [C-1-1] NON DEVONO essere concesse automaticamente dall'amministratore le seguenti autorizzazioni:
  • Posizione (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Fotocamera (CAMERA)
  • Microfono (RECORD_AUDIO)
  • Sensore del corpo (BODY_SENSORS)
  • Attività fisica (ACTIVITY_RECOGNITION)

Se le implementazioni del dispositivo offrono all'utente la possibilità di scegliere quali app possono eseguire il disegno sopra altre app con un'attività che gestisce lo scopo ACTION_MANAGE_OVERLAY_PERMISSION, devono:

• [C-2-1] DEVI assicurarti che tutte le attività con filtri di intent per l'intent ACTION_MANAGE_OVERLAY_PERMISSION abbiano la stessa schermata dell'interfaccia utente, indipendentemente dall'app di lancio o dalle informazioni che fornisce.

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

• [C-3-1] È OBBLIGATORIO mostrare un disclaimer durante la configurazione del dispositivo completamente gestito (configurazione del proprietario del dispositivo) che indichi che l'amministratore IT avrà la possibilità di consentire alle app di controllare le impostazioni dello smartphone, inclusi microfono, fotocamera e posizione, con opzioni per consentire all'utente di continuare la configurazione o uscirne, A MENO CHE l' amministratore non abbia disattivato il controllo delle autorizzazioni sul dispositivo.

Se le implementazioni del dispositivo preinstallano pacchetti che contengono i ruoli System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence o System Visual Intelligence, i pacchetti:

• [C-4-1] DEVE soddisfare tutti i requisiti descritti per le implementazioni dei dispositivi nelle sezioni "9.8.6 Acquisizione di contenuti" "9.8.6 Dati a livello di sistema operativo e ambientali e 9.8.15 Implementazioni di API in sandbox".

9.2. Isolamento UID e dei processi

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare il modello di sandbox per le applicazioni Android, in cui ogni applicazione viene eseguita come UID di tipo Unix univoco e in un processo separato.
• [C-0-2] DEVE supportare l'esecuzione di più applicazioni come lo stesso ID utente Linux, a condizione che le applicazioni siano firmate e costruite correttamente, come definito nel documento di riferimento Sicurezza e autorizzazioni.

9.3. Autorizzazioni del file system

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare il modello di autorizzazioni di accesso ai file di Android come definito nella documentazione di riferimento su sicurezza e autorizzazioni.

9.4. Ambienti di esecuzione alternativi

Le implementazioni dei dispositivi DEVONO mantenere la coerenza del modello di sicurezza e delle autorizzazioni di Android, anche se includono ambienti di runtime che eseguono applicazioni utilizzando software o tecnologie diversi dal formato eseguibile Dalvik o dal codice nativo. In altre parole:

• [C-0-1] I runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella sezione 9.

• [C-0-2] Ai runtime alternativi NON DEVE essere concesso l'accesso alle risorse protette da autorizzazioni non richieste nel file AndroidManifest.xml del runtime tramite il meccanismo <uses-permission>.

• [C-0-3] I runtime alternativi NON DEVONO consentire alle applicazioni di utilizzare funzionalità protette dalle autorizzazioni Android limitate alle applicazioni di sistema.

• [C-0-4] I runtime alternativi DEVONO rispettare il modello di sandbox di Android e le applicazioni installate che utilizzano un runtime alternativo NON DEVONO riutilizzare la sandbox di qualsiasi altra app installata sul dispositivo, tranne tramite i meccanismi standard di Android per ID utente e certificato di firma condivisi.

• [C-0-5] I runtime alternativi NON DEVONO essere avviati con, concedere o essere concessi accesso alle sandbox corrispondenti ad altre applicazioni Android.

• [C-0-6] I runtime alternativi NON DEVONO essere avviati con, essere concessi o concedere ad altre applicazioni i privilegi del superutente (root) o di qualsiasi altro ID utente.

• [C-0-7] Quando i file .apk dei runtime alternativi sono inclusi nell'immagine di sistema delle implementazioni del dispositivo, DEVONO essere firmati con una chiave diversa da quella utilizzata per firmare altre applicazioni incluse nelle implementazioni del dispositivo.

• [C-0-8] Durante l'installazione delle applicazioni, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione.

• [C-0-9] Quando un'applicazione deve utilizzare una risorsa del dispositivo per la quale è presente un'autorizzazione Android corrispondente (ad esempio Fotocamera, GPS e così via), il runtime alternativo DEVE informare l'utente che l'applicazione potrà accedere a quella risorsa.

• [C-0-10] Quando l'ambiente di runtime non registra le funzionalità dell'applicazione in questo modo, l'ambiente di runtime DEVE elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che lo utilizza.

• I runtime alternativi DOVREBBERO installare le app tramite PackageManager in sandbox Android separate (ID utente Linux e così via).

• I runtime alternativi POSSONO fornire una singola sandbox Android condivisa da tutte le applicazioni che li utilizzano.

9.5. Supporto di più utenti

Android include il supporto per più utenti e fornisce il supporto per l'isolamento completo degli utenti e la clonazione dei profili utente con isolamento parziale(ad es. un singolo profilo utente aggiuntivo di tipo android.os.usertype.profile.CLONE).

• Le implementazioni dei dispositivi POSSONO, ma NON DEVONO, attivare il multiutente se utilizzano supporti rimovibili per lo spazio di archiviazione esterno principale.

Se le implementazioni dei dispositivi includono il supporto di più utenti:

• [C-1-2] DEVE, per ogni utente, implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API.
• [C-1-3] DEVE avere directory di archiviazione delle applicazioni condivise separate e isolate (chiamate anche /sdcard) per ogni istanza utente.
• [C-1-4] DEVE garantire che le applicazioni di proprietà di un determinato utente e in esecuzione per suo conto non possano elencare, leggere o scrivere nei file di proprietà di altri utenti, anche se i dati di entrambi gli utenti sono archiviati nello stesso volume o file system.
• [C-1-5] DEVE criptare i contenuti della scheda SD quando è attivato il multiutente utilizzando una chiave memorizzata solo su supporti non rimovibili accessibili solo al sistema se le implementazioni del dispositivo utilizzano supporti rimovibili per le API di archiviazione esterna. Poiché ciò renderà i contenuti multimediali illeggibili da un PC host, le implementazioni dei dispositivi dovranno passare a MTP o a un sistema simile per fornire ai PC host l'accesso ai dati dell'utente corrente.

Se le implementazioni dei dispositivi includono il supporto di più utenti, per tutti gli utenti, ad eccezione di quelli creati appositamente per l'esecuzione di due istanze della stessa app, si applicano le seguenti limitazioni:

• [C-2-1] DEVE avere directory di archiviazione delle applicazioni condivise separate e isolate (ovvero /sdcard) per ogni istanza utente.
• [C-2-2] DEVE garantire che le applicazioni di proprietà di un determinato utente e in esecuzione per suo conto non possano elencare, leggere o scrivere nei file di proprietà di qualsiasi altro utente, anche se i dati di entrambi gli utenti sono archiviati nello stesso volume o file system.

Le implementazioni del dispositivo POSSONO creare un singolo profilo utente aggiuntivo di tipo android.os.usertype.profile.CLONE per l'utente principale (e solo per l'utente principale) allo scopo di eseguire due istanze della stessa app. Queste due istanze condividono uno spazio di archiviazione parzialmente isolato, vengono presentate all' utente finale contemporaneamente nel programma di avvio e compaiono nella stessa visualizzazione App recenti. Ad esempio, questo potrebbe essere utilizzato per consentire all'utente di installare due istanze distinte di una singola app su un dispositivo dual SIM.

Se le implementazioni dei dispositivi creano il profilo utente aggiuntivo discusso sopra:

• [C-3-1] DEVE fornire l'accesso solo allo spazio di archiviazione o ai dati già accessibili al profilo utente principale o di proprietà diretta di questo profilo utente aggiuntivo.
• [C-3-2] NON deve avere questo come profilo di lavoro.
• [C-3-3] DEVE avere directory dei dati delle app private isolate dall'account dell'utente principale.
• [C-3-4] NON DEVE consentire la creazione del profilo utente aggiuntivo se è stato eseguito il provisioning di un proprietario dispositivo (vedi sezione 3.9.1) o consentire l'esecuzione del provisioning di un proprietario dispositivo senza prima rimuovere il profilo utente aggiuntivo.

9.6. Avviso SMS premium

Android include il supporto per avvisare gli utenti di qualsiasi messaggio SMS premium in uscita. Gli SMS premium sono messaggi inviati a un servizio registrato presso un operatore che potrebbe comportare un addebito per l'utente.

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

• [C-1-1] DEVE avvisare gli utenti prima di inviare un messaggio SMS ai numeri identificati dalle espressioni regolari definite nel file /data/misc/sms/codes.xml sul dispositivo. L'Android Open Source Project upstream fornisce un'implementazione che soddisfa questo requisito.

9.7. Funzionalità per la sicurezza

Le implementazioni dei dispositivi DEVONO garantire la conformità alle funzionalità di sicurezza sia nel kernel sia nella piattaforma, come descritto di seguito.

La sandbox di Android include funzionalità che utilizzano il sistema di controllo dell'accesso obbligatorio (MAC) di Security-Enhanced Linux (SELinux), il sandboxing seccomp e altre funzionalità di sicurezza nel kernel di Linux. Implementazioni dei dispositivi:

• [C-0-1] DEVE mantenere la compatibilità con le applicazioni esistenti, anche quando SELinux o altre funzionalità di sicurezza sono implementate sotto il framework Android.
• [C-0-2] NON DEVE avere un'interfaccia utente visibile quando viene rilevata una violazione di sicurezza e bloccata correttamente dalla funzionalità di sicurezza implementata sotto il framework Android, ma PUÒ avere un'interfaccia utente visibile quando si verifica una violazione di sicurezza non bloccata che ha generato uno exploit riuscito.
• [C-0-3] NON DEVE consentire all'utente o allo sviluppatore di app di configurare SELinux o altre funzionalità di sicurezza implementate sotto il framework Android.
• [C-0-4] NON DEVE consentire a un'applicazione che può influire su un'altra tramite un'API (ad esempio un'API di amministrazione del dispositivo) di configurare un criterio che violi la compatibilità.
• [C-0-5] È OBBLIGATORIO suddividere il framework multimediale in più processi in modo da poter concedere l'accesso in modo più specifico per ogni processo, come descritto sul sito del progetto Android Open Source.
• [C-0-6] DEVE implementare un meccanismo di sandboxing delle applicazioni del kernel che consenta di filtrare le chiamate di sistema utilizzando un criterio configurabile da programmi multithread. L'Android Open Source Project upstream soddisfa questo requisito attivando seccomp-BPF con la sincronizzazione del gruppo di thread (TSYNC) come descritto nella sezione Configurazione del kernel di source.android.com.

Le funzionalità di integrità e autoprotezione del kernel sono parte integrante della sicurezza di Android. Implementazioni dei dispositivi:

• [C-0-7] DEVE implementare meccanismi di protezione da overflow del buffer dello stack del kernel. Esempi di questi meccanismi sono CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] È OBBLIGATORIO implementare protezioni rigorose della memoria del kernel in cui il codice eseguibile è di sola lettura, i dati di sola lettura non sono eseguibili e non sono scrivibili e i dati scrivibili non sono eseguibili (ad es. CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] DEVE implementare il controllo dei limiti di dimensione degli oggetti statici e dinamici delle copie tra spazio utente e spazio kernel (ad es. CONFIG_HARDENED_USERCOPY) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
• [C-0-10] NON DEVE eseguire la memoria dello spazio utente durante l'esecuzione in modalità kernel (ad es. PXN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi inizialmente forniti con il livello API 28 o versioni successive.
• [C-0-11] NON DEVE leggere o scrivere memoria nello spazio utente nel kernel al di fuori delle normali API di accesso usercopy (ad es. PAN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
• [C-0-12] È OBBLIGATORIO implementare l'isolamento della tabella delle pagine del kernel se l'hardware è vulnerabile a CVE-2017-5754 su tutti i dispositivi originariamente forniti con il livello API 28 o versioni successive (ad es. CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0).

• [C-0-13] È OBBLIGATORIO implementare il rafforzamento della previsione delle ramificazioni se l'hardware è vulnerabile a CVE-2017-5715 su tutti i dispositivi originariamente forniti con il livello API 28 o versioni successive (ad es. CONFIG_HARDEN_BRANCH_PREDICTOR).

• [C-SR-1] È FORTEMENTE CONSIGLIATO mantenere i dati del kernel scritti solo durante l'inizializzazione contrassegnati come di sola lettura dopo l'inizializzazione (ad es. __ro_after_init).

• [C-SR-2] È FORTEMENTE CONSIGLIATO di randomizzare il layout del codice e della memoria del kernel ed evitare esposizioni che potrebbero compromettere la randomizzazione (ad es. CONFIG_RANDOMIZE_BASE con l'entropia del bootloader tramite /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).

• [C-SR-3] È FORTEMENTE CONSIGLIATO di attivare l'integrità del flusso di controllo (CFI) nel kernel per fornire una protezione aggiuntiva contro gli attacchi di riutilizzo del codice (ad es. CONFIG_CFI_CLANG e CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] È FORTEMENTE CONSIGLIATO di non disattivare l'integrità del flusso di controllo (CFI), la pila di chiamate shadow (SCS) o la convalida degli overflow di interi (IntSan) sui componenti su cui sono attivati.

• [C-SR-5] È FORTEMENTE CONSIGLIATO di attivare CFI, SCS e IntSan per eventuali componenti aggiuntivi dello spazio utente sensibili alla sicurezza, come spiegato in CFI e IntSan.

• [C-SR-6] È FORTEMENTE CONSIGLIATO abilitare l'inizializzazione dello stack nel kernel per impedire l'utilizzo di variabili locali non inizializzate (CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO). Inoltre, le implementazioni del dispositivo NON DEVONO assumere il valore utilizzato dal compilatore per inizializzare le variabili locali.

• [C-SR-7] È FORTEMENTE CONSIGLIATO di attivare l'inizializzazione dell'heap nel kernel per impedire l'utilizzo di allocazioni dell'heap non inizializzate (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) e NON DEVONO assumere il valore utilizzato dal kernel per inizializzare queste allocazioni.

Se le implementazioni dei dispositivi utilizzano un kernel Linux in grado di supportare SELinux, devono:

• [C-1-1] È NECESSARIO implementare SELinux.
• [C-1-2] È NECESSARIO impostare SELinux sulla modalità di applicazione globale.
• [C-1-3] È NECESSARIO configurare tutti i domini in modalità di applicazione. Non sono consentiti i domini in modalità permissiva, inclusi i domini specifici per un dispositivo/fornitore.
• [C-1-4] NON DEVE modificare, omettere o sostituire le regole neverallow presenti nella cartella system/sepolicy fornita nell'Android Open Source Project (AOSP) upstream e il criterio DEVE compilare con tutte le regole neverallow presenti, sia per i domini SELinux AOSP sia per i domini specifici del dispositivo/del fornitore.
• [C-1-5] È OBBLIGATORIO eseguire applicazioni di terze parti che hanno come target il livello API 28 o versioni successive in sandbox SELinux per applicazione con limitazioni SELinux per app nella directory dei dati privati di ogni applicazione.
• DOVREBBE mantenere il criterio SELinux predefinito fornito nella cartella system/sepolicy del progetto Android Open Source upstream e aggiungere solo ulteriori elementi a questo criterio per la propria configurazione specifica del dispositivo.

Se le implementazioni dei dispositivi utilizzano un kernel diverso da Linux o Linux senza SELinux,

• [C-2-1] È NECESSARIO utilizzare un sistema di controllo degli accessi obbligatori equivalente a SELinux.

Se le implementazioni dei dispositivi utilizzano dispositivi I/O in grado di DMA, devono:

• [C-SR-9] È FORTEMENTE CONSIGLIATO di isolare ogni dispositivo I/O in grado di DMA, utilizzando un IOMMU (ad es. l'ARM SMMU).

Android contiene più funzionalità di difesa in profondità che sono parte integrante della sicurezza del dispositivo. Inoltre, Android si concentra sulla riduzione delle classi principali di bug comuni che contribuiscono a una scarsa qualità e sicurezza.

Per ridurre i bug di memoria, le implementazioni dei dispositivi:

• [C-SR-10] È FORTEMENTE CONSIGLIATO di testare gli errori di memoria nello spazio utente utilizzando strumenti di rilevamento come MTE per i dispositivi ARMv9, HWASan per i dispositivi ARMv8+ o ASan per altri tipi di dispositivi.
• [C-SR-11] È FORTEMENTE CONSIGLIATO testare queste funzionalità utilizzando strumenti di rilevamento degli errori di memoria del kernel come KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS per i dispositivi ARMv9, CONFIG_KASAN_SW_TAGS per i dispositivi ARMv8 o CONFIG_KASAN_GENERIC per altri tipi di dispositivi).
• [C-SR-12] È FORTEMENTE CONSIGLIATO di utilizzare strumenti di rilevamento degli errori di memoria in produzione come MTE, GWP-ASan e KFENCE.

Se le implementazioni dei dispositivi utilizzano un TEE basato su Arm TrustZone, devono:

• [C-SR-13] È FORTEMENTE CONSIGLIATO di utilizzare un protocollo standard per la condivisione della memoria tra Android e il TEE, come Arm Firmware Framework per Armv8-A (FF-A).
• [C-SR-14] È FORTEMENTE CONSIGLIATO limitare le applicazioni attendibili all'accesso solo alla memoria che è stata condivisa esplicitamente con loro tramite il protocollo riportato sopra. Se il dispositivo supporta il livello di eccezione Arm S-EL2, questo deve essere applicato dal gestore delle partizioni sicure. In caso contrario, dovrebbe essere applicato dal sistema operativo TEE.

9.8. Privacy

9.8.1. Cronologia utilizzo

Android memorizza la cronologia delle scelte dell'utente e la gestisce tramite UsageStatsManager.

Implementazioni dei dispositivi:

• [C-0-1] DEVE mantenere un periodo di conservazione ragionevole di questa cronologia utente.
• [C-SR-1] È FORTEMENTE CONSIGLIATO di mantenere il periodo di conservazione di 14 giorni come configurato per impostazione predefinita nell'implementazione AOSP.

Android memorizza gli eventi di sistema utilizzando gli identificatori StatsLog e gestisce questa cronologia tramite le API System StatsManager e IncidentManager.

Implementazioni dei dispositivi:

• [C-0-2] È obbligatorio includere solo i campi contrassegnati con DEST_AUTOMATIC nel report sugli incidenti creato dalla classe dell'API di sistema IncidentManager.
• [C-0-3] NON devi utilizzare gli identificatori di eventi di sistema per registrare altri eventi diversi da quelli descritti nella documentazione dell'SDK StatsLog. Se vengono registrati altri eventi di sistema, POTREBBERO utilizzare un identificatore di atomi diverso nell'intervallo compreso tra 100.000 e 200.000.

9.8.2. Registrazione in corso…

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE precaricare o distribuire componenti software out-of-box che inviano le informazioni private dell'utente (ad es. sequenze di tasti, testo visualizzato sullo schermo, report di bug) dal dispositivo senza il consenso dell'utente o cancellare le notifiche in corso.
• [C-0-2] DEVE mostrare un avviso all'utente e ottenere il consenso esplicito dell'utente per consentire la cattura di qualsiasi informazione sensibile visualizzata sullo schermo dell'utenteabilitato che include esattamente lo stesso messaggio di AOSP ogni volta ogni volta che viene avviata una sessione per acquisire la trasmissione o la registrazione dello schermo abilitata tramite MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay(), o API proprietarie. NON DEVE fornire agli utenti un'affordance per disattivare la visualizzazione futura del consenso dell'utente.
• [C-0-3] DEVE essere presente una notifica continua per l'utente mentre la trasmissione o la registrazione dello schermo sono attive. AOSP soddisfa questo requisito mostrando un'icona di notifica in corso nella barra di stato.

Se le implementazioni del dispositivo includono funzionalità nel sistema che acquisiscono i contenuti visualizzati sullo schermo e/o registrano lo stream audio riprodotto sul dispositivo in modo diverso dall'API System ContentCaptureService o tramite altri mezzi proprietari descritti nella Sezione 9.8.6 Dati a livello di sistema e ambientali, devono:

• [C-1-1] DEVE essere inviata una notifica continua all'utente ogni volta che questa funzionalità è attivata e acquisisce/registra attivamente.

Se le implementazioni dei dispositivi includono un componente abilitato out-of-the-box, in grado di registrare l'audio ambientale e/o l'audio riprodotto sul dispositivo per dedurre informazioni utili sul contesto dell'utente, devono:

• [C-2-1] NON DEVE memorizzare nello spazio di archiviazione permanente sul dispositivo o trasmettere al di fuori del dispositivo l'audio non elaborato registrato o qualsiasi formato che possa essere ricondotto all'audio originale o a una copia quasi esatta, tranne con il consenso esplicito dell'utente.

Un "indicatore del microfono" si riferisce a una visualizzazione sullo schermo, costantemente visibile all'utente e che non può essere oscurata, che gli utenti comprendono come indicante che il microfono è in uso(tramite testo, colore, icona o una combinazione di questi elementi).

Un "indicatore della fotocamera" si riferisce a una visualizzazione sullo schermo, costantemente visibile all'utente e che non può essere oscurata, che gli utenti comprendono come indicazione che una fotocamera è in uso (tramite testo, colore, icona o una combinazione di questi elementi).

Dopo il primo secondo visualizzato, un indicatore può cambiare visivamente, ad esempio diventare più piccolo, e non è necessario che venga visualizzato come presentato e compreso inizialmente.

L'indicatore del microfono può essere unito a un indicatore della videocamera visualizzato attivamente, a condizione che testo, icone o colori indichino all'utente che è iniziato l'utilizzo del microfono.

L'indicatore della videocamera può essere unito a un indicatore del microfono visualizzato attivamente, a condizione che testo, icone o colori indichino all'utente che l'uso della videocamera è iniziato.

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

• [C-SR-1] È MOLTO CONSIGLIATO mostrare l'indicatore del microfono quando un'app accede ai dati audio del microfono, ma non quando il microfono è accessibile solo da HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o dalle app che detengono i ruoli indicati nella sezione 9.1 Autorizzazioni con identificatore CDD [C-3-X]. .
• [C-SR-2] È FORTEMENTE CONSIGLIATO di visualizzare l'elenco delle app recenti e attive che utilizzano il microfono restituito daPermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.
• [C-SR-3] È FORTEMENTE CONSIGLIATO di non nascondere l'indicatore del microfono per le app di sistema con interfacce utente visibili o interazione diretta con l'utente.

Se le implementazioni del dispositivo dichiarano android.hardware.camera.any:

• [C-SR-4] È MOLTO CONSIGLIATO mostrare l'indicatore della videocamera quando un'app accede ai dati della videocamera in tempo reale, ma non quando la videocamera viene usata solo dalle app che detengono i ruoli indicati nella Sezione 9.1 Autorizzazioni con identificatore CDD [C-3-X].
• [C-SR-5] È FORTEMENTE CONSIGLIATO mostrare le app recenti e attive che utilizzano la fotocamera come restituito da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.
• [C-SR-6] È FORTEMENTE CONSIGLIATO di non nascondere l'indicatore della fotocamera per le app di sistema con interfacce utente visibili o interazione diretta con l'utente.

9.8.3. Connettività

Se le implementazioni dei dispositivi dispongono di una porta USB con supporto della modalità periferica USB,

• [C-1-1] DEVE presentare un'interfaccia utente che richieda il consenso dell'utente prima di consentire l'accesso ai contenuti dello spazio di archiviazione condiviso tramite la porta USB.

9.8.4. Traffico di rete

Implementazioni dei dispositivi:

• [C-0-1] DEVE preinstallare gli stessi certificati radice per l'archivio delle autorità di certificazione (CA) attendibili di sistema come fornito nel progetto Android Open Source upstream.
• [C-0-2] DEVE essere fornito con un magazzino CA radice utente vuoto.
• [C-0-3] DEVE mostrare un avviso all'utente che indica che il traffico di rete potrebbe essere monitorato quando viene aggiunta una CA radice utente.

Se il traffico del dispositivo viene instradato tramite una VPN, le implementazioni del dispositivo:

• [C-1-1] DEVE mostrare un avviso all'utente che indica:
  • Il traffico di rete potrebbe essere monitorato.
  • Il traffico di rete viene instradato tramite l'applicazione VPN specifica che fornisce la VPN.

Se le implementazioni dei dispositivi dispongono di un meccanismo, abilitato per impostazione predefinita, che indirizza il traffico di dati di rete tramite un server proxy o un gateway VPN (ad esempio, precaricando un servizio VPN con android.permission.CONTROL_VPN concesso), devono:

• [C-2-1] DEVE chiedere il consenso dell'utente prima di attivare il meccanismo, a meno che la VPN non sia attivata dal Device Policy Controller tramite DevicePolicyManager.setAlwaysOnVpnPackage() , nel qual caso l'utente non deve fornire un consenso separato, ma deve solo essere informato.

Se le implementazioni dei dispositivi implementano un'affordance utente per attivare/disattivare la funzione "VPN sempre attiva" di un'app VPN di terze parti, devono:

• [C-3-1] È OBBLIGATORIO disattivare questa funzionalità per gli utenti per le app che non supportano il servizio VPN sempre attivo nel file AndroidManifest.xml impostando l'attributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON su false.

9.8.5. Identificatori dei dispositivi

Implementazioni dei dispositivi:

• [C-0-1] DEVE impedire l'accesso al numero di serie del dispositivo e, ove applicabile, all'IMEI/MEID, al numero di serie della SIM e all'IMSI (International Mobile Subscriber Identity) da un'app, a meno che non soddisfi uno dei seguenti requisiti:
  • è un'app dell'operatore firmata e verificata dai produttori di dispositivi.
  • è stata concessa l'autorizzazione READ_PRIVILEGED_PHONE_STATE.
  • Ha i privilegi dell'operatore come definito in Privilegi dell'operatore UICC.
  • è un proprietario del dispositivo o del profilo a cui è stata concessa l'autorizzazioneREAD_PHONE_STATE.
  • (Solo per numero di serie della SIM/ICCID) è previsto dal requisito delle normative locali che l'app rilevi le modifiche all'identità dell'abbonato.

9.8.6. Acquisizione di contenuti e ricerca di appDati a livello di sistema operativo e ambientali

Android, tramite le API di sistema ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query o tramite altri metodi di proprietà, supporta un meccanismo per le implementazioni dei dispositivi per acquisire le seguenti interazioni dei dati delle applicazioni tra le applicazioni e l'utente dati sensibili:

• Testo e immagini visualizzati sullo schermo, inclusi, a titolo esemplificativo, notifiche e dati di assistenza tramite l'API AssistStructure.
• Dati multimediali, ad esempio audio o video, registrati o riprodotti dal dispositivo.
• Eventi di input (ad es. tasti, mouse, gesti, voce, video e accessibilità).

• Qualsiasi testo o altro dato inviato tramite TextClassifier API al servizio System TextClassifier, ovvero al servizio di sistema per comprendere il significato del testo, nonché per generare azioni successive previste in base al testo.
• Dati indicizzati dall'implementazione della piattaforma AppSearch, inclusi, a titolo esemplificativo, testo, grafica, dati multimediali o altri dati simili.

Se le implementazioni dei dispositivi acquisiscono uno dei dati sopra indicati:

• [C-1-1] DEVE criptare tutti questi dati quando vengono archiviati nel dispositivo. Questa crittografia PUÒ essere eseguita utilizzando la crittografia basata su file di Android o qualsiasi degli algoritmi di crittografia elencati come API versione 26 e successive descritti nell'SDK Cipher.
• [C-1-2] NON DEVE eseguire il backup dei dati non elaborati o criptati utilizzando metodi di backup di Android o altri metodi di backup.
• [C-1-3] DEVE inviare solo tutti questi dati e il log dal dispositivo utilizzando un meccanismo che tutela la privacy, tranne con il consenso esplicito dell'utente ogni volta che i dati vengono condivisi. Il meccanismo di tutela della privacy viene definito come "quelli che consentono solo l'analisi aggregata e impediscono la corrispondenza di eventi registrati o risultati derivati ai singoli utenti", per impedire l'introspezione dei dati per utente (ad es. implementati utilizzando una tecnologia di privacy differenziale come RAPPOR).
• [C-1-4] NON DEVE associare questi dati a qualsiasi identità utente (ad esempio Account) sul dispositivo, tranne con il consenso esplicito dell'utente ogni volta che i dati vengono associati.
• [C-1-5] NON DEVE condividere questi dati con altri componenti del sistema operativo che non seguono i requisiti descritti nella sezione corrente (9.8.6 Acquisizione di contenuti Dati di livello OS e ambientali), tranne con il consenso esplicito dell'utente ogni volta che vengono condivisi. A meno che questa funzionalità non sia stata creata come API SDK per Android (AmbientContext, HotwordDetectionService).
• [C-1-6] DEVE fornire all'utente la possibilità di cancellare i dati raccolti dall'implementazione o dai mezzi proprietari di ContentCaptureService se quando i dati sono archiviati in qualsiasi forma sul dispositivo. Se l'utente sceglie di cancellare i dati, DEVE rimuovere tutti i dati storici raccolti.
• [C-1-7] DEVE fornire all'utente la possibilità di disattivare la visualizzazione dei dati raccolti tramite AppSearch o mezzi proprietari nella piattaforma Android, ad esempio nel launcher.
• [C-SR-1] È FORTEMENTE CONSIGLIATO di NON richiedere l'autorizzazione INTERNET.
• [C-SR-2] È FORTEMENTE CONSIGLIATO di accedere a internet solo tramite API strutturate supportate da implementazioni open source disponibili pubblicamente.

Se le implementazioni dei dispositivi includono un servizio che implementa l'API SystemContentCaptureService, AppSearchManager.index o qualsiasi servizio proprietario che acquisisce i dati come descritto sopra, devono:

• [C-2-1] NON DEVE consentire agli utenti di sostituire i servizi con un'applicazione o un servizio installabile dall'utente e DEVE consentire solo ai servizi preinstallati di acquisire questi dati.
• [C-2-2] NON DEVE consentire ad altre app, oltre al meccanismo dei servizi preinstallati, di acquisire questi dati.
• [C-2-3] È OBBLIGATORIO fornire all'utente la possibilità di disattivare i servizi.
• [C-2-4] NON DEVE omettere l'affordance dell'utente per gestire le autorizzazioni Android detenute dai servizi e seguire il modello di autorizzazioni Android come descritto nella sezione 9.1. Autorizzazione.

• [C-SR-3] È FORTEMENTE CONSIGLIATO di mantenere i servizi separati da altri componenti di sistema(ad es. non associare il servizio o condividere gli ID processo), tranne che per quanto segue:

  • Telefonia, Contatti, Interfaccia utente di sistema e contenuti multimediali

9.8.7. Accesso agli appunti

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE restituire dati ritagliati dagli appunti (ad es. tramite l'API ClipboardManager ) a meno che l'app di terze parti non sia l'IME predefinito o l'app attualmente attiva.

• [C-0-2] DEVE cancellare i dati della clipboard al massimo 60 minuti dopo l'ultima volta che sono stati inseriti o letti da una clipboard.

9.8.8. Posizione

La posizione include le informazioni nella classe Android Location( ad esempio Latitudine, Longitudine, Altitudine), nonché gli identificatori che possono essere convertiti in posizione. La posizione può essere precisa come il DGPS (Differential Global Positioning System) o approssimativa come le posizioni a livello di paese (ad esempio la posizione del codice paese - MCC - Mobile Country Code).

Di seguito è riportato un elenco di tipi di località che derivano direttamente dalla posizione di un utente o che possono essere convertiti in una posizione dell'utente. Non si tratta di un elenco esaustivo, ma deve essere utilizzato come esempio di ciò da cui la posizione può essere ricavata direttamente o indirettamente:

• GPS/GNSS/DGPS/PPP
  • Soluzione di posizionamento globale o Sistema di navigazione satellitare globale o Soluzione di posizionamento globale differenziale
  • Sono incluse anche le misurazioni GNSS non elaborate e lo stato GNSS.
    • La posizione esatta può essere ricavata dalle misurazioni GNSS non elaborate
• Tecnologie wireless con identificatori univoci, ad esempio:
  • Punti di accesso Wi-Fi (MAC, BSSID, nome o SSID)
  • Bluetooth/BLE (MAC, BSSID, nome o SSID)
  • UWB (MAC, BSSID, nome o SSID)
  • ID torre di telefonia mobile (3G, 4G, 5G e tutte le future tecnologie di modem cellulare con identificatori univoci)

Come punto di riferimento principale, consulta le API Android che richiedono le autorizzazioni ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION.

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE attivare/disattivare l'impostazione di geolocalizzazione del dispositivo e le impostazioni di scansione Wi-Fi/Bluetooth senza il consenso esplicito dell'utente o l'avvio da parte dell'utente.
• [C-0-2] È OBBLIGATORIO fornire all'utente la possibilità di accedere alle informazioni relative alla posizione, tra cui richieste di accesso alla posizione recenti, autorizzazioni a livello di app e utilizzo della ricerca Wi-Fi/Bluetooth per determinare la posizione.
• [C-0-3] DEVE garantire che l'applicazione che utilizza l'API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] sia una sessione di emergenza avviata dall'utente (ad es. chiamare il 112 o inviare un messaggio al 112). Tuttavia, per i veicoli, un veicolo PUÒ avviare una sessione di emergenza senza interazione attiva dell'utente nel caso in cui venga rilevato un incidente (ad es. per soddisfare i requisiti di eCall).
• [C-0-4] È NECESSARIO preservare la capacità dell'API Emergency Location Bypass diaggirare le impostazioni di geolocalizzazione del dispositivo senza modificarle.
• [C-0-5] DEVE pianificare una notifica che ricordi all'utente che un'app in background ha avuto accesso alla sua posizione utilizzando l'autorizzazione [ACCESS_BACKGROUND_LOCATION].

9.8.9. App installate

Per impostazione predefinita, le app per Android che hanno come target il livello API 30 o versioni successive non possono vedere i dettagli di altre app installate (consulta la sezione Visibilità dei pacchetti nella documentazione dell'SDK Android).

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE esporre a qualsiasi app che ha come target il livello API 30 o versioni successive dettagli su qualsiasi altra app installata, a meno che l'app non sia già in grado di visualizzare i dettagli sull'altra app installata tramite le API gestite. Sono inclusi, a titolo esemplificativo, i dettagli esposti da eventuali API personalizzate aggiunte dall'implementatore del dispositivo o accessibili tramite il file system.
• [C-0-2] NON DEVE concedere a nessuna app l'accesso in lettura o scrittura ai file nella directory dedicata e specifica per l'app di un'altra app all'interno dello spazio di archiviazione esterno. Le uniche eccezioni sono le seguenti:
  • L'autorità del provider di archiviazione esterno (ad es. app come DocumentsUI).
  • Download Provider, che utilizza l'autorità del provider "download" per scaricare file nello spazio di archiviazione dell'app.
  • App MTP (Media Transfer Protocol) firmate dalla piattaforma che utilizzano l'autorizzazione privilegiata ACCESS_MTP per consentire il trasferimento di file su un altro dispositivo.
  • Le app che installano altre app e dispongono dell'autorizzazione INSTALL_PACKAGES possono accedere solo alle directory "obb" a scopo di gestione file di espansione APK.

9.8.10. Segnalazione di bug relativi alla connettività

Se le implementazioni del dispositivo dichiarano il flag della funzionalità android.hardware.telephony,

• [C-1-1] DEVE supportare la generazione di segnalazioni di bug relativi alla connettività tramite BUGREPORT_MODE_TELEPHONY con BugreportManager.
• [C-1-2] DEVE ottenere il consenso dell'utente ogni volta che BUGREPORT_MODE_TELEPHONY viene utilizzato per generare un report e NON DEVE chiedere all'utente di acconsentire a tutte le richieste future dell'applicazione.
• [C-1-3] NON DEVE restituire il report generato all'app richiedente senza il consenso esplicito dell'utente.
• [C-1-4] I report generati utilizzando BUGREPORT_MODE_TELEPHONY DEVONO contenere almeno le seguenti informazioni:
  • TelephonyDebugService dump
  • TelephonyRegistry dump
  • WifiService dump
  • ConnectivityService dump
  • Un dump dell'istanza CarrierService del pacchetto chiamante (se associata)
  • Buffer dei log del segnale radio
  • SubscriptionManagerService dump
• [C-1-5] NON DEVE includere quanto segue nei report generati:
  • Qualsiasi tipo di informazione non direttamente correlata al debugging della connettività.
  • Qualsiasi tipo di log del traffico delle applicazioni installate dall'utente o profili dettagliati delle applicazioni/dei pacchetti installati dall'utente (gli UID sono accettabili, i nomi dei pacchetti no).
• POTREBBE includere informazioni aggiuntive non associate all'identità di alcun utente. (ad es. log del fornitore).

Se le implementazioni dei dispositivi includono informazioni aggiuntive (ad es. log del fornitore) nelle segnalazioni di bug e queste informazioni hanno un impatto sulla privacy/sicurezza/batteria/spazio di archiviazione/memoria,

• [C-SR-1] È FORTEMENTE CONSIGLIATO impostare un'impostazione per gli sviluppatori su disabilitata per impostazione predefinita. L'implementazione di riferimento AOSP soddisfa questo requisito fornendo l'opzione Enable verbose vendor logging nelle impostazioni per sviluppatori per includere log aggiuntivi del fornitore specifici del dispositivo nelle segnalazioni di bug.

9.8.11. Condivisione di blob di dati

Android, tramite BlobStoreManager, consente alle app di contribuire con blob di dati al sistema per la condivisione con un insieme selezionato di app.

Se le implementazioni dei dispositivi supportano i BLOB di dati condivisi come descritto nella documentazione dell'SDK, questi:

• [C-1-1] NON DEVE condividere blob di dati appartenenti ad app oltre a quanto previsto (ovvero l'ambito dell'accesso predefinito e le altre modalità di accesso che possono essere specificate utilizzando BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() o BlobStoreManager.session#allowPublicAccess() NON DEVE essere modificato). L'implementazione di riferimento AOSP soddisfa questi requisiti.
• [C-1-2] NON DEVE inviare dal dispositivo o condividere con altre app gli hash sicuri delle blob di dati (che vengono utilizzati per controllare l'accesso).

9.8.12. Riconoscimento della musica

Android, tramite l'API di sistema MusicRecognitionManager, supporta un meccanismo per le implementazioni dei dispositivi per richiedere il riconoscimento musicale, dato un record audio, e delegare il riconoscimento musicale a un'app privilegiata che implementa l'API MusicRecognitionService.

Se le implementazioni del dispositivo includono un servizio che implementa l'API di sistema MusicRecognitionManager o qualsiasi servizio proprietario che trasmette in streaming i dati audio come descritto sopra, devono:

• [C-1-1] DEVE verificare che il chiamante di MusicRecognitionManager disponga dell'autorizzazione MANAGE_MUSIC_RECOGNITION
• [C-1-2] È OBBLIGATORIO applicare una singola applicazione di riconoscimento musicale preinstallata che implementi MusicRecognitionService.
• [C-1-3] NON DEVE consentire agli utenti di sostituire MusicRecognitionManagerService o MusicRecognitionService con un'applicazione o un servizio installabile dall'utente.
• [C-1-4] DEVE assicurarsi che quando MusicRecognitionManagerService accede al registro audio e lo inoltra all'applicazione che implementa MusicRecognitionService, l'accesso all'audio venga monitorato tramite le invocazioni di AppOpsManager.noteOp / startOp.

Se le implementazioni di MusicRecognitionManagerService o MusicRecognitionService sul dispositivo memorizzano i dati audio acquisiti:

• [C-2-1] NON DEVE memorizzare audio non elaborato o impronte audio su disco o in memoria per più di 14 giorni.
• [C-2-2] NON DEVE condividere questi dati al di fuori di MusicRecognitionService, tranne con il consenso esplicito dell'utente ogni volta che vengono condivisi.

9.8.13. SensorPrivacyManager

Se le implementazioni del dispositivo forniscono all'utente un'affordance software per disattivare l'input della fotocamera e/o del microfono per l'implementazione del dispositivo, devono:

• [C-1-1] DEVE restituire con precisione "true" per il metodo API pertinente supportsSensorToggle().
• [C-1-2] DEVE, quando un'app tenta di accedere a un microfono o una fotocamera bloccati, presentare all'utente un'affordance non ignorabile che indica chiaramente che il sensore è bloccato e richiede una scelta per continuare a bloccare o sbloccare in base all'implementazione AOSP che soddisfa questo requisito.
• [C-1-3] DEVE trasmettere alle app solo dati audio e video vuoti (o falsi) e non deve segnalare un codice di errore dovuto al fatto che l'utente non ha attivato la videocamera o il microfono tramite l'affordance dell'utente presentata in [C-1-2] sopra.

9.9. Crittografia dell'archiviazione dei dati

Tutti i dispositivi DEVONO soddisfare i requisiti della sezione 9.9.1. I dispositivi lanciati con un livello API precedente a quello di questo documento sono esenti dai requisiti delle sezioni 9.9.2 e 9.9.3; devono invece soddisfare i requisiti della sezione 9.9 del documento Android Compatibility Definition corrispondente al livello API su cui è stato lanciato il dispositivo.

9.9.1. Avvio diretto

Implementazioni dei dispositivi:

• [C-0-1] DEVE implementare le API della modalità di avvio diretto anche se non supportano la crittografia dello spazio di archiviazione.

• [C-0-2] Gli intent ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED DEVONO essere comunque trasmessi per segnalare alle applicazioni compatibili con il Boot diretto che le posizioni di archiviazione con crittografia del dispositivo (DE) e con crittografia delle credenziali (CE) sono disponibili per l'utente.

9.9.2. Requisiti di crittografia

Implementazioni dei dispositivi:

• [C-0-1] DEVE criptare i dati privati dell'applicazione (partizione /data) e la partizione dello spazio di archiviazione condiviso dell'applicazione (partizione /data) se si tratta di una parte permanente e non rimovibile del dispositivo./sdcard
• [C-0-2] DEVE attivare la crittografia dello spazio di archiviazione dei dati per impostazione predefinita al momento in cui l'utente ha completato l'esperienza di configurazione iniziale.

• [C-0-3] DEVE soddisfare il requisito di crittografia di archiviazione dei dati riportato sopra implementando uno dei seguenti due metodi di crittografia:

  • Crittografia basata su file (FBE) e Crittografia dei metadati come descritto nella sezione 9.9.3.1.
  • Crittografia a livello di blocco per utente come descritto nella sezione 9.9.3.2.

9.9.3. Metodi di crittografia

Se le implementazioni dei dispositivi sono criptate:

• [C-1-1] DEVE avviarsi senza richiedere all'utente le credenziali e consentire alle app compatibili con il Boot diretto di accedere allo spazio di archiviazione criptato del dispositivo (DE) dopo l'invio del messaggio ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] DEVE consentire l'accesso allo spazio di archiviazione con crittografia delle credenziali (CE) solo dopo che l'utente ha sbloccato il dispositivo fornendo le proprie credenziali (ad es. passcode, PIN, sequenza o impronta) e il messaggio ACTION_USER_UNLOCKED è stato trasmesso.
• [C-1-13] NON DEVE offrire alcun metodo per sbloccare lo spazio di archiviazione protetto CE senza le credenziali fornite dall'utente, una chiave escrow registrata o un'implementazione del ripristino all'avvio che soddisfi i requisiti della sezione 9.9.4.
• [C-1-4] DEVE utilizzare l'Avvio verificato.

9.9.3.1. Crittografia basata su file con crittografia dei metadati

Se le implementazioni dei dispositivi utilizzano la crittografia basata su file con la crittografia dei metadati:

• [C-1-5] È NECESSARIO criptare i contenuti dei file e i metadati del file system utilizzando AES-256-XTS o Adiantum. AES-256-XTS si riferisce all'Advanced Encryption Standard con una lunghezza della chiave di crittografia di 256 bit, operata in modalità XTS; la lunghezza completa della chiave è di 512 bit. Adiantum si riferisce ad Adiantum-XChaCha12-AES, come specificato all'indirizzo https://github.com/google/adiantum. I metadati del file system sono dati come dimensioni, proprietà, modalità e attributi estesi (xattr) dei file.
• [C-1-6] DEVE criptare i nomi dei file utilizzando AES-256-CBC-CTS, AES-256-HCTR2 o Adiantum.
• [C-1-12] Se il dispositivo dispone di istruzioni Advanced Encryption Standard (AES) (ad esempio le estensioni di crittografia ARMv8 su dispositivi basati su ARM o AES-NI su dispositivi basati su x86), è OBBLIGATORIO utilizzare le opzioni basate su AES riportate sopra per la crittografia del nome file, dei contenuti del file e dei metadati del file system, non Adiantum.
• [C-1-13] DEVE essere utilizzata una funzione di derivazione delle chiavi con crittografia avanzata e non reversibile (ad es. HKDF-SHA512) per ricavare le eventuali sottochiavi necessarie (ad es. le chiavi per file) dalle chiavi CE e DE. "Molto sicura dal punto di vista della crittografia e non reversibile" significa che la funzione di derivazione della chiave ha un'efficacia di sicurezza di almeno 256 bit e si comporta come una famiglia di funzioni pseudocasuali sui suoi input.
• [C-1-14] NON DEVE utilizzare le stesse chiavi o sottochiavi di crittografia basata su file (FBE) per scopi crittografici diversi (ad es. sia per la crittografia sia per la derivazione delle chiavi o per due diversi algoritmi di crittografia).
• [C-1-15] DEVE garantire che tutti i blocchi non eliminati dei contenuti dei file criptati sullo spazio di archiviazione permanente siano stati criptati utilizzando combinazioni di chiave di crittografia e vettore di inizializzazione (IV) che dipendono sia dal file sia dall'offset all'interno del file. Inoltre, tutte queste combinazioni DEVONO essere distinte, tranne nel caso in cui la crittografia venga eseguita utilizzando hardware di crittografia in linea che supporta solo una lunghezza IV di 32 bit.
• [C-1-16] DEVE essere garantito che tutti i nomi file criptati non eliminati nello spazio di archiviazione permanente in directory distinte siano stati criptati utilizzando combinazioni distinte di chiave di crittografia e vettore di inizializzazione (IV).

• [C-1-17] DEVE garantire che tutti i blocchi di metadati del filesystem criptati nello stoccaggio persistente siano stati criptati utilizzando combinazioni distinte di chiave di crittografia e vettore di inizializzazione (IV).

• Chiavi che proteggono le aree di archiviazione CE e DE e i metadati del file system:

  • [C-1-7] DEVE essere associato in modo crittografico a un Keystore basato su hardware. Questo keystore DEVE essere associato all'Avvio verificato e all'elemento di attendibilità di primo livello hardware del dispositivo.
  • [C-1-8] Le chiavi CE DEVONO essere associate alle credenziali della schermata di blocco di un utente.
  • [C-1-9] Le chiavi CE DEVONO essere associate a un passcode predefinito se l'utente non ha specificato le credenziali della schermata di blocco.
  • [C-1-10] DEVE essere univoco e distinto, in altre parole nessuna chiave CE o DE di un utente deve corrispondere a quella di un altro utente.
  • [C-1-11] È OBBLIGATORIO utilizzare le modalità, le lunghezze delle chiavi e le cifre supportate obbligatoriamente.
  • [C-1-12] DEVE essere cancellato in modo sicuro durante lo sblocco e il blocco del bootloader come descritto qui.

• DOVREBBE rendere le app essenziali preinstallate (ad es. Sveglia, Telefono, Messenger) aware di Direct Boot.

Il progetto Android Open Source upstream fornisce un'implementazione preferita della crittografia basata su file in base alla funzionalità di crittografia "fscrypt" del kernel Linux e della crittografia dei metadati in base alla funzionalità "dm-default-key" del kernel Linux.

9.9.3.2. Crittografia a livello di blocco per utente

Se le implementazioni dei dispositivi utilizzano la crittografia a livello di blocco per utente, queste:

• [C-1-1] DEVE essere attivato il supporto multiutente come descritto nella sezione 9.5.
• [C-1-2] DEVE fornire partizioni per utente, utilizzando partizioni non formattate o volumi logici.
• [C-1-3] È OBBLIGATORIO utilizzare chiavi di crittografia univoche e distinte per utente per la crittografia dei dispositivi di blocco sottostanti.

• [C-1-4] È OBBLIGATORIO utilizzare AES-256-XTS per la crittografia a livello di blocco delle partizioni dell'utente.

• Le chiavi che proteggono i dispositivi criptati a livello di blocco per utente:

  • [C-1-5] DEVE essere vincolato in modo crittografico a un Keystore basato su hardware. Questo keystore DEVE essere associato all'Avvio verificato e all'elemento di attendibilità di primo livello hardware del dispositivo.
  • [C-1-6] DEVE essere associato alle credenziali della schermata di blocco dell'utente corrispondente.

La crittografia a livello di blocco per utente può essere implementata utilizzando la funzionalità "dm-crypt" del kernel Linux sulle partizioni per utente.

9.9.4. Riprendi al riavvio

La funzionalità Riprendi dopo il riavvio consente di sbloccare lo spazio di archiviazione CE di tutte le app, anche quelle che non supportano ancora il riavvio diretto, dopo un riavvio avviato da un aggiornamento OTA. Questa funzionalità consente agli utenti di ricevere notifiche dalle app installate dopo il riavvio.

Un'implementazione della funzionalità Riavvia da ibernazione deve continuare a garantire che, quando un dispositivo finisce nelle mani di un malintenzionato, sia estremamente difficile per quest'ultimo recuperare i dati criptati con crittografia lato client dell'utente, anche se il dispositivo è acceso, lo spazio di archiviazione lato client è sbloccato e l'utente ha sbloccato il dispositivo dopo aver ricevuto un aggiornamento OTA. Per la resistenza agli attacchi di tipo insider, supponiamo inoltre che l'utente malintenzionato ottenga l'accesso alle chiavi di firma crittografiche di trasmissione.

Nello specifico:

• [C-0-1] Lo spazio di archiviazione CE NON DEVE essere leggibile nemmeno per l'utente malintenzionato che ha il dispositivo e dispone di queste funzionalità e limitazioni:

  • Può utilizzare la chiave di firma di qualsiasi fornitore o azienda per firmare messaggi arbitrari.
  • Può causare la ricezione di un aggiornamento OTA da parte del dispositivo.
  • Può modificare il funzionamento di qualsiasi hardware (AP, flash e così via), tranne come indicato di seguito, ma questa modifica comporta un ritardo di almeno un'ora e un ciclo di alimentazione che distrugge i contenuti della RAM.
  • Non è possibile modificare il funzionamento dell'hardware a prova di manomissione (ad es. Titan M).
  • Impossibile leggere la RAM del dispositivo in tempo reale.
  • Non è possibile ottenere le credenziali dell'utente (PIN, sequenza, password) o indurre in altro modo l'utente a inserirle.

A titolo esemplificativo, un'implementazione di un dispositivo che implementa e rispetta tutte le descrizioni riportate qui sarà conforme a [C-0-1].

9.10. Integrità del dispositivo

I seguenti requisiti garantiscono la trasparenza dello stato dell'integrità del dispositivo. Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare correttamente tramite il metodo dell'API di sistema PersistentDataBlockManager.getFlashLockState() se lo stato del bootloader consente il flashing dell'immagine di sistema.

• [C-0-2] DEVE supportare l'Avvio verificato per l'integrità del dispositivo.

Se le implementazioni dei dispositivi sono già state lanciate senza supportare Avvio verificato su una versione precedente di Android e non è possibile aggiungere il supporto di questa funzionalità con un aggiornamento del software di sistema, queste POTREBBERO essere esenti dal requisito.

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

• [C-1-1] È OBBLIGATORIO dichiarare il flag della funzionalità della piattaformaandroid.software.verified_boot.
• [C-1-2] È NECESSARIO eseguire la verifica a ogni sequenza di avvio.
• [C-1-3] È NECESSARIO avviare la verifica da una chiave hardware immutabile che sia la radice della attendibilità e arrivare fino alla partizione di sistema.
• [C-1-4] DEVE implementare ogni fase di verifica per controllare l'integrità e l'autenticità di tutti i byte nella fase successiva prima di eseguire il codice nella fase successiva.
• [C-1-5] È NECESSARIO utilizzare algoritmi di verifica altrettanto efficaci quanto le raccomandazioni attuali del NIST per gli algoritmi di hashing (SHA-256) e le dimensioni delle chiavi pubbliche (RSA-2048).
• [C-1-6] NON DEVE consentire il completamento dell'avvio quando la verifica del sistema non va a buon fine, a meno che l'utente non accetti di tentare comunque l'avvio, nel qual caso i dati di qualsiasi blocco di archiviazione non verificato NON DEVONO essere utilizzati.
• [C-1-7] NON DEVE consentire la modifica delle partizioni verificate sul dispositivo a meno che l'utente non abbia sbloccato esplicitamente il bootloader.
• [C-SR-1] Se il dispositivo contiene più chip distinti (ad es. radio, processore di immagini specializzato), è MOLTO CONSIGLIATO verificare ogni fase del processo di avvio di ciascun chip al momento dell'avvio.
• [C-1-8] È NECESSARIO utilizzare uno spazio di archiviazione con dispositivo antimanomissione per memorizzare se il bootloader è sbloccato. Lo spazio di archiviazione con rilevamento di manomissione indica che il bootloader può rilevare se lo spazio di archiviazione è stato manomesso dall'interno di Android.
• [C-1-9] DEVE richiedere all'utente, durante l'utilizzo del dispositivo, di confermare fisicamente prima di consentire la transizione dalla modalità bootloader bloccato alla modalità bootloader sbloccato.
• [C-1-10] DEVE implementare la protezione del rollback per le partizioni utilizzate da Android (ad es. avvio, partizioni di sistema) e utilizzare uno spazio di archiviazione con protezione antimanomissione per memorizzare i metadati utilizzati per determinare la versione minima del sistema operativo consentita.
• [C-1-11] È NECESSARIO cancellare in modo sicuro tutti i dati utente durante lo sblocco e il blocco del bootloader, come da "9.12". "Eliminazione dati" (inclusa la partizione userdata e eventuali spazi NVRAM).
• [C-SR-2] È FORTEMENTE CONSIGLIATO verificare tutti i file APK delle app con privilegi con una catena di attendibilità basata su partizioni protette da Verified Boot.
• [C-SR-3] È FORTEMENTE CONSIGLIATO di verificare gli elementi eseguibili caricati da un'app privilegiata dall'esterno del file APK (ad esempio codice caricato dinamicamente o codice compilato) prima di eseguirli o FORTEMENTE CONSIGLIATO di non eseguirli affatto.
• DEVE implementare la protezione del rollback per qualsiasi componente con firmware permanente (ad es. modem, videocamera) e DEVE utilizzare lo spazio di archiviazione con rilevamento di manomissione per memorizzare i metadati utilizzati per determinare la versione minima consentita.

Se le implementazioni dei dispositivi sono già state lanciate senza supportare C-1-8 e C-1-11 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.

L'Android Open Source Project upstream fornisce un'implementazione preferita di questa funzionalità nel repository external/avb/, che può essere integrata nel bootloader utilizzato per il caricamento di Android.

Implementazioni dei dispositivi

Se le implementazioni dei dispositivi hanno la possibilità di verificare i contenuti dei file su base di pagina,

• [C-0-3 C-2-1] supporta la verifica crittografica dei contenuti dei file in base a una chiave attendibile senza leggere l'intero file.

• [C-0-4 C-2-2] NON DEVE consentire il completamento delle richieste di lettura su un file protetto quando i contenuti letti non vengono verificati rispetto a una chiave attendibile non è stata verificata come indicato in [C-2-1] sopra.

Se le implementazioni dei dispositivi sono già state lanciate senza la possibilità di verificare contenuti dei file rispetto a una chiave attendibile su una versione precedente di Android e non possono aggiungere supporto per questa funzionalità con un aggiornamento del software di sistema, potrebbero essere esenti dal requisito. Il progetto Android Open Source upstream fornisce un'implementazione preferita di questa funzionalità in base alla funzionalità fs-verity del kernel Linux.

Implementazioni dei dispositivi:

• [C-SR-4] È MOLTO CONSIGLIATO supportare l'API Android Protected Confirmation.

Se le implementazioni dei dispositivi supportano l'API Android Protected Confirmation, devono:

• [C-3-1] È OBBLIGATORIO segnalare true per l'API ConfirmationPrompt.isSupported().

• [C-3-2] DEVE garantire che il codice in esecuzione nel sistema operativo Android, incluso il suo kernel, dannoso o meno, non possa generare una risposta positiva senza l'interazione dell'utente.

• [C-3-3] DEVE garantire che l'utente sia stato in grado di esaminare e approvare il messaggio visualizzato anche nel caso in cui il sistema operativo Android, incluso il kernel, sia compromesso.

9.11. Chiavi e credenziali

Il sistema Android Keystore consente agli sviluppatori di app di archiviare le chiavi di crittografia in un contenitore e di utilizzarle nelle operazioni di crittografia tramite l'API KeyChain o l'API Keystore. Implementazioni dei dispositivi:

• [C-0-1] DEVE consentire l'importazione o la generazione di almeno 8192 chiavi.
• [C-0-2] L'autenticazione nella schermata di blocco DEVE implementare un intervallo di tempo tra i tentativi non riusciti. Con n come numero di tentativi non riusciti, l'intervallo di tempo DEVE essere di almeno 30 secondi per 9 < n < 30. Per n > 29, il valore dell'intervallo di tempo DEVE essere almeno pari a 30*2^floor((n-30)/10)) secondi o almeno 24 ore, a seconda del valore più piccolo.
• NON deve limitare il numero di chiavi che possono essere generate

Quando l'implementazione del dispositivo supporta una schermata di blocco sicura:

• [C-1-1] È NECESSARIO eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
• [C-1-2] DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA, ECDH (se IKeyMintDevice è supportato), 3DES e HMAC e funzioni di hash di famiglie MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e sopra. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi 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.
• [C-1-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo se l'autenticazione va a buon fine, 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.
• [C-1-4] DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise tra un numero sufficiente di dispositivi per impedire che vengano utilizzate come identificatori di dispositivi. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore 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.

• [C-1-5] DEVE consentire all'utente di scegliere il timeout della modalità Sospensione per la transizione dallo stato sbloccato a quello bloccato, con un timeout minimo consentito fino a 15 secondi. I dispositivi per auto e motori, che bloccano lo schermo ogni volta che la unità principale viene spenta o l'utente cambia, NON POSSONO avere la configurazione del timeout di sospensione.
• [C-1-6] DEVE supportare una delle seguenti opzioni:
  • IKeymasterDevice 3.0,
  • IKeymasterDevice 4.0,
  • IKeymasterDevice 4.1,
  • IKeyMintDevice versione 1 oppure
  • IKeyMintDevice versione 2.
• [C-SR-1] È FORTEMENTE CONSIGLIATO supportare la versione 1 di IKeyMintDevice.

9.11.1. Schermata di blocco, autenticazione e dispositivi virtuali sicuri

L'implementazione AOSP segue un modello di autenticazione a più livelli in cui un'autenticazione principale basata su knowledge-factory può essere supportata da un'autenticazione biometrica secondaria avanzata o da modalità terziarie meno efficaci.

Implementazioni dei dispositivi:

• [C-SR-1] È FORTEMENTE CONSIGLIATO di impostare solo uno dei seguenti come metodo di autenticazione principale:

  • Un PIN numerico
  • Una password alfanumerica

  • Un pattern di scorrimento su una griglia di esattamente 3 x 3 punti

    Tieni presente che i metodi di autenticazione sopra indicati sono indicati come metodi di autenticazione primaria consigliati in questo documento.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione principale consigliati e utilizzano un nuovo metodo di autenticazione come metodo sicuro per bloccare lo schermo, il nuovo metodo di autenticazione:

• [C-2-1] DEVE essere il metodo di autenticazione utente descritto in Requisiti di autenticazione utente per l'utilizzo della chiave.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco se si basano su una chiave segreta nota e utilizzano un nuovo metodo di autenticazione da trattare come un modo sicuro per bloccare lo schermo:

• [C-3-1] L'entropia della lunghezza minima consentita degli input DEVE essere superiore a 10 bit.
• [C-3-2] L'entropia massima di tutti gli input possibili DEVE essere maggiore di 18 bit.
• [C-3-3] Il nuovo metodo di autenticazione NON DEVE sostituire nessuno dei metodi di autenticazione principale consigliati (ad es. PIN, sequenza, password) implementati e forniti in AOSP.
• [C-3-4] Il nuovo metodo di autenticazione DEVE essere disattivato quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio relativo ai requisiti della password tramite DevicePolicyManager.setRequiredPasswordComplexity() con una costante di complessità più restrittiva rispetto a PASSWORD_COMPLEXITY_NONE o tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante più restrittiva rispetto a PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] I nuovi metodi di autenticazione DEVONO ricorrere ai metodi di autenticazione primaria consigliati (ad es. PIN, sequenza, password) una volta ogni 72 ore o meno OPPURE indicare chiaramente all'utente che non verrà eseguito il backup di alcuni dati per preservare la privacy dei suoi dati.

Se le implementazioni dei dispositivi aggiungono o modificano i metodi di autenticazione principale consigliati per sbloccare la schermata di blocco e utilizzano un nuovo metodo di autenticazione basato sulla biometria da trattare come un modo sicuro per bloccare lo schermo, il nuovo metodo:

• [C-4-1] DEVE soddisfare tutti i requisiti descritti nella sezione 7.3.10 per la classe 1 (in precedenza Convenience).
• [C-4-2] DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principale consigliati basati su una chiave segreta nota.
• [C-4-3] DEVE essere disattivato e deve consentire solo l'autenticazione principale consigliata per sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio della funzionalità di protezione con password chiamando il metodo DevicePolicyManager.setKeyguardDisabledFeatures() con uno dei flag biometrici associati (ovvero KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE o KEYGUARD_DISABLE_IRIS).

Se i metodi di autenticazione biometrica non soddisfano i requisiti per la classe 3 (in precedenza Resistente) come descritto nella sezione 7.3.10:

• [C-5-1] I metodi DEVONO essere disattivati se l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità dei requisiti della password tramite DevicePolicyManager.setRequiredPasswordComplexity() con un bucket di complessità più restrittivo rispetto a PASSWORD_COMPLEXITY_LOW o utilizzando il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva rispetto a PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] L'utente DEVE essere sottoposto a verifica per l'autenticazione principale consigliata (ad es. PIN, sequenza, password) come descritto in [C-1-7] e [C-1-8] nella sezione 7.3.10.
• [C-5-3] I metodi NON DEVONO essere considerati come una schermata di blocco sicura e DEVONO soddisfare i requisiti che iniziano con C-8 in questa sezione di seguito.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco e un nuovo metodo di autenticazione si basa su un token fisico o sulla posizione:

• [C-6-1] Devono disporre di un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principale consigliati basato su una chiave segreta nota e soddisfare i requisiti per essere considerati una schermata di blocco sicura.
• [C-6-2] Il nuovo metodo DEVE essere disattivato e deve consentire solo uno dei metodi di autenticazione principale consigliati per sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio con:
  • Il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
  • Il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva rispetto a PASSWORD_QUALITY_NONE.
  • Il metodo DevicePolicyManager.setRequiredPasswordComplexity() con un bucket di complessità più restrittivo rispetto a PASSWORD_COMPLEXITY_NONE.
• [C-6-3] All'utente DEVE essere richiesto uno dei metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) almeno una volta ogni 4 ore. Quando un token fisico soddisfa i requisiti per le implementazioni di TrustAgent in C-X, si applicano invece le limitazioni di timeout definite in C-9-5.
• [C-6-4] Il nuovo metodo NON DEVE essere considerato una schermata di blocco sicura e DEVE seguire le limitazioni elencate in C-8 di seguito.

Se le implementazioni dei dispositivi dispongono di una schermata di blocco sicura e includono uno o più agenti di attendibilità che implementano l'TrustAgentServiceAPI System, devono:

• [C-7-1] DEVE essere presente un'indicazione chiara nel menu delle impostazioni e nella schermata di blocco quando il blocco del dispositivo è differito o può essere sbloccato dagli agenti di attendibilità. Ad esempio, AOSP soddisfa questo requisito mostrando una descrizione del testo per "Imposta blocco automatico" e "Il tasto di accensione blocca immediatamente" nel menu Impostazioni e un'icona distinguibile nella schermata di blocco.
• [C-7-2] DEVE rispettare e implementare completamente tutte le API di agenti di attendibilità nella classe DevicePolicyManager, ad esempio la costante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NON DEVE implementare completamente la funzione TrustAgentService.addEscrowToken() su un dispositivo che viene utilizzato come dispositivo personale principale (ad es. palmare), ma PUÒ implementare completamente la funzione sulle implementazioni del dispositivo che in genere vengono condivise (ad es. Android TV o dispositivo per auto e motori).
• [C-7-4] DEVE criptare tutti i token archiviati aggiunti da TrustAgentService.addEscrowToken().
• [C-7-5] NON DEVE memorizzare la chiave di crittografia o il token escrow sullo stesso dispositivo su cui viene utilizzata la chiave. Ad esempio, è consentito che una chiave memorizzata su uno smartphone sblocchi un account utente su una TV. Per i dispositivi Automotive, non è consentito memorizzare il token escrow su alcuna parte del veicolo.
• [C-7-6] È OBBLIGATORIO informare l'utente sulle implicazioni per la sicurezza prima di attivare il token escrow per decriptare lo spazio di archiviazione dei dati.
• [C-7-7] DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principale consigliati.
• [C-7-8] All'utente DEVE essere richiesta una verifica per uno dei metodi di autenticazione principale consigliati (ad es.PIN, sequenza, password) almeno una volta ogni 72 ore, a meno che non sia in discussione la sicurezza dell'utente (ad es. distrazione del conducente).
• [C-7-9] All'utente DEVE essere richiesta una verifica per uno dei metodi di autenticazione principale consigliati (ad es.PIN, sequenza, password) come descritto in [C-1-7] e [C-1-8] nella sezione 7.3.10, a meno che non sia in discussione la sicurezza dell'utente (ad es. distrazione del conducente).
• [C-7-10] NON DEVE essere trattata come una schermata di blocco sicura e DEVE rispettare i vincoli elencati in C-8 di seguito.
• [C-7-11] NON DEVE consentire a TrustAgent sui dispositivi personali principali (ad es.palmari) di sbloccare il dispositivo e può utilizzarli solo per mantenere un dispositivo già sbloccato in stato sbloccato per un massimo di 4 ore. L'implementazione predefinita di TrustManagerService in AOSP soddisfa questo requisito.
• [C-7-12] È OBBLIGATORIO utilizzare un canale di comunicazione con protezione criptata (ad es.UKEY2) per trasmettere il token di escrow dal dispositivo di archiviazione al dispositivo di destinazione.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco che non è una schermata di blocco sicura come descritto sopra e utilizzano un nuovo metodo di autenticazione per sbloccare la schermata di blocco:

• [C-8-1] Il nuovo metodo DEVE essere disattivato quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva rispetto a PASSWORD_QUALITY_NONE o tramite il metodo DevicePolicyManager.setRequiredPasswordComplexity() con una costante di complessità più restrittiva rispetto a 'PASSWORD_COMPLEXITY_NONE'.
• [C-8-2] NON DEVONO reimpostare i timer di scadenza della password impostati da DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] NON DEVONO esporre un'API da utilizzare da parte di app di terze parti per cambiare lo stato della serratura.

Se le implementazioni dei dispositivi consentono alle applicazioni di creare display virtuali secondari e non supportano gli eventi di input associati, ad esempio tramite VirtualDeviceManager, questi:

• [C-9-1] DEVE bloccare questi display virtuali secondari quando il display predefinito del dispositivo è bloccato e sbloccarli quando il display predefinito del dispositivo è sbloccato.

Se le implementazioni dei dispositivi consentono alle applicazioni di creare display virtuali secondari e supportano gli eventi di input associati, ad esempio tramite VirtualDeviceManager, devono:

• [C-10-1] DEVE supportare stati di blocco separati per dispositivo virtuale
• [C-10-2] È NECESSARIO scollegare tutti i dispositivi virtuali al termine del tempo di attesa di inattività
• [C-10-3] DEVE avere un timeout per inattività
• [C-10-4] DEVE bloccare tutti i display quando l'utente avvia un blocco, anche tramite l'affordance per l'utente per il blocco richiesto per i dispositivi palmari (vedi Sezione 2.2.5[9.11/H-1-2])
• [C-10-5] DEVE avere istanze di dispositivi virtuali separate per utente
• [C-10-6] È NECESSARIO disattivare la creazione di eventi di input associati tramite VirtualDeviceManager se indicato da DevicePolicyManager.setNearbyAppStreamingPolicy
• [C-10-7] DEVI utilizzare una clipboard separata solo per ogni dispositivo virtuale (o disattivare la clipboard per i dispositivi virtuali)
• [C-10-11] È OBBLIGATORIO disattivare l'interfaccia utente di autenticazione sui dispositivi virtuali, inclusa la voce del fattore di conoscenza e la richiesta biometrica
• [C-10-12] È obbligatorio limitare la visualizzazione degli intent avviati da un dispositivo virtuale solo sullo stesso dispositivo virtuale
• [C-10-13] NON deve essere utilizzato uno stato di blocco del dispositivo virtuale come autorizzazione di autenticazione dell'utente con il sistema Android Keystore. Consulta KeyGenParameterSpec.Builder.setUserAuthentication*.

Quando le implementazioni dei dispositivi consentono all'utente di trasferire il fattore di conoscenza dell'autenticazione principale da un dispositivo di origine a un dispositivo di destinazione, ad esempio per la configurazione iniziale del dispositivo di destinazione, devono:

• [C-11-1] È NECESSARIO criptare il fattore di conoscenza con garanzie di protezione simili a quelle descritte nel white paper sulla sicurezza del servizio Google Cloud Key Vault quando si trasferisce il fattore di conoscenza dal dispositivo di origine al dispositivo di destinazione in modo che il fattore di conoscenza non possa essere decriptato da remoto o utilizzato per sbloccare da remoto entrambi i dispositivi.
• [C-11-2] DEVE chiedere all'utente di confermare il factor di conoscenza sul dispositivo di origine prima di trasferirlo al dispositivo di destinazione.
• [C-11-3] SU un dispositivo di destinazione privo di un fattore di conoscenza per l'autenticazione principale impostato, DEVE chiedere all'utente di confermare un fattore di conoscenza trasferito sul dispositivo di destinazione prima di impostarlo come fattore di conoscenza per l'autenticazione principale per il dispositivo di destinazione e prima di rendere disponibili i dati trasferiti da un dispositivo di origine.

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

• [C-12-1] DEVE chiamare grantTrust() con il flag solo quando è connesso a un dispositivo fisico nelle vicinanze con una schermata di blocco propria e quando l'utente ha autenticato la propria identità in base a quella schermata di blocco. I dispositivi nelle vicinanze possono usare meccanismi di rilevamento sul polso o sul corpo dopo uno sblocco dell'utente una tantum per soddisfare il requisito di autenticazione dell'utente.
• [C-12-2] DEVE impostare l'implementazione del dispositivo nello stato TrustState.TRUSTABLE quando lo schermo è spento (ad esempio tramite la pressione di un pulsante o il tempo di attesa del display) e TrustAgent non ha revocato la fiducia. AOSP soddisfa questo requisito.
• [C-12-3] È NECESSARIO spostare il dispositivo dallo stato TrustState.TRUSTABLE allo stato TrustState.TRUSTED solo se TrustAgent continua a concedere l'attendibilità in base ai requisiti in C-12-1.
• [C-12-4] DEVE chiamare TrustManagerService.revokeTrust()
  • Dopo un massimo di 24 ore dalla concessione della fiducia oppure
  • Dopo un periodo di inattività di 8 ore oppure
  • Se le implementazioni non utilizzano la misurazione della distanza con protezione criptata e accurata come definito in [C-12-5], quando la connessione di base al dispositivo fisico nelle vicinanze viene persa.
• [C-12-5] Le implementazioni che si basano su misurazioni della distanza sicure e precise per soddisfare i requisiti di [C-12-4] DEVONO utilizzare una delle seguenti soluzioni:
  • Implementazioni che utilizzano la tecnologia UWB:
    • DEVE soddisfare i requisiti di conformità, certificazione, accuratezza e calibrazione per la tecnologia UWB descritti in 7.4.9.
    • DEVE utilizzare una delle modalità di sicurezza P-STS elencate in 7.4.9.
  • Implementazioni che utilizzano Neighbor Awareness Networking (NAN) Wi-Fi:
    • DEVE soddisfare i requisiti di accuratezza in 2.2.1 [7.4.2.5/H-SR-1], utilizzare la larghezza di banda di 160 MHz (o superiore) e seguire i passaggi di configurazione della misurazione specificati in Calibrazione della presenza.
    • È NECESSARIO utilizzare LTF sicuro come definito in IEEE 802.11az.

Se le implementazioni dei dispositivi consentono alle applicazioni di creare display virtuali secondari e supportano gli eventi di input associati, ad esempio tramite VirtualDeviceManager, e i display non sono contrassegnati da VIRTUAL_DISPLAY_FLAG_SECURE,

• [C-13-8] È OBBLIGATORIO impedire l'avvio delle attività con l'attributo android:canDisplayOnRemoteDevices o i metadati android.activity.can_display_on_remote_devices impostati su false sul dispositivo virtuale.
• [C-13-9] È OBBLIGATORIO impedire l'avvio sul dispositivo virtuale delle attività che non attivano esplicitamente lo streaming e che indicano di mostrare contenuti sensibili, anche tramite SurfaceView#setSecure, FLAG_SECURE o SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS.
• [C-13-10] È OBBLIGATORIO disattivare l'installazione di app avviate da dispositivi virtuali.

Se le implementazioni dei dispositivi supportano stati di alimentazione del display separati tramite DeviceStateManager E supportano stati di blocco del display separati tramite KeyguardDisplayManager, devono:

• [C-SR-2] È FORTEMENTE CONSIGLIATO di utilizzare una credenziale che soddisfi i requisiti definiti nella sezione 9.11.1 o una biometria che soddisfi almeno le specifiche di classe 1 definite nella sezione 7.3.10 per consentire lo sblocco indipendente dal display predefinito del dispositivo.
• [C-SR-3] È FORTEMENTE CONSIGLIATO limitare lo sblocco del display separato tramite un timeout del display definito.
• [C-SR-4] È FORTEMENTE CONSIGLIATO consentire all'utente di bloccare globalmente tutti i display tramite il blocco dal dispositivo palmare principale.

9.11.2. StrongBox

Il sistema Android Keystore consente agli sviluppatori di app di archiviare le chiavi di crittografia in un processore sicuro dedicato, nonché nell'ambiente di esecuzione isolato descritto sopra. Questo processore sicuro dedicato è chiamato "StrongBox". I requisiti C-1-3 fino a C-1-11 di seguito definiscono i requisiti che un dispositivo deve soddisfare per essere considerato una cassetta di sicurezza.

Implementazioni di dispositivi con un processore sicuro dedicato:

• [C-SR-1] È MOLTO CONSIGLIATO supportare StrongBox. StrongBox diventerà probabilmente un requisito in una release futura.

Se le implementazioni dei dispositivi supportano StrongBox:

• [C-1-1] È OBBLIGATORIO dichiarare FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] È NECESSARIO fornire hardware sicuro dedicato utilizzato per eseguire il backup del keystore e per proteggere l'autenticazione utente. L'hardware sicuro dedicato può essere utilizzato anche per altri scopi.

• [C-1-3] DEVE avere una CPU discreta che non condivide cache, DRAM, coprocessori o altre risorse di base con il processore dell'applicazione (AP).

• [C-1-4] DEVE garantire che le periferiche condivise con l'AP non possano alterare in alcun modo l'elaborazione di StrongBox o ottenere informazioni da StrongBox. L'AP POTREBBE disattivare o bloccare l'accesso a StrongBox.

• [C-1-5] DEVE avere un orologio interno con un'accuratezza ragionevole (+-10%) che sia immune alle manipolazioni da parte dell'AP.

• [C-1-6] DEVE avere un generatore di numeri casuali veri che produca un output distribuito in modo uniforme e imprevedibile.

• [C-1-7] DEVE essere resistente alle manomissioni, inclusa la penetrazione fisica e i glitch.

• [C-1-8] DEVE avere resistenza ai canali laterali, inclusa la resistenza alla fuga di informazioni tramite canali laterali di alimentazione, temporizzazione, radiazioni elettromagnetiche e radiazioni termiche.

• [C-1-9] DEVE disporre di uno spazio di archiviazione sicuro che garantisca la riservatezza, l'integrità, l'autenticità, la coerenza e l'aggiornamento dei contenuti. Lo spazio di archiviazione NON DEVE essere leggibile o modificabile, tranne come consentito dalle API StrongBox.

• Per convalidare la conformità ai punti [C-1-3] fino a [C-1-9], le implementazioni dei dispositivi:

  • [C-1-10] DEVE includere l'hardware certificato in base al profilo di protezione delle smart card sicure BSI-CC-PP-0084-2014 o valutato da un laboratorio di test accreditato a livello nazionale che incorpori la valutazione della vulnerabilità con potenziale di attacco elevato in base ai criteri comuni per l'applicazione del potenziale di attacco alle smart card.
  • [C-1-11] DEVE includere il firmware valutato da un laboratorio di test accreditato a livello nazionale che includa la valutazione della vulnerabilità con potenziale di attacco elevato in base ai Common Criteria Application of Attack Potential to Smartcards.
  • [C-SR-2] È MOLTO CONSIGLIATO includere l'hardware sottoposto a valutazione utilizzando un target di sicurezza, un livello di garanzia della valutazione (EAL) 5, aumentato da AVA_VAN.5. È probabile che la certificazione EAL 5 diventerà un requisito in una release futura.
  • [C-SR-3] È FORTEMENTE CONSIGLIATO di fornire resistenza agli attacchi di addetti ai lavori (IAR), il che significa che un addetto ai lavori con accesso alle chiavi di firma del firmware non può produrre firmware che causi la fuga di segreti da StrongBox, aggiri i requisiti di sicurezza funzionale o in altro modo consenta l'accesso a dati utente sensibili. Il modo consigliato per implementare IAR è consentire gli aggiornamenti del firmware solo quando la password dell'utente principale viene fornita tramite l'HAL IAuthSecret.

9.11.3. Credenziali di identità

Il sistema di credenziali di identità viene definito e realizzato implementando tutte le API nel pacchetto android.security.identity.*. Queste API consentono agli sviluppatori di app di archiviare e recuperare i documenti di identità degli utenti. Implementazioni dei dispositivi:

• [C-SR-1] È MOLTO CONSIGLIATO implementare il Sistema di credenziali di identità.

Se le implementazioni dei dispositivi implementano il Sistema di credenziali di identità:

• [C-1-1] DEVE restituire un valore non nullo per il metodo IdentityCredentialStore#getInstance().

• [C-1-2] DEVE implementare il Sistema di credenziali di identità (ad es. le API android.security.identity.*) con codice che comunica con un'applicazione attendibile in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e sopra. 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.

• [C-1-3] Le operazioni di crittografia necessarie per implementare il Sistema di credenziali di identità (ad es. le API android.security.identity.*) DEVONO essere eseguite interamente nell'applicazione attendibile e il materiale della chiave privata NON DEVE mai uscire dall'ambiente di esecuzione isolato, a meno che non sia specificamente richiesto da API di livello superiore (ad es. il metodo createEphemeralKeyPair()).

• [C-1-4] L'applicazione attendibile DEVE essere implementata in modo che le sue proprietà di sicurezza non siano interessate (ad es. i dati delle credenziali non vengono rilasciati a meno che non siano soddisfatte le condizioni di controllo dell'accesso, non è possibile produrre MAC per dati arbitrari) anche se Android non funziona correttamente o è compromesso.

Il progetto open source Android upstream fornisce un'implementazione di riferimento di un'applicazione attendibile (libeic) che può essere utilizzata per implementare il sistema delle credenziali di identità.

9.12. Eliminazione dei dati

Tutte le implementazioni dei dispositivi:

• [C-0-1] DEVE fornire agli utenti un meccanismo per eseguire un "Ripristino dei dati di fabbrica".
• [C-0-2] È NECESSARIO eliminare tutti i dati sul file system userdata quando viene eseguito un "ripristino dei dati di fabbrica".
• [C-0-3] DEVE eliminare i dati in modo da soddisfare gli standard di settore pertinenti come NIST SP800-88 quando esegue un "ripristino dei dati di fabbrica".
• [C-0-4] DEVE attivare la procedura di "Ripristino dei dati di fabbrica" riportata sopra quando l'API DevicePolicyManager.wipeData() viene chiamata dall'app Device Policy Controller dell'utente principale.
• POTREBBE fornire un'opzione di eliminazione rapida dei dati che esegue solo un'eliminazione logica dei dati.

9.13. Modalità Avvio sicuro

Android fornisce la modalità Avvio sicuro, che consente agli utenti di avviare il sistema in una modalità in cui è consentita l'esecuzione solo delle app di sistema preinstallate e tutte le app di terze parti vengono disattivate. Questa modalità, nota come "Modalità di avvio sicuro", offre all'utente la possibilità di disinstallare app di terze parti potenzialmente dannose.

Le implementazioni dei dispositivi sono:

• [C-SR-1] È FORTEMENTE CONSIGLIATO implementare la modalità Avvio protetto.

Se le implementazioni dei dispositivi implementano la modalità di avvio sicuro, devono:

• [C-1-1] DEVE fornire all'utente un'opzione per attivare la modalità provvisoria in modo che non possa essere interrotta dalle app di terze parti installate sul dispositivo, tranne quando l'app di terze parti è un controller Device Policy e ha impostato il flag UserManager.DISALLOW_SAFE_BOOT su true.

• [C-1-2] DEVE fornire all'utente la possibilità di disinstallare qualsiasi app di terze parti in modalità provvisoria.

• DOVREBBE fornire all'utente un'opzione per accedere alla modalità di avvio sicuro dal menu di avvio utilizzando un flusso di lavoro diverso da quello di un normale avvio.

9.14. Isolamento del sistema di veicoli a motore

I dispositivi Android Automotive devono scambiare dati con i sottosistemi critici del veicolo utilizzando l'HAL del veicolo per inviare e ricevere messaggi tramite le reti del veicolo, come il bus CAN.

Lo scambio di dati può essere reso sicuro implementando funzionalità di sicurezza al di sotto dei livelli del framework Android per impedire l'interazione dannosa o involontaria con questi sottosistemi.

9.15. Piani di abbonamento

Per "Piani di abbonamento" si intendono i dettagli del piano del rapporto di fatturazione forniti da un operatore di telefonia mobile tramite SubscriptionManager.setSubscriptionPlans().

Tutte le implementazioni dei dispositivi:

• [C-0-1] DEVE restituire i piani di abbonamento solo all'app dell'operatore mobile che li ha forniti in origine.
• [C-0-2] NON DEVE eseguire il backup o caricare i piani di abbonamento da remoto.
• [C-0-3] DEVE consentire solo le sostituzioni, ad esempio SubscriptionManager.setSubscriptionOverrideCongested(), dall'app dell'operatore di telefonia mobile che al momento fornisce piani di abbonamento validi.

9.16. Migrazione dei dati delle applicazioni

Se le implementazioni del dispositivo includono la possibilità di eseguire la migrazione dei dati da un dispositivo a un altro e non limitano i dati dell'applicazione che vengono copiati a quelli configurati dallo sviluppatore dell'applicazione nel file manifest tramite l'attributo android:fullBackupContent, devono:

• [C-1-1] NON DEVE avviare trasferimenti di dati delle applicazioni da dispositivi su cui l'utente non ha impostato un'autenticazione principale come descritto in 9.11.1 Schermata di blocco e autenticazione sicure.
• [C-1-2] DEVE confermare in modo sicuro l'autenticazione principale sul dispositivo di origine e confermare con l'utente l'intenzione di copiare i dati sul dispositivo di origine prima che qualsiasi dato venga trasferito.
• [C-1-3] È OBBLIGATORIO utilizzare l'attestazione della chiave di sicurezza per assicurarsi che sia il dispositivo di origine sia il dispositivo di destinazione nella migrazione da dispositivo a dispositivo siano dispositivi Android legittimi e abbiano un bootloader bloccato.
• [C-1-4] È NECESSARIO eseguire la migrazione dei dati dell'applicazione solo alla stessa applicazione sul dispositivo di destinazione, con lo stesso nome del pacchetto E lo stesso certificato di firma.
• [C-1-5] DEVE essere indicata la migrazione dei dati del dispositivo di origine tramite una migrazione dei dati da dispositivo a dispositivo nel menu Impostazioni. Un utente NON DOVREBBE essere in grado di rimuovere questa indicazione.

9.17. Framework di virtualizzazione di Android

Se il dispositivo implementa il supporto per le API del framework di virtualizzazione di Android (android.system.virtualmachine.*), l'host Android:

• [C-1-1] DEVE supportare tutte le API definite dal pacchettoandroid.system.virtualmachine.
• [C-1-2] NON DEVE modificare il modello di autorizzazioni e SELinux di Android per la gestione delle macchine virtuali protette (pVM).

• [C-1-4] DEVE consentire solo il codice firmato dalla piattaforma e le app con privilegiNON DEVE consentire il codice non attendibile (ad es. app di terze parti) per creare ed eseguire una macchina virtuale protetta pVM . Nota: questa impostazione potrebbe cambiare nelle release future di Android.

Se il dispositivo implementa il supporto per le API del Framework di virtualizzazione di Android (android.system.virtualmachine.*), qualsiasi istanza di macchina virtuale protetta pVM :

• [C-2-1] DEVE essere in grado di eseguire tutti i sistemi operativi disponibili nell'APEX di virtualizzazione in una macchina virtuale protetta pVM .
• [C-2-2] NON DEVE consentire a una macchina virtuale protetta pVM di eseguire un sistema operativo che non è firmato dall'implementatore del dispositivo o dal fornitore del sistema operativo.
• [C-2-3] NON DEVE consentire a una macchina virtuale protetta pVM di eseguire i dati come codice (ad es. SELinux neverallow execmem).

• [C-2-5] DEVE implementare i meccanismi di difesa in profondità delle macchine virtuali protette pVM (ad es. SELinux per le pVM) anche per i sistemi operativi non Microdroid.
• [C-2-6] DEVI assicurarti che la pVM non riesca e che il firmware rifiuti di avviarsi se non riesce a verificare le immagini iniziali che la VM eseguirà. La verifica DEVE essere eseguita all'interno della VM.
• [C-2-7] DEVE garantire che la pVM non riesca il firmware rifiuti di avviarsi se l'integrità dell'istanza.img è compromessa.

Se il dispositivo implementa il supporto per le API del Framework di virtualizzazione di Android (android.system.virtualmachine.*), l'hypervisor:

• [C-3-1] DEVE garantire che le pagine di memoria di proprietà esclusiva di una VM (pVM o VM host) siano accessibili solo alla VM stessa o all'hypervisor e non ad altre VM, protette o non protette. NON DEVE consentire a nessuna VM privata di accedere a una pagina appartenente a un'altra entità (ad es. un'altra VM privata o un hypervisor), a meno che non sia condivisa esplicitamente dal proprietario della pagina. inclusa la VM host. Questo vale sia per gli accessi CPU che DMA.
• [C-3-2] È OBBLIGATORIO cancellare una pagina dopo che è stata utilizzata da una pVM e prima che venga restituita all'host (ad es. la pVM viene distrutta).
• [C-3-3SR-1] È FORTEMENTE CONSIGLIATO assicurarsi DEVI assicurarti che il firmware della VM protetta venga caricato ed eseguito prima di qualsiasi codice in una VM protetta.
• [C-3-4] DEVE garantire che ogni VM derivi un segreto per VM che {Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instance può essere dedotto solo da quella determinata VM e cambia al ripristino dei dati di fabbrica e OTA.

Se il dispositivo implementa il supporto per le API Android Virtualization Framework, in tutte le aree:

• [C-4-1] NON DEVE fornire funzionalità a una pVM che consenta di bypassare il modello di sicurezza di Android.

Se il dispositivo implementa il supporto per le API Android Virtualization Framework:

• [C-5-1] DEVE essere in grado di supportare la compilazione isolata ma può disattivare la funzionalità di compilazione isolata al momento della spedizione del dispositivo di un aggiornamento del runtime ART.

Se il dispositivo implementa il supporto per le API Android Virtualization Framework, per la gestione delle chiavi:

• [C-SR-26-2] È FORTEMENTE CONSIGLIATO di utilizzare DICE come meccanismo di derivazione della chiave segreta per VM. DEVI eseguire correttamente DICE, ovvero fornire i valori corretti.

10. Test di compatibilità del software

Le implementazioni dei dispositivi DEVONO superare tutti i test descritti in questa sezione. Tuttavia, tieni presente che nessun pacchetto di test software è completamente esaustivo. Per questo motivo, agli implementatori di dispositivi è FORTEMENTE CONSIGLIATO di apportare il minimo numero di modifiche possibile all'implementazione di riferimento e preferita di Android disponibile nell'Android Open Source Project. In questo modo, ridurrai al minimo il rischio di introdurre bug che creano incompatibilità che richiedono rilavorazioni e potenziali aggiornamenti dei dispositivi.

10.1. Compatibility Test Suite (CTS)

Implementazioni dei dispositivi:

• [C-0-1] DEVE superare la Compatibility Test Suite (CTS) di Android disponibile nell'Android Open Source Project, utilizzando il software di spedizione finale sul dispositivo.

• [C-0-2] DEVE garantire la compatibilità in caso di ambiguità nel CTS e per eventuali reimplementazioni di parti del codice sorgente di riferimento.

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi software, anche il CTS potrebbe contenere bug. Il CTS verrà sottoposto a versionamento indipendentemente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni del CTS per Android 14.

Implementazioni dei dispositivi:

• [C-0-3] DEVE superare la versione CTS più recente disponibile al momento del completamento del software del dispositivo.

• DEVI utilizzare l'implementazione di riferimento nella struttura Android Open Source il più possibile.

10.2. CTS Verifier

CTS Verifier è incluso nella Compatibility Test Suite ed è pensato per essere eseguito da un operatore umano per testare le funzionalità che non possono essere testate da un sistema automatico, ad esempio il corretto funzionamento di una videocamera e dei sensori.

Implementazioni dei dispositivi:

• [C-0-1] DEVE eseguire correttamente tutti i casi applicabili nel verificatore CTS.

CTS Verifier include test per molti tipi di hardware, incluso hardware facoltativo.

Implementazioni dei dispositivi:

• [C-0-2] DEVE superare tutti i test per l'hardware di cui è dotato. Ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente lo scenario di test dell'accelerometro in CTS Verifier.

I casi di test per le funzionalità indicate come facoltative da questo Documento di definizione della compatibilità POSSONO essere saltati o omessi.

• [C-0-2] Ogni dispositivo e ogni build DEVONO eseguire correttamente lo strumento di verifica CTS, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori dei dispositivi eseguano esplicitamente il CTS Verifier sulle build che differiscono solo in modo banale. Nello specifico, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato CTS Verifier solo per l'insieme di lingue, branding e così via inclusi POSSONO omettere il test CTS Verifier.

11. Software aggiornabile

• [C-0-1] Le implementazioni dei dispositivi DEVONO includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire upgrade "in tempo reale", ovvero potrebbe essere necessario riavviare il dispositivo. È possibile utilizzare qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, qualsiasi dei seguenti approccisoddisfa questo requisito:

  • Download "over-the-air (OTA)" con aggiornamento offline tramite riavvio.
  • Aggiornamenti "in tethering" tramite USB da un PC host.
  • Aggiornamenti "offline" tramite un riavvio e un aggiornamento da un file su una memoria rimovibile.

• [C-0-2] Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati dell'utente. In altre parole, il meccanismo di aggiornamento DEVE preservare i dati privati e condivisi dell'applicazione. Tieni presente che il software Android upstream include un meccanismo di aggiornamento che soddisfa questo requisito.

• [C-0-3] L'intero aggiornamento DEVE essere firmato e il meccanismo di aggiornamento sul dispositivo DEVE verificare l'aggiornamento e la firma in base a una chiave pubblica memorizzata sul dispositivo.

• [C-SR-1] È FORTEMENTE CONSIGLIATO che il meccanismo di firma esegui l'hash dell'aggiornamento con SHA-256 e convalidi l'hash rispetto alla chiave pubblica utilizzando ECDSA NIST P-256.

Se le implementazioni del dispositivo includono il supporto di una connessione di dati non misurata come il profilo 802.11 o PAN (Personal Area Network) Bluetooth, devono:

• [C-1-1] DEVE supportare i download OTA con aggiornamento offline tramite riavvio.

Le implementazioni dei dispositivi DEVONO verificare che l'immagine di sistema sia identica in formato binario al risultato previsto dopo un aggiornamento OTA. L'implementazione OTA basata su blocchi nel progetto open source Android upstream, aggiunta da Android 5.1, soddisfa questo requisito.

Inoltre, le implementazioni dei dispositivi DEVONO supportare gli aggiornamenti di sistema A/B. AOSP implementa questa funzionalità utilizzando l'HAL di controllo del boot.

Se viene rilevato un errore nell'implementazione di un dispositivo dopo il rilascio, ma nel corso della sua ragionevole durata del prodotto, stabilita in collaborazione con il team di compatibilità di Android, che influisce sulla compatibilità delle applicazioni di terze parti, allora:

• [C-2-1] L'implementatore del dispositivo DEVE correggere l'errore tramite un aggiornamento software disponibile che può essere applicato in base al meccanismo appena descritto.

Android include funzionalità che consentono all'app Proprietario dispositivo (se presente) di controllare l'installazione degli aggiornamenti di sistema. Se il sottosistema di aggiornamento di sistema per i dispositivi segnala android.software.device_admin, i dispositivi:

• [C-3-1] DEVE implementare il comportamento descritto nella classe SystemUpdatePolicy.

12. Log delle modifiche del documento

Per un riepilogo delle modifiche alla definizione di compatibilità in questa release:

• Documentare il log delle modifiche

13. Contattaci

Puoi partecipare al forum sulla compatibilità con Android e chiedere chiarimenti o segnalare eventuali problemi che ritieni non essere trattati nel documento.