Definizione di compatibilità con Android 14

1. Introduzione

Questo documento elenca i requisiti che devono essere soddisfatti per la compatibilità dei dispositivi con Android 14.

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

Nell'ambito di questo documento, per "implementatore del dispositivo" o "implementatore" si intende una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 14. Con "implementazione del dispositivo" o "implementazione" si intende la soluzione hardware/software così sviluppata.

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

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

Per questo motivo, il Android Open Source Project è sia il riferimento sia l'implementazione preferita di Android. Si consiglia vivamente agli sviluppatori di dispositivi di basare le loro implementazioni sul codice sorgente "upstream" disponibile nel progetto open source Android. Anche se alcuni componenti possono ipoteticamente essere sostituiti con implementazioni alternative, è VIVAMENTE CONSIGLIATO di non seguire questa pratica, in quanto il superamento dei test del software diventerà molto più difficile. È responsabilità dell'implementatore di garantire la piena compatibilità del comportamento con l'implementazione standard di Android, inclusa e oltre la suite di test di compatibilità. Infine, tieni presente che determinate sostituzioni e modifiche dei componenti sono espressamente vietate dal presente documento.

Molte delle risorse collegate in questo documento derivano direttamente o indirettamente dall'SDK Android e saranno identiche dal punto di vista alle informazioni contenute nella documentazione dell'SDK. Nei casi in cui la presente Definizione di compatibilità o la Suite di test di compatibilità non concordi con la documentazione dell'SDK, la documentazione relativa all'SDK è considerata autorevole. Eventuali dettagli tecnici forniti nelle risorse collegate in questo documento vengono considerati inclusi nella presente definizione di compatibilità e vengono considerati ai fini dell'inclusione.

1.1 Struttura dei documenti

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 riguardano universalmente le implementazioni di dispositivi Android, sono elencati nelle sezioni successive alla Sezione 2. Nel presente documento, questi requisiti sono indicati come "Requisiti principali".

1.1.2. ID requisito

L'ID requisito è assegnato per i requisiti MUST.

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

Ogni ID è definito come di seguito:

• ID tipo di dispositivo (per saperne di più, vedi 2. Tipi di dispositivi)
  • C: Core (requisiti che si applicano a tutte le implementazioni dei dispositivi Android)
  • H: Dispositivo portatile Android
  • T: Dispositivo Android TV
  • A: Implementazione di Android Automotive
  • W: Implementazione di Android Watch
  • Scheda: implementazione su tablet Android
• ID condizione
  • Se il requisito è incondizionato, questo ID è impostato su 0.
  • Quando il requisito è condizionale, 1 viene assegnato per la prima condizione e il numero aumenta di 1 nella stessa sezione e nello stesso tipo di dispositivo.
• ID requisito
  • Questo ID parte da 1 e incrementa di 1 nella stessa sezione e nella stessa condizione.

1.1.3. ID requisito nella Sezione 2

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

ID di sezione che è 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

Android Open Source Project fornisce uno stack di software utilizzabile per diversi tipi di dispositivi e fattori di forma. Per supportare la sicurezza sui dispositivi, lo stack software, inclusi eventuali sistemi operativi sostitutivi o implementazioni di kernel alternativi, devono essere eseguiti in un ambiente sicuro come descritto nella sezione 9 e altrove nel presente CDD. Alcuni tipi di dispositivi hanno un ecosistema di distribuzione delle applicazioni relativamente migliore.

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

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

2.1 Configurazioni dei dispositivi

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

2.2. Requisiti per gli smartphone

Un dispositivo portatile Android fa riferimento all'implementazione di un dispositivo Android che viene solitamente utilizzato tenendolo in mano, ad esempio un lettore mp3, uno smartphone o un tablet.

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

• Disporre di una fonte di alimentazione che garantisca la mobilità, ad esempio una batteria.
• Avere una dimensione dello schermo in diagonale fisica compresa tra 4 pollici da 3,3 pollici (o 2,5 pollici per le implementazioni di dispositivi fornite con livello API 29 o precedenti) a 8 pollici.
• Disporre di un'interfaccia di immissione touchscreen.

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

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

2.2.1. Hardware

Implementazioni di 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 con misure di almeno 2,2" sul lato corto e 3,4" su quello lungo.

• [7.1.1.3/H-SR-1] È VIVAMENTE CONSIGLIATO di fornire agli utenti un'invito per modificare le dimensioni di visualizzazione (densità dello schermo).

• [7.1.1.1/H-0-2] DEVE supportare la composizione GPU dei buffer grafici grandi almeno quanto la massima risoluzione di qualsiasi display integrato.

Crea nuovi requisiti

• [7.1.1.1/H-0-3]* DEVE mappare ogni display UI_MODE_NORMAL reso disponibile per applicazioni di terze parti su un'area di visualizzazione fisica non ostruita di almeno 2,2" pollici sul lato corto e 3,4" sul bordo lungo.

• [7.1.1.3/H-0-1]* DEVE impostare il valore di DENSITY_DEVICE_STABLE su un valore pari o superiore al 92% rispetto alla densità fisica effettiva del display corrispondente.

Termina nuovi requisiti

Se le implementazioni dei dispositivi portatili supportano la rotazione dello schermo del software:

• [7.1.1.1/H-1-1]* DEVE rendere lo schermo logico reso disponibile per le applicazioni di terze parti di almeno 50 mm sul bordo corto e 72 mm sul bordo lungo. I dispositivi con livello API Android 29 o precedente con livello API Android 29 o precedente POTREBBERO essere esentati da questo requisito.

Se le implementazioni dei dispositivi portatili non supportano la rotazione dello schermo del software:

• [7.1.1.1/H-2-1]* DEVE rendere lo schermo logico reso disponibile per le applicazioni di terze parti di almeno 7,1 cm sul bordo corto. I dispositivi con livello API Android 29 o precedente con livello API Android 29 o precedente POTREBBERO essere esentati da questo requisito.

Se le implementazioni dei dispositivi portatili rivendicano il supporto della tecnologia High Dynamic Range fino a Configuration.isScreenHdr() , questi:

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

Implementazioni di dispositivi portatili:

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

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

• [7.1.4.6/H-1-1] DEVE segnalare come output una traccia protobuf conforme allo schema per i contatori GPU e le fasi di rendering GPU definiti nella documentazione Perfetto.
• [7.1.4.6/H-1-2] DEVE segnalare valori conformi per i contatori GPU del dispositivo seguendo il protocollo di pacchetti di traccia del contatore GPU.
• [7.1.4.6/H-1-3] DEVE segnalare valori conformi per le RenderStages GPU del dispositivo dopo il protocollo di pacchetti di tracce della fase di rendering.
• [7.1.4.6/H-1-4] DEVE segnalare un tracepoint di frequenza GPU, come specificato dal formato: power/gpu_frequency.

Implementazioni di dispositivi portatili:

• [7.1.5/H-0-1] DEVE includere il supporto per la modalità di compatibilità delle applicazioni legacy, come implementata dal codice open source di Android upstream. Vale a dire, le implementazioni dei dispositivi NON DEVONO alterare i trigger o le soglie di attivazione della modalità di compatibilità e NON DEVONO alterare il comportamento della modalità di compatibilità stessa.
• [7.2.1/H-0-1] DEVE includere il supporto per le applicazioni Input Method Editor (IME) di terze parti.
• [7.2.3/H-0-2] DEVE inviare sia l'evento di pressione prolungata e normale della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano. Questi eventi NON DEVONO essere consumati dal sistema e POSSONO essere attivati dall'esterno del dispositivo Android (ad esempio, una 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 hanno la schermata Home.
• [7.2.3/H-0-4] DEVE fornire la funzione Indietro su tutti i display compatibili con Android e la funzione Recenti su almeno uno dei display compatibili con Android.
• [7.2.4/H-0-1] DEVE supportare l'input del touchscreen.
• [7.2.4/H-SR-1] È VIVAMENTE CONSIGLIATO di avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService o un'attività che gestisce ACTION_ASSIST alla 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] È VIVAMENTE CONSIGLIATO di includere un accelerometro a 3 assi.

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

• [7.3.1/H-1-1] DEVE essere in grado di segnalare eventi con 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, queste:

• [7.3.3/H-2-1] DEVE segnalare le misurazioni GNSS non appena vengono rilevate, anche se non è stata ancora segnalata una posizione calcolata dal GPS/GNSS.
• [7.3.3/H-2-2] DEVE segnalare gli pseudointervalli e i tassi di pseudointervallo GNSS, che, in condizioni di cielo aperto dopo aver determinato la posizione, se fermo o in movimento con meno di 0, 2 metri al secondo quadrato di accelerazione, sono sufficienti per calcolare la posizione entro 20 metri e la velocità entro 0, 2 metri al secondo

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

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

Implementazioni di dispositivi portatili che possono effettuare chiamate vocali e indicare qualsiasi valore diverso da PHONE_TYPE_NONE in getPhoneType:

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

Implementazioni di dispositivi portatili:

• [7.3.11/H-SR-1] È VIVAMENTE CONSIGLIATO di supportare un sensore di posizione con 6 gradi di libertà.
• [7.4.3/H] DOVREBBE includere il supporto per Bluetooth e Bluetooth LE.

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

• [7,4.2.5/H-1-1] DEVE indicare l'intervallo con precisione entro +/-1 metro a 160 MHz di larghezza di banda al 68° percentile (calcolati con la funzione di distribuzione cumulativa), +/-2 metri a 80 MHz di larghezza di banda al 68° percentile, +/-4 metri a 40 MHz-° percentile di larghezza di banda al 68° percentile, +/-4 metri a 40 MHz

• [7.4.2.5/H-SR-1] CONSIGLIATO VIVAMENTE di segnalare l'intervallo con precisione entro +/-1 metro alla larghezza di banda di 160 MHz al 90° percentile (come calcolato con la funzione di distribuzione cumulativa), +/-2 metri alla larghezza di banda di 80 MHz al 90° percentile di larghezza di banda di +/-4 MHz e al 90° percentile di larghezza di banda di +/-4 MHz e al 90° percentile

Ti consigliamo VIVAMENTE di seguire i passaggi di configurazione della misurazione specificati in Calibrazione della presenza.

Crea nuovi requisiti

Se le implementazioni dei dispositivi portatili dichiarano FEATURE_BLUETOOTH_LE:

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

Termina nuovi requisiti

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] DEVE avere un campo visivo normale (FOV) per impostazione predefinita e DEVE essere compreso tra 50 e gradi.

Implementazioni di dispositivi portatili:

• [7.6.1/H-0-1] DEVONO disporre di almeno 4 GB di spazio di archiviazione permanente per i dati privati dell'applicazione (ovvero 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 portatili dichiarano il supporto soltanto di un'ABI a 32 bit:

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

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

Se le implementazioni dei dispositivi portatili 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 di almeno 816 MB se la visualizzazione predefinita utilizza risoluzioni framebuffer fino a qHD (ad es. FWVGA).

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

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

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

Tieni presente che con "memoria disponibile per il kernel e lo spazio utente" si intende lo spazio di memoria fornito oltre alla memoria già dedicata ai componenti hardware, come radio, video e così via, che non sono sotto il controllo del kernel sulle implementazioni dei dispositivi.

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

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

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

• [7.6.1/H-10-1] DEVONO disporre di almeno 4 GB di spazio di archiviazione permanente per i dati privati delle applicazioni (ovvero partizione "/data").
• DEVE dichiarare il flag di funzionalità android.hardware.ram.normal.

Se le implementazioni sui dispositivi portatili includono un numero maggiore o uguale a 2 GB e meno di 4 GB di memoria disponibile per il kernel e lo spazio utente:

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

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

• [7.6.1/H-1-1] DEVE supportare solo le ABI a 32 bit.

Implementazioni di dispositivi portatili:

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

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

• [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 documentato nella documentazione dell'SDK Android.

Implementazioni di 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 il supporto della modalità VR e includono il relativo supporto, possono:

• [7.9.1/H-1-1] DEVE dichiarare il flag della funzionalità android.hardware.vr.high_performance.
• [7.9.1/H-1-2] DEVE includere un'applicazione che implementa android.service.vr.VrListenerService che possa 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 nell'implementazione (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	Il contesto	Comportamento
R	Pagina di utilizzo dell'HID: 0x0C Utilizzo dell'HID: 0x0CD Chiave del kernel: KEY_PLAYPAUSE Chiave Android: KEYCODE_MEDIA_PLAY_PAUSE	Riproduzione di contenuti multimediali	Ingresso: pressione breve Uscita: consente di riprodurre o mettere in pausa
			Input: pressione prolungata Output: avvia comando vocale Invia: android.speech.action.VOICE_SEARCH_HANDS_FREE se il dispositivo è bloccato o lo schermo è spento. Invia android.speech.RecognizerIntent.ACTION_WEB_SEARCH in caso contrario.
		Chiamata in arrivo	Ingresso: pressione breve Output: consente di accettare la chiamata
			Ingresso: pressione prolungata. Output: rifiuta la chiamata.
		Chiamata in corso	Ingresso: pressione breve Uscita: termina la chiamata
			Ingresso: pressione prolungata. Output: disattiva o riattiva l'audio del microfono.
MLD	Pagina di utilizzo HID: 0x0C Utilizzo HID: 0x0E9 Chiave kernel: KEY_VOLUMEUP Chiave Android: VOLUME_UP	Riproduzione di contenuti multimediali, Chiamata in corso	Ingresso: pressione breve o lunga Uscita: consente di aumentare il volume del sistema o delle cuffie
C	Pagina di utilizzo HID: 0x0C Utilizzo HID: 0x0EA Chiave kernel: KEY_VOLUMEDOWN Chiave Android: VOLUME_DOWN	Riproduzione di contenuti multimediali, Chiamata in corso	Ingresso: pressione breve o lunga. Uscita: consente di abbassare il volume del sistema o delle cuffie
D	Pagina di utilizzo dell'HID: 0x0C Utilizzo dell'HID: 0x0CF Chiave del kernel: KEY_VOICECOMMAND Chiave Android: KEYCODE_VOICE_ASSIST	Tutti. Può essere attivato in qualsiasi istanza.	Ingresso: pressione breve o lunga. Output: avvia il comando vocale

• [7.8.2.2/H-1-2] DEVE attivare ACTION_HEADSET_PLUG su un inserto, ma solo dopo che le interfacce audio e gli endpoint USB sono stati elencati correttamente per identificare il tipo di terminale collegato.

Quando vengono rilevati i terminali audio USB di tipo 0x0302, questi:

• [7.8.2.2/H-2-1] DEVE trasmettere l'intent ACTION_HEADSET_PLUG con l'opzione extra "microfono" impostata su 0.

Quando vengono rilevati i terminali audio USB di tipo 0x0402, questi:

• [7.8.2.2/H-3-1] DEVE trasmettere l'intent ACTION_HEADSET_PLUG con l'opzione extra "microfono" impostata su 1.

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

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

• [7.8.2.2/H-4-2] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e il ruolo isSink() se il campo di tipo 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 di tipo 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 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 VIVAMENTE CONSIGLIATE al collegamento di una periferica audio USB-C, per eseguire l'enumerazione dei descrittori USB, identificare i tipi di terminali e trasmettere l'intent ACTION_HEADSET_PLUG in meno di 1000 millisecondi.

Se le implementazioni dei dispositivi portatili dichiarano android.hardware.audio.output e android.hardware.microphone, questi:

• [5.6/H-1-1] DEVE avere una latenza media di andata e ritorno, pari o inferiore a 300 millisecondi, su 5 misurazioni, con deviazione media assoluta inferiore a 30 ms, sui seguenti percorsi dati: "da 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 tocco per toni di 300 millisecondi o meno per almeno 5 misurazioni sul percorso dati speaker-microfono.

Se le implementazioni dei dispositivi portatili includono almeno un attuatore aptico:

• [7.10/H]* NON DEVE utilizzare un attuatore aptico (vibratore) con massa rotante eccentrica (ERM).
• [7.10/H]* DOVREBBE implementare tutte le costanti pubbliche per una tecnologia aptica chiara in android.view.HapticFeedbackConstants, vale a dire (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, MOVEEST_KEY,
• [7.10/H]* DOVREBBE implementare tutte le costanti pubbliche per la aptica chiara in android.os.VibrationEffect, ovvero (Effetti_TICK, Effetti_CLICK, Effetti_HEAVY_CLICK e EFF_DOUBLE_CLICK) e tutte le costanti PRIMITIVE_* pubbliche possibili per i contenuti aptica avanzati QUI, Alcune di queste primitive, come LOW_TICK e SPIN, potrebbero essere realizzabili solo se la vibrazione è in grado di supportare frequenze relativamente basse.
• [7.10/H]* DEVE seguire le linee guida per la mappatura delle costanti pubbliche in android.view.HapticFeedbackConstants alle costanti android.os.VibrationEffect consigliate, con le corrispondenti relazioni di ampiezza.
• [7.10/H]* DEVE seguire la valutazione della qualità per le API createOneShot() e createWaveform().
• [7.10/H]* DEVE verificare che il risultato dell'API pubblica android.os.Vibrator.hasAmplitudeControl() rispecchi correttamente le capacità del vibratore.
• [7.10/H]* DEVE posizionare l'attuatore vicino al punto in cui il dispositivo viene solitamente tenuto o toccato con le mani.

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

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

Crea nuovi requisiti

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

Termina nuovi requisiti

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

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

• [7,10/H] La frequenza di risonanza dell'LRA dell'asse X deve essere inferiore a 200 Hz.

Se le implementazioni dei dispositivi portatili seguono la mappatura della costante aptica, questi:

• [7.10/H]* DEVE verificare lo stato dell'implementazione eseguendo le API android.os.Vibrator.areAllEffectsSupported() e android.os.Vibrator.arePrimitivesSupported().

• [7.10/H]* DEVE eseguire una valutazione della qualità per le costanti aptiche.

• [7.10/H]* DEVE verificare e aggiornare, se necessario, la configurazione di riserva per le primitive non supportate, come descritto nelle linee guida all'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 ad applicazioni di terze parti:

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] Profilo AAC MPEG-4 (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 ad applicazioni di terze parti:

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

Crea nuovi requisiti

• [5.2/H-0-3] AV1

Termina nuovi requisiti

Le implementazioni dei dispositivi portatili DEVONO supportare i seguenti formati di decodifica video e renderli disponibili ad applicazioni di terze parti:

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

Crea nuovi requisiti

• [5.3/H-0-6] AV1

Termina nuovi requisiti

2.2.3. streaming

Implementazioni di dispositivi portatili:

• [3.2.3.1/H-0-1] DEVE avere un'applicazione 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 fornisca all'utente l'affetto per accedere ai dati del fornitore del documento utilizzando l'API DocumentsProvider.
• [3.2.3.1/H-0-2]* DEVE precaricare una o più applicazioni o componenti di servizio con un gestore di intent, per tutti i pattern di filtro per intent pubblici definiti dai seguenti intent di applicazione elencati qui.
• [3.2.3.1/H-SR-1] Si consiglia VIVAMENTE di precaricare un'applicazione email in grado di gestire gli intent ACTION_SENDTO, ACTION_SEND o ACTION_SEND_MULTIPLE per inviare un'email.
• [3.4.1/H-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.
• [3.4.2/H-0-1] DEVE includere un'applicazione browser autonoma per la navigazione web generale degli utenti.
• [3.8.1/H-SR-1] È VIVAMENTE CONSIGLIATO di implementare un'Avvio app predefinito che supporti il blocco in-app di scorciatoie, widget e widgetFeature.
• [3.8.1/H-SR-2] È VIVAMENTE CONSIGLIATO di implementare un'Avvio app predefinito che consenta di accedere rapidamente alle scorciatoie aggiuntive fornite dalle app di terze parti tramite l'API ShortcutManager.
• [3.8.1/H-SR-3] È VIVAMENTE CONSIGLIATO di includere un'app Avvio app predefinita che mostra i badge per le icone delle app.
• [3.8.2/H-SR-1] È VIVAMENTE CONSIGLIATO per supportare i widget di app di terze parti.
• [3.8.3/H-0-1] DEVE consentire ad app di terze parti di notificare agli utenti eventi importanti tramite le classi API Notification e NotificationManager.
• [3.8.3/H-0-2] DEVE supportare le notifiche avanzate.
• [3.8.3/H-0-3] DEVE supportare le notifiche in evidenza.
• [3.8.3/H-0-4] DEVE includere un'area notifiche, che offra all'utente la possibilità di controllare direttamente (ad es. rispondere, posticipare, ignorare, bloccare) le notifiche tramite l'invito dell'utente, come i pulsanti di azione o il pannello di controllo, come implementato nell'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] È VIVAMENTE CONSIGLIATO di mostrare la prima scelta fornita da RemoteInput.Builder setChoices() nell'area notifiche senza ulteriori interazioni da parte dell'utente.
• [3.8.3/H-SR-2] È VIVAMENTE CONSIGLIATO di mostrare tutte le scelte fornite tramite RemoteInput.Builder setChoices() nell'area notifiche quando l'utente espande tutte le notifiche nell'area notifiche.
• [3.8.3.1/H-SR-1] È VIVAMENTE CONSIGLIATO di visualizzare 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] È VIVAMENTE CONSIGLIATO di implementare un assistente sul dispositivo per gestire l'azione di assistenza.

Se le implementazioni dei dispositivi portatili supportano le notifiche MediaStyle:

• [3.8.3.1/H-SR-2] È VIVAMENTE CONSIGLIATO di fornire un'invito all'utente (ad esempio, selettore di output) accessibile dalla UI di sistema che consente agli utenti di passare tra i percorsi multimediali disponibili appropriati (ad esempio, dispositivi e percorsi Bluetooth forniti a MediaRouter2Manager) quando un'app pubblica una notifica MediaStyle con un tokenMediaSession.

Crea nuovi requisiti

Se le implementazioni dei dispositivi, incluso il tasto di navigazione recente della funzione, come descritto in dettaglio nella sezione 7.2.3, modificano l'interfaccia:

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

Termina nuovi requisiti

Se le implementazioni dei dispositivi portatili supportano l'azione Assist, queste:

• [3.8.4/H-SR-2] È VIVAMENTE CONSIGLIATO di usare la pressione prolungata del tasto HOME come interazione designata per avviare l'app di assistenza, come descritto nella sezione 7.2.3. DEVE lanciare l'app di assistenza selezionata dall'utente, in altre parole l'app che implementa VoiceInteractionService , oppure un'attività che gestisce l'intent ACTION_ASSIST.

Se le implementazioni dei dispositivi portatili supportano conversation notifications e le raggruppa in una sezione separata dalle notifiche di avviso e notifiche silenziose senza conversazione, questi:

• [3.8.4/H-1-1]* DEVE visualizzare le notifiche delle conversazioni prima di quelle che non riguardano le conversazioni, ad eccezione delle notifiche dei servizi in primo piano in corso e delle notifiche importance:high.

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

• [3.8.10/H-1-1] DEVE visualizzare le notifiche della schermata di blocco, incluso il modello di notifica dei contenuti multimediali.

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

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

Se le implementazioni dei dispositivi portatili includono il supporto per le API ControlsProviderService e Control e consentono ad applicazioni di terze parti di pubblicare controlli dei dispositivi, questi:

• [3.8.16/H-1-1] DEVE dichiarare il flag della funzionalità android.software.controls e impostarlo su true.
• [3.8.16/H-1-2] DEVE offrire agli utenti la possibilità di aggiungere, modificare, selezionare e utilizzare i controlli dei dispositivi preferiti dall'utente dai controlli registrati dalle applicazioni di terze parti tramite le API ControlsProviderService e Control.
• [3.8.16/H-1-3] DEVE fornire l'accesso a questo invito dell'utente entro tre interazioni da un Avvio app predefinito.

• [3.8.16/H-1-4] DEVE visualizzare con precisione nell'invito dell'utente il nome e l'icona di ogni app di terze parti che fornisce i controlli tramite l'API ControlsProviderService nonché eventuali campi specificati forniti dalle API Control.

• [3.8.16/H-1-5] DEVE offrire agli utenti la possibilità di disattivare i controlli dei dispositivi banali per l'autorizzazione designati per l'app dai controlli registrati dalle applicazioni di terze parti tramite l'API ControlsProviderService e Control Control.isAuthRequired.

Crea nuovi requisiti

• [3.8.16/H-1-6] Le implementazioni dei dispositivi DEVONO mostrare con precisione l'invito all'utente come segue:
  • Se il dispositivo ha impostato config_supportsMultiWindow=true e l'app dichiara i metadati META_DATA_PANEL_ACTIVITY nella dichiarazione ControlsProviderService, incluso il valore ComponentName di un'attività valida (come definita dall'API), l'app DEVE incorporare detta attività in questa offerta utente.
  • Se l'app non dichiara metadati META_DATA_PANEL_ACTIVITY, DEVE visualizzare i campi specificati come forniti dall'API ControlsProviderService così come eventuali campi specificati forniti dalle API Controllo.
• [3.8.16/H-1-7] Se l'app dichiara i metadati META_DATA_PANEL_ACTIVITY, DEVE passare il valore dell'impostazione definita in [3.8.16/H-1-5] utilizzando EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS quando si avvia l'attività incorporata.

Termina nuovi requisiti

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

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

Se le implementazioni dei dispositivi portatili non vengono eseguite in modalità di blocco e i contenuti vengono copiati negli appunti:

• [3.8.17/H-1-1] DEVE presentare una conferma all'utente che i dati sono stati copiati negli appunti (ad es. una miniatura o un avviso di "Contenuto copiato"). Inoltre, includi qui un'indicazione se i dati degli appunti verranno sincronizzati tra i dispositivi.

Implementazioni di dispositivi portatili:

• [3.10/H-0-1] DEVE supportare servizi di accessibilità di terze parti.
• [3.10/H-SR-1] È VIVAMENTE CONSIGLIATO di precaricare sul dispositivo i servizi di accessibilità paragonabili o superiori a quelli dei servizi di accessibilità Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato), come fornito 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] È VIVAMENTE CONSIGLIATO di includere un motore TTS che supporti le lingue disponibili sul dispositivo.
• [3.13/H-SR-1] È VIVAMENTE CONSIGLIATO di includere un componente UI per le Impostazioni rapide.

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

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

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 Home DEVE essere non superiore a 32 dp di altezza dalla parte inferiore dello schermo.

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

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

Se le implementazioni dei dispositivi portatili supportano una schermata di blocco sicura e hanno a disposizione più di 2 GB di memoria per il kernel e lo spazio utente:

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

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

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

• [3.2.3.1/ H-1-1] DEVE avere un'attività che gestisce l'intent Settings#ACTION_SETTINGS_YOUR_DEEP_LINK_ACTIVITY quando è attiva la funzionalità divisa. 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_YOURDED_DEEP_LINK_INTENT_URI.

Crea nuovi requisiti

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

• [7.4.1.2/H-0-1] DEVE dichiarare il flag della funzionalità android.software.telecom.
• [7.4.1.2/H-0-2] DEVE implementare il framework per le telecomunicazioni.

Termina nuovi requisiti

2.2.4. Prestazioni e potenza

• [8.1/H-0-1] Latenza fotogrammi coerente. Una latenza di frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più 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 di elenco, come definito dalla suite per i test di compatibilità Android, in meno di 36 secondi.
• [8.1/H-0-3] Cambio di attività. Dopo aver avviato più applicazioni, il riavvio di un'applicazione già in esecuzione dopo l'avvio DEVE richiedere meno di un secondo.

Implementazioni di dispositivi portatili:

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

Se le implementazioni dei dispositivi portatili includono funzionalità per migliorare la gestione dell'alimentazione dei dispositivi incluse in AOSP o estendere le funzionalità incluse in AOSP, questi:

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

Implementazioni di dispositivi portatili:

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

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

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

Implementazioni di dispositivi portatili:

• [8.5/H-0-1] DEVE fornire l'affdenza dell'utente nel menu Impostazioni per visualizzare tutte le app con servizi in primo piano attivi o i job avviati dall'utente, inclusa la durata di ciascuno di questi servizi da quando è stato avviato come descritto nel documento SDK. e la possibilità di arrestare un'app che esegue un servizio in primo piano o un'app che esegue un job in primo piano avviato dall'utente.
  • Alcune app POTREBBERO essere esentate dall'interruzione o dall'elenco in un invito all'utente come descritto nel documento SDK.

Crea nuovi requisiti

• [8.5/H-0-2]DEVE fornire un'invito all'utente per arrestare un'app che esegue un servizio in primo piano o un job avviato dall'utente.

Termina nuovi requisiti

2.2.5. Modello di sicurezza

Implementazioni di 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 sull'utilizzo tramite l'autorizzazione android.permission.PACKAGE_USAGE_STATS e fornire un meccanismo accessibile all'utente per concedere o revocare l'accesso a tali app in risposta all'intento android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Crea nuovi requisiti

Se le implementazioni dei dispositivi dichiarano il supporto per android.hardware.telephony:

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

Termina nuovi requisiti

Implementazioni di dispositivi portatili:

• [9.11/H-0-2] DEVE eseguire il backup dell'implementazione dell'archivio chiavi con un ambiente di esecuzione isolato.
• [9.11/H-0-3] DEVE avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni di hash della famiglia MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema dell'archivio chiavi Android in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA. L'upstream Android Open Source Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura esaminata da terze parti di un corretto isolamento basato su hypervisor sono opzioni alternative.
• [9.11/H-0-4] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere archiviate in un modo che consenta solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. L'upstream Android Open Source Project fornisce Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
• [9.11/H-0-5] DEVE supportare l'attestazione della chiave in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in un hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise tra un numero sufficientemente elevato di dispositivi da impedire che vengano utilizzate come identificatori del dispositivo. 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, POTREBBE essere utilizzata una chiave diversa ogni 100.000 unità.

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

Quando le implementazioni dei dispositivi portatili supportano una schermata di blocco sicura, queste:

• [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 allo stato di blocco, della durata massima di 15 secondi.
• [9.11/H-1-2] DEVE fornire l'invito all'utente per nascondere le notifiche e disabilitare tutte le forme di autenticazione, ad eccezione dell'autenticazione principale descritta nella sezione 9.11.1 Schermata di blocco sicura. L'AOSP soddisfa i requisiti come modalità di blocco.

Crea nuovi requisiti

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

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

Termina nuovi requisiti

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

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

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

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

Crea nuovi requisiti

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

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

Termina nuovi requisiti

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

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

• [9.8/H-1-1] DEVE assicurarsi che il servizio di rilevamento hotword possa trasmettere dati soltanto al sistema, ContentCaptureService, o al servizio di riconoscimento vocale sul dispositivo creato da SpeechRecognizer#createOnDeviceSpeechRecognizer().
• [9.8/H-1-2] DEVE assicurarsi che il servizio di rilevamento hotword possa trasmettere solo i dati audio del microfono o i dati da esso derivati al server di sistema tramite l'API HotwordDetectionService o a ContentCaptureService tramite l'API ContentCaptureManager.
• [9.8/H-1-3] NON DEVE fornire un audio del microfono superiore a 30 secondi per una singola richiesta attivata dall'hardware al servizio di rilevamento hotword.
• [9.8/H-1-4] NON DEVE fornire audio microfono con buffer più vecchio di 8 secondi per una richiesta individuale al servizio di rilevamento hotword.
• [9.8/H-1-5] NON DEVE fornire audio del microfono con buffer più vecchio di 30 secondi al servizio di interazione vocale o a entità simili.
• [9.8/H-1-6] NON DEVE consentire la trasmissione di più di 100 byte di dati dal servizio di rilevamento hotword su ogni risultato della hotword con successo, ad eccezione dei dati audio trasmessi attraverso HotwordAudioStream.
• [9.8/H-1-7] NON DEVE consentire la trasmissione di più di 5 bit di dati dal servizio di rilevamento hotword per ogni risultato negativo di una hotword.
• [9.8/H-1-8] DEVE consentire la trasmissione di dati dal servizio di rilevamento hotword solo su una richiesta di convalida 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 DEVE apparire nell'interfaccia utente dei dati quantitativi sull'utilizzo del microfono da parte del servizio di rilevamento hotword.
• [9.8/H-1-11] DEVE registrare il numero di byte inclusi in ogni trasmissione dal servizio di rilevamento della hotword per consentire l'ispezione 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 hotword per consentire l'esaminabilità per i ricercatori della sicurezza.
• [9.8/H-1-14] DEVE visualizzare l'indicatore del microfono, come descritto nella sezione 9.8.2, quando viene trasmesso un risultato della hotword con esito positivo al servizio di interazione vocale o a un'entità simile.

Crea nuovi requisiti

• [9.8/H-1-15] DEVE garantire che gli stream audio forniti con risultati hotword successivi siano trasmessi in modo unidirezionale dal servizio di rilevamento hotword al servizio di interazione vocale.

Termina nuovi requisiti

• [9.8/H-SR-1] È VIVAMENTE CONSIGLIATO di informare gli utenti prima di impostare un'applicazione come fornitore del servizio di rilevamento hotword.
• [9.8/H-SR-2] È VIVAMENTE CONSIGLIATO di non consentire la trasmissione di dati non strutturati dal servizio di rilevamento hotword.
• [9.8/H-SR-3] È VIVAMENTE CONSIGLIATO di riavviare il processo che ospita il servizio di rilevamento hotword almeno una volta ogni ora o ogni 30 eventi di trigger hardware, a seconda dell'evento che si verifica per primo.

Se le implementazioni del dispositivo includono un'applicazione che utilizza l'API di sistema HotwordDetectionService o un meccanismo simile per il rilevamento della hotword senza indicazioni sull'utilizzo del microfono, l'applicazione:

• [9.8/H-2-1] DEVE fornire all'utente un avviso esplicito per ogni frase hotword supportata.
• [9.8/H-2-2] NON DEVE conservare i dati audio non elaborati, o i dati da essi derivanti, tramite il servizio di rilevamento hotword.
• [9.8/H-2-3] NON DEVE trasmettere dal servizio di rilevamento hotword, dati audio, dati che possono essere utilizzati per ricostruire (completamente o parzialmente) l'audio o contenuti audio non correlati alla hotword stessa, ad eccezione del ContentCaptureService o del servizio di riconoscimento vocale sul dispositivo.

Crea nuovi requisiti

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

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

Termina nuovi requisiti

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

• [9.8.2/H-4-1] DEVE visualizzare l'indicatore del microfono quando un'app accede ai dati audio dal microfono, ma non quando il microfono è accessibile solo da HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService o dalle app che hanno i ruoli indicati nella sezione 9.1 con identificatore CDD [C-4-X].
• [9.8.2/H-4-2] DEVE visualizzare 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 portatili dichiarano android.hardware.camera.any:

• [9.8.2/H-5-1] DEVE visualizzare l'indicatore della fotocamera quando un'app accede ai dati in diretta della videocamera, ma non quando la videocamera viene accessibile solo dalle app che hanno i ruoli indicati nella sezione 9.1 con identificatore CDD [C-4-X].
• [9.8.2/H-5-2] DEVONO visualizzare le app recenti e attive che utilizzano la fotocamera come restituiti da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.

2.2.6. Compatibilità degli strumenti e delle opzioni per sviluppatori

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

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

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

• Perfetto
  • [6.1/H-0-2]* DEVE esporre un file binario /system/bin/perfetto all'utente shell quale cmdline rispetta la documentazione perfetta.
  • [6.1/H-0-3]* Il programma binario perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
  • [6.1/H-0-4]* Il binario perfetto DEVE scrivere come output una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
  • [6.1/H-0-5]* DEVE fornire, tramite il perfetto binario, almeno le origini dati descritte nella documentazione perfetta.
  • [6.1/H-0-6]* Il daemon tracciato perfetto DEVE essere abilitato per impostazione predefinita (proprietà di sistema persist.traced.enable).

2.2.7. Classe prestazioni contenuti multimediali portatili

Consulta la Sezione 7.11 per la definizione della classe di prestazioni dei media.

2.2.7.1. Contenuti multimediali

Se le implementazioni dei dispositivi portatili restituiscono android.os.Build.VERSION_CODES.T per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

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

Crea nuovi requisiti

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

• [5.1/H-1-1] DEVE pubblicizzare il numero massimo di sessioni di decoder video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-2] DEVE supportare 6 istanze di sessioni di decodifica video hardware a 8 bit (SDR) (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 3 sessioni a risoluzione 1080p a 30 fps e 3 sessioni a 4K di risoluzione a 30 fps, a meno che non sia AV1. I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30 f/s.
• [5.1/H-1-3] DEVE pubblicizzare il numero massimo di sessioni di codificatore video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-4] DEVE supportare 6 istanze di sessioni del codificatore video hardware a 8 bit (SDR) (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 4 sessioni a risoluzione 1080p a 30 f/s e 2 sessioni a 4K di risoluzione a 30 fps, a meno che I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30 f/s.
• [5.1/H-1-5] DEVE pubblicizzare il numero massimo di sessioni di codifica e decodifica video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] DEVE supportare 6 istanze di sessioni di decodificatore video hardware a 8 bit (SDR) e di codificatore video hardware (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 3 sessioni a risoluzione 4K a 30 f/s (tranne AV1), di cui al massimo 2 sessioni encoder e 1 sessione encoder. I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30 f/s.
• [5.1/H-1-19] DEVE supportare 3 istanze del decodificatore video hardware a 10 bit (HDR) e sessioni del codificatore video hardware (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a una risoluzione di 4K a 30 f/s (a meno che AV1) di cui al massimo una sessione encoder configurata per un input AV1 La generazione di metadati HDR da parte dell'encoder non è necessaria se la codifica dalla superficie GL. Le sessioni codec AV1 sono necessarie solo per supportare la risoluzione a 1080p anche se questo requisito prevede la risoluzione 4K.
• [5.1/H-1-7] DEVE avere una latenza di inizializzazione del codec di 40 ms o inferiore per una sessione di codifica video a 1080p o inferiore per tutti i codificatori video hardware sotto carico. "Carica qui" è una sessione simultanea di transcodifica solo video da 1080p a 720p che utilizza codec video hardware insieme all'inizializzazione della registrazione audio-video a 1080p. Per il codec Dolby Vision, la latenza di inizializzazione del codec DEVE essere pari o inferiore a 50 ms.
• [5.1/H-1-8] DEVE avere una latenza di inizializzazione del codec di 30 ms o inferiore per una sessione di codifica audio con velocità in bit a 128 Kbps o inferiore per tutti i codificatori audio sotto carico. "Carica qui" è una sessione simultanea di transcodifica solo video da 1080p a 720p che utilizza codec video hardware insieme all'inizializzazione della registrazione audio-video a 1080p.
• [5.1/H-1-9] DEVE supportare 2 istanze di sessioni di decodifica video hardware sicure (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a risoluzione 4K a 30 fps (a meno che AV1) per contenuti HDR a 8 bit (SDR) e HDR a 10 bit. Le sessioni codec AV1 sono necessarie solo per supportare la risoluzione a 1080p anche se questo requisito prevede la risoluzione 4K.
• [5.1/H-1-10] DEVE supportare 3 istanze di sessioni di decodificatore video hardware non sicure insieme a 1 istanza di sessione di decodifica video hardware sicura (4 istanze in totale) (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 3 sessioni a risoluzione 4K a 0 f/s a 0 f/s e una sessione pn 0 f/s a 0 f/s a risoluzione sicura a 0 f/s a 0 f/s a 30 fps con risoluzione AV1 sicura Le sessioni codec AV1 sono necessarie solo per supportare la risoluzione a 1080p anche se questo requisito prevede la risoluzione 4K.
• [5.1/H-1-11] DEVE supportare un decodificatore sicuro per ogni decoder hardware AVC, HEVC, VP9 o AV1 sul dispositivo.
• [5.1/H-1-12] DEVE avere una latenza di inizializzazione del codec di 40 ms o inferiore per una sessione di decodifica video a 1080p o inferiore per tutti i decoder video hardware quando sotto carico. Per caricamento qui si intende una sessione di transcodifica simultanea da 1080p a 720p solo video che utilizza codec video hardware insieme all'inizializzazione della riproduzione audio-video a 1080p. Per il codec Dolby Vision, la latenza di inizializzazione del codec DEVE essere pari o inferiore a 50 ms.
• [5.1/H-1-13] DEVE avere una latenza di inizializzazione del codec di 30 ms o inferiore per una sessione di decodifica audio con velocità in bit inferiore o di 128 kbps per tutti i decoder audio quando sotto carico. "Carica qui" è una sessione simultanea di transcodifica solo video da 1080p a 720p che utilizza codec video hardware insieme all'inizializzazione della riproduzione audio-video a 1080p.
• [5.1/H-1-14] DEVE supportare il decodificatore hardware AV1, Main 10, Livello 4.1 e grana della pellicola.
• [5.1/H-1-15] DEVE avere almeno 1 decodificatore video hardware che supporti 4K60.
• [5.1/H-1-16] DEVE avere almeno un codificatore video hardware che supporta 4K60.
• [5.3/H-1-1] NON DEVE perdere più di 1 fotogramma in 10 secondi (ovvero meno dello 0,167% di riduzione dei fotogrammi) per una sessione video 4K a 60 f/s sotto carico.
• [5.3/H-1-2] NON DEVE perdere più di 1 fotogramma in 10 secondi durante una modifica della risoluzione video in una sessione video a 60 f/s sotto carico per una sessione in 4K.
• [5.6/H-1-1] DEVE avere una latenza tocco-to-tono di 80 millisecondi o inferiore utilizzando il test del tocco per tono di CTS Verifier.
• [5.6/H-1-2] DEVE avere una latenza audio di andata e ritorno di 80 millisecondi o meno su almeno un percorso dati supportato.
• [5.6/H-1-3] DEVE supportare un audio >=24 bit per l'uscita stereo su jack audio da 3,5 mm, se presente, e tramite audio USB, se supportato attraverso l'intero percorso dati per configurazioni a bassa latenza e streaming. Per la configurazione a bassa latenza, l'app deve utilizzare AAudio in modalità di callback a bassa latenza. Per la configurazione dello streaming, l'app deve utilizzare Java AudioTrack. Nelle configurazioni a bassa latenza e in streaming, il sink di output dell'HAL deve accettare AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT o AUDIO_FORMAT_PCM_FLOAT come formato di output di destinazione.
• [5.6/H-1-4] DEVE supportare dispositivi audio USB >=4 canali (utilizzati dai controller DJ per l'anteprima dei brani).
• [5.6/H-1-5] DEVE supportare dispositivi MIDI conformi alla classe e dichiarare il flag della funzionalità MIDI.
• [5.6/H-1-9] DEVE supportare almeno il missaggio a 12 canali. Ciò implica la possibilità di aprire un'AudioTrack con maschera a 7.1.4 canali e di suddividere correttamente tutti i canali in stereo o di eseguirne il downmix.
• [5.6/H-SR] È VIVAMENTE CONSIGLIATO di supportare il mix a 24 canali e almeno il supporto per le maschere 9.1.6 e 22.2.
• [5.7/H-1-2] DEVE supportare MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL con le seguenti funzionalità di decrittografia dei contenuti.

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

• [5.1/H-1-17] DEVE avere almeno un decodificatore di immagini hardware che supporti il profilo di base AVIF.
• [5.1/H-1-18] DEVE supportare il codificatore AV1 in grado di codificare fino a una risoluzione di 480p a 30 fps e 1 Mbps.
• [5.12/H-1-1] DEVE [5.12/H-SR] È vivamente consigliato supportare la funzionalità Feature_HdrEditing per tutti i codificatori hardware AV1 e HEVC presenti sul dispositivo.
• [5.12/H-1-2] DEVE supportare il formato colore RGBA_1010102 per tutti i codificatori hardware AV1 e HEVC presenti sul dispositivo.
• [5.12/H-1-3] DEVE pubblicizzare il supporto per l'estensione EXT_YUV_target per campionare da texture YUV sia a 8 che a 10 bit.
• [7.1.4/H-1-1] DEVE avere almeno 6 overlay hardware nell'unità di elaborazione del display (DPU), con almeno 2 di questi in grado di visualizzare contenuti video a 10 bit.

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

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

Termina nuovi requisiti

2.2.7.2. Fotocamera

Se le implementazioni dei dispositivi portatili restituiscono android.os.Build.VERSION_CODES.T per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• DEVE soddisfare i requisiti per i contenuti multimediali elencati nella sezione CDD 2.2.7.2 di Android 13.

Crea nuovi requisiti

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

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

Termina nuovi requisiti

2.2.7.3. Hardware

Se le implementazioni dei dispositivi portatili restituiscono android.os.Build.VERSION_CODES.T per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• DEVE soddisfare i requisiti per i contenuti multimediali elencati nella sezione CDD 2.2.7.3 di Android 13.

Crea nuovi requisiti

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

• [7.1.1.1/H-2-1] DEVE avere una risoluzione dello schermo di almeno 1080p.
• [7.1.1.3/H-2-1] DEVE avere una densità dello schermo di almeno 400 dpi.
• [7.1.1.3/H-3-1] DEVE avere un display HDR che supporti almeno 1000 nit in media.
• [7.6.1/H-2-1] DEVE avere almeno 8 GB di memoria fisica.

Termina nuovi requisiti

2.2.7.4. Esibizione

Se le implementazioni dei dispositivi portatili restituiscono android.os.Build.VERSION_CODES.T per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

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

Crea nuovi requisiti

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

• [8.2/H-1-1] DEVE garantire una prestazione di scrittura sequenziale di almeno 150 MB/s.
• [8.2/H-1-2] DEVE garantire una performance di scrittura casuale di almeno 10 MB/s.
• [8.2/H-1-3] DEVE garantire una prestazione di lettura sequenziale di almeno 250 MB/s.
• [8.2/H-1-4] DEVE garantire una prestazione di lettura casuale di almeno 100 MB/s.
• [8.2/H-1-5] DEVE garantire prestazioni di lettura e scrittura sequenziali parallele con prestazioni 2x in lettura e 1x scrittura di almeno 50 MB/s.

Termina nuovi requisiti

2.3. Requisiti per la televisione

Un dispositivo Android TV si riferisce a un'implementazione di dispositivi Android che è 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 3 metri di distanza ("interfaccia utente di 3 metri di distanza").

Le implementazioni sui dispositivi Android sono classificate come televisori 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 incorporato con una lunghezza diagonale superiore a 24 pollici OPPURE includere una porta di uscita video, ad esempio VGA, HDMI, DisplayPort o una porta wireless per il display.

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

2.3.1. Hardware

Implementazioni di dispositivi televisivi:

• [7.2.2/T-0-1] DEVE supportare D-pad.
• [7.2.3/T-0-1] DEVE fornire le funzioni A casa e Indietro.
• [7.2.3/T-0-2] DEVE inviare sia l'evento di pressione prolungata che normale 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] DEVE fornire un telecomando da cui gli utenti possano accedere agli input di navigazione non touch e tasti di navigazione principali.

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

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

Implementazioni di dispositivi televisivi:

• [7.4.3/T-0-1] DEVE supportare Bluetooth e Bluetooth LE.
• [7.6.1/T-0-1] DEVONO disporre di almeno 4 GB di spazio di archiviazione permanente per i dati privati dell'applicazione (ovvero 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 per una videocamera esterna che si collega tramite questa porta USB, ma non è necessariamente sempre collegata.

Se le implementazioni sui dispositivi TV sono a 32 bit:

• [7.6.1/T-1-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 896 MB se viene utilizzata una delle seguenti densità:

  • 400 dpi o superiore su schermi piccoli/normali
  • xhdpi o superiore su schermi di grandi dimensioni
  • tvdpi o superiore su schermi molto grandi

Se le implementazioni sui dispositivi TV sono a 64 bit:

• [7.6.1/T-2-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1280 MB se viene utilizzata una delle seguenti densità:

  • 400 dpi o superiore su schermi piccoli/normali
  • xhdpi o superiore su schermi di grandi dimensioni
  • tvdpi o superiore su schermi molto grandi

Tieni presente che il termine "memoria disponibile per il kernel e lo spazio utente" riportato sopra si riferisce allo spazio di memoria fornito oltre alla memoria già dedicata ai componenti hardware, come radio, video e così via, che non sono sotto il controllo del kernel sulle implementazioni dei dispositivi.

Implementazioni di dispositivi televisivi:

• [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 televisivi DEVONO supportare i seguenti formati di codifica e decodifica audio e renderli disponibili ad applicazioni di terze parti:

• [5.1/T-0-1] Profilo AAC MPEG-4 (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 televisivi DEVONO supportare i seguenti formati di codifica video e renderli disponibili ad applicazioni di terze parti:

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

Crea nuovi requisiti

• [5.2/T-0-3] AV1

Termina nuovi requisiti

Implementazioni di dispositivi televisivi:

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

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

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

Crea nuovi requisiti

• [5.3.2/T-0-7] AV1

Termina nuovi requisiti

Le implementazioni dei dispositivi televisivi DEVONO supportare la decodifica MPEG-2, come descritto nella Sezione 5.3.1, a frequenze fotogrammi e risoluzioni video standard fino a e tra cui:

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

Le implementazioni dei dispositivi televisivi 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 frame al secondo con Profilo di base
• [5.3.4/T-1-2] HD 1080p a 60 frame al secondo con profilo principale
• [5.3.4/T-1-3] HD 1080p a 60 frame al secondo con profilo alto livello 4.2

Le implementazioni di dispositivi televisivi con decodificatori hardware H.265 DEVONO supportare la decodifica H.265, come descritto nella sezione 5.3.5, a frequenze fotogrammi e risoluzioni standard per i video fino a un massimo di:

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

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

• [5.3.5/T-2-1] DEVE supportare il profilo di decodifica UHD a 60 frame al secondo con il profilo di livello principale di livello 5 principale.

Le implementazioni dei dispositivi televisivi 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 televisivi con decodificatori hardware VP9 DEVONO supportare la decodifica VP9, come descritto nella Sezione 5.3.7, a risoluzioni e frequenze fotogrammi video standard fino a:

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

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

• [5.3.7/T-2-1] DEVE supportare il profilo di decodifica UHD a 60 frame al secondo con profilo 0 (profondità di colore a 8 bit).
• [5.3.7/T-SR1] È VIVAMENTE CONSIGLIATO di supportare il profilo di decodifica UHD a 60 frame al secondo con il profilo 2 (profondità di colore a 10 bit).

Implementazioni di dispositivi televisivi:

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

Se le implementazioni dei televisori non dispongono di un display integrato, ma supportano un display esterno collegato tramite HDMI:

• [5.8/T-0-1] DEVE impostare la modalità di uscita HDMI alla massima risoluzione per il formato pixel scelto compatibile con la frequenza di aggiornamento di 50 Hz o 60 Hz per il display esterno, a seconda della frequenza di aggiornamento del video per la regione in cui il dispositivo è venduto. DEVE impostare la modalità di uscita HDMI per selezionare la risoluzione massima che può essere supportata con una frequenza di aggiornamento di 50 Hz o 60 Hz.
• [5.8/T-SR-1] È VIVAMENTE CONSIGLIATO di fornire un selettore della frequenza di aggiornamento HDMI configurabile dall'utente.
• [5.8] DOVREBBE impostare la frequenza di aggiornamento in modalità di uscita HDMI su 50 Hz o 60 Hz, a seconda della frequenza di aggiornamento del video per la regione in cui viene venduto il dispositivo.

Se le implementazioni dei televisori non dispongono di un display integrato, ma supportano un display esterno collegato tramite HDMI:

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

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

Implementazioni di dispositivi televisivi:

• [3/T-0-1] DEVE dichiarare le caratteristiche android.software.leanback e android.hardware.type.television.
• [3.2.3.1/T-0-1] DEVE precaricare una o più applicazioni o componenti di servizio con un gestore di intent, per tutti i pattern di filtro 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 Television supportano una schermata di blocco:

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

Implementazioni di dispositivi televisivi:

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

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

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

Implementazioni di dispositivi televisivi:

• [3.12/T-0-1] DEVE supportare il framework di input TV.

2.3.4. Prestazioni e potenza

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

Se le implementazioni dei dispositivi televisivi includono funzionalità per migliorare la gestione dell'alimentazione dei dispositivi incluse in AOSP o estendere le funzionalità incluse in AOSP, questi:

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

Se le implementazioni dei dispositivi televisivi non hanno una batteria:

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

Se le implementazioni dei dispositivi televisivi:

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

Implementazioni di dispositivi televisivi:

• [8.4/T-0-1] DEVE fornire un profilo di alimentazione per componente che definisca il valore del consumo attuale per ciascun 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] DEVE indicare tutti i valori di consumo energetico in milliampere-ore (mAh).
• [8.4/T-0-3] DEVE segnalare il consumo di energia della CPU in base all'UID di ogni processo. Il progetto open source Android soddisfa i requisiti tramite l'implementazione del modulo kernel uid_cputime.
• [8.4/T] DOVREBBE essere attribuita al componente hardware stesso se non è in grado di attribuire l'utilizzo dell'energia del componente hardware a un'applicazione.
• [8.4/T-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando shell adb shell dumpsys batterystats allo sviluppatore dell'app.

2.3.5. Modello di sicurezza

Implementazioni di dispositivi televisivi:

• [9/T-0-1] DEVE dichiarare la funzionalità android.hardware.security.model.compatible.
• [9.11/T-0-1] DEVE eseguire il backup dell'implementazione dell'archivio chiavi con un ambiente di esecuzione isolato.
• [9.11/T-0-2] DEVONO avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni di hash della famiglia MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema dell'archivio chiavi Android in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA. L'upstream Android Open Source Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura esaminata da terze parti di un corretto isolamento basato su hypervisor sono opzioni alternative.
• [9.11/T-0-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere archiviate in un modo che consenta solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. L'upstream Android Open Source Project fornisce Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
• [9.11/T-0-4] DEVE supportare l'attestazione della chiave in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita su hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise tra un numero sufficientemente elevato di dispositivi da impedire che vengano utilizzate come identificatori del dispositivo. 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, POTREBBE essere utilizzata una chiave diversa ogni 100.000 unità.

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

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

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

Se le implementazioni dei dispositivi televisivi includono più utenti e non viene dichiarato il flag funzionalità android.hardware.telephony, questi:

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

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

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

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

• [9.8.2/T-4-1] DEVE visualizzare l'indicatore del microfono quando un'app accede ai dati audio dal microfono, ma non quando il microfono è accessibile solo da HotwordDetectionService, SOURCE_HOTWORD, Content CaptureService o app che contengono i ruoli descritti nella Sezione 9.1 Autorizzazioni con identificatore CDD C-3-X].
• [9.8.2/T-4-2] Non DEVE nascondere l'indicatore del microfono per le app di sistema con interfacce utente visibili o interazione diretta dell'utente.

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

• [9.8.2/T-5-1] DEVE visualizzare l'indicatore della fotocamera quando un'app accede ai dati della videocamera in diretta, ma non quando la videocamera è accessibile solo alle app che hanno i ruoli descritti 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 dell'utente.

2.3.6. Compatibilità degli strumenti e delle opzioni per sviluppatori

Implementazioni di dispositivi televisivi:

• Perfetto
  • [6.1/T-0-1] DEVE esporre un file /system/bin/perfetto binario all'utente shell che cmdline rispetta la documentazione perfetta.
  • [6.1/T-0-2] Il binario perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
  • [6.1/T-0-3] Il binario perfetto DEVE scrivere come output una traccia protobuf conforme allo schema definito nella documentazione di Perfetto.
  • [6.1/T-0-4] DEVE fornire, tramite il programma binario perfetto, almeno le origini dati descritte nella documentazione del perfetto.

2.4. Requisiti dell'orologio

Un dispositivo Android Watch si riferisce all'implementazione di un dispositivo Android da portare a contatto con il corpo, magari al polso.

Le implementazioni sui dispositivi Android vengono classificate come smartwatch se soddisfano tutti i seguenti criteri:

• Utilizza uno schermo con una lunghezza diagonale fisica compresa tra 1,1 e 2,5 pollici.
• Disporre di un meccanismo da indossare sul corpo.

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

2.4.1. Hardware

Implementazioni dell'orologio:

• [7.1.1.1/W-0-1] DEVE avere uno schermo con dimensioni della diagonale fisica nell'intervallo da 1,1 a 2,5 pollici.

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

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

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

• [7.3.3/W-1-1] DEVE segnalare le misurazioni GNSS non appena vengono rilevate, anche se non è stata ancora segnalata una posizione calcolata dal GPS/GNSS.
• [7.3.3/W-1-2] DEVE indicare gli pseudointervalli e i tassi di pseudointervallo GNSS, che, in condizioni di cielo aperto dopo aver determinato la posizione, se fermo o in movimento con meno di 0, 2 metri al secondo quadrato di accelerazione, sono sufficienti per calcolare la posizione entro 20 metri e la velocità entro 0, 2 metri al secondo

Se le implementazioni dello smartwatch includono un giroscopio a 3 assi:

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

Implementazioni dell'orologio:

• [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 permanente disponibile per i dati privati dell'applicazione (ovvero partizione "/data").

• [7.6.1/W-0-2] DEVE avere almeno 416 MB di memoria disponibili 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. streaming

Implementazioni dell'orologio:

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

Implementazioni dell'orologio:

• [3.8.4/W-SR-1] È VIVAMENTE CONSIGLIATO di 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 servizi di accessibilità di terze parti.
• [3.10/W-SR-1] È VIVAMENTE CONSIGLIATO di precaricare sul dispositivo i servizi di accessibilità paragonabili o superiori a quelli dei servizi di accessibilità Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato), come previsto nel progetto open source TalkBack.

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

• [3.11/W-SR-1] È VIVAMENTE CONSIGLIATO di includere un motore TTS che supporti le lingue disponibili sul dispositivo.

• [3.11/W-0-1] DEVE supportare l'installazione di motori di sintesi vocale di terze parti.

2.4.4. Prestazioni e potenza

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

• [8.3/W-SR-1] È VIVAMENTE CONSIGLIATO per offrire agli utenti l'autorizzazione a visualizzare tutte le app esenti dalle modalità di standby delle app e di risparmio energetico della sospensione.
• [8.3/W-SR-2] È VIVAMENTE CONSIGLIATO di fornire all'utente l'invito ad attivare e disattivare la funzionalità di risparmio energetico.

Implementazioni dell'orologio:

• [8.4/W-0-1] DEVE fornire un profilo di alimentazione per componente che definisca il valore del consumo attuale 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] DEVE indicare tutti i valori di consumo energetica in milliampere-ore (mAh).
• [8.4/W-0-3] DEVE segnalare il consumo di energia della CPU in base all'UID di ogni processo. Il progetto open source Android soddisfa i requisiti tramite l'implementazione del modulo kernel uid_cputime.
• [8.4/W-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando shell adb shell dumpsys batterystats allo sviluppatore dell'app.
• [8.4/W] DOVREBBE essere attribuita al componente hardware stesso se non è possibile attribuire l'utilizzo dell'energia del componente hardware a un'applicazione.

2.4.5. Modello di sicurezza

Implementazioni dell'orologio:

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

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

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

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

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

Crea nuovi requisiti

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

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

Termina nuovi requisiti

2.5. Requisiti per il settore automobilistico

L'implementazione di Android Automotive si riferisce a un'unità principale del veicolo in cui Android è un sistema operativo per l'intero sistema e/o la funzionalità di infotainment o per intero.

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

• Sono incorporati come parte di un veicolo automobilistico o collegabili a un veicolo.
• Stai utilizzando uno schermo nella fila del sedile del conducente come display principale.

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

2.5.1. Hardware

Implementazioni di dispositivi nel settore auto e motori:

• [7.1.1.1/A-0-1] DEVE avere uno schermo con diagonale fisica di almeno 6 pollici.
• [7.1.1.1/A-0-2] DEVE avere un layout con dimensioni dello schermo di almeno 750 dp x 480 dp.
• [7.2.3/A-0-1] DEVE fornire la funzione Home e POTREBBE fornire le funzioni Indietro e Recenti.
• [7.2.3/A-0-2] DEVE inviare sia l'evento di pressione prolungata che normale della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano.
• [7.3/A-0-1] DEVE implementare e segnalare GEAR_SELECTION, NIGHT_MODE PERF_VEHICLE_SPEED e PARKING_BRAKE_ON.
• [7.3/A-0-2] Il valore del flag NIGHT_MODE DEVE essere coerente con la modalità giorno/notte della dashboard e DEVE essere basato sull'input del sensore di luce ambientale. Il sensore di luce ambientale sottostante POTREBBE essere uguale al Fotometro.
• [7.3/A-0-3] DEVE fornire un campo informativo aggiuntivo sul sensore TYPE_SENSOR_PLACEMENT come parte di SensorAdditionalInfo per ogni sensore fornito.
• [7.3/A-SR1] POTREBBE considerare la posizione unendo GPS/GNSS a sensori aggiuntivi. Se il valore per la località è considerato infondato, è VIVAMENTE CONSIGLIATO di implementare e segnalare i tipi di Sensor corrispondenti e/o gli ID proprietà veicolo utilizzati.

• [7.3/A-0-4] La Località richiesta tramite LocationManager#requestLocationUpdates() NON DEVE corrispondere alla mappa.

• [7.3.1/A-0-4] DEVE essere conforme al sistema di coordinate dei sensori dell'auto di Android.

• [7.3/A-SR-1] È StrongLY_CONSIGLIATA di includere un accelerometro e un giroscopio a 3 assi.

• [7.3/A-SR-2] È CONSIGLIATO implementare e segnalare TYPE_HEADING il sensore.

Se le implementazioni dei dispositivi Automotive supportano OpenGL ES 3.1:

• [7.1.4.1/A-0-1] DEVE dichiarare OpenGL ES 3.1 o versione successiva.
• [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 Auto e motori includono un accelerometro, questi:

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

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

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

Se le implementazioni dei dispositivi Auto e motori includono un accelerometro con meno di 3 assi, questi:

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

Se le implementazioni dei dispositivi Auto e motori includono un giroscopio, questi:

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

Se le implementazioni dei dispositivi Auto e motori includono un giroscopio a 3 assi, questi:

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

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

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

Se le implementazioni dei dispositivi Automotive includono un ricevitore GPS/GNSS, ma non includere la connettività dati basata sulla rete cellulare, questi:

• [7.3.3/A-3-1] DEVE determinare la posizione la prima volta che si accende il ricevitore GPS/GNSS o dopo più di 4 giorni entro 60 secondi.
• [7.3.3/A-3-2] DEVE soddisfare i criteri relativi alla prima correzione come descritto in 7.3.3/C-1-2 e 7.3.3/C-1-6 per tutte le altre richieste di posizione (ovvero richieste che non siano la prima volta in assoluto o dopo più di 4 giorni). Il requisito 7.3.3/C-1-2 viene generalmente soddisfatto nei veicoli privi di 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 capacità di calcolare il rischio per almeno 60 secondi con una precisione della posizione che soddisfa 7.3.3/C-1-3 o una combinazione di entrambe.

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

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

Implementazioni di dispositivi nel settore auto e motori:

• [7.4.3/A-0-1] DEVE supportare il Bluetooth e DOVREBBE supportare Bluetooth LE.
• [7.4.3/A-0-2] Le implementazioni di Android Automotive DEVONO supportare i seguenti profili Bluetooth:
  • Chiamate con Profilo in vivavoce (HFP).
  • Riproduzione di contenuti multimediali tramite Audio Distribution Profile (A2DP).
  • Controllo della riproduzione di contenuti multimediali tramite Remote Control Profile (AVRCP).
  • Condivisione dei contatti tramite il Phone Book Access Profile (PBAP).

• [7.4.3/A-SR-1] CONSIGLIATO VIVAMENTE per il supporto del profilo MAP (Message Access Profile).

• [7.4.5/A] DOVREBBE includere il supporto per la connettività dati basata sulla rete cellulare.

• [7.4.5/A] POSSONO utilizzare la costante NetworkCapabilities#NET_CAPABILITY_OEM_PAID dell'API di sistema per le reti che dovrebbero essere disponibili per le app di sistema.

Crea nuovi requisiti

Se le implementazioni dei dispositivi includono il supporto per le trasmissioni radio AM/FM ed espongono la funzionalità a qualsiasi applicazione, questi:

• [7.4.10/A-0-1] DEVE dichiarare il supporto per FEATURE_BROADCAST_RADIO.

Termina nuovi requisiti

Una videocamera per esterni è una videocamera che riproduce scene al di fuori dell'implementazione del dispositivo, come la fotocamera di retrovisione.

Implementazioni di dispositivi nel settore auto e motori:

• DEVE includere una o più videocamere per la vista esterna.

Se le implementazioni dei dispositivi nel settore auto e motori includono una videocamera per esterni, per una fotocamera di questo tipo:

• [7.5/A-1-1] NON DEVONO avere le fotocamere per esterni accessibili tramite le API Android Camera, a meno che non rispettino i requisiti principali della videocamera.

• [7.5/A-SR-1] È VIVAMENTE CONSIGLIATO di non ruotare o specchiare orizzontalmente l'anteprima della fotocamera.

• [7.5/A-SR-2] È VIVAMENTE CONSIGLIATO avere una risoluzione di almeno 1,3 megapixel.

• DEVONO avere hardware a fuoco fisso o EDOF (profondità di campo estesa).

• POTREBBE avere la messa a fuoco automatica hardware o software implementata nel driver della fotocamera.

Se le implementazioni dei dispositivi per auto e motori includono una o più telecamere di visione esterna e caricano il servizio Exterior View System (EVS), per una videocamera di questo tipo:

• [7.5/A-2-1] NON DEVE ruotare o rispecchiare orizzontalmente l'anteprima della fotocamera.

Implementazioni di dispositivi nel settore auto e motori:

• POTREBBERO includere una o più fotocamere disponibili per applicazioni di terze parti.

Se le implementazioni dei dispositivi per auto e motori includono almeno una fotocamera e la rendono disponibile ad applicazioni di terze parti, questi:

• [7.5/A-3-1] DEVE segnalare il flag funzionalità android.hardware.camera.any.
• [7.5/A-3-2] Non DEVE dichiarare la fotocamera come fotocamera di sistema.
• POTREBBERO supportare fotocamere esterne descritte nella sezione 7.5.3.
• POTREBBERO includere funzionalità (come la messa a fuoco automatica e così via) disponibili per le fotocamere posteriori come descritto nella sezione 7.5.1.

Crea nuovi requisiti

Per fotocamera posteriore si intende una videocamera rivolta verso il mondo che può essere collocata in qualsiasi punto del veicolo e rivolta verso l'esterno dell'abitacolo, ovvero immagini scene all'estremità della carrozzeria del veicolo, come la telecamera di retrovisione.

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

Implementazioni di dispositivi nel settore auto e motori:

• [7.5/A-SR-1] È VIVAMENTE CONSIGLIATO di includere una o più fotocamere rivolte verso il mondo.
• POTREBBERO includere una o più fotocamere rivolte all'utente.
• [7.5/A-SR-2] È VIVAMENTE CONSIGLIATO per supportare lo streaming simultaneo di più videocamere.

Se le implementazioni dei dispositivi per auto e motori includono almeno una fotocamera rivolta verso il mondo, per una fotocamera di questo tipo:

• [7.5/A-1-1] DEVE essere orientato in modo che la dimensione lunga della fotocamera sia allineata al piano X-Y degli assi dei sensori di Android Automotive.
• [7.5/A-SR-3] È VIVAMENTE CONSIGLIATO di avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
• [7.5/A-1-2] DEVE avere la fotocamera principale rivolta verso il mondo come quella con l'ID fotocamera più basso.

Se le implementazioni dei dispositivi per auto e motori includono almeno una fotocamera rivolta all'utente, per una fotocamera di questo tipo:

• [7.5/A-2-1] La fotocamera principale rivolta all'utente DEVE essere quella rivolta all'utente con l'ID fotocamera più basso.
• POTREBBERO essere orientati in modo che la dimensione lunga della fotocamera sia allineata al piano X-Y degli assi dei sensori di Android Automotive.

Se le implementazioni dei dispositivi Auto e motori includono una fotocamera accessibile tramite l'API android.hardware.Camera o android.hardware.camera2, questi:

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

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

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

Se le implementazioni dei dispositivi per auto e motori includono una o più fotocamere accessibili tramite il servizio Extended View System, per una fotocamera di questo tipo:

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

Se le implementazioni dei dispositivi per auto e motori includono una o più fotocamere accessibili tramite il servizio Extended View System e l'API android.hardware.Camera o android.hardware.Camera2, per una fotocamera di questo tipo:

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

Se le implementazioni dei dispositivi Automotive forniscono un'API fotocamera di proprietà, queste:

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

Termina nuovi requisiti

Implementazioni di dispositivi nel settore auto e motori:

• [7.6.1/A-0-1] DEVONO disporre di almeno 4 GB di spazio di archiviazione permanente per i dati privati dell'applicazione (ovvero partizione "/data").

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

Se le implementazioni dei dispositivi Automotive forniscono una memoria esterna condivisa tramite una parte della memoria interna non rimovibile,

• [7.6.1/A-SR-1] È VIVAMENTE CONSIGLIATO per ridurre l'overhead I/O sulle operazioni eseguite sulla memoria esterna, ad esempio utilizzando SDCardFS.

Se le implementazioni dei dispositivi Automotive 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 viene utilizzata una delle seguenti densità:

  • 280 dpi o meno su schermi piccoli/normali
  • ldpi o inferiore su schermi molto grandi
  • mdpi o inferiore su schermi grandi

• [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 grandi
  • mdpi o superiore su schermi molto grandi

• [7.6.1/A-2-3] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1280 MB se viene utilizzata una delle seguenti densità:

  • 400 dpi o superiore su schermi piccoli/normali
  • xhdpi o superiore su schermi di grandi dimensioni
  • tvdpi o superiore su schermi molto grandi

• [7.6.1/A-2-4] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1824 MB 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 molto grandi

Tieni presente che con "memoria disponibile per il kernel e lo spazio utente" si intende lo spazio di memoria fornito oltre alla memoria già dedicata ai componenti hardware, come radio, video e così via, che non sono sotto il controllo del kernel sulle implementazioni dei dispositivi.

Implementazioni di dispositivi nel settore auto e motori:

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

Implementazioni di dispositivi nel settore auto e motori:

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

Implementazioni di dispositivi nel settore 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 automobilistici DEVONO supportare i seguenti formati di codifica e decodifica audio e renderli disponibili ad applicazioni di terze parti:

• [5.1/A-0-1] Profilo AAC MPEG-4 (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 ad applicazioni di terze parti:

• [5.2/A-0-1] AVC H.264
• [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 ad applicazioni di terze parti:

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

Le implementazioni dei dispositivi per auto e motori sono VIVAMENTE CONSIGLIATE per supportare la seguente decodifica video:

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

2.5.3. streaming

Implementazioni di dispositivi nel settore auto e motori:

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

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

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

Se le implementazioni dei dispositivi Automotive forniscono un'API di proprietà utilizzando android.car.CarPropertyManager con android.car.VehiclePropertyIds, le implementazioni:

• [3/A-1-1] NON DEVE allegare privilegi speciali all'utilizzo di queste proprietà da parte delle applicazioni di sistema, né impedire alle applicazioni di terze parti di utilizzarle.
• [3/A-1-2] NON DEVE replicare una proprietà di un veicolo già esistente nell'SDK.

Implementazioni di dispositivi nel settore 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 automobilistiche.

• [3.2.3.1/A-0-1] DEVE precaricare una o più applicazioni o componenti di servizio con un gestore di intent, per tutti i pattern di filtro per 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.

Crea nuovi requisiti

• [3.8/A-0-1] NON DEVE consentire agli utenti secondari completi che non sono l'attuale utente in primo piano di avviare attività e avere accesso alla UI su qualsiasi display.

Termina nuovi requisiti

• [3.8.3/A-0-1] DEVONO visualizzare le notifiche che utilizzano l'API Notification.CarExtender quando richiesto da applicazioni di terze parti.

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

Se le implementazioni dei dispositivi Auto e motori includono un pulsante Premi per parlare:

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

Implementazioni di dispositivi nel settore auto e motori:

• [3.8.3.1/A-0-1] DEVE eseguire correttamente il rendering delle risorse come descritto nella documentazione dell'SDK Notifications on Automotive OS.
• [3.8.3.1/A-0-2] DEVE visualizzare RIPRODUZIONE e DISATTIVAZIONE AUDIO per le azioni di notifica al posto di quelle fornite tramite Notification.Builder.addAction()
• [3.8.3.1/A] DOVREBBE limitare l'uso di attività di gestione avanzate, come i controlli dei canali di notifica. POTREBBE utilizzare l'autorizzazione UI per applicazione per ridurre i controlli.

Se le implementazioni dei dispositivi Auto e motori supportano le proprietà HAL dell'utente:

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

Implementazioni di dispositivi nel settore auto e motori:

• [3.14/A-0-1] DEVE includere un framework dell'interfaccia utente per supportare 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 implicito CAR_INTENT_ACTION_MEDIA_TEMPLATE con l'extra CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] DEVE fornire un'invito per accedere all'attività di preferenza di un'applicazione multimediale, ma DEVE abilitarla solo quando le Limitazioni UX dell'auto non sono attive.
• [3.14/A-0-5] DEVE visualizzare i 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'invito 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 si visualizza la gerarchia di MediaBrowser.

Se le implementazioni dei dispositivi Auto e motori includono un'app Avvio app predefinita, queste:

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

Implementazioni di dispositivi nel settore auto e motori:

• [3.8/A] POTREBBE limitare la richiesta dell'applicazione di attivare la modalità a schermo intero come descritto in immersive documentation.
• [3.8/A] POTREBBE mantenere la barra di stato e la barra di navigazione sempre visibili.
• [3.8/A] POTREBBE limitare le richieste dell'applicazione di modifica dei colori alla base degli elementi UI di sistema, per garantire che questi elementi siano chiaramente visibili in ogni momento.

2.5.4. Prestazioni e potenza

Implementazioni di dispositivi nel settore auto e motori:

• [8.2/A-0-1] DEVE segnalare il numero di byte letti e scritti nello spazio di archiviazione permanente per l'UID di ciascun processo, in modo che le statistiche siano disponibili per gli sviluppatori tramite l'API di sistema android.car.storagemonitoring.CarStorageMonitoringManager. Il progetto open source Android soddisfa i requisiti tramite il modulo kernel uid_sys_stats.
• [8.3/A-1-3] DEVE supportare la modalità Garage.
• [8.3/A] DEVE essere in modalità garage per almeno 15 minuti dopo ogni guida, a meno che:
  • La batteria è scarica.
  • Nessun job inattivo pianificato.
  • Il conducente esce dalla modalità Garage.
• [8.4/A-0-1] DEVE fornire un profilo di alimentazione per componente che definisca il valore del consumo attuale per ciascun 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] DEVE indicare tutti i valori di consumo energetico in milliampere-ore (mAh).
• [8.4/A-0-3] DEVE segnalare il consumo di energia della CPU in base all'UID di ogni processo. Il progetto open source Android soddisfa i requisiti tramite l'implementazione del modulo kernel uid_cputime.
• [8.4/A] DOVREBBE essere attribuita al componente hardware stesso se non è in grado di attribuire l'utilizzo dell'energia del componente hardware a un'applicazione.
• [8.4/A-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando shell adb shell dumpsys batterystats allo sviluppatore dell'app.

2.5.5. Modello di sicurezza

Se le implementazioni dei dispositivi Auto e motori supportano più utenti, questi:

• [9.5/A-1-1] NON DEVE consentire agli utenti di interagire né passare all'utente di sistema headless, ad eccezione del provisioning dei dispositivi.
• [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.

Crea nuovi requisiti

Se le implementazioni dei dispositivi per auto e motori dichiarano android.hardware.microphone, :

• [9.8.2/A-1-1] DEVE visualizzare l'indicatore del microfono quando un'app accede ai dati audio dal microfono, ma non quando il microfono è accessibile solo da HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o dalle app che hanno i ruoli descritti nella sezione 9.1 con identificatore CDD [C-4-X].
• [9.8.2/A-1-2] Non DEVE nascondere l'indicatore del microfono per le app di sistema con interfacce utente visibili o interazione diretta dell'utente.
• [9.8.2/A-1-3] DEVE fornire all'utente l'autorizzazione ad attivare il microfono nell'app Impostazioni.

Termina nuovi requisiti

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

• [9.8.2/A-2-1] DEVE visualizzare l'indicatore della videocamera quando un'app accede ai dati della videocamera in diretta, ma non quando la videocamera viene accessibile solo da app che hanno i ruoli definiti descritti 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 dell'utente.

Crea nuovi requisiti

• [9.8.2/A-2-3] DEVE fornire all'utente l'autorizzazione ad attivare/disattivare la fotocamera nell'app Impostazioni.
• [9.8.2/A-2-4] DEVONO visualizzare le app recenti e attive che utilizzano la fotocamera come restituiti da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.

Termina nuovi requisiti

Implementazioni di dispositivi nel settore auto e motori:

• [9/A-0-1] DEVE dichiarare la funzionalità android.hardware.security.model.compatible.
• [9.11/A-0-1] DEVE eseguire il backup dell'implementazione dell'archivio chiavi con un ambiente di esecuzione isolato.
• [9.11/A-0-2] DEVONO avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni di hash della famiglia MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema dell'archivio chiavi Android in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA. L'upstream Android Open Source Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura esaminata da terze parti di un corretto isolamento basato su hypervisor sono opzioni alternative.
• [9.11/A-0-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere archiviate in un modo che consenta solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. L'upstream Android Open Source Project fornisce Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
• [9.11/A-0-4] DEVE supportare l'attestazione della chiave in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in un hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise tra un numero sufficientemente elevato di dispositivi da impedire che vengano utilizzate come identificatori del dispositivo. 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, POTREBBE essere utilizzata una chiave diversa ogni 100.000 unità.

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

Implementazioni di dispositivi nel settore auto e motori:

• [9.14/A-0-1] DEVONO limitare i messaggi provenienti dai sottosistemi dei veicoli del framework Android, ad esempio inserendo nella lista consentita i tipi di messaggi e le origini dei messaggi consentiti.
• [9.14/A-0-2] DEVE essere il watchdog dagli attacchi denial of service dal framework Android o da app di terze parti. Questo impedisce a software dannoso che inonda di traffico la rete dei veicoli, causando il malfunzionamento dei sottosistemi dei veicoli.

2.5.6. Compatibilità degli strumenti e delle opzioni per sviluppatori

Implementazioni di dispositivi nel settore auto e motori:

• Perfetto
  • [6.1/A-0-1] DEVE esporre un file /system/bin/perfetto binario all'utente shell che cmdline rispetta la documentazione perfetta.
  • [6.1/A-0-2] Il binario perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
  • [6.1/A-0-3] Il binario perfetto DEVE scrivere come output una traccia protobuf conforme allo schema definito nella documentazione di Perfetto.
  • [6.1/A-0-4] DEVE fornire, tramite il programma binario perfetto, almeno le origini dati descritte nella documentazione del perfetto.

2.6. Requisiti per i tablet

Un dispositivo tablet Android fa riferimento all'implementazione di un dispositivo Android che in genere soddisfa tutti i seguenti criteri:

• Si usa tenendole con entrambe le mani.
• Non ha una configurazione clamshell o convertibile.
• Le implementazioni della tastiera fisica utilizzate con il dispositivo si connettono tramite una connessione standard (ad es. USB, Bluetooth).

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

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

Le implementazioni dei tablet hanno requisiti simili a quelli delle implementazioni dei dispositivi portatili. Le eccezioni sono indicate con l'asterisco (*) e come riferimento.

2.6.1. Hardware

Giroscopio

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

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

Memoria e spazio di archiviazione minimi (Sezione 7.6.1)

Le densità dello schermo elencate per schermi piccoli/normali nei requisiti per dispositivi portatili 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, questi:

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

Modalità di realtà virtuale (Sezione 7.9.1)

Prestazioni elevate di realtà virtuale (Sezione 7.9.2)

I requisiti di realtà virtuale non si applicano ai tablet.

2.6.2. Modello di sicurezza

Chiavi e credenziali (Sezione 9.11)

Consulta la Sezione [9.11].

Se le implementazioni dei dispositivi tablet includono più utenti e non viene dichiarato il flag funzionalità android.hardware.telephony, questi:

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

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

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

2.6.2. streaming

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

3. streaming

3.1. Compatibilità delle API gestite

L'ambiente di esecuzione bytecode gestito Dalvik è il veicolo principale per le app Android. L'API (Application Programming Interface) di Android è l'insieme di interfacce della piattaforma Android esposte alle applicazioni in esecuzione nell'ambiente di runtime gestito.

Implementazioni dei dispositivi:

• [C-0-1] DEVE fornire implementazioni complete, inclusi tutti i comportamenti documentati, di qualsiasi API documentata esposta dall'SDK per Android o di qualsiasi API decorata con l'indicatore "@SystemApi" nel codice sorgente Android 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, alterare le interfacce o le firme delle API, deviare dal comportamento documentato o includere operazioni autonome, salvo laddove specificamente consentito dalla presente Definizione di compatibilità.

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

• [C-0-5] NON DEVE consentire ad app di terze parti di utilizzare interfacce non SDK, che sono definite come metodi e campi nei pacchetti di linguaggio Java presenti nel classpath 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 nei documenti dell'SDK e con i membri dei corsi privati e privati del pacchetto.

• [C-0-6] DEVE essere fornita con ogni interfaccia non SDK negli stessi elenchi con restrizioni forniti tramite i flag provvisori e della lista bloccata nel percorso di prebuilts/runtime/appcompat/hiddenapi-flags.csv per il ramo del livello API appropriato nell'AOSP.

• [C-0-7] DEVE supportare il meccanismo di aggiornamento dinamico della configurazione firmata per rimuovere le interfacce non SDK da un elenco limitato incorporando la configurazione firmata in qualsiasi APK, usando le chiavi pubbliche esistenti presenti in AOSP.

  Tuttavia:

  • MAGGIO, se un'API nascosta non è presente o implementata in modo diverso nell'implementazione del dispositivo, spostala nella lista bloccata o omettila da tutti gli elenchi con restrizioni.
  • MAGGIO, se nell'AOSP non esiste già un'API nascosta, aggiungila a uno degli elenchi con restrizioni.

Crea nuovi requisiti

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

Termina nuovi requisiti

3.1.1. Estensioni Android

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

Implementazioni di dispositivi Android:

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

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

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

3.1.2. Raccolta Android

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

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

L'implementazione AOSP soddisfa questi requisiti.

3.2. Compatibilità API Soft

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

3.2.1. Autorizzazioni

• [C-0-1] Gli utenti che implementano i dispositivi DEVONO supportare e applicare tutte le costanti di autorizzazione come documentato nella pagina di riferimento alle autorizzazioni. Tieni presente che nella sezione 9 sono elencati requisiti aggiuntivi relativi al modello di sicurezza di Android.

3.2.2. Parametri build

Le API Android includono una serie di costanti nella classe android.os.Build che descrivono il dispositivo corrente.

• [C-0-1] Per fornire valori coerenti e significativi nelle implementazioni dei dispositivi, la tabella riportata di seguito include ulteriori limitazioni sui formati di questi valori a cui le implementazioni dei dispositivi DEVONO essere conformi.

Parametro	Dettagli
VERSIONE.LANCIO	La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE contenere uno dei valori di stringa definiti nella sezione Stringhe di versione consentite per Android 14.
VERSIONE.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.
VERSIONE.INCREMENTALE	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 diverse build rese disponibili agli utenti finali. Un uso tipico di questo campo è indicare quale numero di build o identificatore di modifica del controllo del codice sorgente è stato utilizzato per generare la build. Il valore di questo campo DEVE essere codificabile in formato ASCII a 7 bit stampabile e corrispondere all'espressione regolare "^<!-- :\/~]+$".
DA TAVOLO	Un valore scelto dall'implementatore del dispositivo che identifica l'hardware interno specifico utilizzato dal dispositivo, in formato leggibile. Un possibile utilizzo di questo campo è indicare la revisione specifica della scheda che alimenta il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
BRAND	Un valore che riflette il nome del brand associato al dispositivo e che è noto agli utenti finali. DEVONO essere in formato leggibile e DEVONO rappresentare il produttore del dispositivo o il brand aziendale con cui il dispositivo viene commercializzato. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
SUPPORTO_ABIS	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle API native.
SUPPORTO_32_BIT_ABIS	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle API native.
SUPPORTATO_64_BIT_ABIS	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle API native.
CPU_ABI	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle 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à delle 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 la progettazione industriale del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Questo nome di dispositivo NON DEVE cambiare per tutta la durata del prodotto.
IMPRONTA	Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ecco alcuni esempi: acme/myproduct/ mydevice:14/LMYXX/3359:userdebug/test-keys L'impronta NON DEVE includere spazi vuoti. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit.
HARDWARE	Il nome dell'hardware (dalla riga di comando del kernel o da /proc). DEVE essere ragionevolmente leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
PRESENTATORE	Una stringa che identifica in modo univoco l'host su cui è stata basata la build, in formato leggibile. Non esistono requisiti sul formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere null o la stringa vuota ("").
ID	Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in formato leggibile. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere tra le build del software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
PRODUTTORE	Il nome commerciale del produttore di apparecchiature originali (OEM) del prodotto. Non esistono requisiti relativi al formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere null o con la stringa vuota (""). Questo campo NON DEVE cambiare per tutta la durata del prodotto.
SOC_PRODUTTORE	Il nome commerciale del produttore del sistema principale su chip (SOC) utilizzato nel prodotto. I dispositivi con lo stesso produttore SOC devono usare lo stesso valore costante. Chiedi al produttore del SOC la costante corretta da utilizzare. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit. DEVE corrispondere all'espressione regolare "^([0-9A-Za-z ]+)", NON DEVE iniziare o terminare con uno spazio vuoto e NON DEVE essere uguale a "sconosciuto". Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.
SOC_MODEL	Il nome del modello del sistema principale su un chip (SOC) utilizzato nel prodotto. I dispositivi con lo stesso modello SOC devono usare lo stesso valore costante. Chiedi al produttore del SOC la costante corretta da utilizzare. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^([0-9A-Za-z ._/+-]+)$", NON DEVE iniziare o terminare con uno spazio vuoto e NON DEVE essere uguale a "sconosciuto". 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. DEVE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non esistono requisiti relativi al formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere nullo o contenente la stringa vuota (""). Questo campo NON DEVE cambiare per tutta la durata del prodotto.
PRODOTTO	Un valore scelto dall'implementatore del dispositivo contenente il nome o il nome in codice di sviluppo del prodotto specifico (SKU) che DEVE essere univoco all'interno dello stesso brand. DEVE essere leggibile, ma non necessariamente per la visualizzazione da parte degli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Il nome di questo prodotto NON DEVE cambiare per tutta la durata del prodotto.
SKU ODM	Un valore facoltativo scelto dall'implementatore del dispositivo che contiene lo SKU (codice identificativo dell'articolo) utilizzato per monitorare configurazioni specifiche del dispositivo, ad esempio eventuali periferiche incluse nel dispositivo al momento della vendita. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "[0-9A-Za-z.,_-])"
SERIE	DEVE restituire "UNKNOWN".
TAG	Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che contraddistinguono 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 tipiche di firma della piattaforma Android: chiavi di rilascio, chiavi dev e chiavi di test.
DURATA	Un valore che rappresenta il timestamp di quando è avvenuta la build.
MACCHINA	Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni tipiche di runtime Android: user, userdebug o eng.
UTENTE	Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la build. Non esistono requisiti sul formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere null o la stringa vuota ("").
PATCH_DI_SICUREZZA	Un valore che indica il livello patch di sicurezza di una build. DEVE indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti nel Bollettino sulla sicurezza pubblica di Android designato. DEVE essere nel formato [AAAA-MM-GG], corrispondente a una stringa definita documentata nel Bollettino sulla sicurezza pubblica di Android o nell' Avviso sulla sicurezza di Android, ad esempio "2015-11-01".
Sistema operativo BASE	Un valore che rappresenta il parametro FINGERPRINT della build altrimenti identico a questa build, ad eccezione delle patch fornite nel Bollettino sulla sicurezza pubblica di Android. DEVE segnalare il valore corretto e, se la build di questo tipo non esiste, segnalare una stringa vuota ("").
BOOTLOADER	Un valore scelto dall'implementatore del dispositivo che identifica la versione del bootloader interno specifica 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 identifichi la versione specifica del radio/modem interno utilizzata nel dispositivo, in formato leggibile. Se un dispositivo non dispone di radio/modem interni, DEVE restituire NULL. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-,]+$".
getSerial()	DEVE (essere o restituire) un numero di serie hardware, che DEVE essere disponibile e univoco per tutti i dispositivi con lo stesso MODELLO e PRODUTTORE. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9]+$".

3.2.3. Compatibilità degli intent

3.2.3.1. Application Intent comuni

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

Implementazioni dei dispositivi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di precaricare una o più applicazioni o componenti di servizio con un gestore di intent per tutti i pattern di filtro per intent pubblici definiti dai seguenti intent di applicazione elencati qui e di 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 delle applicazioni obbligatori per ogni tipo di dispositivo.

3.2.3.2. Risoluzione dell'intenzione

• [C-0-1] Poiché Android è una piattaforma estensibile, le implementazioni dei dispositivi DEVONO consentire che ogni pattern di intent a cui si fa riferimento nella sezione 3.2.3.1, ad eccezione delle 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 attribuire privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema, né impedire alle applicazioni di terze parti di associarsi e assumere il controllo di questi pattern. Questo divieto include nello specifico, a titolo esemplificativo, la disattivazione dell'interfaccia utente "Selettore" 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 POTREBBERO fornire attività predefinite per pattern URI specifici (ad es. http://play.google.com) quando l'attività predefinita fornisce un attributo più specifico per l'URI dei dati. Ad esempio, un pattern di filtro per intent che specifica l'URI di dati "http://www.android.com" è più specifico del pattern di intent principale del browser per "http://".

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

• [C-0-4] DEVE tentare di convalidare eventuali filtri per intent eseguendo i passaggi di convalida definiti nella specifica Digital Asset Links, così come implementato dal gestore di pacchetti nel progetto open source Android a monte.
• [C-0-5] DEVE tentare la convalida dei filtri per intent durante l'installazione dell'applicazione e impostare tutti i filtri per intent URI convalidati come gestori di app predefiniti per i relativi URI.
• POTREBBE impostare filtri di intent specifici per gli URI come gestori di app predefiniti per i relativi URI, se la verifica viene completata correttamente, ma gli altri filtri URI candidati non superano la verifica. Se l'implementazione avviene in questo modo, DEVE fornire gli override appropriati dei pattern per URI all'utente nel menu delle impostazioni.
• DEVE fornire all'utente i controlli dei link alle app per ogni app nelle Impostazioni, come descritto di seguito:
  • [C-0-6] L'utente DEVE essere in grado di ignorare in modo olistico il comportamento predefinito dei link dell'app affinché un'app sia sempre aperta, sempre chiedere o mai aperta, che deve essere applicata allo stesso modo a tutti i filtri per intent dell'URI candidato.
  • [C-0-7] L'utente DEVE essere in grado di vedere un elenco dei filtri per intent dell'URI candidati.
  • L'implementazione del dispositivo POTREBBE offrire all'utente la possibilità di eseguire l'override di specifici filtri per intent di URI candidati che sono stati verificati correttamente, in base a un filtro per intent.
  • [C-0-8] L'implementazione del dispositivo DEVE fornire agli utenti la possibilità di visualizzare e sostituire specifici filtri per intent dell'URI candidato se l'implementazione del dispositivo consente ad alcuni filtri di intent di URI candidati di riuscire a completare la verifica, mentre altri potrebbero non riuscire.

3.2.3.3. Spazi dei nomi per intent

• [C-0-1] Le implementazioni dei dispositivi NON DEVONO includere componenti Android che rispettano i nuovi pattern di intent o di trasmissione di intent usando un'azione, una CATEGORIA o un'altra stringa chiave nello spazio dei nomi android.* o com.android.*.
• [C-0-2] Gli implementatori dei dispositivi NON DEVONO includere componenti Android che segnalino nuovi pattern di intent o di trasmissione di intent utilizzando un'AZIONE, una CATEGORIA o un'altra stringa chiave in uno spazio di pacchetto appartenente a un'altra organizzazione.
• [C-0-3] Gli utenti che implementano i dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent elencati nella sezione 3.2.3.1.
• Le implementazioni dei dispositivi POTREBBERO includere pattern di intent che utilizzano spazi dei nomi chiaramente e ovviamente associati alla propria organizzazione. Questo divieto è analogo a quello specificato per le classi di linguaggio Java nella sezione 3.6.

3.2.3.4. Intent di trasmissione

Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent per informarli dei cambiamenti avvenuti nell'ambiente hardware o software.

Implementazioni dei dispositivi:

• [C-0-1] DEVE trasmettere gli intent di trasmissione pubblici elencati qui in risposta agli eventi di sistema appropriati, come descritto nella documentazione dell'SDK. Tieni presente che questo requisito non è in conflitto con la sezione 3.5, poiché i limiti per le applicazioni in background sono descritti anche nella documentazione dell'SDK. Inoltre, alcuni intent di broadcast sono subordinati al supporto hardware. Se il dispositivo supporta l'hardware necessario, DEVONO trasmettere gli intent e fornire il comportamento in linea con la documentazione dell'SDK.

3.2.3.5. Application Intent condizionali

Android include impostazioni che consentono agli utenti di selezionare facilmente 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 di filtro per intent e i metodi API descritti di seguito nella documentazione dell'SDK.

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

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

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

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

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

  • DEVE utilizzare l'UI dell'app Telefono predefinita selezionata dall'utente per le chiamate in arrivo e in uscita, fatta eccezione per le chiamate di emergenza, che userebbero l'app Telefono preinstallata.

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

• [C-2-4] DEVE consentire l'accesso a android.telecom.CallRedirectionService per un'app che detiene il ruolo android.app.role.CALL_REDIRECTION.

• [C-2-5] DEVE fornire all'utente l'affetto per scegliere un'app con il ruolo di 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 SMS.

• [C-SR-1] È VIVAMENTE CONSIGLIATO di rispettare gli intent android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_button, android.intent.action.VIEW e android.intent.action.DIAL con un'applicazione dialer precaricata che possa gestire questi intent nell'SDK.fulfillment come descritto

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

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

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

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

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

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

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

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 all'utente per aggiungere e configurare metodi di input di terze parti in risposta all'intento di android.settings.INPUT_METHOD_SETTINGS.

Se le implementazioni del dispositivo supportano i servizi di accessibilità di terze parti, questi:

• [C-8-1] DEVE rispettare l'intento di android.settings.ACCESSIBILITY_SETTINGS di fornire un meccanismo accessibile dall'utente per abilitare e disabilitare i servizi di accessibilità di terze parti insieme ai servizi di accessibilità precaricati.

Se le implementazioni dei dispositivi includono il supporto di Connessione rapida Wi-Fi ed espongono la funzionalità ad app di terze parti, questi:

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

Se le implementazioni dei dispositivi offrono la modalità Risparmio dati, questi:

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

Se le implementazioni dei dispositivi non offrono la modalità Risparmio dati:

• [C-11-1] DEVE avere un'attività che gestisca l'intento di Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ma POTREBBE implementarla come soluzione indipendente.

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

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

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

• [C-13-1] DEVE rispettare l'intent android.app.action.ADD_DEVICE_ADMIN di richiamare una UI per portare l'utente ad aggiungere l'amministratore del dispositivo al sistema (o consentendogli 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 e android.app.action.START_ENCRYPTION e avere un'attività per fornire il completamento per questi intent qui come descritto.

Se le implementazioni dei dispositivi dichiarano il flag funzionalità android.software.autofill, questi:

• [C-14-1] DEVE implementare completamente le API AutofillService e AutofillManager e rispettare l'intento android.settings.REQUEST_SET_AUTOFILL_SERVICE di mostrare un menu di 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 del dispositivo includono un'app preinstallata o vuoi consentire ad app di terze parti di accedere alle statistiche sull'utilizzo, queste:

• I [C-SR-2] sono VIVAMENTE CONSIGLIATI fornire un meccanismo accessibile dall'utente per concedere o revocare l'accesso alle statistiche sull'utilizzo in risposta all'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS per le app che dichiarano l'autorizzazione android.permission.PACKAGE_USAGE_STATS.

Se le implementazioni dei dispositivi intendono impedire a qualsiasi app, comprese le app preinstallate, di accedere alle statistiche sull'utilizzo, queste:

• [C-15-1] DEVE avere comunque un'attività che gestisca il pattern di intent android.settings.ACTION_USAGE_ACCESS_SETTINGS ma DEVE implementarlo come autonomo, ovvero per avere un comportamento equivalente a quello di quando l'utente viene rifiutato per l'accesso.

Se le implementazioni dei dispositivi mostrano link alle attività specificate da CompilaService_passwordsActivity nelle Impostazioni o link alle password degli utenti tramite un meccanismo simile, questi:

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

Se le implementazioni del dispositivo supportano VoiceInteractionService e hanno installato contemporaneamente più di un'applicazione che utilizza questa API:

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

Se le implementazioni dei dispositivi segnalano la funzionalità android.hardware.audio.output, l'implementazione di questi elementi:

• [C-SR-3] È VIVAMENTE CONSIGLIATO di rispettare gli intent android.intent.action.TTS_SERVICE, android.Speech.tts.engine.INSTALL_TTS_DATA e android.Speech.tts.engine.GET_sample_TEXT hanno un'attività per fornire il completamento per questi intent, come descritto nell'SDK qui.

Android include il supporto per salvaschermo interattivi, precedentemente denominati sogni. I salvaschermo consentono agli utenti di interagire con le applicazioni quando un dispositivo collegato a una fonte di alimentazione è inattivo o agganciato a una base di ricarica. Implementazioni dei dispositivi:

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

Crea nuovi requisiti

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

• [C-19-1] DEVE implementare l'API intent NfcAdapter.ACTION_TRANSACTION_DETECTED (come "EVT_TRANSACTION" definita dalla specifica tecnica dell'associazione GSM TS.26 - NFC Handset requirements).

Termina nuovi requisiti

3.2.4. Attività su display secondari/multipli

Se le implementazioni del dispositivo consentono di avviare le normali attività Android su più di un display, questi:

• [C-1-1] DEVE impostare il flag di funzionalità android.software.activities_on_secondary_displays.
• [C-1-2] DEVE garantire la compatibilità delle API, analogamente a un'attività in esecuzione sul display principale.
• [C-1-3] DEVE indirizzare la nuova attività alla stessa visualizzazione dell'attività che l'ha avviata, quando la nuova attività viene lanciata senza specificare una visualizzazione di destinazione tramite l'API ActivityOptions.setLaunchDisplayId().
• [C-1-4] DEVE eliminare tutte le attività quando viene rimossa una visualizzazione con il flag Display.FLAG_PRIVATE.
• [C-1-5] DEVE nascondere in modo sicuro i contenuti su tutti gli schermi quando il dispositivo è bloccato con una schermata di blocco sicura, a meno che l'app non attivi la visualizzazione nella parte superiore della schermata di blocco usando l'API Activity#setShowWhenLocked().
• DEVE avere android.content.res.Configuration che corrisponde a quel display per poter essere visualizzato, funzionare correttamente e mantenere la compatibilità se un'attività viene avviata sul display secondario.

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

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

3.3. Compatibilità API native

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

• [C-SR-1] CONSIGLIATO VIVAMENTE di usare le implementazioni delle librerie elencate di seguito del progetto open source Android a monte.

3.3.1. Interfacce binarie dell'applicazione

Il bytecode Dalvik gestito può richiamare il codice nativo fornito nel file .apk dell'applicazione come file .so ELF compilato per l'architettura hardware del dispositivo appropriata. Poiché il codice nativo dipende fortemente dalla tecnologia del processore sottostante, Android definisce una serie di ABI (Application Binary Interface) 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 del codice in esecuzione nell'ambiente gestito per chiamare il codice nativo, utilizzando la semantica standard di Java Native Interface (JNI).
• [C-0-3] DEVE essere compatibile con l'origine (ovvero compatibile con l'intestazione) e compatibile con il file binario (per l'ABI) con ciascuna libreria obbligatoria nell'elenco seguente.
• [C-0-5] DEVE segnalare con precisione l'ABI (Application Binary Interface) nativa supportata dal dispositivo tramite i parametri android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, ognuno con un elenco separato da virgole di ABI ordinate dalla più alla meno preferita.

• [C-0-6] DEVE segnalare, tramite i parametri sopra riportati, un sottoinsieme del seguente elenco di ABI e NON DEVE segnalare le 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 tutte le librerie seguenti, fornendo le API native, alle app che includono codice nativo:

  • libaaudio.so (supporto audio nativo AAudio)
  • libamidi.so (supporto MIDI nativo, se la funzionalità android.software.midi è rivendicata come descritto nella Sezione 5.9)
  • libandroid.so (supporto nativo attività Android)
  • libc (libreria C)
  • libcamera2ndk.so
  • libdl (linker dinamico)
  • libEGL.so (gestione della superficie OpenGL nativa)
  • 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 native per i media)
  • libm (libreria matematica)
  • libneuralnetworks.so (API Neural Networks)
  • libOpenMAXAL.so (supporto di OpenMAX AL 1.0.1)
  • libOpenSLES.so (supporto audio OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (supporto minimo per C++)
  • libvulkan.so (Vulkan)
  • libz (compressione Zlib)
  • Interfaccia JNI

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

• [C-0-9] DEVE elencare le librerie non AOSP aggiuntive esposte direttamente ad app di terze parti in /vendor/etc/public.libraries.txt.

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

• [C-0-11] DEVE esportare tutti i simboli delle funzioni OpenGL ES 3.1 e Android Extension Pack, come definito nell'NDK, tramite la libreria libGLESv3.so. Tieni presente che sebbene tutti i simboli DEVONO essere presenti, la sezione 7.1.4.1 descrive in modo più dettagliato i requisiti relativi a quando è prevista l'implementazione completa di ciascuna funzione corrispondente.

• [C-0-12] DEVE esportare i simboli di funzione per i simboli principali della funzione Vulkan 1.0 Vulkan 1.1, nonché per le estensioni VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 tramite la libreria libvulkan.so. Tieni presente che, anche se DEVONO essere presenti tutti i simboli, la sezione 7.1.4.2 descrive in modo più dettagliato i requisiti relativi a quando è prevista la completa implementazione di ciascuna funzione corrispondente.

• DOVREBBE essere create utilizzando il codice sorgente e i file di intestazione disponibili nell'upstream Android Open Source Project.

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

3.3.2. Compatibilità del codice nativo ARM a 32 bit

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

• [C-3-1] DEVE supportare anche armeabi-v7a e riferire il relativo 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 altre ABI.

  • Features:, seguita da un elenco di eventuali funzionalità facoltative della CPU ARMv7 supportate dal dispositivo.
  • CPU architecture:, seguito da un numero intero che descrive l'architettura ARM più supportata 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 implementata su un'architettura ARMv8, tramite il supporto della CPU nativa o tramite l'emulazione software:

  • istruzioni per SWP e SWPB.
  • Operazioni con barriera CP15ISB, CP15DSB e CP15DMB.

• [C-2-3] DEVE includere il supporto per l'estensione SIMD avanzata (anche nota come NEON).

3.4. Compatibilità web

3.4.1. Compatibilità con WebView

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

• [C-1-1] DEVE segnalare android.software.webview.
• [C-1-2] DEVE 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 riportata da WebView DEVE essere nel 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) POTREBBE essere vuota, ma se non è vuota DEVE avere lo stesso valore di android.os.Build.MODEL.
  • "Build/$(BUILD)" POTREBBE 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 a monte.
  • 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 dell'URL remoto con un processo diverso dall'applicazione che crea un'istanza di WebView. In particolare, il processo del renderer separato DEVE avere privilegi inferiori, essere eseguito come un ID utente separato, non avere accesso alla directory dei dati dell'app, non avere accesso diretto alla rete e avere accesso soltanto ai servizi di sistema minimi richiesti tramite Binder. L'implementazione AOSP di WebView soddisfa questo requisito.

Tieni presente che se le implementazioni dei dispositivi 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 generale sul web, questi:

• [C-1-1] DEVE supportare ciascuna di queste API associate a HTML5:
  • operazione offline/cache dell'applicazione
  • Tag<video>
  • geolocalizzazione
• [C-1-2] DEVE supportare l'API Webstorage HTML5/W3C e DEVE supportare l'API IndexedDB HTML5/W3C. Tieni presente che, poiché gli enti degli standard di sviluppo web stanno passando a preferire IndexedDB rispetto all'archiviazione web, è previsto che IndexedDB diventerà un componente obbligatorio in una versione futura di Android.
• POTREBBE spedire una stringa dello user agent personalizzata nell'applicazione browser autonoma.
• DEVONO implementare il supporto per il maggior numero possibile di HTML5 sull'applicazione browser autonoma (in base all'applicazione browser WebKit upstream o a una sostituzione di terze parti).

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

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

3.5. Compatibilità di comportamento delle API

Implementazioni dei dispositivi:

• [C-0-9] DEVE garantire che la compatibilità comportamentale delle API venga applicata a tutte le app installate, a meno che non siano limitate come descritto nella Sezione 3.5.1.
• [C-0-10] NON DEVE implementare l'approccio della lista consentita che garantisce la compatibilità del comportamento delle API solo per le app selezionate dagli strumenti di implementazione dei dispositivi.

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

• [C-0-1] I dispositivi NON DEVONO modificare il comportamento o la semantica di un intent standard.
• [C-0-2] I dispositivi NON DEVONO alterare la semantica del ciclo di vita o del ciclo di vita di un particolare 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 alterare le limitazioni applicate alle applicazioni in background. Nello specifico, per le app in background:
  • [C-0-4] DEVONO interrompere l'esecuzione dei callback registrati dall'app per ricevere output da GnssMeasurement e GnssNavigationMessage.
  • [C-0-5] DEVONO limitare la frequenza degli aggiornamenti forniti all'app tramite la classe API LocationManager o il metodo WifiManager.startScan().
  • [C-0-6] Se l'app ha come target il livello API 25 o superiore, NON DEVONO consentire di registrare broadcast receiver per le trasmissioni implicite di 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 incluso nell'elenco di esenzione.
  • [C-0-7] Se l'app ha come target il livello API 25 o superiore, DEVONO interrompere i servizi in background dell'app, proprio come se l'app avesse chiamato il metodo stopSelf() dei servizi, a meno che l'app non venga 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 superiore, DEVONO rilasciare i wakelock dell'app.
• [C-0-11] I dispositivi DEVONO restituire i seguenti provider di sicurezza come primi sette valori di array dal metodo Security.getProviders(), nell'ordine specificato e con i nomi e le classi specificati (come restituiti da Provider.getName()), a meno che l'app non abbia modificato l'elenco tramite insertProviderAt() o removeProvider(). I dispositivi POSSONO restituire provider aggiuntivi dopo l'elenco di provider specificato di seguito.
  1. AndroidNSSP: android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider - sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCSolution - 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 parti significative della piattaforma per verificarne la compatibilità comportamentale, ma non tutte. È responsabilità dell'implementatore di garantire la compatibilità comportamentale con il progetto open source Android. Per questo motivo, gli implementatori dei dispositivi DEVONO utilizzare il codice sorgente disponibile tramite il progetto open source Android ove possibile, anziché reimplementare 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. modifica o limita i comportamenti delle API descritti nell'SDK) e questo meccanismo è più restrittivo del bucket standby delle app con restrizioni:

• [C-1-1] DEVE consentire all'utente di visualizzare l'elenco delle app con limitazioni.
• [C-1-2] DEVE fornire all'utente l'invito ad attivare / disattivare tutte queste limitazioni proprietarie su ogni app.

• [C-1-3] DEVE non applicare automaticamente queste limitazioni proprietarie senza prove di un comportamento inadeguato dell'integrità del sistema, ma POTREBBE applicare le limitazioni alle app quando vengono rilevati comportamenti non corretti dell'integrità del sistema come wakelock bloccati, servizi a lunga esecuzione e altri criteri. I criteri POTREBBERO essere determinati dagli strumenti di implementazione dei dispositivi, ma DEVONO essere correlati all'impatto dell'app sull'integrità del sistema. Altri criteri non strettamente correlati all'integrità del sistema, come la scarsa popolarità dell'app nel mercato, NON DEVONO essere utilizzati come criteri.

• [C-1-4] DEVE non applicare automaticamente queste limitazioni proprietarie alle app quando un utente ha disattivato manualmente le limitazioni per le app e POTREBBE suggerire all'utente di applicarle.

• [C-1-5] DEVE informare gli utenti se queste limitazioni proprietarie vengono applicate automaticamente a un'app. Tali informazioni DEVONO essere fornite nel periodo di 24 ore precedente l'applicazione di queste restrizioni 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 utilizzata esplicitamente dall'utente.

• [C-1-8] DEVONO sospendere queste limitazioni proprietarie su un'app ogni volta che un utente inizia a utilizzare esplicitamente l'app, rendendola la prima applicazione in primo piano.

• [C-1-10] DEVE fornire un documento o un sito web pubblico e chiaro che descriva come vengono applicate le limitazioni proprietarie. Questo documento o sito web DEVE essere collegabile dai documenti relativi all'SDK Android e DEVE includere:

  • Condizioni di attivazione per le restrizioni di proprietà.
  • Quali e come è possibile limitare un'app.
  • Come un'app può essere esente da queste limitazioni.
  • In che modo un'app può richiedere un'esenzione dalle limitazioni proprietarie, se supportano questa esenzione per le app che l'utente può installare.

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

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

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

3.5.2. Sospensione delle applicazioni

Se le implementazioni dei dispositivi includono App Hibernation inclusa in AOSP o estende la funzionalità inclusa in AOSP, allora:

• [C-1-1] DEVE soddisfare tutti i requisiti della sezione 3.5.1, ad eccezione di [C-1-6] e [C-1-3].
• [C-1-2] DEVE applicare la limitazione sull'app a un utente soltanto se esistono prove che l'utente non utilizzi l'app da un po' di tempo. Questa durata è VIVAMENTE CONSIGLIATA di un mese o più. L'utilizzo DEVE essere definito da un'interazione esplicita dell'utente tramite l'API UsageStats#getLastTimeVisibile() o qualsiasi altro fattore che possa far uscire un'app dallo stato di interruzione forzata, incluse associazioni di servizi, associazioni di fornitori di contenuti, trasmissioni esplicite e così via e che verrà monitorata da una nuova API UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] DEVE applicare limitazioni che interessano tutti gli utenti dei dispositivi soltanto quando esistono prove che il pacchetto non sia stato utilizzato da QUALSIASI utente per un determinato periodo di tempo. Questa durata è VIVAMENTE CONSIGLIATA di un mese o più.
• [C-1-4] NON DEVE far sì che l'app non sia in grado di rispondere a intent di attività, associazioni di servizi, richieste di fornitori di contenuti o trasmissioni esplicite.

La sospensione delle app in AOSP soddisfa i requisiti riportati sopra.

3.6. Spazi dei nomi API

Android segue le convenzioni dello spazio dei nomi dei pacchetti e delle classi definite dal linguaggio di programmazione Java. Per garantire la compatibilità con 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.*

Vale a dire:

• [C-0-1] NON DEVE modificare le API esposte pubblicamente sulla piattaforma Android cambiando le firme dei metodi o delle classi oppure rimuovendo le classi o i campi delle classi.
• [C-0-2] NON DEVE aggiungere elementi esposti pubblicamente (ad esempio classi o interfacce oppure campi o metodi a classi o interfacce esistenti) né alle API di test o di sistema negli spazi dei nomi sopra indicati. Un "elemento esposto pubblicamente" è qualsiasi costrutto che non è decorato con l'indicatore "@hide" come utilizzato nel codice sorgente 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 delle API esposte 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 o fare riferimento a un'altra organizzazione. Ad esempio, gli implementatori dei dispositivi NON DEVONO aggiungere API a com.google.* o a uno spazio dei nomi simile: solo Google può farlo. Analogamente, Google NON DEVE aggiungere API agli spazi dei nomi di altre aziende.
• [C-0-6] DEVONO essere pacchettizzati in una libreria condivisa di Android, in modo che soltanto le app che le usano esplicitamente (tramite il meccanismo <uses-library>) siano interessate dall'aumento dell'utilizzo della memoria da parte di queste API.

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

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

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

Tieni presente che le limitazioni di cui sopra corrispondono alle convenzioni standard per la denominazione delle API nel linguaggio di programmazione Java. Questa sezione mira semplicemente a rafforzare tali convenzioni e renderle vincolanti attraverso l'inclusione in questa definizione di compatibilità.

3.7. Compatibilità di runtime

Implementazioni dei dispositivi:

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

• [C-0-2] DEVE configurare i runtime Dalvik in modo da allocare la memoria in base alla piattaforma Android upstream e come specificato dalla tabella seguente. (Consulta la sezione 7.1.1 per le definizioni delle dimensioni e della densità dello schermo.)

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

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

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

Layout schermo	Densità schermo	Memoria minima delle applicazioni
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à con l'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 la sostituzione di Avvio applicazioni (schermata Home).

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

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

Se le implementazioni del dispositivo includono un'Avvio app predefinito che supporta il blocco delle scorciatoie in-app, queste:

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

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

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

Se le implementazioni del dispositivo implementano un'Avvio app predefinito che consente di accedere rapidamente alle scorciatoie aggiuntive fornite da app di terze parti tramite l'API ShortcutManager, questi:

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

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

• [C-5-1] DEVE rispettare il metodo API NotificationChannel.setShowBadge(). In altre parole, mostra un'invito visivo associata all'icona dell'app se il valore è impostato su true e non mostrare alcuno schema di badge dell'icona dell'app quando tutti i canali di notifica dell'app hanno impostato il valore su false.
• POTREBBERO eseguire l'override dei badge delle icone dell'app con il relativo schema di badge proprietario quando le applicazioni di terze parti indicano il supporto dello schema di badge di proprietà tramite l'uso di API di proprietà, ma DEVONO utilizzare le risorse e i valori forniti tramite le API dei badge di notifica descritte nell'SDK, come 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 se un utente le abilita esplicitamente (ad es. tramite Impostazioni o dal menu del selettore dello sfondo).

3.8.2. Widget

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

Se le implementazioni del dispositivo supportano i widget di app di terze parti, questi:

• [C-1-1] DEVE dichiarare il supporto per la funzionalità della piattaforma android.software.app_widgets.

• [C-1-2] DEVE includere il supporto integrato per AppWidgets ed esporre le caratteristiche dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere AppWidgets

• [C-1-3] DEVE essere in grado di visualizzare widget di 4 x 4 nella dimensione griglia standard. Per maggiori dettagli, consulta App Widget DesignGuidelines nella documentazione dell'SDK per Android.

• POSSONO supportare widget delle applicazioni nella schermata di blocco.

Se le implementazioni del dispositivo supportano i widget di app di terze parti e il blocco delle scorciatoie in-app, questi:

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

3.8.3. Notifiche

Android include API Notification e NotificationManager che consentono agli sviluppatori di app di terze parti di informare gli utenti di eventi importanti e attirare l'attenzione degli utenti utilizzando i componenti hardware (ad es. suono, vibrazione e luce) e le funzionalità software (ad es. area notifiche, barra di sistema) del dispositivo.

3.8.3.1. Presentazione delle notifiche

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

• [C-1-1] DEVE supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK e nella misura possibile con l'hardware di implementazione del dispositivo. Ad esempio, se l'implementazione di un dispositivo include una vibrazione, DEVE implementare correttamente le API di vibrazione. Se l'implementazione in un dispositivo è priva di hardware, le API corrispondenti DEVONO essere implementate come strumenti automatici. Questo comportamento è dettagliato nella sezione 7.
• [C-1-2] DEVE eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) fornite nelle API o nella guida di stile per le icone della barra di stato/di sistema, sebbene possano fornire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'implementazione open source di Android di riferimento.
• [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 un'invito all'utente per bloccare e modificare la notifica di una determinata app di terze parti per ogni canale e livello di pacchetto dell'app.
• [C-1-6] DEVE anche fornire un invito all'utente per visualizzare i canali di notifica eliminati.

• [C-1-7] DEVE visualizzare correttamente 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, comprese le icone fornite tramite android.app.Person in una conversazione di gruppo impostata tramite setGroupConversation.

• [C-SR-1] È VIVAMENTE CONSIGLIATO di fornire un'autorizzazione all'utente per controllare le notifiche esposte alle app a cui è stata concessa l'autorizzazione Listener di notifiche. La granularità DEVE essere necessaria per consentire all'utente di controllare per ciascun listener di notifiche i tipi di notifica che vengono trasmessi a questo listener. I tipi DEVONO includere le notifiche "conversazioni", "avvisi", "silenziose" e "importanti in corso".

• [C-SR-2] È VIVAMENTE CONSIGLIATO fornire un'invito agli utenti per specificare le app da escludere dalla notifica a uno specifico listener di notifiche.

• [C-SR-3] È VIVAMENTE CONSIGLIATO di mostrare automaticamente l'invito dell'utente per bloccare la notifica di una determinata app di terze parti per ogni canale e livello di pacchetto di app dopo che l'utente la chiude più volte.

• DEVONO supportare notifiche avanzate.

• DEVONO presentare alcune notifiche con priorità più alta come notifiche di avviso.

• DEVONO avere l'autorizzazione dell'utente a posticipare le notifiche.

• POTREBBERO gestire soltanto la visibilità e la tempistica in cui le app di terze parti possono informare gli utenti di eventi importanti per mitigare i problemi di sicurezza, come la distrazione della guida.

Android 11 introduce il supporto per le notifiche delle conversazioni, ovvero notifiche che utilizzano MessagingStyle e che fornisce un ID scorciatoia Persone pubblicato.

Implementazioni dei dispositivi:

• [C-SR-4] È VIVAMENTE CONSIGLIATO di raggruppare e visualizzare conversation notifications prima delle notifiche non relative alle conversazioni, ad eccezione delle notifiche di servizio in primo piano e di importance:high in corso.

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

• [C-SR-5] CONSIGLIATO VIVAMENTE di visualizzare questa conversazione sotto forma di bolla. L'implementazione di AOSP soddisfa questi requisiti con UI di sistema, impostazioni e Avvio app predefiniti.

Se le implementazioni dei dispositivi supportano le notifiche avanzate:

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

Le notifiche di avviso sono notifiche presentate all'utente non appena arrivano, indipendentemente dalla piattaforma su cui l'utente è attivo. Se le implementazioni del dispositivo supportano le notifiche in evidenza, questi:

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

3.8.3.2. Servizio listener di notifiche

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

Implementazioni dei dispositivi:

• [C-0-1] DEVE aggiornare in modo corretto e tempestivo le notifiche nella loro interezza in tutti i servizi listener installati e abilitati all'utente, compresi tutti i metadati allegati all'oggetto Notification.
• [C-0-2] DEVE rispettare la chiamata API snoozeNotification(), ignorare la notifica ed effettuare un callback dopo la durata di posticipo impostata nella chiamata API.

Se le implementazioni del dispositivo hanno l'autorizzazione a posticipare le notifiche, l'utente:

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

3.8.3.3. DND (Non disturbare) / Modalità prioritaria

Se le implementazioni dei dispositivi supportano la funzione DND (detta anche modalità Priorità), le implementazioni:

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

3.8.4. API Assist

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

Se le implementazioni del dispositivo supportano l'azione evento indiretto, questi:

• [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, mostra una luce bianca ai bordi dello schermo che supera o supera la durata e la luminosità dell'implementazione di Android Open Source Project.
  • Per l'app di assistenza preinstallata, fornire un'invito dell'utente a meno di due navigazioni lontano dal menu delle impostazioni dell'app di assistenza vocale e dell'assistente predefinita e condividere il contesto soltanto quando l'app di assistenza viene richiamata esplicitamente dall'utente tramite una hotword o l'input del tasto 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, ovvero l'app che implementa VoiceInteractionService, o un'attività che gestisce l'intent ACTION_ASSIST.

3.8.5. Avvisi e toast

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 utilizzare l'API del tipo di finestra TYPE_APPLICATION_OVERLAY per visualizzare le finestre di avviso come overlay su altre app.

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

• [C-1-1] DEVE fornire a un utente l'invito per impedire a un'app di visualizzare finestre di avviso che utilizzano TYPE_APPLICATION_OVERLAY. L'implementazione di AOSP soddisfa questo requisito grazie ai controlli nell'area notifiche.

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

3.8.6. Temi

Android offre i "temi" come meccanismo per applicare stili a un'intera attività o applicazione.

Android include una famiglia di temi "Holo" e "Material" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare l'aspetto del tema Holo come definito dall'SDK Android.

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

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

• [C-1-3] DEVE impostare la famiglia di caratteri "sans-Serif" su Roboto versione 2.x per i linguaggi supportati da Roboto oppure fornire un invito all'utente per modificare il carattere utilizzato per la famiglia di caratteri "sans-serif" in Roboto versione 2.x per le lingue supportate da Roboto.

• [C-1-4] DEVE generare tavolozze dinamiche dei toni dei colori 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 dinamiche delle tonalità dei colori utilizzando gli stili con temi a colori elencati nella documentazione di Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (vedi android.theme.customization.theme_styles), ossia TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD eMONOCHROMATIC.

  "Colore di origine" utilizzato per generare tavolozze dinamiche dei colori dei colori quando inviato con android.theme.customization.system_palette (come documentato in Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

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

  • DOVREBBE derivare dallo sfondo tramite com.android.systemui.monet.ColorScheme#getSeedColors, che fornisce più colori di origine validi tra cui sceglierne uno.

  • DEVE utilizzare il valore 0xFF1B6EF3 se nessuno dei colori forniti soddisfa il requisito per i colori di origine di cui sopra.

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

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

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

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

• [C-2-1] DEVE essere in bianco per le icone di stato del sistema (come 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 non richieda una barra di stato luminosa utilizzando il flag WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
• [C-2-2] Le implementazioni sui 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 luminosa.

3.8.7. Sfondi animati

Android definisce un tipo di componente, nonché l'API e il ciclo di vita corrispondenti, che consente 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 è in grado di eseguire tutti gli sfondi animati, senza limitazioni di funzionalità, a una frequenza fotogrammi ragionevole e senza effetti negativi su altre applicazioni. Se limitazioni dell'hardware causano l'arresto anomalo degli sfondi e/o delle applicazioni, il malfunzionamento, un consumo eccessivo di CPU o batteria o l'esecuzione a frequenze di fotogrammi inaccettabili inferiori, l'hardware non è in grado di eseguire sfondi animati. Ad esempio, alcuni sfondi animati potrebbero utilizzare un contesto OpenGL 2.0 o 3.x per eseguire il rendering dei contenuti. L'esecuzione dello sfondo animato non verrà eseguita in modo affidabile su hardware che non supporta più contesti OpenGL, perché l'utilizzo di sfondi animati di un contesto OpenGL potrebbe essere in conflitto con altre applicazioni che usano anche un contesto OpenGL.

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

Se le implementazioni dei dispositivi implementano gli sfondi animati, questi:

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

3.8.8. Cambio attività

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

Le implementazioni dei dispositivi, incluso il tasto di navigazione recente della funzione, come descritto nella sezione 7.2.3 POTREBBERO modificare l'interfaccia.

Se le implementazioni dei dispositivi, incluso il tasto di navigazione recente della funzione, come descritto nella sezione 7.2.3, modificano l'interfaccia:

• [C-1-1] DEVE supportare almeno 7 attività visualizzate.
• DEVE visualizzare almeno il titolo di 4 attività alla volta.

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

• DOVREBBE visualizzare il colore di evidenziazione, l'icona e il titolo dello schermo nei recenti.
• DEVONO mostrare un invito di chiusura ("x"), ma POTREBBE ritardarlo finché l'utente non interagisce con gli schermi.
• DEVI 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à multi-finestra schermo diviso, se supportata, quando viene premuto a lungo il tasto delle funzioni recenti.
• POTREBBE mostrare gli elementi recenti affiliati come un gruppo che si sposta insieme.
• [C-SR-1] Ti consigliamo vivamente di utilizzare l'interfaccia utente Android upstream (o un'interfaccia simile basata su miniature) per la schermata della panoramica.

3.8.9. Gestione degli input

Android include il supporto per Gestione del input e per editor dei 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 contenuti multimediali schermata di blocco

L'API Remote Control Client è stata ritirata da Android 5.0 a favore del Media Notification Template, che consente l'integrazione delle applicazioni multimediali con i controlli di riproduzione visualizzati nella schermata di blocco.

3.8.11. Salvaschermi (in precedenza Sogni)

Consulta la sezione 3.2.3.5 per le impostazioni che intendono configurare i salvaschermo.

3.8.12. Posizione

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

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

3.8.13. Unicode e Font

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

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

• [C-1-1] DEVE essere in grado di visualizzare questi caratteri emoji in glifo a colori.
• [C-1-2] DEVE includere il supporto di:
  • Carattere Roboto 2 di spessore diverso: Sans Serif-thin, Sans Serif-leggero, Sans Serif-medium, Sans Serif-Black, Sans Serif Condensed, Sans Serif-Luce Condensata per le lingue disponibili sul dispositivo.
  • Copertura completa di Unicode 7.0 in caratteri latini, greci e cirillici, inclusi gli intervalli Latin Extended A, B, C e D e tutti i glifi nel blocco dei simboli di valuta di Unicode 7.0.
• [C-1-3] NON DEVE rimuovere o modificare NotoColorEmoji.tff nell'immagine di sistema. (È consentito aggiungere un nuovo carattere emoji per sostituire l'emoji in NotoColorEmoji.tff)
• DEVONO supportare la tonalità della pelle e le diverse emoji per la famiglia, come specificato nello Unicode Technical Report n. 51.

Se le implementazioni dei dispositivi includono un IME, questi:

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

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

Se le implementazioni dei dispositivi includono il supporto per il 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 un carattere non conforme a Unicode è supportato sul dispositivo. Il carattere non compatibile con Unicode NON DEVE rimuovere o sovrascrivere il carattere Unicode.
• [C-2-3] DEVE eseguire il rendering del testo con carattere non conforme a Unicode SOLO SE è specificato un codice di lingua con codice di script Qaag (ad es. my-Qaag). Nessun altro codice di lingua o regione ISO (assegnato, non assegnato o riservato) può essere utilizzato per fare riferimento a un carattere non conforme Unicode per il Myanmar (Birmania). Gli sviluppatori di app e gli autori di pagine web possono specificare my-Qaag come codice lingua designato, come farebbero per qualsiasi altra lingua.

3.8.14. Multifinestre

Se le implementazioni dei dispositivi hanno la possibilità di visualizzare più attività contemporaneamente:

• [C-1-1] DEVE implementare queste modalità multi-finestra in conformità con i comportamenti dell'applicazione e le API descritti nella documentazione di supporto per la modalità multi-finestra per 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 formato libero se l'altezza dello schermo è inferiore a 440 dp e la larghezza dello schermo è inferiore a 440 dp.
• [C-1-4] Un'attività NON DEVE essere ridimensionata a una dimensione inferiore a 220 dp in modalità multi-finestra diverse da Picture in picture.
• Le implementazioni dei dispositivi con dimensioni dello schermo xlarge DEVONO supportare la modalità in formato libero.

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

• [C-2-2] DEVE ritagliare l'attività agganciata di una multi-finestra a schermo diviso, ma dovrebbe mostrarne del contenuto, se l'app Avvio app è la finestra con lo stato attivo.
• [C-2-3] DEVE rispettare i valori AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight dichiarati dell'applicazione Avvio app di terze parti e non sostituire questi valori nel corso della visualizzazione di alcuni contenuti dell'attività agganciata.

Se le implementazioni dei dispositivi supportano le modalità multi-finestra e Picture in picture:

• [C-3-1] DEVE avviare attività in modalità multi-finestra Picture in picture quando l'app è: * Livello API target 26 o superiore e dichiara android:supportsPictureInPicture * Livello API target 25 o inferiore e dichiara android:resizeableActivity e 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 un'invito all'utente per impedire la visualizzazione di un'app in modalità PIP; l'implementazione AOSP soddisfa questo requisito con i controlli nell'area notifiche.

• [C-3-6] DEVE allocare la seguente larghezza e altezza minime per la finestra PIP quando un'applicazione non dichiara alcun valore per AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight:

  • I dispositivi con il valore 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 il valore 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 display come descritto nel documento SDK. L'API DisplayCutout definisce un'area sul bordo del display che potrebbe non essere funzionante per un'applicazione a causa di un ritaglio del display o di un display curvo sui bordi.

Se le implementazioni dei dispositivi includono ritagli del display:

• [C-1-5] NON DEVE avere 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 display impostati dall'app tramite l'API WindowManager.LayoutParams come descritto nell'SDK.
• [C-1-4] DEVE segnalare i valori corretti per tutte le metriche di ritaglio definite nell'API DisplayCutout.

3.8.16. Controllo dei dispositivi

Android include API ControlsProviderService e Control per consentire alle applicazioni di terze parti di pubblicare controlli dei dispositivi al fine di ottenere rapidamente stato e azioni per gli utenti.

Consulta la Sezione 2_2_3 per i requisiti specifici del dispositivo.

3.8.17. Appunti

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE inviare i dati degli appunti ad alcun componente, attività, servizio o attraverso qualsiasi connessione di rete, senza un'azione esplicita dell'utente (ad esempio, premendo un pulsante sull'overlay), ad eccezione dei servizi menzionati in 9.8.6 Acquisizione di contenuti e Ricerca di app.

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

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

L'implementazione del riferimento AOSP soddisfa questi requisiti per gli appunti.

3,9 Amministrazione dispositivo

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

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

• [C-1-1] DEVE dichiarare android.software.device_admin.
• [C-1-2] DEVE supportare il provisioning dei proprietari dei dispositivi come descritto nella sezione 3.9.1 e nella sezione 3.9.1.1.

3.9.1 Provisioning dei dispositivi

3.9.1.1 Provisioning dei proprietari del dispositivo

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

• [C-1-1] DEVE supportare la registrazione di un client Device Policy (DPC) come app del proprietario del dispositivo come descritto di seguito:
  • Quando l'implementazione del dispositivo non ha né utenti né dati utente configurati,:
    • [C-1-5] DEVE registrare l'applicazione DPC come app Proprietario del dispositivo o consentire all'app DPC di scegliere se diventare un Proprietario del dispositivo o un Proprietario di profilo, se il dispositivo dichiara il supporto di Near Field Communications (NFC) tramite il flag di funzionalità android.hardware.nfc e riceve un messaggio NFC contenente un record con tipo MIME MIME_TYPE_PROVISIONING_NFC.
    • [C-1-8] DEVE inviare l'intent ACTION_GET_PROVISIONING_MODE dopo l'attivazione del provisioning del proprietario del dispositivo, in modo che l'app DPC possa scegliere se diventare Proprietario del dispositivo o Proprietario di 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 del proprietario del dispositivo se viene stabilito un proprietario del dispositivo durante il provisioning, a prescindere dal metodo di provisioning utilizzato. L'utente non deve essere in grado di procedere nella configurazione guidata fino al termine dell'app Proprietario del dispositivo.
  • Quando l'implementazione del dispositivo include utenti o dati utente:
    • [C-1-7] Non DEVE più registrare alcuna applicazione DPC come app del proprietario del dispositivo.

• [C-1-2] DEVE mostrare un'informativa di divulgazione adeguata (ad esempio come indicato 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 in modo programmatico per la modalità demo retail prima dell'interazione dell'utente finale sullo schermo. 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 come riconosciuto dalle API DevicePolicyManager standard di Android, questi:

• [C-2-1] DEVE disporre di una procedura per verificare che l'app specifica da promuovere appartenga a una soluzione di gestione dei dispositivi aziendali legittima e che sia stata configurata nella soluzione proprietaria in modo da avere i diritti equivalenti a un "proprietario del dispositivo".

• [C-2-2] DEVE mostrare la stessa informativa relativa al 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 in forma rigida o impedire l'utilizzo di app di altri proprietari del dispositivo.

3.9.1.2 Provisioning dei profili gestiti

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

• [C-1-1] DEVE implementare le API consentendo a un'applicazione del controller dei criteri dei dispositivi (DPC) di diventare proprietario di un nuovo profilo gestito.

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

• [C-1-3] DEVE fornire le seguenti autorizzazioni utente nelle Impostazioni per indicare all'utente quando una determinata funzione di sistema è stata disattivata dal controller dei criteri dei dispositivi (DPC):

  • Un'icona coerente o un altro invito all'utente (ad esempio l'icona delle informazioni AOSP upstream) da rappresentare quando una determinata impostazione è limitata da un amministratore del dispositivo.
  • Un breve messaggio esplicativo, fornito dall'amministratore del dispositivo tramite setShortSupportMessage.
  • L'icona dell'applicazione DPC (controller criteri dispositivi).

• [C-1-4] DEVE lanciare 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 la trasmissione 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 Proprietario del dispositivo o 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 fino al termine dell'app del proprietario del profilo.

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

3.9.2 Supporto dei profili gestiti

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

• [C-1-1] 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 a forma di icona (simile al badge di lavoro upstream di AOSP) per rappresentare le applicazioni e i widget gestiti e altri elementi UI con badge come Recenti e notifiche.
• [C-1-4] DEVE mostrare un'icona di notifica (simile al badge di lavoro upstream AOSP) per indicare quando l'utente si trova all'interno di un'applicazione con profilo gestito.
• [C-1-5] DEVE visualizzare un avviso popup che indica che l'utente è nel profilo gestito se e quando il dispositivo si attiva (ACTION_USER_PRESENT) e l'applicazione in primo piano si trova all'interno del profilo gestito.
• [C-1-6] Se esiste un profilo gestito, DEVE mostrare un'invito visivo nel "Selettore di intent" per consentire all'utente di inoltrare l'intent dal profilo gestito all'utente principale o viceversa, se abilitato dal controller dei criteri dei dispositivi.
• [C-1-7] Se esiste un profilo gestito, DEVE esporre le seguenti tariffe utente sia per l'utente principale sia per il profilo gestito:
  • Dati separati per l'utilizzo di batteria, posizione, dati mobili e spazio di archiviazione per l'utente principale e il profilo gestito.
  • Gestione indipendente delle applicazioni VPN installate nel profilo dell'utente principale o gestito.
  • Gestione indipendente delle applicazioni installate nel profilo utente principale o gestito.
  • Gestione indipendente degli account all'interno dell'utente principale o del profilo gestito.
• [C-1-8] DEVE garantire che la tastiera, i contatti e le applicazioni di messaggistica preinstallate possano cercare e cercare informazioni sul chiamante nel profilo gestito (se esistente) oltre a quelli nel profilo principale, se il controller dei criteri dei dispositivi lo consente.
• [C-1-9] DEVE garantire che soddisfi tutti i requisiti di sicurezza applicabili a un dispositivo in cui sono abilitati più utenti (vedi sezione 9.5), anche se il profilo gestito non viene conteggiato come un altro utente oltre all'utente principale.

Crea nuovi requisiti

• [C-1-10] DEVE garantire che i dati degli screenshot vengano salvati nello spazio di archiviazione del profilo di lavoro quando viene acquisito uno screenshot con una finestra topActivity con stato attivo (quella con cui l'utente ha interagito per ultimo tra tutte le attività) e che appartenga a un'app del profilo di lavoro.
• [C-1-11] NON DEVE acquisire altri contenuti dello schermo (barra di sistema, notifiche o contenuti del profilo personale), ad eccezione della finestra/finestre dell'applicazione del profilo di lavoro durante il salvataggio di uno screenshot nel profilo di lavoro (per garantire che i dati del profilo personale non vengano salvati nel profilo di lavoro).

Termina nuovi requisiti

Se le implementazioni dei dispositivi dichiarano android.software.managed_users e android.software.secure_lock_screen, questi:

• [C-2-1] DEVE supportare la possibilità di specificare una schermata di blocco separata che soddisfi i seguenti requisiti per concedere l'accesso soltanto alle app eseguite in un profilo gestito.
  • Le implementazioni dei dispositivi DEVONO rispettare l'intento di DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrare un'interfaccia per configurare una credenziali della schermata di blocco separata per il profilo gestito.
  • Le credenziali della schermata di blocco del profilo gestito DEVONO utilizzare gli stessi meccanismi di archiviazione e gestione delle credenziali del profilo principale, come documentato sul sito del progetto open source Android.
  • I criteri relativi alle password del DPC (controller criteri dispositivi) DEVONO essere applicati solo alle credenziali della schermata di blocco del profilo gestito, a meno che non venga richiamata l'istanza DevicePolicyManager restituita da getParentProfileInstance.
• Quando i contatti del profilo gestito sono visualizzati nel registro chiamate preinstallato, nella UI in corso, nelle notifiche di chiamata in corso e persa, nei contatti e nelle app di messaggistica, DEVONO essere contrassegnati con lo stesso badge utilizzato per indicare le applicazioni del profilo gestito.

3.9.3 Supporto degli utenti gestiti

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

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

Se le implementazioni dei dispositivi dichiarano android.software.device_admin e forniscono un'invito per l'utente on-device per aggiungere altri utenti secondari, questi:

• [C-SR-1] È VIVAMENTE 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 capiscano che il dispositivo è gestito.

3.9.4 Requisiti del ruolo Gestione criteri dispositivi

Se le implementazioni dei dispositivi registrano android.software.device_admin o android.software.managed_users, questi:

• [C-1-1] DEVE supportare il ruolo di gestione dei criteri relativi ai dispositivi come definito nella sezione 9.1. L'applicazione che contiene il ruolo di gestione dei criteri dei dispositivi POTREBBE 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 viene definito il nome di un pacchetto come descritto sopra:

• [C-2-1] Le implementazioni dei dispositivi DEVONO supportare il provisioning senza un'applicazione di titolare del ruolo per la gestione dei criteri dei dispositivi (AOSP fornisce un'implementazione di riferimento).

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

• [C-3-1] L'applicazione DEVE essere installata su tutti i profili di un utente.
• [C-3-2] Le implementazioni dei dispositivi POTREBBERO definire un'applicazione che aggiorna il titolare del ruolo di gestione dei criteri dei dispositivi prima del provisioning impostando config_devicePolicyManagementUpdater.

Se per config_devicePolicyManagementUpdater viene definito il nome di un pacchetto, come descritto sopra:

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

Crea nuovi requisiti

3.9.5 Framework per la risoluzione dei criteri dei dispositivi

Se le implementazioni dei dispositivi registrano android.software.device_admin o android.software.managed_users, questi:

• [C-1-1] DEVE risolvere i conflitti dei criteri relativi ai dispositivi come documentato nel framework per la risoluzione dei criteri dei dispositivi.

Termina nuovi requisiti

3.10. Accessibilità

Android fornisce un livello di accessibilità che aiuta gli utenti con disabilità a utilizzare i dispositivi più facilmente. Inoltre, Android fornisce API delle piattaforme che consentono le implementazioni dei servizi di accessibilità per ricevere callback per gli eventi dell'utente e del sistema e generare meccanismi di feedback alternativi, come sintesi vocale, feedback aptico e navigazione trackball/D-pad.

Se le implementazioni del dispositivo supportano i servizi di accessibilità di terze parti, questi:

• [C-1-1] DEVE fornire un'implementazione del framework di accessibilità Android come descritto nella documentazione dell'SDK per le API accessibility.
• [C-1-2] DEVE generare eventi di accessibilità e fornire il AccessibilityEvent appropriato a tutte le implementazioni AccessibilityService registrate, come documentato nell'SDK.
• [C-1-4] DEVE fornire un'autorizzazione all'utente per controllare i servizi di accessibilità che dichiarano il AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_Button. Tieni presente che, per le implementazioni sui dispositivi con una barra di navigazione del sistema, DOVREBBE 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, questi:

• [C-2-1] DEVE implementare questi servizi di accessibilità preinstallati come app Direct Boot Aware se lo spazio di archiviazione dei dati è criptato con la crittografia basata su file (FBE).
• DOVREBBE fornire un meccanismo nel flusso di configurazione predefinito per consentire agli utenti di abilitare servizi di accessibilità pertinenti, nonché opzioni per regolare le dimensioni del carattere, le dimensioni di visualizzazione e i gesti di ingrandimento.

3.11. Sintesi vocale

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

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

• [C-1-1] DEVE supportare le API Android TTS Framework.

Se le implementazioni del dispositivo supportano l'installazione di motori di sintesi vocale di terze parti, questi:

• [C-2-1] DEVE fornire l'autorizzazione all'utente per permettergli di selezionare un motore di sintesi vocale da utilizzare a livello di sistema.

3.12. Framework input TV

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

Se le implementazioni dei dispositivi supportano la funzionalità TIF:

• [C-1-1] DEVE dichiarare la funzionalità della piattaforma android.software.live_tv.
• [C-1-2] DEVE supportare tutte le API TIF in modo che un'applicazione che usa 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 UI Impostazioni rapide che consente di accedere rapidamente alle azioni utilizzate di frequente o urgenti.

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

• [C-1-1] DEVE consentire all'utente di aggiungere o rimuovere i riquadri forniti tramite le API quicksettings da un'app di terze parti.
• [C-1-2] NON DEVE aggiungere automaticamente un riquadro da un'app di terze parti direttamente alle Impostazioni rapide.
• [C-1-3] DEVE visualizzare tutti i riquadri aggiunti dagli utenti 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 ad attivazione vocale (le App) che interagiscono con applicazioni di terze parti tramite MediaBrowser o MediaSession, le App:

• [C-1-2] DEVE visualizzare chiaramente le icone ottenute tramite getIconBitmap() o getIconUri() e i titoli ottenuti tramite getTitle() come descritto in MediaDescription. I titoli potrebbero essere abbreviati per rispettare le normative di sicurezza (ad es. distrazioni alla guida).

• [C-1-3] DEVE mostrare l'icona dell'applicazione di terze parti ogni volta che vengono visualizzati contenuti forniti da questa applicazione.

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

• [C-1-5] DEVE considerare il doppio tocco di KEYCODE_HEADSETHOOK o KEYCODE_MEDIA_PLAY_PAUSE come KEYCODE_MEDIA_NEXT per MediaSession.Callback#onMediaButtonEvent.

3.15. App istantanee

Se le implementazioni del dispositivo supportano le app istantanee, DEVONO soddisfare i seguenti requisiti:

• [C-1-1] Alle app istantanee DEVONO essere concesse soltanto le autorizzazioni in cui android:protectionLevel è impostato su "instant".
• [C-1-2] Le app istantanee NON DEVONO interagire con le app installate tramite intent impliciti, a meno che non si verifichi una delle seguenti condizioni:
  • Il filtro del pattern per intent del componente è esposto e ha CATEGORY_BROWSABLE
  • L'azione è una tra ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
  • Il target è esposto esplicitamente con android:visibleTo InstantApps
• [C-1-3] Le app istantanee NON DEVONO interagire esplicitamente con le app installate, a meno che il componente non venga esposto tramite android:visibleTo InstantApps.
• [C-1-4] Le app installate NON DEVONO visualizzare i dettagli sulle app istantanee presenti sul dispositivo, a meno che l'app istantanea non si connetta esplicitamente all'applicazione installata.

• Le implementazioni del dispositivo DEVONO fornire le seguenti induzioni utente per interagire con le app istantanee. L'AOSP soddisfa i requisiti con UI di sistema, impostazioni e Avvio app predefiniti. Implementazioni dei dispositivi:

  • [C-1-5] DEVE fornire un invito all'utente per visualizzare ed eliminare le app istantanee nella cache locale per ogni singolo pacchetto dell'app.
  • [C-1-6] DEVE fornire una notifica all'utente persistente che possa essere compressa mentre un'app istantanea è in esecuzione in primo piano. Questa notifica all'utente DEVE includere che le app istantanee non richiedono l'installazione e devono fornire un invito all'utente che indirizzi l'utente alla schermata con le informazioni sull'applicazione in Impostazioni. Per le app istantanee avviate tramite intent web, come definito utilizzando un intent con azione impostata su Intent.ACTION_VIEW e con uno schema "http" o "https", un'invito utente aggiuntivo DEVE consentire all'utente di non avviare l'app istantanea e avviare il link associato con il browser web configurato, se un browser è disponibile sul dispositivo.
  • [C-1-7] DEVE consentire l'accesso alle app istantanee in esecuzione dalla funzione Recenti se quest'ultima è disponibile sul dispositivo.

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

3.16. Associazione dispositivo companion

Android supporta l'accoppiamento di dispositivi associati per gestire in modo più efficace l'associazione con i dispositivi associati 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 associato, questi:

• [C-1-1] DEVE dichiarare il flag della funzionalità FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] DEVE garantire che le API nel pacchetto android.companion sia completamente implementata.
• [C-1-3] DEVE fornire gli inviti all'utente affinché possa selezionare/confermare che un dispositivo associato sia presente e operativo.

3.17. App pesanti

Se le implementazioni dei dispositivi dichiarano la funzionalità FEATURE_CANT_SAVE_STATE:

• [C-1-1] DEVE avere installato una sola app alla volta in cui è in esecuzione cantSaveState nel sistema. Se l'utente abbandona l'app senza chiuderla esplicitamente (ad esempio premendo Home mentre il sistema lascia un'attività attiva, invece di premere Indietro senza altre attività attive nel sistema), le implementazioni del dispositivo DEVONO dare la priorità all'app nella RAM come fanno per altri elementi che si prevede rimangano in esecuzione, come i servizi in primo piano. Mentre un'app di questo tipo è in background, il sistema può comunque applicarvi funzionalità di gestione dell'alimentazione, come la limitazione della CPU e dell'accesso alla rete.
• [C-1-2] DEVE fornire un'invito UI per scegliere l'app che non parteciperà al normale meccanismo di salvataggio/ripristino dello stato dopo che l'utente lancia una seconda app dichiarata con l'attributo cantSaveState.
• [C-1-3] NON DEVE applicare altre modifiche ai criteri alle app che specificano cantSaveState, ad esempio la modifica delle prestazioni della CPU o la modifica della priorità di pianificazione.

Se le implementazioni dei dispositivi non dichiarano la funzionalità FEATURE_CANT_SAVE_STATE:

• [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 le API Contacts Provider per consentire alle applicazioni di gestire i dati di contatto memorizzati sul dispositivo. I dati di contatto inseriti direttamente nel dispositivo sono generalmente sincronizzati con un servizio web, ma i dati POTREBBERO anche risiedere solo localmente sul dispositivo. I contatti archiviati solo sul dispositivo sono definiti contatti locali.

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

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

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

Implementazioni dei dispositivi:

• [C-SR-1] È VIVAMENTE 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 entro ContactsContract.RawContacts.getLocalAccountName.
• [C-1-2] Il valore ACCOUNT_TYPE, dell'account locale personalizzato DEVE essere restituito entro 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 all'account locale personalizzato.
• [C-1-4] I contatti non elaborati inseriti nell'account locale personalizzato non DEVONO essere rimossi quando vengono aggiunti o rimossi account.
• [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 era impostato su false o non è stato specificato.

4. Compatibilità con la confezione dell'applicazione

Implementazioni dei dispositivi:

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

  • Poiché il requisito di cui sopra può essere impegnativo, per le implementazioni dei dispositivi si consiglia di utilizzare il sistema di gestione dei pacchetti dell'implementazione di riferimento AOSP.

• [C-0-2] DEVE supportare la verifica dei file ".apk" tramite 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 "Programma di installazione registrato" del pacchetto di disinstallare automaticamente l'app senza una conferma dell'utente, come documentato nell'SDK per l'autorizzazione DELETE_PACKAGE. Le uniche eccezioni riguardano l'intent PACKAGE_NEEDS_VERIFICATION per la gestione dell'app di verifica del pacchetto di sistema e l'intent ACTION_MANAGE_STORAGE per l'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 soddisfi tutti i requisiti seguenti:

  • DEVE dichiarare l'autorizzazione REQUEST_INSTALL_PACKAGES o avere il valore android:targetSdkVersion impostato su 24 o su un valore inferiore.
  • L'utente DEVE avere ricevuto l'autorizzazione per installare app da origini sconosciute.

• DOVREBBE fornire un'autorizzazione all'utente per concedere/revocare l'autorizzazione a installare app da origini sconosciute per applicazione, ma POTREBBE scegliere di implementarla in modo autonomo e restituire RESULT_CANCELED per startActivityForResult(), se l'implementazione del dispositivo non vuole consentire agli utenti di avere questa scelta. Tuttavia, anche in questi casi DEVONO indicare all'utente il motivo per cui non viene presentata questa scelta.

• [C-0-7] DEVE visualizzare una finestra di dialogo di avviso con la stringa di avviso fornita tramite l'API di sistema PackageManager.setHarmfulAppWarning prima di avviare un'attività in un'applicazione contrassegnata dalla stessa API di sistema PackageManager.setHarmfulAppWarning come potenzialmente dannosa.

• DOVREBBE fornire un invito all'utente per scegliere di disinstallare o avviare un'applicazione nella finestra di dialogo di avviso.

• [C-0-8] DEVE implementare il supporto per il file system incrementale come documentato qui.

• [C-0-9] DEVE supportare la verifica dei file .apk utilizzando lo schema di firma dell'APK v4 e lo schema di firma dell'APK v4.1.

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

5. Compatibilità multimediale

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare i formati multimediali, i codificatori, i decoder, i tipi di file e i formati dei contenitori definiti nella sezione 5.1 per ogni singolo codec dichiarato da MediaCodecList.
• [C-0-2] DEVE dichiarare e segnalare il supporto dei codificatori, dei decoder disponibili per applicazioni di terze parti tramite MediaCodecList.
• [C-0-3] DEVE essere in grado di decodificare e rendere disponibili alle app di terze parti tutti i formati che è in grado di codificare. Ciò include tutti i bitstream generati dai suoi codificatori e i profili riportati nel relativo CamcorderProfile.

Implementazioni dei dispositivi:

• DOVREBBERO puntare alla latenza minima del codec, in altre parole,
  • NON DEVE utilizzare e archiviare i buffer di input e restituirli solo una volta elaborati.
  • NON DEVE conservare i buffer decodificati per un tempo superiore a quello specificato dallo standard (ad es. SPS).
  • NON DEVE conservare i buffer codificati per un tempo superiore a quello richiesto dalla struttura GOP.

Tutti i codec elencati nella sezione che segue sono forniti come implementazioni software nell'implementazione Android preferita dell'Android Open Source Project.

Tieni presente che né Google né l'Open Handset Alliance fanno alcuna dichiarazione sul fatto che questi codec sono esenti da brevetti di terze parti. Consigliamo a chi intende utilizzare questo codice sorgente in prodotti hardware o software che le implementazioni di questo codice, anche in software open source o shareware, potrebbero richiedere licenze di brevetto dei rispettivi titolari dei brevetti.

5.1. Codec multimediali

5.1.1. Codifica audio

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

Se le implementazioni dei dispositivi dichiarano android.hardware.microphone, DEVONO supportare la codifica dei seguenti formati audio e renderli disponibili per 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 nativi 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 per la funzionalità android.hardware.audio.output, devono supportare la decodifica dei seguenti formati audio:

• [C-1-1] Profilo AAC MPEG-4 (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 (Basso ritardo AAC 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 dell'intervallo dinamico 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 a 192 kHz e 8 canali. Tieni presente che questo requisito riguarda unicamente la decodifica e che un dispositivo può eseguire il sottocampionamento e il downmix durante la fase di riproduzione.
• [C-1-10] Opus

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

• [C-2-1] La decodifica DEVE essere eseguita senza downmixing (ad esempio, un flusso AAC 5.0 deve essere decodificato su cinque canali di PCM, uno stream AAC 5.1 deve essere decodificato su sei canali di PCM).
• [C-2-2] I metadati dell'intervallo dinamico DEVONO essere definiti nel documento "Controllo intervallo dinamico (DRC)" della normativa ISO/IEC 14496-3 e i tasti 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] Consigliamo VIVAMENTE che i requisiti C-2-1 e C-2-2 di cui sopra siano soddisfatti da tutti i decoder audio AAC.

Quando si decodifica l’audio USAC, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] Il volume e i metadati DRC DEVONO essere interpretati e applicati in base al livello 1 del profilo di controllo dinamico dell'intervallo DRC MPEG-D.
• [C-3-2] Il decoder 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.

Decoder del profilo MPEG-4 AAC, HE AAC e HE AACv2:

• POTREBBE supportare il controllo del volume e dell'intervallo dinamico utilizzando il profilo di controllo dell'intervallo dinamico ISO/IEC 23003-4.

Se è supportato lo standard ISO/IEC 23003-4 e se in un flusso di bit decodificato sono presenti entrambi i metadati ISO/IEC 23003-4 e ISO/IEC 14496-3:

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

Tutti i decoder audio DEVONO supportare l'output:

• [C-6-1] Frame audio PCM a 16 bit nativi a 16 bit tramite l'API android.media.MediaCodec.

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

• [C-7-1] DEVE essere configurato dall'applicazione utilizzando la decodifica con la chiave KEY_MAX_OUTPUT_CHANNEL_COUNT per controllare se i contenuti vengono downmixati in stereo (con il valore 2) o se vengono trasmessi utilizzando il numero nativo di canali (quando si utilizza un valore uguale o maggiore a quel numero). Ad esempio, un valore pari o superiore a 6 configura un decoder per l'uscita di 6 canali quando riceve contenuto 5.1.
• [C-7-2] Durante la decodifica, il decoder DEVE pubblicizzare la maschera del canale utilizzata nel formato di output con la chiave KEY_CHANNEL_MASK, usando le costanti android.media.AudioFormat (esempio: CHANNEL_OUT_5POINT1).

Se le implementazioni del dispositivo supportano decoder audio diversi dal decodificatore audio AAC predefinito e sono in grado di trasmettere audio multicanale (ovvero più di 2 canali) quando vengono alimentati contenuti multicanale compressi:

• [C-SR-2] Il decoder è VIVAMENTE CONSIGLIATO per poter essere configurato dall'applicazione utilizzando la decodifica con la chiave KEY_MAX_OUTPUT_CHANNEL_COUNT per controllare se i contenuti vengono downmix in stereo (quando si utilizza il valore 2) o se vengono trasmessi utilizzando il numero nativo di canali (quando si utilizza un valore uguale o maggiore a quel numero). Ad esempio, un valore pari o superiore a 6 configura un decoder per l'uscita di 6 canali quando riceve contenuto 5.1.
• [C-SR-3] Durante la decodifica, al decoder è VIVAMENTE CONSIGLIATO di pubblicizzare la maschera di canale utilizzata sul formato di output con la chiave KEY_CHANNEL_MASK, usando le costanti android.media.AudioFormat (esempio: CHANNEL_OUT_5POINT1).

5.1.3. Dettagli codec audio

Formato/Codec	Dettagli	Tipi di file/formati dei contenitori da supportare
Profilo AAC MPEG-4 (AAC LC)	Supporto di contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 8 a 48 kHz.	3 GPP (0,3 gp) MPEG-4 (.mp4, .m4a) AAC non elaborato ADTS (.aac, ADIF non supportato) MPEG-TS (.ts, non ricercabile, solo decodifica) Matroska (solo .mkv, decodifica)
Profilo MPEG-4 HE AAC (AAC+)	Supporto di contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.	3 GPP (0,3 gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profilo (AAC+ migliorato)	Supporto di contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.	3 GPP (0,3 gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC a basso ritardo migliorato)	Supporto di contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.	3 GPP (0,3 gp) MPEG-4 (.mp4, .m4a)
USAC	Supporto di 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	3 GPP (0,3 gp)
AMR-WB	9 velocità da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz, come definito in AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec	3 GPP (0,3 gp)
FLAC	Sia per l'encoder che per il decoder: DEVONO essere supportate almeno le modalità mono e stereo. DEVONO essere supportate frequenze di campionamento fino a 192 kHz; la risoluzione a 16 e 24 bit DEVE essere supportata. La gestione dei dati audio a 24 bit FLAC DEVE essere disponibile con la configurazione audio in virgola mobile.	FLAC (.flac) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (solo .mkv, decodifica)
MP3	Costante mono/stereo da 8-320 Kbps (CBR) o velocità in bit variabile (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (solo .mkv, decodifica)
MIDI	MIDI Type 0 e 1. DLS versione 1 e 2. XMF e XMF mobile. 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		Ogg (.ogg) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (.mkv) Webm (.webm)
PCM/WAVE	Il codec PCM DEVE supportare un PCM lineare a 16 bit e un numero in virgola mobile a 16 bit. L'estrattore WAVE deve supportare un PCM lineare a 16-bit, 24-bit, 32-bit e un numero in virgola mobile a 32-bit (ratenze fino al limite dell'hardware). Le frequenze di campionamento DEVONO essere supportate tra 8 kHz e 192 kHz.	onda (.wav)
Opus	Decodifica: supporto di contenuti mono, stereo, 5.0 e 5.1 con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz. Codifica: supporto di contenuti mono e stereo con frequenze di campionamento di 8000, 12000, 16000, 16000, 16000, 16000 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 della seguente codifica dell'immagine:

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

Crea nuovi requisiti

• [C-0-4] AVIF
  • I dispositivi devono supportare BITRATE_MODE_CQ e Baseline Profile.

Termina nuovi requisiti

Se le implementazioni del dispositivo supportano la codifica HEIC tramite android.media.MediaCodec per il tipo di media MIMETYPE_IMAGE_ANDROID_HEIC, questi:

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

5.1.5. Decodifica dell'immagine

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

Le implementazioni dei dispositivi DEVONO supportare la decodifica della seguente codifica dell'immagine:

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Grezzo
• [C-0-7] AVIF (Profilo Baseline)

Se le implementazioni dei dispositivi supportano la decodifica video HEVC, queste: * [C-1-1] DEVONO supportare la decodifica delle immagini in HEIF (HEIC).

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

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

5.1.6. Dettagli codec immagine

Formato/Codec	Dettagli	Tipi di file/formati container supportati
JPEG	Base+progressivo	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)	Immagine, raccolta di immagini, sequenza di immagini del profilo di base	Container HEIF (.avif)

Codificatori e decoder di immagini esposti tramite l'API MediaCodec

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

• [C-SR-1] VIVAMENTE CONSIGLIATO di supportare il formato colore RGB888 per la modalità Surface di input.

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

5.1.7. Codec video

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

Se le implementazioni dei dispositivi includono un decodificatore o un codificatore video:

• [C-1-1] I codec video DEVONO supportare dimensioni bytebuffer di output e di input che ospitano il frame compresso e non compresso più grande possibile, come dettato dallo standard e dalla configurazione, ma non globalmente.

• [C-1-2] I codificatori e i decoder video DEVONO supportare i formati di colore flessibili YUV420 8:8:8 (COLOR_FormatYUV420Flexible) tramite CodecCapabilities.

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

• [C-SR-1] I codificatori e i decoder video sono VIVAMENTE CONSIGLIATI di supportare almeno uno dei formati a colori YUV420 8:8:8 planari o semiplanari ottimizzati per hardware (YV12, NV12, NV21 o un formato equivalente ottimizzato dal fornitore).

• [C-1-5] I decoder video che supportano un formato a profondità di bit elevata (9 o più bit per canale) DEVONO supportare l'output di un formato equivalente a 8 bit se richiesto dall'applicazione. Ciò DEVE essere indicato dal supporto di 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, l'implementazione di questi dispositivi:

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

Se le implementazioni dei dispositivi pubblicizzano il supporto intra-aggiornamento tramite FEATURE_IntraRefresh nella classe MediaCodecInfo.CodecCapabilities, possono:

• [C-3-1] DEVE supportare i periodi di aggiornamento nell'intervallo 10-60 frame e operare in modo accurato 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 decoder video:

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

5.1.8. Elenco codec video

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

5.1.9. Sicurezza del codec multimediale

Le implementazioni dei dispositivi DEVONO garantire la conformità con le funzionalità di sicurezza del codec multimediale, 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, questi:

• [C-1-1] DEVE fornire supporto per i codec multimediali tramite API OMX o Codec 2.0 (o entrambi), come nel progetto open source Android, e non disabilitare o eludere le protezioni di sicurezza. Ciò in particolare non significa che ogni codec DEVE utilizzare l'API OMX o Codec 2.0, ma solo che il supporto per almeno una di queste API DEVE essere disponibile, e il supporto per le API disponibili DEVE includere le protezioni di sicurezza presenti.
• [C-SR-1] CONSIGLIATO VIVAMENTE di includere il supporto per l'API Codec 2.0.

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

• [C-2-1] DEVE includere il codec software OMX corrispondente dell'Android Open Source Project (se disponibile) per ogni formato e tipo multimediale (encoder o decoder) supportato dal dispositivo.
• [C-2-2] Codec i cui nomi iniziano con "OMX.google." DEVE essere basato sul codice sorgente del progetto open source Android.
• [C-SR-2] È VIVAMENTE CONSIGLIATO che i codec software OMX vengano eseguiti in un processo codec che non ha accesso a driver hardware diversi dai mappatori di memoria.

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

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

5.1.10. Caratterizzazione del codec multimediale

Se le implementazioni dei dispositivi supportano i codec multimediali, questi:

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

In particolare:

• [C-1-2] Codec con nomi che iniziano con "OMX." DEVONO usare 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 di denominazione 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 eseguiti in un processo codec (fornitore o sistema) che hanno accesso a driver hardware diversi dagli allocatori di memoria e dai mappatori NON DEVONO essere definiti solo software.
• [C-1-6] Codec non presenti nel progetto open source Android o non basati sul codice sorgente del progetto DEVONO essere contrassegnati come fornitore.
• [C-1-7] I codec che utilizzano l'accelerazione hardware DEVONO essere caratterizzati come accelerazione hardware.
• [C-1-8] I nomi dei codec NON DEVONO essere fuorvianti. Ad esempio, i codec denominati "decoder" DEVONO supportare la decodifica, mentre quelli denominati "encoder" DEVONO supportare la codifica. I codec con nomi contenenti formati multimediali DEVONO supportare tali formati.

Se le implementazioni dei dispositivi supportano i codec video:

• [C-2-1] Tutti i codec video DEVONO pubblicare dati sulla frequenza fotogrammi raggiungibili per le seguenti dimensioni, se supportati 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 (encoder MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 px (altro)	704 x 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 px (codificatore MPEG4) 720 x 480 px (altro, AV1)	1408 x 1152 px (H263) 1280 x 720 px (altro, AV1)	1920 x 1080 px (diverso da MPEG4, AV1)	3840 x 2160 px (HEVC, VP9, AV1)

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

5.2. Codifica video

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

• NON DEVE essere, su due finestre scorrevoli, superiore al 15% della velocità in bit tra gli intervalli intraframe (I-frame).
• NON DEVE superare il 100% della velocità in bit in una finestra scorrevole di 1 secondo.

Crea nuovi requisiti

Se le implementazioni dei dispositivi supportano qualsiasi codificatore video e lo rendono disponibile per app di terze parti e imposta
MediaFormat.KEY_BITRATE_MODE su BITRATE_MODE_VBR in modo che il codificatore funzioni in modalità a velocità in bit variabile, se questo non influisce sulla qualità minima la velocità in bit codificata :

• [C-5-1] DEVE NON DEVE essere, oltre una finestra scorrevole, di oltre il 15% rispetto alla velocità in bit tra gli intervalli di intraframe (I-frame).
• [C-5-2] DEVE NON superare il 100% della velocità in bit su una finestra scorrevole di 1 secondo.

Se le implementazioni dei dispositivi supportano qualsiasi codificatore video e lo rendono disponibile per app di terze parti e impostano MediaFormat.KEY_BITRATE_MODE su BITRATE_MODE_CBR in modo che il codificatore funzioni in modalità con velocità in bit costante, la velocità in bit codificata:

• [C-6-1] DEVE CONSIGLIARE VIVAMENTE a [C-SR-2] NON superare il 15% della velocità in bit target su una finestra scorrevole di 1 secondo.

Termina nuovi requisiti

Se le implementazioni dei dispositivi includono uno schermo incorporato con lunghezza diagonale di almeno 2,5 pollici o includono una porta di uscita video o dichiarano il supporto di una videocamera tramite il flag della funzionalità android.hardware.camera.any, questi:

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

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

• [C-2-1] DEVE supportare la velocità in bit configurabile dinamicamente.
• DEVONO supportare frequenze fotogrammi variabili, laddove 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 alla durata del frame.

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

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

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

• [C-4-1] tutti i codificatori di immagini e video con accelerazione hardware DEVONO supportare la codifica dei fotogrammi dalle videocamere hardware.
• DEVONO supportare i fotogrammi di codifica dalle fotocamere hardware attraverso tutti i codificatori video o di immagini.

Se le implementazioni dei dispositivi forniscono la codifica HDR:

• [C-SR-1] è VIVAMENTE CONSIGLIATO di fornire un plug-in per consentire all'API di transcodifica Seamless di convertire dal formato HDR al formato SDR.

5.2.1. H.263

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

• [C-1-1] DEVE supportare la risoluzione QCIF (176 x 144) utilizzando il livello 45 del profilo di riferimento. La risoluzione SQCIF è facoltativa.
• DEVE supportare la velocità in bit configurabile 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 livello 3 del profilo di riferimento. Tuttavia, il supporto per ASO (Ordine delle sezioni arbitrario), Ordine dei macroblocchi flessibile (FMO) e RS (sezioni ridondanti) è FACOLTATIVO. Inoltre, per mantenere la compatibilità con altri dispositivi Android, consigliamo di non utilizzare ASO, FMO e RS per il profilo di riferimento dai codificatori.
• [C-1-2] DEVE supportare i profili di codifica video SD (Standard Definition) riportati nella tabella seguente.
• DEVE supportare il livello del profilo principale 4.
• DEVONO 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 in risoluzione 720p o 1080p tramite le API multimediali, questi:

• [C-2-1] DEVE supportare i profili di codifica della 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 del dispositivo supportano il codec VP8:

• [C-1-1] DEVE supportare i profili di codifica video SD.
• DEVONO 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 hardware VP8 che soddisfi i requisiti di codifica hardware RTC del progetto WebM, al fine di garantire una qualità accettabile per lo streaming di video sul web e i servizi 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, questi:

• [C-2-1] DEVE supportare i profili di codifica della 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 livello 3 del profilo 0.
• [C-1-1] DEVE supportare la scrittura di file Matroska WebM.
• [C-1-3] DEVE generare dati CodecPrivate.
• DEVONO supportare i profili di decodifica HD come indicato nella tabella seguente.
• I [C-SR-1] sono VIVAMENTE CONSIGLIATI per il supporto dei 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 del dispositivo dichiarano di supportare il Profilo 2 o 3 tramite le API multimediali:

• Il supporto per il 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 livello 3 del profilo principale fino alla risoluzione 512 x 512.
• DEVE supportare i profili di codifica HD come indicato nella seguente tabella.
• I [C-SR-1] sono VIVAMENTE 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

Crea nuovi requisiti

5.2.6. AV1

Se le implementazioni dei dispositivi supportano il codec AV1:

• [C-1-1] DEVE supportare il profilo principale, inclusi contenuti a 8 e 10 bit.

• [C-1-2] DEVE pubblicare i dati sul rendimento, ovvero generare report sui dati sul rendimento tramite le API getSupportedFrameRatesFor() o getSupportedPerformancePoints() per le risoluzioni supportate nella tabella seguente.

• [C-1-3] DEVE accettare i metadati HDR e inviarli al bitstream

Se il codificatore AV1 ha un'accelerazione hardware, allora:

• [C-2-1] DEVE supportare fino al profilo di codifica HD1080p incluso nella tabella seguente:

	SD	HD 720p	HD 1080p	UHD
Risoluzione video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps
Velocità in bit video	5 Mbps	8 Mbps	16 Mbps	50 Mbit/s

Termina nuovi requisiti

5.3 Decodifica video

Se le implementazioni del dispositivo supportano i codec VP8, VP9, H.264 o H.265:

• [C-1-1] DEVE supportare il cambio dinamico della risoluzione video e della frequenza fotogrammi tramite le API Android standard all'interno dello stesso stream per tutti i codec VP8, VP9, H.264 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 decoder MPEG-2:

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

5.3.2. H.263

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

• [C-1-1] DEVE supportare il livello di profilo di base 30 (risoluzioni CIF, QCIF e SQCIF a 30 f/s 384 kbps) e livello 45 (risoluzioni QCIF e SQCIF a 30 f/s 128 kbps).

5.3.3. MPEG-4

Se il dispositivo viene implementato con decoder MPEG-4, questi:

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

5.3.4. H.264

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

• [C-1-1] DEVE supportare Main Profile Level 3.1 e Baseline Profile. Il supporto per ASO (Ordine delle sezioni arbitrario), Ordine flessibile delle sezioni (FMO) e RS (sezioni ridondanti) è FACOLTATIVO.
• [C-1-2] DEVE essere in grado di decodificare i video con i profili SD (definizione standard) elencati nella seguente tabella e codificati con il profilo di base e il livello del profilo principale 3.1 (inclusi 720p30).
• DOVREBBE essere in grado di decodificare i video con i profili HD (alta definizione) come indicato nella tabella seguente.

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

• [C-2-1] DEVE supportare i profili di decodifica video HD 720p nella tabella seguente.
• [C-2-2] DEVE supportare i profili di decodifica video HD 1080p nella tabella seguente.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p
Risoluzione video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	60 FPS	30 f/s (60 f/s^televisore)
Velocità in bit video	800 kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

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

• [C-1-1] DEVE supportare il livello principale 3 del profilo principale e i profili di decodifica video SD, come indicato nella tabella seguente.
• DEVONO 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 riportata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, allora:

• [C-2-1] Le implementazioni dei dispositivi DEVONO supportare almeno una decodifica H.265 o VP9 di profili 720, 1080 e UHD.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p	UHD
Risoluzione video	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30/60 f/s (60 f/s^televisore con decodifica hardware H.265)	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se le implementazioni del dispositivo 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 container.
• [C-3-2] Le implementazioni dei dispositivi DEVONO visualizzare correttamente i contenuti HDR sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

5.3.6. VP8

Se le implementazioni del dispositivo supportano il codec VP8:

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

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

• [C-2-1] Le implementazioni dei dispositivi DEVONO supportare i profili 720p nella tabella seguente.
• [C-2-2] Le implementazioni dei dispositivi DEVONO supportare i profili 1080p nella tabella seguente.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	30 f/s (60 f/s^televisore)	30 (60 f/s^televisore)
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.
• DEVONO 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 riportata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, allora:

• [C-3-1] Le implementazioni dei dispositivi DEVONO supportare almeno una delle decodifica VP9 o H.265 dei profili 720, 1080 e UHD.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p	UHD
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 f/s (60 f/s^televisore con decodifica hardware VP9)	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se le implementazioni dei dispositivi dichiarano di supportare VP9Profile2 o VP9Profile3 tramite le API multimediali 'CodecProfileLevel':

• Il supporto per il formato a 12 bit è FACOLTATIVO.

Se le implementazioni del dispositivo dichiarano di supportare un profilo HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) tramite le API multimediali:

• [C-4-1] Le implementazioni dei dispositivi DEVONO accettare i metadati HDR richiesti (KEY_HDR_STATIC_INFO per tutti i profili HDR, nonché "KEY_HDR10_PLUS_INFO" per i profili HDR10Plus) dall'applicazione. DEVONO inoltre supportare l'estrazione e l'output dei metadati HDR richiesti dal flusso di bit e/o dal container.
• [C-4-2] Le implementazioni dei dispositivi DEVONO visualizzare correttamente i contenuti HDR sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

5.3.8. Dolby Vision

Se le implementazioni dei dispositivi dichiarano il supporto per il decoder Dolby Vision tramite HDR_TYPE_DOLBY_VISION, questi:

• [C-1-1] DEVE fornire un estrattore compatibile con Dolby Vision.
• [C-1-2] DEVE visualizzare correttamente i contenuti Dolby Vision sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).
• [C-1-3] DEVE impostare l'ID traccia dei livelli di base compatibili con le versioni precedenti (se presenti) in modo che siano uguali all'ID traccia del livello Dolby Vision combinato.

5.3.9. AV1

Se le implementazioni dei dispositivi supportano il codec AV1:

• [C-1-1] DEVE supportare il profilo 0 incluso il contenuto a 10 bit.

Crea nuovi requisiti

Se le implementazioni dei dispositivi supportano il codec AV1 e lo rendono disponibile ad applicazioni di terze parti, questi:

• [C-1-1] DEVE supportare il profilo principale, inclusi contenuti a 8 e 10 bit.

Se le implementazioni dei dispositivi forniscono supporto per il codec AV1 con un decoder con accelerazione hardware:

• [C-2-1] DEVE essere in grado di decodificare almeno i profili di decodifica video HD a 720p dalla tabella seguente quando l'altezza riportata dal metodo Display.getSupportedModes() è uguale o superiore a 720p.
• [C-2-2] DEVE essere in grado di decodificare almeno i profili di decodifica video HD a 1080p dalla tabella seguente quando l'altezza riportata dal metodo Display.getSupportedModes() è uguale o superiore a 1080p.

	SD	HD 720p	HD 1080p	UHD
Risoluzione video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps
Velocità in bit video	5 Mbps	8 Mbps	16 Mbps	50 Mbit/s

Se le implementazioni del dispositivo supportano il profilo HDR tramite le API Media, l'implementazione di questi dispositivi:

• [C-3-1] DEVE supportare l'estrazione e l'output dei metadati HDR dal bitstream e/o dal container.
• [C-3-2] DEVE visualizzare correttamente i contenuti HDR sullo schermo del dispositivo o su una porta di uscita video standard (ad esempio, HDMI).

Termina nuovi requisiti

5.4. Registrazione audio

Anche se alcuni dei requisiti descritti in questa sezione sono elencati come DOVREBBE da Android 4.3, si prevede che la definizione di compatibilità per le versioni future debba cambiarli in DEVE. I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare questi requisiti che sono elencati come DOVRESTI oppure non saranno in grado di raggiungere la compatibilità con Android dopo l'upgrade alla versione futura.

5.4.1. Acquisizione audio non elaborata e informazioni del microfono

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

• [C-1-1] DEVE consentire l'acquisizione di contenuti audio non elaborati per qualsiasi stream AudioRecord o AAudio INPUT aperto correttamente. DEVONO essere supportate almeno le seguenti caratteristiche:

  • 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 predefiniti di input equivalenti in AAudio, ad esempio, AAUDIO_INPUT_PRESET_CAMCORDER.

• DEVONO consentire l'acquisizione di contenuti audio non elaborati con le seguenti caratteristiche:

  • Formato: PCM lineare, 16 bit e 24 bit
  • Frequenze di campionamento: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
  • Canali: un numero di canali uguale al numero di microfoni sul dispositivo.

• [C-1-2] DEVE effettuare l'acquisizione a frequenze di campionamento superiori senza eseguire l'up-sampling.

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

• DOVREBBE consentire l'acquisizione di qualità radio AM e DVD di contenuti audio non elaborati, con le seguenti caratteristiche:

  • Formato: PCM lineare, a 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 l'attivazione di AudioRecord utilizzando MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED o VOICE_PERFORMANCE. Se le implementazioni dei dispositivi consentono l'acquisizione di qualità radio AM e DVD di contenuti audio non elaborati:

• [C-2-1] DEVE acquisire senza eseguire l'up-sampling a qualsiasi rapporto superiore a 16000:22050 o 44100:48000.

• [C-2-2] DEVE includere un filtro anti-aliasing appropriato per ogni up-sampling o down-sampling.

5.4.2. Acquisisci per il riconoscimento vocale

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

• [C-1-1] DEVE acquisire android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION sorgente audio a una delle frequenze di campionamento, 44100 e 48000.
• [C-1-2] DEVE, per impostazione predefinita, disattivare l'elaborazione audio per la riduzione del rumore durante la registrazione di uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.

• [C-1-3] DEVE, per impostazione predefinita, disattivare eventuali controlli automatici del guadagno durante la registrazione di uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.

• DOVREBBE presentare caratteristiche di ampiezza piatta rispetto alla frequenza nella gamma di frequenze medie: in particolare ±3 dB da 100 Hz a 4000 Hz per ogni microfono utilizzato per registrare la sorgente audio del riconoscimento vocale.

• I [C-SR-1] sono VIVAMENTE CONSIGLIATI di mostrare livelli di ampiezza nella gamma di frequenza bassa: in particolare da ±20 dB da 30 Hz a 100 Hz rispetto alla gamma di frequenza media per ogni microfono utilizzato per registrare la sorgente audio per il riconoscimento vocale.

• I [C-SR-2] sono VIVAMENTE CONSIGLIATI di mostrare livelli di ampiezza nella gamma delle alte frequenze: in particolare da ±30 dB da 4000 Hz a 22 KHz rispetto alla gamma di media frequenza di ogni singolo microfono usato per registrare la sorgente audio per il riconoscimento vocale.

• DOVREBBE impostare la sensibilità dell'ingresso audio in modo che una sorgente di tono sinusoidale a 1000 Hz venga riprodotta a 90 dB di livello di pressione sonora (SPL) (misurata a una distanza di 30 cm accanto al microfono) restituisce una risposta ideale di RMS 2500 per ciascun

• DOVREBBE registrare lo stream audio di riconoscimento vocale in modo che i livelli di ampiezza PCM tracciano in modo lineare l'SPL di ingresso cambi sopra una gamma di almeno 30 dB da -18 dB a +12 dB re 90 dB SPL al microfono.

• DEVI registrare lo stream audio di riconoscimento vocale con distorsione armonica totale (THD) inferiore all'1% per 1 kHz a 90 dB di livello di ingresso SPL al microfono.

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

• [C-2-1] DEVE consentire che questo effetto audio sia controllabile con l'API android.media.audiofx.NoiseSuppressor.
• [C-2-2] DEVE identificare in modo univoco ogni implementazione di 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 la sorgente audio REMOTE_SUBMIX.

Se le implementazioni dei dispositivi dichiarano sia android.hardware.audio.output sia android.hardware.microphone, questi:

• [C-1-1] DEVE implementare correttamente la sorgente audio REMOTE_SUBMIX in modo che quando un'applicazione utilizza l'API android.media.AudioRecord per registrare da questa sorgente audio, acquisisca un mix di tutti gli stream audio tranne i seguenti:

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

5.4.4. Cancellatore dell'eco acustica

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

• DEVI implementare una tecnologia Acoustic Echo Canceler (AEC) ottimizzata per la comunicazione vocale e applicata al percorso di acquisizione durante l'acquisizione con AudioSource.VOICE_COMMUNICATION.

Se le implementazioni del dispositivo forniscono un Cancellazione dell'eco acustica che viene inserito nel percorso di acquisizione dell'audio quando viene selezionato AudioSource.VOICE_COMMUNICATION, questi:

• [C-SR-1] sono StrongLY_RECOMMENDED per dichiararlo tramite il metodo API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
• I [C-SR-2] sono StrongLY_RECOMMENDED per consentire il controllo di questo effetto audio con l'API AcousticEchoCanceler.
• I [C-SR-3] sono StrongLY_RECOMMENDED per identificare in modo univoco ciascuna tecnologia AEC implementata tramite il campo AudioEffect.Descriptor.uuid.

5.4.5. Acquisizione simultanea

Se le implementazioni del dispositivo dichiarano android.hardware.microphone,DEVONO implementare l'acquisizione simultanea come descritto in questo documento. Nello specifico:

• [C-1-1] DEVE consentire l'accesso simultaneo al microfono da parte di un servizio di accessibilità di acquisizione con AudioSource.VOICE_RECOGNITION e di almeno un'acquisizione di applicazioni con qualsiasi AudioSource.
• [C-1-2] DEVE consentire l'accesso simultaneo al microfono da parte di un'applicazione preinstallata che possiede un ruolo di Assistente e almeno un'applicazione di acquisizione con qualsiasi AudioSource, ad eccezione di AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER.
• [C-1-3] DEVE silenziare l'acquisizione dell'audio per qualsiasi altra applicazione, ad eccezione di un servizio di accessibilità, durante l'acquisizione di un'applicazione con AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER. Tuttavia, quando un'app viene acquisita tramite AudioSource.VOICE_COMMUNICATION, un'altra app può acquisire la chiamata vocale se si tratta di un'app con privilegi (preinstallati) con autorizzazione CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Se due o più applicazioni acquisiscono contemporaneamente e nessuna di queste ha una UI nella parte superiore, quella che ha iniziato ad acquisire l'ultima versione riceve l'audio.

5.5. Riproduzione audio

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

5.5.1. Riproduzione audio RAW

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

• [C-1-1] DEVE consentire la riproduzione di contenuti audio non elaborati con le seguenti caratteristiche:

  • Formati di origine: PCM lineare, 16 bit, 8 bit, numero in virgola mobile
  • Canali: mono, stereo, configurazioni multicanale valide con un massimo di 8 canali
  • Frequenze di campionamento (in Hz):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 nelle configurazioni di canale sopra elencate
    • 96000 in mono e stereo

5.5.2. Effetti audio

Android fornisce un'API per gli effetti audio per le implementazioni sui dispositivi.

Se le implementazioni dei dispositivi 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 visualizzatore, controllabile tramite la classe Visualizer.
• [C-1-3] DEVE supportare l'implementazione EFFECT_TYPE_DYNAMICS_PROCESSING controllabile tramite la sottoclasse AudioEffect DynamicsProcessing.

Crea nuovi requisiti

• [C-1-4] DEVE supportare gli effetti audio con input e output floating.
• [C-1-5] DEVE assicurarsi che gli effetti audio supportino più canali fino al numero di canali del mixer, noto anche come FCC_LIMIT.

Termina nuovi requisiti

• DEVONO supportare le implementazioni EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controllabili tramite le AudioEffect sottoclassi BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.
• [C-SR-1] CONSIGLIATE VIVAMENTE per il supporto di effetti in virgola mobile e multicanale.

5.5.3. Volume di uscita audio

Implementazioni di dispositivi nel settore auto e motori:

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

5.5.4. Offload audio

Se le implementazioni del dispositivo supportano la riproduzione con trasferimento audio, questi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di tagliare i contenuti audio gapless riprodotti tra due clip con lo stesso formato se specificato dall'API AudioTrack gapless e dal container multimediale per MediaPlayer.

5.6. Latenza audio

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

Ai fini di questa sezione, utilizza le seguenti definizioni:

• latenza di output. L'intervallo tra il momento in cui un'applicazione scrive un frame di dati in codice PCM e il momento in cui il suono corrispondente viene presentato all'ambiente in un trasduttore sul dispositivo o il segnale esce dal dispositivo tramite una porta e può essere osservato esternamente.
• latenza di output a freddo. Il tempo che intercorre tra l'avvio di uno stream di output e l'ora di presentazione del primo frame in base ai timestamp, quando il sistema di output audio è stato inattivo e si è spento prima della richiesta.
• latenza di output continua. La latenza di output per i frame successivi, dopo che il dispositivo ha riprodotto l'audio.
• latenza dell'input. L'intervallo tra il momento in cui un suono viene presentato dall'ambiente al dispositivo su un trasduttore o il segnale sul dispositivo entra nel dispositivo tramite una porta e quando un'applicazione legge il frame corrispondente di dati in codice PCM.
• input perso. La parte iniziale di un segnale di input che è inutilizzabile o non disponibile.
• latenza di input a freddo. Il tempo che intercorre tra l'avvio dello streaming e la ricezione del primo frame valido, ovvero quando il sistema di input audio è rimasto inattivo e si spegneva prima della richiesta.

• latenza di input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.

• latenza di round trip continua. La somma della latenza di input continuo più la latenza di output continuo più un periodo di buffer. Il periodo di buffer lascia all'app il tempo di elaborare il segnale e il tempo necessario all'app per mitigare la differenza di fase tra i flussi di input e di output.

• API OpenSL ES PCM buffer Queue Il set di API OpenSL ES correlate a PCM all'interno di Android NDK.

• Un'API audio nativa audio. Il set di API AAudio all'interno di Android NDK.

• Timestamp: Una coppia composta da una posizione relativa di frame all'interno di un flusso e dal tempo stimato in cui il frame entra o esce dalla pipeline di elaborazione audio sull'endpoint associato. Vedi anche AudioTimestamp.

• glitch. Un'interruzione temporanea o un valore di campionamento errato nel segnale audio, in genere causata da un underrun del buffer in uscita, da un superamento del buffer per l'input o da qualsiasi altra fonte di rumore digitale o analogico.

• deviazione media assoluta. La media del valore assoluto delle deviazioni dalla media per un insieme di valori.

• latenza tocco per toni. Il tempo che intercorre tra il momento in cui si tocca lo schermo e il momento in cui viene emesso un segnale acustico come conseguenza del tocco.

Se le implementazioni dei dispositivi 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 per +/- 2 ms.

• [C-1-2] Latenza dell'output a freddo di 500 millisecondi o inferiore.

• [C-1-3] L'apertura di un flusso di output utilizzando AAudioStreamBuilder_openStream() DEVE richiedere meno di 1000 millisecondi.

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

• [C-SR-1] Latenza di uscita a freddo pari o inferiore a 100 millisecondi sul percorso dei dati dello speaker.
• [C-SR-2] Latenza Tono per tocco di 80 millisecondi o inferiore.

• [C-SR-4] Il timestamp di output restituito da AudioTrack.getTimestamp e AAudioStream_getTimestamp è preciso con un valore di +/- 1 ms.

Crea nuovi requisiti

• [C-SR-4] Le latenze di andata e ritorno calcolate in base ai timestamp di input e output restituiti da AAudioStream_getTimestamp sono VIVAMENTE CONSIGLIATE di non superare i 30 msec della latenza di andata e ritorno misurata per AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY per speaker, cuffie con cavo e wireless.

Termina nuovi requisiti

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

• [C-SR-5] VIVAMENTE CONSIGLIATO di segnalare l'audio a bassa latenza dichiarando il flag funzionalità android.hardware.audio.low_latency.
• [C-SR-6] VIVAMENTE CONSIGLIATO per soddisfare i requisiti per l'audio a bassa latenza tramite l'API AAudio.
• [C-SR-7] VIVAMENTE CONSIGLIATO per garantire che, per gli stream che restituiscono AAUDIO_PERFORMANCE_MODE_LOW_LATENCY da AAudioStream_getPerformanceMode(), il valore restituito da AAudioStream_getFramesPerBurst() sia inferiore o uguale al valore restituito da android.media.AudioManager.getProperty(String) per la chiave di proprietà AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Se le implementazioni del dispositivo non soddisfano i requisiti per l'audio a bassa latenza tramite l'API audio nativo AAudio:

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

Se le implementazioni del dispositivo 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. "Errore" qui indica la deviazione dal valore corretto.
• [C-3-2] Latenza dell'input a freddo di 500 millisecondi o inferiore.
• [C-3-3] L'apertura di uno stream di input utilizzando AAudioStreamBuilder_openStream() DEVE richiedere meno di 1000 millisecondi.

Se le implementazioni dei dispositivi includono android.hardware.microphone, vi consigliamo VIVAMENTE di soddisfare i seguenti requisiti di input audio:

• [C-SR-8] Latenza dell'input a freddo pari o inferiore a 100 millisecondi nel percorso dei dati del microfono.

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

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

• [C-SR-12] È VIVAMENTE CONSIGLIATO di avere una latenza media di round trip continuo di 50 millisecondi o inferiore su 5 misurazioni, con una deviazione media assoluta inferiore a 10 msec, su almeno un percorso supportato.

5.7. Protocolli di rete

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

Per ogni codec e formato del contenitore che l'implementazione del dispositivo deve supportare, l'implementazione del dispositivo:

• [C-1-1] DEVE supportare il codec o il container tramite HTTP e HTTPS.

• [C-1-2] DEVE supportare i formati dei segmenti multimediali corrispondenti come mostrato nella tabella dei formati dei segmenti multimediali riportata di seguito con il protocollo HTTP Live Streaming bozza, versione 7.

• [C-1-3] DEVE supportare i formati del payload RTSP corrispondenti, come mostrato nella tabella RTSP riportata 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 codec richiesto
Stream di trasporto MPEG-2	ISO 13818	Codec video: AVC H264 MPEG-4 SP MPEG-2 Consulta la sezione 5.1.8 per maggiori dettagli su H264 AVC, MPEG2-4 SP e MPEG-2. Codec audio: AAC Consulta la sezione 5.1.3 per informazioni dettagliate su AAC e sulle sue varianti.
AAC con inquadratura ADTS e tag ID3	ISO 13818-7	Consulta la sezione 5.1.1 per i dettagli su AAC e sulle sue varianti
WebVTT	WebVTT

RTSP (RTP, SDP)

Nome del profilo	Riferimenti	Supporto codec richiesto
AVC H264	RFC 6184	Consulta la sezione 5.1.8 per dettagli sull'AVC H264
MP4A-LATM	RFC 6416	Consulta la sezione 5.1.3 per i dettagli su AAC e sulle sue varianti
H263-1998	RFC 3551 RFC 4629 RFC 2190	Consulta la sezione 5.1.8 per dettagli su H263
263-2000	RFC 4629	Consulta la sezione 5.1.8 per dettagli su H263
Retrospettiva	RFC 4867	Consulta la sezione 5.1.3 per i dettagli su AMR-NB
AMR-WB	RFC 4867	Consulta la sezione 5.1.3 per i dettagli su AMR-WB
MP4V-ES	RFC 6416	Consulta la sezione 5.1.8 per i dettagli su MPEG-4 SP
mpeg4-generico	RFC 3640	Consulta la sezione 5.1.3 per i dettagli su AAC e sulle sue varianti
MP2T	RFC 2250	Per maggiori dettagli, consulta MPEG-2 Transport Stream sotto Live Streaming HTTP

5.8 Contenuti multimediali sicuri

Se le implementazioni dei dispositivi supportano l'output video sicuro e sono in grado di supportare piattaforme sicure, questi:

• [C-1-1] DEVE dichiarare il supporto per Display.FLAG_SECURE.

Se le implementazioni dei dispositivi dichiarano il supporto per Display.FLAG_SECURE e supportano il protocollo display wireless, questi:

• [C-2-1] DEVE proteggere il collegamento con un meccanismo crittograficamente efficace come HDCP 2.x o superiore per i display collegati tramite protocolli wireless come Miracast.

Se le implementazioni dei dispositivi dichiarano il supporto per Display.FLAG_SECURE e supportano il display esterno con cavo:

• [C-3-1] DEVE supportare HDCP 1.2 o versioni successive per tutti i display esterni collegati tramite una porta cablata accessibile dall'utente.

5.9 MIDI (Musical Instrument Digital Interface)

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

• [C-1-1] DEVE supportare il MIDI su tutti i trasporti hardware compatibili con MIDI per i quali viene fornita una connettività generica non MIDI, laddove tali trasporti siano:

  • Modalità host USB, sezione 7.7
  • MIDI over Bluetooth LE con ruolo centrale, sezione 7.4.3

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

• [C-1-3] DEVE includere libamidi.so (supporto MIDI nativo)

• DEVE supportare la modalità periferica MIDI over USB, sezione 7.7

5.10. Audio professionale

Se le implementazioni dei dispositivi segnalano il supporto della funzionalità android.hardware.audio.pro tramite la classe android.content.pm.PackageManager, questi:

• [C-1-1] DEVE segnalare il supporto della funzionalità android.hardware.audio.low_latency.
• [C-1-2] DEVE avere la latenza audio di andata e ritorno continua, come definita nella sezione Latenza audio 5.6, 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 le latenze e i requisiti audio USB utilizzando l'API AAudio native audio e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [C-1-6] DEVE avere una latenza dell'output a freddo di 200 millisecondi o inferiore.
• [C-1-7] DEVE avere una latenza dell'input freddo pari o inferiore a 200 millisecondi.

• [C-1-8] DEVE avere una latenza media tocco per toni di 80 millisecondi o meno su almeno 5 misurazioni sul percorso dati speaker-microfono.

• [C-SR-1] È VIVAMENTE CONSIGLIATO per rispettare le latenze definite nella sezione Latenza audio 5.6, di 20 millisecondi o inferiore, su 5 misurazioni con deviazione media assoluta inferiore a 5 millisecondi sul percorso tra speaker e microfono.

• [C-SR-2] È VIVAMENTE CONSIGLIATO per soddisfare i requisiti del servizio Audio Pro in termini di latenza audio andata e ritorno continua, latenza di input a freddo e latenza di output a freddo e requisiti audio USB usando l'API AAudio native audio sul percorso MMAP.

• [C-SR-3] È VIVAMENTE CONSIGLIATO di fornire un livello coerente di prestazioni della CPU quando l'audio è attivo e il carico della CPU varia. Questa funzionalità deve essere testata utilizzando l'app per Android SynthMark. SynthMark utilizza un sintetizzatore software in esecuzione su un framework audio simulato che misura le prestazioni del sistema. Consulta la documentazione di SynthMark per una spiegazione dei benchmark. L'app SynthMark deve essere eseguita utilizzando l'opzione "Test automatico" e ottenere i seguenti risultati:

  • voicemark.90 >= 32 voci
  • latenzamark.fixed.little <= 15 msec
  • latenzamark.dynamic.little <= 50 msec

• DEVE ridurre al minimo l'imprecisione e la deviazione dell'orologio audio rispetto all'ora standard.

• DOVRESTI ridurre al minimo la deviazione del clock 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 in caso di audio digitale USB.

• DEVE documentare le misurazioni della latenza audio su tutti i percorsi.

• DEVE ridurre al minimo il tremolio nei tempi di ingresso del callback di completamento del buffer audio, in quanto questo interessa la percentuale utilizzabile della larghezza di banda completa della CPU da parte del callback.

• DEVE fornire zero glitch audio in condizioni di normale utilizzo alla latenza segnalata.

• DEVE fornire zero differenze di latenza tra canali.

• DEVE ridurre al minimo la latenza media MIDI su tutti i trasporti.

• DEVE ridurre al minimo la variabilità della latenza MIDI sotto carico (jitter) su tutti i trasporti.

• DOVREBBE fornire timestamp MIDI precisi su tutti i trasporti.

• DEVE ridurre al minimo il rumore del segnale audio sui trasduttori sul dispositivo, incluso il periodo immediatamente dopo l'avvio a freddo.

• DOVREBBE fornire zero differenza di orologio audio tra i lati di ingresso e di uscita degli endpoint corrispondenti, quando entrambi sono attivi. Esempi di punti finali corrispondenti includono il microfono e l'altoparlante sul dispositivo o l'ingresso e l'uscita del jack audio.

• DOVREBBE gestire i callback di completamento del buffer audio per i lati di input e di output dei punti finali corrispondenti sullo stesso thread quando entrambi sono attivi e inserire il callback di output subito dopo il ritorno dal callback di input. Oppure, se non è possibile gestire i callback sullo stesso thread, inserisci il callback di output poco dopo aver inserito il callback di input per consentire all'applicazione di avere una tempistica coerente dei lati di input e di output.

• DEVE ridurre al minimo la differenza di fase tra il buffering audio HAL per i lati di ingresso e di uscita dei punti finali corrispondenti.

• DEVE ridurre al minimo la latenza al tocco.

• DEVE ridurre al minimo la variabilità della latenza al tocco sotto carico (jitter).

Se le implementazioni dei dispositivi soddisfano tutti i requisiti di cui sopra:

• [C-SR-4] CONSIGLIATO VIVAMENTE di segnalare il supporto della funzionalità android.hardware.audio.pro tramite il corso android.content.pm.PackageManager.

Se le implementazioni del dispositivo includono un jack audio da 3,5 mm a 4 conduttori, questi:

• [C-2-1] DEVE avere una latenza media di audio andata e ritorno media, come definita nella sezione Latenza audio 5.6, di 20 millisecondi o inferiore, oltre 5 misurazioni con deviazione media assoluta inferiore a 5 millisecondi sul percorso del jack audio utilizzando una chiavetta di loopback audio.

• [C-SR-5] VIVAMENTE CONSIGLIATA di rispettare la sezione Specifiche per i dispositivi mobili (jack) della Specifica delle cuffie audio con cavo (v1.1).

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

• [C-3-1] DEVE implementare la classe audio USB.
• [C-3-2] DEVE avere una latenza media di andata e ritorno media di 25 millisecondi o inferiore, oltre 5 misurazioni con deviazione media assoluta inferiore a 5 millisecondi sulla porta in modalità host USB che utilizza la classe audio USB. (Questo può essere misurato utilizzando un adattatore USB da 3, 5 mm e un dongle di loopback audio o utilizzando un'interfaccia audio USB con cavi patch che collegano gli ingressi alle uscite).
• [C-SR-6] Sono VIVAMENTE CONSIGLIATE per il supporto di I/O simultanei fino a 8 canali per direzione, frequenza di campionamento a 96 kHz e profondità a 24 o 32 bit, se utilizzati con periferiche audio USB che supportano anche questi requisiti.
• [C-SR-7] È VIVAMENTE CONSIGLIATO di soddisfare questo gruppo di requisiti utilizzando l'API audio nativa AAudio sul percorso MMAP.

Se le implementazioni dei dispositivi includono una porta HDMI:

• DEVE supportare l'output in stereo e in otto canali a profondità di 20 o 24 bit e a 192 kHz senza perdita o ricampionamento della profondità di bit, in almeno una configurazione.

5.11. Acquisisci per i dati non elaborati

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

Se le implementazioni del dispositivo intendono supportare la sorgente audio non elaborata e renderla disponibile ad app di terze parti, l'obiettivo è:

• [C-1-1] DEVE segnalare l'assistenza tramite la proprietà android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] DEVE presentare caratteristiche approssimativamente di ampiezza piatta rispetto alla frequenza nella gamma di frequenze medie: in particolare ±10 dB da 100 Hz a 7000 Hz per ogni microfono usato per registrare la sorgente audio non elaborata.

• [C-1-3] DEVE presentare livelli di ampiezza nella gamma di frequenze basse, in particolare da ±20 dB da 5 Hz a 100 Hz rispetto alla gamma di frequenza media per ogni singolo microfono utilizzato per registrare la sorgente audio non elaborata.

• [C-1-4] DEVE presentare livelli di ampiezza nella gamma delle alte frequenze, in particolare da ±30 dB da 7000 Hz a 22 KHz rispetto alla gamma di frequenze medie di ogni singolo microfono utilizzato per registrare la sorgente audio non elaborata.

• [C-1-5] DEVE impostare la sensibilità dell'ingresso audio in modo che una sorgente di toni sinusoidali a 1000 Hz riprodotta a 94 dB di livello di pressione sonora (SPL) produca una risposta con RMS di 520 per i campioni a 16 bit (o di -36 dB Full Scale per i campioni a virgola mobile/doppia precisione audio utilizzati) per registrare ogni sorgente e ogni campionamento audio a doppia precisione.

• [C-1-6] DEVE avere un rapporto segnale-rumore (SNR) a 60 dB o superiore per ogni microfono usato per registrare la sorgente audio non elaborata. (mentre l'SNR viene misurato come differenza tra 94 dB SPL e l'equivalente SPL di rumore autonomo, ponderato A).

• [C-1-7] DEVE avere una distorsione armonica totale (THD) inferiore all'1% per un livello di ingresso di 1 kHZ a 90 dB SPL in ogni microfono usato per registrare la sorgente audio non elaborata.

• [C-1-8] DEVE non avere nessun'altra elaborazione del segnale (ad es. Controllo automatico del guadagno, Filtro passa-alto o cancellazione dell'eco) nel percorso diverso da un moltiplicatore di livello per portare il livello all'intervallo desiderato. In altre parole:

  • [C-1-9] Se per qualsiasi motivo è presente un'elaborazione del segnale nell'architettura, DEVE essere disabilitata e effettivamente introdurre zero ritardo o latenza aggiuntiva al percorso del segnale.
  • [C-1-10] Il moltiplicatore di livello, sebbene possa essere sul percorso, NON DEVE introdurre ritardo o latenza nel percorso del segnale.

Tutte le misurazioni SPL vengono effettuate direttamente accanto al microfono sottoposto a test. Per più configurazioni di microfono, questi requisiti si applicano a ciascun microfono.

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

• [C-2-1] DEVE restituire null per il metodo API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), per indicare correttamente la mancanza di supporto.
• I [C-SR-1] sono comunque VIVAMENTE CONSIGLIATI per soddisfare molti dei 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 prossimo documento.

Formato pixel

Se un decodificatore video pubblicizza il supporto per COLOR_FormatYUVP010, allora:

• [C-1-1] DEVE supportare il formato P010 per la lettura con la CPU (ImageReader, MediaImage, ByteBuffer). In Android 13, P010 è rilassato per consentire un passo arbitrario per i piani Y e UV.

• [C-1-2] Il buffer di output di P010 DEVE essere campionato dalla GPU (se allocato con l'utilizzo GPU_SAMPLING). Ciò consente la composizione GPU e la mappatura dei toni personalizzata da parte delle app.

Se un decodificatore video pubblicizza il supporto per COLOR_Format32bitABGR2101010, questo:

• [C-2-1] DEVE supportare il formato RGBA_1010102 per la superficie di output e leggibile dalla CPU (output ByteBuffer).

Se un codificatore video pubblicizza il supporto di COLOR_FormatYUVP010, questo:

• [C-3-1] DEVE supportare il formato P010 per la superficie di input e l'input scrivibile con CPU (ImageWriter, MediaImage, ByteBuffer).

Nota: in Android 13, P010 è rilassato per consentire un passo arbitrario per i piani Y e UV. (Questo formato P010 POTREBBE essere ottimizzato e diverso dal formato Camera2 P010.)

Se un codificatore video pubblicizza il supporto per COLOR_Format32bitABGR2101010, questo:

• [C-4-1] DEVE supportare il formato RGBA_1010102 per la superficie di input e l'input scrivibile con CPU (ImageWriter, ByteBuffer). Nota: la conversione tra varie curve di trasferimento NON è obbligatoria per i codificatori.

Requisiti per l'acquisizione HDR

Per tutti i codificatori video che supportano i profili HDR, le implementazioni sui dispositivi:

• [C-5-1] NON DEVE presupporre che i metadati HDR siano precisi. Ad esempio, il frame codificato potrebbe avere pixel oltre il livello di luminanza massima oppure l'istogramma potrebbe non essere rappresentativo del fotogramma.

• DEVONO aggregare i metadati dinamici HDR per generare metadati statici HDR appropriati per gli stream codificati e dovrebbero inviarli alla fine di ogni sessione di codifica.

Se le implementazioni dei dispositivi supportano l'acquisizione HDR utilizzando le API CamcorderProfile:

• [C-6-1] DEVE supportare l'acquisizione HDR anche tramite le API Camera2.

• [C-6-2] DEVE supportare almeno un codificatore video con accelerazione hardware per ogni tecnologia HDR supportata.

• [C-6-3] DEVE supportare (almeno) l'acquisizione HLG.

• [C-6-4] DEVE supportare la scrittura dei metadati HDR (se applicabile alla tecnologia HDR) nel file video acquisito. Per AV1, HEVC e DolbyVision ciò 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 dei toni da HDR a SDR nel decodificatore con accelerazione hardware predefinito per il profilo acquisito. In altre parole, se un dispositivo è in grado di acquisire HDR10+ HEVC, il decoder 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:

• DEVONO utilizzare una latenza minima per generare i metadati HDR quando non presenti, e DOVREBBERO gestire agevolmente le situazioni in cui i metadati sono presenti per alcuni frame e non per altri. Questi metadati DEVONO essere precisi (ad esempio, rappresentano l'effettiva luminanza massima e l'istogramma del fotogramma).

Se l'implementazione nel 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 utilizzano metadati HDR.

• [C-7-3] DEVE supportare i seguenti formati di input del codificatore video che conservano completamente il segnale decodificato HDR:

  • RGBA_1010102 (già nella curva di trasferimento target) sia per la superficie di input che per ByteBuffer e DEVE pubblicizzare il supporto per 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à degli strumenti e delle opzioni per 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 documentato nell'SDK Android e i comandi di shell forniti in AOSP, che possono essere utilizzati dagli sviluppatori di app, tra cui 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 dati permanente POTREBBE essere esentati dalle norme C-0-11.
  • [C-0-3] NON DEVE alterare il formato o i contenuti degli eventi di sistema del dispositivo (batterystats , diskstats, fingerprint, graphicstats, netstats, notifica, procstats) registrati tramite il comando dumpsys.
  • [C-0-10] DEVE registrare, senza omettere, e rendere i seguenti eventi accessibili e disponibili per il comando shell cmd stats e la classe API di sistema StatsManager.
    • StatoattivitàForegroundChanged
    • Rilevata anomalia
    • Report AppBreadcrumb
    • Si è verificato un arresto anomalo dell'applicazione
    • Occorrenza dell'avvio dell'applicazione
    • LivelloBatteria cambiato
    • Risparmio energeticoModeStateChanged
    • BleScanResultRicevuto
    • BleScanStateChanged
    • Stato di ricaricaModifica
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduleJobStateChanged
    • StatoScreenChanged
    • SyncStateChanged
    • SistemaElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • Si è verificato un allarme sveglia
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] DEVE avere il daemon adb lato dispositivo non attivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivare il bridge di debug Android.
  • [C-0-5] DEVE supportare ADB sicuro. Android include il supporto per l'ADB sicuro. Secure adb abilita adb su host autenticati noti.
  • [C-0-6] DEVE fornire un meccanismo che consenta ad adb di essere connesso da una macchina host. Nello specifico:

  Se le implementazioni dei dispositivi senza una porta USB supportano la modalità periferica:

  • [C-3-1] DEVE implementare adb tramite una rete locale (come Ethernet o Wi-Fi).
  • [C-3-2] DEVE fornire driver per Windows 7, 8 e 10, consentendo agli sviluppatori di connettersi al dispositivo utilizzando il protocollo adb.

  Se le implementazioni del dispositivo supportano le connessioni adb a un computer host tramite Wi-Fi o Ethernet, questi:

  • [C-4-1] DEVE avere il metodo AdbManager#isAdbWifiSupported() restituire true.

  Se le implementazioni del dispositivo supportano le connessioni adb a un computer host tramite Wi-Fi o Ethernet e include almeno una videocamera, questi:

  • [C-5-1] DEVE avere il metodo AdbManager#isAdbWifiQrSupported() restituire true.

• Dalvik Debug Monitor (DDMS)

  • [C-0-7] DEVE supportare tutte le funzionalità DDMS come documentato nell'SDK per Android. Poiché ddms utilizza adb, il supporto di ddms DEVE essere inattivo per impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato Android Debug Bridge, come descritto sopra.

• SysTrace

  • [C-0-9] DEVE supportare lo strumento Systrace come documentato nell'SDK per Android. Systrace deve essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile dall'utente per attivarlo.

• Perfetto

  • [C-SR-1] È VIVAMENTE CONSIGLIATO di esporre un file binario /system/bin/perfetto all'utente shell quale cmdline rispetta la documentazione perfetta.
  • [C-SR-2] Il programma binario perfetto è VIVAMENTE CONSIGLIATO di accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
  • [C-SR-3] Il programma binario perfetto è VIVAMENTE CONSIGLIATO di scrivere come output una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
  • [C-SR-4] È VIVAMENTE CONSIGLIATO di fornire, tramite il programma binario perfetto, almeno le origini dati descritte nella documentazione relativa al perfetto.

• Minore memoria

  • [C-0-12] DEVE scrivere un Atom LMK_KILL_OCCURRED_FIELD_NUMBER nel log delle statistiche quando un'app viene terminata dal Low Memory Killer.

• Modalità test Harness Se le implementazioni dei dispositivi supportano il comando shell cmd testharness ed eseguono cmd testharness enable, questi:

  • [C-2-1] DEVE restituire true per ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] DEVE implementare la modalità test Harness come descritto nella documentazione relativa alla modalità di test.

• Informazioni di lavoro delle 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 tracciamento del kernel power/gpu_work_period oppure non visualizzare nessun dato se il tracepoint non è supportato. L'implementazione di AOSP è frameworks/native/services/gpuservice/gpuwork/.

Se le implementazioni dei dispositivi segnalano il supporto di Vulkan 1.0 o versioni successive tramite i flag delle funzionalità android.hardware.vulkan.version:

• [C-1-1] DEVE fornire un'invito allo sviluppatore dell'app per attivare/disattivare i livelli di debug delle GPU.
• [C-1-2] DEVE, quando i livelli di debug GPU sono abilitati, enumerare i livelli nelle librerie fornite dagli strumenti esterni (ovvero che non fanno parte della piattaforma o del pacchetto dell'applicazione) trovati nella directory di base delle applicazioni di cui è possibile eseguire il debug per supportare i metodi API vkEnumerateInstancelayerProperties() e vkCreateInstance().

6.2. Opzioni sviluppatore

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

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

• [C-0-1] DEVE rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo delle applicazioni. L'implementazione upstream di Android nasconde per impostazione predefinita il menu Opzioni sviluppatore e consente agli utenti di avviare Opzioni sviluppatore dopo aver premuto sette (7) volte sulla voce 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 anziché a un'altra per attivare le Opzioni sviluppatore. DEVE fornire un documento o un sito web visibile pubblicamente che descriva come attivare le Opzioni sviluppatore. Questo documento o sito web DEVE essere collegato ai documenti dell'SDK Android.
• DOVREBBE avere una notifica visiva continua per l'utente quando le Opzioni sviluppatore sono attivate e la sicurezza dell'utente è preoccupata.
• POTREBBE limitare temporaneamente l'accesso al menu Opzioni sviluppatore, nascondendo visivamente o disattivando il menu, per evitare distrazioni nei casi in cui la sicurezza dell'utente è preoccupante.

7. Compatibilità hardware

Se un dispositivo include un particolare 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 che è stato dichiarato facoltativo e l'implementazione del dispositivo non possiede questo componente:

• [C-0-2] Le definizioni complete delle classi (come documentate dall'SDK) per le API del componente DEVONO comunque essere presentate.
• [C-0-3] I comportamenti dell'API DEVONO essere implementati come operativi in modo ragionevole.
• [C-0-4] I metodi API DEVONO restituire valori nulli ove consentito dalla documentazione dell'SDK.
• [C-0-5] I metodi API DEVONO restituire implementazioni senza intervento 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 riportare costantemente informazioni accurate sulla configurazione hardware tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) nella classe android.content.pm.PackageManager per la stessa fingerprint della build.

Un esempio tipico di scenario in cui si applicano questi requisiti è l'API di telefonia: anche sui dispositivi diversi dagli smartphone, queste API devono essere implementate in modo ragionevole.

7.1 Display e grafica

Android include funzionalità che regolano automaticamente gli asset delle applicazioni e i layout dell'interfaccia utente in modo appropriato per il dispositivo per garantire che le applicazioni di terze parti funzionino correttamente su serie di configurazioni hardware. serie di display e configurazioni hardware. Un display compatibile con Android è uno schermo che implementa tutti i comportamenti e le API descritti in Android Developers - Panoramica sulla compatibilità dello schermo, in questa sezione (7.1) e nelle relative sottosezioni, nonché in qualsiasi altro comportamento specifico per tipo di dispositivo documentato nella sezione 2 di questo CDD. Sui display compatibili con Android in 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 dettaglio in questa sezione.

Crea nuovi requisiti

Implementazioni dei dispositivi:

• [C-0-1] DEVE, per impostazione predefinita, eseguire il rendering delle applicazioni di terze parti solo su display compatibili con Android.

Termina nuovi requisiti

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

• dimensione diagonale fisica. La distanza in pollici tra due angoli contrapposti della parte illuminata del display.
• densità dei punti per pollice (dpi). Il numero di pixel inclusi in un'area lineare orizzontale o verticale di 1", espresso in pixel per pollice (ppi o dpi). Quando sono elencati i valori dpi ppi e dpi, i dpi orizzontali e verticali devono rientrare nell'intervallo elencato.
• proporzioni. Il rapporto tra i pixel della dimensione più lunga e la dimensione più breve dello schermo. Ad esempio, un display di 480 x 854 pixel corrisponde a 854/480 = 1,779, ovvero a "16:9".
• pixel indipendenti dalla densità (dp). L' unità pixel virtuale normalizzata per uno schermo da 160 dpi con una densità dello schermo pari a 160. Per alcuni valori di densità d e numero di pixel p, il numero di pixel indipendenti dalla densità dp viene calcolato come segue: pixel = dps * (density/160) dp = (160 / d) * p .

7.1.1. Configurazione schermata

7.1.1.1. Dimensioni e forma dello schermo

Il framework della UI di Android supporta una varietà di dimensioni logiche di layout dello schermo e consente alle applicazioni di eseguire query sulle dimensioni del layout dello schermo della configurazione attuale tramite Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK e Configuration.smallestScreenWidthDp.

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare la dimensione del layout corretta per Configuration.screenLayout, come definito nella documentazione dell'SDK Android. In particolare, le implementazioni dei dispositivi DEVONO indicare le dimensioni dello schermo corrette in pixel indipendenti dalla densità logica (dp), come riportato di seguito:

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

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

• POTREBBE avere display compatibili con Android con angoli arrotondati.

Se le implementazioni dei dispositivi supportano schermi che supportano la UI_MODE_TYPE_NORMAL configurazione delle dimensioni e includono schermi compatibili con Android utilizzano display fisici con gli angoli arrotondati per il rendering di questi schermi, che:

• [C-1-1] DEVE garantire che sia soddisfatto almeno uno dei seguenti requisiti per ogni display di questo tipo:

  • Il raggio degli angoli arrotondati è inferiore o uguale a 38 dp.
  • Quando una casella con 15 e 18 dp per 1518 dp è ancorata in ogni angolo del display logico, almeno un pixel di ogni riquadro è visibile sullo schermo.

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

Crea nuovi requisiti

Se le implementazioni del dispositivo supportano soltanto la configurazione da tastiera NO_KEYS e intendi segnalare il supporto per la configurazione della modalità UI UI_MODE_TYPE_NORMAL:

• [C-4-1] DEVE avere le dimensioni del layout, esclusi eventuali ritagli dello schermo, di almeno 596 dp x 384 dp o superiori.

Termina nuovi requisiti

Se le implementazioni dei dispositivi includono uno o più display compatibili con Android pieghevoli o che includono una cerniera pieghevole tra più pannelli del display e rendono disponibili questi display per il rendering di app di terze parti, questi:

• [C-2-1] DEVE implementare l'ultima versione stabile disponibile dell'API Extensions o la versione stabile dell'API Sidecar che deve essere utilizzata dalla libreria Window Manager Jetpack.

Se le implementazioni dei dispositivi includono uno o più display compatibili con Android pieghevoli o che includono una cerniera pieghevole tra più pannelli display e se la cerniera o la piegatura attraversa una finestra dell'applicazione a schermo intero, questi:

• [C-3-1] DEVE segnalare la posizione, i limiti e lo stato della cerniera o di piegare le estensioni o le API collaterali all'applicazione.

Per maggiori dettagli sulla corretta implementazione delle API collaterali o di estensione, consulta la documentazione pubblica di Window Manager Jetpack.

Crea nuovi requisiti

Se le implementazioni dei dispositivi includono una o più aree pieghevoli compatibili con Android o includono una cerniera pieghevole tra più aree di pannelli compatibili con Android e le mettono a disposizione delle applicazioni, queste:

• [C-4-1] DEVE implementare la versione corretta del livello API Estensioni Window Manager come descritto in Estensioni WindowsManager.

Termina nuovi requisiti

7.1.1.2. Proporzioni dello schermo

Anche se non sono previste limitazioni alle proporzioni del display fisico per i display compatibili con Android, le proporzioni del display logico su cui viene eseguito il rendering delle app di terze parti, che possono essere derivate dai valori di altezza e larghezza riportati tramite le API view.Display e le API Configurazione, DEVONO soddisfare i seguenti requisiti:

• [C-0-1] Le implementazioni dei dispositivi con l'opzione Configuration.uiMode impostata su UI_MODE_TYPE_NORMAL DEVONO avere un valore per le proporzioni inferiore o uguale a 1,86 (circa 16:9), a meno che l'app non soddisfi una delle seguenti condizioni:

  • L'app ha dichiarato di supportare proporzioni dello schermo più grandi tramite il valore dei metadati android.max_aspect.
  • L'app dichiara che è ridimensionabile tramite l'attributo android:resizeableActivity.
  • L'app ha come target il livello API 24 o versioni successive e non dichiara un android:maxAspectRatio che limiterebbe le proporzioni consentite.

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

7.1.1.3. Densità schermo

Il framework della UI di Android definisce un insieme di densità logiche standard per aiutare gli sviluppatori di applicazioni a scegliere come target le risorse delle applicazioni.

Implementazioni dei dispositivi:

• [C-0-1] Per impostazione predefinita, le implementazioni dei dispositivi DEVONO segnalare solo una delle densità del framework Android elencate in DisplayMetrics tramite l'API DENSITY_DEVICE_STABLE e questo valore deve essere un valore statico per ogni display fisico. NON DEVE cambiare in qualsiasi momento; tuttavia, Tuttavia il dispositivo POTREBBE segnalare una densità arbitraria DisplayMetrics.density diversa a seconda delle modifiche alla configurazione del display apportate dall'utente (ad esempio, le dimensioni di visualizzazione) impostate dopo l'avvio iniziale.

• Le implementazioni dei dispositivi DEVONO definire la densità del framework Android standard numericamente più vicina alla densità fisica dello schermo, a meno che questa densità logica non spinga le dimensioni dello schermo riportate al di sotto del minimo supportato. Se la densità del framework Android standard numericamente più vicina alla densità fisica risulta in una dimensione dello schermo inferiore a quella minima supportata dello schermo compatibile (320 dp di larghezza), le implementazioni dei dispositivi DEVONO segnalare la densità successiva più bassa del framework Android standard.

Crea nuovi requisiti

• DEVE definire la densità standard del framework Android che è numericamente più vicina alla densità fisica dello schermo, oppure un valore che verrebbe mappato alle stesse misurazioni del campo visivo angolare equivalente di un dispositivo portatile.

Termina nuovi requisiti

Se le implementazioni dei dispositivi forniscono esiste un'autorizzazione per modificare le dimensioni di visualizzazione del dispositivo, :

• [C-1-1] Le dimensioni del display NON DEVONO essere ridimensionate NON DEVONO scalare il display oltre 1,5 volte la densità nativa della DENSITY_DEVICE_STABLE o produrre una dimensione minima effettiva dello schermo inferiore a 320 dp (equivalente al qualificatore risorsa sw320dp), a seconda dell'evento che si verifica per primo.
• [C-1-2] Le dimensioni del display NON DEVONO essere ridimensionate NON DEVE scalare il display inferiore a 0,85 volte la densità nativa di DENSITY_DEVICE_STABLE.
• Per garantire una buona usabilità e dimensioni dei caratteri coerenti, ti consigliamo di fornire la seguente scalabilità delle opzioni di display nativo (nel rispetto dei limiti specificati sopra):
  • Piccola: 0,85x
  • Valore predefinito: 1x (scala display nativa)
  • Grande: 1,15x
  • Più grande: 1,3x
  • Il più grande 1,45x

7.1.2. Metriche di visualizzazione

Se le implementazioni dei dispositivi includono display o output video compatibili con Android agli schermi dei display compatibili con Android, questi:

• [C-1-1] DEVE segnalare i valori corretti per tutte le metriche di visualizzazione compatibili con Android definite nell'API android.util.DisplayMetrics.

Se le implementazioni dei dispositivi non includono una schermata o un output video incorporati:

• [C-2-1] DEVE segnalare i valori corretti del display compatibile con Android come definito nell'API android.util.DisplayMetrics per il valore predefinito emulato view.Display.

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 schermo orizzontale con orientamento fisso, come una televisione o un laptop, DOVREBBE indicare solo android.hardware.screen.landscape.
• [C-0-2] DEVE segnalare il valore corretto per l'orientamento attuale del dispositivo, ogni volta che viene eseguita una query tramite android.content.res.Configuration.orientation, android.view.Display.getOrientation() o altre API.

Se le implementazioni del dispositivo supportano entrambi gli orientamenti dello schermo:

• [C-1-1] DEVE supportare l'orientamento dinamico delle applicazioni con l'orientamento dello schermo verticale o orizzontale. Ciò significa che il dispositivo deve rispettare la richiesta dell'applicazione relativa a un orientamento specifico dello schermo.
• [C-1-2] NON DEVE modificare le dimensioni o la densità dello schermo segnalate quando cambi l'orientamento.
• POTREBBE selezionare l'orientamento verticale o orizzontale come impostazione predefinita.

7.1.4. Accelerazione delle schede grafiche 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 e 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 corrispondenti e delle API native per ogni versione OpenGL ES da supportare.

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

• [C-1-1] DEVE supportare sia OpenGL ES 1.1 che 2.0, come incorporato e descritto in dettaglio nella documentazione relativa all'SDK per Android.
• [C-SR-1] È VIVAMENTE CONSIGLIATO il supporto di OpenGL ES 3.1.
• DEVE supportare OpenGL ES 3.2.

I test dEQP OpenGL ES sono partizionati in una serie di elenchi di test, ciascuno con un numero di data/versione associato. Si trovano nella struttura di origine Android all'indirizzo external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt. Un dispositivo che supporta OpenGL ES a un livello segnalato autonomamente indica che può superare i test dEQP in tutti gli elenchi di test di questo livello e di quelli precedenti.

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

• [C-2-1] DEVE segnalare tramite le API gestite OpenGL ES e le API native altre eventuali estensioni OpenGL ES implementate e, viceversa, NON DEVE segnalare stringhe di estensioni che non supportano.
• [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 supportati tramite il flag funzionalità android.software.opengles.deqp.level.
• [C-2-4] DEVE supportare almeno la versione 132383489 (dal 1° marzo 2020) come segnalato 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 flag della funzionalità android.software.opengles.deqp.level, per ogni versione di OpenGL ES supportata.
• [C-SR-2] È VIVAMENTE CONSIGLIATO di supportare le estensioni EGL_KHR_partial_update e OES_EGL_image_external.

• DEVONO segnalare con precisione tramite il metodo getString() qualsiasi formato di compressione delle texture supportato, che in genere è specifico del fornitore.

• DEVONO supportare le estensioni EGL_IMG_context_priority e EGL_EXT_protected_content.

Se le implementazioni dei dispositivi dichiarano il supporto per OpenGL ES 3.0, 3.1 o 3.2:

• [C-3-1] DEVE esportare i simboli di funzione corrispondenti per questa versione oltre ai simboli di funzione OpenGL ES 2.0 nella libreria libGLESv2.so.
• [C-SR-3] È VIVAMENTE CONSIGLIATO di supportare l'estensione OES_EGL_image_external_essl3.

Se le implementazioni dei dispositivi supportano OpenGL ES 3.2:

• [C-4-1] DEVE supportare completamente il pacchetto di estensioni Android OpenGL ES.

Se le implementazioni dei dispositivi supportano completamente il pacchetto di estensioni Android OpenGL ES, le implementazioni:

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

Se le implementazioni del dispositivo espongono il supporto per l'estensione EGL_KHR_mutable_render_buffer:

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

7.1.4.2 Vulkan

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

Se le implementazioni dei dispositivi supportano OpenGL ES 3.1:

• [C-SR-1] CONSIGLIATO VIVAMENTE di includere il supporto per Vulkan 1.3.
• [C-4-1] NON DEVE supportare una versione di variante Vulkan (ovvero la parte della variante della versione principale Vulkan DEVE essere zero).

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

• [C-SR-2] Ti consigliamo vivamente di includere il supporto per Vulkan 1.3.

I test Vulkan dEQP sono suddivisi in vari elenchi di test, ciascuno con una data/versione associata. Si trovano nella struttura di origine Android all'indirizzo 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 di questo livello e di quelli precedenti.

Se le implementazioni dei dispositivi includono il supporto per Vulkan 1.0 o versioni successive, questi:

• [C-1-1] DEVE segnalare il valore intero corretto con i flag delle funzionalità android.hardware.vulkan.level e android.hardware.vulkan.version.
• [C-1-2] DEVE enumerare almeno un VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices().
• [C-1-3] DEVE implementare completamente le API Vulkan 1.0 Vulkan 1.1 per ogni API enumerata VkPhysicalDevice.
• [C-1-4] DEVE enumerare i livelli, contenuti nelle librerie native denominate libVkLayer*.so nella directory della libreria nativa del pacchetto dell'applicazione, tramite le API native Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties().
• [C-1-5] NON DEVE enumerare i livelli forniti dalle librerie al di fuori del pacchetto dell'applicazione, né fornire altri modi per tracciare o intercettare l'API Vulkan, a meno che l'applicazione non abbia l'attributo android:debuggable impostato su true o i metadati com.android.graphics.injectLayers.enable impostati su true .
• [C-1-6] DEVONO segnalare tutte le stringhe di estensione supportate tramite le API native di Vulkan e NON DEVONO segnalare le stringhe di estensioni che non supportano 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] DEVE segnalare la versione massima dei test Vulkan dEQP supportati tramite il flag della funzionalità android.software.vulkan.deqp.level.
• [C-1-9] DEVE supportare almeno la versione 132317953 (dal 1° marzo 2019) come segnalato 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 della funzionalità android.software.vulkan.deqp.level.
• [C-1-11] NON DEVE enumerare il supporto per le estensioni VK_KHR_video_queue, VK_KHR_video_decode_queue o VK_KHR_video_encode_queue.
• [C-SR-3] È VIVAMENTE CONSIGLIATO di supportare le estensioni VK_KHR_driver_properties e VK_GOOGLE_display_timing.

• DOVREBBE supportare VkPhysicalDeviceProtectedMemoryFeatures e VK_EXT_global_priority.

• [C-1-12] NON DEVE enumerare il supporto per l'estensione VK_KHR_performance_query.

Crea nuovi requisiti

• [C-1-13] DEVE soddisfare i requisiti specificati dal profilo Android Baseline 2021.

Termina nuovi requisiti

• [C-SR-4] È VIVAMENTE CONSIGLIATO per soddisfare i requisiti specificati dal profilo di base di Android Baseline 2022.

Crea nuovi requisiti

• [C-SR-5] È VIVAMENTE CONSIGLIATO di supportare VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory e VK_EXT_global_priority.

• [C-SR-6] Ti consigliamo VIVAMENTE di usare SkiaVk con HWUI.

Termina nuovi requisiti

Se le implementazioni dei dispositivi non includono il supporto per Vulkan 1.0:

• [C-2-1] NON DEVE dichiarare nessuno dei flag delle funzionalità Vulkan (ad es. android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] NON DEVE enumerare VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices().

Se le implementazioni dei dispositivi includono il supporto per Vulkan 1.1 e dichiarano uno qualsiasi dei flag delle funzionalità di Vulkan descritti qui , questi:

• [C-3-1] DEVE esporre il supporto per il semaforo esterno SYNC_FD e di gestire i tipi e l'estensione VK_ANDROID_external_memory_android_hardware_buffer.

Crea nuovi requisiti

• [C-SR-7] È VIVAMENTE CONSIGLIATO di rendere l'estensione VK_KHR_external_fence_fd disponibile per le applicazioni di terze parti e di consentire all'applicazione di esportare il payload del recinto e di importare il payload del recinto dai descrittori dei file POSIX, come descritto qui.

Termina nuovi requisiti

7.1.4.3 RenderScript

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

7.1.4.4 Accelerazione della grafica 2D

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

Implementazioni dei dispositivi:

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

Android include un oggetto TextureView che consente agli sviluppatori di integrare direttamente trame 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 upstream.

7.1.4.5 Display ad ampia gamma

Se le implementazioni dei dispositivi dichiarano il supporto di display ad ampia gamma tramite Configuration.isScreenWideColorGamut() , questi:

• [C-1-1] DEVE avere un display con calibrazione del colore.
• [C-1-2] DEVE avere un display la cui gamma copre la gamma di colori sRGB interamente nello spazio xyY CIE 1931.
• [C-1-3] DEVE avere un display la cui gamma abbia un'area di almeno il 90% dello spazio 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 delle 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] È VIVAMENTE CONSIGLIATO di supportare GL_EXT_sRGB.

Al contrario, se le implementazioni dei dispositivi non supportano i display ad alta gamma:

• [C-2-1] DEVE coprire il 100% o più dello sRGB nello spazio CIE 1931 xyY, sebbene la gamma di colori dello schermo non sia definita.

7.1.5. Modalità di compatibilità delle applicazioni legacy

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

7.1.6. Tecnologia dello schermo

La piattaforma Android include API che consentono alle applicazioni di eseguire il rendering di grafiche avanzate su un display compatibile con Android. I dispositivi DEVONO supportare tutte queste API come definito dall'SDK Android, a meno che non siano specificamente consentiti in questo documento.

Tutti i display compatibili con Android nell'implementazione di un dispositivo:

• [C-0-1] DEVE essere in grado di eseguire il rendering di grafica a colori a 16 bit.
• DOVREBBE supportare display con grafica a colori a 24 bit.
• [C-0-2] DEVE essere in grado di visualizzare le animazioni.
• [C-0-3] DEVE avere proporzioni pixel (PAR) tra 0,9 e 1,15. In altre parole, le proporzioni dei pixel DEVONO essere quasi quadrate (1,0) con una tolleranza del 10-15%.

7.1.7. Display secondari

Android include il supporto di display secondari compatibili con Android per attivare le funzionalità di condivisione dei contenuti multimediali e le API per sviluppatori per accedere a display esterni.

Se le implementazioni dei dispositivi supportano un display esterno tramite una connessione display aggiuntiva cablata, wireless o incorporata:

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

7.2. Dispositivi di immissione

Implementazioni dei dispositivi:

• [C-0-1] DEVE includere un meccanismo di inserimento, ad esempio una navigazione touchscreen o una navigazione non touch, per spostarsi tra gli elementi dell'interfaccia utente.

7.2.1. Tastiera

Se le implementazioni del dispositivo includono il supporto per applicazioni IME (Input Method Editor) di terze parti, queste:

• [C-1-1] DEVE dichiarare il flag della funzionalità android.software.input_methods.
• [C-1-2] DEVE implementare 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 corrisponde a uno dei formati specificati in android.content.res.Configuration.keyboard (QWERTY o a 12 tasti).
• DEVE includere ulteriori implementazioni della tastiera su schermo.
• POTREBBE includere una tastiera hardware.

7.2.2. Navigazione non touch

Android include il supporto di D-pad, trackball e wheel come meccanismi per la navigazione non touch.

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare il valore corretto per android.content.res.Configuration.navigation.

Se le implementazioni del dispositivo non dispongono di navigazioni non touch, questi:

• [C-1-1] DEVE fornire un meccanismo di interfaccia utente alternativo e ragionevole per la selezione e la modifica del testo, compatibile con i motori di gestione degli input. L'implementazione open source di Android upstream include un meccanismo di selezione adatto all'utilizzo con dispositivi privi di input di navigazione non touch.

7.2.3. Tasti di navigazione

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

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

Se vengono fornite le funzioni Home, Recenti o Indietro, queste:

• [C-1-1] DEVE essere accessibile con una singola azione (ad es. tocco, doppio clic o gesto) quando una di esse è accessibile.
• [C-1-2] DEVE fornire una chiara indicazione di quale singola azione attiverà ciascuna funzione. Avere un'icona visibile impressa sul pulsante, mostrare un'icona del software nella parte dello schermo relativa alla barra di navigazione o guidare l'utente in una procedura demo guidata passo passo durante l'esperienza di configurazione pronta all'uso sono esempi di questo tipo di indicazione.

Implementazioni dei dispositivi:

• [C-SR-1] è VIVAMENTE CONSIGLIATO di non fornire il meccanismo di immissione per la funzione Menu in quanto è deprecata a favore della barra delle azioni da Android 4.0.

• [C-SR-2] Sono VIVAMENTE CONSIGLIATI per fornire tutte le funzioni di navigazione come annullabili. "Annullabile" è la capacità dell'utente di impedire l'esecuzione della funzione di navigazione (ad es. tornare alla schermata Home, tornare indietro e così via) se lo scorrimento non viene rilasciato oltre una certa soglia.

Se le implementazioni dei dispositivi forniscono la funzione Menu, queste:

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

Se le implementazioni del dispositivo non offrono la funzione Menu, per la compatibilità con le versioni precedenti: * [C-3-1] DEVE rendere disponibile la funzione Menu alle applicazioni quando targetSdkVersion è inferiore a 10, tramite un pulsante fisico, un tasto software o gesti. Questa funzione del menu deve essere accessibile, a meno che non sia nascosta insieme ad altre funzioni di navigazione.

Se le implementazioni dei dispositivi forniscono la funzione di assistenza, l'implementazione di questi dispositivi:

• [C-4-1] DEVE rendere accessibile la funzione Assist con una singola azione (ad es. tocco, doppio clic o gesto) quando gli altri tasti di navigazione sono accessibili.
• [C-SR-3] VIVAMENTE CONSIGLIATO di usare la pressione prolungata sulla funzione HOME come interazione designata.

Se le implementazioni dei dispositivi utilizzano una porzione distinta dello schermo per visualizzare le chiavi di navigazione, queste:

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

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() DEVE essere utilizzato solo per segnalare l'area di riconoscimento 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 purché il rettangolo di esclusione sia consentito entro il limite massimo di esclusione specificato nella documentazione di View#setSystemGestureExclusionRects().
• [C-6-3] DEVE inviare all'app in primo piano un evento MotionEvent.ACTION_CANCEL una volta che i tocchi iniziano a essere intercettati per un gesto di sistema, se all'app in primo piano è stato precedentemente inviato un evento MotionEvent.ACTION_DOWN.
• [C-6-4] DEVE fornire all'utente l'invito a passare a una navigazione sullo schermo basata su pulsanti (ad esempio, in Impostazioni).
• DOVREBBE offrire la funzione Home come scorrimento verso l'alto dal bordo inferiore dell'orientamento corrente dello schermo.
• DOVREBBE offrire la funzione Recenti, ad esempio scorrere verso l'alto e tenere premuto prima di rilasciarlo, dalla stessa area del gesto Home.
• I gesti che iniziano all'interno di WindowInsets#getMandatorySystemGestureInsets() NON DEVONO essere interessati dai retti di esclusione forniti dall'applicazione in primo piano tramite View#setSystemGestureExclusionRects().

Se viene fornita una funzione di navigazione 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 consentire di scorrere dai bordi sinistro e destro dell'orientamento corrente dello schermo.
• [C-7-2] Se sui bordi sinistro o destro vengono forniti riquadri di sistema con possibilità di scorrimento personalizzati, DEVONO essere posizionati all'interno del terzo superiore dello schermo con un'indicazione visiva chiara e persistente che il trascinamento potrebbe richiamare i riquadri sopra menzionati, e quindi non Indietro. Un pannello di sistema POTREBBE essere configurato da un utente in modo che arrivi sotto il terzo superiore dei bordi dello schermo, ma il pannello del sistema NON DEVE utilizzare più di 1/3 dei bordi.
• [C-7-3] Quando l'app in primo piano ha i flag View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE flag impostati, che passano dal documento SDK.
• [C-7-4] Se l'app in primo piano presenta View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE flag impostati, i pannelli di navigazione personalizzati vengono implementati con le barre di navigazione A scorrimento personalizzate

Se è disponibile la funzione di navigazione a ritroso e l'utente annulla il gesto Indietro:

• [C-8-1] DEVE essere chiamato OnBackInvokedCallback.onBackCancelled().
• [C-8-2] NON DEVE essere chiamato OnBackInvokedCallback.onBackInvoked().
• [C-8-3] L'evento KEYCODE_BACK NON DEVE essere inviato.

Se viene fornita la funzione di navigazione a ritroso, ma l'applicazione in primo piano NON ha un OnBackInvokedCallback registrato, allora:

• Il sistema DEVE fornire un'animazione per l'applicazione in primo piano che suggerisca che l'utente sta tornando indietro, come fornito in AOSP.

Se le implementazioni dei dispositivi forniscono il supporto per l'API di sistema setNavBarMode per consentire a qualsiasi app di sistema con l'autorizzazione android.permission.STATUS_BAR di impostare la modalità della barra di navigazione,:

• [C-9-1] DEVE fornire supporto per icone a misura di bambino o per la navigazione basata su pulsanti, come fornito nel codice AOSP.

7.2.4. Ingresso touchscreen

Android include il supporto di diversi sistemi di input del puntatore, come touchscreen, touchscreen e dispositivi di input tocco falsi. Le implementazioni dei dispositivi basate su touchscreen sono associate a un display in modo che l'utente abbia l'impressione di manipolare direttamente gli elementi sullo schermo. Poiché l'utente tocca direttamente lo schermo, il sistema non richiede ulteriori inviti per indicare gli oggetti manipolati.

Implementazioni dei dispositivi:

• DOVREBBE avere un sistema di input del puntatore di qualche tipo (simile a un mouse o a un tocco).
• DEVONO supportare puntatori monitorati in modo completamente indipendente.

Se le implementazioni dei dispositivi includono un touchscreen (singolo tocco o migliore) su un display principale compatibile con Android, questi:

• [C-1-1] DEVE segnalare TOUCHSCREEN_FINGER per il campo API Configuration.touchscreen.
• [C-1-2] DEVE segnalare i flag funzionalità android.hardware.touchscreen e android.hardware.faketouch.

Se le implementazioni del dispositivo includono un touchscreen che può monitorare più di un singolo tocco su un display principale compatibile con Android, questi:

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

Se le implementazioni del dispositivo si basano su un dispositivo di input esterno come un mouse o una trackball (ovvero non toccano direttamente lo schermo) per l'input su un display principale compatibile con Android e soddisfano i requisiti di tocco falsi nella sezione 7.2.5, questi:

• [C-3-1] NON DEVE segnalare eventuali flag di funzionalità che iniziano con android.hardware.touchscreen.
• [C-3-2] DEVE segnalare solo android.hardware.faketouch.
• [C-3-3] DEVE segnalare TOUCHSCREEN_NOTOUCH per il campo API Configuration.touchscreen.

7.2.5. Input tocco fittizio

L'interfaccia touch fittizia fornisce un sistema di input dell'utente che si avvicina a un sottoinsieme di funzionalità touchscreen. Ad esempio, un mouse o un telecomando che attiva il cursore sullo schermo è simile al tocco, ma richiede all'utente di puntare o impostare lo stato attivo e poi di fare clic. Numerosi dispositivi di input, come mouse, trackpad, air mouse basato su giroscopio, giroscopio, joystick e trackpad multi-touch, possono supportare interazioni false con il tocco. Android include la funzionalità constant android.hardware.faketouch, che corrisponde a un dispositivo di input non touch ad alta precisione (basato su puntatore), come un mouse o un trackpad in grado di emulare adeguatamente l'input basato sul tocco (incluso il supporto tramite gesti di base), e indica che il dispositivo supporta un sottoinsieme emulato di funzionalità touchscreen.

Se le implementazioni del dispositivo non includono un touchscreen, ma includono un altro sistema di input del puntatore che si vuole rendere disponibile, l'azione:

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

Se le implementazioni dei dispositivi dichiarano il supporto per android.hardware.faketouch:

• [C-1-1] DEVE indicare le posizioni assolute nello schermo X e Y della posizione del puntatore e mostrare un puntatore visivo sullo schermo.
• [C-1-2] DEVE segnalare l'evento touch con il codice di azione che specifica la modifica dello stato che si verifica sul puntatore che va in basso o in alto sullo schermo.
• [C-1-3] DEVE supportare il puntatore verso il basso e verso l'alto su un oggetto sullo schermo, che consente agli utenti di emulare il tocco su un oggetto sullo schermo.
• [C-1-4] DEVE supportare i puntatori verso il basso, verso l'alto e verso il basso e poi verso l'alto nella stessa posizione su un oggetto dello schermo entro una soglia temporale, che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo.
• [C-1-5] DEVE supportare il puntatore verso il basso in un punto arbitrario dello schermo, lo spostamento del puntatore verso qualsiasi altro punto arbitrario sullo schermo, seguito da un puntatore verso l'alto, che consente agli utenti di emulare un trascinamento al tocco.
• [C-1-6] DEVE supportare il puntatore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in una posizione diversa sullo schermo e poi di puntare il puntatore verso l'alto sullo schermo, consentendo agli utenti di far scorrere un oggetto sullo schermo.

Se le implementazioni dei dispositivi dichiarano il supporto per android.hardware.faketouch.multitouch.distinct, questi:

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

Se le implementazioni dei dispositivi dichiarano il supporto per android.hardware.faketouch.multitouch.jazzhand, questi:

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

7.2.6. Supporto del controller di gioco

7.2.6.1. Mappature pulsanti

Implementazioni dei dispositivi:

• [C-1-1] DEVE essere in grado di mappare gli eventi HID alle costanti InputEvent corrispondenti, come indicato nelle tabelle di seguito. L'implementazione upstream di Android soddisfa questo requisito.

Se le implementazioni nei dispositivi incorporano un controller o vengono fornite con un controller separato nella confezione che fornirebbero un mezzo per inserire tutti gli eventi elencati nelle tabelle seguenti, questi:

• [C-2-1] DEVE dichiarare il flag della funzionalità android.hardware.gamepad

Pulsante	Utilizzo HID^2	Pulsante Android
R^1	0x09 0x0001	KEYCODE_PULSANTE_A (96)
M^1	0x09 0x0002	KEYCODE_PULSANTE_B (97)
X^1	0x09 0x0004	KEYCODE_PULSANTE_X (99)
A^1	0x09 0x0005	KEYCODE_PULSANTE_Y (100)
D-pad in alto^1 D-pad in basso^1	0x01 0x0039^3	AXIS_HAT_Y^4
D-pad sinistro1 D-pad destro^1	0x01 0x0039^3	AXIS_HAT_X^4
Pulsante sulla spalla sinistra^1	0x09 0x0007	KEYCODE_PULSANTE_L1 (102)
Pulsante sulla spalla destra^1	0x09 0x0008	KEYCODE_PULSANTE_R1 (103)
Clic sulla levetta sinistra^1	0x09 0x000E	KEYCODE_button_THUMBL (106)
Clic sulla levetta destra^1	0x09 0x000F	KEYCODE_Button_THUMBR (107)
Indietro^1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Gli utilizzi HID riportati sopra devono essere dichiarati all'interno di un Gamepad CA (0x01 0x0005).

3 Questo utilizzo deve avere un minimo logico di 0, un massimo logico di 7, un minimo fisico di 0, un massimo fisico di 315, le unità in gradi e una dimensione del report di 4. Il valore logico è definito come la rotazione in senso orario dall'asse verticale; ad esempio, un valore logico 0 rappresenta l'assenza di rotazione e il pulsante Su che viene premuto, mentre il valore logico 1 rappresenta una rotazione di 45 gradi e vengono premuti entrambi i tasti SU e SINISTRA.

4 MotionEvent

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

1 MotionEvent

7.2.7. Telecomando

Consulta la Sezione 2.3.1 per i requisiti specifici del dispositivo.

7.3. Sensori

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

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare con precisione la presenza o l'assenza di sensori per la classe android.content.pm.PackageManager.
• [C-0-2] DEVE restituire un elenco accurato dei sensori supportati tramite SensorManager.getSensorList() e metodi simili.
• [C-0-3] DEVE comportarsi in modo ragionevole per tutte le altre API dei sensori (ad esempio, restituendo true o false a seconda dei casi quando le applicazioni tentano di registrare gli ascoltatori, non chiamano i listener dei sensori quando i sensori corrispondenti non sono presenti e così via).

Se le implementazioni dei dispositivi includono un particolare tipo di sensore con un'API corrispondente per sviluppatori di terze parti, queste:

• [C-1-1] DEVE segnalare tutte le misurazioni dei sensori utilizzando i valori pertinenti del sistema internazionale di unità di misura (metrica) per ciascun tipo di sensore, come definito nella documentazione dell'SDK per Android.
• [C-1-2] DEVE indicare i dati dei sensori con una latenza massima di 100 millisecondi + 2 * sample_time nel caso di un flusso di sensori con una latenza massima richiesta di 0 ms quando il processore dell'applicazione è attivo. Questo ritardo non include eventuali ritardi dei filtri.
• [C-1-3] DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time del sensore da attivare. È accettabile che questo campione abbia un'accuratezza pari a 0.
• [C-1-4] Per qualsiasi API indicata nella documentazione dell'SDK Android come sensore continuo, le implementazioni del dispositivo DEVONO fornire continuamente campioni di dati periodici che DEVONO avere un tremolio inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori di timestamp riportati tra eventi consecutivi.
• [C-1-5] DEVE garantire che il flusso di eventi del sensore NON DEVI impedire alla CPU del dispositivo di entrare in uno stato di sospensione o di riattivarsi dallo stato di sospensione.
• [C-1-6] DEVE segnalare l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta l'ora in cui si è verificato l'evento e la sincronizzazione con l'orologio SystemClock.elapsedRealtimeNano().
• [C-SR-1] È VIVAMENTE CONSIGLIATO che l'errore di sincronizzazione del timestamp sia inferiore a 100 millisecondi e DOVREBBE avere un errore di sincronizzazione inferiore a 1 millisecondo.
• Quando sono attivati più sensori, il consumo di corrente NON DEVE superare la somma del consumo energetico segnalato del singolo sensore.

L'elenco riportato sopra non è completo; il comportamento documentato dell'SDK Android e della documentazione open source di Android sui sensori è da considerarsi autorevole.

Se le implementazioni dei dispositivi includono un particolare tipo di sensore con un'API corrispondente per sviluppatori di terze parti, queste:

• [C-1-6] DEVE impostare una risoluzione diversa da zero per tutti i sensori e indicare il valore tramite il metodo API Sensor.getResolution().

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

Implementazioni dei dispositivi:

• DOVREBBERO implementare questi tipi di sensori, quando includono i prerequisiti dei sensori fisici, come descritto nei tipi di sensori.

Se le implementazioni dei dispositivi includono un sensore composito:

• [C-2-1] DEVE implementare il sensore come descritto nella documentazione open source di Android sui sensori composti.

Se le implementazioni dei dispositivi includono un particolare tipo di sensore con un'API corrispondente per sviluppatori di terze parti e il sensore segnala solo un valore, le implementazioni del dispositivo:

• [C-3-1] DEVE impostare la risoluzione su 1 per il sensore e segnalare il valore tramite il metodo API Sensor.getResolution().

Se le implementazioni del dispositivo includono un particolare tipo di sensore che supporta SensorAdditionalInfo#TYPE_VEC3_CALIBRATION e il sensore viene 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 dei dispositivi includono una combinazione di accelerometro a 3 assi, sensore giroscopio a 3 assi o sensore magnetometro, si tratta di:

• [C-SR-2] VIVAMENTE CONSIGLIATO per garantire che l'accelerometro, il giroscopio e il magnetometro abbiano una posizione relativa fissa, in modo che se il dispositivo sia trasformabile (ad es. pieghevole), gli assi dei sensori 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] È VIVAMENTE CONSIGLIATO di includere un accelerometro a 3 assi.

Se le implementazioni dei dispositivi includono un accelerometro, questi:

• [C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
• [C-1-3] DEVE essere conforme al sistema di coordinate dei sensori di Android come descritto nelle API di Android.
• [C-1-4] DEVE essere in grado di misurare dalla 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 per asse sui campioni raccolti in un periodo di almeno 3 secondi alla frequenza di campionamento più elevata.
• DEVI segnalare eventi fino ad almeno 200 Hz.
• DEVE avere una risoluzione di almeno 16 bit.
• DEVE essere calibrata durante l'uso se le caratteristiche cambiano durante il ciclo di vita e vengono compensate, e mantengono i parametri di compensazione tra i riavvii del dispositivo.
• DEVONO essere compensati in base alla temperatura.

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

• [C-2-1] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER.
• [C-SR-4] È VIVAMENTE CONSIGLIATO di implementare il sensore composito TYPE_SIGNIFICANT_MOTION.
• [C-SR-5] È VIVAMENTE CONSIGLIATO di implementare e segnalare TYPE_ACCELEROMETER_UNCALIBRATED il sensore. I dispositivi Android sono VIVAMENTE CONSIGLIATI per soddisfare questo requisito, pertanto potranno eseguire l'upgrade alla futura release della piattaforma, laddove questo potrebbe diventare OBBLIGATORIO.
• DOVREBBE implementare i sensori composti TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento relativo all'SDK Android.

Se le implementazioni dei dispositivi includono un accelerometro con meno di 3 assi, questi:

• [C-3-1] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER_LIMITED_AXES.
• [C-SR-6] È StrongLY_CONSIGLIATO per implementare e segnalare TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED il sensore.

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

• [C-4-1] La somma del loro consumo di energia DEVE essere sempre inferiore a 4 mW.
• DOVREBBE essere al di sotto di 2 mW e 0,5 mW quando il dispositivo è in condizioni dinamiche o statiche.

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

• [C-5-1] DEVE implementare i sensori composti TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [C-SR-7] È VIVAMENTE CONSIGLIATO di implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

Se le implementazioni dei dispositivi includono un accelerometro a 3 assi, un sensore giroscopio a 3 assi e un sensore magnetometro, questi:

• [C-6-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

7.3.2. Magnetometro

Implementazioni dei dispositivi:

• [C-SR-1] Si consiglia vivamente di includere un magnetometro a 3 assi (compasso).

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi, questi:

• [C-1-1] DEVE implementare il sensore TYPE_MAGNETIC_FIELD.
• [C-1-2] DEVE essere in grado di segnalare eventi fino ad una frequenza di almeno 10 Hz e DEVE segnalare eventi fino ad almeno 50 Hz.
• [C-1-3] DEVE essere conforme al sistema di coordinate dei sensori Android come descritto nelle API Android.
• [C-1-4] DEVE essere in grado di misurare tra -900 μT e +900 μT su ciascun asse prima della saturazione.
• [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 dai campi magnetici dinamici (indotti dalla corrente) e statici (indotti dal magnete).
• [C-1-6] DEVE avere una risoluzione uguale o più densa di 0,6 μT.
• [C-1-7] DEVE supportare la calibrazione online e la compensazione dei bias in ferro duro e mantenere i parametri di compensazione tra i riavvii del dispositivo.
• [C-1-8] DEVE applicare la compensazione del ferro morbido: la calibrazione può essere eseguita durante l'uso o durante la produzione del dispositivo.
• [C-1-9] DEVE avere una deviazione standard, calcolata per asse su campioni raccolti in un periodo di almeno 3 secondi alla frequenza di campionamento più veloce, non superiore a 1,5 μT; DEVE avere una deviazione standard non superiore a 0,5 μT.
• [C-1-10] DEVE implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi, un sensore accelerometro e un sensore giroscopio a 3 assi, questi:

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

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi o un accelerometro, questi:

• POTREBBE implementare il sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi, un accelerometro e un sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR, questi:

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

7.3.3. GPS

Implementazioni dei dispositivi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di includere un ricevitore GPS/GNSS.

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

• [C-1-1] DEVE supportare gli output di localizzazione a una frequenza di almeno 1 Hz se richiesto tramite LocationManager#requestLocationUpdate.
• [C-1-2] DEVE essere in grado di determinare la posizione in condizioni di cielo aperto (segnali forti, multipath trascurabile, HDOP < 2) entro 10 secondi (tempo veloce per la prima correzione), quando connesso a una connessione a internet con velocità dati di 0,5 Mbps o superiore. Questo requisito viene in genere soddisfatto utilizzando alcune tecniche GPS/GNSS assistite o previste per ridurre al minimo i tempi di blocco del GPS/GNSS (i dati sull'assistenza includono ora di riferimento, posizione di riferimento ed efemeridi/orologio satellitari).
  • [C-1-6] Dopo aver effettuato il calcolo della posizione, le implementazioni dei dispositivi DEVONO determinarne la posizione, in cielo aperto, entro 5 secondi, quando le richieste di posizione vengono riavviate, fino a un'ora dopo il calcolo iniziale della posizione, anche se la richiesta successiva viene effettuata senza una connessione dati e/o dopo un ciclo di spegnimento e riaccensione.

• In condizioni di cielo aperto dopo aver determinato la posizione, a sedere 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, per almeno il 95% delle volte.
  • [C-1-4] DEVE monitorare e segnalare contemporaneamente tramite GnssStatus.Callback almeno 8 satelliti di una costellazione.
  • DOVREBBE essere in grado di monitorare contemporaneamente almeno 24 satelliti, da più costellazioni (ad es. GPS + almeno uno di Glonass, Beidou, Galileo).

• [C-SR-2] È VIVAMENTE CONSIGLIATO di continuare a fornire i normali output di posizione GPS/GNSS tramite le API GNSS Location Provider durante una chiamata telefonica di emergenza.

• [C-SR-3] È VIVAMENTE CONSIGLIATO di registrare le misurazioni GNSS da tutte le costellazioni monitorate (come riportate nei messaggi GnssStatus), ad eccezione di SBAS.

• [C-SR-4] È VIVAMENTE CONSIGLIATO di registrare i dati AGC e la frequenza delle misurazioni GNSS.

• [C-SR-5] Ti consigliamo VIVAMENTE di indicare tutte le stime di accuratezza (incluse orientamento, velocità e verticale) come parte di ogni posizione GPS/GNSS.

• [C-SR-6] È VIVAMENTE CONSIGLIATO di riportare le misurazioni GNSS, non appena vengono rilevate, anche se non è stata ancora segnalata una posizione calcolata dal GPS/GNSS.

• [C-SR-7] È VIVAMENTE CONSIGLIATO di segnalare i tassi di pseudorange e pseudointervallo

7.3.4. Giroscopio

Implementazioni dei dispositivi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di includere un sensore giroscopico.

Se le implementazioni dei dispositivi includono un giroscopio, questi:

• [C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
• [C-1-4] DEVE avere una risoluzione di almeno 12 bit.
• [C-1-5] DEVE essere compensato in temperatura.
• [C-1-6] DEVE essere calibrato e compensato durante l'uso e preservare i parametri di compensazione tra i riavvii del dispositivo.
• [C-1-7] DEVE avere una varianza non superiore a 1e-7 rad^2 / s^2 per Hz (varianza per Hz, o rad^2 / s). La varianza può variare con la frequenza di campionamento, ma DEVE essere vincolata da questo valore. In altre parole, se misuri la varianza del giroscopio a una frequenza di campionamento di 1 Hz, DOVREBBE non essere superiore a 1e-7 rad^2/s^2.
• [C-SR-2] L'errore di calibrazione è VIVAMENTE CONSIGLIATO essere inferiore a 0,01 rad/s quando il dispositivo è fermo a temperatura ambiente.
• [C-SR-3] È VIVAMENTE CONSIGLIATO avere una risoluzione di almeno 16 bit.
• DEVI segnalare eventi fino ad almeno 200 Hz.

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

• [C-2-1] DEVE implementare il sensore TYPE_GYROSCOPE.
• [C-SR-4] È vivamente consigliata l'implementazione del sensore TYPE_GYROSCOPE_UNCALIBRATED.

Se le implementazioni del dispositivo includono un giroscopio con meno di 3 assi:

• [C-3-1] DEVE implementare e segnalare il sensore TYPE_GYROSCOPE_LIMITED_AXES.
• [C-SR-5] Sono StrongLY_RECOMMENDED per implementare e segnalare TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED il sensore.

Se le implementazioni dei dispositivi includono un giroscopio a 3 assi, un sensore dell'accelerometro e un sensore magnetometro, questi:

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

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

• [C-5-1] DEVE implementare i sensori composti TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [C-SR-6] È VIVAMENTE CONSIGLIATO di implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometro

Implementazioni dei dispositivi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di includere un barometro (sensore di pressione aria ambiente).

Se le implementazioni dei dispositivi includono un barometro, questi:

• [C-1-1] DEVE implementare e segnalare il sensore TYPE_PRESSURE.
• [C-1-2] DEVE essere in grado di inviare eventi a 5 Hz o superiore.
• [C-1-3] DEVE essere compensato in temperatura.
• [C-SR-2] VIVAMENTE CONSIGLIATO di poter riportare misurazioni di pressione nell'intervallo da 300 hPa a 1100 hPa.
• DEVE avere una precisione assoluta di 1 hPa.
• DOVREBBE avere una precisione relativa di 0,12 hPa su un intervallo di 20 hPa (equivalente a una precisione di ~1 m su una variazione di ~200 m al livello del mare).

7.3.6. Termometro

Se le implementazioni dei dispositivi includono un termometro ambientale (sensore di temperatura), :

• [C-1-1] DEVE definire SENSOR_TYPE_AMBIENT_TEMPERATURE per il sensore di temperatura ambiente, che DEVE misurare la temperatura ambiente (nella stanza/abitacolo del veicolo) da cui l'utente interagisce con il dispositivo in gradi Celsius.

Se le implementazioni dei dispositivi includono un sensore termometro che misura una temperatura diversa dalla temperatura dell'ambiente, ad esempio la temperatura della CPU, questi:

• [C-2-1] NON DEVE definire SENSOR_TYPE_AMBIENT_TEMPERATURE per il sensore di temperatura.

Se le implementazioni dei dispositivi includono un sensore per il monitoraggio della temperatura cutanea, questi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare l'API PowerManager.getThermalHeadroom.

7.3.7. Fotometro

• Le implementazioni dei dispositivi POTREBBERO includere un fotometro (sensore della luce ambientale).

7.3.8. Sensore di prossimità

• Le implementazioni dei dispositivi POTREBBERO includere un sensore di prossimità.

Se le implementazioni dei dispositivi includono un sensore di prossimità e riportano solo una lettura binaria "vicino" o "lontano", queste:

• [C-1-1] DEVE misurare la vicinanza di un oggetto nella stessa direzione dello schermo. In altre parole, il sensore di prossimità DEVE essere orientato in modo da rilevare oggetti vicini allo schermo, in quanto l'intento principale di questo tipo di sensore è rilevare lo 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 usare 0 centimetri come lettura vicina e 5 centimetri come lettura lontana.
• [C-1-4] DEVE segnalare un intervallo e una risoluzione massimi pari a 5.

7.3.9. Sensori ad alta affidabilità

Se le implementazioni dei dispositivi includono un insieme di sensori di qualità superiore, come definito in questa sezione, e li mettono a disposizione di app di terze parti, questi:

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

Se le implementazioni dei dispositivi dichiarano android.hardware.sensor.hifi_sensors, :

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

  • DEVE avere un intervallo di misurazione compreso tra -8 g e +8 g; È VIVAMENTE CONSIGLIATO di avere un intervallo di misurazione compreso tra -16 g e +16 g.
  • DEVE avere una risoluzione di misurazione di almeno 2048 LSB/g.
  • DEVE avere una frequenza di misurazione minima di 12,5 Hz o inferiore.
  • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DEVE supportare il SensorDirectChannel RATE_VERY_FAST.
  • DEVE avere un rumore di misurazione non superiore a 400 μg/√Hz.
  • È NECESSARIO implementare una forma non riattivazione di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore.
  • DEVE avere un consumo energetico per i batch non inferiore a 3 mW.
  • [C-SR-1] È VIVAMENTE CONSIGLIATO disporre di una larghezza di banda di misurazione di 3 dB pari almeno all'80% della frequenza di Nyquist e di uno spettro del rumore bianco all'interno di questa larghezza di banda.
  • Dovremmo avere una camminata casuale con un'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 best-fit pari a ≤ 0,5% e una variazione di sensibilità rispetto alla temperatura di ≤ 0,03%/C°.
  • DEVE avere una sensibilità trasversale < 2,5 % e una variazione della sensibilità trasversale < 0,2% nell'intervallo di temperatura di funzionamento del dispositivo.

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

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

  • DEVE avere un intervallo di misurazione compreso tra almeno -1000 e +1000 dps.
  • DEVE avere una risoluzione di misurazione di almeno 16 LSB/dps.
  • DEVE avere una frequenza di misurazione minima di 12,5 Hz o inferiore.
  • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DEVE supportare il SensorDirectChannel RATE_VERY_FAST.
  • DEVE avere un rumore di misurazione non superiore a 0,014°/s/√Hz.
  • [C-SR-2] È VIVAMENTE CONSIGLIATO disporre di una larghezza di banda di misurazione di 3 dB pari almeno all'80% della frequenza di Nyquist e di uno spettro del rumore bianco all'interno di questa larghezza di banda.
  • DEVE avere una frequenza di camminata casuale inferiore a 0,001 °/s √ Hz testata a temperatura ambiente.
  • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 0,05 °/ s / °C.
  • DEVE avere una variazione di sensibilità rispetto alla temperatura ≤ 0,02% / °C.
  • DEVE avere una non linearità della linea di best-fit pari a ≤ 0,2%.
  • DEVE avere una densità del rumore ≤ 0,007 °/s/√Hz.
  • DEVE avere un errore di calibrazione inferiore a 0,002 rad/s nell'intervallo di temperatura 10 ~ 40 °C quando il dispositivo è fermo.
  • DEVE avere una sensibilità g inferiore a 0,1°/s/g.
  • DEVE avere una sensibilità trasversale < 4,0 % e una variazione della sensibilità trasversale < 0,3% nell'intervallo di temperatura di funzionamento del dispositivo.

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

• [C-2-5] DEVE avere un sensore TYPE_GEOMAGNETIC_FIELD che:

  • DEVE avere un intervallo di misurazione compreso tra almeno -900 e +900 μT.
  • DEVE avere una risoluzione di misurazione di almeno 5 LSB/uT.
  • DEVE avere una frequenza di misurazione minima di 5 Hz o inferiore.
  • DEVE avere una frequenza di misurazione massima di 50 Hz o superiore.
  • DEVE avere un rumore di misurazione non superiore a 0,5 uT.

• [C-2-6] DEVE avere un elemento TYPE_MAGNETIC_FIELD_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GEOMAGNETIC_FIELD e inoltre:

  • DEVE implementare un formato non riattivazione di questo sensore con una capacità di buffering di almeno 600 eventi del sensore.
  • [C-SR-3] È VIVAMENTE CONSIGLIATO di avere uno spettro di rumore bianco compreso da 1 Hz ad almeno 10 Hz quando la frequenza del report è di 50 Hz o superiore.

• [C-2-7] DEVE avere un sensore TYPE_PRESSURE che:

  • DEVE avere un intervallo di misurazione compreso tra almeno 300 e 1100 hPa.
  • DEVE avere una risoluzione di misurazione di almeno 80 LSB/hPa.
  • DEVE avere una frequenza di misurazione minima di 1 Hz o inferiore.
  • DEVE avere una frequenza di misurazione massima di 10 Hz o superiore.
  • DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz.
  • DEVE implementare un formato non riattivazione di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
  • DEVE avere un consumo energetico per i batch non inferiore a 2 mW.

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

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

  • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.

• [C-2-10] DEVE avere un sensore TYPE_STEP_DETECTOR che:

  • DEVE implementare un formato non riattivazione di questo sensore con una capacità di buffering di almeno 100 eventi del sensore.
  • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.
  • DEVE avere un consumo energetico per i batch non inferiore a 4 mW.

• [C-2-11] DEVE avere un sensore TYPE_STEP_COUNTER che:

  • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.

• [C-2-12] DEVE avere un sensore TILT_DETECTOR che:

  • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.

• [C-2-13] Il timestamp dello stesso evento fisico riportato da Accelerometro, Giroscopio e Magnetometro DEVE essere di massimo 2, 5 millisecondi l'uno dall'altro. Il timestamp dello stesso evento fisico riportato dall'accelerometro e dal giroscopio DEVE essere entro 0,25 millisecondi l'uno dall'altro.

• [C-2-14] DEVONO avere i timestamp degli eventi del sensore giroscopio nello stesso base temporale del sottosistema della fotocamera ed entro 1 millisecondi dall'errore.

• [C-2-15] DEVE consegnare i campioni alle applicazioni entro 5 millisecondi dal momento in cui i dati sono disponibili su uno dei sensori fisici di cui sopra all'applicazione.

• [C-2-16] NON DEVE avere un consumo energetico superiore a 0,5 mW con il dispositivo statico e di 2 mW quando il dispositivo è in movimento se è attiva una qualsiasi combinazione dei seguenti sensori:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] POTREBBE avere un sensore TYPE_PROXIMITY, ma se presente DEVE avere una capacità di buffer minima di 100 eventi del sensore.

Tieni presente che tutti i requisiti di consumo di energia presenti in questa sezione non includono il consumo del processore di applicazioni. È comprensiva della potenza assorbita dall'intera catena dei sensori (il sensore, eventuali circuiti di supporto, qualsiasi sistema di elaborazione dei sensori dedicato e così via).

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

• [C-3-1] DEVE dichiarare correttamente il supporto dei tipi di canali diretti e delle tariffe per i report diretti tramite l'API isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
• [C-3-2] DEVE supportare almeno uno dei due tipi di canali diretti dei sensori per tutti i sensori che dichiarano il supporto per il canale diretto dei sensori.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DEVONO supportare i report sugli eventi tramite il canale diretto dei sensori per i sensori principali (variante non sveglia) dei seguenti tipi:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensori biometrici

Per ulteriori informazioni sulla misurazione della sicurezza dello sblocco biometrico, consulta la documentazione relativa alla misurazione della sicurezza biometrica.

Se le implementazioni dei dispositivi includono una schermata di blocco sicura:

• DEVE includere un sensore biometrico

I sensori biometrici possono essere classificati come Classe 3 (in precedenza Strong), Classe 2 (in precedenza debole) o Classe 1 (in precedenza Convenience) in base ai tassi di spoofing e di accettazione degli impostori e in base alla sicurezza della pipeline biometrica. Questa classificazione determina le funzionalità del sensore biometrico di interfacciarsi con la piattaforma e con applicazioni di terze parti. I sensori devono soddisfare i requisiti aggiuntivi descritti di seguito se deve essere classificati come Classe 1, Classe 2 o Classe 3. Sia la biometria di Classe 2 che quella di Classe 3 offrono funzionalità aggiuntive, come descritto di seguito.

Se le implementazioni dei dispositivi rendono disponibile un sensore biometrico ad applicazioni di terze parti tramite android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt e android.provider.Settings.ACTION_BIOMETRIC_ENROLL:

• [C-4-1] DEVE soddisfare i requisiti biometrici di Classe 3 o Classe 2 come definiti nel presente documento.
• [C-4-2] DEVE riconoscere e rispettare ogni nome di parametro definito come costante nella classe Authenticators e tutte le relative combinazioni. Al contrario, NON DEVE rispettare o riconoscere le costanti intere passate ai metodi canAuthenticate(int) e setAllowedAuthenticators(int) diversi da quelli documentati come costanti pubbliche in Authenticators e qualsiasi combinazione di essi.
• [C-4-3] DEVE implementare l'azione ACTION_BIOMETRIC_ENROLL sui dispositivi con biometria di Classe 3 o Classe 2. Questa azione DEVE presentare solo i punti di ingresso di registrazione per la biometria di Classe 3 o Classe 2.

Se le implementazioni dei dispositivi supportano la biometria passiva, questi:

• [C-5-1] DEVE richiedere per impostazione predefinita un ulteriore passaggio di conferma (ad esempio la pressione di un pulsante).
• [C-SR-1] È VIVAMENTE CONSIGLIATO di avere un'impostazione che consenta agli utenti di ignorare la preferenza dell'applicazione e di richiedere sempre un passaggio di conferma associato.
• [C-SR-2] È VIVAMENTE CONSIGLIATO di assicurarsi che l'azione di conferma sia protetta, in modo che un sistema operativo o un kernel non possano essere oggetto di spoofing. Ad esempio, ciò significa che l'azione di conferma basata su un pulsante fisico viene instradata tramite un pin di input/output generico di solo input di un Secure Element (SE) che non può essere controllato da altri mezzi se non la pressione fisica di un pulsante.
• [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 essere utilizzate per i flussi di accesso.

Se le implementazioni dei dispositivi hanno più sensori biometrici, questi:

Crea nuovi requisiti

• [C-7-1] DEVE, quando un dato biometrico è in blocco (ovvero la biometria è disabilitata fino a quando l'utente non si sblocca con l'autenticazione principale) o un blocco vincolato al tempo (ovvero la biometria è temporaneamente disattivata fino a quando l'utente non attende un intervallo di tempo) a causa di un numero eccessivo di tentativi non riusciti, bloccare anche tutte le altre biometrie di una classe biometrica inferiore. Nel caso del blocco vincolato al tempo, l'orario di backoff per la verifica biometrica DEVE essere il tempo di backoff massimo di tutti i dati biometrici in blocco vincolato al tempo.

• [C-SR-12] Sono VIVAMENTE CONSIGLIATE quando un dato biometrico è in blocco (ovvero la biometria viene disattivata fino a quando l'utente non si sblocca con l'autenticazione principale) o nel blocco vincolato al tempo (ovvero la biometria viene temporaneamente disattivata fino a quando l'utente non attende un intervallo di tempo) a causa di un numero eccessivo di tentativi non riusciti, per bloccare anche tutti gli altri dati biometrici della stessa classe biometrica. In caso di blocco vincolato al tempo, l'orario di backoff per la verifica biometrica è VIVAMENTE CONSIGLIATO che sia il tempo di backoff massimo di tutti i dati biometrici in blocco vincolato al tempo.

• [C-7-2] DEVE richiedere all'utente l'autenticazione primaria consigliata (ad es. PIN, sequenza, password) per reimpostare il contatore di blocco in caso di blocco biometrico. La biometria di Classe 3 POTREBBE essere autorizzata a reimpostare il contatore del blocco per un dato biometrico bloccato della stessa classe o di una classe inferiore. La biometria di Classe 2 o Classe 1 NON DEVE essere consentita per completare un'operazione di blocco di reimpostazione per qualsiasi biometria.

Termina nuovi requisiti

• [C-SR-3] È VIVAMENTE CONSIGLIATO di richiedere la conferma di un solo dato biometrico per autenticazione (ad esempio, se sul dispositivo sono disponibili sia i sensori di impronta che i sensori del volto, onAuthenticationSucceeded deve essere inviato dopo la conferma di uno dei due).

Affinché le implementazioni dei dispositivi consentano l'accesso alle chiavi dell'archivio chiavi ad applicazioni di terze parti, è necessario:

• [C-6-1] DEVE soddisfare i requisiti per la Classe 3 definiti nella sezione di seguito.
• [C-6-2] DEVE presentare solo la biometria di Classe 3 se l'autenticazione richiede BIOMETRIC_Strong o se viene richiamata con un CryptoObject.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 1 (in precedenza Convenience),:

• [C-1-1] DEVE avere un tasso di accettazione falsa inferiore allo 0,002%.
• [C-1-2] DEVE comunicare che questa modalità potrebbe essere meno sicura di un PIN, una sequenza o una password efficaci ed indicare chiaramente i rischi associati ad attivarla, se i tassi di accettazione di spoofing e impostori sono superiori al 7%, secondo quanto misurato dai protocolli Android Biometrics Test.
• [C-1-9] DEVE richiedere all'utente l'autenticazione primaria consigliata (ad es. PIN, sequenza, password) dopo non più di venti prove false e un tempo di backoff non inferiore a novanta secondi per la verifica biometrica, ovvero una prova falsa con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a una biometria registrata.
• [C-SR-4] CONSIGLIATE VIVAMENTE 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 impostori sono superiori al 7%, come misurano i protocolli Android Biometrics Test.
• [C-1-3] DEVE limitare la frequenza dei tentativi di verifica biometrica, nel caso in cui una prova falsa sia quella con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a un dato biometrico registrato.
• [C-SR-5] È VIVAMENTE CONSIGLIATO di limitare la frequenza dei tentativi per almeno 30 secondi dopo cinque false prove per la verifica biometrica per il numero massimo di prove false per [C-1-9], dove una prova falsa è una con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a un dato biometrico registrato.
• [C-SR-6] È VIVAMENTE CONSIGLIATO di avere tutte le logiche di limitazione della frequenza in TEE.

• [C-1-10] DEVE disabilitare la biometria una volta attivato il backoff dell'autenticazione primaria, come descritto in [C-0-2] della sezione 9.11.

• [C-1-11] DEVE avere un tasso di accettazione di spoofing e impostore non superiore al 30%, con (1) un tasso di accettazione di spoofing e impostore per le specie di strumenti di attacco da presentazione (PAI) di livello A non superiore al 30% e (2) un tasso di parodia e imposter accettazione delle specie PAI di livello B non superiore al 40%, come misurato dal protocollo Android.

• [C-1-4] DEVE impedire l'aggiunta di nuovi dati biometrici senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare l'esistenza o aggiungere una nuova credenziali dispositivo (PIN/pattern/password) protetta da TEE; l'implementazione di Android Open Source Project fornisce il meccanismo nel framework per farlo.

• [C-1-5] DEVE rimuovere completamente tutti i dati biometrici identificabili di un utente quando il suo account viene rimosso (anche tramite un ripristino dei dati di fabbrica).

• [C-1-6] DEVE rispettare la segnalazione individuale per i dati biometrici (ovvero 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 versione precedente 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 l'autenticazione biometrica di Classe 3 (Strong) dopo una delle seguenti operazioni:

  • un periodo di timeout di inattività di 4 ore OPPURE
  • 3 tentativi di autenticazione biometrica non riusciti.
  • Il periodo di timeout per inattività e il conteggio delle autenticazione non riuscite vengono reimpostati dopo una conferma di tutte le credenziali del dispositivo. Nota: l'upgrade dei dispositivi lanciati con Android 9 o versioni precedenti POTREBBE essere esentati dalla normativa C-1-8.

• [C-SR-7] Ti consigliamo vivamente di utilizzare la logica nel framework fornito dal progetto open source Android per applicare i vincoli specificati in [C-1-7] e [C-1-8] per i nuovi dispositivi.

• [C-SR-8] È VIVAMENTE CONSIGLIATO avere un tasso di rifiuto errato inferiore al 10%, come misurato sul dispositivo.

• [C-SR-9] È VIVAMENTE 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.

Crea nuovi requisiti

• [C-1-12] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 40% per specie di strumenti di attacco di presentazione (PAI), come misurato dai protocolli Android Biometrics Tests.

• [C-SR-13] È VIVAMENTE CONSIGLIATO di avere un tasso di accettazione di spoofing e impostori non superiore al 30% per ogni specie di strumenti di attacco di presentazione (PAI), come misurato dai protocolli Android Biometrics Tests.

• [C-SR-14] È VIVAMENTE CONSIGLIATO di divulgare la classe biometrica del sensore biometrico e i corrispondenti rischi legati all'abilitazione del sensore.

• [C-SR-17] Ti consigliamo vivamente di implementare le nuove interfacce AIDL (come IFace.aidl e IFingerprint.aidl).

Termina nuovi requisiti

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 2 (in precedenza Debole):

• [C-2-1] DEVE soddisfare tutti i requisiti della Classe 1 di cui sopra.

• [C-2-2] DEVE avere un tasso di accettazione di spoofing e impostore non superiore al 20%, con (1) un tasso di accettazione di spoofing e impostore per le specie di strumenti di attacco di presentazione di livello A (PAI) non superiore al 20% e (2) un tasso di accettazione di spoofing e impostore delle specie PAI di livello B non superiore al 30% della Biometria .

Crea nuovi requisiti

• [C-SR-15] È VIVAMENTE CONSIGLIATO di avere un tasso di accettazione di spoofing e impostori non superiore al 20% per specie di strumento di attacco di presentazione (PAI), come misurato dai protocolli Android Biometrics Tests.

Termina nuovi requisiti

• [C-2-3] DEVE eseguire la corrispondenza biometrica in un ambiente di esecuzione isolato al di fuori dello spazio utente o kernel Android, come il Trusted Execution Environment (TEE), oppure su un chip con un canale sicuro verso l'ambiente di esecuzione isolato o su una macchina virtuale protetta che soddisfi i requisiti della Sezione 9.17.
• [C-2-4] DEVE avere tutti i dati identificabili crittografati e autenticati in modo crittografico, in modo che non possano essere acquisiti, letti o alterati al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro per l'ambiente di esecuzione isolato come documentato nelle linee guida per l'implementazione sul sito del progetto open source Android o una macchina virtuale protetta controllata da hypervisor che soddisfi i requisiti della Sezione 9.17.
• [C-2-5] Per la biometria basata su fotocamera, durante l'autenticazione o la registrazione basate su dati biometrici:
  • DEVE utilizzare la fotocamera in una modalità che impedisca la lettura o l'alterazione dei fotogrammi della videocamera al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro verso l'ambiente di esecuzione isolato oppure una macchina virtuale protetta controllata dall'hypervisor che soddisfi i requisiti della sezione 9.17.
  • Per le soluzioni RGB a fotocamera singola, i fotogrammi della fotocamera POSSONO essere leggibili al di fuori dell'ambiente di esecuzione isolato per supportare operazioni come l'anteprima per la registrazione, ma NON DEVONO comunque essere modificabili.
• [C-2-6] NON DEVE consentire alle applicazioni di terze parti di distinguere le singole registrazioni biometriche.
• [C-2-7] NON DEVE consentire l'accesso non criptato a dati biometrici identificabili o a qualsiasi dato derivato da questi ultimi (come gli incorporamenti) al processore di applicazioni 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 aggiornati su Android 9 o versioni precedenti non sono esenti da C-2-7.

• [C-2-8] DEVE avere una pipeline di elaborazione sicura, tale che un sistema operativo o la compromissione del kernel non possano consentire l'inserimento diretto dei dati per autenticare erroneamente l'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 software di sistema, POTREBBERO essere esentate dal requisito.

• [C-SR-10] È VIVAMENTE CONSIGLIATO di includere il rilevamento dell'attività per tutte le modalità biometriche e il rilevamento dell'attenzione per la biometria del volto.

• [C-2-9] DEVE rendere il sensore biometrico disponibile ad applicazioni di terze parti.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 3 (in precedenza Strong),:

• [C-3-1] DEVE soddisfare tutti i requisiti della suddetta classe 2, ad eccezione di [C-1-7] e [C-1-8].
• [C-3-2] DEVE avere un'implementazione di keystore supportata da hardware.
• [C-3-3] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 7%, con (1) un tasso di accettazione di spoofing e impostore per le specie di strumenti di attacco di presentazione di livello A (PAI) non superiore al 7% e (2) un tasso di accettazione di spoofing e impostore delle specie PAI di livello B non superiore al 20%, come misurato dal test di biometria Android.
• [C-3-4] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) una volta ogni 72 ore o meno.
• [C-3-5] DEVE rigenerare l'ID Authenticator per tutti i dati biometrici di Classe 3 supportati sul dispositivo se uno di questi viene registrato di nuovo.
• [C-3-6] Devono abilitare le chiavi di archivi di chiavi biometrici per applicazioni di terze parti.

Crea nuovi requisiti

• [C-SR-16] È VIVAMENTE CONSIGLIATO di avere un tasso di accettazione di spoofing e impostori non superiore al 7% per specie di strumenti di attacco di presentazione (PAI), come misurato dai protocolli Android Biometrics Tests.

Termina nuovi requisiti

Se le implementazioni dei dispositivi contengono un sensore di impronte digitali integrato nel display:

• [C-SR-11] È VIVAMENTE CONSIGLIATO per evitare che l'area toccabile del UDFPS interferisca con la navigazione con tre pulsanti( che alcuni utenti potrebbero richiedere per l'accessibilità).

7.3.11. Sensore di posizione

Implementazioni dei dispositivi:

• POTREBBE 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à, questi:

• [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 dei dispositivi supportano un sensore per l'angolo della cerniera, questi:

• [C-1-1] DEVE implementare e segnalare TYPE_HINGLE_ANGLE.
• [C-1-2] DEVE supportare almeno due letture comprese tra 0 e 360 gradi (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 per 802.1.15.4 ed espongono la funzionalità a un'applicazione di terze parti, questi:

Crea nuovi requisiti

• [C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.uwb.
• [C-1-3] DEVE supportare tutti i seguenti set di configurazione (combinazioni predefinite di parametri FIRA UCI) definiti nell'implementazione AOSP.
  • CONFIG_ID_1: intervallo unicast STATIC STS DS-TWR definito da FiRa, modalità differita, intervallo con intervallo di 240 ms.
  • CONFIG_ID_2: intervallo STATIC STS DS-TWR one-to-many definito da FiRa, modalità differita, intervallo con intervallo di 200 ms. Caso d'uso tipico: lo smartphone interagisce con molti smart device.
  • CONFIG_ID_3: come CONFIG_ID_1, ad eccezione dei dati relativi all'angolo di arrivo (AoA) non vengono riportati.
  • CONFIG_ID_4: come CONFIG_ID_1, ad eccezione della modalità di sicurezza P-STS attivata.
  • CONFIG_ID_5: come CONFIG_ID_2, ad eccezione della modalità di sicurezza P-STS attivata.
  • CONFIG_ID_6: come CONFIG_ID_3, ad eccezione della modalità di sicurezza P-STS attivata.
  • CONFIG_ID_7: come CONFIG_ID_2, ad eccezione del fatto che è abilitata la modalità chiave del controllo individuale P-STS.
• [C-1-4] DEVE fornire un'invito all'utente per consentire all'utente di attivare/disattivare lo stato della radio UWB.
• [C-1-5] DEVE imporre che le app che utilizzano radio UWB contengano l'autorizzazione UWB_RANGING (nel gruppo di autorizzazioni NEARBY_DEVICES).

Il superamento dei test di conformità e certificazione pertinenti definiti dalle organizzazioni standard, tra cui FIRA, CCC e CSA, contribuisce a garantire il corretto funzionamento dello standard 802.1.15.4.

Termina nuovi requisiti

7.4. Connettività dei dati

7.4.1. Telefonia

"Telefonia", come utilizzato dalle API Android, e nel presente documento si riferisce specificamente all'hardware relativo all'effettuazione di chiamate vocali e all'invio di SMS o alla definizione di dati mobili tramite una rete mobile (ad es. GSM, CDMA, LTE, NR)GSM o CDMA. Un dispositivo che supporta il servizio "Telefonia" può scegliere di offrire alcuni o tutti i servizi di chiamata, messaggistica e dati in base al prodotto.

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

• Android POTREBBE essere utilizzato su dispositivi che non includono hardware per la telefonia. In altre parole, Android è compatibile con dispositivi diversi dagli smartphone.

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

• [C-1-1] DEVE dichiarare il flag della funzionalità android.hardware.telephony e altri flag delle funzionalità secondarie in base alla tecnologia.
• [C-1-2] DEVE implementare il supporto completo dell'API per la tecnologia in questione.
• DEVE consentire tutti i tipi di servizi cellulari 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 per la telefonia:

• [C-2-1] DEVE implementare le API complete in modalità autonoma.

Se le implementazioni dei dispositivi supportano eUICC o eSIM/SIM incorporate e includono un meccanismo proprietario per rendere la funzionalità eSIM disponibile per gli sviluppatori di terze parti, queste:

• [C-3-1] DEVE dichiarare il flag della funzionalità android.hardware.telephony.euicc.

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 IP Multimedia Subsystem (IMS) per le funzionalità dei servizi di telefonia multimediale (MMTEL) e RCS (Rich Communication Services) e sono tenuti a rispettare i requisiti degli operatori di telefonia mobile relativi all'utilizzo di un'unica registrazione IMS per tutto il traffico di segnalazione IMS,

• [C-5-1] DEVE dichiarare il flag della funzionalità android.hardware.telephony.ims e fornire un'implementazione completa dell'API ImsService sia per l'API User Capability Exchange MMTEL che per RCS.
• [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 relative al vettore utilizzando IRadio 1.6 HAL e del provisioning tramite l'Auto Configuration Server (ACS) o un altro meccanismo di provisioning proprietario utilizzando l'API IRadio.

Se le implementazioni dei dispositivi 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 di testo. SmsManager#sendMultimediaMessage e SmsManager#downloadMultimediaMessage DEVONO generare chiamate corrispondenti a CarrierMessagingService per fornire funzionalità di messaggistica multimediale.
• [C-6-2] L'applicazione designata da android.provider.Telephony.Sms#getDefaultSmsPackage DEVE utilizzare le API SmsManager per l'invio e la ricezione di SMS e MMS. L'implementazione del riferimento di AOSP in pacchetti/apps/Messaging soddisfa questo requisito.
• [C-6-3] L'applicazione che risponde a Intent#ACTION_DIAL DEVE supportare l'inserimento di codici tastierino arbitrario formattati come *#*#CODE#*#* e attivare una trasmissione TelephonyManager#ACTION_SECRET_CODE corrispondente.
• [C-6-4] L'applicazione che risponde a Intent#ACTION_DIAL DEVE utilizzare VoicemailContract.Voicemails#TRANSCRIPTION per mostrare agli utenti la trascrizione della segreteria visiva se supporta le trascrizioni di messaggi vocali.
• [C-6-5] DEVE rappresentare tutte le SubscriptionInfo con UUID di gruppo equivalenti come un singolo abbonamento in tutte le comunicazioni visibili all'utente che mostrano e controllano i dati della scheda SIM. Esempi di questi inviti includono le interfacce delle impostazioni che corrispondono a Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS o EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
• [C-6-6] NON DEVE visualizzare o consentire il controllo di SubscriptionInfo con un UUID di gruppo e un bit opportunistico non nulli in qualsiasi invito 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 fornisce una barra di stato del sistema:

• [C-7-1] DEVE selezionare un abbonamento attivo rappresentativo per un determinato UUID di gruppo da mostrare all'utente in tutti gli inviti che forniscono informazioni sullo stato della SIM. Esempi di tali inviti includono l'icona del segnale cellulare nella barra di stato o il riquadro delle impostazioni rapide.
• [C-SR-1] È VIVAMENTE CONSIGLIATO che l'abbonamento rappresentativo sia scelto come abbonamento per i dati attivi, a meno che il dispositivo non sia in una chiamata vocale, durante la quale è VIVAMENTE CONSIGLIATO che l'abbonamento per rappresentante sia l'abbonamento per Voice attivo.

Se le implementazioni dei dispositivi 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 ciascun UICC secondo lo standard ETSI TS 102 221.
• [C-6-8] NON DEVE applicare automaticamente o senza una conferma esplicita dell'utente nessuno dei seguenti comportamenti alle app dell'operatore attive (indicate da TelephonyManager#getCarrierServicePackageName):
  • Revocare o limitare l'accesso alla rete
  • Revoca autorizzazioni
  • Limita l'esecuzione di app in background o in primo piano oltre le funzionalità di gestione dell'alimentazione esistenti incluse in AOSP
  • Disattivare o disinstallare l'app

Se le implementazioni del dispositivo segnalano la funzionalità android.hardware.telephony e tutti gli abbonamenti attivi non opportunistici che condividono un UUID di gruppo vengono disattivati, rimossi fisicamente dal dispositivo o contrassegnati come opportunistici, il dispositivo:

• [C-8-1] DEVE disabilitare automaticamente tutti gli abbonamenti opportunisti 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 quando si tenta 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, questi:

• [C-10-1] DEVE dichiarare il flag della funzionalità android.hardware.telephony.euicc.mep.

7.4.1.1. Compatibilità con blocco numerico

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

• [C-1-1] DEVE includere il supporto del 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 "BlockNumberProvider" senza alcuna interazione con le app. L'unica eccezione si verifica quando il blocco dei numeri viene temporaneamente rimosso, come descritto nella documentazione dell'SDK.

• [C-1-4] DEVE scrivere nel provider del registro chiamate della piattaforma per una chiamata bloccata e DEVE filtrare le chiamate con BLOCKED_TYPE al di fuori della visualizzazione predefinita del registro chiamate nell'app Telefono preinstallata.

• [C-1-5] NON DEVE scrivere al provider di telefonia per un messaggio bloccato.

• [C-1-6] DEVE implementare un'interfaccia utente per la gestione dei numeri bloccata, 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. Tutte le UI correlate al blocco DEVONO essere nascoste agli utenti secondari e l'elenco bloccato DEVE essere comunque rispettato.

• DOVRESTI eseguire la migrazione dei numeri bloccati al provider quando un dispositivo viene aggiornato ad Android 7.0.

• DOVREBBE fornire un invito all'utente per mostrare le chiamate bloccate nell'app Telefono preinstallata.

7.4.1.2. API Telecom

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

• [C-1-1] DEVE supportare le API ConnectionService descritte nell'SDK.
• [C-1-2] DEVE visualizzare una nuova chiamata in arrivo e fornire all'utente l'invito ad accettare o rifiutare la chiamata in arrivo quando è in corso una chiamata effettuata da un'app di terze parti che non supporta la funzionalità di attesa specificata tramite CAPABILITY_SUPPORT_HOLD.
• [C-1-3] DEVE avere un'applicazione che implementa InCallService.

• [C-SR-1] È VIVAMENTE CONSIGLIATO di informare l'utente che rispondendo a una chiamata in arrivo verrà interrotta una chiamata in corso.

  L'implementazione di AOSP soddisfa questi requisiti tramite una notifica di avviso che indica all'utente che rispondendo a una chiamata in arrivo, l'altra chiamata verrà interrotta.

• [C-SR-2] È VIVAMENTE CONSIGLIATO di precaricare l'app Telefono predefinita che mostra una voce di registro chiamate e il nome di un'app di terze parti nel registro chiamate quando l'app di terze parti imposta la chiave extra EXTRA_LOG_SELF_MANAGED_CALLS su PhoneAccount su true.

• [C-SR-3] È VIVAMENTE CONSIGLIATO di gestire gli eventi KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK delle cuffie 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 di CallAudioState.

7.4.1.3. Offload keepalive NAT-T cellulare

Implementazioni dei dispositivi:

• DEVE includere il supporto per l'offload keepalive della rete mobile.

Se le implementazioni dei dispositivi includono il supporto per lo scarico keepalive mobile ed espongono la funzionalità ad app di terze parti, queste:

• [C-1-1] DEVE supportare l'API SocketKeepAlive.
• [C-1-2] DEVE supportare almeno uno slot keepalive simultaneo su rete cellulare.
• [C-1-3] DEVE supportare tanti slot keepalive di telefonia mobile simultanei supportati da Cellular Radio HAL.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare almeno tre slot keepalive cellulari per istanza radio.

Se le implementazioni dei dispositivi non includono il supporto per l'offload 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 per una o più forme di 802.11.

Se le implementazioni dei dispositivi includono il supporto per 802.11 ed espongono la funzionalità a un'applicazione di terze parti, questi:

• [C-1-1] DEVE implementare l'API Android corrispondente.
• [C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.wifi.
• [C-1-3] DEVE implementare l'API multicast come descritto nella documentazione dell'SDK.
• [C-1-4] DEVE supportare il DNS multicast (mDNS) e NON filtrare i pacchetti mDNS (224.0.0.251 o ff02::fb) in qualsiasi momento, anche quando lo schermo non è in stato attivo, a meno che non sia necessario eliminare o filtrare questi pacchetti per rimanere entro gli intervalli di consumo di energia applicabili alle normative di riferimento. Per implementazioni di dispositivi Android Television, anche in stato di alimentazione in standby.
• [C-1-5] NON DEVE considerare la chiamata al metodo API WifiManager.enableNetwork() come un'indicazione sufficiente per cambiare il Network attualmente attivo che viene utilizzato per impostazione predefinita per il traffico delle applicazioni e viene restituito da ConnectivityManager metodi API come getActiveNetwork e registerDefaultNetworkCallback. In altre parole, POSSONO disabilitare l'accesso a internet fornito da qualsiasi altro provider di rete (ad es., dati mobili) solo se viene verificato che la rete Wi-Fi fornisce l'accesso a Internet.
• [C-1-6] È VIVAMENTE CONSIGLIATO, quando viene chiamato il metodo API ConnectivityManager.reportNetworkConnectivity(), rivalutare l'accesso a internet su Network e, una volta che la valutazione determina che l'attuale Network non fornisce più l'accesso a internet, passare a qualsiasi altra rete disponibile (ad esempio, dati mobili) che fornisce accesso a internet.
• [C-1-7] DEVE randomizzare l'indirizzo MAC di origine e il numero di sequenza dei frame di richiesta del probe, una volta all'inizio di ogni scansione, mentre STA è disconnesso.
• [C-1-8] DEVE utilizzare un indirizzo MAC coerente (NON DEVE randomizzare l'indirizzo MAC a metà di una scansione).
• [C-1-9] DEVE ripetere il numero di sequenza della richiesta di probe come normale (in sequenza) tra le richieste di probe in una scansione.
• [C-1-10] DEVE randomizzare il numero di sequenza della richiesta di probe tra l'ultima richiesta di probe di una scansione e la prima richiesta di probe della scansione successiva.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di randomizzare l'indirizzo MAC di origine utilizzato per tutte le comunicazioni STA con un punto di accesso (AP) durante l'associazione e l'associazione.
  • Il dispositivo DEVE utilizzare un indirizzo MAC randomizzato diverso per ogni SSID (FQDN per Passpoint) con cui comunica.
  • Il dispositivo DEVE fornire all'utente la possibilità di controllare la casuale per SSID (FQDN per Passpoint) con opzioni non randomizzate e casuali e DEVE impostare la modalità predefinita per la randomizzazione di nuove configurazioni Wi-Fi.
• [C-SR-2] CONSIGLIATO VIVAMENTE di usare un BSSID casuale per tutti gli AP che creano.
  • L'indirizzo MAC DEVE essere randomizzato e mantenuto in base all'SSID utilizzato dall'AP.
  • Il DISPOSITIVO POTREBBE offrire all'utente un'opzione per disattivare questa funzione. Se viene fornita questa opzione, la randomizzazione DEVE essere abilitata per impostazione predefinita.

Se le implementazioni dei dispositivi includono il supporto per la modalità di risparmio energetico del Wi-Fi come definito nello standard IEEE 802.11, questi:

• DEVE disattivare la modalità di risparmio energetico del Wi-Fi ogni volta che un'app acquisisce un 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 di andata e ritorno tra il dispositivo e un punto di accesso quando il dispositivo è in una modalità di blocco a bassa latenza Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) DEVE essere inferiore alla latenza durante una modalità di blocco Wi-Fi ad alte prestazioni (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] È VIVAMENTE CONSIGLIATO per ridurre al minimo la latenza di round trip Wi-Fi ogni volta che viene acquisito un blocco a bassa latenza (WIFI_MODE_FULL_LOW_LATENCY) e ha effetto.

Se le implementazioni dei dispositivi supportano il Wi-Fi e utilizzano il Wi-Fi per la scansione della posizione:

• [C-2-1] DEVE fornire un'invito all'utente per abilitare/disabilitare il valore letto tramite il metodo API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementazioni dei dispositivi:

• DOVREBBE includere il supporto per Wi-Fi Direct (peer-to-peer Wi-Fi).

Se le implementazioni dei dispositivi includono il supporto per 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 operazioni Wi-Fi e Wi-Fi Direct.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di randomizzare l'indirizzo MAC di origine per tutte le nuove connessioni Wi-Fi Direct.

7.4.2.2. Configurazione del collegamento diretto tramite tunnel Wi-Fi

Implementazioni dei dispositivi:

• DEVE includere il supporto per la configurazione del collegamento diretto tramite tunnel Wi-Fi (TDLS) come descritto nella documentazione dell'SDK Android.

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

• [C-1-1] DEVE dichiarare il supporto per TDLS tramite WifiManager.isTdlsSupported.
• DOVREBBE usare TDLS solo quando è possibile E vantaggioso.
• DOVREBBE avere un po' di euristica e NON usare TDLS quando le sue prestazioni potrebbero essere peggiori rispetto al punto di accesso Wi-Fi.

7.4.2.3. Sensibile al Wi-Fi

Implementazioni dei dispositivi:

• DEVE includere il supporto per Wi-Fi Aware.

Se le implementazioni dei dispositivi includono il supporto per Wi-Fi Aware ed espongono la funzionalità ad app di terze parti, questi:

• [C-1-1] DEVE implementare le API WifiAwareManager come descritto nella documentazione dell'SDK.
• [C-1-2] DEVE dichiarare il flag della funzionalità android.hardware.wifi.aware.
• [C-1-3] DEVE supportare contemporaneamente 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 il Wi-Fi Aware è abilitato, a meno che non sia in corso un'operazione di ranging di Aware 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 per Wi-Fi Aware e Posizione Wi-Fi come descritto nella Sezione 7.4.2.5 ed espongono queste funzionalità ad app di terze parti, questi:

• [C-2-1] DEVE implementare le API di rilevamento della posizione: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscovered WithinRange.

7.4.2.4. Passpoint Wi-Fi

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

• [C-1-1] DEVE includere il supporto per Passpoint Wi-Fi.
• [C-1-2] DEVE implementare le API WifiManager relative a Passpoint come descritto nella documentazione dell'SDK.
• [C-1-3] DEVE supportare lo standard IEEE 802.11u, correlato in modo specifico al rilevamento e alla selezione della rete, ad esempio GAS (Generic Advertisingment Service) e Access Network Query Protocol (ANQP).
• [C-1-4] DEVE dichiarare il flag di funzionalità android.hardware.wifi.passpoint.
• [C-1-5] DEVE seguire l'implementazione di AOSP per scoprire, associare e associare le reti Passpoint.
• [C-1-6] DEVE supportare almeno il seguente sottoinsieme di protocolli di provisioning dei dispositivi definito nel 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 dell'hotspot 2.0 R3.
• [C-1-8] DEVE supportare il controllo utente del provisioning tramite il selettore Wi-Fi.
• [C-1-9] DEVE mantenere le configurazioni Passpoint persistenti tra i riavvii.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare la funzionalità di accettazione di Termini e condizioni.
• [C-SR-2] È VIVAMENTE CONSIGLIATO per il supporto della funzionalità Informazioni sulla sede.

Se viene fornita un'opzione di controllo utente per la disattivazione di Passpoint globale, le implementazioni:

• [C-3-1] DEVE attivare Passpoint per impostazione predefinita.

7.4.2.5. Posizione Wi-Fi (tempo di andata e ritorno Wi-Fi - RTT)

Implementazioni dei dispositivi:

• DEVE includere il supporto della posizione Wi-Fi.

Se le implementazioni dei dispositivi includono il supporto della posizione Wi-Fi ed espongono la funzionalità ad app di terze parti, questi:

• [C-1-1] DEVE implementare le API WifiRttManager come descritto nella documentazione dell'SDK.
• [C-1-2] DEVE dichiarare il flag della funzionalità android.hardware.wifi.rtt.
• [C-1-3] DEVE randomizzare l'indirizzo MAC di origine per ogni burst RTT che viene eseguito mentre l'interfaccia Wi-Fi su cui viene eseguito l'RTT non è associata ad un punto di accesso.
• [C-1-4] DEVE essere preciso entro i 2 metri di larghezza di banda di 80 MHz al 68° percentile (come calcolato con la funzione di distribuzione cumulativa).
• [C-SR-1] CONSIGLIATO VIVAMENTE di riportarlo con precisione entro 1,5 metri di 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 keepalive Wi-Fi.

Se le implementazioni dei dispositivi includono il supporto per l'offload keepalive Wi-Fi ed espongono la funzionalità ad app di terze parti, questi:

• [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 (protocollo di provisioning dei dispositivi)

Implementazioni dei dispositivi:

• DEVE includere il supporto per DPP (Wi-Fi Easy Connect).

Se le implementazioni dei dispositivi includono il supporto di Connessione rapida Wi-Fi ed espongono la funzionalità ad app di terze parti, questi:

• [C-1-1] DEVE avere il metodo WifiManager#is EasyConnectSupported() che restituisca true.

7.4.2.8. Convalida certificati server Wi-Fi aziendali

Se il certificato del server Wi-Fi non viene convalidato o il nome di dominio del server Wi-Fi non è impostato, le implementazioni del dispositivo:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di non offrire all'utente la possibilità di aggiungere manualmente la rete Wi-Fi aziendale nell'app Impostazioni.

7.4.2.9. Trust On First Use (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 scegliere di utilizzare TOFU.

7.4.3. Bluetooth

Se le implementazioni del dispositivo supportano il profilo audio Bluetooth:

• DEVE supportare i codec audio avanzati e i codec audio Bluetooth (ad esempio LDAC)

Se le implementazioni dei dispositivi supportano HFP, A2DP e AVRCP, questi:

• DEVONO supportare almeno 5 dispositivi connessi in totale.

Se le implementazioni dei dispositivi dichiarano la funzionalità android.hardware.vr.high_performance:

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

Android include il supporto per Bluetooth e Bluetooth Low Energy.

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

• [C-2-1] DEVE dichiarare le funzionalità della piattaforma pertinenti (rispettivamente android.hardware.bluetooth e android.hardware.bluetooth_le) e implementare le API della piattaforma.
• DEVI implementare profili Bluetooth pertinenti, come A2DP, AVRCP, OBEX, HFP e così via in base al dispositivo.

Se le implementazioni dei dispositivi includono il supporto per Bluetooth Low Energy (BLE):

• [C-3-1] DEVE dichiarare la funzionalità hardware android.hardware.bluetooth_le.
• [C-3-2] DEVE attivare le API Bluetooth basate su GATT (profilo attributo generico) come descritto nella documentazione dell'SDK e su android.bluetooth.
• [C-3-3] DEVE segnalare il valore corretto per BluetoothAdapter.isOffloadedFilteringSupported() per indicare se è implementata la logica di filtro per le classi API ScanFilter.
• [C-3-4] DEVE segnalare il valore corretto per BluetoothAdapter.isMultipleAdvertisementSupported() per indicare se la pubblicità a bassa energia è supportata.

• [C-3-5] DEVE implementare un timeout dell'indirizzo privato risolvibile (RPA) non superiore a 15 minuti e ruotare l'indirizzo al timeout per proteggere la privacy degli utenti quando il dispositivo utilizza attivamente BLE per la scansione o la pubblicità. Per evitare attacchi al tempo, anche gli intervalli di timeout DEVONO essere randomizzati tra 5 e 15 minuti.

• DOVREBBE supportare lo scarico della logica di filtro al chipset Bluetooth durante l'implementazione dell'API ScanFilter.

• DOVREBBE supportare lo scarico della scansione in batch sul chipset Bluetooth.

• DEVE supportare più annunci con almeno 4 aree annuncio.

Se le implementazioni dei dispositivi supportano Bluetooth LE e lo utilizzano per la ricerca della posizione, questi:

• [C-4-1] DEVE fornire un'invito all'utente per abilitare/disabilitare il valore letto tramite l'API di sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se le implementazioni del dispositivo includono il supporto per Bluetooth LE e Profilo degli apparecchi acustici, come descritto nell'articolo Supporto audio degli apparecchi acustici con Bluetooth LE:

• [C-5-1] DEVE restituire true per BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

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

• [C-6-1] DEVE limitare l'accesso a tutti i metadati Bluetooth (ad esempio i risultati della scansione) che potrebbero essere utilizzati per ricavare la posizione del dispositivo, a meno che l'app che richiede la richiesta non superi un controllo delle autorizzazioni android.permission.ACCESS_FINE_LOCATION basato sul suo stato in primo piano/in background attuale.

Se le implementazioni dei dispositivi includono il supporto per Bluetooth o Bluetooth Low Energy e il file manifest dell'app non include una dichiarazione dello sviluppatore in cui si afferma che non derivano la posizione dal Bluetooth, allora:

• [C-6-2] DEVE limitare l'accesso al Bluetooth dietro il android.permission.ACCESS_FINE_LOCATION.

Se le implementazioni dei dispositivi restituiscono true per l'API BluetoothAdapter.isLeAudioSupported(), questi:

• [C-7-1] DEVE supportare il client unicast.
• [C-7-2] DEVE supportare 2 MB di PHY.
• [C-7-3] DEVE supportare LE Extended Advertising.
• [C-7-4] DEVE supportare almeno 2 connessioni CIS in una CIG.
• [C-7-5] DEVE abilitare il client unicast BAP, il coordinatore impostato CSIP, il server MCP, il controller VCP, il server CCP contemporaneamente.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di abilitare il client unicast HAP.

Se le implementazioni dei dispositivi restituiscono true per l'API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), questi:

• [C-8-1] DEVE supportare almeno 2 collegamenti BIS in un GRANDE.
• [C-8-2] DEVE abilitare contemporaneamente la sorgente di trasmissione BAP, l'assistente di trasmissione BAP.
• [C-8-3] DEVE supportare LE la pubblicità periodica.

Se le implementazioni dei dispositivi restituiscono true per l'API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), questi:

• [C-9-1] DEVE supportare il trasferimento periodico della sincronizzazione della pubblicità.
• [C-9-2] DEVE supportare LE la pubblicità periodica.

Se le implementazioni dei dispositivi dichiarano FEATURE_BLUETOOTH_LE:

• [C-10-1] DEVE avere misurazioni RSSI entro +/-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 linea con l'ambiente visivo.

• [C-10-2] DEVE 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 vengono utilizzate più antenne) siano entro +/-3 dB l'una dall'altra per il 95% delle misurazioni.

• [C-SR-2] È VIVAMENTE CONSIGLIATO di misurare e compensare l'offset Rx per garantire che il RSSI BLE mediano sia -60dBm +/-10 dB a 1 metro di distanza da un dispositivo di riferimento che trasmette a ADVERTISE_TX_POWER_HIGH, con dispositivi orientati in modo da essere su "piani paralleli" con schermi rivolti nella stessa direzione.

• [C-SR-3] È VIVAMENTE CONSIGLIATO di misurare e compensare l'offset Tx per garantire che l'RSSI BLE media sia -60dBm +/-10 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e la trasmissione a ADVERTISE_TX_POWER_HIGH, dove i dispositivi sono orientati in modo da essere su "piani paralleli" con schermi rivolti nella stessa direzione.

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

• [C-10-3] DEVE misurare e compensare l'offset Rx per garantire che il RSSI BLE mediano sia -55 dBm +/-10 dB a 1 m di distanza da un dispositivo di riferimento che trasmette a ADVERTISE_TX_POWER_HIGH.
• [C-10-4] DEVE misurare e compensare l'offset Tx per garantire che l'RSSI BLE mediano sia -55 dBm +/-10 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e la trasmissione a ADVERTISE_TX_POWER_HIGH.

È VIVAMENTE CONSIGLIATO di seguire i passaggi di configurazione della misurazione specificati nei Requisiti per la calibrazione della presenza di persone.

Se le implementazioni dei dispositivi supportano Bluetooth versione 5.0:

• [C-SR-4] È VIVAMENTE CONSIGLIATO di fornire assistenza per:
  • LE 2M PHY
  • Codec LE PHY
  • Estensione pubblicità LE
  • Pubblicità periodica
  • Almeno 10 insiemi di annunci.
  • Almeno 8 connessioni simultanee LE. Ogni connessione può essere associata a entrambi i ruoli di topologia di connessione.
  • Privacy del livello di link LE
  • Una dimensione "elenco di risoluzione" di almeno 8 voci

7.4.4. Near Field Communication

Implementazioni dei dispositivi:

• DEVE includere un ricetrasmettitore e l'hardware correlato per la tecnologia Near Field Communication (NFC).
• [C-0-1] DEVE implementare le API android.nfc.NdefMessage e android.nfc.NdefRecord anche se non includono supporto per NFC o dichiarare la funzionalità android.hardware.nfc perché 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 ad app di terze parti, questi:

• [C-1-1] DEVE segnalare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature().
• DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC, come descritto di seguito:
• [C-1-2] DEVE essere in grado di agire come lettore/autore dell'NFC Forum (come definito dalle specifiche tecniche dell'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 del forum NFC 1, 2, 3, 4, 5 (definiti dal forum NFC)

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

• [C-1-13] DEVE effettuare il polling per tutte le tecnologie supportate in modalità di rilevamento NFC.

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

• DOVREBBE essere in grado di leggere il codice a barre e l'URL (se codificato) dei prodotti Thinfilm NFC Barcode.

Tieni presente che i link disponibili pubblicamente non sono disponibili per le specifiche per i forum JIS, ISO e NFC citate in precedenza.

Android supporta la modalità HCE (NFC Host Card Emulation).

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

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

Se le implementazioni dei dispositivi includono un chipset del controller NFC in grado di eseguire HCE per NfcF e implementano la funzionalità per le applicazioni di terze parti, questi:

• [C-3-1] DEVE segnalare la costante della funzionalità android.hardware.nfc.hcef.
• [C-3-2] DEVE implementare le API NFC Card Emulation come definito nell'SDK Android.

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

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

7.4.5. Protocolli di rete e API

7.4.5.1. Capacità di rete minima

Implementazioni dei dispositivi:

• [C-0-1] DEVE includere il supporto di una o più forme di networking di dati. In particolare, le implementazioni dei dispositivi DEVONO includere il supporto di almeno uno standard di dati in grado di funzionare da 200 Kbit/sec o superiore. Esempi di tecnologie che soddisfano questo requisito includono EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
• DEVE includere anche il supporto per almeno uno standard di dati wireless comune, ad esempio 802.11 (Wi-Fi), quando la connessione dati principale è uno standard di rete fisico (come Ethernet).
• POTREBBE implementare più di una forma di connettività 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, quali java.net.Socket e java.net.URLConnection, nonché le API native, quali i socket AF_INET6.
• [C-0-3] DEVE abilitare IPv6 per impostazione predefinita.
  • DEVE garantire che la comunicazione IPv6 sia affidabile quanto IPv4, ad esempio:
    • [C-0-4] DEVE mantenere la connettività IPv6 in modalità sospensione.
    • [C-0-5] La limitazione di frequenza NON DEVE causare la perdita della connettività IPv6 del dispositivo su qualsiasi rete conforme a IPv6 che utilizza una durata RA di almeno 180 secondi.
• [C-0-6] DEVE fornire alle applicazioni di terze parti la connettività IPv6 diretta alla rete quando si è connessi a una rete IPv6, senza che alcun tipo di traduzione di indirizzi o porte avvenga localmente sul dispositivo. Sia le API gestite come Socket#getLocalAddress o Socket#getLocalPort che le API NDK come getsockname() o IPV6_PKTINFO DEVONO restituire l'indirizzo IP e la porta effettivamente utilizzati per inviare e ricevere pacchetti sulla rete e che sono visibili come IP di origine e porta sui server internet (web).

Il livello richiesto di supporto IPv6 dipende dal tipo di rete, come mostrato nei requisiti seguenti.

Se le implementazioni del dispositivo 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 sistema dual stack e solo IPv6 su Ethernet.

Se le implementazioni dei dispositivi supportano la rete dati:

• [C-3-1] DEVE supportare l'operazione IPv6 (solo IPv6 e probabilmente a doppio stack) sulla rete cellulare.

Se le implementazioni dei dispositivi supportano più di un tipo di rete (ad es. Wi-Fi e rete dati):

• [C-4-1] DEVE soddisfare contemporaneamente i requisiti precedenti su ogni rete quando il dispositivo è connesso contemporaneamente a più di un tipo di rete.

7.4.5.3. Captive portal

Un captive portal è una rete che richiede l'accesso per ottenere l'accesso a internet.

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

• [C-1-1] DEVE fornire un'applicazione captive portal per gestire l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN e visualizzare la pagina di accesso del captive portal inviando tale intent durante la 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, incluse reti cellulare/mobili, Wi-Fi, Ethernet o Bluetooth.
• [C-1-3] DEVE supportare l'accesso ai captive portal utilizzando il DNS in chiaro se il dispositivo è configurato per l'uso della modalità con restrizioni DNS privato.
• [C-1-4] DEVE utilizzare il DNS criptato, come indicato nella 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 captive portal.
• [C-1-5] DEVE garantire che, mentre l'utente accede a un captive portal, la rete predefinita utilizzata dalle applicazioni (restituita da ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback e utilizzata per impostazione predefinita dalle API di networking Java come java.net.Socket e dalle API native come connect()) sia qualsiasi altra rete disponibile che fornisce accesso a internet, se disponibile.

7.4.6. Impostazioni sincronizzazione

Implementazioni dei dispositivi:

• [C-0-1] DEVE avere l'impostazione di sincronizzazione automatica master attivata per impostazione predefinita, in modo che il metodo getMasterSyncAutomatically() restituisca "true".

7.4.7. Risparmio dati

Se le implementazioni dei dispositivi includono una connessione a consumo, si tratta di:

• [C-SR-1] VIVAMENTE CONSIGLIATO per offrire la modalità Risparmio dati.

Se le implementazioni dei dispositivi offrono la modalità Risparmio dati, questi:

• [C-1-1] DEVE supportare tutte le API nella classe ConnectivityManager come descritto nella documentazione dell'SDK

Se le implementazioni dei dispositivi non offrono la modalità Risparmio dati:

• [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 che supportano l'API Open Mobile e li rendono disponibili per app di terze parti, questi:

• [C-1-1] DEVE enumerare i lettori di elementi sicuri disponibili tramite l'API android.se.omapi.SEService.getReaders().

• [C-1-2] DEVE dichiarare i flag funzionalità corretti tramite android.hardware.se.omapi.uicc per il dispositivo con elementi di sicurezza basati su UICC, android.hardware.se.omapi.ese per il dispositivo con elementi di sicurezza basati su eSE e android.hardware.se.omapi.sd per il dispositivo con elementi di sicurezza basati su SD.

7.4.9. UWB

Se le implementazioni dei dispositivi includono il supporto per 802.1.15.4 ed espongono la funzionalità a un'applicazione di terze parti:

• [C-1-1] DEVE implementare l'API Android corrispondente in android.uwb.
• [C-1-2] DEVE segnalare il flag 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'invito all'utente per consentire all'utente di attivare/disattivare lo stato della radio UWB.
• [C-1-5] DEVE forzare l'applicazione forzata dell'autorizzazione UWB_RANGING alle app che utilizzano radio UWB (nella sezione gruppo di autorizzazioni NEARBY_PAYMENTS).
• [C-SR-1] È VIVAMENTE CONSIGLIATO di superare i relativi test di conformità e certificazione definiti dalle organizzazioni standard, tra cui FIRA, CCC e CSA.
• [C-1-6] DEVE garantire che le misurazioni della distanza siano entro +/-15 cm per il 95% delle misurazioni nell'ambiente di visuale a 1 m di distanza in una camera non riflettente.
• [C-1-7] DEVE garantire che la mediana delle misurazioni della distanza a 1 m dal dispositivo di riferimento sia entro [0,75 m o 1,25 m], dove la distanza di dati empirici reali è misurata dal bordo superiore del DUT. rivolto verso l'alto e inclinato di 45 gradi.
• [C-SR-2] È VIVAMENTE CONSIGLIATO di seguire i passaggi di configurazione della misurazione specificati nella sezione Requisiti per la calibrazione della presenza.

7.5. Videocamere

Se le implementazioni dei dispositivi includono almeno una fotocamera:

• [C-1-1] DEVE dichiarare il flag della funzionalità android.hardware.camera.any.
• [C-1-2] Un'applicazione deve poter allocare contemporaneamente 3 bitmap RGBA_8888 uguali alle dimensioni delle immagini generate dal sensore della fotocamera con la massima risoluzione sul dispositivo, mentre la fotocamera è aperta per l'anteprima di base e l'acquisizione.
• [C-1-3] DEVE garantire che gli intent di gestione delle applicazioni predefinite della videocamera preinstallati MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE o MediaStore.ACTION_VIDEO_CAPTURE, siano responsabili della rimozione della posizione dell'utente nei metadati dell'immagine prima di inviarla all'applicazione ricevente quando quest'ultima non dispone di ACCESS_FINE_LOCATION.

Se le implementazioni dei dispositivi supportano la funzionalità di output HDR a 10 bit:

• [C-2-1] DEVE supportare almeno il profilo HLG HDR per ogni dispositivo fotocamera che supporta l'output a 10 bit.
• [C-2-2] DEVE supportare l'output a 10 bit per la fotocamera principale posteriore o anteriore.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare l'output a 10 bit per entrambe le fotocamere principali.
• [C-2-3] DEVE supportare gli stessi profili HDR per tutte le fotocamere secondarie fisiche compatibili con BACKWARD_COMPATIBLE di una fotocamera logica, nonché per la fotocamera logica stessa.

Per i dispositivi con fotocamera logica che supportano la tecnologia HDR a 10 bit e implementano l'API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO:

• [C-3-1] DEVE supportare il passaggio tra tutte le fotocamere fisiche compatibili con le versioni precedenti tramite il controllo CONTROL_ZOOM_RATIO sulla fotocamera logica.

7.5.1. Fotocamera posteriore

Una fotocamera posteriore è una fotocamera che si trova sul lato del dispositivo opposto al display, ovvero immagini scene all'altro lato del dispositivo, come una videocamera tradizionale.

Crea nuovi requisiti

Una videocamera posteriore è rivolta verso il mondo e riproduce scene sul lato opposto del dispositivo, come una videocamera tradizionale; sui dispositivi portatili, è una videocamera sul lato del dispositivo di fronte al display.

Termina nuovi requisiti

Implementazioni dei dispositivi:

• DEVE includere una fotocamera posteriore.

Se le implementazioni del dispositivo includono almeno una fotocamera posteriore:

• [C-1-1] DEVE segnalare il flag di funzionalità android.hardware.camera e android.hardware.camera.any.
• [C-1-2] DEVE avere una risoluzione di almeno 2 megapixel.
• DEVONO avere la messa a fuoco automatica hardware o software implementata nel driver della fotocamera (trasparente al software dell'applicazione).
• POTREBBERO avere hardware a fuoco fisso o EDOF (profondità di campo estesa).
• POSSONO includere un flash.

Se la fotocamera include il flash:

• [C-2-1] il flash NON DEVE essere acceso mentre è stata registrata un'istanza android.hardware.Camera.PreviewCallback su un'area di anteprima della fotocamera, a meno che l'applicazione non abbia abilitato esplicitamente il flash attivando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON di un oggetto Camera.Parameters. Tieni presente che questo vincolo non si applica all'applicazione della fotocamera di sistema integrata del dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

Una fotocamera anteriore è una videocamera situata sullo stesso lato del dispositivo del display, ovvero una videocamera solitamente utilizzata per immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.

Crea nuovi requisiti

Una fotocamera anteriore è una videocamera rivolta all'utente che in genere viene utilizzata per acquisire immagini dell'utente, ad esempio per videoconferenze e applicazioni simili; sui dispositivi portatili, si tratta di una videocamera situata sullo stesso lato del dispositivo del display.

Termina nuovi requisiti

Implementazioni dei dispositivi:

• POTREBBE includere una fotocamera anteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera anteriore:

• [C-1-1] DEVE segnalare il flag di funzionalità android.hardware.camera.any e android.hardware.camera.front.
• [C-1-2] DEVE avere una risoluzione di almeno VGA (640x480 pixel).
• [C-1-3] NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Camera e NON DEVE configurare l'API in modo da considerare una fotocamera anteriore come 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 esplicitamente richiesto la rotazione del display della videocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation(). Al contrario, l'anteprima DEVE essere visualizzata lungo l'asse orizzontale predefinito del dispositivo quando l'applicazione corrente non richiede esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NON DEVE rispecchiare gli stream video o l'immagine statica acquisiti finali restituiti ai callback delle applicazioni o impegnati nello spazio di archiviazione multimediale.
• [C-1-6] DEVE eseguire il mirroring dell'immagine visualizzata dal postview nello stesso modo in cui viene eseguito lo stream di immagini di anteprima della fotocamera.
• POTREBBERO includere funzionalità (ad esempio 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 input utente):

• [C-2-1] L'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto all'orientamento corrente del dispositivo.

7.5.3. Videocamera esterna

Crea nuovi requisiti

Una videocamera esterna è una videocamera che può essere collegata o scollegata fisicamente dall'implementazione del dispositivo in qualsiasi momento e rivolta in qualsiasi direzione, ad esempio le videocamere USB.

Termina nuovi requisiti

Implementazioni dei dispositivi:

• POTREBBE includere il supporto di una videocamera esterna che non è necessariamente sempre connessa.

Se le implementazioni dei dispositivi includono il supporto per una fotocamera esterna:

• [C-1-1] DEVE dichiarare il flag della funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any.
• [C-1-2] DEVE supportare USB Video Class (UVC 1.0 o superiore) se la videocamera esterna si collega tramite la porta host USB.
• [C-1-3] DEVE superare i test CTS della videocamera con una videocamera esterna fisica collegata. I dettagli dei test CTS della fotocamera sono disponibili all'indirizzo source.android.com.
• DEVONO supportare le compressione video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ovvero stream di immagini non elaborati o compressi in modo indipendente).
• POTREBBE supportare più fotocamere.
• POTREBBE supportare la codifica video basata su fotocamera.

Se la codifica video basata su fotocamera è supportata:

• [C-2-1] Uno stream simultaneo non codificato / MJPEG (con 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 che espone all'app un controllo della fotocamera di livello inferiore, inclusi flussi burst/streaming zero-copy efficienti e controlli per fotogramma di esposizione, guadagno, aumento 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 l'uso delle app. Le implementazioni dei dispositivi Android DEVONO garantire il supporto continuo dell'API come descritto in questa sezione e nell'SDK Android.

Tutte le funzionalità comuni tra la classe android.hardware.Camera deprecata e il pacchetto android.hardware.camera2 più recente DEVONO avere prestazioni e qualità equivalenti in entrambe le API. Ad esempio, con impostazioni equivalenti, velocità e precisione della messa a fuoco automatica devono essere identiche e la qualità delle immagini acquisite deve essere la stessa. Le funzionalità che dipendono dalla semantica diversa delle due API non devono garantire una velocità o una qualità corrispondenti, ma DEVONO corrispondere il più fedelmente possibile.

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API relative alle fotocamere, per tutte le videocamere disponibili. Implementazioni dei dispositivi:

• [C-0-1] DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione quando un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] 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(). Il formato di anteprima è YCbCr_420_SP, ovvero i dati nel byte[] passati in onPreviewFrame(). Vale a dire che NV21 DEVE essere l'impostazione predefinita.
• [C-0-3] DEVE supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime delle fotocamere per le fotocamere anteriori e posteriori di android.hardware.Camera. (Il codificatore video hardware e la fotocamera possono utilizzare qualsiasi formato di pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione a YV12.)
• [C-0-4] DEVE supportare i formati android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG come output tramite l'API android.media.ImageReader per i dispositivi android.hardware.camera2 che pubblicizzano la funzionalità di REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities.
• [C-0-5] DEVE comunque implementare l'API Camera completa inclusa nella documentazione relativa all'SDK Android, a prescindere dal fatto che il dispositivo includa la messa a fuoco automatica hardware o altre funzionalità. Ad esempio, le fotocamere senza messa a fuoco automatica DEVONO comunque richiamare qualsiasi istanza android.hardware.Camera.AutoFocusCallback registrata, anche se 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 la messa a fuoco automatica, le richiamate API devono essere comunque "false" come descritto.
• [C-0-6] DEVE riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters e nella classe android.hardware.camera2.CaptureRequest. Al contrario, le implementazioni dei dispositivi NON DEVONO rispettare o riconoscere costanti stringhe passate al metodo android.hardware.Camera.setParameters(), diverse da quelle documentate come costanti nel android.hardware.Camera.Parameters. In altre parole, le implementazioni dei dispositivi DEVONO supportare tutti i parametri standard della videocamera, se l'hardware lo consente, e NON DEVONO supportare tipi di parametri personalizzati della fotocamera. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini con 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 assistenza corretto per la proprietà android.info.supportedHardwareLevel come descritto nell'SDK Android e i flag delle funzionalità framework appropriati.
• [C-0-8] DEVE inoltre dichiarare le funzionalità della singola fotocamera di android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag di funzionalità appropriati; DEVE definire il flag della funzionalità se uno dei dispositivi della 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 l'ingresso dell'immagine viene aggiunto al media store.
• [C-0-10] DEVE trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e l'ingresso dell'immagine viene aggiunto al media store.
• [C-0-11] DEVE avere accesso a tutte le videocamere tramite l'API android.hardware.Camera deprecata anche tramite l'API android.hardware.camera2.
• [C-0-12] DEVE garantire che l'aspetto del volto NON sia alterato, inclusa, a titolo esemplificativo, l'alterazione della geometria e della tonalità della pelle del viso o della levigatura della pelle del viso per qualsiasi API android.hardware.camera2 o android.hardware.Camera.
• [C-SR-1] Per i dispositivi con più fotocamere RGB vicino e rivolte nella stessa direzione, è VIVAMENTE CONSIGLIATO di supportare un dispositivo fotocamera logica che elenca la funzionalità CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, composto da tutte le fotocamere RGB rivolte in quella direzione come sottodispositivi fisici.

Se le implementazioni dei dispositivi forniscono un'API della fotocamera di proprietà ad app di terze parti, le implementazioni:

• [C-1-1] DEVE implementare l'API della fotocamera di questo tipo utilizzando l'API android.hardware.camera2.
• POTREBBE fornire tag e/o estensioni del fornitore all'API android.hardware.camera2.

7.5.5. Orientamento fotocamera

Se le implementazioni del dispositivo hanno una fotocamera anteriore o posteriore, ad esempio:

• [C-1-1] DEVE essere orientato in modo che la dimensione lunga della fotocamera sia allineata alla dimensione lunga dello schermo. In altre parole, quando il dispositivo è tenuto in orientamento orizzontale, le videocamere DEVONO acquisire le immagini con l'orientamento orizzontale. Ciò vale indipendentemente dall'orientamento naturale del dispositivo, ovvero ai dispositivi principali orizzontali e verticali.

I dispositivi che soddisfano tutti i seguenti criteri sono esenti dal requisito di cui sopra:

• Il dispositivo implementa schermi a geometria variabile, come display pieghevoli o incernierati.
• Quando lo stato di piegatura o cerniera del dispositivo cambia, il dispositivo passa dall'orientamento verticale-principale a orizzontale-principale (o viceversa).

Crea nuovi requisiti

• Implementazioni di dispositivi che non possono essere ruotate dall'utente, ad esempio i dispositivi auto e motori.

Termina nuovi requisiti

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 Gestione dei download che le applicazioni POSSONO utilizzare per scaricare file di dati e DEVONO essere in grado di scaricare singoli file di almeno 100 MB nella posizione predefinita della "cache".

7.6.2. Archiviazione condivisa delle applicazioni

Implementazioni dei dispositivi:

• [C-0-1] DEVE offrire lo spazio di archiviazione condiviso dalle applicazioni, spesso definito anche "archiviazione esterna condivisa", "archiviazione condivisa delle applicazioni" o dal percorso Linux "/sdcard" su cui è montato.
• [C-0-2] DEVE essere configurato con l'archiviazione condivisa montata per impostazione predefinita, in altre parole "pronta all'uso", indipendentemente dal fatto che l'archiviazione sia implementata su un componente di archiviazione interno o su un supporto di archiviazione rimovibile (ad es. slot per schede Secure Digital).
• [C-0-3] DEVE montare lo spazio di archiviazione condiviso dell'applicazione direttamente sul percorso Linux sdcard o includere un link simbolico Linux da sdcard al punto di montaggio effettivo.
• [C-0-4] DEVE abilitare l'archiviazione con ambito per impostazione predefinita per tutte le app che hanno come target il livello API 29 o versioni successive, tranne che nella seguente situazione:
  • Quando l'app ha richiesto android:requestLegacyExternalStorage="true" nel file manifest.
• [C-0-5] DEVE oscurare i metadati di posizione, come i tag GPS Exif, archiviati nei file multimediali quando questi file sono accessibili tramite MediaStore, tranne nei casi in cui l'app chiamante dispone dell'autorizzazione ACCESS_MEDIA_LOCATION.

Le implementazioni dei dispositivi POSSONO soddisfare i requisiti di cui sopra utilizzando uno dei seguenti elementi:

• Dispositivo di archiviazione rimovibile accessibile all'utente, ad esempio uno slot per schede SD (Secure Digital).
• Una parte dello spazio di archiviazione interno (non rimovibile) implementato nell'Android Open Source Project (AOSP).

Se le implementazioni dei dispositivi utilizzano l'archiviazione rimovibile per soddisfare i requisiti di cui sopra, questi:

• [C-1-1] DEVE implementare un avviso popup o un'interfaccia utente popup che avvisa l'utente quando nello slot non è inserito un supporto di archiviazione.
• [C-1-2] DEVE includere un supporto di archiviazione in formato FAT (ad es. una scheda SD) o indicare sulla confezione e altro materiale disponibile al momento dell'acquisto che il supporto deve essere acquistato separatamente.

Se le implementazioni del dispositivo utilizzano una parte dello spazio di archiviazione non rimovibile per soddisfare i requisiti di cui sopra, questi:

• DOVREBBE usare l'implementazione AOSP dello spazio di archiviazione condiviso delle applicazioni interne.
• POTREBBE condividere lo spazio di archiviazione con i dati privati dell'applicazione.

Se le implementazioni dei dispositivi hanno una porta USB con supporto della modalità periferica USB:

• [C-3-1] DEVE fornire un meccanismo per accedere ai dati nell'archivio condiviso dell'applicazione da un computer host.
• DEVONO esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione multimediale di Android e android.provider.MediaStore.
• POSSONO utilizzare un archivio di massa USB, ma DEVI usare Media Transfer Protocol per soddisfare questo requisito.

Se le implementazioni del dispositivo hanno una porta USB con modalità periferica USB e supportano Media Transfer Protocol, questi:

• DEVE essere compatibile con l'host Android MTP di riferimento, Android File Transfer.
• DEVI segnalare una classe di dispositivi USB pari a 0x00.
• DEVI segnalare un nome di interfaccia USB di "MTP".

7.6.3. Spazio di archiviazione utilizzabile

Se si prevede che il dispositivo sia mobile a differenza della televisione, le implementazioni dei dispositivi sono:

• [C-SR-1] VIVAMENTE CONSIGLIATO di implementare lo spazio di archiviazione adottabile in una posizione stabile a lungo termine, poiché la disconnessione accidentale può causare la perdita/il danneggiamento dei dati.

Se la porta rimovibile del dispositivo di archiviazione si trova in un luogo stabile a lungo termine, ad esempio all'interno del vano batterie o di un'altra copertura protettiva, le implementazioni del dispositivo sono:

• [C-SR-2] VIVAMENTE CONSIGLIATO di implementare lo spazio di archiviazione adottabile.

7.7 USB

Se le implementazioni dei dispositivi hanno una porta USB:

• DEVE supportare la modalità periferica USB e la modalità host USB.
• DEVE supportare la disattivazione della segnalazione 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 collegabile a un host USB che ha una porta USB standard di tipo A o C.
• [C-1-2] DEVE segnalare il valore corretto di iSerialNumber nel descrittore del dispositivo standard USB tramite android.os.Build.SERIAL.
• [C-1-3] DEVE rilevare i caricabatterie da 1,5 A e 3,0 A in base allo standard per la resistenza di tipo C e DEVE rilevare eventuali modifiche alla pubblicità se supportano USB di tipo C.
• [C-SR-1] La porta DEVE usare il fattore di forma USB micro-B, micro-AB o Tipo-C. I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare questi requisiti in modo che possano eseguire l'upgrade alle future release della piattaforma.
• [C-SR-2] La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o abilitare la rotazione dello schermo del software per tutte le app (inclusa la schermata Home), in modo che il display venga spostato correttamente quando il dispositivo è orientato con la porta in basso. I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare questi requisiti, in modo da essere in grado di eseguire l'upgrade a release future della piattaforma.
• [C-SR-3] DEVE implementare il supporto per assorbire 1,5 A di corrente durante il suono e il traffico HS, come specificato nella specifica per la ricarica della batteria USB, revisione 1.2. I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare questi requisiti in modo che possano eseguire l'upgrade alle future release della piattaforma.
• [C-SR-4] CONSIGLIATO VIVAMENTE di non supportare metodi di ricarica proprietari che modificano la tensione Vbus oltre i livelli predefiniti o alterano i ruoli sink/source in quanto tali potrebbero causare problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard USB Power Delivery. Anche se questa opzione è definita "FORTEMENTE CONSIGLIATA", nelle future versioni di Android potremmo RICHIEDERE tutti i dispositivi di tipo C per supportare l'interoperabilità completa con i caricabatterie standard di tipo C.
• [C-SR-5] VIVAMENTE CONSIGLIATO per supportare la funzionalità Power Delivery per lo scambio di dati e alimentazione quando supportano le modalità USB di tipo C e host USB.
• DOVREBBE supportare la funzionalità Power Delivery per la ricarica ad alta tensione e il supporto di modalità alternative come il display out.
• DEVI implementare l'API e la specifica Android Open Accessory (AOA) come documentato nella documentazione relativa all'SDK Android.

Se le implementazioni del dispositivo includono una porta USB e implementano la specifica AOA:

• [C-2-1] DEVE dichiarare il supporto per la funzionalità hardware android.hardware.usb.accessory.
• [C-2-2] La classe di archiviazione di massa USB DEVE includere la stringa "android" alla fine della stringa della descrizione dell'interfaccia iInterface dell'archiviazione di massa USB
• NON DEVE implementare l'audio AOAv2 documentato nella documentazione di Android Open Accessory Protocol 2.0. L'audio AOAv2 è deprecato a partire dalla versione 8.0 di Android (livello API 26).

7.7.2. Modalità host USB

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host:

• [C-1-1] DEVE implementare l'API Android USB Host come documentato nell'SDK per Android e DEVE dichiarare il supporto per la 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 spedire con cavi che ne adattano una porta proprietaria sul dispositivo a una porta USB Type-C standard (dispositivo USB Type-C).
  • Avere un dispositivo di tipo A integrato o disporre di cavi che adattino una porta proprietaria sul dispositivo a una porta USB di tipo A standard.
  • Avere una porta micro-AB sul dispositivo, che DEVE essere spedita con un cavo adattato a una porta di tipo A standard.
• [C-1-3] NON DEVE essere fornito con un adattatore che converte le porte USB di tipo A o micro-AB in una porta di tipo C (presa).
• [C-SR-1] È VIVAMENTE CONSIGLIATO di implementare la classe audio USB come documentato nella documentazione dell'SDK Android.
• DEVE supportare la ricarica del dispositivo periferico USB connesso in modalità host; pubblicizzando una corrente di origine di almeno 1,5 A come specificato nella sezione Parametri di terminazione della sezione Revisione 1.2 della specifica del cavo e del connettore USB Type-C per i connettori USB Type-C o dell'intervallo della corrente di uscita della porta di ricarica downstream(CDP), come specificato nella sezione Specifiche di ricarica della batteria USB 2.
• DOVREBBE implementare e supportare gli standard USB Type-C.

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host e la classe audio USB, questi:

• [C-2-1] DEVE supportare la classe USB HID.
• [C-2-2] DEVE supportare il rilevamento e la mappatura dei seguenti campi di dati HID specificati nelle Tabelle di utilizzo dell'HID USB e nella Richiesta di utilizzo di Voice Command alle costanti KeyEvent come indicato di seguito:
  • Pagina utilizzo (0xC) ID utilizzo (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Pagina di utilizzo (0xC) ID utilizzo (0x0E9): KEYCODE_VOLUME_UP
  • ID di utilizzo della pagina di utilizzo (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • Pagina di utilizzo (0xC) ID utilizzo (0x0CF): KEYCODE_VOICE_ASSIST

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host e il framework Storage Access Framework (SAF), questi:

• [C-3-1] DEVE riconoscere i dispositivi MTP (Media Transfer Protocol) collegati da remoto e rendere i relativi contenuti accessibili tramite gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host e USB Type-C, questi:

• [C-4-1] DEVE implementare la funzionalità Dual Role Port come definito dalla specifica USB Type-C (sezione 4.5.1.3.3). Per le porte a due ruoli, sui dispositivi che includono un jack audio da 3,5 mm, il rilevamento del sink USB (modalità host) POTREBBE essere disattivato per impostazione predefinita, ma DEVE essere possibile che l'utente lo abiliti.
• [C-SR-2] VIVAMENTE CONSIGLIATO per supportare DisplayPort, DOVREBBE supportare USB SuperSpeed Data Rates e sono VIVAMENTE CONSIGLIATI per supportare Power Delivery per lo scambio di dati e ruoli.
• [C-SR-3] CONSIGLIATO VIVAMENTE di NON supportare la modalità accessorio adattatore audio come descritto nell'Appendice A della revisione 1.2 della specifica del cavo e del connettore USB Type-C.
• DEVI implementare il modello Prova.* più appropriato per il fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DOVREBBE implementare il modello Explore.SNK.

7.8 Audio

7.8.1. Microfono

Se le implementazioni dei dispositivi includono un microfono, questi:

• [C-1-1] DEVE segnalare la costante della funzionalità android.hardware.microphone.
• [C-1-2] DEVE soddisfare i requisiti per la registrazione audio di cui alla sezione 5.4.
• [C-1-3] DEVE soddisfare i requisiti relativi alla latenza audio di cui alla sezione 5.6.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare la registrazione quasi a ultrasuoni, come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono un microfono:

• [C-2-1] NON DEVE segnalare la costante della funzionalità android.hardware.microphone.
• [C-2-2] DEVE implementare l'API Registrazione audio almeno in modalità autonoma, secondo la sezione 7.

7.8.2. Uscita audio

Se le implementazioni del dispositivo includono un altoparlante o una porta di uscita audio/multimediale per una periferica di uscita audio, ad esempio un jack audio da 3,5 mm a 4 conduttori o una porta in modalità host USB che utilizza la classe audio USB, questi:

• [C-1-1] DEVE segnalare la costante della funzionalità android.hardware.audio.output.
• [C-1-2] DEVE soddisfare i requisiti per la riproduzione audio di cui alla sezione 5.5.
• [C-1-3] DEVE soddisfare i requisiti relativi alla latenza audio di cui alla sezione 5.6.
• [C-SR-1] VIVAMENTE CONSIGLIATA per supportare la riproduzione in a ultrasuoni, come descritto nella sezione 7.8.3.

Se le implementazioni del dispositivo non includono un altoparlante o una porta di uscita audio:

• [C-2-1] NON DEVE segnalare la funzionalità android.hardware.audio.output.
• [C-2-2] DEVE implementare le API relative all'output audio almeno in modalità autonoma.

Ai fini di questa sezione, per "porta di uscita" si intende un'interfaccia fisica, ad esempio una porta jack audio da 3, 5 mm oppure una porta in modalità host USB o HDMI con classe audio USB. Il supporto per l'uscita audio tramite protocolli basati su radio come Bluetooth, WiFi o rete mobile non è idoneo come inclusione di una "porta di uscita".

7.8.2.1. Porte audio analogiche

Per essere compatibile con cuffie e altri accessori audio utilizzando il connettore audio da 3,5 mm sull'ecosistema Android, se le implementazioni dei dispositivi includono una o più porte audio analogiche, questi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di includere almeno una delle porte audio come 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, questi:

• [C-1-1] DEVE supportare la riproduzione audio su cuffie e auricolari stereo con microfono.
• [C-1-2] DEVE supportare i connettori audio TRRS con l'ordine di pin-out CTIA.
• [C-1-3] DEVE supportare il rilevamento e la mappatura ai codici chiave per i seguenti 3 intervalli di impedenza equivalente tra il microfono e i conduttori di terra sulla spina 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 su un inserto, ma solo dopo che tutti i contatti sulla spina toccano i segmenti pertinenti sul jack.
• [C-1-5] DEVE essere in grado di pilotare almeno 150 mV ± 10% della tensione di uscita su un'impedenza di altoparlanti da 32 ohm.
• [C-1-6] DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V ~ 2,9 V.
• [C-1-7] DEVE rilevare e mappare il codice della chiave per il seguente intervallo di impedenza equivalente tra il microfono e i conduttori di terra sulla presa audio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR-2] È VIVAMENTE CONSIGLIATO di supportare connettori audio con l'ordine di pin-out OMTP.
• [C-SR-3] È VIVAMENTE CONSIGLIATO per il supporto della registrazione audio da auricolari stereo con microfono.

Se le implementazioni del dispositivo hanno un jack audio da 3,5 mm a 4 conduttori, supportano un microfono e trasmettono android.intent.action.HEADSET_PLUG con il microfono di valore aggiuntivo impostato su 1, questi:

• [C-2-1] DEVE supportare il rilevamento del microfono sull'accessorio audio collegato.

7.8.2.2. Porte audio digitali

Consulta la Sezione 2.2.1 per i requisiti specifici del dispositivo.

7.8.3. Quasi a ultrasuoni

L'audio a ultrasuoni è la banda da 18,5 kHz a 20 kHz.

Implementazioni dei dispositivi:

• DEVE segnalare correttamente il supporto della funzionalità audio quasi a ultrasuoni tramite l'API AudioManager.getProperty come segue:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND è "true", le sorgenti audio VOICE_RECOGNITION e UNPROCESSED DEVONO soddisfare i seguenti requisiti:

• [C-1-1] La risposta di potenza media del microfono nella banda da 18,5 kHz a 20 kHz DEVE essere non più di 15 dB al di sotto della risposta a 2 kHz.
• [C-1-2] Il rapporto tra segnale e rumore non ponderato del microfono, compreso tra 18,5 kHz e 20 kHz, per un tono di 19 kHz a -26 dBFS DEVE essere non inferiore a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND è "true":

• [C-2-1] La risposta media dell'altoparlante nella banda 18,5 kHz - 20 kHz DEVE essere non inferiore a 40 dB al di sotto della risposta a 2 kHz.

7.8.4. Integrità del segnale

Implementazioni dei dispositivi:

• DOVREBBE fornire un percorso del segnale audio privo di errori sia per gli stream di ingresso che di uscita sui dispositivi portatili, come definito da zero problemi misurati durante un test di un minuto per percorso. Esegui il test utilizzando OboeTester "Automated Glitch Test".

Il test richiede un dongle di loopback audio, utilizzato direttamente in un jack da 3,5 mm e/o in combinazione con un adattatore da USB-C a 3,5 mm. Tutte le porte di uscita audio DEVONO essere testate.

OboeTester al momento supporta i percorsi AAudio, quindi le seguenti combinazioni DEVONO essere testate per rilevare eventuali glitch usando AAudio:

Modalità prestazioni	Condivisione	Frequenza di campionamento in uscita	Occasionalmente	Margini di uscita
BASSO_LATEENZA	ESCLUSIVA	NON SPECIFICATO	1	2
BASSO_LATEENZA	ESCLUSIVA	NON SPECIFICATO	2	1
BASSO_LATEENZA	CONDIVISO	NON SPECIFICATO	1	2
BASSO_LATEENZA	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 il seno a 2000 Hz.

Trasduttore	THD	SNR (SNR)
altoparlante principale integrato, misurato utilizzando un microfono esterno di riferimento	< 3,0%	>= 50 dB
microfono principale integrato, misurato utilizzando un altoparlante esterno di riferimento	< 3,0%	>= 50 dB
jack analogici da 3,5 mm integrati, testato con adattatore di loopback	< 1%	>= 60 dB
Adattatori USB forniti con lo smartphone, testati utilizzando l'adattatore di loopback	< 1,0%	>= 60 dB

7.9 Realtà virtuale

Android include API e strutture per creare applicazioni di "realtà virtuale" (VR), che includono esperienze VR di alta qualità per dispositivi mobili. Le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

7.9.1. Modalità realtà virtuale

Android include il supporto per la modalità VR, una funzionalità che gestisce il rendering stereoscopico delle notifiche e disattiva i componenti dell'interfaccia utente del sistema monoculare mentre un'applicazione VR è incentrata sull'utente.

7.9.2. Modalità realtà virtuale - Alte prestazioni

Se le implementazioni dei dispositivi supportano la modalità VR:

• [C-1-1] DEVE avere almeno 2 core fisici.
• [C-1-2] DEVE dichiarare la funzionalità android.hardware.vr.high_performance.
• [C-1-3] DEVE supportare la modalità di prestazioni sostenute.
• [C-1-4] DEVE supportare OpenGL ES 3.2.
• [C-1-5] DEVE supportare android.hardware.vulkan.level 0.
• DOVREBBE 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 ed esporre le estensioni disponibili 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 ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di implementare GL_EXT_external_buffer, GL_EXT_EGL_image_array GL_OVR_multiview_multisampled_render_to_texture e di esporre le estensioni nell'elenco delle estensioni GL disponibili.
• [C-SR-2] CONSIGLIATE VIVAMENTE per il supporto di Vulkan 1.1.
• [C-SR-3] È VIVAMENTE CONSIGLIATO di implementare VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing VK_KHR_shared_presentable_image e di esporlo nell'elenco delle estensioni Vulkan disponibili.
• [C-SR-4] È VIVAMENTE CONSIGLIATO di esporre almeno una famiglia di code Vulkan in cui flags contenga sia VK_QUEUE_GRAPHICS_BIT che VK_QUEUE_COMPUTE_BIT e queueCount sia di almeno 2.
• [C-1-7] La GPU e il display DEVONO essere in grado di sincronizzare l'accesso al buffer frontale condiviso in modo che il rendering a occhio alternato dei contenuti VR a 60 fps con due contesti di rendering venga visualizzato senza artefatti di strappo 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 AHardwareBuffer con qualsiasi combinazione dei flag di utilizzo AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT per almeno i seguenti formati: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] È VIVAMENTE CONSIGLIATO per supportare l'allocazione di AHardwareBuffer con più di un livello, flag e formati specificati in C-1-10.
• [C-1-11] DEVE supportare la decodifica H.264 almeno 3840 x 2160 a 30 f/s, compressa fino a una media di 40 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 f/s-10 Mbps o 2 istanze di 1920 x 1080 f/s a 1920 x 1080 Mbps o 2 istanze di 1920 x 20 Mbps a 1920 x 20 Mbps).
• [C-1-12] DEVE supportare HEVC e VP9, DEVE essere in grado di decodificare almeno 1920 x 1080 a 30 f/s compresso a una media di 10 Mbps e DEVE essere in grado di decodificare istanze a 3840 x 2160 a 30 f/s - 20 f/s a 10 Mbps equivalenti a 10 f/s - 20 Mbps istanze
• [C-1-13] DEVE supportare l'API HardwarePropertiesManager.getDeviceTemperatures e restituire valori precisi per la temperatura cutanea.
• [C-1-14] DEVE avere uno schermo incorporato e la sua risoluzione DEVE essere di almeno 1920 x 1080.
• [C-SR-6] CONSIGLIATO VIVAMENTE una risoluzione del display di almeno 2560 x 1440.
• [C-1-15] Il display DEVE aggiornarsi di almeno 60 Hz in modalità VR.
• [C-1-17] Il display DEVE supportare una modalità a bassa persistenza con una persistenza ≤ 5 millisecondi, la persistenza è definita come il tempo durante il quale un pixel emette luce.
• [C-1-18] DEVE supportare Bluetooth 4.2 e Bluetooth LE Data Length Extension sezione 7.4.3.
• [C-1-19] DEVE supportare e indicare correttamente il tipo di canale diretto per tutti i seguenti tipi di sensori predefiniti:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] È VIVAMENTE CONSIGLIATO di supportare il tipo di canale diretto TYPE_HARDWARE_BUFFER 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] È VIVAMENTE CONSIGLIATO per il supporto della funzionalità android.hardware.sensor.hifi_sensors.
• [C-1-22] DEVE avere una latenza end-to-end tra moto e fotoni non superiore a 28 millisecondi.
• [C-SR-9] È VIVAMENTE CONSIGLIATO avere una latenza end-to-end tra movimenti e fotoni non superiore a 20 millisecondi.
• [C-1-23] DEVE avere un rapporto del primo fotogramma, ovvero il rapporto tra la luminosità dei pixel sul primo fotogramma dopo una transizione dal nero al bianco e la luminosità dei pixel bianchi in stato stabile, pari ad almeno l'85%.
• [C-SR-10] È VIVAMENTE CONSIGLIATO avere una percentuale di primo fotogramma di almeno il 90%.
• POTREBBE fornire un core esclusivo all'applicazione in primo piano e supportare l'API Process.getExclusiveCores per restituire i numeri di core CPU esclusivi dell'applicazione in primo piano.

Se è supportato un core esclusivo, il core:

• [C-2-1] DEVE non consentire l'esecuzione di altri processi dello spazio utente (ad eccezione dei driver di dispositivo utilizzati dall'applicazione), ma POTREBBE consentire l'esecuzione di alcuni processi del kernel all'occorrenza.

7.10. Tecnologia aptica

Crea nuovi requisiti

I dispositivi da tenere in mano o da indossare possono includere un attuatore aptico per uso generico, disponibile per le applicazioni, allo scopo di attirare l'attenzione tramite suonerie, allarmi, notifiche e feedback tattili generali.

Se le implementazioni dei dispositivi NON includono un attuatore aptico per uso generico:

• [7.10/C] DEVE restituire false per Vibrator.hasVibrator().

Se le implementazioni dei dispositivi NON includono almeno uno di questi attuatori aptici per uso generico, questi:

• [C-1-1] DEVE restituire true per Vibrator.hasVibrator().
• NON utilizzare un attuatore aptico aptico (vibratore) a massa rotante eccentrica (ERM).
• DEVE implementare tutte le costanti pubbliche per una risoluzione aptica chiara in android.view.HapticFeedbackConstants vale a dire (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START e GESTURE_END).
• DOVREBBE implementare tutte le costanti pubbliche per la aptica chiara in android.os.VibrationEffect vale a dire (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK e EFFECT_DOUBLE_CLICK) e tutte le costanti PRIMITIVE_* pubbliche applicabili per la tecnologia aptica avanzata in android.os.VibrationEffect.Composition vale a dire (CLICK, TICK, LOW_TICK, LOW_TICKQUICK_FALLQUICK_RISESLOW_RISESPINSPINTHUD
• DEVE seguire le linee guida per la mappatura delle costanti pubbliche in android.view.HapticFeedbackConstants alle costanti android.os.VibrationEffect consigliate, con le relazioni di ampiezza corrispondenti.
• DEVI utilizzare queste mappature della costante aptica collegata.
• DEVE seguire la valutazione della qualità per le API createOneShot() e createWaveform().
• DEVONO verificare che il risultato dell'API pubblica di android.os.Vibrator.hasAmplitudeControl() rispecchi correttamente le capacità della vibrazione.
• DEVI verificare le funzionalità per la scalabilità dell'ampiezza eseguendo android.os.Vibrator.hasAmplitudeControl().

Se le implementazioni dei dispositivi seguono la mappatura della costante aptica, questi:

• DEVI verificare lo stato dell'implementazione eseguendo le API android.os.Vibrator.areAllEffectsSupported() e android.os.Vibrator.arePrimitivesSupported().
• DOVREBBE eseguire una valutazione della qualità per le costanti aptiche.
• DEVE verificare e aggiornare, se necessario, la configurazione di riserva per le primitive non supportate, come descritto nelle indicazioni per l'implementazione per le costanti.
• DOVREBBE fornire assistenza di riserva per ridurre il rischio di errore come descritto qui.

Termina nuovi requisiti

Consulta la Sezione 2.2.1 per i requisiti specifici del dispositivo.

7.11. Classe di rendimento dei media

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

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

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

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

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

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

Consulta la sezione 2.2.7 per i requisiti specifici del dispositivo.

8. Prestazioni e potenza

Alcuni criteri minimi per le prestazioni e l'alimentazione sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di base che gli sviluppatori avrebbero quando sviluppano un'app.

8.1. Coerenza dell'esperienza utente

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

8.2. Prestazioni accesso file I/O

Fornire una base comune per prestazioni di accesso ai file coerenti nell'archiviazione dei dati privati dell'applicazione (/data partizione) consente agli sviluppatori di app di impostare un'aspettativa adeguata che aiuterebbe la progettazione 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. Misurato scrivendo un file da 256 MB con un buffer di scrittura da 10 MB.
• Prestazioni di scrittura casuale. Misurato scrivendo un file da 256 MB utilizzando un buffer di scrittura da 4 kB.
• Prestazioni di lettura sequenziale. Misurato leggendo un file da 256 MB con un buffer di scrittura da 10 MB.
• Prestazioni di lettura casuale. Misurato leggendo un file da 256 MB utilizzando un buffer di scrittura da 4 KB.

8.3. Modalità di risparmio energetico

Se le implementazioni dei dispositivi includono funzionalità per migliorare la gestione dell'alimentazione dei dispositivi incluse in AOSP (ad es. bucket di standby delle app, sospensione) o estendi le funzionalità per applicare limitazioni più forti rispetto al bucket di standby delle app RESTRICTO:

• [C-1-1] NON DEVE discostarsi dall'implementazione AOSP per gli algoritmi di attivazione, manutenzione e riattivazione e per l'uso delle impostazioni di sistema globali o di DeviceConfig delle modalità di risparmio energetico delle app e Sospensione.
• [C-1-2] NON DEVE discostarsi dall'implementazione AOSP per l'uso delle impostazioni globali o da DeviceConfig per gestire la limitazione di job, allarmi e rete per le app in ogni bucket per lo standby delle app.
• [C-1-3] NON DEVE discostarsi dall'implementazione di AOSP per il numero di bucket di standby delle app utilizzati per lo standby delle app.
• [C-1-4] DEVE implementare i bucket di standby delle app e 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 l'invito all'utente per visualizzare tutte le app esenti dalle modalità di risparmio energetico di App Standby e Sospensione o da eventuali ottimizzazioni della batteria e DEVE implementare l'intento ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS per chiedere all'utente di consentire a un'app di ignorare le ottimizzazioni della batteria.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di fornire all'utente l'invito per attivare e disattivare la funzionalità di risparmio energetico.
• [C-SR-2] È VIVAMENTE CONSIGLIATO di fornire all'utente l'invito per visualizzare tutte le app esenti dalle modalità di risparmio energetico di Standby delle app e Sospensione.

Se le implementazioni dei dispositivi estendono le funzionalità di gestione dell'alimentazione incluse in AOSP e l'estensione applica restrizioni più rigorose rispetto al bucket standby delle app raro, consulta la sezione 3.5.1.

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

Se le implementazioni del dispositivo implementano gli stati di alimentazione S4 come definito dall'ACPI, questi:

• [C-1-1] DEVE entrare in questo stato solo dopo che l'utente ha intrapreso un'azione esplicita che pone il dispositivo in stato di inattività (ad esempio chiudendo un coperchio che fa parte del dispositivo o spegnendo un veicolo o un televisore) e prima che l'utente riattivi il dispositivo (ad esempio aprendo il coperchio o riaccendendo il veicolo o il televisore).

Se le implementazioni del dispositivo implementano gli stati di alimentazione S3 come definito dall'ACPI, questi:

• [C-2-1] DEVE soddisfare il precedente C-1-1 oppure DEVE entrare nello stato S3 solo quando le applicazioni di terze parti non hanno bisogno delle risorse di sistema (ad esempio, lo schermo, la CPU).

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

  Ad esempio, anche se le applicazioni di terze parti richiedono di mantenere lo schermo acceso fino a FLAG_KEEP_SCREEN_ON o di mantenere la CPU in esecuzione attraverso 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 attivare lo stato di inattività del dispositivo. Al contrario, nel momento in cui viene attivata un'attività implementata da app di terze parti tramite JobScheduler o Firebase Cloud Messaging viene inviata ad app di terze parti, il dispositivo DEVE uscire dallo stato S3, a meno che l'utente non abbia attivato lo stato inattivo. Non si tratta di esempi completi e AOSP implementa indicatori di wakeup estesi che attivano un wakeup da questo stato.

8.4. Contabilità consumo energetico

Una contabilità e un report più accurati sul consumo energetico forniscono allo sviluppatore di app sia gli incentivi sia gli strumenti per ottimizzare il modello di consumo energetico dell'applicazione.

Implementazioni dei dispositivi:

• [C-SR-1] VIVAMENTE CONSIGLIATO di fornire un profilo di alimentazione per componente che definisca il valore del consumo attuale per ciascun componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
• [C-SR-2] VIVAMENTE CONSIGLIATO di riportare tutti i valori del consumo energetico in milliampere ora (mAh).
• [C-SR-3] VIVAMENTE CONSIGLIATO di segnalare il consumo energetico della CPU per ogni UID di processo. Il progetto open source Android soddisfa il requisito tramite l'implementazione del modulo kernel uid_cputime.
• [C-SR-4] VIVAMENTE CONSIGLIATO di rendere disponibile allo sviluppatore dell'app questo consumo energetico tramite il comando shell adb shell dumpsys batterystats.
• DOVREBBERO essere attribuiti al componente hardware stesso se non è possibile attribuire l'utilizzo dell'energia al componente hardware a un'applicazione.

8.5. Prestazioni costanti

Le prestazioni possono variare notevolmente per le app a lunga esecuzione ad alte prestazioni, a causa delle altre app in esecuzione in background o della limitazione della CPU a causa dei limiti di temperatura. Android include interfacce programmatiche che, quando il dispositivo è in grado di funzionare, l'applicazione in primo piano di primo livello può richiedere al sistema di ottimizzare l'allocazione delle risorse per risolvere queste fluttuazioni.

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare in modo preciso il supporto della modalità di rendimento sostenuto tramite il metodo API PowerManager.isSustainedPerformanceModeSupported().

• DEVE supportare la modalità di rendimento sostenuto.

Se le implementazioni dei dispositivi registrano il supporto della modalità Rendimento sostenuto:

• [C-1-1] DEVE fornire all'applicazione in primo piano principale un livello coerente 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 del dispositivo includono due o più core CPU:

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

• [C-2-1] DEVE segnalare tramite il metodo API Process.getExclusiveCores() gli ID dei core esclusivi che possono essere prenotati dall'applicazione in primo piano principale.
• [C-2-2] DEVE non consentire l'esecuzione su core esclusivi di alcun processo dello spazio utente, ad eccezione dei driver di dispositivo utilizzati dall'applicazione, ma POTREBBE consentire l'esecuzione di alcuni processi del kernel all'occorrenza.

Se le implementazioni del dispositivo 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 per sicurezza e autorizzazioni nelle API della documentazione per gli sviluppatori Android.

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

Se le implementazioni dei dispositivi dichiarano la funzionalità android.hardware.security.model.compatible:

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

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. In particolare, DEVONO applicare in modo forzato ogni autorizzazione e ruolo definiti come descritto nella documentazione dell'SDK; nessuna autorizzazione e nessun ruolo può essere omesso, alterato o ignorato.

• POTREBBE aggiungere ulteriori autorizzazioni, a condizione che le nuove stringhe degli ID autorizzazione non si trovino nello spazio dei nomi android.\*.

• [C-0-2] Le autorizzazioni con protectionLevel di PROTECTION_FLAG_PRIVILEGED DEVONO essere concesse soltanto alle app preinstallate nei percorsi con privilegi dell'immagine di sistema (nonché nei file APEX) e rientrare nel sottoinsieme delle autorizzazioni esplicitamente incluse nella lista consentita per ogni app. L'implementazione AOSP soddisfa questo requisito leggendo e rispettando le autorizzazioni nella lista consentita per ogni app dai file nel percorso etc/permissions/ come percorso system/priv-app.etc/permissions/ e utilizzando il privilegio system/priv-app.

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

Implementazioni dei dispositivi:

• [C-0-3] DEVE mostrare all'utente un'interfaccia dedicata per decidere se concedere le autorizzazioni di runtime richieste, oltre a fornire un'interfaccia per la gestione delle autorizzazioni di runtime.

• [C-0-4] DEVE avere una sola implementazione di entrambe le interfacce utente.

• [C-0-5] NON DEVE concedere autorizzazioni di runtime alle app 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,

    OPPURE

  • Le autorizzazioni di runtime vengono concesse dal criterio di concessione di autorizzazioni predefinito o per il possesso di un ruolo di piattaforma.

• [C-0-6] DEVE concedere l'autorizzazione android.permission.RECOVER_KEYSTORE solo alle app di sistema che registrano un Recovery Agent protetto correttamente. Un agente di ripristino adeguatamente protetto è definito come un agente software on-device che si sincronizza con uno spazio di archiviazione remoto fuori dispositivo, dotato di un hardware sicuro con protezione equivalente o più potente di quanto descritto nel servizio Google Cloud Key Vault per prevenire attacchi di forza bruta al fattore di conoscenza della schermata di blocco.

Implementazioni dei dispositivi:

• [C-0-7] DEVE rispettare le proprietà delle autorizzazioni 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. Tali dati includono, a titolo esemplificativo:

  • La posizione del dispositivo (ad esempio, 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.

In particolare, le implementazioni dei dispositivi:

• [C-0-8] DEVE ottenere il consenso degli utenti 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 dispone di un'autorizzazione sufficiente, come descritto nell'SDK. Ad esempio, TelephonyManager#getServiceState richiede android.permission.ACCESS_FINE_LOCATION).

Le uniche eccezioni alle proprietà relative all'autorizzazione di accesso alla posizione per Android riportate sopra riguardano le app che non accedono alla posizione per ricavarne o identificare la posizione dell'utente; in particolare:

• Quando le app contengono l'autorizzazione RADIO_SCAN_WITHOUT_LOCATION.
• Ai fini della configurazione e della configurazione del dispositivo, in cui le app di sistema detengono l'autorizzazione NETWORK_SETTINGS o NETWORK_SETUP_WIZARD.

Le autorizzazioni possono essere contrassegnate come limitate, che ne alterano 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 un ruolo associato alle autorizzazioni hardRestricted a un'app.
  • Il programma di installazione concede hardRestricted a un'app.
  • A un'app viene concesso il hardRestricted su una versione precedente di Android.

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

• [C-0-12] NON DEVE fornire funzioni o API personalizzate per ignorare le limitazioni di autorizzazione definite nelle API setPermissionPolicy e setPermissionGrantState.

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

• [C-0-14] DEVE assegnare ruoli solo ad applicazioni con funzionalità che soddisfano i requisiti dei ruoli.

• [C-0-15] Non DEVE definire ruoli che sono duplicati o funzionalità soprainsieme di ruoli definiti dalla piattaforma.

Se i dispositivi segnalano android.software.managed_users, questi:

• [C-1-1] NON DEVE disporre delle seguenti autorizzazioni automaticamente concesse dall'amministratore:
  • 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 dei dispositivi forniscono all'utente l'autorizzazione a scegliere quali app possono attingere ad altre app con un'attività che gestisce l'intent ACTION_MANAGE_OVERLAY_PERMISSION, queste:

• [C-2-1] DEVE garantire che tutte le attività con filtri per intent per l'intent ACTION_MANAGE_OVERLAY_PERMISSION abbiano la stessa schermata dell'interfaccia utente, indipendentemente dall'app iniziale o da qualsiasi informazione fornita.

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

• [C-3-1] DEVE mostrare un disclaimer durante la configurazione del dispositivo completamente gestito (configurazione del proprietario del dispositivo) in cui si specifica che l'amministratore IT potrà consentire alle app di controllare le impostazioni sullo smartphone, inclusi microfono, fotocamera e posizione, con la possibilità di continuare la configurazione o uscire dalla configurazione A MENO che l'amministratore abbia disattivato il controllo delle autorizzazioni sul dispositivo.

Se le implementazioni dei dispositivi preinstallano eventuali pacchetti contenenti 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 ambientali e a livello di sistema operativo e 9.8.15 Implementazioni di API con sandbox".

• [C-4-2] NON DEVE avere l'autorizzazione android.permission.INTERNET. Questo è più difficile rispetto a quanto indicato nella sezione 9.8.6.
• [C-4-3] NON DEVE essere vincolato ad altre app, ad eccezione delle seguenti app di sistema: Bluetooth, Contatti, Contenuti multimediali, Telefonia, SystemUI e componenti che forniscono API internet. Questo valore è più rigoroso rispetto a quanto indicato nella sezione 9.8.6 VIVAMENTE CONSIGLIATA.

Crea nuovi requisiti

Se le implementazioni del dispositivo includono un'applicazione predefinita per supportare i VoiceInteractionService, questi:

• [C-5-1] NON DEVE concedere ACCESS_FINE_LOCATION come impostazione predefinita per tale applicazione.

Termina nuovi requisiti

9.2. UID e isolamento dei processi

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare il modello sandbox per le applicazioni Android, in cui ogni applicazione viene eseguita come UID Unixstyle univoco e in un processo separato.
• [C-0-2] DEVE supportare l'esecuzione di più applicazioni con lo stesso ID utente Linux, a condizione che le applicazioni siano firmate e create correttamente, come definito nel riferimento su 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 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 autorizzazione di Android, anche se includono ambienti di runtime che eseguono applicazioni utilizzando un software o una tecnologia diversi dal formato eseguibile Dalvik o dal codice nativo. In altre parole:

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

• [C-0-2] NON DEVE essere concesso ai runtime alternativi l'accesso a 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 usare funzionalità protette da 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, a meno che tramite i meccanismi Android standard di ID utente condiviso e certificato di firma.

• [C-0-5] I runtime alternativi NON DEVONO avviarsi con, concedere o avere l'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 privilegi del super user (root) o di qualsiasi altro ID utente.

• [C-0-7] Quando i file .apk di runtime alternativi vengono 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 di 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 dispositivo per la quale esiste un'autorizzazione Android corrispondente (ad esempio Fotocamera, GPS e così via), il runtime alternativo DEVE informare l'utente che l'applicazione potrà accedere a tale risorsa.

• [C-0-10] Quando l'ambiente di runtime non registra le capacità 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 utilizza tale runtime.

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

• I runtime alternativi POTREBBERO fornire un'unica sandbox Android condivisa da tutte le applicazioni che utilizzano il runtime alternativo.

9.5 Supporto di più utenti

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

• Le implementazioni dei dispositivi POSSONO, ma NON DEVONO abilitare la funzionalità multiutente se utilizzano supporti rimovibili per l'unità di archiviazione esterna principale.

Se le implementazioni dei dispositivi includono il supporto per più utenti, questi:

• [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 per sicurezza e autorizzazioni nelle API.
• [C-1-3] DEVE avere directory di archiviazione delle applicazioni condivise separate e isolate (noto anche come /sdcard) per ogni istanza utente.
• [C-1-4] DEVE garantire che le applicazioni di proprietà di un determinato utente ed eseguite per suo conto non possano elencare, leggere o scrivere sui file di proprietà di qualsiasi altro utente, anche se i dati di entrambi gli utenti sono archiviati sullo stesso volume o file system.
• [C-1-5] DEVE crittografare i contenuti della scheda SD quando l'opzione Multiutente è abilitata utilizzando una chiave archiviata solo su supporti non rimovibili accessibili solo al sistema se le implementazioni dei dispositivi utilizzano supporti rimovibili per le API di archiviazione esterna. Dal momento che ciò renderà illeggibile i contenuti multimediali 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 per più utenti, per tutti gli utenti, ad eccezione di quelli creati appositamente per eseguire doppie istanze della stessa app, questi:

• [C-2-1] DEVONO avere directory separate e isolate dalle applicazioni condivise (noto anche come /sdcard) per ogni istanza utente.
• [C-2-2] DEVE garantire che le applicazioni di proprietà di un determinato utente e in esecuzione per conto di un determinato utente non possano elencare, leggere o scrivere sui 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) al fine di eseguire due istanze della stessa app. Queste istanze doppie condividono uno spazio di archiviazione parzialmente isolato, vengono presentate all'utente finale contemporaneamente in Avvio app e appaiono nella stessa visualizzazione recenti. Ad esempio, questo può essere usato per supportare l'installazione da parte dell'utente di due istanze separate di una singola app su un dispositivo dual SIM.

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

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

Crea nuovi requisiti

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

• [C-4-5] DEVE distinguere visivamente le icone dell'applicazione a doppia istanza quando le icone vengono presentate agli utenti.
• [C-4-6] DEVE fornire una tariffa utente per eliminare tutti i dati del profilo clone.
• [C-4-7] DEVE disinstallare tutte le app Clone, eliminare le directory dei dati privati dell'app e i relativi contenuti, ed eliminare i dati del profilo Clone, se l'utente sceglie di eliminare interi dati del profilo Clone.
• DOVREBBE richiedere all'utente di eliminare tutti i dati del profilo clone quando viene eliminata l'ultima app clone.
• [C-4-8] DEVE informare l'utente che i dati dell'app verranno eliminati quando l'applicazione di clonazione verrà disinstallata oppure offrire agli utenti un'opzione per conservare i dati dell'app quando l'applicazione viene disinstallata dal dispositivo.
• [C-4-9] DEVE eliminare le directory dei dati private dell'app e i relativi contenuti se l'utente sceglie di eliminare i dati durante la disinstallazione.

• [C-4-1] DEVE consentire la gestione dei seguenti intent provenienti dal profilo aggiuntivo da parte delle applicazioni dell'utente principale sul dispositivo:

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] DEVE ereditare tutte le limitazioni relative agli utenti per i criteri relativi ai dispositivi e le restrizioni non relative agli utenti selezionate(elenco di seguito) applicate all'utente principale del dispositivo a questo profilo utente aggiuntivo.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] DEVE consentire la scrittura di contatti da questo profilo aggiuntivo solo tramite i seguenti intent:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] NON DEVE avere le sincronizzazioni dei contatti in esecuzione per le applicazioni in esecuzione in questo profilo utente aggiuntivo.

• [C-4-14] DEVONO avere autorizzazioni e gestione dello spazio di archiviazione separate per le applicazioni in esecuzione in questo profilo aggiuntivo

• [C-4-5] DEVONO consentire solo alle applicazioni nel profilo aggiuntivo che hanno un'attività Avvio app di accedere ai contatti che sono già accessibili per il profilo utente principale.

Termina nuovi requisiti

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 con un operatore che può comportare un addebito per l'utente.

Se le implementazioni dei dispositivi dichiarano il supporto per android.hardware.telephony:

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

9.7 Funzionalità per la sicurezza

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

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

• [C-0-1] DEVE mantenere la compatibilità con le applicazioni esistenti, anche se SELinux o qualsiasi altra funzionalità di sicurezza sono implementate sotto il framework di Android.
• [C-0-2] NON DEVE avere un'interfaccia utente visibile quando viene rilevata una violazione della sicurezza e bloccata correttamente dalla funzionalità di sicurezza implementata sotto il framework Android, ma POTREBBE avere un'interfaccia utente visibile quando si verifica una violazione della sicurezza sbloccata che determina un exploit.
• [C-0-3] NON DEVE rendere SELinux o qualsiasi altra funzionalità di sicurezza implementata al di sotto del framework Android configurabile per l'utente o lo sviluppatore dell'app.
• [C-0-4] NON DEVE consentire a un'applicazione che può interessare un'altra applicazione tramite un'API (ad esempio un'API di amministrazione del dispositivo) di configurare un criterio che interrompe la compatibilità.
• [C-0-5] DEVE suddividere il framework multimediale in più processi in modo che sia possibile concedere in modo più limitato l'accesso a ogni processo come descritto nel sito del progetto open source Android.
• [C-0-6] DEVE implementare un meccanismo di sandboxing delle applicazioni kernel che permetta di filtrare le chiamate di sistema utilizzando un criterio configurabile da programmi multithread. Il progetto open source Android upstream soddisfa questo requisito mediante l'abilitazione di 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à del kernel e di autoprotezione sono parte integrante della sicurezza di Android. Implementazioni dei dispositivi:

• [C-0-7] DEVE implementare meccanismi di protezione dall'overflow del buffer dello stack del kernel. Esempi di questi meccanismi sono CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] DEVE implementare rigide protezioni della memoria del kernel in cui il codice eseguibile è di sola lettura, i dati di sola lettura non sono eseguibili e non scrivibili e i dati scrivibili non sono eseguibili (ad esempio, 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) su dispositivi originariamente forniti con livello API 28 o superiore.
• [C-0-10] NON DEVE eseguire la memoria dello spazio utente durante l'esecuzione in modalità kernel (ad es. hardware Pxn, o emulata tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) su dispositivi che inizialmente erano disponibili con livello API 28 o superiore.
• [C-0-11] NON DEVE leggere o scrivere la memoria dello spazio utente nel kernel al di fuori delle normali API di accesso alla copia utente (ad es. PAN hardware, o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) su dispositivi originariamente distribuiti con livello API 28 o superiore.
• [C-0-12] DEVE implementare l'isolamento della tabella delle pagine del kernel se l'hardware è vulnerabile a CVE-2017-5754 su tutti i dispositivi originariamente forniti con livello API 28 o superiore (ad es. CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0).

• [C-0-13] DEVE implementare il rafforzamento delle previsioni di rami se l'hardware è vulnerabile a CVE-2017-5715 su tutti i dispositivi originariamente forniti con livello API 28 o superiore (ad es. CONFIG_HARDEN_BRANCH_PREDICTOR).

• [C-SR-1] È VIVAMENTE CONSIGLIATO per abilitare l'inizializzazione dello stack nel kernel per impedire l'uso di variabili locali non inizializzate (CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO). Inoltre, le implementazioni dei dispositivi NON DEVONO assumere il valore utilizzato dal compilatore per inizializzare gli utenti locali.

• [C-SR-2] È VIVAMENTE CONSIGLIATO di mantenere i dati kernel che vengono scritti solo durante l'inizializzazione, contrassegnati come di sola lettura dopo l'inizializzazione (ad es. __ro_after_init).

• [C-SR-3] È VIVAMENTE CONSIGLIATO di randomizzare il layout del codice e della memoria del kernel, nonché di evitare esposizioni che comprometterebbero la randomizzazione (ad es. CONFIG_RANDOMIZE_BASE con entropia del bootloader tramite /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).

• [C-SR-4] È VIVAMENTE CONSIGLIATO di abilitare l'integrità del flusso di controllo (CFI) nel kernel per fornire ulteriore protezione contro gli attacchi da riutilizzo del codice (ad es. CONFIG_CFI_CLANG e CONFIG_SHADOW_CALL_STACK).

• [C-SR-5] È VIVAMENTE CONSIGLIATO di non disattivare l'integrità del flusso di controllo (CFI), lo stack delle chiamate shadow (SCS) o la sanificazione dell'overflow intero (IntSan) sui componenti in cui è abilitato.

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

• [C-SR-7] È VIVAMENTE CONSIGLIATO per abilitare l'inizializzazione dello stack nel kernel per impedire l'uso di variabili locali non inizializzate (CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO). Inoltre, le implementazioni dei dispositivi NON DEVONO assumere il valore utilizzato dal compilatore per inizializzare gli utenti locali.

• [C-SR-8] È VIVAMENTE CONSIGLIATO di abilitare l'inizializzazione dell'heap nel kernel per impedire l'uso di allocazioni di 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 del dispositivo utilizzano un kernel Linux in grado di supportare SELinux, questi:

• [C-1-1] DEVE implementare SELinux.
• [C-1-2] DEVE impostare SELinux sulla modalità di applicazione globale.
• [C-1-3] DEVE configurare tutti i domini in modalità di applicazione forzata. Non sono consentiti domini in modalità permissiva, inclusi i domini specifici di un dispositivo/fornitore.
• [C-1-4] NON DEVE modificare, omettere o sostituire le regole non consentite all'interno della cartella del sistema/sepolicy fornita nell'Android Open Source Project (AOSP) upstream e il criterio DEVE essere compilato con tutte le regole non consentite presenti, sia per i domini AOSP SELinux sia per i domini specifici del dispositivo/fornitore.
• [C-1-5] DEVONO eseguire applicazioni di terze parti che hanno come target il livello API 28 o superiore nelle sandbox SELinux per applicazione con restrizioni SELinux per app sulla directory dei dati privati di ciascuna applicazione.
• DEVE mantenere il criterio SELinux predefinito fornito nella cartella system/sepolicy del progetto open source Android a monte e aggiungere ulteriormente a questo criterio solo per la configurazione specifica del dispositivo.

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

• [C-2-1] DEVE utilizzare un sistema di controllo degli accessi obbligatorio equivalente a SELinux.

Se le implementazioni dei dispositivi utilizzano dispositivi I/O in grado di rispettare il DMA, questi:

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

Android contiene diverse funzionalità di difesa in profondità fondamentali per la sicurezza del dispositivo. Inoltre, Android si concentra sulla riduzione delle classi chiave di bug comuni che contribuiscono a scarsa qualità e sicurezza.

Per ridurre i bug di memoria, le implementazioni del dispositivo:

• [C-SR-10] È VIVAMENTE CONSIGLIATO di essere testati utilizzando strumenti di rilevamento degli errori della memoria dello spazio utente come MTE per i dispositivi ARMv9, HWASan per i dispositivi ARMv8+ o ASan per gli altri tipi di dispositivi.
• [C-SR-11] È VIVAMENTE CONSIGLIATO di essere testati utilizzando strumenti di rilevamento degli errori della memoria kernel come KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS per dispositivi ARMv9, CONFIG_KASAN_SW_TAGS per dispositivi ARMv8 o CONFIG_KASAN_GENERIC per altri tipi di dispositivi).
• [C-SR-12] È VIVAMENTE 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 TrustZone ARM:

• [C-SR-13] Ti consigliamo vivamente di utilizzare un protocollo standard per la condivisione della memoria tra Android e TEE, come il framework del firmware ARM per Armv8-A (FF-A).
• [C-SR-14] È VIVAMENTE CONSIGLIATO di limitare le applicazioni attendibili all'accesso solo alla memoria che è stata esplicitamente condivisa con loro tramite il protocollo sopra indicato. Se il dispositivo supporta il livello di eccezione ARM S-EL2, questo deve essere applicato dal gestore della partizione sicura. In caso contrario, questa operazione dovrebbe essere applicata dal sistema operativo TEE.

Crea nuovi requisiti

Una tecnologia di sicurezza della memoria è una tecnologia che mitiga almeno le seguenti classi di bug con una probabilità elevata (> 90%) nelle applicazioni che utilizzano l'opzione manifest android:memtagMode:

• overflow del buffer heap
• utilizzare dopo le spese
• doppio senza costi
• wild free (privo di un puntatore non-malloc)

Implementazioni dei dispositivi:

• [C-SR-15] È VIVAMENTE CONSIGLIATO di impostare ro.arm64.memtag.bootctl_supported.

Se le implementazioni dei dispositivi impostano la proprietà di sistema ro.arm64.memtag.bootctl_supported su true, questi:

• [C-3-1] DEVE consentire alla proprietà di sistema arm64.memtag.bootctl di accettare un elenco separato da virgole dei seguenti valori, con l'effetto desiderato applicato al successivo riavvio successivo:

  • memtag: è stata attivata una tecnologia di sicurezza della memoria come definita sopra
  • memtag-once: una tecnologia Memory Safety come definita sopra è abilitata temporaneamente e viene disattivata automaticamente al successivo riavvio
  • memtag-off: una tecnologia di sicurezza della memoria come definita sopra è disattivata

• [C-3-2] DEVE consentire all'utente shell di impostare arm64.memtag.bootctl.

• [C-3-3] DEVE consentire a qualsiasi processo di leggere arm64.memtag.bootctl.

• [C-3-4] DEVE impostare arm64.memtag.bootctl sullo stato attualmente richiesto all'avvio, DEVE anche aggiornare la proprietà, se l'implementazione del dispositivo consente di modificare lo stato senza cambiare la proprietà di sistema.

• [C-SR-16] È VIVAMENTE CONSIGLIATO di mostrare un'impostazione sviluppatore che imposti memtag-una volta e riavvii il dispositivo. Con un bootloader compatibile, il progetto open source Android soddisfa i requisiti riportati sopra tramite il protocollo bootloader MTE.

• [C-SR-17] È VIVAMENTE CONSIGLIATO di mostrare un'impostazione nel menu Impostazioni di sicurezza che consenta all'utente di abilitare memtag.

Termina nuovi requisiti

9.8 Privacy

9.8.1. Cronologia di utilizzo

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

Implementazioni dei dispositivi:

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

Android archivia gli eventi di sistema utilizzando gli identificatori StatsLog e gestisce questa cronologia tramite l'API StatsManager e l'API di sistema IncidentManager.

Implementazioni dei dispositivi:

• [C-0-2] DEVE includere solo i campi contrassegnati con DEST_AUTOMATIC nel report sugli incidenti creato dalla classe dell'API di sistema IncidentManager.
• [C-0-3] Non DEVE utilizzare gli identificatori di eventi di sistema per registrare altri eventi diversi da quelli descritti nei StatsLog documenti SDK. Se vengono registrati altri eventi di sistema, POTREBBE utilizzare un identificatore atomico 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 immediatamente componenti software che inviano informazioni private dell'utente (ad es. sequenze di tasti, testo visualizzato sullo schermo, segnalazione di bug) dal dispositivo senza il consenso dell'utente o senza chiare notifiche in corso.
• [C-0-2] DEVE visualizzare un avviso relativo all'utente e ottenere il consenso esplicito dell'utente consentendo l'acquisizione di qualsiasi informazione sensibile visualizzata sullo schermo dell'utenteche includa esattamente lo stesso messaggio di AOSP ogni volta ogni volta che una sessione per acquisire lo schermo trasmissione o registrazione dello schermo viene attivata/i 1.0MediaProjection.createVirtualDisplay()VirtualDeviceManager.createVirtualDisplay() NON DEVE offrire agli utenti una possibilità di disattivare la futura visualizzazione del consenso dell'utente.
• [C-0-3] DEVE avere una notifica fissa per l'utente mentre è attiva la trasmissione o la registrazione dello schermo. AOSP soddisfa questo requisito mostrando un'icona di notifica continua nella barra di stato.

Crea nuovi requisiti

• [C-SR-1] È VIVAMENTE CONSIGLIATO di visualizzare un avviso all'utente che è esattamente lo stesso messaggio implementato in AOSP ma PUÒ essere modificato purché il messaggio avvisi chiaramente l'utente che vengono acquisite informazioni sensibili sullo schermo dell'utente.

• [C-0-4] NON DEVE fornire agli utenti un'invito per disabilitare le richieste future del consenso dell'utente per l'acquisizione dello schermo, a meno che la sessione non venga avviata da un'app di sistema che l'utente ha autorizzato a associate() con il profilo del dispositivo android.app.role.COMPANION_DEVICE_APP_STREAMING o android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING.

  Termina nuovi requisiti

Se le implementazioni dei dispositivi includono funzionalità nel sistema che acquisiscono i contenuti visualizzati sullo schermo e/o registrano lo stream audio riprodotto sul dispositivo diversi dall'API di sistema ContentCaptureService o altri mezzi proprietari descritti nella Sezione 9.8.6 Dati ambientali e a livello di sistema operativo:

• [C-1-1] DEVE avere una notifica continua per l'utente ogni volta che questa funzionalità viene attivata e l'acquisizione/registrazione è attiva.

Se le implementazioni del dispositivo includono un componente pronto all'uso abilitato per registrare l'audio ambientale e/o l'audio riprodotto sul dispositivo per dedurre informazioni utili sul contesto dell'utente, questi:

• [C-2-1] NON DEVE archiviare nello spazio di archiviazione permanente sul dispositivo né trasmettere al di fuori del dispositivo l'audio RAW registrato o qualsiasi formato che possa essere riconvertito nell'audio originale o in un vicino facsimile, salvo esplicito consenso dell'utente.

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

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

Dopo il primo secondo visualizzato, un indicatore può cambiare visivamente, ad esempio diventa più piccolo, e non deve essere mostrato come presentato e compreso inizialmente.

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

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

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

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

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

• [C-SR-4] È VIVAMENTE CONSIGLIATO di visualizzare l'indicatore della fotocamera quando un'app accede ai dati della fotocamera in diretta, ma non quando la fotocamera è accessibile solo dall'app che hanno i ruoli descritti nella Sezione 9.1 Autorizzazioni con l'identificatore CDD [C-3-X].
• [C-SR-5] È VIVAMENTE CONSIGLIATO di mostrare le app recenti e attive che usano la fotocamera restituita da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.
• [C-SR-6] CONSIGLIATO VIVAMENTE di non nascondere l'indicatore della fotocamera per le app di sistema con interfacce utente visibili o interazione diretta dell'utente.

9.8.3. Connettività

Se le implementazioni dei dispositivi hanno 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 dell'archivio 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 dell'autorità di certificazione (CA) attendibile dal sistema così come forniti nel progetto open source Android a monte.
• [C-0-2] DEVE essere fornito con un archivio CA radice dell'utente vuoto.
• [C-0-3] DEVE mostrare all'utente un avviso che indica che il traffico di rete potrebbe essere monitorato quando viene aggiunta una CA radice dell'utente.

Se il traffico dei dispositivi viene instradato tramite VPN, le implementazioni dei dispositivi:

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

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

• [C-2-1] DEVE chiedere il consenso dell'utente prima di attivare questo meccanismo, a meno che la VPN non sia attivata dal controller dei criteri dei dispositivi tramite DevicePolicyManager.setAlwaysOnVpnPackage() . In questo caso l'utente non deve fornire un consenso separato, ma DEVE ricevere soltanto una notifica.

Se le implementazioni del dispositivo implementano l'autorizzazione dell'utente per attivare la funzione "VPN sempre attiva" di un'app VPN di terze parti, l'utente:

• [C-3-1] DEVE disattivare l'accettazione di questo utente 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 da un'app al numero di serie del dispositivo e, ove applicabile, a IMEI/MEID, numero di serie della SIM e IMSI (International Mobile Subscriber Identity), a meno che non soddisfi uno dei seguenti requisiti:
  • è un'app dell'operatore firmata e verificata dai produttori di dispositivi.
  • a cui è stata concessa l'autorizzazione READ_PRIVILEGED_PHONE_STATE.
  • dispone dei privilegi di operatore definiti in Privilegi degli operatori UICC.
  • è un proprietario del dispositivo o del profilo a cui è stata concessa l'autorizzazione READ_PHONE_STATE.
  • (Solo per il numero di serie della SIM/ICCID) prevede il requisito delle normative locali che prevede che l'app rilevi cambiamenti nell'identità dell'abbonato.

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

Android, tramite le API di sistema ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query o con altri mezzi proprietari, supporta un meccanismo che consente alle implementazioni di dispositivi di acquisire le seguenti interazioni di dati delle applicazioni tra le applicazioni e l'utente dati sensibili:

• Testo e grafici visualizzati sullo schermo, inclusi, a titolo esemplificativo, notifiche e dati relativi all'evento indiretto tramite l'API AssistStructure.
• Dati multimediali, ad esempio audio o video, registrati o riprodotti dal dispositivo.
• Eventi di input (ad es. tasto, mouse, gesto, voce, video e accessibilità).

Crea nuovi requisiti

• Qualsiasi schermata o altri dati inviati tramite AugmentedAutofillService al sistema.
• Qualsiasi schermata o altri dati accessibili tramite l'API Content Capture.
• Qualsiasi schermata o altro dato accessibile tramite l'API FieldClassificationService
• Tutti i dati dell'applicazione trasmessi al sistema tramite l'API AppSearchManager e accessibili tramite AppSearchGlobalManager.query.

Termina nuovi requisiti

• Qualsiasi altro evento fornito da un'applicazione al sistema tramite l'API Content Capture o l'API AppSearchManager un'API Android e un'API proprietaria con funzionalità simili.

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

Crea nuovi requisiti

• Dati audio ottenuti a seguito dell'uso di SpeechRecognizer#onDeviceSpeechRecognizer() da parte dell'implementazione del riconoscimento vocale.
• Dati audio ottenuti in background (continua) tramite AudioRecord, SoundTrigger o altre API audio; non viene quindi mostrato un indicatore visibile all'utente
• Dati della videocamera ottenuti in background (continua) tramite CameraManager o altre API Camera; non viene visualizzato un indicatore visibile all'utente

Termina nuovi requisiti

Se le implementazioni del dispositivo acquisiscono uno qualsiasi dei dati sopra indicati:

• [C-1-1] DEVE crittografare tutti questi dati quando sono memorizzati nel dispositivo. La crittografia POTREBBE essere eseguita utilizzando la crittografia basata su file Android o una qualsiasi delle crittografie elencate come versione API 26 o successive descritte nell'SDK Cipher.
• [C-1-2] NON DEVE eseguire il backup dei dati non elaborati o criptati utilizzando i metodi di backup di Android o qualsiasi altro metodo di backup.
• [C-1-3] DEVE inviare tutti questi dati e il log dal dispositivo solo utilizzando un meccanismo che tutela la privacy, salvo con il consenso esplicito dell'utente ogni volta che i dati vengono condivisi. Il meccanismo di tutela della privacy è definito come "quelli che consentono solo l'analisi in forma aggregata e impediscono la corrispondenza di eventi registrati o risultati derivati per i singoli utenti", per evitare che qualsiasi dato per utente sia introspezionabile (ad es. implementato utilizzando una tecnologia di privacy differenziale come RAPPOR).
• [C-1-4] NON DEVE associare questi dati a identità utente (ad esempio Account) sul dispositivo, salvo 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 rispettano i requisiti descritti nella sezione corrente (9.8.6 Acquisizione di contenuti Dati ambientali e a livello di sistema operativo), salvo che con il consenso esplicito dell'utente ogni volta che vengono condivisi. A meno che questa funzionalità non sia creata come un'API SDK Android (AmbientContext, HotwordDetectionService).
• [C-1-6] DEVE fornire all'utente l'autorizzazione a cancellare i dati che l'implementazione di ContentCaptureService o i mezzi proprietari raccolgono se quando i dati vengono archiviati in qualsiasi formato sul dispositivo. Se l'utente sceglie di cancellare i dati, DEVE rimuovere tutti i dati storici raccolti.
• [C-1-7] DEVE fornire all'utente l'autorizzazione a disattivare la visualizzazione dei dati, raccolti tramite AppSearch o tramite mezzi proprietari, nella piattaforma Android, ad esempio Avvio app.
• [C-SR-1] CONSIGLIATO VIVAMENTE di NON richiedere l'autorizzazione INTERNET.
• [C-SR-2] CONSIGLIATO VIVAMENTE di accedere a internet solo tramite API strutturate supportate da implementazioni open source disponibili pubblicamente.

Crea nuovi requisiti

• [C-SR-4] È VIVAMENTE CONSIGLIATO di essere implementato con l'API Android SDK o un repository open source simile di proprietà dell'OEM e / o da eseguire in un'implementazione con sandbox (consulta la sezione 9.8.15 Implementazioni API con sandbox).

Termina nuovi requisiti

Se le implementazioni del dispositivo includono un servizio che implementa l'API di sistema ContentCaptureService, AppSearchManager.index o qualsiasi servizio proprietario che acquisisce i dati come descritto sopra, questi:

• [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 app diverse dal meccanismo dei servizi preinstallati di acquisire questi dati.
• [C-2-3] DEVE fornire l'invito all'utente per disabilitare i servizi.
• [C-2-4] NON DEVE omettere l'autorizzazione 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] CONSIGLIATO VIVAMENTE per mantenere i servizi separati dagli altri componenti di sistema(ad es. non vincolare gli ID servizio o di condivisione dei processi), ad eccezione di quanto segue:

  • Telefonia, contatti, UI di sistema e contenuti multimediali

Android, tramite SpeechRecognizer#onDeviceSpeechRecognizer(), offre la possibilità di eseguire il riconoscimento vocale sul dispositivo senza coinvolgere la rete. Qualsiasi implementazione di SpeechRiconoscimento on-device DEVE seguire i criteri descritti in questa sezione.

9.8.7. Accesso agli appunti

Implementazioni dei dispositivi:

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

• [C-0-2] DEVE cancellare i dati degli appunti al massimo 60 minuti dopo l'ultima volta che sono stati inseriti negli appunti o letti da un blocco.

9.8.8. Posizione

La posizione include informazioni nella classe di geolocalizzazione di Android( ad esempio latitudine, longitudine e altitudine), nonché identificatori che possono essere convertiti in Posizione. La località può essere precisa come DGPS (Diffial Global Positioning System) o approssimativa rispetto a quella a livello di paese (ad esempio località del codice paese - Centro clienti - Codice paese mobile).

Di seguito è riportato un elenco dei tipi di località che derivano direttamente dalla posizione di un utente o che possono essere convertiti in quest'ultima. Non si tratta di un elenco completo, ma dovrebbe essere utilizzato come esempio su quale località può essere ricavata direttamente o indirettamente da:

• GPS/GNSS/DGPS/PPP
  • Global Positioning Solution, Global Navigation Satellite o Integrated Global Positioning Solution
  • Sono inclusi anche le misurazioni GNSS non elaborate e lo stato GNSS.
    • La posizione precisa può essere ricavata dalle misurazioni GNSS non elaborate
• Tecnologie wireless con identificatori univoci come:
  • Punti di accesso Wi-Fi (MAC, BSSID, nome o SSID)
  • Bluetooth/BLE (MAC, BSSID, nome o SSID)
  • UWB (MAC, BSSID, nome o SSID)
  • ID ripetitore di telefonia mobile (3G, 4G, 5G... comprese tutte le future tecnologie di modem cellulare che hanno identificatori univoci)

Come punto di riferimento principale, vedi 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 la sua iniziativa.
• [C-0-2] DEVE fornire all'utente l'autorizzazione ad accedere alle informazioni relative alla posizione, tra cui richieste di posizione recenti, autorizzazioni a livello di app e utilizzo della scansione Wi-Fi/Bluetooth per determinare la posizione.
• [C-0-3] DEVE garantire che l'applicazione che utilizza l'API Emergency Location Bypass [LocationRequest.setLocationSettings ignorid()] sia una sessione di emergenza avviata dall'utente (ad es. componi il numero 911 o invii un messaggio al numero 112). Nel settore auto e motori, invece, un veicolo POTREBBE avviare una sessione di emergenza senza interazione dell'utente attiva nel caso in cui venga rilevato un incidente/incidente (ad es. per soddisfare i requisiti di eCall).
• [C-0-4] DEVE preservare la capacità dell'API Emergency Location Bypass di eludere le impostazioni di geolocalizzazione del dispositivo senza modificare le impostazioni.
• [C-0-5] DEVE pianificare una notifica che ricordi all'utente dopo che un'app in background ha eseguito l'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 relativi ad altre app installate (consulta la sezione Visibilità dei pacchetti nella documentazione dell'SDK Android).

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE essere esposta ad alcun livello API target dell'app di livello 30 o superiore relativo a qualsiasi altra app installata, a meno che l'app non sia già in grado di vedere i dettagli dell'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 ad alcuna app, leggere o scrivere l'accesso ai file nella directory specifica delle app di qualsiasi altra app all'interno della memoria esterna. Le uniche eccezioni sono le seguenti:
  • L'autorità del fornitore di archiviazione esterna (ad esempio app come DocumentsUI).
  • Provider di download che utilizza l'autorità del provider "download" per scaricare file nello spazio di archiviazione delle app.
  • App MTP (Media Transfer Protocol) con firma a piattaforma che utilizzano l'autorizzazione con privilegi 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" per gestire i file di espansione APK.

9.8.10. Report sui bug relativi alla connettività

Se le implementazioni dei dispositivi dichiarano il flag funzionalità android.hardware.telephony, :

• [C-1-1] DEVE supportare la generazione di report di bug relativi alla connettività tramite BUGREPORT_MODE_TELEPHONY con BugreportManager.
• [C-1-2] DEVE ottenere il consenso dell'utente ogni volta che viene utilizzato BUGREPORT_MODE_TELEPHONY per generare un report e NON DEVE richiedere 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:
  • Dump TelephonyDebugService
  • Dump TelephonyRegistry
  • Dump WifiService
  • Dump ConnectivityService
  • Un dump dell'istanza CarrierService del pacchetto chiamante (se vincolata)
  • Buffer log radio
  • SubscriptionManagerService dump
• [C-1-5] NON DEVE includere quanto segue nei report generati:
  • Qualsiasi tipo di informazione non direttamente correlata al debug della connettività.
  • Qualsiasi tipo di log del traffico delle applicazioni installate dall'utente o profili dettagliati di applicazioni o pacchetti installati dall'utente (gli UID sono validi, non i nomi dei pacchetti).
• POTREBBERO includere informazioni aggiuntive non associate a nessuna identità utente. (ad es. log dei fornitori).

Se le implementazioni dei dispositivi includono informazioni aggiuntive (ad es. i log dei fornitori) nei report di bug e queste informazioni hanno un impatto su privacy/sicurezza/batteria/archiviazione/memoria, queste:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di disattivare un'impostazione sviluppatore per impostazione predefinita. L'implementazione del riferimento AOSP soddisfa questo requisito fornendo l'opzione Enable verbose vendor logging nelle impostazioni sviluppatore per includere log aggiuntivi del fornitore specifico per dispositivo nelle segnalazioni di bug.

9.8.11. Condivisione dei BLOB di dati

Android, tramite BlobStoreManager, consente alle app di contribuire al sistema con BLOB di dati da condividere con un insieme selezionato di app.

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

• [C-1-1] NON DEVE condividere i BLOB di dati appartenenti ad app oltre ciò che intendeva consentire (ad es. l'ambito dell'accesso predefinito e le altre modalità di accesso che possono essere specificate utilizzando BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() o BlobStore.session#allowPublicAccess() L'implementazione del riferimento AOSP soddisfa questi requisiti.
• [C-1-2] NON DEVE inviare al di fuori del dispositivo o condividere con altre app gli hash sicuri dei BLOB di dati (utilizzati per controllare l'accesso).

9.8.12. Riconoscimento della musica

Android, tramite l'API di sistema MusicRecognitionManager, supporta un meccanismo che consente alle implementazioni dei dispositivi di richiedere il riconoscimento musicale, con un record audio, e di delegare il riconoscimento musicale a un'app con privilegi che implementa l'API MusicRecognitionService.

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

• [C-1-1] DEVE imporre che il chiamante di MusicRecognitionManager disponga dell'autorizzazione MANAGE_MUSIC_RECOGNITION
• [C-1-2] DEVE imporre l'implementazione di MusicRecognitionService da parte di un'unica applicazione di riconoscimento musicale preinstallata.
• [C-1-3] NON DEVE consentire agli utenti di sostituire MusicRecognitionManagerService o MusicRecognitionService con un'applicazione o un servizio installabili dall'utente.
• [C-1-4] DEVE garantire che quando MusicRecognitionManagerService accede al record audio e lo inoltra all'applicazione che implementa MusicRecognitionService, l'accesso all'audio venga monitorato tramite le chiamate di AppOpsManager.noteOp / startOp.

Se le implementazioni dei dispositivi di MusicRecognitionManagerService o MusicRecognitionService memorizzano i dati audio acquisiti, questi:

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

9.8.13. SensorPrivacyManager

Se le implementazioni del dispositivo forniscono all'utente un'autorizzazione software per disattivare l'ingresso della fotocamera e/o del microfono per l'implementazione del dispositivo, questi:

• [C-1-1] DEVE restituire con precisione "true" per il metodo API supportsSensorToggle() pertinente.
• [C-1-2] DEVE, quando un'app tenta di accedere a un microfono o una fotocamera bloccati, presenta all'utente un'invito utente non ignorabile che indichi chiaramente che il sensore è bloccato e richiede la scelta di continuare con il blocco o lo sblocco in base all'implementazione AOSP che soddisfa questo requisito.
• [C-1-3] DEVE passare soltanto dati vuoti (o falsi) della fotocamera e dell'audio alle app e non segnalare un codice di errore dovuto al fatto che l'utente non ha attivato la fotocamera o il microfono tramite l'invito dell'utente presentato in [C-1-2] di cui sopra.

Crea nuovi requisiti

9.8.14. Gestore delle credenziali

Rimosso.

9.8.15. Implementazioni di API con sandbox

Android, tramite una serie di API di delega, fornisce un meccanismo per elaborare dati ambientali e sicuri a livello di sistema operativo. Tale elaborazione può essere delegata a un APK preinstallato con accesso privilegiato e capacità di comunicazione ridotte, nota come implementazione delle API con sandbox.

Qualsiasi implementazione di API con sandbox:

• [C-0-1] NON DEVE richiedere l'autorizzazione per INTERNET.
• [C-0-2] DEVE accedere a internet solo tramite API strutturate supportate da implementazioni open source disponibili pubblicamente che utilizzano meccanismi che tutelano la privacy o indirettamente tramite API SDK per Android. Il meccanismo che tutela la privacy è definito come "quelli che consentono solo l'analisi in forma aggregata e impediscono la corrispondenza di eventi registrati o risultati derivati per i singoli utenti", per impedire che qualsiasi dato per utente sia introspezionabile (ad es. implementato utilizzando una tecnologia di privacy differenziale come RAPPOR).
• [C-0-3] DEVE mantenere i servizi separati dagli altri componenti di sistema (ad es. non associare il servizio o gli ID processo di condivisione), ad eccezione dei seguenti elementi:
  • Telefonia, contatti, UI di sistema e contenuti multimediali
• [C-0-4] NON DEVE consentire agli utenti di sostituire i servizi con un'applicazione o un servizio installabile dall'utente
• [C-0-5] DEVE consentire solo ai servizi preinstallati di acquisire questi dati. A meno che la funzionalità di sostituzione non sia integrata in AOSP (ad esempio per le app per l'assistente digitale).
• [C-0-6] NON DEVE consentire ad app diverse dal meccanismo dei servizi preinstallati di acquisire questi dati. A meno che tale funzionalità di acquisizione non sia implementata con un'API SDK Android.
• [C-0-7] DEVE fornire l'autorizzazione all'utente per disabilitare i servizi.
• [C-0-8] NON DEVE omettere l'autorizzazione dell'utente per gestire le autorizzazioni Android di cui sono in possesso i servizi e seguire il modello di autorizzazioni Android descritto nella Sezione 9.1. Autorizzazione.

9.8.16. Dati audio e della videocamera continui

In aggiunta ai requisiti descritti nelle sezioni 9.8.2 Registrazione, 9.8.6 Dati ambientali e a livello di sistema operativo e 9.8.15 Implementazioni API con sandbox, implementazioni che utilizzano dati audio ottenuti in background (continua) tramite AudioRecord, SoundTrigger o altre API Audio O dati della videocamera ottenuti in background (continua) tramite CameraManager o altre API Camera:

• [C-0-1] DEVE applicare un indicatore corrispondente (videocamera e/o microfono come indicato nella sezione 9.8.2 Registrazione), a meno che:
  • Questo accesso viene eseguito in un'implementazione con sandbox (vedi Implementazione dell'API Sandboxed 9.8.15), tramite un pacchetto che contiene uno o più dei seguenti ruoli: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, o System Visual Intelligence.
  • L'accesso viene eseguito tramite una sandbox, implementato e applicato tramite meccanismi in AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).
  • L'accesso all'audio viene eseguito per scopi di assistenza dall'applicazione dell'Assistente digitale, fornendo SOURCE_HOTWORD come sorgente audio.
  • L'accesso viene eseguito dal sistema e implementato con codice open source.
• [C-SR-1] CONSIGLIamo VIVAMENTE di richiedere il consenso dell'utente per ogni funzionalità che utilizza questi dati e di essere disabilitato per impostazione predefinita.
• [C-SR-2] VIVAMENTE CONSIGLIATO di applicare lo stesso trattamento (ovvero seguire le limitazioni descritte nei punti 9.8.2 Registrazione, 9.8.6 Dati ambientali e a livello di sistema operativo, 9.8.15 Implementazioni dell'API Sandboxed e 9.8.16 Dati continui relativi ad audio e fotocamera) ai dati della videocamera provenienti da un dispositivo indossabile remoto.

Se i dati della Fotocamera vengono forniti da un dispositivo indossabile remoto e vi si accede in un formato non criptato al di fuori del sistema operativo Android, di un'implementazione con sandbox o di una funzionalità con sandbox creata da WearableSensingManager, questi:

• [C-1-1] DEVE indicare al dispositivo indossabile remoto per visualizzare un indicatore aggiuntivo.

Se i dispositivi offrono la possibilità di interagire con un'applicazione assistente digitale senza la parola chiave assegnata (gestione di query generiche dell'utente o analisi della presenza dell'utente tramite la videocamera):

• [C-2-1] DEVE garantire che questa implementazione sia fornita da un pacchetto con il ruolo android.app.role.ASSISTANT.
• [C-2-2] DEVE garantire che tale implementazione utilizzi le API Android HotwordDetectionService e/o VisualQueryDetectionService.

9.8.17. Telemetry

Android memorizza i log di sistema e delle app utilizzando le API StatisticheLog. Questi log sono gestiti tramite le API StatisticheManager che possono essere utilizzate da applicazioni di sistema con privilegi.

StatisticheManager offre anche un modo per raccogliere dati classificati come sensibili alla privacy dai dispositivi con un meccanismo di tutela della privacy. In particolare, l'API StatsManager::query offre la possibilità di eseguire query su categorie di metriche limitate definite in StatisticheLog.

Qualsiasi query di implementazione e raccolta di metriche limitate da StatsManager:

• [C-0-1] DEVE essere l'unica applicazione/implementazione sul dispositivo e disporre dell'autorizzazione READ_RESTRICTED_STATS.
• [C-0-2] DEVE inviare i dati di telemetria e il log del dispositivo soltanto utilizzando un meccanismo che tutela la privacy. Il meccanismo di tutela della privacy è definito come "quelli che consentono solo l'analisi in forma aggregata e impediscono la corrispondenza di eventi registrati o risultati derivati per i singoli utenti", per evitare che qualsiasi dato per utente sia introspezionabile (ad es. implementato utilizzando una tecnologia di privacy differenziale come RAPPOR).
• [C-0-3] NON DEVE associare questi dati a identità utente (ad esempio Account) sul dispositivo.
• [C-0-4] NON DEVE condividere questi dati con altri componenti del sistema operativo che non rispettano i requisiti descritti nella sezione corrente (9.8.17 Telemetria incentrata sulla tutela della privacy).
• [C-0-5] DEVE fornire un'invito all'utente per attivare/disattivare la raccolta, l'uso e la condivisione della telemetria che tutela la privacy.
• [C-0-6] DEVE fornire all'utente il permesso di cancellare i dati raccolti dall'implementazione se i dati sono memorizzati in qualsiasi forma sul dispositivo. Se l'utente ha scelto di cancellare i dati, DEVE rimuovere tutti i dati attualmente memorizzati sul dispositivo.
• [C-0-7] DEVE comunicare l'implementazione di base di un protocollo per la tutela della privacy in un repository open source.
• [C-0-8 ]DEVE applicare i criteri di traffico in uscita dei dati in questa sezione per limitare la raccolta dei dati nelle categorie di metriche limitate definite in StatisticheLog.

Termina nuovi requisiti

9,9 Crittografia archiviazione dati

Tutti i dispositivi DEVONO soddisfare i requisiti della sezione 9.9.1. I dispositivi che sono stati lanciati a 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 in cui è stato lanciato il dispositivo.

9.9.1. Avvio diretto

Implementazioni dei dispositivi:

• [C-0-1] DEVONO implementare le API in modalità di avvio diretto anche se non supportano Storage Encryption.

• [C-0-2] Gli intent ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED DEVONO comunque essere trasmessi per segnalare alle applicazioni sensibili all'avvio diretto che le posizioni di archiviazione con crittografia DE (dispositivo) e con crittografia CE (credenziali per l'utente) 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), nonché la partizione dello spazio di archiviazione condiviso dell'applicazione (partizione /sdcard), se si tratta di una parte permanente e non rimovibile del dispositivo.
• [C-0-2] DEVE attivare la crittografia dello spazio di archiviazione dati per impostazione predefinita al momento in cui l'utente ha completato l'esperienza di configurazione pronta all'uso.

• [C-0-3] DEVE soddisfare il requisito di crittografia dell'archiviazione dei dati di cui 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.

Nota: le implementazioni dei dispositivi che sono state fornite con livello API 28 o precedente e che non soddisfano i requisiti della sezione 9.9.2 tramite un aggiornamento software di sistema DEVONO soddisfare i requisiti della sezione 9.9 del documento Android Compatibility Definition corrispondente al livello API in cui è stato spedito il dispositivo.

9.9.3. Metodi di crittografia

Se le implementazioni dei dispositivi sono criptate, queste:

• [C-1-1] DEVE avviarsi senza richiedere le credenziali all'utente e consentire alle app sensibili all'avvio diretto di accedere allo spazio di archiviazione con crittografia dei dispositivi (DE) dopo la trasmissione del messaggio ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] DEVE consentire l'accesso allo spazio di archiviazione con crittografia CE (Credential Encrypted) solo dopo che l'utente ha sbloccato il dispositivo fornendo le proprie credenziali (ad esempio passcode, PIN, sequenza o impronta) e dopo la trasmissione del messaggio ACTION_USER_UNLOCKED.
• [C-1-13] NON DEVE offrire alcun metodo per sbloccare lo spazio di archiviazione protetto da CE senza le credenziali fornite dall'utente, una chiave di deposito registrata o un ripristino dell'implementazione del riavvio che soddisfi i requisiti della sezione 9.9.4.
• [C-1-4] DEVE utilizzare l'Avvio verificato.

9.9.3.1. Crittografia basata su file con crittografia dei metadati

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

• [C-1-5] DEVE criptare i contenuti e i metadati del file system utilizzando AES-256-XTS o Adiantum. AES-256-XTS fa riferimento all'Advanced Encryption Standard con lunghezza della chiave di crittografia a 256 bit, gestita in modalità XTS. L'intera lunghezza 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 quali dimensioni, proprietà, modalità e attributi estesi (xattrs) 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 ARMv8 Cryptography Extensions su dispositivi basati su ARM o AES-NI su dispositivi basati su x86, DEVONO essere utilizzate le opzioni basate su AES riportate sopra per il nome, i contenuti e la crittografia dei metadati del file system, non Adiantum.
• [C-1-13] DEVE utilizzare una funzione di derivazione delle chiavi crittograficamente potente e non reversibile (ad es. HKDF-SHA512) per ricavare eventuali sottochiavi necessarie (ad es. chiavi per file) dalle chiavi CE e DE. "Crittograficamente forte e non reversibile" significa che la funzione di derivazione della chiave ha una sicurezza di almeno 256 bit e si comporta come una famiglia di funzioni pseudocasuali sui suoi input.
• [C-1-14] NON DEVE utilizzare le stesse chiavi o sottochiavi di crittografia basata su file (FBE) per scopi crittografici diversi (ad es. sia per la crittografia che per la derivazione delle chiavi o per due algoritmi di crittografia diversi).
• [C-1-15] DEVE garantire che tutti i blocchi non eliminati dei contenuti dei file criptati nell'archiviazione permanente siano stati criptati utilizzando combinazioni di chiave di crittografia e vettore di inizializzazione (IV) che dipendono sia dal file che 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 di 32 bit IV.
• [C-1-16] DEVE garantire che tutti i nomi file criptati non eliminati nell'archiviazione permanente in directory distinte siano stati criptati utilizzando combinazioni distinte di chiave di crittografia e vettore di inizializzazione (IV).

• [C-1-17] DEVE garantire che tutti i blocchi di metadati del file system crittografati nell'archiviazione permanente siano stati criptati utilizzando combinazioni distinte di chiave di crittografia e vettore di inizializzazione (IV).

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

  • [C-1-7] DEVE essere crittograficamente associato a un archivio chiavi supportato da hardware. Questo archivio chiavi DEVE essere associato ad Avvio verificato e alla radice di attendibilità hardware del dispositivo.
  • [C-1-8] Le chiavi CE DEVONO essere associate alle credenziali della schermata di blocco di un utente.
  • [C-1-9] Le chiavi CE DEVONO essere associate a 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 corrisponde a quella di qualsiasi altro utente.
  • [C-1-11] DEVE utilizzare le modalità, la lunghezza e la lunghezza delle chiavi obbligatoriamente supportate.
  • [C-1-12] DEVE essere resettato in modo sicuro durante lo sblocco e il blocco del bootloader, come descritto qui.

• DEVONO rendere disponibili app essenziali preinstallate (ad es. Sveglia, Telefono, Messenger) Avvio diretto.

Il progetto open source Android upstream fornisce un'implementazione preferita della crittografia basata su file basata sulla funzionalità di crittografia "fscrypt" del kernel Linux e della crittografia dei metadati basata sulla funzionalità "dm-default-key" del kernel Linux.

Nota: le implementazioni dei dispositivi fornite con livello API 28 o precedente e che non soddisfano i requisiti della sezione 9.9.3 tramite un aggiornamento del software di sistema DEVONO soddisfare i requisiti della sezione 9.9 del Documento di definizione della compatibilità Android corrispondenti al livello API a cui è stato spedito il dispositivo.

9.9.3.2. Crittografia a livello di blocco per utente

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

• [C-1-1] DEVE abilitare il supporto multiutente come descritto nella sezione 9.5.
• [C-1-2] DEVE fornire partizioni per utente, utilizzando partizioni non elaborate o volumi logici.
• [C-1-3] DEVE utilizzare chiavi di crittografia univoche e distinte per utente per la crittografia dei dispositivi a blocchi sottostanti.

• [C-1-4] DEVE utilizzare AES-256-XTS per la crittografia a livello di blocco delle partizioni degli utenti.

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

  • [C-1-5] DEVE essere crittograficamente associato a un archivio chiavi supportato da hardware. Questo archivio chiavi DEVE essere associato ad Avvio verificato e alla radice di attendibilità 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 dei singoli utenti.

9.9.4. Riprendi al riavvio

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

L'implementazione della funzione Riprendi al riavvio deve continuare per garantire che, quando un dispositivo cade nelle mani di un utente malintenzionato, sia estremamente difficile per l'utente malintenzionato recuperare i dati criptati con CE dell'utente, anche se il dispositivo è acceso, lo spazio di archiviazione CE è sbloccato e l'utente lo ha sbloccato dopo aver ricevuto un'OTA. Per la resistenza agli attacchi interni, supponiamo inoltre che l'utente malintenzionato ottenga l'accesso per trasmettere le chiavi di firma di crittografia.

Nello specifico:

• [C-0-1] L'archiviazione CE NON DEVE essere leggibile anche per l'utente malintenzionato che possiede fisicamente il dispositivo e quindi presenta queste capacità e limitazioni:

  • Puoi utilizzare la chiave di firma di qualsiasi fornitore o azienda per firmare messaggi arbitrari.
  • Può causare la ricezione di una OTA da parte del dispositivo.
  • Può modificare il funzionamento di qualsiasi hardware (AP, Flash ecc.), ad eccezione di quanto descritto di seguito, ma tale modifica comporta un ritardo di almeno un'ora e un ciclo di spegnimento e riaccensione che distrugge i contenuti della RAM.
  • Impossibile modificare il funzionamento dell'hardware antimanomissione (ad es. Titan M).
  • Impossibile leggere la RAM del dispositivo in uso.
  • Non possono ottenere la credenziale dell'utente (PIN, sequenza, password) o altrimenti causare l'inserimento della credenziale.

Ad esempio, un'implementazione del dispositivo che implementa e rispetta tutte le descrizioni riportate qui sarà conforme a [C-0-1].

9.10. Integrità del dispositivo

I seguenti requisiti garantiscono la trasparenza sullo stato di integrità del dispositivo. Implementazioni dei dispositivi:

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

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

Se le implementazioni dei dispositivi sono già state lanciate senza supportare l'Avvio verificato su una versione precedente di Android e non è possibile aggiungere supporto per questa funzionalità con un aggiornamento software di sistema, POTREBBE essere esenti da questo requisito.

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

• [C-1-1] DEVE dichiarare il flag della funzionalità della piattaforma android.software.verified_boot.
• [C-1-2] DEVE eseguire la verifica a ogni sequenza di avvio.
• [C-1-3] DEVE avviare la verifica da una chiave hardware immutabile che è la radice di attendibilità e arrivare fino alla partizione di sistema.
• [C-1-4] DEVE implementare ogni fase di verifica per controllare l'integrità e l'autenticità di tutti i byte nella fase successiva prima di eseguire il codice nella fase successiva.
• [C-1-5] DEVE utilizzare algoritmi di verifica efficaci quanto gli attuali consigli del NIST per gli algoritmi di hashing (SHA-256) e le dimensioni delle chiavi pubbliche (RSA-2048).
• [C-1-6] NON DEVE consentire il completamento dell'avvio quando la verifica del sistema non va a buon fine, a meno che l'utente non acconsenta a tentare comunque l'avvio, nel qual caso non DEVONO essere utilizzati i dati di qualsiasi blocco di archiviazione non verificato.
• [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 nel dispositivo sono presenti più chip discreti (ad es. radio, processore di immagini specializzato), al processo di avvio di ognuno di questi chip è VIVAMENTE CONSIGLIATO di verificare ogni fase al momento dell'avvio.
• [C-1-8] DEVE utilizzare uno spazio di archiviazione che evidenzia le manomissioni, per memorizzare se il bootloader è sbloccato. Lo spazio di archiviazione a prova di manomissione significa che il bootloader può rilevare se lo spazio di archiviazione è stato manomesso dall'interno di Android.
• [C-1-9] DEVE chiedere all'utente di usare il dispositivo e richiedere una conferma fisica prima di consentire una transizione dalla modalità di blocco del bootloader alla modalità di sblocco del bootloader.
• [C-1-10] DEVE implementare la protezione rollback per le partizioni utilizzate da Android (ad esempio, avvio, partizioni di sistema) e utilizzare un'archiviazione che evidenzia le manomissioni per l'archiviazione dei metadati utilizzati per determinare la versione minima consentita del sistema operativo.
• [C-1-11] DEVE cancellare in modo sicuro tutti i dati utente durante lo sblocco e il blocco del bootloader, come da "9.12. "Data Deletion" (Eliminazione dei dati, inclusa la partizione dei dati utente e gli eventuali spazi NVRAM).
• [C-SR-2] È VIVAMENTE CONSIGLIATO di verificare tutti i file APK delle app con privilegi con una catena di attendibilità radicata in partizioni protette da Avvio verificato.
• [C-SR-3] È VIVAMENTE CONSIGLIATO di verificare eventuali artefatti eseguibili caricati da un'app con privilegi al di fuori del suo file APK (come codice caricato dinamicamente o codice compilato) prima di eseguirle o VIVAMENTE CONSIGLIATO di non eseguirli affatto.
• DOVREBBE implementare la protezione rollback per qualsiasi componente con firmware permanente (ad esempio, modem, fotocamera) e DEVONO utilizzare l'archiviazione che evidenzia le manomissioni per l'archiviazione dei metadati utilizzati per determinare la versione minima consentita.

Se le implementazioni dei dispositivi sono già state lanciate senza il supporto da C-1-8 a C-1-11 su una versione precedente di Android e non è possibile aggiungere il supporto per questi requisiti con un aggiornamento software di sistema, questi POSSONO essere esenti dai requisiti.

Il progetto open source Android upstream fornisce un'implementazione preferita di questa funzionalità nel repository external/avb/, che può essere integrata nel bootloader utilizzato per caricare Android.

Implementazioni sui dispositivi

Se le implementazioni dei dispositivi sono in grado di verificare i contenuti dei file per singola pagina,:

• [C-0-3 C-2-1] supporta la verifica crittografica del contenuto del file con una chiave attendibile senza leggere l'intero file.

• [C-0-4 C-2-2] NON DEVE consentire la riuscita delle richieste di lettura su un file protetto quando i contenuti di lettura non vengono verificati in base a una chiave attendibile non viene verificato in base a [C-2-1] di cui sopra.

Crea nuovi requisiti

• [C-2-4] DEVE restituire il checksum del file in O(1) per i file abilitati.

Termina nuovi requisiti

Se le implementazioni dei dispositivi sono già state lanciate senza la possibilità di verificare il contenuto dei file con una chiave attendibile in una versione precedente di Android e non è possibile aggiungere il supporto di questa funzionalità con un aggiornamento del software di sistema, i dispositivi POSSONO essere esentati dal requisito. Il progetto open source Android upstream offre un'implementazione preferita di questa funzionalità basata sulla funzionalità fs-verity del kernel Linux.

Implementazioni dei dispositivi:

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

Se le implementazioni del dispositivo supportano l'API Android Protected Confirmation, l'implementazione:

• [C-3-1] DEVE 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 di altro tipo, non possa generare una risposta positiva senza interazione da parte dell'utente.

• [C-3-3] DEVE garantire che l'utente sia riuscito a rivedere e approvare il messaggio richiesto 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 container e di utilizzarle in operazioni di crittografia tramite l'API KeyChain o l'API Keystore. Implementazioni dei dispositivi:

• [C-0-1] DEVE consentire almeno 8.192 chiavi da importare o generare.
• [C-0-2] L'autenticazione della schermata di blocco DEVE implementare un intervallo di tempo tra i tentativi non riusciti. Con n come conteggio dei tentativi non riusciti, l'intervallo di tempo DEVE essere di almeno 30 secondi per un valore di 9 < n < 30. Per n > 29, il valore dell'intervallo di tempo DEVE essere di almeno 30*2^floor((n-30)/10)) secondi o di almeno 24 ore, a seconda di quale sia il valore più piccolo.
• Non deve limitare il numero di chiavi che possono essere generate

Crea nuovi requisiti

• [C-0-3] DEVE limitare il numero di tentativi di autenticazione principale non riusciti.
• [C-SR-2] È VIVAMENTE CONSIGLIATO di implementare un limite superiore di 20 tentativi di autenticazione principale non riusciti e, se gli utenti acconsentono e attivano la funzionalità, eseguire un "ripristino dei dati di fabbrica" dopo aver superato il limite di tentativi di autenticazione principale non riusciti.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco in base a un secret noto e utilizzano un nuovo metodo di autenticazione da considerare come modo sicuro per bloccare lo schermo:

• [C-SR-3] È VIVAMENTE CONSIGLIATO che il PIN abbia almeno 6 cifre o, equivalente, un'entropia di 20 bit.
• [C-2-1] Un PIN di lunghezza inferiore a 6 cifre NON DEVE consentire l'inserimento automatico senza interazione dell'utente, per evitare di rivelare la lunghezza del PIN.

Termina nuovi requisiti

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

• [C-1-1] DEVE eseguire il backup dell'implementazione dell'archivio chiavi con un ambiente di esecuzione isolato.
• [C-1-2] DEVE avere implementazioni di RSA, AES, ECDSA, ECDH (se IKeyMintDevice è supportato), 3DES, e algoritmi crittografici HMAC e funzioni di hash della famiglia MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema dell'archivio chiavi Android in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA. L'upstream Android Open Source Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura esaminata da terze parti di un isolamento adeguato basato su hypervisor sono opzioni alternative.
• [C-1-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere archiviate in un modo che consenta solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. L'upstream Android Open Source Project fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
• [C-1-4] DEVE supportare l'attestazione della chiave in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise tra un numero sufficientemente elevato di dispositivi da impedire che vengano utilizzate come identificatori del dispositivo. 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, POTREBBE essere utilizzata una chiave diversa per ogni 100.000 unità.

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

• [C-1-5] DEVE consentire all'utente di scegliere il timeout del sonno per la transizione dallo stato sbloccato allo stato di blocco, con un timeout minimo consentito fino a 15 secondi. I dispositivi automobilistici, che bloccano lo schermo ogni volta che l'unità principale viene spenta o l'utente viene spento, POTREBBERO NON avere la configurazione del timeout della sospensione.
• [C-1-6] DEVE supportare IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice versione 1 o IKeyMintDevice versione 2.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare IKeyMintDevice versione 1.

9.11.1. Schermata di blocco sicura, autenticazione e dispositivi virtuali

L'implementazione di AOSP segue un modello di autenticazione a più livelli in cui un'autenticazione primaria basata su knowledge base può essere supportata da una biometria forte secondaria o da modalità terziarie più deboli.

Implementazioni dei dispositivi:

• [C-SR-1] Ti consigliamo vivamente di impostare solo uno dei seguenti metodi di autenticazione principale:

  • Un PIN numerico
  • Una password alfanumerica

  • Una sequenza di scorrimento su una griglia di 3 x 3 punti esatti

    Tieni presente che in questo documento i metodi di autenticazione descritti in precedenza sono indicati come metodi principali di autenticazione consigliati.

Crea nuovi requisiti

• [C-0-1] DEVE limitare il numero di tentativi di autenticazione principale non riusciti.
• [C-SR-5] È VIVAMENTE CONSIGLIATO di implementare un limite superiore di 20 tentativi di autenticazione principali non riusciti e, se gli utenti acconsentono e attivano la funzionalità, eseguire un "ripristino dei dati di fabbrica" dopo aver superato il limite di tentativi di autenticazione primari non riusciti.

Se le implementazioni del dispositivo impostano un PIN numerico come metodo di autenticazione principale consigliato:

• [C-SR-6] È VIVAMENTE CONSIGLIATO che il PIN abbia almeno 6 cifre o, equivalente, un'entropia di 20 bit.
• [C-SR-7] UN PIN di lunghezza inferiore a 6 cifre è VIVAMENTE CONSIGLIATO DI NON consentire l'inserimento automatico senza interazione dell'utente ed evitare di rivelare la lunghezza del PIN.

Termina nuovi requisiti

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione principali 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 nella sezione Richiedere l'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 in base a un secret noto e utilizzano un nuovo metodo di autenticazione da trattare come un modo sicuro per bloccare lo schermo:

• [C-3-1] L'entropia della lunghezza di input minima consentita DEVE essere maggiore di 10 bit.
• [C-3-2] L'entropia massima di tutti gli input possibili DEVE essere maggiore di 18 bit.
• [C-3-3] Il nuovo metodo di autenticazione NON DEVE sostituire nessuno dei metodi di autenticazione principali consigliati (ovvero PIN, pattern, password) implementati e forniti in AOSP.
• [C-3-4] Il nuovo metodo di autenticazione DEVE essere disattivato se l'applicazione Device Policy Controller (DPC) ha impostato il criterio dei requisiti per le 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_METRICAKIO.
• [C-3-5] I nuovi metodi di autenticazione DEVONO fare riferimento ai metodi di autenticazione principali consigliati (ovvero PIN, pattern, password) una volta ogni 72 ore o meno OPPURE comunicare chiaramente all'utente che non verrà eseguito il backup di alcuni dati per preservare la privacy dei suoi dati.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione principali 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 Comodità).
• [C-4-2] DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali consigliati, basato su un secret noto.
• [C-4-3] DEVE essere disattivato e consentire solo l'autenticazione primaria consigliata per sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio per la funzionalità di blocco della chiave chiamando il metodo DevicePolicyManager.setKeyguardDisabledFeatures(), con uno qualsiasi dei flag biometrici associati (ad es. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE o KEYGUARD_DISABLE_IRIS).

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

• [C-5-1] I metodi DEVONO essere disabilitati se l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità dei requisiti per le password tramite DevicePolicyManager.setRequiredPasswordComplexity() con un bucket di complessità più restrittivo di PASSWORD_COMPLEXITY_LOW o utilizzando il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva rispetto a PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] L'utente DEVE essere richiesto all'utente di richiedere 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 trattati 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 è basato su un token fisico o sulla posizione:

• [C-6-1] DEVONO avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali consigliati, basato su un secret noto e soddisfare i requisiti per essere trattati come una schermata di blocco sicura.
• [C-6-2] Il nuovo metodo DEVE essere disattivato e consentire solo a uno dei metodi di autenticazione principali consigliati di sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio con una delle seguenti opzioni:
  • 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] L'utente DEVE richiedere uno dei metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) almeno una volta ogni 4 ore o meno. Quando un token fisico soddisfa i requisiti per le implementazioni di TrustAgent in C-X, vengono applicate le limitazioni di timeout definite in C-9-5.
• [C-6-4] Il nuovo metodo NON DEVE essere considerato come una schermata di blocco sicura e DEVE seguire i vincoli elencati in C-8 di seguito.

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

• [C-7-1] DEVE avere un'indicazione chiara nel menu Impostazioni e nella schermata di blocco quando il blocco del dispositivo viene posticipato o può essere sbloccato da agenti di attendibilità. Ad esempio, AOSP soddisfa questo requisito mostrando una descrizione di testo per le impostazioni "Blocca automaticamente" e "Blocca immediatamente il tasto di accensione" nel menu Impostazioni e un'icona distinguibile nella schermata di blocco.
• [C-7-2] DEVE rispettare e implementare completamente tutte le API dell'agente di attendibilità nella classe DevicePolicyManager, come la costante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NON DEVE implementare completamente la funzione TrustAgentService.addEscrowToken() su un dispositivo utilizzato come dispositivo personale principale (ad esempio, un dispositivo portatile), ma POTREBBE implementarla completamente nelle implementazioni dei dispositivi che vengono tipicamente condivise (ad esempio Android Television o un dispositivo Automotive).
• [C-7-4] DEVE criptare tutti i token archiviati aggiunti da TrustAgentService.addEscrowToken().
• [C-7-5] NON DEVE archiviare la chiave di crittografia o il token di deposito a garanzia sullo stesso dispositivo in cui viene utilizzata la chiave. Ad esempio, una chiave memorizzata su uno smartphone può sbloccare un account utente su una TV. Per i dispositivi Auto e motori, non è consentito archiviare il token di garanzia in nessuna parte del veicolo.
• [C-7-6] DEVE informare l'utente delle implicazioni per la sicurezza prima di abilitare il token del deposito a garanzia per decriptare l'archiviazione dei dati.
• [C-7-7] DEVE disporre di un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali consigliati.
• [C-7-8] L'utente DEVE essere sottoposto a una richiesta di verifica di uno dei metodi di autenticazione principale consigliati (ad es.PIN, sequenza, password) almeno una volta ogni 72 ore o meno, a meno che la sicurezza dell'utente (ad es. la distrazione del conducente) non sia preoccupante.
• [C-7-9] L'utente DEVE essere sottoposto a una richiesta di verifica di uno dei metodi di autenticazione principali consigliati (ad es.PIN, sequenza, password) come descritto in [C-1-7] e [C-1-8] nella sezione 7.3.10, a meno che la sicurezza dell'utente (ad es. la distrazione del conducente) non sia preoccupante.
• [C-7-10] NON DEVE essere considerato come una schermata di blocco sicura e DEVE seguire i vincoli elencati in C-8 di seguito.
• [C-7-11] NON DEVE consentire a TrustAgent sui dispositivi personali principali (ad esempio i dispositivi portatili) di sbloccare il dispositivo e può utilizzarli solo per mantenere un dispositivo già sbloccato in stato sbloccato per un massimo di quattro ore al massimo. L'implementazione predefinita di TrustManagerService in AOSP soddisfa questo requisito.
• [C-7-12] DEVE utilizzare un canale di comunicazione crittograficamente sicuro (ad es.UKEY2) per passare il token di garanzia dal dispositivo di archiviazione al dispositivo di destinazione.

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

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

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

• [C-10-1] DEVE supportare stati di blocco separati per ogni dispositivo virtuale
• [C-10-2] DEVE disconnettere tutti i dispositivi virtuali in caso di timeout per 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'autorizzazione dell'utente per il blocco richiesta per i dispositivi portatili (consulta la Sezione 2.2.5[9.11/H-1-2])
• [C-10-5] DEVE avere istanze di dispositivi virtuali separate per utente
• [C-10-6] DEVE disabilitare la creazione degli eventi di input associati tramite VirtualDeviceManager quando indicato da DevicePolicyManager.setNearbyAppStreamingPolicy
• [C-10-7] DEVE utilizzare appunti separati unicamente per ogni dispositivo virtuale (o disattivare gli appunti per i dispositivi virtuali)
• [C-10-11] DEVE disabilitare l'interfaccia utente di autenticazione sui dispositivi virtuali, tra cui l'immissione del fattore di conoscenza e la richiesta biometrica
• [C-10-12] DEVONO limitare gli intent avviati da un dispositivo virtuale affinché vengano visualizzati solo sullo stesso dispositivo
• [C-10-13] Non DEVE utilizzare uno stato di blocco dispositivo virtuale come autorizzazione dell'autenticazione utente con il sistema Android Keystore. Consulta KeyGenParameterSpec.Builder.setUserAuthentication*.

Quando le implementazioni del dispositivo 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, l'utente:

• [C-11-1] DEVE criptare il fattore di conoscenza con garanzie di protezione simili a quelle descritte nel white paper sulla sicurezza di Google Cloud Key Vault Service quando si trasferisce il fattore di conoscenza dal dispositivo di origine a quello di destinazione, in modo che il fattore di conoscenza non possa essere decriptato o utilizzato da remoto per sbloccare nessuno dei due dispositivi.
• [C-11-2] DEVE, sul dispositivo di origine , chiedere all'utente di confermare il fattore di conoscenza del dispositivo di origine prima di trasferire il fattore di conoscenza al dispositivo di destinazione.
• [C-11-3] DEVE, su un dispositivo di destinazione privo di un knowledge-factor di autenticazione primario impostato, chiedere all'utente di confermare un fattore di conoscenza trasferito sul dispositivo di destinazione prima di impostare tale fattore di conoscenza come fattore di conoscenza principale dell'autenticazione 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 soltanto se è collegato a un dispositivo fisico vicino con una schermata di blocco separata e quando l'utente ha autenticato la propria identità in quella schermata di blocco. I dispositivi proxy possono utilizzare meccanismi di rilevamento sul polso o sul corpo dopo lo sblocco da parte 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 premendo un pulsante o con il timeout del display) e TrustAgent non ha revocato l'attendibilità. L'AOSP soddisfa questo requisito.
• [C-12-3] DEVE spostare il dispositivo dallo stato TrustState.TRUSTABLE allo stato TrustState.TRUSTED solo se il TrustAgent sta ancora concedendo l'attendibilità in base ai requisiti in C-12-1.
• [C-12-4] DEVE chiamare TrustManagerService.revokeTrust() dopo massimo 24 ore dalla concessione dell'attendibilità, dopo un periodo di inattività di 8 ore o quando si perde la connessione sottostante al dispositivo fisico vicino.

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 con VIRTUAL_DISPLAY_FLAG_SECURE, questi:

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

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

• [C-SR-2] È VIVAMENTE CONSIGLIATO di utilizzare le credenziali che soddisfano i requisiti definiti nella sezione 9.11.1 o una riunione biometrica 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] È VIVAMENTE CONSIGLIATO di limitare lo sblocco separato del display tramite un timeout del display definito.
• [C-SR-4] È VIVAMENTE CONSIGLIATO per consentire all'utente di bloccare a livello globale tutti i display tramite il blocco del dispositivo portatile principale.

9.11.2. StrongBox

Il sistema Android Keystore consente agli sviluppatori di app di archiviare le chiavi di crittografia in un processore sicuro dedicato e nell'ambiente di esecuzione isolato descritto sopra. Questo processore sicuro dedicato è chiamato "StrongBox". I requisiti da C-1-3 a C-1-11 riportati di seguito definiscono i requisiti che un dispositivo deve soddisfare per essere idoneo come StrongBox.

Implementazioni del dispositivo dotate di un processore sicuro dedicato:

• [C-SR-1] È VIVAMENTE CONSIGLIATO per il supporto di StrongBox. StrongBox diventerà probabilmente un requisito in una release futura.

Se le implementazioni del dispositivo supportano StrongBox:

• [C-1-1] DEVE dichiarare FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] DEVE fornire hardware sicuro dedicato che venga utilizzato per l'archiviazione delle chiavi e l'autenticazione sicura degli utenti. L'hardware sicuro dedicato potrebbe 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 il punto di accesso non possano alterare in alcun modo l'elaborazione di StrongBox, né ottenere informazioni da StrongBox. L'AP POTREBBE disattivare o bloccare l'accesso a StrongBox.

• [C-1-5] DEVE avere un orologio interno con una ragionevole precisione (+-10%) immune alla manipolazione da parte dell'AP.

• [C-1-6] DEVE avere un vero generatore di numeri casuali che generi un output distribuito uniformemente e imprevedibile.

• [C-1-7] DEVONO essere resistenti alle manomissioni, anche alla penetrazione fisica e agli glitch.

• [C-1-8] DEVE avere una resistenza nei canali laterali, inclusa la resistenza a perdite di informazioni tramite alimentazione, temporizzazione, radiazioni elettromagnetiche e canali laterali a radiazioni termiche.

• [C-1-9] DEVE disporre di un'archiviazione sicura che garantisca riservatezza, integrità, autenticità, coerenza e aggiornamento dei contenuti. Lo spazio di archiviazione NON DEVE essere letto o modificato, tranne nei casi consentiti dalle API StrongBox.

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

  • [C-1-10] DEVE includere l'hardware certificato per il Secure IC Protection Profile BSI-CC-PP-0084-2014 o valutato da un laboratorio di collaudo accreditato a livello nazionale che incorpora la valutazione di vulnerabilità con potenziale di attacco elevato in base alla normativa Common Criteria Application of Attack Potential to Smartcard.
  • [C-1-11] DEVE includere il firmware valutato da un laboratorio di test accreditato a livello nazionale, che incorpora la valutazione della vulnerabilità del potenziale di attacco elevato in base al documento Common Criteria Application of Attack Potential to Smartcards.
  • [C-SR-2] È VIVAMENTE CONSIGLIATO di includere l'hardware valutato utilizzando un obiettivo di sicurezza, il Evaluation Assurance Level (EAL) 5, migliorato da AVA_VAN.5. La certificazione EAL 5 diventerà probabilmente un requisito in una release futura.
  • [C-SR-3] È VIVAMENTE CONSIGLIATO di fornire la resistenza agli attacchi interni (IAR), il che significa che un utente interno con accesso alle chiavi di firma del firmware non può produrre un firmware che causa la divulgazione di segreti per StrongBox, l'elusione dei requisiti di sicurezza funzionali o l'accesso a dati utente sensibili. Il metodo consigliato per implementare IAR è consentire gli aggiornamenti firmware solo quando la password dell'utente principale viene fornita tramite IAuthSecret HAL.

9.11.3. Credenziale identità

Identity Credential System viene definito e ottenuto implementando tutte le API nel pacchetto android.security.identity.*. Queste API consentono agli sviluppatori di app di archiviare e recuperare i documenti di identità utente. Implementazioni dei dispositivi:

• [C-SR-1] è VIVAMENTE CONSIGLIATO di implementare il sistema di credenziali di identità.

Se le implementazioni del dispositivo implementano il sistema delle credenziali di identità, questi:

• [C-1-1] DEVE restituire un valore diverso da null per il metodo IdentityCredentialStore#getInstance().

• [C-1-2] DEVE implementare Identity Credential System (ad esempio 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 su versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA.

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

• [C-1-4] L'applicazione attendibile DEVE essere implementata in modo tale che le sue proprietà di sicurezza non vengano interessate (ad esempio, i dati delle credenziali non vengono rilasciati a meno che non vengano soddisfatte le condizioni di controllo dell'accesso, non è possibile produrre MAC per dati arbitrari) anche se Android presenta un comportamento anomalo o una compromissione.

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

9.12. Eliminazione dei dati

Tutte le implementazioni sui dispositivi:

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

9.13. Modalità di avvio protetto

Android offre la modalità di avvio protetto, che consente agli utenti di avviare una modalità in cui possono essere eseguite solo le app di sistema preinstallate e tutte le app di terze parti sono disattivate. Questa modalità, nota come "modalità di avvio sicuro", offre all'utente la possibilità di disinstallare app di terze parti potenzialmente dannose.

Le implementazioni dei dispositivi sono:

• [C-SR-1] VIVAMENTE CONSIGLIATA di implementare la modalità di avvio protetto.

Se le implementazioni dei dispositivi implementano la modalità di avvio protetto, questi:

• [C-1-1] DEVE fornire all'utente un'opzione per attivare la modalità di avvio protetto in modo che non possa essere interrotto dalle app di terze parti installate sul dispositivo, tranne quando l'app di terze parti è un controller dei criteri dei dispositivi e ha impostato il flag UserManager.DISALLOW_SAFE_BOOT come true.

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

• DOVREBBE fornire all'utente un'opzione per entrare in modalità di avvio protetto dal menu di avvio utilizzando un flusso di lavoro diverso da quello di un normale avvio.

9.14. Isolamento dei sistemi per veicoli automobilistici

I dispositivi Android Automotive dovrebbero scambiare dati con sottosistemi critici dei veicoli utilizzando l'HAL per veicoli per inviare e ricevere messaggi sulle reti di veicoli come il bus CAN.

Lo scambio di dati può essere protetto implementando funzionalità di sicurezza al di sotto dei livelli del framework Android per impedire interazioni dannose o non intenzionali con questi sottosistemi.

9.15. Piani di abbonamento

I "piani di abbonamento" fanno riferimento ai dettagli dei piani di relazione di fatturazione forniti da un operatore di telefonia mobile tramite SubscriptionManager.setSubscriptionPlans().

Tutte le implementazioni sui dispositivi:

• [C-0-1] DEVONO restituire i piani di abbonamento solo all'app dell'operatore di telefonia mobile che li ha originariamente forniti.
• [C-0-2] NON DEVE effettuare il backup o il caricamento dei piani di abbonamento da remoto.
• [C-0-3] DEVE consentire solo gli override, ad esempio SubscriptionManager.setSubscriptionOverrideCongested(), dall'app dell'operatore di telefonia mobile che attualmente fornisce piani di abbonamento validi.

9.16. Migrazione dei dati delle applicazioni

Se le implementazioni dei dispositivi 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 in base a quanto configurato dallo sviluppatore dell'applicazione nel manifest tramite l'attributo android:fullBackupContent, questi:

• [C-1-1] NON DEVE avviare trasferimenti dei dati delle applicazioni da dispositivi su cui l'utente non ha impostato un'autenticazione primaria come descritto in 9.11.1 Schermata di blocco sicura e autenticazione.
• [C-1-2] DEVE confermare in modo sicuro l'autenticazione principale sul dispositivo di origine e confermare con l'intento dell'utente di copiare i dati sul dispositivo di origine prima che vengano trasferiti dati.
• [C-1-3] DEVE utilizzare l'attestazione del token di sicurezza per garantire che sia il dispositivo di origine sia quello di destinazione nella migrazione da dispositivo a dispositivo siano dispositivi Android legittimi e abbiano un bootloader bloccato.
• [C-1-4] DEVE eseguire la migrazione dei dati dell'applicazione solo nella stessa applicazione sul dispositivo di destinazione, con lo stesso nome di pacchetto E lo stesso certificato di firma.
• [C-1-5] DEVE mostrare un'indicazione del fatto che i dati del dispositivo di origine sono stati migrati mediante una migrazione dei dati tra dispositivi nel menu Impostazioni. Un utente NON DEVE essere in grado di rimuovere questa indicazione.

9.17. Framework di virtualizzazione di Android

Se il dispositivo implementa il supporto per le API Android Virtualization Framework (android.system.virtualmachine.*), l'host Android:

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

• [C-1-3] NON DEVE modificare, omettere o sostituire le regole non consentite all'interno del sistema/sepolicy fornito nell'Android Open Source Project (AOSP) upstream e il criterio DEVE essere compilato con tutte le regole non consentite presenti.

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

• [C-1-5] NON DEVE consentire a una macchina virtuale protetta pVM di eseguire codice che non fa parte dell'immagine di fabbrica o dei relativi aggiornamenti. Tutto ciò che non è coperto da Avvio verificato di Android (ad esempio, i file scaricati da internet o installate tramite sideload) NON DEVE essere consentito per l'esecuzione in una macchina virtuale protetta .

Crea nuovi requisiti

• [C-1-5] DEVE consentire solo a una pVM non di cui non è possibile eseguire il debug di eseguire il codice dall'immagine di fabbrica o dagli aggiornamenti della relativa piattaforma, che includono anche eventuali aggiornamenti alle app con privilegi.

Termina nuovi requisiti

Se il dispositivo implementa il supporto per le API Android Virtualization Framework (android.system.virtualmachine.*), qualsiasi istanza Protected Virtual Machine pVM :

• [C-2-1] DEVE essere in grado di eseguire tutti i sistemi operativi disponibili nell'APEX di virtualizzazione in una macchina virtuale protetta .
• [C-2-2] NON DEVE consentire a una macchina virtuale protetta pVM di eseguire un sistema operativo 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 dati come codice (ad es. SELinux non consentire mai execmem).

• [C-2-4] NON DEVE modificare, omettere o sostituire le regole non consentite all'interno del sistema/sepolicy/microdroid fornito nell'Android Open Source Project (AOSP) a monte.

• [C-2-5] DEVE implementare meccanismi di difesa in profondità Protected Virtual Machine pVM (ad es. SELinux per pVM) anche per i sistemi operativi non microdroidi.
• [C-2-6] DEVE garantire che la pVM non riesca che il firmware si rifiuta di avviarsi se non è in grado di verificare le immagini iniziali che la VM non potrà essere eseguita. La verifica DEVE essere eseguita all'interno della VM.
• [C-2-7] DEVE garantire che la pVM non si avvii il firmware si rifiuta se l'integrità dell'istanza.img è compromessa.

Se il dispositivo implementa il supporto per le API Android Virtualization Framework (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 macchina virtuale stessa o all'hypervisor, non da altre macchine virtuali protette o non protette. NON DEVE consentire a nessuna pVM di accedere a una pagina che appartiene a un'altra entità (ossia un'altra pVM o un hypervisor), a meno che non venga condivisa esplicitamente dal proprietario della pagina. Include la VM host. Questo vale sia per gli accessi a CPU che per DMA.
• [C-3-2] DEVE cancellare una pagina dopo che è stata utilizzata da una pVM e prima che venga restituita all'host (ad esempio, la pVM viene eliminata).
• [C-3-3SR-1] È VIVAMENTE CONSIGLIATO per garantire DEVONO garantire che il firmware pVM venga caricato ed eseguito prima di qualsiasi codice in una pVM.
• [C-3-4] DEVE garantire che ogni VM generi un secret per VM che {Boot Certificate Chain (BCC) and Compound Device Identifier (CDI) fornito a un'istanza pVM possa essere ottenuto solo da quella specifica istanza VM e modifiche 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 a una VM una funzionalità che consente di aggirare il Modello di sicurezza Android.

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

• [C-5-1] DEVE essere in grado di supportare le compilazioni isolate ma potrebbe disattivare la funzionalità Compilation isolate nella spedizione sul dispositivo di un aggiornamento del runtime ART.

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

• [C-6-1] DEVE eseguire il rooting della catena DICE in un punto che l'utente non possa modificare, anche sui dispositivi sbloccati. (per garantire che non sia possibile falsificarlo).

• [C-SR-26-2] È CONSIGLIATO VIVAMENTE l'uso di DICE come meccanismo di derivazione dei secret per VM. DICE DEVE funzionare correttamente, 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 è del tutto completo. Per questo motivo, agli utenti che implementano i dispositivi è CONSIGLIATO di apportare il numero minimo di modifiche possibile al riferimento e all'implementazione preferita di Android disponibili nel progetto open source Android. In questo modo ridurrai al minimo il rischio di introdurre bug che creano incompatibilità che richiedono rielaborazione e potenziali aggiornamenti dei dispositivi.

10.1 Suite di test di compatibilità

Implementazioni dei dispositivi:

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

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

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi altro software, il CTS può contenere dei bug. Il CTS verrà sottoposto al controllo delle versioni indipendentemente da questa Definizione di compatibilità e potrebbero essere rilasciate più revisioni per Android 14.

Implementazioni dei dispositivi:

• [C-0-3] DEVE superare l'ultima versione CTS disponibile al momento del completamento del software del dispositivo.

• DEVI usare il più possibile l'implementazione dei riferimenti nell'albero open source di Android.

10.2. Verificatore CTS

CTS Verifier è incluso nella suite di test di compatibilità ed è destinato a essere eseguito da un operatore umano per testare le funzionalità che non possono essere testate da un sistema automatizzato, come il corretto funzionamento di una fotocamera e di sensori.

Implementazioni dei dispositivi:

• [C-0-1] DEVE eseguire correttamente tutti i casi applicabili nello strumento di verifica CTS.

Lo strumento di verifica CTS effettua test per molti tipi di hardware, inclusi alcuni hardware facoltativi.

Implementazioni dei dispositivi:

• [C-0-2] DEVE superare tutti i test relativi all'hardware in suo possesso; ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente lo scenario di test dell'accelerometro nello strumento di verifica CTS.

Gli scenari di test per le funzionalità indicate come facoltative da questo documento di definizione di compatibilità POTREBBERO essere ignorati 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 strumenti di implementazione dei dispositivi eseguano in modo esplicito CTS Verifier su build che differiscono solo per aspetti banali. In particolare, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato lo strumento di verifica CTS solo per l'insieme di impostazioni internazionali, branding e così via inclusi. POSSONO omettere il test di verifica CTS.

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, ossia potrebbe essere necessario riavviare il dispositivo. È possibile utilizzare qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, uno qualsiasi dei seguenti approccio soddisferà questo requisito:

  • Download di "over-the-air (OTA)" con aggiornamento offline tramite riavvio.
  • Aggiornamenti "con tethering" tramite USB da un PC host.
  • Gli aggiornamenti "Offline" vengono riavviati e vengono aggiornati da un file nello spazio di archiviazione rimovibile.

• [C-0-2] Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. Vale a dire che il meccanismo di aggiornamento DEVE conservare i dati privati dell'applicazione e i dati condivisi dalle applicazioni. 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 confrontandoli con una chiave pubblica memorizzata sul dispositivo.

• [C-SR-1] Il meccanismo di firma è VIVAMENTE CONSIGLIATO di eseguire l'hashing dell'aggiornamento con SHA-256 e convalidare l'hash in base alla chiave pubblica utilizzando ECDSA NIST P-256.

Se le implementazioni dei dispositivi includono il supporto per una connessione dati unmetered come 802.11 o un profilo Bluetooth PAN (Personal Area Network), questi:

• [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 binaria identica al risultato previsto a seguito di un'OTA. L'implementazione di OTA basata su blocchi nell'upstream Android Open Source Project, aggiunta a partire da Android 5.1, soddisfa questo requisito.

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

Se viene rilevato un errore in un'implementazione del dispositivo dopo il suo rilascio, ma entro il suo ciclo di vita ragionevole del prodotto, determinato in consultazione con il team per la compatibilità Android per influire sulla compatibilità delle applicazioni di terze parti, procedi come segue:

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

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

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

• Log delle modifiche dei documenti

13. Contattaci

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