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

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

Definizione di compatibilità di Android 11

1. Introduzione

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

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

Ai fini del presente documento, un "implementatore di dispositivi" o "implementatore" è una persona o un'organizzazione che sviluppa una soluzione hardware/software che esegue Android 11. Un'implementazione del dispositivo o "implementazione" è la soluzione hardware/software così sviluppata.

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

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

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

Molte delle risorse a cui viene fatto riferimento in questo documento derivano direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni contenute nella documentazione dell'SDK. Nei casi in cui questa definizione di compatibilità o la suite di test di compatibilità non sono in linea con la documentazione dell'SDK, quest'ultima è considerata autorevole. Tutti i dettagli tecnici forniti nelle risorse collegate in questo documento sono considerati parte di questa Definizione di compatibilità.

1.1 Struttura del documento

1.1.1. Requisiti per tipo di dispositivo

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

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

1.1.2. ID requisito

L'ID requisito viene assegnato per i requisiti MUST.

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

Ogni ID è definito come segue:

ID tipo di dispositivo (vedi di più in 2. Tipi di dispositivi)
- C: Core (requisiti applicati a qualsiasi implementazione di dispositivi Android)
- H: Dispositivo palmare Android
- T: Dispositivo Android Television
- R. Implementazione di Android Automotive
- W: Android Watch implementation
- Scheda: implementazione del tablet Android
ID condizione
- Quando il requisito è incondizionato, questo ID è impostato su 0.
- Quando il requisito è condizionale, viene assegnato il numero 1 alla prima condizione e il numero aumenta di 1 all'interno della stessa sezione e dello stesso tipo di dispositivo.
ID requisito
- Questo ID inizia da 1 e viene incrementato di 1 all'interno della stessa sezione e della stessa condizione.

1.1.3. ID requisito nella sezione 2

L'ID requisito nella Sezione 2 inizia con l'ID sezione corrispondente, seguito dall'ID requisito descritto sopra.

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

2. Tipi di dispositivi

Sebbene l'Android Open Source Project fornisca uno stack software che può essere utilizzato per una varietà di tipi di dispositivi e fattori di forma, esistono alcuni tipi di dispositivi che hanno un ecosistema di distribuzione delle applicazioni relativamente più consolidato.

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

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

2.1 Configurazioni dispositivo

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

2.2. Requisiti per i dispositivi portatili

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

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

Avere una fonte di alimentazione che fornisca mobilità, ad esempio una batteria.
Avere una dimensione diagonale dello schermo fisica compresa tra 3,3 pollici (o 2,5 pollici per i dispositivi lanciati con un livello API precedente ad Android 11) e 8 pollici.

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

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

2.2.1. Hardware

Implementazioni di dispositivi palmari:

[7.1.1.1/H-0-1] DEVE avere almeno un display compatibile con Android che soddisfi tutti i requisiti descritti in questo documento.
[7.1.1.3/H-SR] Sono FORTEMENTE CONSIGLIATE per offrire agli utenti la possibilità di modificare le dimensioni di visualizzazione (densità dello schermo).

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

[7.1.1.1/H-1-1]* DEVE rendere lo schermo logico disponibile per le applicazioni di terze parti di almeno 5 cm sul bordo corto e 6,8 cm sul bordo lungo. I dispositivi lanciati con un livello API precedente a quello di questo documento sono esenti da questo requisito.

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

[7.1.1.1/H-2-1]* DEVE rendere lo schermo logico disponibile per le applicazioni di terze parti di almeno 2,7 pollici sul lato corto. I dispositivi lanciati con un livello API precedente a quello di questo documento sono esenti da questo requisito.

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

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

Implementazioni di dispositivi palmari:

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

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

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

Implementazioni di dispositivi palmari:

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

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

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

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

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

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

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

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

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

Implementazioni di dispositivi palmari:

[7.3.11/H-SR] Sono CONSIGLIATI per supportare il sensore di postura con 6 gradi di libertà.
[7.4.3/H] DEVE includere il supporto per Bluetooth e Bluetooth LE.

Se le implementazioni di dispositivi palmari includono una connessione a consumo:

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

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

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

Implementazioni di dispositivi palmari:

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

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

[7.6.1/H-1-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere almeno 416 MB se il display predefinito utilizza risoluzioni framebuffer fino a qHD (ad es. FWVGA).
[7.6.1/H-2-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 592 MB se il display predefinito utilizza risoluzioni del framebuffer fino a HD+ (ad es. HD, WSVGA).
[7.6.1/H-3-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 896 MB se il display predefinito utilizza risoluzioni framebuffer fino a FHD (ad es. WSXGA+).
[7.6.1/H-4-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1344 MB se il display predefinito utilizza risoluzioni framebuffer fino a QHD (ad es. QWXGA).

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

[7.6.1/H-5-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 816 MB se il display predefinito utilizza risoluzioni framebuffer fino a qHD (ad es. FWVGA).
[7.6.1/H-6-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 944 MB se il display predefinito utilizza risoluzioni del framebuffer fino a HD+ (ad es. HD, WSVGA).
[7.6.1/H-7-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1280 MB se il display predefinito utilizza risoluzioni del framebuffer fino a FHD (ad es. WSXGA+).
[7.6.1/H-8-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1824 MB se il display predefinito utilizza risoluzioni framebuffer fino a QHD (ad es. QWXGA).

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

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

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

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

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

Implementazioni di dispositivi palmari:

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

Se le implementazioni di dispositivi palmari 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 di 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 palmari:

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

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

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

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

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

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

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

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

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

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

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

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

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

Se le implementazioni di dispositivi palmari includono almeno un attuatore aptico:

[7.10/H-SR]* È FORTEMENTE CONSIGLIATO di NON utilizzare un attuatore aptico (vibratore) con massa rotante eccentrica(ERM).
[7.10/H]* DOVREBBE posizionare l'attuatore vicino alla posizione in cui il dispositivo viene in genere tenuto o toccato con le mani.
[7.10/H-SR]* È FORTEMENTE CONSIGLIATO di implementare tutte le costanti pubbliche per il feedback aptico chiaro in android.view.HapticFeedbackConstants, ovvero (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START e GESTURE_END).
[7.10/H-SR]* È FORTEMENTE CONSIGLIATO di implementare tutte le costanti pubbliche per il feedback aptico chiaro in android.os.VibrationEffect, ovvero (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK e EFFECT_DOUBLE_CLICK) e tutte le costanti pubbliche per il feedback aptico avanzato in android.os.VibrationEffect.Composition, ovvero (PRIMITIVE_CLICK e PRIMITIVE_TICK).
[7.10/H-SR]* È FORTEMENTE CONSIGLIATO utilizzare queste mappature di costanti aptiche collegate.
[7.10/H-SR]* È FORTEMENTE CONSIGLIATO di seguire la valutazione della qualità per le API createOneShot() e createWaveform().
[7.10/H-SR]* È VIVAMENTE CONSIGLIATO verificare le funzionalità di scalabilità dell'ampiezza eseguendo android.os.Vibrator.hasAmplitudeControl().

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

Se le implementazioni di dispositivi palmari includono almeno un attuatore risonante lineare:

[7.10/H]* DOVREBBE spostare l'attuatore aptico sull'asse X dell'orientamento verticale.

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

[7.10/H-SR]* È FORTEMENTE CONSIGLIATO che la frequenza di risonanza dell'attuatore LRA dell'asse X sia inferiore a 200 Hz.

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

[7.10/H-SR]* È FORTEMENTE CONSIGLIATO eseguire una valutazione della qualità per le costanti aptiche.

2.2.2. Multimediali

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

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

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

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

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

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

2.2.3. Software

Implementazioni di dispositivi palmari:

[3.2.3.1/H-0-1] DEVE avere un'applicazione che gestisca gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE e ACTION_CREATE_DOCUMENT come descritto nei documenti dell'SDK e fornire all'utente la possibilità di accedere ai dati del provider di documenti utilizzando l'API DocumentsProvider.
[3.2.3.1/H-0-2]* DEVE precaricare uno o più componenti di applicazioni o servizi con un gestore di intent, per tutti i pattern di filtri per intent pubblici definiti dai seguenti intent dell'applicazione elencati qui.
[3.2.3.1/H-SR] È VIVAMENTE CONSIGLIATO di precaricare un'applicazione email in grado di gestire intent ACTION_SENDTO o ACTION_SEND o ACTION_SEND_MULTIPLE per inviare un'email.
[3.4.1/H-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.
[3.4.2/H-0-1] DEVE includere un'applicazione browser autonoma per la navigazione web generale degli utenti.
[3.8.1/H-SR] È VIVAMENTE CONSIGLIATO di implementare un Avvio app predefinito che supporti il blocco in-app di scorciatoie, widget e widgetFeatures.
[3.8.1/H-SR] È VIVAMENTE CONSIGLIATO implementare un launcher predefinito che fornisca un accesso rapido alle scorciatoie aggiuntive fornite da app di terze parti tramite l'API ShortcutManager.
[3.8.1/H-SR] È VIVAMENTE CONSIGLIATO includere un'app di avvio predefinita che mostri i badge per le icone delle app.
[3.8.2/H-SR] Sono FORTEMENTE CONSIGLIATI per supportare i widget di app di terze parti.
[3.8.3/H-0-1] DEVONO consentire alle app di terze parti di notificare agli utenti eventi importanti tramite le classi API Notification e NotificationManager.
[3.8.3/H-0-2] MUST support rich notifications.
[3.8.3/H-0-3] DEVE supportare le notifiche heads-up.
[3.8.3/H-0-4] DEVE includere un'area notifiche, che consenta all'utente di controllare direttamente (ad es. rispondere, posticipare, ignorare, bloccare) le notifiche tramite funzionalità utente come pulsanti di azione o il pannello di controllo implementato in AOSP.
[3.8.3/H-0-5] DEVE mostrare le scelte fornite tramite RemoteInput.Builder setChoices() nell'area notifiche.
[3.8.3/H-SR] È FORTEMENTE CONSIGLIATO di mostrare la prima scelta fornita tramite RemoteInput.Builder setChoices() nell'area notifiche senza ulteriori interazioni utente.
[3.8.3/H-SR] È FORTEMENTE 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] È FORTEMENTE CONSIGLIATO visualizzare le azioni per le quali Notification.Action.Builder.setContextual è impostato come true in linea con le risposte visualizzate da Notification.Remoteinput.Builder.setChoices.
[3.8.4/H-SR] È FORTEMENTE CONSIGLIATO implementare un assistente sul dispositivo per gestire l'azione Assist.

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

[3.8.4/H-SR] È VIVAMENTE CONSIGLIATO di utilizzare la pressione prolungata del tasto HOME come interazione designata per avviare l'app di assistenza, come descritto nella sezione 7.2.3. DEVE avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService o un'attività che gestisce lintent ACTION_ASSIST.

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

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

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

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

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

[3.9/H-1-1] DEVE implementare l'intera gamma di criteri di amministrazione dei dispositivi definiti nella documentazione dell'SDK Android.
[3.9/H-1-2] DEVE dichiarare il supporto dei profili gestiti tramite il flag di funzionalità android.software.managed_users, tranne quando il dispositivo è configurato in modo da segnalarsi come dispositivo con poca RAM o in modo da allocare lo spazio di archiviazione interno (non rimovibile) come spazio di archiviazione condiviso.

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

[3.8.16/H-1-1] DEVE dichiarare il flag funzionalità android.software.controls e impostarlo su true.
[3.8.16/H-1-2] DEVE fornire un'interfaccia utente con la possibilità di aggiungere, modificare, selezionare e utilizzare i controlli dei dispositivi preferiti dell'utente dai controlli registrati dalle applicazioni di terze parti tramite le API ControlsProviderService e Control.
[3.8.16/H-1-3] DEVE fornire l'accesso a questa funzionalità per l'utente entro tre interazioni da un Launcher predefinito.
[3.8.16/H-1-4] DEVE eseguire il rendering accurato in questa funzionalità utente del nome e dell'icona di ogni app di terze parti che fornisce controlli tramite l'API ControlsProviderService, nonché di tutti i campi specificati forniti dalle API Control.

Al contrario, se le implementazioni dei dispositivi palmari 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 funzionalità android.software.controls e impostarlo su false.

Implementazioni di dispositivi palmari:

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

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

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

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

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

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

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

2.2.4. Prestazioni e potenza

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

Implementazioni di dispositivi palmari:

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

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

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

Implementazioni di dispositivi palmari:

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

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

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

2.2.5. Modello di sicurezza

Implementazioni di dispositivi palmari:

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

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

[9.11/H-0-2]* DEVE eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
[9.11/H-0-3]* DEVONO essere implementati gli algoritmi crittografici RSA, AES, ECDSA e HMAC e le funzioni hash MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto open source Android (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti di un isolamento basato su hypervisor adeguato sono opzioni alternative.
[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 memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto Android Open Source Project upstream fornisce l'Hardware Abstraction Layer (HAL) Gatekeeper e Trusty, che possono essere utilizzati per soddisfare questo requisito.
[9.11/H-0-5]* DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori di 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 l'implementazione di un dispositivo è già stata lanciata su una versione precedente di Android, il dispositivo è esente dal requisito di disporre di un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione della chiave, a meno che non dichiari la funzionalità android.hardware.fingerprint, che richiede un keystore supportato da un ambiente di esecuzione isolato.

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

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

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

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

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

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

2.2.6. Compatibilità di strumenti e opzioni per sviluppatori

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

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

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

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

2.2.7 Classe di prestazioni dei contenuti multimediali portatili

Per la definizione di classe di rendimento dei contenuti multimediali, consulta la sezione 7.11.

2.2.7.1. Media

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

[5.1/H-1-1] DEVE pubblicizzare il numero massimo di sessioni di decodifica video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-2] DEVE supportare 6 istanze di sessioni di decodifica video hardware (AVC o HEVC) in qualsiasi combinazione di codec in esecuzione contemporaneamente alla risoluzione 720p a 30 fps.
[5.1/H-1-3] DEVE pubblicizzare il numero massimo di sessioni di codifica video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-4] DEVE supportare 6 istanze di sessioni di codifica video hardware (AVC o HEVC) in qualsiasi combinazione di codec in esecuzione contemporaneamente alla risoluzione 720p a 30 fps.
[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 decodifica video hardware e codifica video hardware (AVC o HEVC) in qualsiasi combinazione di codec in esecuzione contemporaneamente alla risoluzione 720p a 30 fps.
[5.1/H-1-7] DEVE avere una latenza di inizializzazione del codec pari o inferiore a 65 ms per una sessione di codifica video a 1080p o inferiore per tutti i codificatori video hardware (diverso dal codec Dolby Vision) sotto carico. Il carico qui è definito come una sessione di transcodifica simultanea solo video da 1080p a 720p che utilizza codec video hardware insieme all'inizializzazione della registrazione audio-video a 1080p.
[5.1/H-1-8] DEVE avere una latenza di inizializzazione del codec di 50 ms o inferiore per una sessione di codifica audio con bitrate di 128 kbps o inferiore per tutti i codificatori audio quando sotto carico.Il carico qui è definito come una sessione di transcodifica solo video da 1080p a 720p con codec video hardware insieme all'inizializzazione della registrazione audio-video a 1080p.
[5.3/H-1-1] NON DEVE perdere più di 1 frame in 10 secondi (ovvero meno dello 0,333% di perdita di frame) per una sessione video a 1080p e 30 fps sotto carico. Il carico è definito come una sessione di transcodifica simultanea solo video da 1080p a 720p che utilizza codec video hardware, nonché una riproduzione audio AAC a 128 kbps.
[5.3/H-1-2] NON DEVE perdere più di 1 frame in 10 secondi durante una modifica della risoluzione video in una sessione video a 30 fps sotto carico. Il carico è definito come una sessione di transcodifica simultanea solo video da 1080p a 720p che utilizza codec video hardware, nonché una riproduzione audio AAC a 128 Kbps.
[5.6/H-1-1] DEVE avere una latenza tap-to-tone inferiore a 100 millisecondi utilizzando il test tap-to-tone di OboeTester o CTS Verifier.

2.2.7.2. Fotocamera

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

[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 fps. La fotocamera posteriore principale è la fotocamera posteriore con l'ID fotocamera più basso.
[7.5/H-1-2] DEVE avere una fotocamera anteriore principale con una risoluzione di almeno 4 megapixel che supporti l'acquisizione video a 1080p a 30 fps. La fotocamera anteriore principale è quella con l'ID fotocamera più basso.
[7.5/H-1-3] DEVE supportare la proprietà android.info.supportedHardwareLevel come FULL o superiore per la fotocamera principale posteriore e LIMITED o superiore per la fotocamera principale anteriore.
[7.5/H-1-4] DEVE supportare CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME per entrambe le fotocamere principali.
[7.5/H-1-5] DEVE avere una latenza di acquisizione JPEG camera2 < 1000 ms per risoluzione 1080p misurata dal test delle prestazioni della fotocamera CTS in condizioni di illuminazione ITS (3000 K) per entrambe le fotocamere principali.
[7.5/H-1-6] DEVE avere una latenza di avvio di camera2 (apertura della fotocamera al primo frame di anteprima) < 600 ms misurata dal test delle prestazioni della fotocamera CTS in condizioni di illuminazione ITS (3000 K) per entrambe le fotocamere principali.

2.2.7.3. Hardware

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

[7.1.1.1/H-1-1] DEVE avere una risoluzione dello schermo di almeno 1080p.
[7.1.1.3/H-1-1] DEVE avere una densità dello schermo di almeno 400 dpi.
[7.6.1/H-1-1] DEVE avere almeno 6 GB di memoria fisica.

2.2.7.4. Rendimento

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

[8.2/H-1-1] DEVE garantire una velocità di scrittura sequenziale di almeno 100 MB/s.
[8.2/H-1-2] DEVE garantire una velocità di scrittura casuale di almeno 10 MB/s.
[8.2/H-1-3] DEVE garantire una velocità di lettura sequenziale di almeno 200 MB/s.
[8.2/H-1-4] DEVE garantire una velocità di lettura casuale di almeno 25 MB/s.

2.3. Requisiti della TV

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

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

Avere fornito un meccanismo per controllare da remoto l'interfaccia utente visualizzata sul display, che potrebbe trovarsi a tre metri di distanza dall'utente.
Avere uno schermo integrato con una 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 per le implementazioni di dispositivi Android Television.

2.3.1. Hardware

Implementazioni di dispositivi TV:

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

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

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

Implementazioni di dispositivi TV:

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

Se le implementazioni dei dispositivi TV 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 connette tramite questa porta USB, ma non è necessariamente sempre connessa.

Se le implementazioni dei dispositivi TV sono a 32 bit:

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

Se le implementazioni dei dispositivi TV sono a 64 bit:

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

Implementazioni di dispositivi TV:

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

2.3.2. Multimediali

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

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

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

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

Implementazioni di dispositivi TV:

[5.2.2/T-SR] Sono FORTEMENTE CONSIGLIATI per supportare la codifica H.264 dei video con risoluzione 720p e 1080p a 30 fotogrammi al secondo.

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

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

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

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

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

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

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

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

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

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

Le implementazioni dei dispositivi televisivi DEVONO supportare la decodifica VP8, come descritto in dettaglio nella sezione 5.3.6, a frame rate 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 decoder hardware VP9 DEVONO supportare la decodifica VP9, come descritto nella sezione 5.3.7, a frame rate video e risoluzioni standard fino a:

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

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

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

Implementazioni di dispositivi TV:

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

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

[5.8/T-0-1] DEVE impostare la modalità di output HDMI per selezionare la risoluzione massima supportata con una frequenza di aggiornamento di 50 Hz o 60 Hz.
[5.8/T-SR] È VIVAMENTE CONSIGLIATO fornire un selettore della frequenza di aggiornamento HDMI configurabile dall'utente.
[5.8] DEVE impostare la frequenza di aggiornamento della modalità di uscita HDMI su 50 Hz o 60 Hz, a seconda della frequenza di aggiornamento video per la regione in cui viene venduto il dispositivo.

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

[5.8/T-1-1] 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] MUST support HDCP 1.4

2.3.3. Software

Implementazioni di dispositivi TV:

[3/T-0-1] DEVE dichiarare le funzionalità android.software.leanback e android.hardware.type.television.
[3.2.3.1/T-0-1] DEVE precaricare uno o più componenti di applicazioni o servizi con un gestore di intent, per tutti i pattern di filtri per intent pubblici definiti dagli intent dell'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 nella schermata di blocco, incluso il modello di notifica multimediale.

Implementazioni di dispositivi TV:

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

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

[3.11/T-SR] È FORTEMENTE CONSIGLIATO 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 TV:

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

2.3.4. Prestazioni e potenza

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

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

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

Se le implementazioni dei dispositivi televisivi non hanno una batteria:

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

Se le implementazioni dei dispositivi televisivi hanno una batteria:

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

Implementazioni di dispositivi TV:

[8.4/T-0-1] DEVE fornire un profilo di alimentazione per componente che definisca il valore di consumo di corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto Android Open Source.
[8.4/T-0-2] DEVE segnalare tutti i valori di consumo energetico in milliampere ora (mAh).
[8.4/T-0-3] DEVE segnalare il consumo energetico della CPU per ogni UID del processo. L'Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
[8.4/T] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo energetico 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 TV:

[9.11/T-0-1] DEVE eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
[9.11/T-0-2] DEVONO essere implementati gli algoritmi crittografici RSA, AES, ECDSA e HMAC e le funzioni hash MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto open source Android (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti di un isolamento basato su hypervisor adeguato sono opzioni alternative.
[9.11/T-0-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e solo se riuscita, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto Android Open Source Project upstream fornisce l'Hardware Abstraction Layer (HAL) Gatekeeper e Trusty, che possono essere utilizzati per soddisfare questo requisito.
[9.11/T-0-4] DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori di 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à.

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 di sospensione per la transizione dallo stato sbloccato a quello bloccato, con un timeout minimo consentito fino a 15 secondi o meno.

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

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

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

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

2.3.6. Compatibilità di strumenti e opzioni per sviluppatori

Implementazioni di dispositivi TV:

Perfetto
- [6.1/T-0-1] DEVE esporre un binario /system/bin/perfetto all'utente della shell la cui riga di comando è conforme alla documentazione di Perfetto.
- [6.1/T-0-2] Il binario perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
- [6.1/T-0-3] Il binario perfetto DEVE scrivere come output una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
- [6.1/T-0-4] DEVE fornire, tramite il binario perfetto, almeno le origini dati descritte nella documentazione di perfetto.

2.4. Requisiti dell'orologio

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

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

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

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

2.4.1. Hardware

Guarda le implementazioni dei dispositivi:

[7.1.1.1/W-0-1] DEVE avere uno schermo con dimensioni diagonali fisiche comprese tra 1,1 e 2,5 pollici.
[7.2.3/W-0-1] DEVE avere la funzione Home disponibile per l'utente e la funzione Indietro, tranne quando si trova in UI_MODE_TYPE_WATCH.
[7.2.4/W-0-1] DEVE supportare l'input touchscreen.
[7.3.1/W-SR] È FORTEMENTE CONSIGLIATO 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 di funzionalità android.hardware.location.gps,

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

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

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

Guarda le implementazioni dei dispositivi:

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

2.4.2. Multimediali

Nessun altro requisito.

2.4.3. Software

Guarda le implementazioni dei dispositivi:

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

Guarda le implementazioni dei dispositivi:

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

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

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

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

[3.11/W-SR] Sono FORTEMENTE CONSIGLIATI per 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 estendono le funzionalità incluse in AOSP:

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

Guarda le implementazioni dei dispositivi:

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

2.4.5. Modello di sicurezza

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

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

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

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

2.5. Requisiti per il settore automobilistico

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

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

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

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

2.5.1. Hardware

Implementazioni di dispositivi per il settore automotive:

[7.1.1.1/A-0-1] DEVE avere uno schermo di almeno 6 pollici di dimensione diagonale fisica.
[7.1.1.1/A-0-2] DEVE avere un layout delle dimensioni dello schermo di almeno 750 dp x 480 dp.
[7.2.3/A-0-1] DEVE fornire la funzione Home e PUÒ fornire le funzioni Indietro e Recenti.
[7.2.3/A-0-2] DEVE inviare sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano.
[7.3/A-0-1] DEVE implementare e segnalare GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED e PARKING_BRAKE_ON.
[7.3/A-0-2] Il valore del flag NIGHT_MODE DEVE essere coerente con la modalità giorno/notte del cruscotto e DOVREBBE basarsi sull'input del sensore della luce ambientale. Il sensore della luce ambientale sottostante POTREBBE essere lo stesso del fotometro.
[7.3/A-0-3] DEVE fornire il campo di informazioni aggiuntive del sensore TYPE_SENSOR_PLACEMENT nell'ambito di SensorAdditionalInfo per ogni sensore fornito.
[7.3/A-0-1] PUÒ stimare la posizione combinando GPS/GNSS con sensori aggiuntivi. Se la posizione è stimata, è VIVAMENTE CONSIGLIATO implementare e segnalare i tipi di sensore e/o gli ID proprietà veicolo corrispondenti utilizzati.
[7.3/A-0-2] La posizione richiesta tramite LocationManager#requestLocationUpdates() NON DEVE essere associata alla mappa.

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

[7.3.1/A-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 100 Hz.
[7.3.1/A-1-2] DEVE essere conforme al sistema di coordinate del sensore dell'auto Android.

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

[7.3.4/A-2-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 100 Hz.
[7.3.4/A-2-2] DEVE implementare anche il sensore TYPE_GYROSCOPE_UNCALIBRATED.
[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] È VIVAMENTE CONSIGLIATO configurare l'intervallo di misurazione del giroscopio su +/-250 dps per massimizzare la risoluzione possibile

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

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

Implementazioni di dispositivi per il settore automotive:

[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 telefoniche tramite il profilo Hands-Free (HFP).
- Riproduzione di contenuti multimediali tramite il profilo di distribuzione audio (A2DP).
- Controllo della riproduzione dei contenuti multimediali tramite il profilo controllo remoto (AVRCP).
- Condivisione dei contatti tramite il profilo Phonebook Access (PBAP).
[7.4.3/A-SR] Sono FORTEMENTE CONSIGLIATI per supportare il profilo di accesso ai messaggi (MAP).
[7.4.5/A] DEVE includere il supporto per la connettività dati basata sulla rete cellulare.
[7.4.5/A] PUÒ utilizzare la costante NetworkCapabilities#NET_CAPABILITY_OEM_PAID dell'API di sistema per le reti che devono essere disponibili per le app di sistema.

Una videocamera con visuale esterna è una videocamera che riprende scene al di fuori dell'implementazione del dispositivo, come una dashcam.

Implementazioni di dispositivi per il settore automotive:

DEVE includere una o più videocamere con vista esterna.

Se le implementazioni di dispositivi per il settore automobilistico includono una videocamera con visuale esterna, per questa videocamera:

[7.5/A-1-1] NON DEVONO avere telecamere con visuale esterna accessibili tramite le API Android Camera, a meno che non rispettino i requisiti di base della fotocamera.
[7.5/A-SR] È VIVAMENTE CONSIGLIATO di non ruotare o eseguire il mirroring orizzontale dell'anteprima della videocamera.
[7.5.5/A-SR] È VIVAMENTE CONSIGLIATO di orientare la videocamera in modo che la dimensione più lunga sia allineata all'orizzonte.
[7.5/A-SR] Sono FORTEMENTE CONSIGLIATE con una risoluzione di almeno 1,3 megapixel.
DEVE avere un hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
DEVE supportare il framework di sincronizzazione Android.
POTREBBE avere la messa a fuoco automatica hardware o software implementata nel driver della videocamera.

Implementazioni di dispositivi per il settore automotive:

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

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

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

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

[7.6.1/A-1-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 512 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 di grandi dimensioni
[7.6.1/A-1-2] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 608 MB se viene utilizzata una delle seguenti densità:
- xhdpi o superiore su schermi piccoli/normali
- hdpi o superiore su schermi di grandi dimensioni
- mdpi o superiore su schermi molto grandi
[7.6.1/A-1-3] 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 grandi
- tvdpi o superiore su schermi molto grandi
[7.6.1/A-1-4] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 1344 MB se viene utilizzata una delle seguenti densità:
- 560 dpi o superiore su schermi piccoli/normali
- 400 dpi o superiore su schermi grandi
- xhdpi o superiore su schermi molto grandi

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

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

Implementazioni di dispositivi per il settore automotive:

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

Implementazioni di dispositivi per il settore automotive:

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

Implementazioni di dispositivi per il settore automotive:

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

2.5.2. Multimediali

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

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

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

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

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

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

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

[5.3/A-SR] H.265 HEVC

2.5.3. Software

Implementazioni di dispositivi per il settore automotive:

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

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

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

Implementazioni di dispositivi per il settore automotive:

[3.2.1/A-0-1] DEVE supportare e applicare tutte le costanti di autorizzazione come documentato nella pagina di riferimento delle autorizzazioni per il settore automobilistico.
[3.2.3.1/A-0-1] DEVE precaricare uno o più componenti di applicazioni o servizi con un gestore di intent per tutti i pattern di filtri per intent pubblici definiti dai seguenti intent dell'applicazione elencati qui.
[3.4.1/A-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.
[3.8.3/A-0-1] DEVE mostrare le notifiche che utilizzano l'API Notification.CarExtender quando richiesto da applicazioni di terze parti.
[3.8.4/A-SR] È vivamente consigliato di implementare un assistente sul dispositivo per gestire l'azione Assist.

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

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

Implementazioni di dispositivi per il settore automotive:

[3.8.3.1/A-0-1] DEVE eseguire il rendering corretto delle risorse come descritto nella documentazione dell'SDK Notifications on Automotive OS.
[3.8.3.1/A-0-2] MUST display PLAY and MUTE for notification actions in the place of those provided through Notification.Builder.addAction()
[3.8.3.1/A] DOVREBBE limitare l'utilizzo di attività di gestione avanzate, come i controlli per canale di notifica. PUÒ utilizzare l'affordance dell'interfaccia utente per applicazione per ridurre i controlli.

Implementazioni di dispositivi per il settore automotive:

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

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

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

Implementazioni di dispositivi per il settore automotive:

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

2.5.4. Prestazioni e potenza

Implementazioni di dispositivi per il settore automotive:

[8.2/A-0-1] DEVE segnalare il numero di byte letti e scritti nell'archiviazione non volatile per ogni UID del processo, in modo che le statistiche siano disponibili per gli sviluppatori tramite l'API di sistema android.car.storagemonitoring.CarStorageMonitoringManager. Android Open Source Project soddisfa il requisito tramite il modulo kernel uid_sys_stats.
[8.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 consumo energetico per componente che definisca il valore di consumo di corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto Android Open Source.
[8.4/A-0-2] DEVE segnalare tutti i valori di consumo energetico in milliampereora (mAh).
[8.4/A-0-3] DEVE segnalare il consumo energetico della CPU per ogni UID del processo. L'Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
[8.4/A] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo energetico 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 per il settore automobilistico supportano più utenti:

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

Implementazioni di dispositivi per il settore automotive:

[9.11/A-0-1] DEVE eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
[9.11/A-0-2] DEVE avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e delle funzioni hash MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto open source Android (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti di un isolamento basato su hypervisor adeguato sono opzioni alternative.
[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 memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto Android Open Source Project upstream fornisce l'Hardware Abstraction Layer (HAL) Gatekeeper e Trusty, che possono essere utilizzati per soddisfare questo requisito.
[9.11/A-0-4] DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori di 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à.

Implementazioni di dispositivi per il settore automotive:

[9.14/A-0-1] DEVONO controllare i messaggi provenienti dai sottosistemi del veicolo del framework Android, ad esempio aggiungendo tipi di messaggi e origini dei messaggi consentiti a una lista consentita.
[9.14/A-0-2] DEVE proteggere dagli attacchi Denial of Service dal framework Android o da app di terze parti. In questo modo si evita che software dannosi inondino la rete del veicolo di traffico, il che potrebbe portare a un malfunzionamento dei sottosistemi del veicolo.

2.5.6. Compatibilità di strumenti e opzioni per sviluppatori

Implementazioni di dispositivi per il settore automotive:

Perfetto
- [6.1/A-0-1] DEVE esporre un binario /system/bin/perfetto all'utente della shell la cui riga di comando è conforme alla documentazione di Perfetto.
- [6.1/A-0-2] Il binario perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
- [6.1/A-0-3] Il binario perfetto DEVE scrivere come output una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
- [6.1/A-0-4] DEVE fornire, tramite il binario perfetto, almeno le origini dati descritte nella documentazione di perfetto.

2.6. Requisiti per i tablet

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

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

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

2.6.1. Hardware

Dimensioni schermo

[7.1.1.1/Tab-0-1] DEVE avere uno schermo compreso tra 7 e 18 pollici.

Giroscopio

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

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

Memoria e spazio di archiviazione minimi (sezione 7.6.1)

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

Modalità periferica USB (Sezione 7.7.1)

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

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

Modalità Realtà virtuale (sezione 7.9.1)

Virtual Reality High Performance (Sezione 7.9.2)

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

2.6.2. Modello di sicurezza

Chiavi e credenziali (sezione 9.11)

Fai riferimento alla sezione [9.11].

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

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

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

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

2.6.2. Software

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

3. Software

3.1. Compatibilità API gestita

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

Implementazioni del dispositivo:

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

Tuttavia,
- MAGGIO, se un'API nascosta è assente o implementata in modo diverso nell'implementazione del dispositivo, sposta l'API nascosta nell'elenco negato o omettila da tutti gli elenchi con limitazioni (ad es. grigio chiaro, grigio scuro, nero).
- MAGGIO, se un'API nascosta non esiste già in AOSP, aggiungila a uno degli elenchi con limitazioni (ad es. grigio chiaro, grigio scuro, nero).

3.1.1. Estensioni Android

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

Implementazioni di dispositivi Android:

[C-0-1] DEVE precaricare l'implementazione AOSP sia della libreria condivisa ExtShared sia dei servizi ExtServices con versioni maggiori o uguali alle versioni minime consentite per ogni livello API. Ad esempio, le implementazioni di dispositivi Android 7.0 che eseguono il livello API 24 DEVONO includere almeno la versione 1.
[C-0-2] DEVE restituire solo un numero di versione dell'estensione valido definito da AOSP.
[C-0-3] DEVE supportare tutte le API definite dalle versioni delle estensioni restituite da android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) nello stesso modo in cui sono supportate le altre API gestite, seguendo i requisiti della sezione 3.1.

3.1.2. Libreria Android

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

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

L'implementazione AOSP soddisfa questi requisiti.

3.2. Compatibilità API soft

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

3.2.1. Autorizzazioni

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

3.2.2. Parametri di build

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

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

Parametro	Dettagli
VERSIONE.RELEASE	La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE contenere uno dei valori stringa definiti in 11.
VERSION.SDK	La versione del sistema Android in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 11, questo campo DEVE avere il valore intero 11_INT.
VERSION.SDK_INT	La versione del sistema Android in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 11, questo campo DEVE avere il valore intero 11_INT.
VERSION.INCREMENTAL	Un valore scelto dall'implementatore del dispositivo che indica la build specifica del sistema Android attualmente in esecuzione, in formato leggibile. Questo valore NON DEVE essere riutilizzato per build diverse rese disponibili agli utenti finali. Un utilizzo tipico di questo campo è indicare il numero di build o l'identificatore di modifica del controllo del codice sorgente utilizzato per generare la build. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit stampabile e corrispondere all'espressione regolare "^[^ :\/~]+$".
DA TAVOLO	Un valore scelto dall'implementatore del dispositivo che identifica l'hardware interno specifico utilizzato dal dispositivo, in formato leggibile. Un possibile utilizzo di questo campo è indicare la revisione specifica della scheda che alimenta il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
BRAND	Un valore che riflette il nome del brand associato al dispositivo noto agli utenti finali. DEVE essere in un formato leggibile e DOVREBBE rappresentare il produttore del dispositivo o il brand dell'azienda con cui viene commercializzato il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
SUPPORTED_32_BIT_ABIS	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
SUPPORTED_64_BIT_ABIS	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
CPU_ABI	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
CPU_ABI2	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
DISPOSITIVO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice che identifica la configurazione delle funzionalità hardware e del design industriale del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Il nome del dispositivo NON DEVE cambiare durante il ciclo di vita del prodotto.
FINGERPRINT	Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ad esempio: acme/myproduct/ mydevice:11/LMYXX/3359:userdebug/test-keys L'impronta NON DEVE includere spazi. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit.
HARDWARE	Il nome dell'hardware (dalla riga di comando del kernel o da /proc). DEVE essere ragionevolmente leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
HOST	Una stringa che identifica in modo univoco l'host su cui è stata creata la build, in formato leggibile. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota ("").
ID	Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in formato leggibile. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DOVREBBE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere tra le build software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
PRODUTTORE	Il nome commerciale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota (""). Questo campo NON deve cambiare durante il ciclo di vita del prodotto.
MODEL	Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo noto all'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota (""). Questo campo NON deve cambiare durante il ciclo di vita del prodotto.
PRODOTTO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice dello specifico prodotto (SKU) che DEVE essere univoco all'interno dello stesso brand. DEVE essere leggibile, ma non è necessariamente destinato alla visualizzazione da parte degli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Il nome del prodotto NON DEVE cambiare durante il ciclo di vita del prodotto.
SERIAL	DEVE restituire "UNKNOWN".
TAG	Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che distinguono ulteriormente la build. I tag DEVONO essere codificabili come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+" e DEVONO avere uno dei valori corrispondenti alle tre configurazioni di firma tipiche della piattaforma Android: release-keys, dev-keys e test-keys.
TEMPO	Un valore che rappresenta il timestamp di quando è stata eseguita la build.
TIPO	Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni tipiche di Android Runtime: user, userdebug o eng.
UTENTE	Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota ("").
VERSION.SECURITY_PATCH	Un valore che indica il livello patch di sicurezza di una build. DEVE indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti nel Bollettino pubblico sulla sicurezza di Android designato. Deve essere nel formato [AAAA-MM-GG], corrispondente a una stringa definita documentata nel bollettino di sicurezza pubblico di Android o nell'avviso di sicurezza di Android, ad esempio "2015-11-01".
VERSION.BASE_OS	Un valore che rappresenta il parametro FINGERPRINT della build che è altrimenti identica a questa build, ad eccezione delle patch fornite nel Bollettino sulla sicurezza pubblica di Android. Deve segnalare il valore corretto e, se tale build non esiste, segnalare una stringa vuota ("").
BOOTLOADER	Un valore scelto dall'implementatore del dispositivo che identifica la versione specifica del bootloader interno utilizzata nel dispositivo, in formato leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
getRadioVersion()	DEVE (essere o restituire) un valore scelto dall'implementatore del dispositivo che identifica la versione specifica della radio/del modem interno utilizzata nel dispositivo, in formato leggibile. Se un dispositivo non ha radio/modem interni, DEVE restituire NULL. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-,]+$".
getSerial()	DEVE (essere o restituire) un numero di serie hardware, che DEVE essere disponibile e univoco su tutti i dispositivi con lo stesso MODELLO e PRODUTTORE. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-,]+$".

3.2.3. Compatibilità degli intent

3.2.3.1. Common Application Intents

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

Implementazioni del dispositivo:

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

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

3.2.3.2. Risoluzione dell'intent

[C-0-1] Poiché Android è una piattaforma estensibile, le implementazioni dei dispositivi DEVONO consentire l'override di ogni pattern di intent a cui viene fatto riferimento nella sezione 3.2.3.1 , ad eccezione delle Impostazioni, da parte di applicazioni di terze parti. L'implementazione open source di Android upstream lo consente per impostazione predefinita.
[C-0-2] Gli implementatori di dispositivi NON DEVONO assegnare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema né impedire alle applicazioni di terze parti di eseguire il binding e assumere il controllo di questi pattern. Questo divieto include in modo specifico, a titolo esemplificativo, la disattivazione dell'interfaccia utente "Chooser", che consente all'utente di scegliere tra più applicazioni che gestiscono tutte lo stesso pattern di intent.
[C-0-3] Le implementazioni dei dispositivi DEVONO fornire un'interfaccia utente per consentire agli utenti di modificare l'attività predefinita per gli intent.
Tuttavia, le implementazioni del dispositivo POSSONO fornire attività predefinite per pattern URI specifici (ad es. http://play.google.com) quando l'attività predefinita fornisce un attributo più specifico per l'URI dei dati. Ad esempio, un pattern di filtro per intent che specifica l'URI dati "http://www.android.com" è più specifico del pattern di intent principale del browser per "http://".

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

[C-0-4] DEVE tentare di convalidare tutti i filtri per intent eseguendo i passaggi di convalida definiti nella specifica Digital Asset Links implementata da Gestore pacchetti nel progetto Android Open Source Project upstream.
[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 correttamente come gestori di app predefiniti per i relativi URI.
POSSONO impostare filtri per intent URI specifici come gestori di app predefiniti per i propri URI, se vengono verificati correttamente, ma altri filtri URI candidati non superano la verifica. Se un'implementazione del dispositivo lo fa, DEVE fornire all'utente override di pattern per URI appropriati nel menu delle impostazioni.
DEVE fornire all'utente controlli dei link dell'app per app in Impostazioni come segue:
- [C-0-6] L'utente DEVE essere in grado di ignorare in modo olistico il comportamento predefinito dei link per app per un'app da: aprire sempre, chiedere sempre o non aprire mai, il che deve valere per tutti i filtri per intent URI candidati in egual misura.
- [C-0-7] L'utente DEVE essere in grado di visualizzare un elenco dei filtri per intent URI candidati.
- L'implementazione del dispositivo PUÒ fornire all'utente la possibilità di ignorare filtri per intent URI candidati specifici verificati correttamente, in base al filtro per intent.
- [C-0-8] L'implementazione del dispositivo DEVE consentire agli utenti di visualizzare e ignorare filtri di intent URI candidati specifici se l'implementazione del dispositivo consente la verifica di alcuni filtri di intent URI candidati, mentre altri possono non superarla.

3.2.3.3. Spazi dei nomi degli intent

[C-0-1] Le implementazioni dei dispositivi NON DEVONO includere componenti Android che rispettino nuovi pattern di intent o intent di trasmissione utilizzando un'AZIONE, una CATEGORIA o un'altra stringa chiave nello spazio dei nomi android. o com.android..
[C-0-2] Gli implementatori di dispositivi NON DEVONO includere componenti Android che rispettino nuovi intent o pattern di intent di trasmissione utilizzando una stringa ACTION, CATEGORY o un'altra stringa chiave in uno spazio di pacchetti appartenente a un'altra organizzazione.
[C-0-3] Gli implementatori di dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent elencati nella sezione 3.2.3.1.
Le implementazioni dei dispositivi POSSONO includere pattern di intent 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. Broadcast Intents

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

Implementazioni del dispositivo:

[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, in quanto la limitazione per le applicazioni in background è descritta anche nella documentazione dell'SDK. Inoltre, alcuni intent di trasmissione sono condizionati dal supporto hardware. Se il dispositivo supporta l'hardware necessario, DEVE trasmettere gli intent e fornire il comportamento in linea con la documentazione dell'SDK.

3.2.3.5. Intent di applicazione condizionali

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

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

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

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

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

[C-2-1] DEVE fornire un menu delle impostazioni che richiami l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT per mostrare una finestra di dialogo per modificare l'applicazione SMS predefinita.
[C-2-2] DEVE rispettare l'intent android.telecom.action.CHANGE_DEFAULT_DIALER di mostrare una finestra di dialogo per consentire all'utente di modificare l'applicazione Telefono predefinita.
- DEVE utilizzare la UI dell'app Telefono predefinita selezionata dall'utente per le chiamate in entrata e in uscita, ad eccezione delle chiamate di emergenza, che utilizzano l'app Telefono preinstallata.
[C-2-3] DEVE rispettare l'intent android.telecom.action.CHANGE_PHONE_ACCOUNTS per consentire all'utente di configurare l'ConnectionServices associato all'PhoneAccounts, nonché un PhoneAccount predefinito che il fornitore di servizi di telecomunicazioni utilizzerà per effettuare chiamate in uscita. L'implementazione AOSP soddisfa questo requisito includendo un menu "Opzione Account chiamate" nel menu delle impostazioni "Chiamate".
[C-2-4] DEVE consentire android.telecom.CallRedirectionService per un'app che detiene il ruolo android.app.role.CALL_REDIRECTION.
[C-2-5] DEVE fornire all'utente la possibilità di scegliere un'app che detiene il ruolo android.app.role.CALL_REDIRECTION.
[C-2-6] DEVE rispettare gli intent android.intent.action.SENDTO e android.intent.action.VIEW e fornire un'attività per inviare/visualizzare messaggi SMS.
[C-SR] È 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 di composizione precaricata in grado di gestire questi intent e fornire l'evasione come descritto nell'SDK.

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

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

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

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

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

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

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

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

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

[C-6-1] DEVE implementare un'attività che risponda all'intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, che per le implementazioni con UI_MODE_TYPE_NORMAL DEVE essere un'attività in cui l'utente può concedere o negare all'app l'accesso alle configurazioni delle norme DND.

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

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

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

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

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

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

Se le implementazioni del dispositivo forniscono la modalità Risparmio dati, devono: * [C-10-1] Fornire un'interfaccia utente nelle impostazioni che gestisca l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, consentendo agli utenti di aggiungere o rimuovere applicazioni dalla lista consentita.

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

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

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

[C-12-1] DEVE rispettare l'intent android.media.action.STILL_IMAGE_CAMERA e android.media.action.STILL_IMAGE_CAMERA_SECURE e avviare la fotocamera in modalità immagine statica come descritto nell'SDK.
[C-12-2] DEVE rispettare l'intent android.media.action.VIDEO_CAMERA per avviare la fotocamera in modalità video come descritto nell'SDK.
[C-12-3] DEVE consentire solo alle applicazioni Android preinstallate di gestire gli intent seguenti MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE e MediaStore.ACTION_VIDEO_CAPTURE, come descritto nel documento SDK.

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

[C-13-1] DEVE rispettare l'intent android.app.action.ADD_DEVICE_ADMIN per richiamare un'interfaccia utente che guidi l'utente nell'aggiunta dell'amministratore del dispositivo al sistema (o che gli consenta di rifiutarla).
[C-13-2] DEVE rispettare gli intent android.app.action.ADMIN_POLICY_COMPLIANCE, android.app.action.GET_PROVISIONING_MODE, android.app.action.PROVISIONING_SUCCESSFUL, android.app.action.PROVISION_MANAGED_DEVICE, 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 soddisfare questi intent come descritto nell'SDK qui.

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

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

Se le implementazioni dei dispositivi includono un'app preinstallata o vogliono consentire alle app di terze parti di accedere alle statistiche di utilizzo:

[C-SR] are STRONGLY RECOMMENDED provide user-accessible mechanism to grant or revoke access to the usage stats in response to the android.settings.ACTION_USAGE_ACCESS_SETTINGS intent for apps that declare the android.permission.PACKAGE_USAGE_STATS permission.

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

[C-15-1] DEVE comunque avere un'attività che gestisce il pattern di intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, ma DEVE implementarlo come no-op, ovvero avere un comportamento equivalente a quando l'accesso viene negato all'utente.

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

[C-SR] È 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, che hanno un'attività per fornire il completamento di questi intent, come descritto nell'SDK qui.

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

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

3.2.4. Attività su display secondari/multipli

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

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

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

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

3.3. Compatibilità con l'API nativa

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

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

3.3.1. Application Binary Interfaces

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

Implementazioni del dispositivo:

[C-0-1] DEVE essere compatibile con una o più ABI NDK per Android definite.
[C-0-2] DEVE includere il supporto per il codice in esecuzione nell'ambiente gestito per chiamare il codice nativo, utilizzando la semantica standard di Java Native Interface (JNI).
[C-0-3] DEVE essere compatibile con l'origine (ovvero con l'intestazione) e con i file binari (per l'ABI) con ogni libreria richiesta nell'elenco seguente.
[C-0-5] DEVE segnalare con precisione l'Application Binary Interface (ABI) nativa supportata dal dispositivo tramite i parametri android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, ognuno dei quali è un elenco di ABI separati da virgole e ordinati dalla più preferita alla meno preferita.
[C-0-6] DEVE segnalare, tramite i parametri sopra indicati, un sottoinsieme del seguente elenco di ABI e NON DEVE segnalare ABI non presenti nell'elenco.
- armeabi (non più supportato come target dall'NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
[C-0-7] DEVE rendere disponibili alle app che includono codice nativo tutte le seguenti librerie, che forniscono API native:
- libaaudio.so (supporto audio nativo AAudio)
- libamidi.so (supporto MIDI nativo, se la funzionalità android.software.midi è rivendicata come descritto nella Sezione 5.9)
- libandroid.so (supporto dell'attività Android nativa)
- libc (libreria C)
- libcamera2ndk.so
- libdl (dynamic linker)
- libEGL.so (gestione nativa della superficie OpenGL)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (logging Android)
- libmediandk.so (supporto delle API media native)
- libm (libreria matematica)
- libneuralnetworks.so (API Neural Networks)
- libOpenMAXAL.so (supporto di OpenMAX AL 1.0.1)
- libOpenSLES.so (supporto audio OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (supporto minimo per C++)
- libvulkan.so (Vulkan)
- libz (compressione Zlib)
- Interfaccia JNI
[C-0-8] NON DEVE aggiungere o rimuovere le funzioni pubbliche per le librerie native elencate sopra.
[C-0-9] DEVE elencare 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 versioni successive, in quanto sono riservate.
[C-0-11] DEVE esportare tutti i simboli di funzione OpenGL ES 3.1 e Android Extension Pack, come definiti nell'NDK, tramite la libreria libGLESv3.so. Tieni presente che, sebbene tutti i simboli DEBBANO essere presenti, la sezione 7.1.4.1 descrive in modo più dettagliato i requisiti per quando è prevista l'implementazione completa di ciascuna funzione corrispondente.
[C-0-12] DEVE esportare i simboli di funzione per i simboli di funzione Vulkan 1.0 di base, nonché le estensioni VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 tramite la libreria libvulkan.so. Tieni presente che, sebbene tutti i simboli DEBBANO essere presenti, la sezione 7.1.4.2 descrive in modo più dettagliato i requisiti per quando è prevista l'implementazione completa di ciascuna funzione corrispondente.
DEVE essere creato utilizzando il codice sorgente e i file di intestazione disponibili nel progetto Android Open Source Project upstream

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

3.3.2. Compatibilità del codice nativo ARM a 32 bit

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

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

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

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

3.4. Compatibilità web

3.4.1. Compatibilità di WebView

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

[C-1-1] MUST report android.software.webview.
[C-1-2] DEVE utilizzare la build del progetto Chromium dall'Android Open Source Project upstream sul ramo Android 11 per l'implementazione dell'API android.webkit.WebView.
[C-1-3] La stringa dello user agent segnalata da WebView DEVE essere nel seguente formato:

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

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

3.4.2. Compatibilità dei browser

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

[C-1-1] DEVE supportare ciascuna di queste API associate a HTML5:
[C-1-2] DEVE supportare l'API webstorage HTML5/W3C e DOVREBBE supportare l'API IndexedDB HTML5/W3C. Tieni presente che, poiché gli enti di standardizzazione dello sviluppo web stanno passando a IndexedDB rispetto a webstorage, è previsto che IndexedDB diventi un componente obbligatorio in una versione futura di Android.
POTREBBE spedire una stringa user agent personalizzata nell'applicazione browser autonoma.
DEVE implementare il supporto per la maggior parte possibile di HTML5 nell'applicazione browser autonoma (basata sull'applicazione browser WebKit upstream o su una sostituzione di terze parti).

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

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

3.5. Compatibilità comportamentale delle API

Implementazioni del dispositivo:

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

I comportamenti di ciascun tipo di API (gestite, soft, native e web) devono essere coerenti con l'implementazione preferita del progetto Android Open Source Project 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 il ciclo di vita o la semantica del ciclo di vita di un particolare tipo di componente di sistema (ad esempio Service, Activity, ContentProvider e così via).
[C-0-3] I dispositivi NON DEVONO modificare la semantica di un'autorizzazione standard.
I dispositivi NON DEVONO alterare le limitazioni imposte alle applicazioni in background. Più nello specifico, per le app in background:
- [C-0-4] devono interrompere l'esecuzione dei callback registrati dall'app per ricevere gli output da GnssMeasurement e GnssNavigationMessage.
- [C-0-5] DEVONO limitare la frequenza degli aggiornamenti forniti all'app tramite la classe API LocationManager o il metodo WifiManager.startScan().
- [C-0-6] Se l'app ha come target il livello API 25 o versioni successive, NON DEVE consentire la registrazione di ricevitori di trasmissioni per le trasmissioni implicite di intent standard di Android nel manifest dell'app, a meno che l'intent di trasmissione non richieda un'autorizzazione "signature" o "signatureOrSystem" protectionLevel o non sia presente nell'elenco delle esenzioni.
- [C-0-7] Se l'app ha come target il livello API 25 o superiore, DEVE interrompere i servizi in background dell'app, proprio come se l'app avesse chiamato il metodo stopSelf() dei servizi, a meno che l'app non venga inserita in un elenco consentito temporaneo per gestire un'attività visibile all'utente.
- [C-0-8] Se l'app ha come target il livello API 25 o versioni successive, DEVE rilasciare i wakelock che detiene.
[C-0-9] I dispositivi DEVONO restituire i seguenti fornitori di sicurezza come primi sette valori dell'array dal metodo Security.getProviders(), nell'ordine indicato e con i nomi (restituiti da Provider.getName()) e le classi indicati, a meno che l'app non abbia modificato l'elenco tramite insertProviderAt() o removeProvider(). I dispositivi POSSONO restituire fornitori aggiuntivi dopo l'elenco specificato di fornitori riportato di seguito.
1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
3. CertPathProvider - sun.security.provider.CertPathProvider
4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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

3.5.1. Limitazione dell'applicazione

Se le implementazioni dei dispositivi implementano un meccanismo proprietario per limitare le app e questo meccanismo è più restrittivo del bucket di standby delle app rare, queste:

[C-1-1] DEVE fornire un'interfaccia utente in cui l'utente possa visualizzare l'elenco delle app con limitazioni.
[C-1-2] DEVE fornire all'utente la possibilità di attivare / disattivare le limitazioni per ogni app.
[C-1-3] NON deve applicare automaticamente le limitazioni senza prove di un comportamento di integrità del sistema scadente, ma PUÒ applicare le limitazioni alle app al rilevamento di un comportamento di integrità del sistema scadente, come wakelock bloccati, servizi a lunga esecuzione e altri criteri. I criteri POSSONO essere determinati dagli implementatori del dispositivo, ma DEVONO essere correlati all'impatto dell'app sull'integrità del sistema. Altri criteri non puramente correlati all'integrità del sistema, come la scarsa popolarità dell'app sul mercato, NON DEVONO essere utilizzati come criteri.
[C-1-4] NON deve applicare automaticamente le limitazioni delle app quando un utente le ha disattivate manualmente e PUÒ suggerire all'utente di applicarle.
[C-1-5] DEVE informare gli utenti se le limitazioni delle app vengono applicate automaticamente a un'app. Queste informazioni DEVONO essere fornite entro 24 ore dall'applicazione delle limitazioni.
[C-1-6] DEVE restituire true per ActivityManager.isBackgroundRestricted() quando l'app con limitazioni chiama questa API.
[C-1-7] NON DEVE limitare l'app in primo piano principale utilizzata esplicitamente dall'utente.
[C-1-8] DEVE sospendere le limitazioni di un'app che diventa l'applicazione in primo piano principale quando l'utente inizia esplicitamente a utilizzare l'app che era limitata.

3.6. API Namespaces

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

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

ovvero:

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

Gli implementatori di dispositivi POSSONO modificare l'implementazione sottostante delle API, ma tali modifiche:

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

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

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

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

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

3.7. Compatibilità del runtime

Implementazioni del dispositivo:

[C-0-1] DEVE supportare il formato Dalvik Executable (DEX) completo e la specifica e la semantica del bytecode Dalvik.
[C-0-2] MUST configure Dalvik runtimes to allocate memory in accordance with the upstream Android platform, and as specified by the following table. (Per le definizioni di dimensioni e densità dello schermo, consulta la sezione 7.1.1.)
DEVE utilizzare Android RunTime (ART), l'implementazione di riferimento upstream del formato Dalvik Executable e il sistema di gestione dei pacchetti dell'implementazione di riferimento.
DOVREBBE eseguire test fuzzing in varie modalità di esecuzione e architetture di destinazione per garantire la stabilità del runtime. Consulta JFuzz e DexFuzz sul sito web di Android Open Source Project.

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

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

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

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

Se le implementazioni dei dispositivi 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 la propria icona e vengono chiamati i metodi PackageManager per recuperare le icone.

Se le implementazioni dei dispositivi includono un Avvio app predefinito che supporta il blocco delle scorciatoie nelle app:

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

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

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

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

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

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

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

3.8.2. Widget

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

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

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

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

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

3.8.3. Notifiche

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

3.8.3.1. Presentazione delle notifiche

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

[C-1-1] DEVE supportare le notifiche che utilizzano le funzionalità hardware, come descritto nella documentazione dell'SDK e nella misura possibile con l'hardware di implementazione del dispositivo. Ad esempio, se l'implementazione di un dispositivo include un vibratore, DEVE implementare correttamente le API di vibrazione. Se un'implementazione del dispositivo non dispone di hardware, le API corrispondenti DEVONO essere implementate come no-op. Questo comportamento è descritto in dettaglio nella sezione 7.
[C-1-2] DEVE eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) fornite nelle API o nella guida di stile delle icone della barra di stato/di sistema, anche se PUÒ fornire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'implementazione di riferimento di Android Open Source.
[C-1-3] DEVE rispettare e implementare correttamente i comportamenti descritti per le API per aggiornare, rimuovere e raggruppare le notifiche.
[C-1-4] DEVE fornire il comportamento completo dell'API NotificationChannel documentato nell'SDK.
[C-1-5] DEVE fornire un'opzione per bloccare e modificare la notifica di una determinata app di terze parti per ogni canale e livello di pacchetto applicativo.
[C-1-6] DEVE anche fornire un'interfaccia utente per visualizzare i canali di notifica eliminati.
[C-1-7] DEVE eseguire il rendering corretto di tutte le risorse (immagini, adesivi, icone e così via) fornite tramite Notification.MessagingStyle insieme al testo della notifica senza interazione aggiuntiva dell'utente. Ad esempio, DEVE mostrare tutte le risorse, incluse le icone fornite tramite android.app.Person in una conversazione di gruppo impostata tramite setGroupConversation.
[C-SR] Sono FORTEMENTE CONSIGLIATE per mostrare automaticamente una funzionalità utente per bloccare la notifica di una determinata app di terze parti per ogni canale e livello di pacchetto applicativo dopo che l'utente ha chiuso la notifica più volte.
DEVE supportare le notifiche avanzate.
DOVREBBE presentare alcune notifiche con priorità più elevata come notifiche in evidenza.
DOVREBBE avere un'opzione per posticipare le notifiche.
MAY può gestire solo la visibilità e la tempistica delle notifiche di eventi importanti inviate agli utenti da app di terze parti per mitigare problemi di sicurezza come la distrazione del conducente.

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

Implementazioni del dispositivo:

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

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

[C-SR] Are STRONGLY RECOMMENDED to display this conversation as a bubble. L'implementazione AOSP soddisfa questi requisiti con l'interfaccia utente di sistema, le Impostazioni e il Launcher predefiniti.

Se le implementazioni dei dispositivi supportano le notifiche avanzate:

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

Se le implementazioni dei dispositivi supportano le notifiche di avviso, queste:

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

3.8.3.2. Servizio listener di notifiche

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

Implementazioni del dispositivo:

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

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

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

3.8.3.3. DND (Do Not Disturb, Non disturbare)

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

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

3.8.4. Cerca

Android include API che consentono agli sviluppatori di incorporare la ricerca nelle proprie applicazioni ed esporre i dati dell'applicazione nella ricerca globale del sistema. In generale, questa funzionalità è costituita da un'unica interfaccia utente a livello di sistema che consente agli utenti di inserire query, visualizza suggerimenti durante la digitazione e mostra i risultati. Le API Android consentono agli sviluppatori di riutilizzare questa interfaccia per fornire la ricerca all'interno delle proprie app e di fornire risultati all'interfaccia utente di ricerca globale comune.

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

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

[C-1-1] DEVE implementare le API che consentono alle applicazioni di terze parti di aggiungere suggerimenti alla casella di ricerca quando viene eseguita in modalità di ricerca globale.

Se non sono installate applicazioni di terze parti che utilizzano la ricerca globale:

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

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

Se le implementazioni dei dispositivi supportano l'azione Aiuto,

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

3.8.5. Avvisi e notifiche di tipo toast

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

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

[C-1-1] DEVE fornire un'interfaccia utente per impedire a un'app di visualizzare finestre di avviso che utilizzano TYPE_APPLICATION_OVERLAY . L'implementazione AOSP soddisfa questo requisito disponendo di controlli nell'area notifiche.
[C-1-2] DEVE rispettare l'API Toast e mostrare i toast delle applicazioni agli utenti finali in modo molto visibile.

3.8.6. Temi

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

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

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

[C-1-1] NON DEVE alterare nessuno degli attributi del tema Holo esposti alle applicazioni.
[C-1-2] DEVE supportare la famiglia di temi "Material" e NON DEVE alterare nessuno degli attributi del tema Material o delle relative risorse esposte alle applicazioni.
[C-1-3] DEVE impostare il carattere "sans-serif" su Roboto versione 2.x per le lingue supportate da Roboto oppure fornire un'opzione per consentire all'utente di modificare il carattere utilizzato per il carattere "sans-serif" in Roboto versione 2.x per le lingue supportate da Roboto.

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

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

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

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

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

3.8.7. Sfondi animati

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

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

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

Se le implementazioni dei dispositivi implementano sfondi animati:

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

3.8.8. Passaggio da un'attività all'altra

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

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

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

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

3.8.9. Input Management

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

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

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

3.8.10. Controllo dei contenuti multimediali nella schermata di blocco

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

3.8.11. Salvaschermi (precedentemente chiamati Sogni)

Consulta la sezione 3.2.3.5 per l'intent delle impostazioni per configurare i salvaschermo.

3.8.12. Località

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

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

3.8.13. Unicode e carattere

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

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

[C-1-1] DEVE essere in grado di eseguire il rendering di questi caratteri emoji in un glifo a colori.
[C-1-2] MUST include support for:
- Font Roboto 2 con diversi pesi: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light per le lingue disponibili sul dispositivo.
- Copertura completa di Unicode 7.0 di latino, greco e cirillico, inclusi gli intervalli latino esteso A, B, C e D e tutti i glifi nel blocco dei simboli di valuta di Unicode 7.0.
DEVE supportare le emoji con tonalità della pelle e delle diverse famiglie come specificato nel Unicode Technical Report #51.

Se le implementazioni dei dispositivi includono un IME:

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

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

Se le implementazioni dei dispositivi includono il supporto del birmano:

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. Multi-finestra

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

[C-1-1] DEVE implementare una o più modalità multi-finestra in conformità con i comportamenti e le API dell'applicazione descritti nella documentazione sul supporto della modalità multi-finestra dell'SDK Android e soddisfare i seguenti requisiti:
[C-1-2] DEVE rispettare android:resizeableActivity impostato da un'app nel file AndroidManifest.xml come descritto in questo SDK.
[C-1-3] NON DEVE offrire la modalità Split Screen o Freeform se l'altezza dello schermo è inferiore a 440 dp e la larghezza dello schermo è inferiore a 440 dp.
[C-1-4] Un'attività NON DEVE essere ridimensionata a una dimensione inferiore a 220 dp nelle modalità multi-finestra diverse da Picture in picture.
Le implementazioni del dispositivo con dimensioni dello schermo xlarge DEVONO supportare la modalità a mano libera.

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

[C-2-1] DEVE precaricare un launcher ridimensionabile come predefinito.
[C-2-2] DEVE ritagliare l'attività agganciata di una Multi-finestra in modalità schermo diviso, ma DOVREBBE mostrare alcuni contenuti se l'app Avvio app è la finestra selezionata.
[C-2-3] DEVE rispettare i valori dichiarati di AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight dell'applicazione di avvio di terze parti e non sostituirli durante la visualizzazione di alcuni contenuti dell'attività agganciata.

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

[C-3-1] DEVE avviare le attività in modalità multi-finestra Picture in picture quando l'app: * Ha come target il livello API 26 o versioni successive e dichiara android:supportsPictureInPicture * Ha come target il livello API 25 o versioni precedenti e dichiara sia android:resizeableActivity sia android:supportsPictureInPicture.
[C-3-2] DEVE esporre le azioni nella SystemUI come specificato dall'attività PIP corrente tramite l'API setActions().
[C-3-3] DEVE supportare proporzioni maggiori o uguali a 1:2,39 e minori o uguali a 2,39:1, come specificato dall'attività PIP tramite l'API setAspectRatio().
[C-3-4] DEVE utilizzare KeyEvent.KEYCODE_WINDOW per controllare la finestra PIP; se la modalità PIP non è implementata, il tasto DEVE essere disponibile per l'attività in primo piano.
[C-3-5] DEVE fornire un'interfaccia utente per impedire la visualizzazione di un'app in modalità PIP. L'implementazione AOSP soddisfa questo requisito grazie ai controlli nell'area notifiche.
[C-3-6] DEVE allocare la larghezza e l'altezza minime seguenti per la finestra PIP quando un'applicazione non dichiara alcun valore per AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight:
- I dispositivi con Configuration.uiMode impostato su un valore diverso da UI_MODE_TYPE_TELEVISION DEVONO allocare una larghezza e un'altezza minime di 108 dp.
- I dispositivi con Configuration.uiMode impostato su UI_MODE_TYPE_TELEVISION DEVONO allocare una larghezza minima di 240 dp e un'altezza minima di 135 dp.

3.8.15. Ritaglio display

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

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

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

3.8.16. Controllo dei dispositivi

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

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

3.9. Amministrazione dispositivo

Android include funzionalità che consentono alle applicazioni attente alla sicurezza di eseguire funzioni di amministrazione del dispositivo a livello di sistema, ad esempio l'applicazione di criteri per le password o l'esecuzione 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 del proprietario del dispositivo come descritto nella sezione 3.9.1 e nella sezione 3.9.1.1.

3.9.1 Provisioning dispositivo

3.9.1.1 Provisioning del proprietario del dispositivo

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

[C-1-1] DEVE supportare la registrazione di un client Device Policy (DPC) come app Device Owner, come descritto di seguito:
- Quando l'implementazione del dispositivo non ha ancora dati utente:
  - [C-1-3] DEVE segnalare true per DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  - [C-1-4] DEVE registrare l'applicazione DPC come app proprietario del dispositivo in risposta all'azione intent android.app.action.PROVISION_MANAGED_DEVICE.
  - [C-1-5] DEVE registrare l'applicazione DPC come app proprietario del dispositivo se il dispositivo dichiara il supporto della tecnologia Near Field Communication (NFC) tramite il flag di funzionalità android.hardware.nfc e riceve un messaggio NFC contenente un record con tipo MIME MIME_TYPE_PROVISIONING_NFC.
- Quando l'implementazione del dispositivo include dati utente:
  - [C-1-6] DEVE segnalare false per DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  - [C-1-7] NON deve più registrare alcuna applicazione DPC come app proprietario del dispositivo.
[C-1-2] DEVE richiedere un'azione affermativa prima o durante la procedura di provisioning per acconsentire all'impostazione dell'app come proprietario del dispositivo. Il consenso può essere ottenuto tramite l'azione dell'utente o con mezzi programmatici, ma prima di avviare il provisioning del proprietario del dispositivo DEVE essere mostrata una notifica di informativa appropriata (come indicato in AOSP). Inoltre, il meccanismo programmatico di consenso del proprietario del dispositivo utilizzato (dalle aziende) per il provisioning del proprietario del dispositivo NON DEVE interferire con l'esperienza out-of-box per l'utilizzo non aziendale.
[C-1-3] NON DEVE codificare in modo permanente il consenso o impedire l'utilizzo di altre app del proprietario del dispositivo.

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

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

3.9.1.2 Provisioning dei profili gestiti

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

[C-1-1] DEVE implementare le API che consentono a un'applicazione controller dei criteri dei dispositivi (DPC) di diventare il proprietario di un nuovo profilo gestito.
[C-1-2] La procedura di provisioning del profilo gestito (il flusso avviato da android.app.action.PROVISION_MANAGED_PROFILE) deve essere in linea con l'implementazione AOSP.
[C-1-3] DEVE fornire le seguenti funzionalità per l'utente all'interno delle Impostazioni per indicare all'utente quando una particolare funzione di sistema è stata disattivata dal controller delle norme del dispositivo (DPC):
- Un'icona coerente o un altro elemento di usabilità per l'utente (ad esempio l'icona delle informazioni AOSP upstream) per indicare quando una determinata impostazione è limitata da un amministratore del dispositivo.
- Un breve messaggio di spiegazione, fornito dall'amministratore del dispositivo tramite setShortSupportMessage.
- L'icona dell'applicazione DPC.

3.9.2 Supporto dei profili gestiti

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

[C-1-1] DEVE supportare i profili gestiti tramite le API android.app.admin.DevicePolicyManager.
[C-1-2] DEVE consentire la creazione di un solo profilo gestito.
[C-1-3] DEVE utilizzare un badge icona (simile al badge aziendale upstream AOSP) per rappresentare le applicazioni e i widget gestiti e altri elementi dell'interfaccia utente con badge come Recenti e Notifiche.
[C-1-4] DEVE visualizzare un'icona di notifica (simile al badge di lavoro upstream AOSP) per indicare quando l'utente si trova all'interno di un'applicazione del profilo gestito.
[C-1-5] DEVE mostrare una notifica toast che indica che l'utente si trova nel profilo gestito quando il dispositivo si riattiva (ACTION_USER_PRESENT) e l'applicazione in primo piano si trova all'interno del profilo gestito.
[C-1-6] Se esiste un profilo gestito, DEVE mostrare un ausilio visivo nel "Selettore" di intent per consentire all'utente di inoltrare l'intent dal profilo gestito all'utente principale o viceversa, se abilitato dal controller dei criteri del dispositivo.
[C-1-7] Se esiste un profilo gestito, DEVONO essere esposte le seguenti funzionalità per l'utente sia per l'utente principale sia per il profilo gestito:
- Contabilità separata per l'utilizzo di batteria, posizione, dati mobili e utilizzo dello spazio di archiviazione per l'utente principale e il profilo gestito.
- Gestione indipendente delle applicazioni VPN installate nell'utente principale o nel profilo gestito.
- Gestione indipendente delle applicazioni installate nell'utente principale o nel profilo gestito.
- Gestione indipendente degli account all'interno dell'utente principale o del profilo gestito.
[C-1-8] DEVE garantire che le applicazioni preinstallate Telefono, Contatti e Messaggi possano cercare e consultare le informazioni del chiamante dal profilo gestito (se esistente) insieme a quelle del profilo principale, se il Policy Controller del dispositivo lo consente.
[C-1-9] DEVE garantire di soddisfare tutti i requisiti di sicurezza applicabili a un dispositivo con più utenti abilitati (vedi sezione 9.5), anche se il profilo gestito non viene conteggiato come un altro utente oltre all'utente principale.

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

[C-2-1] DEVE supportare la possibilità di specificare una schermata di blocco separata che soddisfi i seguenti requisiti per concedere l'accesso solo alle app in esecuzione in un profilo gestito.
- Le implementazioni del dispositivo DEVONO rispettare l'intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrare un'interfaccia per configurare una credenziale della schermata di blocco separata per il profilo gestito.
- Le credenziali della schermata di blocco del profilo gestito DEVONO utilizzare gli stessi meccanismi di archiviazione e gestione delle credenziali del profilo genitore, come documentato nel sito del progetto Android Open Source.
- I criteri per le password del DPC DEVONO essere applicati solo alle credenziali della schermata di blocco del profilo gestito, a meno che non venga chiamata l'istanza DevicePolicyManager restituita da getParentProfileInstance.
Quando i contatti del profilo gestito vengono visualizzati nel registro chiamate preinstallato, nella UI durante la chiamata e nelle notifiche di chiamate in corso e senza risposta, le app di contatti e messaggistica DEVONO essere contrassegnate con lo stesso badge utilizzato per indicare le applicazioni del profilo gestito.

3.9.3 Assistenza utenti gestiti

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

[C-1-1] DEVE fornire un'agevolazione per l'utente per uscire dall'utente corrente e tornare all'utente principale nella sessione multiutente quando isLogoutEnabled restituisce true. L'interfaccia utente DEVE essere accessibile dalla schermata di blocco senza sbloccare il dispositivo.

3.10. Accessibilità

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

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

[C-1-1] DEVE fornire un'implementazione del framework di accessibilità Android come descritto nella documentazione dell'SDK delle API per l'accessibilità.
[C-1-2] DEVE generare eventi di accessibilità e fornire il AccessibilityEvent appropriato a tutte le implementazioni AccessibilityService come documentato nell'SDK.
[C-1-4] DEVE aggiungere un pulsante nella barra di navigazione del sistema che consenta all'utente di controllare il servizio di accessibilità quando i servizi di accessibilità attivati dichiarano AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Tieni presente che per le implementazioni del dispositivo senza barra di navigazione di sistema, questo requisito non è applicabile, ma le implementazioni del dispositivo DEVONO fornire un'agevolazione per l'utente per controllare questi servizi di accessibilità.

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

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

3.11. Text-to-Speech

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

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

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

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

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

3.12. Framework per l'ingresso TV

Il framework di input della televisione Android (TIF) semplifica la distribuzione di contenuti live ai dispositivi Android TV. TIF fornisce un'API standard per creare moduli di input che controllano i dispositivi Android Television.

Se le implementazioni dei dispositivi supportano 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 utilizza queste API e il servizio di input basati su TIF di terze parti possa essere installata e utilizzata sul dispositivo.

3.13. Impostazioni rapide

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

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

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

3.14. UI dei contenuti multimediali

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

[C-1-2] DEVE mostrare chiaramente le icone ottenute tramite getIconBitmap() o getIconUri() e i titoli ottenuti tramite getTitle(), come descritto in MediaDescription. Potrebbe abbreviare i titoli per rispettare le norme di sicurezza (ad es. distrazione del conducente).
[C-1-3] DEVE mostrare l'icona dell'applicazione di terze parti ogni volta che vengono visualizzati contenuti forniti da questa applicazione.
[C-1-4] DEVE consentire all'utente di interagire con l'intera gerarchia di MediaBrowser. PUÒ limitare l'accesso a una parte della gerarchia per rispettare le norme di sicurezza (ad es. 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

Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti:

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

Se le implementazioni dei dispositivi supportano le app istantanee, allora:

[C-1-1] DEVE fornire le seguenti funzionalità per l'interazione con le app istantanee. AOSP soddisfa i requisiti con l'UI di sistema, le Impostazioni e il Launcher predefiniti.
[C-1-2] DEVE fornire un invito per visualizzare ed eliminare le app istantanee memorizzate nella cache locale per ogni singolo pacchetto applicativo.
[C-1-3] DEVE fornire una notifica utente persistente che può essere compressa mentre un'app istantanea è in esecuzione in primo piano. Questa notifica per l'utente DEVE includere l'informazione che le app istantanee non richiedono l'installazione e fornire un'agevolazione che indirizzi l'utente alla schermata delle informazioni sull'applicazione in Impostazioni. Per le app istantanee avviate tramite intent web, come definito dall'utilizzo di un intent con l'azione impostata su Intent.ACTION_VIEW e con uno schema "http" o "https", un'ulteriore funzionalità per l'utente DOVREBBE consentirgli di non avviare l'app istantanea e di avviare il link associato con il browser web configurato, se un browser è disponibile sul dispositivo.
[C-1-4] DEVE consentire l'accesso alle app istantanee dalla funzione Recenti, se disponibile sul dispositivo.
[C-1-5] DEVE precaricare uno o più componenti di applicazioni o servizi con un gestore di intent per gli intent elencati nell'SDK qui e rendere visibili gli intent per le app istantanee.

3.16. Accoppiamento del dispositivo complementare

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

Se le implementazioni dei dispositivi supportano la funzionalità di accoppiamento di dispositivi complementari:

[C-1-1] DEVE dichiarare il flag funzionalità FEATURE_COMPANION_DEVICE_SETUP .
[C-1-2] DEVE garantire che le API nel pacchetto android.companion siano completamente implementate.
[C-1-3] DEVE fornire all'utente la possibilità di selezionare/confermare la presenza e il funzionamento di un dispositivo complementare.

3.17. App pesanti

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

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

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

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

3.18. Contatti

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

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

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

Implementazioni del dispositivo:

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

Se le implementazioni dei dispositivi utilizzano un account locale personalizzato:

[C-1-1] Il ACCOUNT_NAME dell'account locale personalizzato DEVE essere restituito entro il giorno ContactsContract.RawContacts.getLocalAccountName
[C-1-2] Il ACCOUNT_TYPE dell'account locale personalizzato DEVE essere restituito entro il giorno ContactsContract.RawContacts.getLocalAccountType
[C-1-3] I contatti grezzi inseriti da applicazioni di terze parti con l'account locale predefinito (ovvero impostando valori nulli per ACCOUNT_NAME e ACCOUNT_TYPE) DEVONO essere inseriti nell'account locale personalizzato.
[C-1-4] I contatti non elaborati inseriti nell'account locale personalizzato NON DEVONO essere rimossi quando 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 è impostato su false o non è specificato.

4. Compatibilità con il packaging delle applicazioni

Implementazioni dei dispositivi:

[C-0-1] DEVE essere in grado di installare ed eseguire file ".apk" Android generati dallo strumento "aapt" incluso nell'SDK Android ufficiale.
Poiché il requisito precedente potrebbe essere difficile da soddisfare, è CONSIGLIATO che le implementazioni dei dispositivi utilizzino il sistema di gestione dei pacchetti dell'implementazione di riferimento AOSP.

Implementazioni del dispositivo:

[C-0-2] DEVE supportare la verifica dei file ".apk" utilizzando lo schema di firma dell'APK v3 , lo schema di firma dell'APK v2 e la firma JAR.
[C-0-3] NON DEVE estendere i formati .apk, Android Manifest, bytecode Dalvik o bytecode RenderScript in modo 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" per il pacchetto di disinstallare l'app automaticamente senza alcuna conferma dell'utente, come documentato nell'SDK per l'autorizzazione DELETE_PACKAGE. Le uniche eccezioni sono l'app di verifica dei pacchetti di sistema che gestisce l'intent PACKAGE_NEEDS_VERIFICATION e l'app Gestione archiviazione che gestisce l'intent ACTION_MANAGE_STORAGE.
[C-0-5] DEVE avere un'attività che gestisce l'intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.
[C-0-6] NON DEVE installare pacchetti dell'applicazione da fonti sconosciute, a meno che l'app che richiede l'installazione soddisfi tutti i seguenti requisiti:
- DEVE dichiarare l'autorizzazione REQUEST_INSTALL_PACKAGES o avere il valore di android:targetSdkVersion impostato su 24 o inferiore.
- L'utente DEVE aver concesso l'autorizzazione per installare app da origini sconosciute.
DEVE fornire un'interfaccia utente per concedere/revocare l'autorizzazione a installare app da origini sconosciute per ogni applicazione, ma PUÒ scegliere di implementarla come no-op e restituire RESULT_CANCELED per startActivityForResult(), se l'implementazione del dispositivo non vuole consentire agli utenti di avere questa scelta. Tuttavia, anche in questi casi, DEVONO indicare all'utente il motivo per cui non viene presentata alcuna scelta.
[C-0-7] DEVE mostrare all'utente 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 che è stata contrassegnata dalla stessa API di sistema PackageManager.setHarmfulAppWarning come potenzialmente dannosa.
DEVE fornire un'opzione 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.
Se le implementazioni dei dispositivi sono già state lanciate su una versione precedente di Android e non soddisfano i requisiti [C-0-8] e [C-0-9] tramite un aggiornamento del software di sistema, POSSONO essere esentate da questi requisiti.

5. Compatibilità multimediale

Implementazioni del dispositivo:

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

Implementazioni del dispositivo:

SHOULD aim for minimum codec latency, in others words, they
- NON DEVE consumare e archiviare i buffer di input e restituirli solo una volta elaborati.
- NON DEVE conservare i buffer decodificati per un periodo di tempo superiore a quello specificato dallo standard (ad es. SPS).
- NON DEVE conservare i buffer codificati più a lungo di quanto richiesto dalla struttura GOP.

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

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

5.1. Codec multimediali

5.1.1. Codifica audio

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

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

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

Tutti i codificatori audio DEVONO supportare:

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

5.1.2. Decodifica audio

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

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

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

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

[C-2-1] La decodifica DEVE essere eseguita senza downmix (ad es. un flusso AAC 5.0 deve essere decodificato in cinque canali PCM, un flusso AAC 5.1 deve essere decodificato in sei canali PCM).
[C-2-2] I metadati dell'intervallo dinamico DEVONO essere definiti in "Dynamic Range Control (DRC)" in ISO/IEC 14496-3 e le chiavi DRC android.media.MediaFormat per configurare i comportamenti correlati all'intervallo dinamico del decodificatore audio. Le chiavi AAC DRC sono state introdotte nell'API 21 e sono: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_ENCODED_TARGET_LEVEL.
[SR] È VIVAMENTE CONSIGLIATO che i requisiti C-2-1 e C-2-2 sopra indicati siano soddisfatti da tutti i decoder audio AAC.

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

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

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

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

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

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

Tutti i decoder audio DEVONO supportare l'output di:

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

5.1.3. Dettagli sui codec audio

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

5.1.4. Codifica dell'immagine

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

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

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

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

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

5.1.5. Decodifica dell'immagine

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

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

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

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

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

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

5.1.6. Dettagli codec immagine

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

Encoder e decoder di immagini esposti tramite l'API MediaCodec

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

5.1.7. Codec video

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

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

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

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

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

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

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

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

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

5.1.8. Elenco dei codec video

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

5.1.9. Sicurezza del codec multimediale

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

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

Se le implementazioni dei dispositivi supportano i contenuti multimediali:

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

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

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

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

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

5.1.10. Caratterizzazione del codec multimediale

Se le implementazioni dei dispositivi supportano i codec multimediali:

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

In particolare:

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

Se le implementazioni del dispositivo supportano i codec video:

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

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

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

5.2. Codifica video

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

NON DEVE superare, in due finestre scorrevoli, il 15% del bitrate tra gli intervalli intraframe (I-frame).
NON DEVE superare il 100% del bitrate in una finestra mobile di 1 secondo.

Se le implementazioni del dispositivo includono un display integrato con una lunghezza diagonale di almeno 2, 5 pollici o includono una porta di uscita video o dichiarano il supporto di una videocamera tramite il flag di funzionalità android.hardware.camera.any:

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

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

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

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

DEVE supportare bit rate configurabili dinamicamente per il codificatore supportato.

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

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

5.2.1. H.263

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

[C-1-1] DEVE supportare il profilo di baseline di livello 45.
DEVE supportare bit rate configurabili dinamicamente per il codificatore supportato.

5.2.2. H.264

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

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

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

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

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

5.2.3. VP8

Se le implementazioni dei dispositivi supportano il codec VP8:

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

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

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

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

5.2.4. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

[C-1-2] DEVE supportare il profilo 0 livello 3.
[C-1-1] DEVE supportare la scrittura di file Matroska WebM.
[C-1-3] DEVE generare dati CodecPrivate.
DEVE supportare i profili di decodifica HD indicati nella tabella seguente.
[SR] sono FORTEMENTE CONSIGLIATI per supportare i profili di decodifica HD, come indicato nella tabella seguente, se è presente un codificatore hardware.

	SD	HD 720p	HD 1080p	UHD
Risoluzione video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps
Velocità in bit video	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se le implementazioni dei dispositivi dichiarano di supportare il profilo 2 o il profilo 3 tramite le API Media:

Il supporto del formato a 12 bit è FACOLTATIVO.

5.2.5. H.265

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

[C-1-1] DEVE supportare il profilo principale di livello 3.
DEVE supportare i profili di codifica HD indicati nella tabella seguente.
[SR] sono FORTEMENTE CONSIGLIATI per supportare i profili di codifica HD, come indicato nella tabella seguente, se è presente un codificatore hardware.

	SD	HD 720p	HD 1080p	UHD
Risoluzione video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps
Velocità in bit video	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3. Decodifica video

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

[C-1-1] DEVE supportare 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 profilo di baseline di livello 30 e 45.

5.3.3. MPEG-4

Se le implementazioni del dispositivo con decoder MPEG-4:

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

5.3.4. H.264

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

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

Se l'altezza segnalata dal metodo Display.getSupportedModes() è uguale o maggiore della risoluzione video, le implementazioni del dispositivo:

[C-2-1] DEVE supportare i profili di decodifica video HD 720p nella tabella seguente.
[C-2-2] DEVE supportare i profili di decodifica video HD 1080p nella tabella seguente.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p
Risoluzione video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	60 f/s	30 fps (60 fps^Televisione)
Velocità in bit video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

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

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

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

[C-2-1] Le implementazioni dei dispositivi DEVONO supportare almeno una delle decodifiche H.265 o VP9 dei profili 720, 1080 e UHD.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p	UHD
Risoluzione video	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30/60 fps (60 fps^{Televisione con decodifica hardware H.265})	60 f/s
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se le implementazioni 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 bitstream e/o dal contenitore.
[C-3-2] Le implementazioni del dispositivo DEVONO visualizzare correttamente i contenuti HDR sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

5.3.6. VP8

Se le implementazioni dei dispositivi supportano il codec VP8:

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

Se l'altezza segnalata dal metodo Display.getSupportedModes() è uguale o maggiore della 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 fps (60 fps^Televisione)	30 (60 fps^Televisione)
Velocità in bit video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

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

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

[C-2-1] DEVE supportare i profili di decodifica HD indicati nella tabella seguente.

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

[C-3-1] Le implementazioni dei dispositivi DEVONO supportare almeno una delle decodifiche VP9 o H.265 dei profili 720, 1080 e UHD.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p	UHD
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps (60 fps^{TV con decodifica hardware VP9})	60 f/s
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se le implementazioni dei dispositivi dichiarano di supportare VP9Profile2 o VP9Profile3 tramite le API multimediali 'CodecProfileLevel':

Il supporto del formato a 12 bit è FACOLTATIVO.

Se le implementazioni dei dispositivi dichiarano di supportare un profilo HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) tramite le API Media:

[C-4-1] Le implementazioni del dispositivo DEVONO accettare i metadati HDR richiesti (KEY_HDR_STATIC_INFO per tutti i profili HDR, nonché "KEY_HDR10_PLUS_INFO" per i profili HDR10Plus) dall'applicazione. Inoltre, DEVONO supportare l'estrazione e l'output dei metadati HDR richiesti dal bitstream e/o dal contenitore.
[C-4-2] Le implementazioni del dispositivo DEVONO visualizzare correttamente i contenuti HDR sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

5.3.8. Dolby Vision

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

[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'indice della traccia dei livelli base compatibili con le versioni precedenti (se presenti) in modo che corrisponda all'indice della traccia del livello Dolby Vision combinato.

5.3.9. AV1

Se le implementazioni dei dispositivi supportano il codec AV1:

[C-1-1] MUST support Profile 0 including 10-bit content.

5.4. Registrazione audio

Sebbene alcuni dei requisiti descritti in questa sezione siano elencati come SHOULD a partire da Android 4.3, è previsto che la Definizione di compatibilità per le versioni future li modifichi in MUST. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti elencati come SHOULD, altrimenti non potranno ottenere la compatibilità con Android quando verranno aggiornati alla versione futura.

5.4.1. Acquisizione audio grezzo e informazioni sul microfono

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

[C-1-1] DEVE consentire l'acquisizione di contenuti audio non elaborati con le seguenti caratteristiche:
- Formato: PCM lineare, 16 bit
- Frequenze di campionamento: 8000, 11025, 16000, 44100, 48000 Hz
- Canali: mono
DEVE consentire l'acquisizione di contenuti audio non elaborati con le seguenti caratteristiche:
- Formato: PCM lineare, 16 bit e 24 bit
- Frequenze di campionamento: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
- Canali: tanti canali quanti sono i microfoni sul dispositivo
[C-1-2] DEVE acquisire a frequenze di campionamento superiori senza upsampling.
[C-1-3] DEVE includere un filtro anti-aliasing appropriato quando le frequenze di campionamento indicate sopra vengono acquisite con il downsampling.
DEVE consentire l'acquisizione di contenuti audio grezzi con qualità radio AM e DVD, il che significa le seguenti caratteristiche:
- Formato: PCM lineare, 16 bit
- Frequenze di campionamento: 22050, 48000 Hz
- Canali: stereo
- [C-1-4] DEVE rispettare l'API MicrophoneInfo e compilare correttamente le informazioni per i microfoni disponibili sul dispositivo accessibili alle applicazioni di terze parti tramite l'API AudioManager.getMicrophones() e i microfoni attualmente attivi accessibili alle applicazioni di terze parti tramite le API AudioRecord.getActiveMicrophones() e MediaRecorder.getActiveMicrophones(). Se le implementazioni del dispositivo consentono la radio AM e l'acquisizione di contenuti audio grezzi di qualità DVD:
[C-2-1] DEVE acquisire senza upsampling a qualsiasi rapporto superiore a 16000:22050 o 44100:48000.
[C-2-2] DEVE includere un filtro anti-aliasing appropriato per qualsiasi upsampling o downsampling.

5.4.2. Acquisizione per il riconoscimento vocale

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

[C-1-1] DEVE acquisire la sorgente audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION a una delle frequenze di campionamento, 44100 e 48000.
[C-1-2] DEVE, per impostazione predefinita, disattivare qualsiasi elaborazione audio di riduzione del rumore durante la registrazione di uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
[C-1-3] DEVE, per impostazione predefinita, disattivare qualsiasi controllo automatico del guadagno durante la registrazione di un flusso audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
DEVE registrare lo stream audio del riconoscimento vocale con un'ampiezza approssimativamente piatta rispetto alle caratteristiche di frequenza: in particolare, ±3 dB, da 100 Hz a 4000 Hz.
DEVE registrare il flusso audio del riconoscimento vocale con la sensibilità di input impostata in modo che una sorgente di livello di potenza sonora (SPL) di 90 dB a 1000 Hz produca un valore RMS di 2500 per campioni a 16 bit.
DEVE registrare il flusso audio del riconoscimento vocale in modo che i livelli di ampiezza PCM traccino linearmente le variazioni del livello di pressione sonora di ingresso in un intervallo di almeno 30 dB da -18 dB a +12 dB rispetto a 90 dB SPL sul microfono.
DEVE registrare il flusso audio del riconoscimento vocale con distorsione armonica totale (THD) inferiore all'1% per 1 kHz a un livello di ingresso di 90 dB SPL al microfono.

Se le implementazioni dei dispositivi dichiarano android.hardware.microphone e tecnologie di eliminazione dei rumori ottimizzate per il riconoscimento vocale:

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

5.4.3. Acquisizione per il reindirizzamento della riproduzione

La classe android.media.MediaRecorder.AudioSource include la sorgente audio REMOTE_SUBMIX.

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

[C-1-1] DEVE implementare correttamente la sorgente audio REMOTE_SUBMIX in modo che quando un'applicazione utilizza l'API android.media.AudioRecord per registrare da questa sorgente audio, acquisisca un mix di tutti i flussi audio, ad eccezione di quanto segue:
- AudioManager.STREAM_RING
- AudioManager.STREAM_ALARM
- AudioManager.STREAM_NOTIFICATION

5.4.4. Cancellatore dell'eco acustica

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

DEVE implementare una tecnologia di cancellazione dell'eco acustico (AEC) ottimizzata per la comunicazione vocale e applicata al percorso di acquisizione quando si acquisisce utilizzando AudioSource.VOICE_COMMUNICATION

Se le implementazioni del dispositivo forniscono un Acoustic Echo Canceler inserito nel percorso audio di acquisizione quando è selezionato AudioSource.VOICE_COMMUNICATION, queste:

[C-SR] are STRONGLY_RECOMMENDED to declare this via AcousticEchoCanceler API method AcousticEchoCanceler.isAvailable()
[C-SR] are STRONGLY_RECOMMENDED to allow this audio effect to be controllable with the AcousticEchoCanceler API.
[C-SR] sono STRONGLY_RECOMMENDED per identificare in modo univoco ogni implementazione della tecnologia AEC tramite il campo AudioEffect.Descriptor.uuid.

5.4.5. Acquisizione simultanea

Se le implementazioni del dispositivo dichiarano android.hardware.microphone,DEVONO implementare l'acquisizione simultanea come descritto in questo documento. In particolare:

[C-1-1] DEVE consentire l'accesso simultaneo al microfono da parte di un servizio di accessibilità che acquisisce con AudioSource.VOICE_RECOGNITION e di almeno un'applicazione che acquisisce con qualsiasi AudioSource.
[C-1-2] DEVE consentire l'accesso simultaneo al microfono da parte di un'applicazione preinstallata che detiene un ruolo di assistente e di almeno un'applicazione che acquisisce con qualsiasi AudioSource, ad eccezione di AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER.
[C-1-3] DEVE disattivare l'acquisizione audio per qualsiasi altra applicazione, ad eccezione di un servizio di accessibilità, mentre un'applicazione acquisisce con AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER. Tuttavia, quando un'app acquisisce tramite AudioSource.VOICE_COMMUNICATION, un'altra app può acquisire la chiamata vocale se è un'app privilegiata (preinstallata) con l'autorizzazione CAPTURE_AUDIO_OUTPUT.
[C-1-4] Se due o più applicazioni acquisiscono contemporaneamente e nessuna delle due ha un'interfaccia utente in primo piano, quella che ha iniziato l'acquisizione più di recente riceve l'audio.

5.4.6. Livelli di guadagno del microfono

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

DEVE mostrare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte nella gamma di frequenza media: in particolare ±3 dB da 100 Hz a 4000 Hz per ogni microfono utilizzato per registrare la sorgente audio del riconoscimento vocale.
DEVE impostare la sensibilità dell'input audio in modo che una sorgente di tono sinusoidale a 1000 Hz riprodotta a un livello di pressione sonora (SPL) di 90 dB produca una risposta con RMS di 2500 per campioni a 16 bit (o -22,35 dB Full Scale per campioni in virgola mobile/a doppia precisione) per ogni microfono utilizzato per registrare la sorgente audio di riconoscimento vocale.
[C-SR] è FORTEMENTE CONSIGLIATO di mostrare livelli di ampiezza nella gamma di basse frequenze: in particolare da ±20 dB da 5 Hz a 100 Hz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio del riconoscimento vocale.
[C-SR] è FORTEMENTE CONSIGLIATO di mostrare livelli di ampiezza nella gamma di alte frequenze: in particolare da ±30 dB da 4000 Hz a 22 kHz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio del riconoscimento vocale.

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 grezzo

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

[C-1-1] DEVE consentire la riproduzione di contenuti audio non elaborati con le seguenti caratteristiche:
- Formati sorgente: PCM lineare, 16 bit, 8 bit, virgola mobile
- Canali: mono, stereo, configurazioni multicanale valide con un massimo di 8 canali
- Frequenze di campionamento (in Hz):
  - 8000, 11025, 16000, 22050, 32000, 44100, 48000 nelle configurazioni dei canali elencate sopra
  - 96000 in mono e stereo
DOVREBBE consentire la riproduzione di contenuti audio grezzi con le seguenti caratteristiche:
- Frequenze di campionamento: 24000, 48000

5.5.2. Effetti audio

Android fornisce un'API per gli effetti audio per le implementazioni dei dispositivi.

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

[C-1-1] DEVE supportare le implementazioni EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controllabili tramite le sottoclassi AudioEffect Equalizer e LoudnessEnhancer.
[C-1-2] DEVE supportare l'implementazione dell'API visualizzatore, controllabile tramite la classe Visualizer.
[C-1-3] DEVE supportare l'implementazione di EFFECT_TYPE_DYNAMICS_PROCESSING controllabile tramite la sottoclasse AudioEffect DynamicsProcessing.
DEVE supportare le implementazioni EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controllabili tramite le sottoclassi AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.
[C-SR] Sono VIVAMENTE CONSIGLIATI per supportare gli effetti in virgola mobile e multicanale.

5.5.3. Volume di uscita audio

Implementazioni di dispositivi per il settore automotive:

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

5.6. Latenza audio

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

Ai fini della presente sezione, utilizza le seguenti definizioni:

latenza di output. L'intervallo tra il momento in cui un'applicazione scrive un frame di dati codificati in PCM e il momento in cui il suono corrispondente viene presentato all'ambiente in un trasduttore sul dispositivo o il segnale esce dal dispositivo tramite una porta e può essere osservato esternamente.
Latenza di output a freddo. La latenza di output per il primo frame, quando il sistema di output audio è rimasto inattivo e spento prima della richiesta.
latenza di output continua. La latenza di output per i frame successivi, dopo che il dispositivo riproduce l'audio.
Latenza input. L'intervallo tra il momento in cui un suono viene presentato dall'ambiente al dispositivo in un trasduttore on-device o il momento in cui un segnale entra nel dispositivo tramite una porta e il momento in cui un'applicazione legge il frame corrispondente di dati codificati in PCM.
input perso. La parte iniziale di un segnale di input inutilizzabile o non disponibile.
Latenza di input a freddo. La somma del tempo di input perso e della latenza di input per il primo frame, quando il sistema di input audio è rimasto inattivo e spento prima della richiesta.
Latenza input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.
jitter dell'output a freddo. La variabilità tra misurazioni separate dei valori di latenza di output a freddo.
jitter di input a freddo. La variabilità tra misurazioni separate dei valori di latenza di input a freddo.
latenza di andata e ritorno continua. La somma della latenza di input continua, della latenza di output continua e di un periodo di buffer. Il periodo di buffer consente all'app di elaborare il segnale e di mitigare la differenza di fase tra i flussi di input e output.
API OpenSL ES coda di buffer PCM. Il set di API OpenSL ES correlate a PCM all'interno di Android NDK.
API audio nativa AAudio. Il set di API AAudio all'interno di Android NDK.
Timestamp. Una coppia costituita da una posizione relativa del frame all'interno di un flusso e dall'ora stimata in cui il frame entra o esce dalla pipeline di elaborazione audio sull'endpoint associato. Vedi anche AudioTimestamp.
glitch. Un'interruzione temporanea o un valore di campionamento errato nel segnale audio, in genere causato da un buffer underrun per l'output, da un buffer overrun per l'input o da qualsiasi altra fonte di rumore digitale o analogico.

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

[C-1-1] Il timestamp di output restituito da AudioTrack.getTimestamp e AAudioStream_getTimestamp è preciso con un margine di errore di +/- 2 ms.
[C-1-2] Latenza di output a freddo pari o inferiore a 500 millisecondi.

Se le implementazioni dei dispositivi dichiarano android.hardware.audio.output, è FORTEMENTE CONSIGLIATO che soddisfino o superino i seguenti requisiti:

[C-SR] Latenza di uscita a freddo di 100 millisecondi o meno. È VIVAMENTE CONSIGLIATO che i dispositivi esistenti e nuovi che eseguono questa versione di Android soddisfino questi requisiti ora. In una futura release della piattaforma nel 2021, la latenza di output a freddo di 200 ms o inferiore sarà un requisito OBBLIGATORIO.
[C-SR] Latenza di output continua pari o inferiore a 45 millisecondi.
[C-SR] Riduci al minimo il jitter dell'output a freddo.
[C-SR] Il timestamp di output restituito da AudioTrack.getTimestamp e AAudioStream_getTimestamp è preciso con un margine di errore di +/- 1 ms.

Se le implementazioni dei dispositivi soddisfano i requisiti sopra indicati, dopo la calibrazione iniziale, quando si utilizzano sia la coda del buffer PCM OpenSL ES sia le API audio native AAudio, per la latenza di output continua e la latenza di output a freddo su almeno un dispositivo di output audio supportato, sono:

[C-SR] VIVAMENTE CONSIGLIATO di segnalare l'audio a bassa latenza dichiarando il flag della funzionalità android.hardware.audio.low_latency.
[C-SR] VIVAMENTE CONSIGLIATO per soddisfare i requisiti per l'audio a bassa latenza tramite l'API AAudio.
[C-SR] 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 minore o uguale al valore restituito da android.media.AudioManager.getProperty(String) per la chiave della proprietà AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Se le implementazioni dei dispositivi non soddisfano i requisiti per l'audio a bassa latenza tramite la coda di buffer PCM OpenSL ES e le API audio native AAudio:

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

Se le implementazioni dei dispositivi includono android.hardware.microphone, DEVONO soddisfare i seguenti requisiti audio di input:

[C-3-1] Limita l'errore nei timestamp di input, restituiti da AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 2 ms. Per "errore" si intende la deviazione dal valore corretto.
[C-3-2] Latenza di input a freddo pari o inferiore a 500 millisecondi.

Se le implementazioni dei dispositivi includono android.hardware.microphone, è VIVAMENTE CONSIGLIATO che soddisfino questi requisiti audio di input:

[C-SR] Latenza di input a freddo di 100 millisecondi o meno. È VIVAMENTE CONSIGLIATO che i dispositivi esistenti e nuovi che eseguono questa versione di Android soddisfino questi requisiti ora. In una futura release della piattaforma nel 2021, la latenza di input a freddo di 200 ms o inferiore sarà un requisito OBBLIGATORIO.
[C-SR] Latenza di input continua di 30 millisecondi o meno.
[C-SR] Latenza di round trip continua pari o inferiore a 50 millisecondi.
[C-SR] Minimizza il jitter dell'input a freddo.
[C-SR] Limita l'errore nei timestamp di input, restituiti da AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 1 ms.

5.7. Protocolli di rete

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

Se le implementazioni dei dispositivi includono un decoder audio o video:

[C-1-1] DEVE supportare tutti i codec e i formati contenitore richiesti nella sezione 5.1 tramite HTTP(S).
[C-1-2] DEVE supportare i formati dei segmenti multimediali mostrati nella tabella Formati dei segmenti multimediali di seguito tramite il protocollo bozza HTTP Live Streaming, versione 7.
[C-1-3] DEVE supportare il seguente profilo audio/video RTP e i codec correlati 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	Riferimento/i	Supporto codec richiesto
Stream di trasporto MPEG-2	ISO 13818	Codec video: H264 AVC MPEG-4 SP MPEG-2 Per informazioni dettagliate su H264 AVC, MPEG2-4 SP e MPEG-2,consulta la sezione 5.1.3. Codec audio: AAC Per informazioni dettagliate su AAC e sulle relative varianti, consulta la sezione 5.1.1.
AAC con framing ADTS e tag ID3	ISO 13818-7	Per maggiori dettagli su AAC e sulle relative varianti, consulta la sezione 5.1.1.
WebVTT	WebVTT

Formati dei segmenti

Riferimento/i

Supporto codec richiesto

Stream di trasporto MPEG-2

ISO 13818

Codec video:

H264 AVC
MPEG-4 SP
MPEG-2

Per informazioni dettagliate su H264 AVC, MPEG2-4 SP
e MPEG-2,consulta la sezione 5.1.3.

Codec audio:

Per informazioni dettagliate su AAC e sulle relative varianti, consulta la sezione 5.1.1.

AAC con framing ADTS e tag ID3

ISO 13818-7

Per maggiori dettagli su AAC e sulle relative varianti, consulta la sezione 5.1.1.

WebVTT

RTSP (RTP, SDP)

Nome del profilo	Riferimento/i	Supporto codec richiesto
H264 AVC	RFC 6184	Per informazioni dettagliate su H264 AVC, consulta la sezione 5.1.3.
MP4A-LATM	RFC 6416	Per maggiori dettagli su AAC e sulle relative varianti, consulta la sezione 5.1.1.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Per informazioni dettagliate su H263, consulta la sezione 5.1.3.
H263-2000	RFC 4629	Per informazioni dettagliate su H263, consulta la sezione 5.1.3.
AMR	RFC 4867	Per informazioni dettagliate su AMR-NB, consulta la sezione 5.1.1.
AMR-WB	RFC 4867	Per informazioni dettagliate su AMR-WB, consulta la sezione 5.1.1.
MP4V-ES	RFC 6416	Per informazioni dettagliate su MPEG-4 SP, consulta la sezione 5.1.3.
mpeg4-generic	RFC 3640	Per maggiori dettagli su AAC e sulle relative varianti, consulta la sezione 5.1.1.
MP2T	RFC 2250	Per i dettagli, consulta MPEG-2 Transport Stream in HTTP Live Streaming.

5.8. Secure Media

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

[C-1-1] DEVE dichiarare il supporto per Display.FLAG_SECURE.

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

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

Se le implementazioni dei dispositivi dichiarano il supporto di Display.FLAG_SECURE e supportano il display esterno cablato:

[C-3-1] DEVE supportare HDCP 1.2 o versioni successive per tutti i display esterni collegati tramite una porta cablata accessibile all'utente.

5.9. Musical Instrument Digital Interface (MIDI)

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

[C-1-1] DEVE supportare MIDI su tutti i trasporti hardware compatibili con MIDI per i quali fornisce connettività generica non MIDI, dove questi trasporti sono:
- Modalità host USB, sezione 7.7
- MIDI su Bluetooth LE che funge da ruolo centrale, sezione 7.4.3
[C-1-2] DEVE supportare il trasporto software MIDI tra app (dispositivi MIDI virtuali)
[C-1-3] DEVE includere libamidi.so (supporto MIDI nativo)
DEVE supportare la modalità periferica MIDI su USB, sezione 7.7

5.10. Audio professionale

Se le implementazioni dei dispositivi segnalano il supporto della funzionalità android.hardware.audio.pro tramite la classe android.content.pm.PackageManager,

[C-1-1] DEVE segnalare il supporto per la funzionalità android.hardware.audio.low_latency.
[C-1-2] DEVE avere una latenza audio di andata e ritorno continua, come definita nella sezione 5.6 Latenza audio, DEVE essere pari o inferiore a 20 millisecondi e DOVREBBE essere pari o inferiore a 10 millisecondi su almeno un percorso supportato.
[C-1-3] DEVE includere una o più porte USB che supportano la modalità host USB e la modalità periferica USB.
[C-1-4] DEVE segnalare il supporto per la funzionalità android.software.midi.
[C-1-5] DEVE soddisfare i requisiti di latenza e audio USB utilizzando sia l'API coda buffer PCM OpenSL ES sia almeno un percorso dell'API AAudio native audio.
[SR] È VIVAMENTE CONSIGLIATO di soddisfare i requisiti di latenza e audio USB utilizzando l'API AAudio native audio anziché il percorso MMAP.
[C-1-6] DEVE avere una latenza di output a freddo pari o inferiore a 200 millisecondi.
[C-1-7] DEVE avere una latenza di input a freddo pari o inferiore a 200 millisecondi.
[SR] Sono FORTEMENTE CONSIGLIATI per fornire un livello coerente di prestazioni della CPU mentre l'audio è attivo e il carico della CPU varia. Questo test deve essere eseguito utilizzando la versione dell'app per Android di SynthMark con ID commit 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. SynthMark utilizza un sintetizzatore software in esecuzione su un framework audio simulato che misura le prestazioni del sistema. L'app SynthMark deve essere eseguita utilizzando l'opzione "Test automatico" e ottenere i seguenti risultati:
- voicemark.90 >= 32 voci
- latencymark.fixed.little <= 15 ms
- latencymark.dynamic.little <= 50 ms

Per una spiegazione dei benchmark, consulta la documentazione di SynthMark.

DOVREBBE ridurre al minimo l'imprecisione e la deriva dell'orologio audio rispetto all'ora standard.
DOVREBBE ridurre al minimo la deriva dell'orologio audio rispetto alla CPU CLOCK_MONOTONIC quando entrambi sono attivi.
DEVE ridurre al minimo la latenza audio sui trasduttori del dispositivo.
DEVE ridurre al minimo la latenza audio tramite l'audio digitale USB.
DEVE documentare le misurazioni della latenza audio in tutti i percorsi.
DEVE ridurre al minimo il jitter nei tempi di inserimento del callback di completamento del buffer audio, in quanto ciò influisce sulla percentuale utilizzabile della larghezza di banda della CPU completa da parte del callback.
DEVE fornire zero problemi audio durante l'uso normale alla latenza segnalata.
DEVE fornire una differenza di latenza tra i canali pari a zero.
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.
DEVE fornire timestamp MIDI accurati su tutti i trasporti.
DOVREBBE ridurre al minimo il rumore del segnale audio sui trasduttori del dispositivo, incluso il periodo immediatamente successivo all'avvio a freddo.
DEVE fornire una differenza di clock audio pari a zero tra i lati di input e output degli endpoint corrispondenti, quando entrambi sono attivi. Esempi di endpoint corrispondenti includono il microfono e l'altoparlante sul dispositivo o l'input e l'output del jack audio.
DEVE gestire i callback di completamento del buffer audio per i lati di input e output degli endpoint corrispondenti sullo stesso thread quando entrambi sono attivi ed entrare nel callback di output immediatamente dopo il ritorno dal callback di input. Se non è possibile gestire i callback nello stesso thread, inserisci il callback di output subito dopo aver inserito il callback di input per consentire all'applicazione di avere una tempistica coerente dei lati di input e output.
DEVE ridurre al minimo la differenza di fase tra il buffering audio HAL per i lati di input e output degli endpoint corrispondenti.
DEVE ridurre al minimo la latenza del tocco.
DEVE ridurre al minimo la variabilità della latenza del tocco sotto carico (jitter).
DOVREBBE avere una latenza dall'input tocco all'uscita audio inferiore o uguale a 40 ms.

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

[SR] VIVAMENTE CONSIGLIATO di segnalare il supporto per la funzionalità android.hardware.audio.pro tramite la classe android.content.pm.PackageManager.

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

[C-2-1] DEVE avere una latenza audio continua di andata e ritorno pari o inferiore a 20 millisecondi sul percorso del jack audio.
[SR] VIVAMENTE CONSIGLIATO di rispettare la sezione Specifiche del dispositivo mobile (jack) della specifica per le cuffie audio con cavo (v1.1).
La latenza audio continua di andata e ritorno DOVREBBE essere pari o inferiore a 10 millisecondi sul percorso del jack audio.

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

[C-3-1] DEVE implementare la classe audio USB.
[C-3-2] DEVE avere una latenza audio di round trip continua pari o inferiore a 20 millisecondi sulla porta in modalità host USB utilizzando la classe audio USB.
La latenza audio continua nel tempo di round trip DOVREBBE essere pari o inferiore a 10 millisecondi sulla porta della modalità host USB utilizzando la classe audio USB.
[C-SR] Sono FORTEMENTE CONSIGLIATI per supportare I/O simultanei fino a 8 canali per direzione, frequenza di campionamento di 96 kHz e profondità di 24 o 32 bit, se utilizzati con periferiche audio USB che supportano anche questi requisiti.

Se le implementazioni dei dispositivi includono una porta HDMI:

DEVE supportare l'output in stereo e otto canali a 20 bit o 24 bit di profondità e 192 kHz senza perdita di profondità di bit o ricampionamento, in almeno una configurazione.

5.11. Acquisizione per Non elaborato

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

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

[C-1-1] DEVE segnalare il supporto tramite la proprietà android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] DEVE presentare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte nella gamma di frequenza media: in particolare ±10 dB da 100 Hz a 7000 Hz per ogni microfono utilizzato per registrare la sorgente audio non elaborata.
[C-1-3] DEVE mostrare livelli di ampiezza nella gamma di basse frequenze: in particolare da ±20 dB da 5 Hz a 100 Hz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio non elaborata.
[C-1-4] DEVE mostrare livelli di ampiezza nella gamma di alte frequenze: in particolare da ±30 dB da 7000 Hz a 22 kHz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio non elaborata.
[C-1-5] DEVE impostare la sensibilità dell'ingresso audio in modo che una sorgente di tono sinusoidale a 1000 Hz riprodotta a un livello di pressione sonora (SPL) di 94 dB produca una risposta con RMS di 520 per campioni a 16 bit (o -36 dB Full Scale per campioni in virgola mobile/a doppia precisione) per ogni microfono utilizzato per registrare la sorgente audio non elaborata.
[C-1-6] DEVE avere un rapporto segnale/rumore (SNR) pari o superiore a 60 dB per ogni microfono utilizzato per registrare la sorgente audio non elaborata. mentre il rapporto segnale/rumore viene misurato come la differenza tra 94 dB SPL e il livello SPL equivalente del rumore proprio, ponderato A.
[C-1-7] DEVE avere una distorsione armonica totale (THD) inferiore all'1% per 1 kHz a un livello di ingresso SPL di 90 dB per ogni microfono utilizzato per registrare la sorgente audio non elaborata.
NON deve avere altre elaborazioni del segnale (ad es. controllo automatico del guadagno, filtro passa alto o cancellazione dell'eco) nel percorso, ad eccezione di un moltiplicatore di livello per portare il livello all'intervallo desiderato. In altre parole:
[C-1-8] Se nell'architettura è presente un'elaborazione del segnale per qualsiasi motivo, questa DEVE essere disattivata e non deve introdurre ritardi o latenza aggiuntivi nel percorso del segnale.
[C-1-9] Il moltiplicatore di livello, sebbene sia consentito nel percorso, NON DEVE introdurre ritardi o latenza nel percorso del segnale.

Tutte le misurazioni SPL vengono effettuate direttamente accanto al microfono in fase di test. Per le configurazioni con più microfoni, questi requisiti si applicano a ogni microfono.

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

[C-2-1] DEVE restituire null per il metodo API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), per indicare correttamente la mancanza di supporto.
[SR] are still STRONGLY RECOMMENDED to satisfy as many of the requirements for the signal path for the unprocessed recording source.

6. Compatibilità di strumenti e opzioni per sviluppatori

6.1. Strumenti per sviluppatori

Implementazioni del dispositivo:

[C-0-1] DEVE supportare gli strumenti per sviluppatori Android forniti nell'SDK Android.
Android Debug Bridge (ADB)
- [C-0-2] DEVE supportare adb come documentato nell'SDK Android e i comandi della shell forniti in AOSP, che possono essere utilizzati dagli sviluppatori di app, incluso dumpsys cmd stats
- [C-0-11] DEVE supportare il comando shell cmd testharness. L'upgrade delle implementazioni dei dispositivi da una versione precedente di Android senza un blocco di dati persistente POTREBBE essere esentato da C-0-11.
- [C-0-3] NON DEVE alterare il formato o i contenuti degli eventi di sistema del dispositivo (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrati tramite il comando dumpsys.
- [C-0-10] DEVE registrare, senza omissioni, e rendere accessibili e disponibili i seguenti eventi al comando shell cmd stats e alla classe API di sistema StatsManager.
  - ActivityForegroundStateChanged
  - AnomalyDetected
  - AppBreadcrumbReported
  - AppCrashOccurred
  - AppStartOccurred
  - BatteryLevelChanged
  - BatterySaverModeStateChanged
  - BleScanResultReceived
  - BleScanStateChanged
  - ChargingStateChanged
  - DeviceIdleModeStateChanged
  - ForegroundServiceStateChanged
  - GpsScanStateChanged
  - JobStateChanged
  - PluggedStateChanged
  - ScheduledJobStateChanged
  - ScreenStateChanged
  - SyncStateChanged
  - SystemElapsedRealtime
  - UidProcessStateChanged
  - WakelockStateChanged
  - WakeupAlarmOccurred
  - WifiLockStateChanged
  - WifiMulticastLockStateChanged
  - WifiScanStateChanged
- [C-0-4] Il daemon ADB lato dispositivo DEVE essere inattivo per impostazione predefinita e DEVE esistere un meccanismo accessibile all'utente per attivare Android Debug Bridge.
- [C-0-5] DEVE supportare adb sicuro. Android include il supporto di adb sicuro. Secure adb consente adb su host autenticati noti.
- [C-0-6] DEVE fornire un meccanismo che consenta la connessione di adb da una macchina host. In particolare:
Se le implementazioni dei dispositivi senza porta USB supportano la modalità periferica:
- [C-3-1] DEVE implementare adb tramite rete locale (ad esempio Ethernet o Wi-Fi).
- [C-3-2] DEVE fornire driver per Windows 7, 8 e 10, consentendo agli sviluppatori di connettersi al dispositivo utilizzando il protocollo adb.
Se le implementazioni dei dispositivi supportano le connessioni adb a una macchina host tramite Wi-Fi:
- [C-4-1] DEVE avere il metodo AdbManager#isAdbWifiSupported() che restituisce true.
Se le implementazioni del dispositivo supportano le connessioni adb a una macchina host tramite Wi-Fi e includono almeno una videocamera:
- [C-5-1] MUST have the AdbManager#isAdbWifiQrSupported() method return true.
Dalvik Debug Monitor Service (DDMS)
- [C-0-7] DEVE supportare tutte le funzionalità di ddms come documentato nell'SDK Android. Poiché ddms utilizza adb, il supporto di ddms DEVE essere inattivo per impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato Android Debug Bridge, come indicato sopra.
Scimmia
- [C-0-8] DEVE includere il framework Monkey e renderlo disponibile per l'utilizzo da parte delle applicazioni.
SysTrace
- [C-0-9] MUST support the systrace tool as documented in the Android SDK. Systrace deve essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivarlo.
Perfetto
- [C-SR] È FORTEMENTE CONSIGLIATO di esporre un binario /system/bin/perfetto all'utente della shell la cui riga di comando è conforme alla documentazione di Perfetto.
- [C-SR] È VIVAMENTE CONSIGLIATO che il binario perfetto accetti come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
- [C-SR] È VIVAMENTE CONSIGLIATO di scrivere il binario perfetto come output di una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
- [C-SR] È FORTEMENTE CONSIGLIATO fornire, tramite il binario perfetto, almeno le origini dati descritte nella documentazione di perfetto.
Low Memory Killer
- [C-0-10] DEVE scrivere un LMK_KILL_OCCURRED_FIELD_NUMBER Atom nel log statsd quando un'app viene chiusa da Low Memory Killer.
Modalità test harness Se le implementazioni del dispositivo supportano il comando shell cmd testharness ed eseguono cmd testharness enable,:
- [C-2-1] MUST return true for ActivityManager.isRunningInUserTestHarness()
- [C-2-2] DEVE implementare la modalità test harness come descritto nella documentazione relativa alla modalità test harness.

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 uno strumento per consentire allo sviluppatore di app di attivare/disattivare i livelli di debug della GPU.
[C-1-2] DEVE, quando i livelli di debug della GPU sono attivati, enumerare i livelli nelle librerie fornite da strumenti esterni (ovvero non parte del pacchetto della piattaforma o dell'applicazione) trovati nella directory di base delle applicazioni sottoponibili a debug per supportare i metodi API vkEnumerateInstanceLayerProperties() e vkCreateInstance().

6.2. Opzioni sviluppatore

Android include il supporto per gli sviluppatori per configurare le impostazioni relative allo sviluppo di applicazioni.

Le implementazioni dei dispositivi DEVONO fornire un'esperienza coerente per le opzioni sviluppatore, ovvero:

[C-0-1] DEVE rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo di applicazioni. L'implementazione Android upstream nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avviare le opzioni sviluppatore dopo aver premuto sette (7) volte la voce di menu Impostazioni > Informazioni dispositivo > Numero build.
[C-0-2] MUST hide Developer Options by default.
[C-0-3] DEVE fornire un meccanismo chiaro che non dia un trattamento preferenziale a un'app di terze parti rispetto a un'altra per attivare le opzioni sviluppatore. DEVE fornire un documento o un sito web visibile pubblicamente che descriva come attivare le opzioni sviluppatore. Questo documento o sito web DEVE essere collegabile dai documenti dell'SDK Android.
DEVE mostrare una notifica visiva continua all'utente quando le Opzioni sviluppatore sono attive e la sicurezza dell'utente è a rischio.
POTREBBE limitare temporaneamente l'accesso al menu Opzioni sviluppatore nascondendolo o disattivandolo visivamente, per evitare distrazioni negli scenari in cui la sicurezza dell'utente è un problema.

7. Compatibilità hardware

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

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

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

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

Un esempio tipico di scenario in cui si applicano questi requisiti è l'API Telephony: anche sui dispositivi non telefonici, queste API devono essere implementate come no-op ragionevoli.

7.1. Display e grafica

Android include funzionalità che regolano automaticamente gli asset 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 una varietà di configurazioni hardware. Sui display compatibili con Android su cui possono essere eseguite tutte le applicazioni di terze parti compatibili con Android, le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

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

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

7.1.1. Configurazione dello schermo

7.1.1.1. Dimensioni e forma dello schermo

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

Implementazioni del dispositivo:

[C-0-1] DEVE segnalare le dimensioni corrette del layout per Configuration.screenLayout come definito nella documentazione dell'SDK Android. Nello specifico, le implementazioni dei dispositivi DEVONO segnalare le dimensioni dello schermo corrette in pixel indipendenti dalla densità logica (dp) come indicato di seguito:
- I dispositivi con Configuration.uiMode impostato su un valore diverso da UI_MODE_TYPE_WATCH e che segnalano una dimensione small per Configuration.screenLayout DEVONO avere almeno 426 dp x 320 dp.
- I dispositivi che segnalano una dimensione normal per Configuration.screenLayout DEVONO avere almeno 480 dp x 320 dp.
- I dispositivi che segnalano una dimensione large per Configuration.screenLayout DEVONO avere almeno 640 dp x 480 dp.
- I dispositivi che segnalano una dimensione xlarge per Configuration.screenLayout DEVONO avere almeno 960 dp x 720 dp.
[C-0-2] DEVE rispettare correttamente il supporto dichiarato delle applicazioni per le dimensioni dello schermo tramite l'attributo <supports-screens> nel file AndroidManifest.xml, come descritto nella documentazione dell'SDK Android.
POTREBBE avere i display compatibili con Android con angoli arrotondati.

Se le implementazioni dei dispositivi supportano UI_MODE_TYPE_NORMAL e includono uno o più display compatibili con Android con angoli arrotondati:

[C-1-1] DEVE garantire che sia soddisfatto almeno uno dei seguenti requisiti:
Il raggio degli angoli arrotondati è inferiore o uguale a 38 dp.
Quando un riquadro di 15 dp x 15 dp è ancorato a ogni angolo del display logico, almeno un pixel di ogni riquadro è visibile sullo schermo.
DEVE includere la possibilità per l'utente di passare alla modalità di visualizzazione con gli angoli rettangolari.

Se le implementazioni del dispositivo includono uno o più display compatibili con Android che sono pieghevoli o includono una cerniera pieghevole tra più pannelli del display e rendono disponibili questi display per il rendering di app di terze parti,

[C-2-1] DEVE implementare l'ultima versione stabile disponibile dell'API Extensions o la versione stabile dell'API Sidecar da utilizzare con la libreria Window Manager Jetpack.

Se le implementazioni del dispositivo includono uno o più display compatibili con Android pieghevoli o una cerniera pieghevole tra più pannelli del display e se la cerniera o la piega attraversa una finestra dell'applicazione a schermo intero,

[C-3-1] DEVE segnalare la posizione, i limiti e lo stato della cerniera o della piega all'applicazione tramite estensioni o API sidecar.

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

7.1.1.2. Proporzioni dello schermo

Sebbene non vi siano restrizioni per le proporzioni del display fisico per i display compatibili con Android, le proporzioni del display logico in cui vengono visualizzate le app di terze parti, che possono essere derivate dai valori di altezza e larghezza riportati tramite le API view.Display e le API Configuration, DEVONO soddisfare i seguenti requisiti:

[C-0-1] Le implementazioni del dispositivo con Configuration.uiMode impostato su UI_MODE_TYPE_NORMAL DEVONO avere un valore delle 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 un rapporto di formato dello schermo più ampio tramite il valore dei metadati android.max_aspect.
- L'app dichiara di essere ridimensionabile tramite l'attributo android:resizeableActivity.
- L'app ha come target il livello API 24 o versioni successive e non dichiara un android:maxAspectRatio che limiterebbe le proporzioni consentite.
[C-0-2] Le implementazioni del dispositivo con Configuration.uiMode impostato su UI_MODE_TYPE_NORMAL DEVONO avere un valore del formato uguale o maggiore di 1,3333 (4:3), a meno che l'app non possa essere allargata soddisfacendo una delle seguenti condizioni:
- L'app dichiara di essere ridimensionabile tramite l'attributo android:resizeableActivity.
- L'app dichiara un android:minAspectRatio che limiterebbe le proporzioni consentite.
[C-0-3] Le implementazioni del dispositivo con Configuration.uiMode impostato su UI_MODE_TYPE_WATCH DEVONO avere un valore delle proporzioni impostato su 1.0 (1:1).

7.1.1.3. Densità schermo

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

[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 NON DEVE cambiare in nessun momento; tuttavia, il dispositivo PUÒ segnalare una densità arbitraria diversa in base alle modifiche alla configurazione del display apportate dall'utente (ad esempio, dimensioni di visualizzazione) impostate dopo l'avvio iniziale.
Le implementazioni del dispositivo DEVONO definire la densità standard del framework Android numericamente più vicina alla densità fisica dello schermo, a meno che questa densità logica non riduca le dimensioni dello schermo riportate al di sotto del minimo supportato. Se la densità del framework Android standard numericamente più vicina alla densità fisica comporta una dimensione dello schermo inferiore alla più piccola dimensione dello schermo compatibile supportata (larghezza di 320 dp), le implementazioni del dispositivo DEVONO segnalare la densità del framework Android standard più bassa successiva.

Se è presente un'opzione per modificare le dimensioni di visualizzazione del dispositivo:

[C-1-1] Le dimensioni di visualizzazione NON DEVONO essere scalate a un valore superiore a 1,5 volte la densità nativa o produrre una dimensione minima effettiva dello schermo inferiore a 320 dp (equivalente al qualificatore delle risorse sw320dp), a seconda di quale delle due condizioni si verifica per prima.
[C-1-2] Le dimensioni di visualizzazione NON DEVONO essere ridotte a meno di 0,85 volte la densità nativa.
Per garantire una buona usabilità e dimensioni dei caratteri coerenti, è CONSIGLIATO fornire il seguente ridimensionamento delle opzioni di visualizzazione nativa (rispettando i limiti specificati sopra)
Piccola: 0,85x
Valore predefinito: 1x (scala di visualizzazione nativa)
Large: 1,15x
Più grande: 1,3x
Più grande 1,45x

7.1.2. Metriche display

Se le implementazioni dei dispositivi includono il display o l'uscita video compatibili con Android sullo schermo del display compatibile con Android,

[C-1-1] DEVE segnalare i valori corretti per tutte le metriche di visualizzazione compatibili con Android definite nell'API android.util.DisplayMetrics.

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

[C-2-1] DEVE segnalare i valori corretti del display compatibile con Android come definito nell'API android.util.DisplayMetrics per view.Display predefinito emulato.

7.1.3. Orientamento schermo

Implementazioni del dispositivo:

[C-0-1] DEVE indicare gli orientamenti dello schermo supportati (android.hardware.screen.portrait e/o android.hardware.screen.landscape) e DEVE indicare almeno un orientamento supportato. Ad esempio, un dispositivo con uno schermo orizzontale a orientamento fisso, come una televisione o un laptop, DEVE segnalare solo android.hardware.screen.landscape.
[C-0-2] DEVE segnalare il valore corretto per l'orientamento attuale del dispositivo, ogni volta che viene eseguita una query tramite 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 in verticale o orizzontale. ovvero il dispositivo deve rispettare la richiesta dell'applicazione di un orientamento dello schermo specifico.
[C-1-2] NON DEVE modificare le dimensioni o la densità dello schermo segnalate quando cambia l'orientamento.
PUÒ selezionare l'orientamento verticale o orizzontale come predefinito.

7.1.4. Accelerazione grafica 2D e 3D

7.1.4.1 OpenGL ES

Implementazioni del dispositivo:

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

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

[C-1-1] DEVE supportare OpenGL ES 1.1 e 2.0, come descritto e dettagliato nella documentazione di SDK Android.
[C-SR] Are STRONGLY RECOMMENDED to support OpenGL ES 3.1.
DEVE supportare OpenGL ES 3.2.

Se le implementazioni dei dispositivi supportano una delle versioni di OpenGL ES:

[C-2-1] DEVE segnalare tramite le API gestite OpenGL ES e le API native qualsiasi altra estensione OpenGL ES che ha implementato e, viceversa, NON DEVE segnalare stringhe di estensione che non supporta.
[C-2-2] DEVE supportare le estensioni EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable e EGL_ANDROID_GLES_layers.
[C-SR] Sono VIVAMENTE CONSIGLIATI per supportare le estensioni EGL_KHR_partial_update e OES_EGL_image_external.
DEVE segnalare con precisione tramite il metodo getString() qualsiasi formato di compressione delle texture supportato, che in genere è specifico del fornitore.

Se le implementazioni dei dispositivi dichiarano il supporto di OpenGL ES 3.0, 3.1 o 3.2:

[C-3-1] MUST export the corresponding function symbols for these version in addition to the OpenGL ES 2.0 function symbols in the libGLESv2.so library.
[SR] Are STRONGLY RECOMMENDED to support the OES_EGL_image_external_essl3 extension.

Se le implementazioni dei dispositivi supportano OpenGL ES 3.2:

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

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

[C-5-1] DEVE identificare il supporto tramite il flag di funzionalità android.hardware.opengles.aep.

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

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

7.1.4.2 Vulkan

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

Se le implementazioni dei dispositivi supportano OpenGL ES 3.1:

[SR] È VIVAMENTE CONSIGLIATO includere il supporto di Vulkan 1.1.

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

DOVREBBE includere il supporto di Vulkan 1.1.

I test Vulkan dEQP sono suddivisi in un numero di elenchi di test, ognuno con una data/versione associata. Si trovano nell'albero delle origini Android in external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Un dispositivo che supporta Vulkan a un livello auto-dichiarato indica che può superare i test dEQP in tutti gli elenchi di test di questo livello e dei livelli precedenti.

Se le implementazioni dei dispositivi includono il supporto di Vulkan 1.0 o versioni successive:

[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 per ogni VkPhysicalDevice enumerato.
[C-1-4] DEVE enumerare i livelli contenuti nelle librerie native denominate libVkLayer*.so nella directory delle librerie native del pacchetto dell'applicazione tramite le API native Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties() .
[C-1-5] NON DEVE enumerare i livelli forniti dalle librerie al di fuori del pacchetto dell'applicazione o fornire altri modi per tracciare o intercettare l'API Vulkan, a meno che l'applicazione non abbia l'attributo android:debuggable impostato su true.
[C-1-6] DEVE segnalare tutte le stringhe di estensione che supporta tramite le API native Vulkan e, viceversa, NON DEVE segnalare le stringhe di estensione che non supporta correttamente.
[C-1-7] DEVE supportare le 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 di funzionalità android.software.vulkan.deqp.level.
[C-1-9] DEVE supportare almeno la versione 132317953 (dal 1° marzo 2019) come indicato nel flag della funzionalità android.software.vulkan.deqp.level.
[C-1-10] DEVE superare tutti i test dEQP Vulkan negli elenchi di test tra la versione 132317953 e la versione specificata nel flag funzionalità android.software.vulkan.deqp.level.
[C-SR] Sono FORTEMENTE CONSIGLIATE per supportare le estensioni VK_KHR_driver_properties e VK_GOOGLE_display_timing.

Se le implementazioni dei dispositivi non includono il supporto di Vulkan 1.0:

[C-2-1] NON DEVE dichiarare nessuno dei flag funzionalità Vulkan (ad es. android.hardware.vulkan.level, android.hardware.vulkan.version).
[C-2-2] NON DEVE enumerare alcun VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices().

Se le implementazioni dei dispositivi includono il supporto di Vulkan 1.1 e dichiarano uno qualsiasi dei flag di funzionalità Vulkan:

[C-3-1] MUST expose support for the SYNC_FD external semaphore and handle types and the VK_ANDROID_external_memory_android_hardware_buffer extension.

7.1.4.3 RenderScript

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

7.1.4.4 Accelerazione grafica 2D

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

Implementazioni del dispositivo:

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

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

Implementazioni del dispositivo:

[C-0-3] DEVE supportare l'API TextureView e DEVE mostrare un comportamento coerente con l'implementazione Android upstream.

7.1.4.5 Display con ampia gamma cromatica

Se le implementazioni dei dispositivi dichiarano il supporto per display ad ampia gamma tramite Configuration.isScreenWideColorGamut():

[C-1-1] DEVE avere un display con colori calibrati.
[C-1-2] DEVE avere un display la cui gamma copre interamente la gamma di colori sRGB nello spazio CIE 1931 xyY.
[C-1-3] DEVE avere un display la cui gamma ha un'area di almeno il 90% di DCI-P3 nello spazio CIE 1931 xyY.
[C-1-4] DEVE supportare OpenGL ES 3.1 o 3.2 e segnalarlo correttamente.
[C-1-5] DEVE pubblicizzare il supporto per le estensioni EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear e EGL_EXT_gl_colorspace_display_p3_passthrough.
[C-SR] Sono FORTEMENTE CONSIGLIATI per supportare GL_EXT_sRGB.

Al contrario, se le implementazioni dei dispositivi non supportano i display ad ampia gamma,

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

7.1.5. Modalità di compatibilità con le applicazioni legacy

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

7.1.6. Tecnologia dello schermo

La piattaforma Android include API che consentono alle applicazioni di eseguire il rendering di grafica avanzata su un display compatibile con Android. I dispositivi DEVONO supportare tutte queste API come definito dall'SDK Android, a meno che non sia specificamente consentito in questo documento.

Tutti i display compatibili con Android di un'implementazione del dispositivo:

[C-0-1] MUST be capable of rendering 16-bit color graphics.
DEVE supportare display in grado di visualizzare grafica a 24 bit.
[C-0-2] DEVE essere in grado di eseguire il rendering delle animazioni.
[C-0-3] DEVE avere proporzioni pixel (PAR) comprese tra 0,9 e 1,15. ovvero le proporzioni pixel DEVONO essere quasi quadrate (1.0) con una tolleranza del 10-15%.

7.1.7. Display secondari

Android include il supporto per display secondari compatibili con Android per attivare le funzionalità di condivisione dei contenuti multimediali e le API per sviluppatori per l'accesso a display esterni.

Se le implementazioni dei dispositivi supportano un display esterno tramite una connessione cablata, wireless o un'ulteriore connessione display incorporata:

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

7.2. Dispositivi di immissione

Implementazioni del dispositivo:

[C-0-1] DEVE includere un meccanismo di input, ad esempio un touchscreen o una navigazione non touch, per spostarsi tra gli elementi della UI.

7.2.1. Tastiera

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

[C-1-1] DEVE dichiarare il flag funzionalità android.software.input_methods.
[C-1-2] MUST implement fully Input Management Framework
[C-1-3] DEVE avere una tastiera su schermo preinstallata.

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

7.2.2. Navigazione non touch

Android include il supporto per il D-pad, la trackball e la rotella come meccanismi per la navigazione non touch.

Implementazioni del dispositivo:

[C-0-1] DEVE segnalare il valore corretto per android.content.res.Configuration.navigation.

Se le implementazioni dei dispositivi non prevedono navigazioni non touch:

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

7.2.3. Tasti di navigazione

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

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

Se vengono fornite le funzioni Home, Recenti o Indietro:

[C-1-1] DEVE essere accessibile con una singola azione (ad es. tocco, doppio clic o gesto) quando una qualsiasi di queste azioni è accessibile.
[C-1-2] DEVE fornire un'indicazione chiara di quale singola azione attiverebbe ogni funzione. Un'indicazione di questo tipo può essere un'icona visibile impressa sul pulsante, un'icona software nella parte della barra di navigazione dello schermo o una demo guidata passo passo durante la configurazione iniziale.

Implementazioni del dispositivo:

[SR] è FORTEMENTE CONSIGLIATO di non fornire il meccanismo di input per la funzione Menu, in quanto è deprecata a favore della barra delle azioni a partire da Android 4.0.

Se le implementazioni del dispositivo forniscono la funzione Menu:

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

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

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

Se le implementazioni dei dispositivi forniscono la funzione Assist,

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

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

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

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

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() DEVE essere utilizzato solo per segnalare l'area di riconoscimento del gesto Home.
[C-6-2] I gesti che iniziano all'interno di un rettangolo di esclusione fornito dall'applicazione in primo piano tramite View#setSystemGestureExclusionRects(), ma al di fuori di WindowInsets#getMandatorySystemGestureInsets(), NON DEVONO essere intercettati per la funzione di navigazione, a condizione che il rettangolo di esclusione sia consentito entro il limite massimo di esclusione specificato nella documentazione per View#setSystemGestureExclusionRects().
[C-6-3] DEVE inviare all'app in primo piano un evento MotionEvent.ACTION_CANCEL una volta che i tocchi iniziano a essere intercettati per un gesto di sistema, se all'app in primo piano è stato precedentemente inviato un evento MotionEvent.ACTION_DOWN.
[C-6-4] DEVE fornire un'interfaccia utente per passare a una navigazione sullo schermo basata su pulsanti (ad esempio, nelle Impostazioni).
DEVE fornire la funzione Home scorrendo verso l'alto dal bordo inferiore dell'orientamento corrente dello schermo.
DEVE fornire la funzione Recenti con uno scorrimento verso l'alto e una pressione prolungata prima del rilascio, dalla stessa area del gesto Home.
I gesti che iniziano entro WindowInsets#getMandatorySystemGestureInsets() NON DEVONO essere interessati dai rettangoli di esclusione forniti dall'applicazione in primo piano tramite View#setSystemGestureExclusionRects().

Se una funzione di navigazione viene fornita da qualsiasi punto dei bordi sinistro e destro dell'orientamento attuale dello schermo:

[C-7-1] La funzione di navigazione DEVE essere Indietro e deve essere fornita come scorrimento dai bordi sinistro e destro dell'orientamento attuale dello schermo.
[C-7-2] Se vengono forniti pannelli di sistema personalizzati scorrevoli sui bordi sinistro o destro, questi DEVONO essere posizionati nel terzo superiore dello schermo con un'indicazione visiva chiara e persistente che il trascinamento verso l'interno richiama i pannelli sopra menzionati e quindi non la funzionalità Indietro. Un pannello di sistema PUÒ essere configurato da un utente in modo che si trovi sotto il primo terzo del bordo o dei bordi dello schermo, ma NON deve occupare più di un terzo del bordo o dei bordi.
[C-7-3] Quando l'app in primo piano ha impostato i flag View.SYSTEM_UI_FLAG_IMMERSIVE o View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, lo scorrimento dai bordi DEVE comportarsi come implementato in AOSP, come documentato nell'SDK.
[C-7-4] Quando l'app in primo piano ha impostato i flag View.SYSTEM_UI_FLAG_IMMERSIVE o View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, i pannelli di sistema personalizzati scorrevoli DEVONO essere nascosti finché l'utente non visualizza le barre di sistema (ovvero la barra di navigazione e la barra di stato) come implementato in AOSP.

7.2.4. Input touchscreen

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

Implementazioni del dispositivo:

DEVE avere un sistema di input del puntatore di qualche tipo (simile al mouse o al tocco).
DEVE supportare puntatori tracciati in modo completamente indipendente.

Se le implementazioni del dispositivo includono un touchscreen (single-touch o migliore) su un display principale compatibile con Android:

[C-1-1] DEVE segnalare TOUCHSCREEN_FINGER per il campo API Configuration.touchscreen.
[C-1-2] DEVE segnalare i flag delle funzionalità android.hardware.touchscreen e android.hardware.faketouch.

Se le implementazioni dei dispositivi includono un touchscreen in grado di tracciare più di un tocco su un display principale compatibile con Android:

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

Se le implementazioni dei dispositivi si basano su un dispositivo di input esterno come 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 simulato nella sezione 7.2.5,

[C-3-1] NON DEVE segnalare alcun flag funzionalità che inizia con android.hardware.touchscreen.
[C-3-2] DEVE segnalare solo android.hardware.faketouch.
[C-3-3] DEVE segnalare TOUCHSCREEN_NOTOUCH per il campo API Configuration.touchscreen.

7.2.5. Input tocco simulato

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

Se le implementazioni del dispositivo non includono un touchscreen, ma includono un altro sistema di input del puntatore che vogliono rendere disponibile:

DEVE dichiarare il supporto per il flag della funzionalità android.hardware.faketouch.

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

[C-1-1] DEVE segnalare le posizioni assolute X e Y dello schermo della posizione del puntatore e visualizzare un puntatore visivo sullo schermo.
[C-1-2] DEVE segnalare l'evento tocco con il codice azione che specifica la modifica dello stato che si verifica quando il puntatore si sposta verso il basso o verso l'alto sullo schermo.
[C-1-3] DEVE supportare il puntatore verso il basso e verso l'alto su un oggetto sullo schermo, il che consente agli utenti di emulare il tocco di un oggetto sullo schermo.
[C-1-4] DEVE supportare il puntatore verso il basso, il puntatore verso l'alto, il puntatore verso il basso e poi verso l'alto nello stesso punto di un oggetto sullo schermo entro una soglia di tempo, il che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo.
[C-1-5] DEVE supportare il puntatore verso il basso su un punto arbitrario dello schermo, il movimento del puntatore verso un altro punto arbitrario dello schermo, seguito da un puntatore verso l'alto, che consente agli utenti di emulare un trascinamento con il tocco.
[C-1-6] DEVE supportare il puntatore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in una posizione diversa sullo schermo e poi il puntatore verso l'alto sullo schermo, il che consente agli utenti di lanciare un oggetto sullo schermo.

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

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

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

[C-3-1] DEVE dichiarare il supporto per android.hardware.faketouch.
[C-3-2] DEVE supportare il tracciamento distinto di 5 (tracciamento di una mano di dita) o più input del puntatore in modo completamente indipendente.

7.2.6. Supporto del controller di gioco

7.2.6.1. Mappature dei pulsanti

Implementazioni del dispositivo:

[C-1-1] DEVE essere in grado di mappare gli eventi HID alle costanti InputEvent corrispondenti elencate nelle tabelle seguenti. L'implementazione Android upstream soddisfa questo requisito.

Se le implementazioni dei dispositivi incorporano un controller o vengono spedite con un controller separato nella confezione che fornisce i mezzi per inserire tutti gli eventi elencati nelle tabelle seguenti:

[C-2-1] DEVE dichiarare il flag funzionalità android.hardware.gamepad

Pulsante	Utilizzo HID²	Pulsante Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad su¹ D-pad giù¹	0x01 0x0039³	AXIS_HAT_Y⁴
D-pad - Sinistra1 D-pad - Destra¹	0x01 0x0039³	AXIS_HAT_X⁴
Pulsante dorsale sinistro¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Pulsante dorsale destro¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic su levetta analogica sinistra¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic su levetta analogica destra¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Home¹	0x0c 0x0223	KEYCODE_HOME (3)
Indietro¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Gli utilizzi HID precedenti devono essere dichiarati all'interno di una CA Gamepad (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, unità in gradi e una dimensione report di 4. Il valore logico è definito come la rotazione in senso orario rispetto all'asse verticale. Ad esempio, un valore logico pari a 0 non rappresenta alcuna rotazione e indica la pressione del tasto Su, mentre un valore logico pari a 1 rappresenta una rotazione di 45 gradi e la pressione dei tasti Su e Sinistra.

4 MotionEvent

Controlli analogici¹	Utilizzo HID	Pulsante Android
Grilletto sinistro	0x02 0x00C5	AXIS_LTRIGGER
Grilletto destro	0x02 0x00C4	AXIS_RTRIGGER
Joystick sinistro	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick destro	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Telecomando

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

7.3. Sensori

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

Implementazioni del dispositivo:

[C-0-1] DEVE segnalare con precisione la presenza o l'assenza di sensori in base alla classe android.content.pm.PackageManager.
[C-0-2] DEVE restituire un elenco accurato dei sensori supportati tramite SensorManager.getSensorList() e metodi simili.
[C-0-3] DEVE comportarsi in modo ragionevole per tutte le altre API dei sensori (ad esempio, restituendo true o false a seconda dei casi quando le applicazioni tentano di registrare i listener, non chiamando 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:

[C-1-1] DEVE segnalare tutte le misurazioni dei sensori utilizzando i valori pertinenti del Sistema internazionale di unità di misura (metrico) per ogni tipo di sensore, come definito nella documentazione dell'SDK Android.
[C-1-2] DEVE segnalare i dati dei sensori con una latenza massima di 100 millisecondi + 2 * sample_time nel caso di un flusso di sensori con una latenza massima richiesta di 0 ms quando il processore dell'applicazione è attivo. Questo ritardo non include eventuali ritardi di filtraggio.
[C-1-3] DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time dall'attivazione del sensore. È accettabile che questo campione abbia una precisione pari a 0.
[C-1-4] Per qualsiasi API indicata dalla documentazione dell'SDK Android come sensore continuo, le implementazioni del dispositivo DEVONO fornire continuamente campioni di dati periodici che DOVREBBERO avere un jitter inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori timestamp segnalati tra eventi consecutivi.
[C-1-5] DEVE garantire che il flusso di eventi del sensore NON impedisca alla CPU del dispositivo di entrare in stato di sospensione o di riattivarsi da uno stato di sospensione.
[C-1-6] DEVE segnalare l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta l'ora in cui si è verificato l'evento e sincronizzata con l'orologio SystemClock.elapsedRealtimeNano().
[C-SR] Sono FORTEMENTE CONSIGLIATI per avere un errore di sincronizzazione del timestamp inferiore a 100 millisecondi e DOVREBBE avere un errore di sincronizzazione del timestamp inferiore a 1 millisecondo.
Quando vengono attivati più sensori, il consumo energetico NON DEVE superare la somma del consumo energetico segnalato di ogni sensore.

L'elenco riportato sopra non è esaustivo. Il comportamento documentato dell'SDK Android e delle documentazioni open source di Android sui sensori deve essere considerato autorevole.

Se le implementazioni dei dispositivi includono un particolare tipo di sensore con un'API corrispondente per sviluppatori di terze parti:

[C-1-6] DEVE impostare una risoluzione diversa da zero per tutti i sensori e segnalare il valore tramite il metodo API Sensor.getResolution().

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

Implementazioni del dispositivo:

DOVREBBE implementare questi tipi di sensori, quando includono i sensori fisici prerequisiti descritti in Tipi di sensori.

Se le implementazioni dei dispositivi includono un sensore composito:

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

Se le implementazioni del dispositivo includono un particolare tipo di sensore con un'API corrispondente per sviluppatori di terze parti e il sensore segnala un solo valore, le implementazioni del dispositivo:

[C-3-1] DEVE impostare la risoluzione su 1 per il sensore e segnalare il valore tramite il metodo API Sensor.getResolution().

Se le implementazioni del dispositivo includono un particolare tipo di sensore che supporta SensorAdditionalInfo#TYPE_VEC3_CALIBRATION e il sensore è esposto a sviluppatori di terze parti, questi:

[C-4-1] NON DEVE includere parametri di calibrazione fissi e determinati in fabbrica nei dati forniti.

Se le implementazioni dei dispositivi includono una combinazione di accelerometro a 3 assi, un sensore giroscopio a 3 assi o un sensore magnetometro, sono:

[C-SR] FORTEMENTE CONSIGLIATO per garantire che accelerometro, giroscopio e magnetometro abbiano una posizione relativa fissa, in modo che se il dispositivo è trasformabile (ad es. pieghevole), gli assi del sensore rimangano allineati e coerenti con il sistema di coordinate del sensore in tutti i possibili stati di trasformazione del dispositivo.

7.3.1. Accelerometro

Implementazioni del dispositivo:

[C-SR] È VIVAMENTE CONSIGLIATO includere un accelerometro a 3 assi.

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

[C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
[C-1-2] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER.
[C-1-3] DEVE rispettare il sistema di coordinate del sensore Android come descritto nelle API Android.
[C-1-4] DEVE essere in grado di misurare da caduta libera fino a quattro volte la gravità(4 g) o più su qualsiasi asse.
[C-1-5] DEVE avere una risoluzione di almeno 12 bit.
[C-1-6] DEVE avere una deviazione standard non superiore a 0,05 m/s^, dove la deviazione standard deve essere calcolata per asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più rapida.
[SR] è FORTEMENTE CONSIGLIATO implementare il sensore composito TYPE_SIGNIFICANT_MOTION.
[SR] are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. È FORTEMENTE CONSIGLIATO che i dispositivi Android soddisfino questo requisito, in modo che possano essere aggiornati alla futura release della piattaforma in cui questo potrebbe diventare OBBLIGATORIO.
DEVE implementare i sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento dell'SDK Android.
DEVE segnalare eventi fino ad almeno 200 Hz.
DOVREBBE avere una risoluzione di almeno 16 bit.
DEVE essere calibrato durante l'uso se le caratteristiche cambiano durante il ciclo di vita e compensato e conservare i parametri di compensazione tra i riavvii del dispositivo.
DEVE essere compensato in base alla temperatura.

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

[C-2-1] La somma del loro consumo energetico DEVE sempre essere inferiore a 4 mW.
DOVREBBE essere inferiore a 2 mW e 0,5 mW quando il dispositivo si trova in una condizione dinamica o statica.

Se le implementazioni dei dispositivi includono un accelerometro a 3 assi e un sensore giroscopio a 3 assi:

[C-3-1] DEVE implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
[C-SR] È 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:

[C-4-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

7.3.2. Magnetometro

Implementazioni del dispositivo:

[C-SR] È VIVAMENTE CONSIGLIATO includere un magnetometro a 3 assi (bussola).

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi:

[C-1-1] DEVE implementare il sensore TYPE_MAGNETIC_FIELD.
[C-1-2] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 10 Hz e DOVREBBE segnalare eventi fino ad almeno 50 Hz.
[C-1-3] DEVE rispettare il sistema di coordinate del sensore Android come descritto nelle API Android.
[C-1-4] DEVE essere in grado di misurare tra -900 µT e +900 µT su ogni asse prima di saturarsi.
[C-1-5] DEVE avere un valore di compensazione del ferro duro inferiore a 700 µT e DOVREBBE avere un valore inferiore a 200 µT posizionando il magnetometro lontano da campi magnetici dinamici (indotti dalla corrente) e statici (indotti dal magnete).
[C-1-6] DEVE avere una risoluzione uguale o più densa di 0,6 µT.
[C-1-7] DEVE supportare la calibrazione e la compensazione online della distorsione del ferro duro e conservare i parametri di compensazione tra i riavvii del dispositivo.
[C-1-8] DEVE essere applicata la compensazione del ferro dolce. La calibrazione può essere eseguita durante l'uso o la produzione del dispositivo.
[C-1-9] DEVE avere una deviazione standard, calcolata per asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più rapida, non superiore a 1,5 µT; DOVREBBE avere una deviazione standard non superiore a 0,5 µT.
[C-SR] È VIVAMENTE CONSIGLIATO di 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:

[C-2-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

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

MAY implement the TYPE_GEOMAGNETIC_ROTATION_VECTOR sensor.

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi, un accelerometro e un sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR:

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

7.3.3. GPS

Implementazioni del dispositivo:

[C-SR] È VIVAMENTE CONSIGLIATO includere un ricevitore GPS/GNSS.

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

[C-1-1] DEVE supportare gli output di posizione a una velocità di almeno 1 Hz quando richiesto tramite LocationManager#requestLocationUpdate.
[C-1-2] DEVE essere in grado di determinare la posizione in condizioni di cielo aperto (segnali forti, multipath trascurabile, HDOP < 2) entro 10 secondi (tempo di acquisizione rapido), quando è connesso a una connessione a internet con velocità dati pari o superiore a 0,5 Mbps. Questo requisito viene in genere soddisfatto utilizzando una qualche forma di tecnica GPS/GNSS assistita o predittiva per ridurre al minimo il tempo di acquisizione del segnale GPS/GNSS (i dati di assistenza includono l'ora di riferimento, la posizione di riferimento e l'effemeride/l'orologio del satellite).
- [C-1-6] Dopo aver eseguito il calcolo della posizione, le implementazioni del dispositivo DEVONO determinare 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 quando la richiesta successiva viene effettuata senza una connessione dati e/o dopo un ciclo di accensione.
In condizioni di cielo aperto dopo aver determinato la posizione, da fermo o in movimento con un'accelerazione inferiore a 1 metro al secondo quadrato:
- [C-1-3] DEVE essere in grado di determinare la posizione entro 20 metri e la velocità entro 0,5 metri al secondo almeno il 95% delle volte.
- [C-1-4] DEVE tracciare e segnalare simultaneamente tramite GnssStatus.Callback almeno 8 satelliti di una costellazione.
- DEVE essere in grado di monitorare simultaneamente almeno 24 satelliti di più costellazioni (ad es. GPS + almeno una tra Glonass, Beidou, Galileo).
- [C-SR] È FORTEMENTE CONSIGLIATO di continuare a fornire normali output di posizione GPS/GNSS tramite le API del fornitore di servizi di localizzazione GNSS durante una chiamata di emergenza.
- [C-SR] È VIVAMENTE CONSIGLIATO segnalare le misurazioni GNSS di tutte le costellazioni monitorate (come riportato nei messaggi GnssStatus), ad eccezione di SBAS.
- [C-SR] È VIVAMENTE CONSIGLIATO di segnalare AGC e frequenza di misurazione GNSS.
- [C-SR] È VIVAMENTE CONSIGLIATO di segnalare tutte le stime di accuratezza (inclusi orientamento, velocità e verticale) nell'ambito di ogni posizione GPS/GNSS.
- [C-SR] È VIVAMENTE CONSIGLIATO segnalare le misurazioni GNSS non appena vengono trovate, anche se una posizione calcolata dal GPS/GNSS non è ancora stata segnalata.
- [C-SR] È FORTEMENTE CONSIGLIATO segnalare le pseudodistanze e le velocità di pseudodistanza GNSS che, in condizioni di cielo aperto dopo aver determinato la posizione, da fermo o in movimento con un'accelerazione inferiore a 0, 2 metri al secondo quadrato, sono sufficienti per calcolare la posizione entro 20 metri e la velocità entro 0, 2 metri al secondo, almeno il 95% delle volte.

7.3.4. Giroscopio

Implementazioni del dispositivo:

[C-SR] È VIVAMENTE CONSIGLIATO includere un sensore giroscopico.

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

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

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

[C-2-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

Se le implementazioni dei dispositivi includono un accelerometro a 3 assi e un sensore giroscopio a 3 assi:

[C-3-1] DEVE implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
[C-SR] È VIVAMENTE CONSIGLIATO di implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometro

Implementazioni del dispositivo:

[C-SR] È VIVAMENTE CONSIGLIATO di includere un barometro (sensore di pressione dell'aria ambiente).

Se le implementazioni del dispositivo includono un barometro:

[C-1-1] DEVE implementare e segnalare il sensore TYPE_PRESSURE.
[C-1-2] DEVE essere in grado di fornire eventi a 5 Hz o superiore.
[C-1-3] DEVE essere compensato in temperatura.
[SR] VIVAMENTE CONSIGLIATO per poter segnalare misurazioni della pressione nell'intervallo compreso tra 300 hPa e 1100 hPa.
DOVREBBE avere una precisione assoluta di 1 hPa.
DOVREBBE avere una precisione relativa di 0,12 hPa in un intervallo di 20 hPa (equivalente a una precisione di circa 1 m in una variazione di circa 200 m a livello del mare).

7.3.6. Termometro

Se le implementazioni dei dispositivi includono un termometro ambientale (sensore di temperatura):

[C-1-1] DEVE definire SENSOR_TYPE_AMBIENT_TEMPERATURE per il sensore di temperatura ambiente e il sensore DEVE misurare la temperatura ambiente (stanza/abitacolo del veicolo) da dove l'utente interagisce con il dispositivo in gradi Celsius.

Se le implementazioni dei dispositivi includono un sensore termometro che misura una temperatura diversa da quella ambiente, ad esempio la temperatura della CPU:

[C-2-1] NON DEVE definire SENSOR_TYPE_AMBIENT_TEMPERATURE per il sensore di temperatura.

7.3.7. Fotometro

Le implementazioni del dispositivo POSSONO includere un fotometro (sensore della luce ambientale).

7.3.8. Sensore di prossimità

Le implementazioni del dispositivo POSSONO includere un sensore di prossimità.

Se le implementazioni dei dispositivi includono un sensore di prossimità:

[C-1-1] DEVE misurare la prossimità di un oggetto nella stessa direzione dello schermo. ovvero il sensore di prossimità DEVE essere orientato in modo da rilevare gli oggetti vicini allo schermo, poiché lo scopo principale di questo tipo di sensore è rilevare un telefono in uso da parte dell'utente. Se le implementazioni del dispositivo includono un sensore di prossimità con un altro orientamento, NON DEVE essere accessibile tramite questa API.
[C-1-2] DEVE avere una precisione di almeno 1 bit.

7.3.9. Sensori ad alta fedeltà

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

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

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

[C-2-1] DEVE avere un sensore TYPE_ACCELEROMETER che:
- DEVE avere un intervallo di misurazione compreso tra almeno -8 g e +8 g ed è FORTEMENTE CONSIGLIATO che abbia un intervallo di misurazione compreso tra almeno -16 g e +16 g.
- DEVE avere una risoluzione di misurazione di almeno 2048 LSB/g.
- DEVE avere una frequenza di misurazione minima di 12,5 Hz o inferiore.
- DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DOVREBBE supportare SensorDirectChannel RATE_VERY_FAST.
- DEVE avere un rumore di misurazione non superiore a 400 μg/√Hz.
- DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore.
- DEVE avere un consumo energetico di batching non superiore a 3 mW.
- [C-SR] È VIVAMENTE CONSIGLIATO di avere una larghezza di banda di misurazione di 3 dB di almeno l'80% della frequenza di Nyquist e uno spettro di rumore bianco all'interno di questa larghezza di banda.
- DEVE avere una passeggiata casuale di accelerazione inferiore a 30 μg √Hz testata a temperatura ambiente.
- DOVREBBE avere una variazione della distorsione rispetto alla temperatura di ≤ +/- 1 mg/°C.
- DOVREBBE avere una non linearità della linea di migliore adattamento ≤ 0,5% e una variazione della sensibilità rispetto alla temperatura ≤ 0,03%/°C.
- DOVREBBE avere una sensibilità all'asse trasversale < 2,5 % e una variazione della sensibilità all'asse trasversale < 0,2% nell'intervallo di temperatura di funzionamento del dispositivo.
[C-2-2] DEVE avere un TYPE_ACCELEROMETER_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_ACCELEROMETER.
[C-2-3] DEVE avere un sensore TYPE_GYROSCOPE che:
- DEVE avere un intervallo di misurazione compreso tra almeno -1000 e +1000 dps.
- DEVE avere una risoluzione di misurazione di almeno 16 LSB/dps.
- DEVE avere una frequenza di misurazione minima di 12,5 Hz o inferiore.
- DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DOVREBBE supportare SensorDirectChannel RATE_VERY_FAST.
- DEVE avere un rumore di misurazione non superiore a 0,014°/s/√Hz.
- [C-SR] È VIVAMENTE CONSIGLIATO di avere una larghezza di banda di misurazione di 3 dB di almeno l'80% della frequenza di Nyquist e uno spettro di rumore bianco all'interno di questa larghezza di banda.
- DEVE avere una passeggiata casuale della velocità inferiore a 0,001 °/s √Hz testata a temperatura ambiente.
- DOVREBBE avere una variazione di polarizzazione rispetto alla temperatura ≤ +/- 0,05 °/ s / °C.
- DOVREBBE avere una variazione di sensibilità rispetto alla temperatura ≤ 0,02% / °C.
- DEVE avere una non linearità della linea di miglior adattamento ≤ 0,2%.
- DEVE avere una densità di rumore ≤ 0,007 °/s/√Hz.
- DOVREBBE avere un errore di calibrazione inferiore a 0,002 rad/s nell'intervallo di temperatura 10 ~ 40 °C quando il dispositivo è fermo.
- DEVE avere una sensibilità all'accelerazione inferiore a 0,1 °/s/g.
- DEVE avere una sensibilità all'asse trasversale < 4,0 % e una variazione della sensibilità all'asse trasversale < 0,3% nell'intervallo di temperatura di funzionamento del dispositivo.
[C-2-4] DEVE avere un TYPE_GYROSCOPE_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GYROSCOPE.
[C-2-5] DEVE avere un sensore TYPE_GEOMAGNETIC_FIELD che:
- DEVE avere un intervallo di misurazione compreso tra almeno -900 e +900 μT.
- DEVE avere una risoluzione di misurazione di almeno 5 LSB/uT.
- DEVE avere una frequenza di misurazione minima di 5 Hz o inferiore.
- DEVE avere una frequenza di misurazione massima di 50 Hz o superiore.
- DEVE avere un rumore di misurazione non superiore a 0,5 μT.
[C-2-6] DEVE avere un TYPE_MAGNETIC_FIELD_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GEOMAGNETIC_FIELD e, inoltre:
- DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 600 eventi del sensore.
- [C-SR] È VIVAMENTE CONSIGLIATO di avere uno spettro di rumore bianco da 1 Hz ad almeno 10 Hz quando la frequenza di segnalazione è pari o superiore a 50 Hz.
[C-2-7] DEVE avere un sensore TYPE_PRESSURE che:
- DEVE avere un intervallo di misurazione compreso tra almeno 300 e 1100 hPa.
- DEVE avere una risoluzione di misurazione di almeno 80 LSB/hPa.
- DEVE avere una frequenza di misurazione minima di 1 Hz o inferiore.
- DEVE avere una frequenza di misurazione massima di 10 Hz o superiore.
- DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz.
- DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
- DEVE avere un consumo energetico di batching non superiore a 2 mW.
[C-2-8] DEVE avere un sensore TYPE_GAME_ROTATION_VECTOR.
[C-2-9] DEVE avere un sensore TYPE_SIGNIFICANT_MOTION che:
- DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
[C-2-10] DEVE avere un sensore TYPE_STEP_DETECTOR che:
- DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 100 eventi del sensore.
- DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
- DEVE avere un consumo energetico di batching non superiore a 4 mW.
[C-2-11] DEVE avere un sensore TYPE_STEP_COUNTER che:
- DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
[C-2-12] DEVE avere un sensore TILT_DETECTOR che:
- DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
[C-2-13] Il timestamp dell'evento fisico segnalato da accelerometro, giroscopio e magnetometro DEVE essere compreso in un intervallo di 2, 5 millisecondi. Il timestamp dell'evento fisico riportato dall'accelerometro e dal giroscopio DEVE essere compreso entro 0,25 millisecondi l'uno dall'altro.
[C-2-14] I timestamp degli eventi del sensore giroscopio DEVONO essere basati sullo stesso orologio del sottosistema della videocamera e con un errore di 1 millisecondo.
[C-2-15] DEVE fornire campioni alle applicazioni entro 5 millisecondi dal momento in cui i dati sono disponibili per l'applicazione su uno qualsiasi dei sensori fisici sopra indicati.
[C-2-16] NON DEVE avere un consumo energetico superiore a 0,5 mW quando il dispositivo è statico e a 2,0 mW quando il dispositivo è in movimento quando è abilitata una qualsiasi combinazione dei seguenti sensori:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] POTREBBE avere un sensore TYPE_PROXIMITY, ma se presente DEVE avere una capacità di buffer minima di 100 eventi del sensore.

Tieni presente che tutti i requisiti di consumo energetico in questa sezione non includono il consumo energetico del processore dell'applicazione. Include la potenza assorbita dall'intera catena di sensori: il sensore, qualsiasi circuito di supporto, qualsiasi sistema di elaborazione dei sensori dedicato e così via.

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

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

7.3.10. Sensori biometrici

Per ulteriori informazioni sulla misurazione della sicurezza dello sblocco biometrico, consulta la documentazione sulla misurazione della sicurezza biometrica.

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

DEVE includere un sensore biometrico

I sensori biometrici possono essere classificati come Classe 3 (in precedenza Forte), Classe 2 (in precedenza Debole) o Classe 1 (in precedenza Comodità) in base ai tassi di accettazione di spoofing e impostori e alla sicurezza della pipeline biometrica. Questa classificazione determina le funzionalità che il sensore biometrico deve interfacciare con la piattaforma e con le applicazioni di terze parti. I sensori sono classificati come Classe 1 per impostazione predefinita e devono soddisfare requisiti aggiuntivi, come descritto di seguito, se vogliono essere classificati come Classe 2 o Classe 3. Le biometrie di Classe 2 e Classe 3 ottengono funzionalità aggiuntive, come descritto di seguito.

Se le implementazioni del dispositivo rendono disponibile un sensore biometrico ad applicazioni di terze parti tramite android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, queste:

[C-4-1] DEVE soddisfare i requisiti per la biometria di Classe 3 o Classe 2, come definito in questo documento.
[C-4-2] DEVE riconoscere e rispettare ogni nome di parametro definito come costante nella classe Authenticators e qualsiasi combinazione. Al contrario, NON DEVE rispettare o riconoscere le costanti intere trasmesse ai metodi canAuthenticate(int) e setAllowedAuthenticators(int) diversi da quelli documentati come costanti pubbliche in Authenticators e qualsiasi loro combinazione.
[C-4-3] DEVE implementare l'intent ACTION_BIOMETRIC_ENROLL sui dispositivi con biometria di classe 3 o classe 2. Questa azione DEVE presentare solo i punti di accesso alla registrazione per la biometria di classe 3 o classe 2.

Se le implementazioni dei dispositivi supportano la biometria passiva:

[C-5-1] PER IMPOSTAZIONE PREDEFINITA DEVE richiedere un passaggio di conferma aggiuntivo (ad es. la pressione di un pulsante).
[C-SR] È VIVAMENTE CONSIGLIATO di avere un'impostazione che consenta agli utenti di ignorare la preferenza dell'applicazione e richiedere sempre un passaggio di conferma.
[C-SR] È FORTEMENTE CONSIGLIATO proteggere l'azione di conferma in modo che non possa essere falsificata da una compromissione del sistema operativo o del kernel. Ad esempio, ciò significa che l'azione di conferma basata su un pulsante fisico viene indirizzata tramite un pin di input/output (GPIO) per uso generico solo di input di un Secure Element (SE) che non può essere azionato in altro modo se non premendo un pulsante fisico.
[C-5-2] DEVE inoltre implementare un flusso di autenticazione implicito (senza passaggio di conferma) corrispondente a setConfirmationRequired(boolean), che le applicazioni possono impostare per l'utilizzo nei flussi di accesso.

Se le implementazioni dei dispositivi hanno più sensori biometrici:

[C-SR] È VIVAMENTE CONSIGLIATO di richiedere la conferma di una sola biometria per autenticazione (ad es. se sul dispositivo sono disponibili sensori per l'impronta e il volto, onAuthenticationSucceeded deve essere inviato dopo la conferma di uno dei due).

Affinché le implementazioni dei dispositivi consentano l'accesso alle chiavi del keystore ad applicazioni di terze parti, devono:

[C-6-1] DEVE soddisfare i requisiti per la classe 3 definiti nella sezione seguente.
[C-6-2] DEVE presentare solo dati biometrici di classe 3 quando l'autenticazione richiede BIOMETRIC_STRONG o quando l'autenticazione viene richiamata con un CryptoObject.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 1 (in precedenza Comodità), devono:

[C-1-1] DEVE avere un tasso di falsa accettazione inferiore allo 0,002%.
[C-1-2] DEVE comunicare che questa modalità potrebbe essere meno sicura di un PIN, una sequenza o una password efficaci ed elencare chiaramente i rischi della sua attivazione, se i tassi di accettazione di spoofing e impostori sono superiori al 7%, come misurato dai protocolli di test biometrici di Android.
[C-1-3] DEVE limitare la frequenza dei tentativi per almeno 30 secondi dopo cinque tentativi errati di verifica biometrica, dove un tentativo errato è uno con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a una biometria registrata.
[C-1-4] DEVE impedire l'aggiunta di nuove biometrie senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare le credenziali del dispositivo esistenti o di aggiungerne di nuove (PIN/sequenza/password) protette da TEE; l'implementazione di Android Open Source Project fornisce il meccanismo nel framework per farlo.
[C-1-5] DEVE rimuovere completamente tutti i dati biometrici identificabili di un utente quando il suo account viene rimosso (anche tramite un ripristino dei dati di fabbrica).
[C-1-6] DEVE rispettare il flag individuale per quella biometria (ad es. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE o DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
[C-1-7] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) una volta ogni 24 ore o meno per i nuovi dispositivi con Android 10 e una volta ogni 72 ore o meno per i dispositivi che eseguono l'upgrade da una versione precedente di Android.
[C-1-8] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) dopo uno dei seguenti eventi:
- un periodo di timeout di inattività di 4 ore OPPURE
- 3 tentativi di autenticazione biometrica non riusciti.
- Il periodo di timeout di inattività e il conteggio dei tentativi di autenticazione non riusciti vengono reimpostati dopo qualsiasi conferma riuscita delle credenziali del dispositivo.
L'upgrade dei dispositivi da una versione precedente di Android può essere esentato dal punto C-1-8. * [C-SR] È FORTEMENTE CONSIGLIATO di utilizzare la logica nel framework fornito da Android Open Source Project per applicare i vincoli specificati in [C-1-7] e [C-1-8] per i nuovi dispositivi. * [C-SR] Sono FORTEMENTE CONSIGLIATI per avere un tasso di rifiuto errato inferiore al 10%, misurato sul dispositivo. * [C-SR] È FORTEMENTE CONSIGLIATO che abbiano una latenza inferiore a 1 secondo, misurata dal momento in cui viene rilevata la biometria fino allo sblocco dello schermo, per ogni biometria registrata.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 2 (in precedenza Debole), devono:

[C-2-1] DEVE soddisfare tutti i requisiti per la classe 1 sopra indicati.
[C-2-2] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 20%, misurato dai protocolli di test biometrici di Android.
[C-2-3] DEVE eseguire la corrispondenza biometrica in un ambiente di esecuzione isolato al di fuori dello spazio utente o del kernel Android, ad esempio il Trusted Execution Environment (TEE), o su un chip con un canale sicuro per l'ambiente di esecuzione isolato.
[C-2-4] DEVE avere tutti i dati identificabili criptati e autenticati crittograficamente in modo che non possano essere acquisiti, letti o alterati al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro per l'ambiente di esecuzione isolato, come documentato nelle linee guida per l'implementazione sul sito del progetto Android Open Source.
[C-2-5] Per la biometria basata sulla videocamera, durante l'autenticazione o la registrazione biometrica:
- DEVE utilizzare la videocamera in una modalità che impedisca la lettura o l'alterazione dei frame della videocamera al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro per l'ambiente di esecuzione isolato.
- Per le soluzioni RGB a singola videocamera, i frame della videocamera POSSONO essere leggibili al di fuori dell'ambiente di esecuzione isolato per supportare operazioni come l'anteprima per la registrazione, ma NON DEVONO comunque essere modificabili.
[C-2-6] NON DEVE consentire alle applicazioni di terze parti di distinguere tra 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 (ad esempio incorporamenti) al processore dell'applicazione al di fuori del contesto del TEE.
[C-2-8] DEVE disporre di una pipeline di elaborazione sicura in modo che la compromissione di un sistema operativo o di un kernel non possa consentire l'inserimento diretto di dati per l'autenticazione fraudolenta come utente.

Se le implementazioni dei dispositivi sono già state lanciate su una versione precedente di Android e non possono soddisfare il requisito C-2-8 tramite un aggiornamento del software di sistema, POSSONO essere esentate dal requisito.
[C-SR] È VIVAMENTE CONSIGLIATO includere il rilevamento della vitalità per tutte le modalità biometriche e il rilevamento dell'attenzione per la biometria del volto.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 3 (in precedenza Forte), devono:

[C-3-1] DEVE soddisfare tutti i requisiti della classe 2 sopra, ad eccezione di [C-1-7] e [C-1-8]. L'upgrade dei dispositivi da una versione precedente di Android non è esente dal punto C-2-7.
[C-3-2] DEVE avere un'implementazione di un keystore basato su hardware.
[C-3-3] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 7%, misurato dai protocolli di test biometrici di Android.
[C-3-4] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) una volta ogni 72 ore o meno.

7.3.12. Sensore di postura

Implementazioni del dispositivo:

POTREBBE supportare il sensore di postura con 6 gradi di libertà.

Se le implementazioni dei dispositivi supportano il sensore di postura con 6 gradi di libertà:

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

7.3.13. Sensore dell'angolo della cerniera

Se le implementazioni dei dispositivi supportano un sensore dell'angolo della cerniera:

[C-1-1] DEVE implementare e segnalare TYPE_HINGLE_ANGLE.
[C-1-2] DEVE supportare almeno due letture tra 0 e 360 gradi (inclusi 0 e 360 gradi).
[C-1-3] DEVE restituire un sensore di riattivazione per getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.4. Connettività dei dati

7.4.1. Telefonia

Il termine "telefonia" utilizzato dalle API Android e in questo documento si riferisce in modo specifico all'hardware correlato all'effettuazione di chiamate vocali e all'invio di messaggi SMS tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano o meno essere a commutazione di pacchetto, ai fini di Android sono considerate indipendenti da qualsiasi connettività dati che possa essere implementata utilizzando la stessa rete. In altre parole, le funzionalità e le API "telefonia" di Android si riferiscono specificamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni di dispositivi che non possono effettuare chiamate o inviare/ricevere SMS non sono considerate dispositivi di telefonia, indipendentemente dal fatto che utilizzino una rete cellulare per la connettività dati.

Android PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. ovvero Android è compatibile con dispositivi diversi dagli smartphone.

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

[C-1-1] DEVE dichiarare il flag funzionalità android.hardware.telephony e altri flag delle funzionalità secondarie in base alla tecnologia.
[C-1-2] DEVE implementare il supporto completo per l'API per quella tecnologia.

Se le implementazioni dei dispositivi non includono hardware di telefonia:

[C-2-1] DEVE implementare le API complete come no-op.

Se le implementazioni dei dispositivi supportano eUICC o eSIM/SIM integrate e includono un meccanismo proprietario per rendere disponibile la funzionalità eSIM per gli sviluppatori di terze parti:

[C-3-1] DEVE fornire un'implementazione completa di EuiccManager API.

7.4.1.1. Compatibilità con il blocco dei numeri

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

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

7.4.1.2. API Telecom

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

[C-1-1] DEVE supportare le API ConnectionService descritte nell'SDK.
[C-1-2] DEVE mostrare una nuova chiamata in arrivo e fornire all'utente la possibilità di accettarla o rifiutarla 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] È FORTEMENTE CONSIGLIATO notificare all'utente che rispondere a una chiamata in arrivo interromperà una chiamata in corso.

L'implementazione AOSP soddisfa questi requisiti tramite una notifica in evidenza che indica all'utente che se risponde a una chiamata in arrivo, l'altra chiamata verrà interrotta.
[C-SR] È VIVAMENTE CONSIGLIATO precaricare l'app Telefono predefinita che mostra una voce del registro chiamate e il nome di un'app di terze parti nel registro chiamate quando l'app di terze parti imposta il tasto degli extra EXTRA_LOG_SELF_MANAGED_CALLS nel suo PhoneAccount su true.
[C-SR] È VIVAMENTE CONSIGLIATO di gestire gli eventi KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK delle cuffie audio per le API android.telecom come indicato di seguito:
- Chiama Connection.onDisconnect() quando viene rilevata una pressione breve dell'evento chiave durante una chiamata in corso.
- Chiama Connection.onAnswer() quando viene rilevata una pressione breve dell'evento chiave durante una chiamata in arrivo.
- Chiama Connection.onReject() quando viene rilevata una pressione prolungata dell'evento chiave durante una chiamata in arrivo.
- Attiva/disattiva lo stato di disattivazione dell'audio di CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementazioni del dispositivo:

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

Se le implementazioni del dispositivo includono il supporto di 802.11 ed espongono la funzionalità a un'applicazione di terze parti:

[C-1-1] DEVE implementare l'API Android corrispondente.
[C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.wifi.
[C-1-3] DEVE implementare l'API multicast come descritto nella documentazione dell'SDK.
[C-1-4] DEVE supportare il DNS multicast (mDNS) e NON DEVE filtrare i pacchetti mDNS (224.0.0.251) in qualsiasi momento del funzionamento, tra cui:
- Anche quando lo schermo non è in stato attivo.
- Per le implementazioni di dispositivi Android Television, anche in modalità di alimentazione in standby.
[C-1-5] NON DEVE considerare la chiamata al metodo API WifiManager.enableNetwork() come indicazione sufficiente per cambiare l'Network attualmente attivo, utilizzato per impostazione predefinita per il traffico dell'applicazione e restituito dai metodi API ConnectivityManager come getActiveNetwork e registerDefaultNetworkCallback. In altre parole, POSSONO disattivare l'accesso a internet fornito da qualsiasi altro operatore di rete (ad es. dati mobili) solo se verificano correttamente che la rete Wi-Fi fornisce l'accesso a internet.
[C-1-6] È FORTEMENTE CONSIGLIATO di, quando viene chiamato il metodo API ConnectivityManager.reportNetworkConnectivity(), rivalutare l'accesso a internet sul Network e, una volta che la valutazione determina che l'attuale Network non fornisce più l'accesso a internet, passare a qualsiasi altra rete disponibile (ad es. dati mobili) che fornisca l'accesso a internet.
[C-SR] È FORTEMENTE CONSIGLIATO di randomizzare l'indirizzo MAC di origine e il numero di sequenza dei frame di richiesta di probe, una volta all'inizio di ogni scansione, mentre la STA è disconnessa.
- Ogni gruppo di frame di richiesta di probe che comprende una scansione deve utilizzare un indirizzo MAC coerente (NON deve randomizzare l'indirizzo MAC a metà scansione).
- Il numero di sequenza della richiesta di probe deve essere iterato normalmente (in sequenza) tra le richieste di probe in una scansione.
- Il numero di sequenza della richiesta di probe deve essere randomizzato tra l'ultima richiesta di probe di una scansione e la prima richiesta di probe della scansione successiva.
[C-SR] Sono FORTEMENTE CONSIGLIATI, mentre STA è disconnesso, per consentire solo i seguenti elementi nei frame delle richieste di probe:
- Set di parametri SSID (0)
- Set di parametri DS (3)

Se le implementazioni dei dispositivi includono il supporto della modalità di risparmio energetico Wi-Fi come definita nello standard IEEE 802.11,

[C-3-1] DEVE disattivare la modalità di risparmio energetico del Wi-Fi ogni volta che un'app acquisisce il blocco WIFI_MODE_FULL_HIGH_PERF o WIFI_MODE_FULL_LOW_LATENCY tramite le API WifiManager.createWifiLock() e WifiManager.WifiLock.acquire() e il blocco è attivo.
[C-3-2] La latenza media di andata e ritorno tra il dispositivo e un punto di accesso mentre il dispositivo è in modalità di blocco Wi-Fi a bassa latenza (WIFI_MODE_FULL_LOW_LATENCY) DEVE essere inferiore alla latenza durante la modalità di blocco Wi-Fi ad alte prestazioni (WIFI_MODE_FULL_HIGH_PERF).
[C-SR] Sono FORTEMENTE CONSIGLIATI per ridurre al minimo la latenza di andata e ritorno del Wi-Fi ogni volta che viene acquisita e ha effetto una serratura a bassa latenza (WIFI_MODE_FULL_LOW_LATENCY).

Se le implementazioni dei dispositivi supportano il Wi-Fi e lo utilizzano per la scansione della posizione:

[C-2-1] DEVE fornire un'interfaccia utente per attivare/disattivare la lettura del valore tramite il metodo API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementazioni del dispositivo:

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

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

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

7.4.2.2. Configurazione di Wi-Fi Tunneled Direct Link

Implementazioni del dispositivo:

DEVE includere il supporto per la configurazione del collegamento diretto con tunneling Wi-Fi (TDLS), come descritto nella documentazione dell'SDK Android.

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

[C-1-1] DEVE dichiarare il supporto di TDLS tramite WifiManager.isTdlsSupported.
DEVE utilizzare TDLS solo quando è possibile E vantaggioso.
DOVREBBE utilizzare alcune euristiche e NON utilizzare TDLS quando le sue prestazioni potrebbero essere peggiori rispetto a quelle del punto d'accesso Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementazioni del dispositivo:

DEVE includere il supporto per Wi-Fi Aware.

Se le implementazioni del dispositivo includono il supporto di Wi-Fi Aware ed espongono la funzionalità ad app di terze parti, allora:

[C-1-1] DEVE implementare le API WifiAwareManager come descritto nella documentazione dell'SDK.
[C-1-2] DEVE dichiarare il flag funzionalità android.hardware.wifi.aware.
[C-1-3] DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Aware.
[C-1-4] DEVE randomizzare l'indirizzo dell'interfaccia di gestione Wi-Fi Aware a intervalli non superiori a 30 minuti e ogni volta che Wi-Fi Aware è attivato, a meno che non sia in corso un'operazione di misurazione della distanza Aware o un percorso dati Aware sia attivo (la randomizzazione non è prevista finché il percorso dati è attivo).

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Aware e della posizione Wi-Fi come descritto nella Sezione 7.4.2.5 ed espongono queste funzionalità ad app di terze parti, allora:

[C-2-1] DEVE implementare le API di rilevamento basate sulla posizione: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

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

DEVE includere il supporto per Wi-Fi Passpoint.

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

[C-1-2] DEVE implementare le API WifiManager correlate a Passpoint come descritto nella documentazione dell'SDK.
[C-1-3] DEVE supportare lo standard IEEE 802.11u, in particolare per quanto riguarda l'individuazione e la selezione della rete, ad esempio il servizio di pubblicità generica (GAS) e il protocollo di query della rete di accesso (ANQP).

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

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

7.4.2.5. Posizione Wi-Fi (tempo di round trip - RTT - del Wi-Fi)

Implementazioni del dispositivo:

DEVE includere il supporto per la posizione Wi-Fi.

Se le implementazioni del dispositivo includono il supporto della posizione Wi-Fi ed espongono la funzionalità ad app di terze parti, allora:

[C-1-1] DEVE implementare le API WifiRttManager come descritto nella documentazione dell'SDK.
[C-1-2] DEVE dichiarare il flag funzionalità android.hardware.wifi.rtt.
[C-1-3] DEVE randomizzare l'indirizzo MAC di origine per ogni burst RTT eseguito mentre l'interfaccia Wi-Fi su cui viene eseguito l'RTT non è associata a un punto di accesso.

7.4.2.6. Wi-Fi Keepalive Offload

Implementazioni del dispositivo:

DEVE includere il supporto per l'offload di Wi-Fi Keepalive.

Se le implementazioni del dispositivo includono il supporto per l'offload di Wi-Fi Keepalive ed espongono la funzionalità ad app di terze parti:

[C-1-1] DEVE supportare l'API SocketKeepAlive.
[C-1-2] DEVE supportare almeno tre slot keepalive simultanei tramite Wi-Fi e almeno uno slot keepalive tramite rete cellulare.

Se le implementazioni dei dispositivi non includono il supporto per l'offload di Wi-Fi Keepalive,

[C-2-1] MUST return ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocollo di provisioning dei dispositivi)

Implementazioni del dispositivo:

DEVE includere il supporto per Wi-Fi Easy Connect (DPP).

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

[C-1-1] DEVE restituire true il metodo WifiManager#isEasyConnectSupported().

7.4.3. Bluetooth

Se le implementazioni dei dispositivi supportano il profilo audio Bluetooth:

DEVE supportare i codec audio avanzati e i codec audio Bluetooth (ad es. LDAC).

Se le implementazioni dei dispositivi supportano HFP, A2DP e AVRCP:

DEVE supportare almeno 5 dispositivi connessi in totale.

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

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

Android supporta Bluetooth e Bluetooth Low Energy.

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

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

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

[C-3-1] DEVE dichiarare la funzionalità hardware android.hardware.bluetooth_le.
[C-3-2] DEVE abilitare le API Bluetooth basate su GATT (generic attribute profile) come descritto nella documentazione dell'SDK e in android.bluetooth.
[C-3-3] DEVE segnalare il valore corretto per BluetoothAdapter.isOffloadedFilteringSupported() per indicare se è implementata la logica di filtraggio per le classi API ScanFilter.
[C-3-4] DEVE segnalare il valore corretto per BluetoothAdapter.isMultipleAdvertisementSupported() per indicare se la pubblicità a basso consumo energetico è supportata.
[C-3-5] DEVE implementare un timeout dell'indirizzo privato risolvibile (RPA) non superiore a 15 minuti e ruotare l'indirizzo al timeout per proteggere la privacy dell'utente quando il dispositivo utilizza attivamente il Bluetooth Low Energy per la scansione o la pubblicità. Per evitare attacchi di temporizzazione, gli intervalli di timeout DEVONO essere randomizzati tra 5 e 15 minuti.
DEVE supportare l'offload della logica di filtraggio al chipset Bluetooth durante l'implementazione dell'API ScanFilter.
DEVE supportare l'offload della scansione batch al chipset Bluetooth.
DEVE supportare più pubblicità con almeno 4 spazi.

Se le implementazioni dei dispositivi supportano Bluetooth LE e lo utilizzano per la scansione della posizione:

[C-4-1] DEVE fornire un'interfaccia utente per attivare/disattivare la lettura del valore tramite l'API di sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se le implementazioni del dispositivo includono il supporto per Bluetooth LE e il profilo per apparecchi acustici, come descritto in Supporto audio per apparecchi acustici tramite Bluetooth LE, queste:

[C-5-1] DEVE restituire true per BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

7.4.4. Near Field Communication

Implementazioni del dispositivo:

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 il supporto NFC o non dichiarano la funzionalità android.hardware.nfc, in quanto le classi rappresentano un formato di rappresentazione dei dati indipendente dal protocollo.

Se le implementazioni del dispositivo includono hardware NFC e prevedono di renderlo disponibile per app di terze parti:

[C-1-1] DEVE segnalare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature().
DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC:
[C-1-2] DEVE essere in grado di fungere da lettore/scrittore NFC Forum (come definito dalla specifica tecnica NFCForum-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Tipi di tag NFC Forum 1, 2, 3, 4, 5 (definiti da NFC Forum)
[SR] 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 FORTEMENTE CONSIGLIATI, è previsto che la definizione di compatibilità per una versione futura li modifichi in OBBLIGATORI. Questi standard sono facoltativi in questa versione, ma saranno obbligatori nelle versioni future. È vivamente consigliato ai dispositivi esistenti e nuovi che eseguono questa versione di Android di soddisfare questi requisiti ora, in modo da poter eseguire l'upgrade alle versioni future della piattaforma.
[C-1-13] DEVE eseguire il polling di tutte le tecnologie supportate in modalità di rilevamento NFC.
DEVE essere in modalità di rilevamento NFC mentre il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.
DEVE essere in grado di leggere il codice a barre e l'URL (se codificato) dei prodotti Thinfilm NFC Barcode.

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

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

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

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

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

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

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

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

7.4.5. API e protocolli di rete

7.4.5.1. Capacità di rete minima

Implementazioni del dispositivo:

[C-0-1] DEVE includere il supporto per una o più forme di rete di dati. Nello specifico, le implementazioni del dispositivo DEVONO includere il supporto di almeno uno standard di dati in grado di raggiungere una velocità di 200 Kbit/sec o superiore. Alcuni esempi di tecnologie che soddisfano questo requisito includono EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
DOVREBBE includere anche il supporto di almeno uno standard comune per i dati wireless, ad esempio 802.11 (Wi-Fi), quando uno standard di rete fisico (ad esempio Ethernet) è la connessione dati principale.
PUÒ implementare più di una forma di connettività dei dati.

7.4.5.2. IPv6

Implementazioni del dispositivo:

[C-0-2] DEVE includere uno stack di rete IPv6 e supportare la comunicazione IPv6 utilizzando le API gestite, come java.net.Socket e java.net.URLConnection, nonché le API native, come i socket AF_INET6.
[C-0-3] DEVE abilitare IPv6 per impostazione predefinita.
DEVE garantire che la comunicazione IPv6 sia affidabile quanto IPv4, ad esempio:
- [C-0-4] DEVE mantenere la connettività IPv6 in modalità Doze.
- [C-0-5] La limitazione della velocità NON DEVE causare la perdita della connettività IPv6 sul dispositivo su qualsiasi rete compatibile con IPv6 che utilizza durate RA di almeno 180 secondi.
[C-0-6] DEVE fornire alle applicazioni di terze parti connettività IPv6 diretta alla rete quando è connesso a una rete IPv6, senza alcuna forma di traduzione di indirizzi o porte a livello locale sul dispositivo. Sia le API gestite, come Socket#getLocalAddress o Socket#getLocalPort, sia le API NDK, come getsockname() o IPV6_PKTINFO, DEVONO restituire l'indirizzo IP e la porta effettivamente utilizzati per inviare e ricevere pacchetti sulla rete e visibili come IP e porta di origine ai server internet (web).

Il livello di supporto IPv6 richiesto dipende dal tipo di rete, come mostrato nei seguenti requisiti.

Se le implementazioni dei dispositivi supportano il Wi-Fi:

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

Se le implementazioni dei dispositivi supportano Ethernet:

[C-2-1] DEVE supportare il funzionamento a doppio stack e solo IPv6 su Ethernet.

Se le implementazioni dei dispositivi supportano la rete dati:

[C-3-1] DEVE supportare il funzionamento IPv6 (solo IPv6 e possibilmente dual-stack) sulla rete cellulare.

Se le implementazioni dei dispositivi supportano più di un tipo di rete (ad es. Wi-Fi e dati cellulari):

[C-4-1] DEVE soddisfare contemporaneamente i requisiti di cui sopra su ogni rete quando il dispositivo è connesso contemporaneamente a più di un tipo di rete.

7.4.5.3. Captive portal

Un captive portal è una rete che richiede l'accesso per ottenere l'accesso a internet.

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

[C-1-1] DEVE fornire un'applicazione captive portal per gestire l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN e visualizzare la pagina di accesso al captive portal inviando l'intent alla chiamata all'API di sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] DEVE eseguire il rilevamento dei captive portal e supportare l'accesso tramite l'applicazione captive portal quando il dispositivo è connesso a qualsiasi tipo di rete, inclusa rete cellulare/mobile, Wi-Fi, Ethernet o Bluetooth.
[C-1-3] DEVE supportare l'accesso ai captive portal utilizzando DNS in testo normale quando il dispositivo è configurato per utilizzare la modalità rigida del DNS privato.
[C-1-4] DEVE utilizzare DNS criptato come da documentazione dell'SDK per android.net.LinkProperties.getPrivateDnsServerName e android.net.LinkProperties.isPrivateDnsActive per tutto il traffico di rete che non comunica esplicitamente con il captive portal.
[C-1-5] DEVE garantire che, mentre l'utente esegue l'accesso a un captive portal, la rete predefinita utilizzata dalle applicazioni (restituita da ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback e utilizzata per impostazione predefinita dalle API di rete Java come java.net.Socket e dalle API native come connect()) sia qualsiasi altra rete disponibile che fornisca l'accesso a internet, se disponibile.

7.4.6. Impostazioni di sincronizzazione

Implementazioni del dispositivo:

[C-0-1] DEVE avere l'impostazione di sincronizzazione automatica principale attiva per impostazione predefinita, in modo che il metodo getMasterSyncAutomatically() restituisca "true".

7.4.7. Risparmio dati

Se le implementazioni dei dispositivi includono una connessione a consumo, sono:

[SR] CONSIGLIATO VIVAMENTE di fornire la modalità Risparmio dati.

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

[C-1-1] DEVE supportare tutte le API nella classe ConnectivityManager come descritto nella documentazione dell'SDK

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

[C-2-1] MUST return the value RESTRICT_BACKGROUND_STATUS_DISABLED for ConnectivityManager.getRestrictBackgroundStatus()
[C-2-2] MUST NOT broadcast ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Secure Element

Se le implementazioni dei dispositivi supportano elementi sicuri compatibili con l'API Open Mobile e li rendono disponibili per le app di terze parti:

[C-1-1] DEVE elencare i lettori di elementi sicuri disponibili tramite l'API android.se.omapi.SEService.getReaders().
[C-1-2] DEVE dichiarare i flag delle funzionalità corretti tramite android.hardware.se.omapi.uicc per il dispositivo con elementi sicuri basati su UICC, android.hardware.se.omapi.ese per il dispositivo con elementi sicuri basati su eSE e android.hardware.se.omapi.sd per il dispositivo con elementi sicuri basati su SD.

7.5. Videocamere

Se le implementazioni dei dispositivi includono almeno una videocamera:

[C-1-1] DEVE dichiarare il flag funzionalità android.hardware.camera.any.
[C-1-2] DEVE essere possibile per un'applicazione allocare simultaneamente 3 bitmap RGBA_8888 di dimensioni pari a quelle delle immagini prodotte dal sensore della fotocamera con la risoluzione più alta sul dispositivo, mentre la fotocamera è aperta per lo scopo di anteprima di base e acquisizione di foto.
[C-1-3] DEVE garantire che l'applicazione fotocamera preinstallata predefinita che gestisce gli intent MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE o MediaStore.ACTION_VIDEO_CAPTURE sia responsabile della rimozione della posizione dell'utente nei metadati dell'immagine prima di inviarla all'applicazione ricevente quando quest'ultima non dispone di ACCESS_FINE_LOCATION.

7.5.1. Fotocamera posteriore

Una fotocamera posteriore è una fotocamera posizionata sul lato del dispositivo opposto al display, ovvero riprende scene sul lato opposto del dispositivo, come una fotocamera tradizionale.

Implementazioni del dispositivo:

DOVREBBE includere una fotocamera posteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera posteriore:

[C-1-1] DEVE segnalare i flag funzionalità android.hardware.camera e android.hardware.camera.any.
[C-1-2] DEVE avere una risoluzione di almeno 2 megapixel.
DEVE avere la messa a fuoco automatica hardware o software implementata nel driver della fotocamera (trasparente per il software applicativo).
POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
POTREBBE includere un flash.

Se la videocamera include un flash:

[C-2-1] La lampada flash NON DEVE essere accesa mentre è stata registrata un'istanza android.hardware.Camera.PreviewCallback su una superficie di anteprima della videocamera, a meno che l'applicazione non abbia attivato esplicitamente il flash attivando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON di un oggetto Camera.Parameters. Tieni presente che questo vincolo non si applica all'applicazione della fotocamera di sistema integrata nel dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

Una fotocamera frontale è una fotocamera posizionata sullo stesso lato del dispositivo del display, ovvero una fotocamera in genere utilizzata per riprendere l'utente, ad esempio per le videoconferenze e applicazioni simili.

Implementazioni del dispositivo:

POTREBBE includere una fotocamera anteriore.

Se le implementazioni dei dispositivi includono almeno una videocamera frontale:

[C-1-1] DEVE segnalare i flag funzionalità android.hardware.camera.any e android.hardware.camera.front.
[C-1-2] DEVE avere una risoluzione di almeno VGA (640x480 pixel).
[C-1-3] NON DEVE utilizzare una fotocamera frontale come predefinita per l'API Camera e NON DEVE configurare l'API in modo che tratti una fotocamera frontale come fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
[C-1-4] L'anteprima della videocamera DEVE essere specchiata orizzontalmente rispetto all'orientamento specificato dall'applicazione quando l'applicazione corrente ha richiesto esplicitamente la rotazione del display della videocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation(). Al contrario, l'anteprima DEVE essere specchiata lungo l'asse orizzontale predefinito del dispositivo quando l'applicazione corrente non richiede esplicitamente la rotazione del display della videocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation().
[C-1-5] NON DEVE eseguire il mirroring dei flussi video o del fermo immagine finale acquisito restituiti ai callback dell'applicazione o salvati nella memoria multimediale.
[C-1-6] DEVE rispecchiare l'immagine visualizzata dalla postview nello stesso modo del flusso di immagini di anteprima della videocamera.
POSSONO includere funzionalità (come messa a fuoco automatica, flash e così via) disponibili per le fotocamere posteriori, come descritto nella sezione 7.5.1.

Se le implementazioni del dispositivo possono essere ruotate dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente):

[C-2-1] L'anteprima della videocamera DEVE essere specchiata orizzontalmente rispetto all'orientamento attuale del dispositivo.

7.5.3. Videocamera esterna

Implementazioni del dispositivo:

POTREBBE includere il supporto di una fotocamera esterna che non è necessariamente sempre connessa.

Se le implementazioni dei dispositivi includono il supporto di una videocamera esterna:

[C-1-1] DEVE dichiarare i flag delle funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any.
[C-1-2] DEVE supportare USB Video Class (UVC 1.0 o versioni successive) se la videocamera esterna si connette tramite la porta host USB.
[C-1-3] DEVE superare i test CTS della fotocamera con un dispositivo fotocamera esterno fisico collegato. I dettagli dei test CTS della videocamera sono disponibili all'indirizzo source.android.com.
DEVE supportare compressioni video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ad es. stream di immagini grezze o compressi in modo indipendente).
POTREBBE supportare più videocamere.
POTREBBE supportare la codifica video basata sulla videocamera.

Se la codifica video basata sulla videocamera è supportata:

[C-2-1] L'implementazione del dispositivo DEVE poter accedere a uno stream simultaneo non codificato / MJPEG (risoluzione QVGA o superiore).

7.5.4. Comportamento dell'API Camera

Android include due pacchetti API per accedere alla fotocamera. La nuova API android.hardware.camera2 espone il controllo della fotocamera di livello inferiore all'app, inclusi flussi di streaming/scatto a raffica efficienti senza copia e controlli per frame di esposizione, guadagno, guadagni del bilanciamento del bianco, conversione del colore, riduzione del rumore, nitidezza e altro ancora.

Il pacchetto API precedente,android.hardware.Camera, è contrassegnato come deprecato in Android 5.0, ma dovrebbe comunque essere disponibile per l'utilizzo da parte delle app. Le implementazioni dei dispositivi Android DEVONO garantire il supporto continuo dell'API come descritto in questa sezione e nell'SDK Android.

Tutte le funzionalità comuni tra la classe android.hardware.Camera deprecata e il pacchetto android.hardware.camera2 più recente DEVONO avere prestazioni e qualità equivalenti in entrambe le API. Ad esempio, con impostazioni equivalenti, la velocità e la precisione della messa a fuoco automatica devono essere identiche e la qualità delle immagini acquisite deve essere la stessa. Le funzionalità che dipendono dalle diverse semantiche delle due API non devono avere velocità o qualità corrispondenti, ma DEVONO corrispondere il più possibile.

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API correlate alla fotocamera, per tutte le fotocamere disponibili. Implementazioni del dispositivo:

[C-0-1] DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione quando un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int).
[C-0-2] DEVE inoltre essere nel formato di codifica NV21 quando un'applicazione registra un'istanza android.hardware.Camera.PreviewCallback e il sistema chiama il metodo onPreviewFrame() e il formato di anteprima è YCbCr_420_SP, i dati nel byte[] passati a onPreviewFrame(). ovvero NV21 DEVE essere il formato predefinito.
[C-0-3] DEVE supportare il formato YV12 (indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia per le fotocamere anteriori che per quelle posteriori per android.hardware.Camera. Il codificatore video hardware e la videocamera possono utilizzare qualsiasi formato pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione in YV12.
[C-0-4] DEVE supportare i formati android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG come output tramite l'API android.media.ImageReader per i dispositivi android.hardware.camera2 che pubblicizzano la funzionalità REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities.
[C-0-5] DEVE comunque implementare l'API Camera completa inclusa nella documentazione dell'SDK Android, indipendentemente dal fatto che il dispositivo includa la messa a fuoco automatica hardware o altre funzionalità. Ad esempio, le videocamere senza messa a fuoco automatica DEVONO comunque chiamare le istanze android.hardware.Camera.AutoFocusCallback registrate (anche se non è pertinente per una videocamera senza messa a fuoco automatica). Tieni presente che questo vale per le fotocamere frontali; ad esempio, anche se la maggior parte delle fotocamere frontali non supporta la messa a fuoco automatica, i callback API devono comunque essere "falsificati" come descritto.
[C-0-6] DEVE riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters e nella classe android.hardware.camera2.CaptureRequest. Al contrario, le implementazioni del dispositivo NON DEVONO rispettare o riconoscere le costanti stringa trasmesse al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. ovvero le implementazioni del dispositivo DEVONO supportare tutti i parametri standard della fotocamera se l'hardware lo consente e NON DEVONO supportare tipi di parametri della fotocamera personalizzati. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini utilizzando tecniche di imaging High Dynamic Range (HDR) DEVONO supportare il parametro della videocamera Camera.SCENE_MODE_HDR.
[C-0-7] DEVE segnalare il livello di supporto appropriato con la proprietà android.info.supportedHardwareLevel, come descritto nell'SDK Android, e segnalare i flag delle funzionalità del framework appropriati.
[C-0-8] DEVE anche dichiarare le funzionalità della singola videocamera android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag delle funzionalità appropriati; DEVE definire il flag della funzionalità se uno qualsiasi dei dispositivi videocamera collegati la supporta.
[C-0-9] DEVE trasmettere l'intent Camera.ACTION_NEW_PICTURE ogni volta che la videocamera scatta una nuova foto e la voce della foto è stata aggiunta all'archivio multimediale.
[C-0-10] DEVE trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e la voce dell'immagine è stata aggiunta all'archivio multimediale.
[C-0-11] TUTTE le videocamere accessibili tramite l'API android.hardware.Camera ritirata DEVONO essere accessibili anche tramite l'API android.hardware.camera2.
[C-0-12] DEVE garantire che l'aspetto del viso NON venga alterato, inclusi, a titolo esemplificativo, l'alterazione della geometria del viso, della tonalità della pelle del viso o del levigamento della pelle del viso per qualsiasi API android.hardware.camera2 o android.hardware.Camera.
[C-SR] Per i dispositivi con più videocamere RGB rivolte nella stessa direzione, è VIVAMENTE CONSIGLIATO supportare un dispositivo videocamera logico che elenca la funzionalità CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, costituita da tutte le videocamere RGB rivolte in quella direzione come sottodispositivi fisici.

Se le implementazioni dei dispositivi forniscono un'API fotocamera proprietaria ad app di terze parti:

[C-1-1] DEVE implementare un'API fotocamera di questo tipo utilizzando l'API android.hardware.camera2.
POSSONO fornire tag e/o estensioni del fornitore all'API android.hardware.camera2.

7.5.5. Orientamento della videocamera

Se le implementazioni del dispositivo hanno una fotocamera anteriore o posteriore, queste fotocamere:

[C-1-1] DEVE essere orientata in modo che la dimensione lunga della videocamera sia allineata alla dimensione lunga dello schermo. ovvero, quando il dispositivo è tenuto in orientamento orizzontale, le videocamere DEVONO acquisire immagini in orientamento orizzontale. Ciò vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica sia ai dispositivi con orientamento orizzontale principale sia a quelli con orientamento verticale principale.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

Implementazioni del dispositivo:

[C-0-1] DEVE includere un gestore dei download che le applicazioni POSSONO utilizzare per scaricare file di dati e DEVE essere in grado di scaricare singoli file di almeno 100 MB nella posizione "cache" predefinita.

7.6.2. Spazio di archiviazione condiviso dell'applicazione

Implementazioni del dispositivo:

[C-0-1] DEVE offrire uno spazio di archiviazione da condividere tra le applicazioni, spesso indicato anche come "spazio di archiviazione esterno condiviso", "spazio di archiviazione condiviso dell'applicazione" o dal percorso Linux "/sdcard" su cui è montato.
[C-0-2] DEVE essere configurato con spazio di archiviazione condiviso montato per impostazione predefinita, ovvero "pronto all'uso", indipendentemente dal fatto che l'archiviazione sia implementata su un componente di memoria interna o su un supporto di archiviazione rimovibile (ad es. slot per schede Secure Digital).
[C-0-3] DEVE montare lo spazio di archiviazione condiviso dell'applicazione direttamente sul percorso Linux sdcard o includere un link simbolico Linux da sdcard al punto di montaggio effettivo.
[C-0-4] DEVE attivare l'archiviazione mirata per impostazione predefinita per tutte le app che hanno come target il livello API 29 o versioni successive, tranne nella seguente situazione:
- Quando l'app ha richiesto android:requestLegacyExternalStorage="true" nel manifest.
[C-0-5] DEVE oscurare i metadati sulla posizione, come i tag EXIF GPS, memorizzati nei file multimediali quando questi file vengono consultati tramite MediaStore, tranne quando l'app di chiamate dispone dell'autorizzazione ACCESS_MEDIA_LOCATION.

Le implementazioni dei dispositivi POSSONO soddisfare i requisiti di cui sopra utilizzando una delle seguenti opzioni:

Memoria rimovibile accessibile all'utente, ad esempio uno slot per schede Secure Digital (SD).
Una parte dello spazio di archiviazione interno (non rimovibile) come implementato in Android Open Source Project (AOSP).

Se le implementazioni dei dispositivi utilizzano supporti di archiviazione rimovibili per soddisfare i requisiti sopra indicati:

[C-1-1] DEVE implementare un avviso nell'interfaccia utente sotto forma di toast o popup quando non è inserito alcun supporto di archiviazione nello slot.
[C-1-2] DEVE includere un supporto di archiviazione formattato FAT (ad es. scheda SD) o mostrare sulla confezione e su altro materiale disponibile al momento dell'acquisto che il supporto di archiviazione deve essere acquistato separatamente.

Se le implementazioni dei dispositivi utilizzano una parte dello spazio di archiviazione non rimovibile per soddisfare i requisiti di cui sopra:

DEVE utilizzare l'implementazione AOSP dello spazio di archiviazione condiviso interno dell'applicazione.
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.
DEVE esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione dei contenuti multimediali di Android e android.provider.MediaStore.
PUÒ utilizzare l'archiviazione di massa USB, ma DEVE utilizzare il protocollo di trasferimento multimediale per soddisfare questo requisito.

Se le implementazioni dei dispositivi hanno una porta USB con modalità periferica USB e supportano il protocollo di trasferimento multimediale,

DEVE essere compatibile con l'host MTP Android di riferimento, Android File Transfer.
DEVE segnalare una classe di dispositivo USB pari a 0x00.
DEVE segnalare il nome dell'interfaccia USB "MTP".

7.6.3. Spazio di archiviazione utilizzabile

Se il dispositivo è mobile per natura, a differenza della televisione, le implementazioni del dispositivo sono:

[SR] È VIVAMENTE CONSIGLIATO di implementare la memoria adottabile in una posizione stabile a lungo termine, poiché la disconnessione accidentale può causare la perdita/il danneggiamento dei dati.

Se la porta del dispositivo di archiviazione rimovibile si trova in una posizione stabile a lungo termine, ad esempio all'interno del vano batteria o di un'altra copertura protettiva, le implementazioni del dispositivo sono:

[SR] VIVAMENTE CONSIGLIATO di implementare la memoria adottabile.

7.7. USB

Se le implementazioni del dispositivo hanno una porta USB:

DEVE supportare la modalità periferica USB e la modalità host USB.

7.7.1. Modalità periferica USB

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

[C-1-1] La porta DEVE essere collegabile a un host USB con una porta USB standard di tipo A o di tipo C.
[C-1-2] DEVE segnalare il valore corretto di iSerialNumber nel descrittore del dispositivo standard USB tramite android.os.Build.SERIAL.
[C-1-3] DEVE rilevare caricabatterie da 1,5 A e 3 A in base allo standard di resistenza Type-C e DEVE rilevare le modifiche alla pubblicità se supportano USB Type-C.
[SR] La porta DEVE utilizzare il fattore di forma USB micro-B, micro-AB o Type-C. È VIVAMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti, in modo che possano essere aggiornati alle versioni future della piattaforma.
[SR] La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o abilitare la rotazione dello schermo software per tutte le app (inclusa la schermata Home), in modo che il display venga disegnato correttamente quando il dispositivo è orientato con la porta in basso. È VIVAMENTE CONSIGLIATO che i dispositivi Android nuovi ed esistenti soddisfino questi requisiti, in modo che possano essere aggiornati alle versioni future della piattaforma.
[SR] DEVE implementare il supporto per assorbire una corrente di 1,5 A durante il segnale acustico HS e il traffico come specificato nella specifica di ricarica della batteria USB, revisione 1.2. È VIVAMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti, in modo che possano essere aggiornati alle versioni future della piattaforma.
[SR] È VIVAMENTE CONSIGLIATO di non supportare metodi di ricarica proprietari che modificano la tensione Vbus oltre i livelli predefiniti o alterano i ruoli di sink/source, in quanto ciò potrebbe causare problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard di alimentazione USB. Sebbene sia indicato come "FORTEMENTE CONSIGLIATO", nelle future versioni di Android potremmo RICHIEDERE che tutti i dispositivi di tipo C supportino la piena interoperabilità con i caricabatterie standard di tipo C.
[SR] VIVAMENTE CONSIGLIATO per supportare Power Delivery per lo scambio di ruoli di dati e alimentazione quando supportano USB Type-C e la modalità host USB.
DOVREBBE supportare Power Delivery per la ricarica ad alta tensione e le modalità alternative come l'uscita video.
DEVE implementare l'API e la specifica Android Open Accessory (AOA) come documentato nella documentazione dell'SDK Android.

Se le implementazioni dei dispositivi includono una porta USB e implementano la specifica AOA:

[C-2-1] DEVE dichiarare il supporto per la funzionalità hardware android.hardware.usb.accessory.
[C-2-2] La classe di archiviazione di massa USB DEVE includere la stringa "android" alla fine della stringa iInterface della descrizione dell'interfaccia dell'archiviazione di massa USB

7.7.2. Modalità host USB

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

[C-1-1] DEVE implementare l'API host USB di Android come documentato nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host.
[C-1-2] DEVE implementare il supporto per connettere periferiche USB standard, ovvero DEVE:
- Avere una porta di tipo C sul dispositivo o essere fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB Type-C standard (dispositivo USB Type-C).
- Avere un tipo A sul dispositivo o essere fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB standard di tipo A.
- Avere una porta micro-AB sul dispositivo, che DOVREBBE essere fornito con un cavo di adattamento a una porta Type-A standard.
[C-1-3] NON DEVE essere spedito con un adattatore che converte le porte USB di tipo A o micro-AB in una porta (presa) di tipo C.
[C-SR] È FORTEMENTE CONSIGLIATO di implementare la classe audio USB come descritto nella documentazione dell'SDK Android.
DEVE supportare la ricarica del dispositivo periferico USB collegato in modalità host; pubblicizzare una corrente di alimentazione di almeno 1,5 A come specificato nella sezione Parametri di terminazione della specifica del cavo e del connettore USB Type-C, revisione 1.2 per i connettori USB Type-C o utilizzare l'intervallo di corrente di uscita della porta di ricarica downstream(CDP) come specificato nelle specifiche di ricarica della batteria USB, revisione 1.2 per i connettori Micro-AB.
DEVONO implementare e supportare gli standard USB Type-C.

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

[C-2-1] DEVE supportare la classe USB HID.
[C-2-2] DEVE supportare il rilevamento e la mappatura dei seguenti campi di dati HID specificati nelle tabelle di utilizzo HID USB e nella richiesta di utilizzo dei comandi vocali alle costanti KeyEvent come indicato di seguito:
- Pagina di utilizzo (0xC) ID utilizzo (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- Pagina di utilizzo (0xC) ID utilizzo (0x0E9): KEYCODE_VOLUME_UP
- Pagina di utilizzo (0xC) ID utilizzo (0x0EA): KEYCODE_VOLUME_DOWN
- Pagina di utilizzo (0xC) ID utilizzo (0x0CF): KEYCODE_VOICE_ASSIST

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e Storage Access Framework (SAF),

[C-3-1] DEVE riconoscere tutti i dispositivi MTP (Media Transfer Protocol) connessi da remoto e rendere accessibili i relativi contenuti tramite gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e USB Type-C:

[C-4-1] DEVE implementare la funzionalità Dual Role Port come definita dalla specifica USB Type-C (sezione 4.5.1.3.3).
[SR] VIVAMENTE CONSIGLIATO per supportare DisplayPort, DOVREBBE supportare velocità di trasferimento dati USB SuperSpeed ed è VIVAMENTE CONSIGLIATO per supportare Power Delivery per lo scambio di ruoli di dati e alimentazione.
[SR] È VIVAMENTE CONSIGLIATO di NON supportare la modalità accessorio adattatore audio come descritto nell'appendice A della specifica del cavo e del connettore USB Type-C Revisione 1.2.
DEVE implementare il modello Try.* più appropriato per il fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DEVE implementare il modello Try.SNK.

7.8. Audio

7.8.1. Microfono

Se le implementazioni del dispositivo includono un microfono:

[C-1-1] DEVE segnalare la costante della funzionalità android.hardware.microphone.
[C-1-2] DEVE soddisfare i requisiti di registrazione audio indicati nella sezione 5.4.
[C-1-3] DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
[SR] Sono FORTEMENTE CONSIGLIATI per supportare la registrazione di suoni quasi impercettibili come descritto nella sezione 7.8.3.

Se le implementazioni del dispositivo omettono un microfono:

[C-2-1] NON DEVE segnalare la costante della funzionalità android.hardware.microphone.
[C-2-2] DEVE implementare l'API di registrazione audio almeno come no-ops, come indicato nella sezione 7.

7.8.2. Uscita audio

Se le implementazioni dei dispositivi includono un altoparlante o una porta di output audio/multimediale per una periferica di output audio come un jack audio da 3,5 mm a 4 conduttori o una porta in modalità host USB che utilizza la classe audio USB, queste:

[C-1-1] DEVE segnalare la costante della funzionalità android.hardware.audio.output.
[C-1-2] DEVE soddisfare i requisiti di riproduzione audio riportati nella sezione 5.5.
[C-1-3] DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
[SR] VIVAMENTE CONSIGLIATO per supportare la riproduzione di suoni quasi ultrasonici, come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono un altoparlante o una porta di uscita audio:

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

Ai fini di questa sezione, una "porta di uscita" è un'interfaccia fisica come un jack audio da 3, 5 mm, HDMI o una porta in modalità host USB con classe audio USB. Il supporto dell'uscita audio tramite protocolli basati su segnale radio come Bluetooth, Wi-Fi o rete mobile non è considerato un "output port".

7.8.2.1. Porte audio analogiche

Per essere compatibili con le cuffie e altri accessori audio che utilizzano la spina audio da 3, 5 mm nell'ecosistema Android, se le implementazioni dei dispositivi includono una o più porte audio analogiche:

[C-SR] È VIVAMENTE CONSIGLIATO includere almeno una delle porte audio come jack audio da 3,5 mm a 4 conduttori.

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

[C-1-1] DEVE supportare la riproduzione audio su cuffie stereo e cuffie stereo con microfono.
[C-1-2] DEVE supportare i connettori audio TRRS con l'ordine dei pin CTIA.
[C-1-3] DEVE supportare il rilevamento e la mappatura dei codici chiave per i seguenti tre intervalli di impedenza equivalente tra il microfono e i conduttori di terra sul connettore audio:
- 70 ohm o meno: KEYCODE_HEADSETHOOK
- 210-290 ohm: KEYCODE_VOLUME_UP
- 360-680 ohm: KEYCODE_VOLUME_DOWN
[C-1-4] DEVE attivare ACTION_HEADSET_PLUG all'inserimento di una spina, ma solo dopo che tutti i contatti della spina toccano i segmenti pertinenti del jack.
[C-1-5] DEVE essere in grado di pilotare almeno 150 mV ± 10% della tensione di uscita su un'impedenza dell'altoparlante di 32 ohm.
[C-1-6] DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V e 2,9 V.
[C-1-7] DEVE rilevare e mappare il keycode per il seguente intervallo di impedenza equivalente tra il microfono e i conduttori di terra sul jack audio:
- 110-180 ohm: KEYCODE_VOICE_ASSIST
[C-SR] Sono FORTEMENTE CONSIGLIATI per supportare i jack audio con l'ordine di piedinatura OMTP.
[C-SR] È FORTEMENTE CONSIGLIATO supportare la registrazione audio da cuffie stereo con microfono.

Se le implementazioni dei dispositivi hanno un jack audio da 3, 5 mm a 4 conduttori e supportano un microfono e trasmettono android.intent.action.HEADSET_PLUG con il valore aggiuntivo del microfono impostato su 1, allora:

[C-2-1] DEVE supportare il rilevamento del microfono sull'accessorio audio collegato.

7.8.2.2. Porte audio digitali

Per essere compatibili con le cuffie e altri accessori audio che utilizzano connettori USB-C e implementano (USB audio class) nell'ecosistema Android, come definito nella specifica delle cuffie USB per Android.

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

7.8.3. Near-Ultrasound

L'audio quasi ultrasonico è la banda da 18,5 kHz a 20 kHz.

Implementazioni del dispositivo:

DEVE segnalare correttamente il supporto della funzionalità audio a ultrasuoni tramite l'API AudioManager.getProperty nel seguente modo:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND è "true", le seguenti condizioni DEVONO essere soddisfatte dalle sorgenti audio VOICE_RECOGNITION e UNPROCESSED:

[C-1-1] La risposta di potenza media del microfono nella banda da 18,5 kHz a 20 kHz NON DEVE essere inferiore di oltre 15 dB rispetto alla risposta a 2 kHz.
[C-1-2] Il rapporto segnale/rumore non ponderato del microfono nell'intervallo da 18,5 kHz a 20 kHz per un tono a 19 kHz a -26 dBFS NON DEVE essere inferiore a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND è "true":

[C-2-1] La risposta media dell'altoparlante a 18,5 kHz - 20 kHz NON DEVE essere inferiore a 40 dB rispetto alla risposta a 2 kHz.

7.8.4. Integrità del segnale

Implementazioni del dispositivo: * DEVONO fornire un percorso del segnale audio privo di problemi per i flussi di input e output sui dispositivi portatili, come definito da zero problemi misurati durante un test di un minuto per percorso. Esegui il test utilizzando "Automated Glitch Test" di [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester).

Il test richiede un dongle di loopback audio, utilizzato direttamente in un jack da 3,5 mm e/o in combinazione con un adattatore da USB-C a 3,5 mm. Tutte le porte di uscita audio DEVONO essere testate.

OboeTester attualmente supporta i percorsi AAudio, pertanto le seguenti combinazioni DEVONO essere testate per rilevare problemi utilizzando AAudio:

Modalità Prestazioni	Condivisione	Frequenza di campionamento in uscita	In Chans	Out Chans
LOW_LATENCY	ESCLUSIVO	NON SPECIFICATO	1	2
LOW_LATENCY	ESCLUSIVO	NON SPECIFICATO	2	1
LOW_LATENCY	CONDIVISO	NON SPECIFICATO	1	2
LOW_LATENCY	CONDIVISO	NON SPECIFICATO	2	1
NESSUNO	CONDIVISO	48000	1	2
NESSUNO	CONDIVISO	48000	2	1
NESSUNO	CONDIVISO	44100	1	2
NESSUNO	CONDIVISO	44100	2	1
NESSUNO	CONDIVISO	16000	1	2
NESSUNO	CONDIVISO	16000	2	1

Un flusso affidabile DEVE soddisfare i seguenti criteri per il rapporto segnale/rumore (SNR) e la distorsione armonica totale (THD) per una sinusoide a 2000 Hz.

Trasduttore	THD	SNR
altoparlante integrato principale, misurato utilizzando un microfono di riferimento esterno	< 3,0%	>= 50 dB
microfono integrato principale, misurato utilizzando un altoparlante di riferimento esterno	< 3,0%	>= 50 dB
Jack analogici da 3,5 mm integrati, testati utilizzando l'adattatore loopback	< 1%	>= 60 dB
Adattatori USB forniti con lo smartphone, testati utilizzando l'adattatore loopback	< 1,0%	>= 60 dB

7.9. Realtà virtuale

Android include API e funzionalità per creare applicazioni di "realtà virtuale" (VR), tra cui esperienze VR mobile di alta qualità. Le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

7.9.1. Modalità Realtà virtuale

Android include il supporto della modalità VR, una funzionalità che gestisce il rendering stereoscopico delle notifiche e disattiva i componenti dell'interfaccia utente di sistema monoculare mentre un'applicazione VR è in primo piano.

7.9.2. Modalità Realtà virtuale - Alte prestazioni

Se le implementazioni dei dispositivi supportano la modalità VR:

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

Se il core esclusivo è supportato, il core:

[C-2-1] NON DEVE consentire l'esecuzione di altri processi dello spazio utente (ad eccezione dei driver di dispositivo utilizzati dall'applicazione), ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

7.10. Tecnologia aptica

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

7.11. Media Performance Class

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

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

[C-1-1] DEVE restituire almeno un valore pari a android.os.Build.VERSION_CODES.R.
[C-1-2] DEVE essere un'implementazione di un dispositivo portatile.
[C-1-3] DEVE soddisfare tutti i requisiti per la "Classe di rendimento dei contenuti multimediali" descritti nella sezione 2.2.7.

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

8. Prestazioni e potenza

Alcuni criteri minimi di prestazioni e consumo energetico sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di base che gli sviluppatori avrebbero durante lo sviluppo di un'app.

8.1. Coerenza dell'esperienza utente

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

8.2. Prestazioni di accesso I/O di file

Fornire una base di riferimento comune per prestazioni di accesso ai file coerenti nell'archivio dati privato dell'applicazione (partizione /data) consente agli sviluppatori di app di impostare un'aspettativa adeguata che aiuti la progettazione del software. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POSSONO avere determinati requisiti descritti nella sezione 2 per le seguenti operazioni di lettura e scrittura:

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

8.3. Modalità di risparmio energetico

Se le implementazioni dei dispositivi includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo incluse in AOSP (ad es. Bucket di standby delle app, Doze) o estendono le funzionalità che non applicano restrizioni più rigide rispetto al bucket di standby delle app rare, queste:

[C-1-1] NON DEVE discostarsi dall'implementazione AOSP per gli algoritmi di attivazione, manutenzione e riattivazione e per l'utilizzo delle impostazioni di sistema globali delle modalità di risparmio energetico Standby delle app e Sospensione.
[C-1-2] NON DEVE discostarsi dall'implementazione AOSP per l'utilizzo delle impostazioni globali per gestire la limitazione di attività, sveglie e rete per le app in ogni bucket per la funzionalità App in standby.
[C-1-3] NON DEVE discostarsi dall'implementazione AOSP per il numero di bucket di standby delle app utilizzati per lo standby delle app.
[C-1-4] DEVE implementare Bucket di standby delle app e Doze come descritto in Gestione dell'alimentazione.
[C-1-5] DEVE restituire true per PowerManager.isPowerSaveMode() quando il dispositivo è in modalità di risparmio energetico.
[C-SR] È VIVAMENTE CONSIGLIATO di fornire agli utenti la possibilità di attivare e disattivare la funzionalità di risparmio energetico.
[C-SR] Sono VIVAMENTE CONSIGLIATE per fornire agli utenti la possibilità di visualizzare tutte le app esentate dalle modalità di risparmio energetico Standby delle app e Sospensione.

Se le implementazioni dei dispositivi estendono le funzionalità di gestione dell'alimentazione incluse in AOSP e questa estensione applica restrizioni più rigorose rispetto al bucket di standby delle app rare, consulta la sezione 3.5.1.

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

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S4 come definiti da ACPI:

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

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S3 come definiti da ACPI,

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

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

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

8.4. Contabilizzazione del consumo energetico

Una contabilizzazione e un report più accurati del consumo energetico forniscono allo sviluppatore di app sia gli incentivi che gli strumenti per ottimizzare il modello di utilizzo dell'energia dell'applicazione.

Implementazioni del dispositivo:

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

8.5. Prestazioni costanti

Le prestazioni possono variare notevolmente per le app a esecuzione prolungata ad alte prestazioni, a causa delle altre app in esecuzione in background o della limitazione della CPU dovuta ai limiti di temperatura. Android include interfacce programmatiche in modo che, quando il dispositivo è in grado, l'applicazione in primo piano principale possa richiedere al sistema di ottimizzare l'allocazione delle risorse per gestire queste fluttuazioni.

Implementazioni del dispositivo:

[C-0-1] DEVE segnalare con precisione il supporto della modalità Prestazioni sostenute tramite il metodo API PowerManager.isSustainedPerformanceModeSupported().
DEVE supportare la modalità Prestazioni sostenute.

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

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

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

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

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

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

Se le implementazioni dei dispositivi non supportano un core esclusivo:

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

9. Compatibilità del modello di sicurezza

Implementazioni del dispositivo:

[C-0-1] DEVE implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento su sicurezza e autorizzazioni nelle API nella documentazione per sviluppatori Android.
[C-0-2] DEVE supportare l'installazione di applicazioni autofirmate senza richiedere autorizzazioni/certificati aggiuntivi da terze parti/autorità. Nello specifico, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle sottosezioni seguenti.

9.1. Autorizzazioni

Implementazioni del dispositivo:

[C-0-1] DEVE supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android. Nello specifico, DEVONO applicare ogni autorizzazione definita come descritto nella documentazione dell'SDK; nessuna autorizzazione può essere omessa, modificata o ignorata.
POSSONO aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe ID autorizzazione non si trovino nello spazio dei nomi android.\*.
[C-0-2] Le autorizzazioni con un protectionLevel di PROTECTION_FLAG_PRIVILEGED DEVONO essere concesse solo alle app preinstallate nei percorsi privilegiati dell'immagine di sistema e nel sottoinsieme delle autorizzazioni esplicitamente consentite per ogni app. L'implementazione AOSP soddisfa questo requisito leggendo e rispettando le autorizzazioni consentite per ogni app dai file nel percorso etc/permissions/ e utilizzando il percorso system/priv-app come percorso privilegiato.

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

Implementazioni del dispositivo:

[C-0-3] DEVE mostrare un'interfaccia dedicata all'utente per decidere se concedere le autorizzazioni di runtime richieste e fornire anche un'interfaccia per gestire le autorizzazioni di runtime.
[C-0-4] DEVE avere una sola implementazione di entrambe le interfacce utente.
[C-0-5] NON DEVE concedere autorizzazioni di runtime alle app preinstallate, a meno che:
- Il consenso dell'utente può essere ottenuto prima che l'applicazione lo utilizzi.
- Le autorizzazioni di runtime sono associate a un pattern di intent per il quale l'applicazione preinstallata è impostata come gestore predefinito.
[C-0-6] DEVE concedere l'autorizzazione android.permission.RECOVER_KEYSTORE solo alle app di sistema che registrano un agente di recupero adeguatamente protetto. Un agente di recupero protetto correttamente è definito come un agente software sul dispositivo che si sincronizza con uno spazio di archiviazione remoto esterno al dispositivo, dotato di hardware sicuro con protezione equivalente o superiore a quella descritta nel servizio Google Cloud Key Vault per impedire attacchi brute force al fattore di conoscenza della schermata di blocco.

Implementazioni del dispositivo:

[C-0-7] DEVE rispettare le proprietà dell'autorizzazione di accesso alla posizione di Android quando un'app richiede i dati sulla posizione o sull'attività fisica tramite l'API Android standard o un meccanismo proprietario. Questi dati includono, a titolo esemplificativo:
- Posizione del dispositivo (ad es. latitudine e longitudine).
- Informazioni che possono essere utilizzate per determinare o stimare la posizione del dispositivo (ad es. SSID, BSSID, ID cella o posizione della rete a cui è connesso il dispositivo).
- Attività fisica dell'utente o classificazione dell'attività fisica.

Più nello specifico, le implementazioni dei dispositivi:

[C-0-8] DEVE ottenere il consenso dell'utente per consentire a un'app di accedere ai dati di posizione o di 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 autorizzazioni possono essere contrassegnate come limitate, modificandone il comportamento.

[C-0-10] Le autorizzazioni contrassegnate dal flag hardRestricted NON DEVONO essere concesse a un'app a meno che:
- Un file APK dell'app si trova nella partizione di sistema.
- L'utente assegna a un'app un ruolo associato alle autorizzazioni hardRestricted.
- Il programma di installazione concede hardRestricted a un'app.
- A un'app viene concesso hardRestricted in una versione precedente di Android.
[C-0-11] Le app che dispongono di un'autorizzazione softRestricted DEVONO ottenere solo un accesso limitato e NON DEVONO ottenere l'accesso completo finché non vengono inserite nella lista consentita come descritto nell'SDK, dove l'accesso completo e limitato è definito per ogni autorizzazione softRestricted (ad esempio, READ_EXTERNAL_STORAGE).

Se le implementazioni del dispositivo forniscono un'interfaccia utente per scegliere quali app possono essere visualizzate sopra altre app con un'attività che gestisce l'intent ACTION_MANAGE_OVERLAY_PERMISSION, queste:

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

9.2. UID e isolamento dei processi

Implementazioni del dispositivo:

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

9.3. Autorizzazioni del file system

Implementazioni del dispositivo:

[C-0-1] DEVE supportare il modello di autorizzazioni di accesso ai file Android come definito nel riferimento a sicurezza e autorizzazioni.

9.4. Ambienti di esecuzione alternativi

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

[C-0-1] Gli ambienti di runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella sezione 9.
[C-0-2] I runtime alternativi NON DEVONO avere accesso alle risorse protette da autorizzazioni non richieste nel file AndroidManifest.xml del runtime tramite il meccanismo <uses-permission>.
[C-0-3] I runtime alternativi NON DEVONO consentire alle applicazioni di utilizzare funzionalità protette 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 utilizzando un runtime alternativo NON DEVONO riutilizzare la sandbox di altre app installate sul dispositivo, se non tramite i meccanismi standard di Android di ID utente condiviso e certificato di firma.
[C-0-5] Gli ambienti di runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso ai sandbox corrispondenti ad altre applicazioni per Android.
[C-0-6] I runtime alternativi NON DEVONO essere avviati con, ricevere o concedere ad altre applicazioni privilegi di superutente (root) o di qualsiasi altro ID utente.
[C-0-7] Quando i file .apk di runtime alternativi sono inclusi nell'immagine di sistema delle implementazioni del dispositivo, DEVONO essere firmati con una chiave distinta da quella utilizzata per firmare altre applicazioni incluse nelle implementazioni del dispositivo.
[C-0-8] Durante l'installazione delle applicazioni, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione.
[C-0-9] Quando un'applicazione deve utilizzare una risorsa del dispositivo per la quale esiste un'autorizzazione Android corrispondente (ad esempio fotocamera, GPS e così via), l'ambiente di runtime alternativo DEVE informare l'utente che l'applicazione potrà accedere a quella risorsa.
[C-0-10] Quando l'ambiente di runtime non registra le funzionalità dell'applicazione in questo modo, DEVE elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che utilizza quel runtime.
I runtime alternativi DEVONO installare le app tramite PackageManager in sandbox Android separate (ID utente Linux e così via).
Runtime alternativi POSSONO fornire una singola sandbox Android condivisa da tutte le applicazioni che utilizzano il runtime alternativo.

9.5. Supporto multiutente

Android include il supporto multiutente e fornisce il supporto per l'isolamento completo degli utenti.

Le implementazioni del dispositivo POSSONO, ma NON DEVONO, attivare il multiutente se utilizzano supporti rimovibili per l'archiviazione esterna principale.

Se le implementazioni dei dispositivi includono più utenti:

[C-1-1] DEVE soddisfare i seguenti requisiti relativi al supporto multiutente.
[C-1-2] DEVE, per ogni utente, implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento su sicurezza e autorizzazioni nelle API.
[C-1-3] MUST have separate and isolated shared application storage (a.k.a. /sdcard) directories for each user instance.
[C-1-4] DEVE garantire che le applicazioni di proprietà di un determinato utente e in esecuzione per suo conto non possano elencare, leggere o scrivere nei file di proprietà di qualsiasi altro utente, anche se i dati di entrambi gli utenti sono archiviati nello stesso volume o file system.
[C-1-5] DEVE criptare i contenuti della scheda SD quando è abilitato l'utilizzo multiutente utilizzando una chiave memorizzata solo su supporti non rimovibili accessibili solo al sistema se le implementazioni del dispositivo utilizzano supporti rimovibili per le API di archiviazione esterna. Poiché in questo modo i contenuti multimediali non saranno leggibili da un PC host, le implementazioni dei dispositivi dovranno passare a MTP o a un sistema simile per fornire ai PC host l'accesso ai dati dell'utente corrente.

9.6. Avviso SMS premium

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

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

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

9.7. Security Features

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

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

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

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

[C-0-7] DEVE implementare meccanismi di protezione dal buffer overflow dello stack del kernel. Esempi di questi meccanismi sono CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] DEVE implementare protezioni rigorose della memoria del kernel in cui il codice eseguibile è di sola lettura, i dati di sola lettura non sono eseguibili e non sono scrivibili e i dati scrivibili non sono eseguibili (ad es. CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
[C-0-9] DEVE implementare il controllo dei limiti delle dimensioni degli oggetti statici e dinamici delle copie tra lo spazio utente e lo spazio kernel (ad es. CONFIG_HARDENED_USERCOPY) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
[C-0-10] NON DEVE eseguire la memoria dello spazio utente durante l'esecuzione in modalità kernel (ad es. PXN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
[C-0-11] NON DEVE leggere o scrivere nella memoria dello spazio utente nel kernel al di fuori delle normali API di accesso usercopy (ad es. PAN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
[C-0-12] DEVE implementare l'isolamento della tabella delle pagine del kernel se l'hardware è vulnerabile a CVE-2017-5754 su tutti i dispositivi originariamente forniti con il livello API 28 o versioni successive (ad es. CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] DEVE implementare la protezione della predizione dei rami se l'hardware è vulnerabile a CVE-2017-5715 su tutti i dispositivi originariamente forniti con il livello API 28 o versioni successive (ad es. CONFIG_HARDEN_BRANCH_PREDICTOR).
[SR] STRONGLY RECOMMENDED to keep kernel data which is written only during initialization marked read-only after initialization (e.g. __ro_after_init).
[C-SR] È VIVAMENTE CONSIGLIATO di randomizzare il layout del codice kernel e della memoria ed evitare esposizioni che comprometterebbero la randomizzazione (ad es. CONFIG_RANDOMIZE_BASE con l'entropia del bootloader tramite /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).
[C-SR] È VIVAMENTE CONSIGLIATO di attivare l'integrità del flusso di controllo (CFI) nel kernel per fornire una protezione aggiuntiva contro gli attacchi di riutilizzo del codice (ad es. CONFIG_CFI_CLANG e CONFIG_SHADOW_CALL_STACK).
[C-SR] È VIVAMENTE CONSIGLIATO di non disattivare l'integrità del flusso di controllo (CFI), lo stack di chiamate shadow (SCS) o la sanificazione dell'overflow di interi (IntSan) sui componenti in cui è attivata.
[C-SR] È FORTEMENTE CONSIGLIATO attivare CFI, SCS e IntSan per eventuali componenti aggiuntivi dello spazio utente sensibili alla sicurezza, come spiegato in CFI e IntSan.
[C-SR] È VIVAMENTE CONSIGLIATO attivare l'inizializzazione dello stack nel kernel per impedire l'utilizzo di variabili locali non inizializzate (CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO). Inoltre, le implementazioni dei dispositivi NON DEVONO presupporre il valore utilizzato dal compilatore per inizializzare le variabili locali.
[C-SR] È VIVAMENTE CONSIGLIATO di attivare l'inizializzazione dell'heap nel kernel per impedire l'utilizzo di allocazioni dell'heap non inizializzate (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) e NON DEVE presupporre il valore utilizzato dal kernel per inizializzare queste allocazioni.

Se le implementazioni dei dispositivi utilizzano un kernel Linux:

[C-1-1] DEVE implementare SELinux.
[C-1-2] DEVE impostare SELinux sulla modalità di applicazione globale.
[C-1-3] MUST configure all domains in enforcing mode. Non sono consentiti domini in modalità permissiva, inclusi i domini specifici di un dispositivo/fornitore.
[C-1-4] NON DEVE modificare, omettere o sostituire le regole neverallow presenti nella cartella system/sepolicy fornita nel progetto Android Open Source Project (AOSP) upstream e il criterio DEVE essere compilato con tutte le regole neverallow presenti, sia per i domini SELinux AOSP sia per i domini specifici del dispositivo/fornitore.
[C-1-5] DEVONO eseguire applicazioni di terze parti che hanno come target il livello API 28 o superiore in sandbox SELinux per applicazione con restrizioni SELinux per app sulla directory dei dati privati di ogni applicazione.
DEVE conservare il criterio SELinux predefinito fornito nella cartella system/sepolicy del progetto Android Open Source e aggiungervi solo la propria configurazione specifica del dispositivo.

Se le implementazioni dei dispositivi sono già state lanciate su una versione precedente di Android e non soddisfano i requisiti [C-1-1] e [C-1-5] tramite un aggiornamento del software di sistema, POSSONO essere esentate da questi requisiti.

Se le implementazioni dei dispositivi utilizzano un kernel diverso da Linux:

[C-2-1] DEVE utilizzare un sistema di controllo dell'accesso obbligatorio equivalente a SELinux.

Android include diverse funzionalità di difesa in profondità che sono parte integrante della sicurezza del dispositivo.

9.8. Privacy

9.8.1. Cronologia di utilizzo

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

Implementazioni del dispositivo:

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

Android archivia gli eventi di sistema utilizzando gli identificatori StatsLog e gestisce la cronologia tramite l'API di sistema StatsManager e IncidentManager.

Implementazioni del dispositivo:

[C-0-2] DEVE includere solo i campi contrassegnati con DEST_AUTOMATIC nella segnalazione di un problema creata dalla classe API di sistema IncidentManager.
[C-0-3] NON DEVE utilizzare gli identificatori di eventi di sistema per registrare eventi diversi da quelli descritti nei documenti dell'SDK StatsLog. Se vengono registrati eventi di sistema aggiuntivi, questi POTREBBERO utilizzare un identificatore atomo diverso nell'intervallo compreso tra 100.000 e 200.000.

9.8.2. Registrazione

Implementazioni del dispositivo:

[C-0-1] NON DEVE precaricare o distribuire componenti software out-of-box che inviano informazioni private dell'utente (ad es. sequenze di tasti, testo visualizzato sullo schermo, report di bug) dal dispositivo senza il consenso dell'utente o notifiche chiare e continue.
[C-0-2] DEVE mostrare e ottenere il consenso esplicito dell'utente che consenta l'acquisizione di qualsiasi informazione sensibile visualizzata sullo schermo dell'utente ogni volta che la trasmissione o la registrazione dello schermo è attivata tramite MediaProjection o API proprietarie. NON DEVE fornire agli utenti la possibilità di disattivare la visualizzazione futura del consenso dell'utente.
[C-0-3] DEVE avere una notifica continua 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.

Se le implementazioni del dispositivo includono funzionalità nel sistema che acquisiscono i contenuti visualizzati sullo schermo e/o registrano il flusso audio riprodotto sul dispositivo in modo diverso dall'API di sistema ContentCaptureService o con altri mezzi proprietari descritti nella Sezione 9.8.6 Acquisizione dei contenuti, queste:

[C-1-1] DEVE mostrare una notifica continua all'utente ogni volta che questa funzionalità è abilitata e sta acquisendo/registrando attivamente.

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

[C-2-1] NON DEVE memorizzare in modo permanente nella memoria del dispositivo o trasmettere al di fuori del dispositivo l'audio grezzo registrato o qualsiasi formato che possa essere riconvertito nell'audio originale o in una copia quasi esatta, se non con il consenso esplicito 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 chieda il consenso dell'utente prima di consentire l'accesso ai contenuti dello spazio di archiviazione condiviso tramite la porta USB.

9.8.4. Traffico di rete

Implementazioni del dispositivo:

[C-0-1] DEVE preinstallare gli stessi certificati radice per l'archivio delle autorità di certificazione (CA) attendibili dal sistema come fornito nel progetto open source Android upstream.
[C-0-2] MUST ship with an empty user root CA store.
[C-0-3] DEVE mostrare un avviso all'utente che indica che il traffico di rete potrebbe essere monitorato quando viene aggiunta una CA radice utente.

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

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

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

[C-2-1] DEVE chiedere il consenso dell'utente prima di attivare questo meccanismo, a meno che la VPN non sia attivata dal controller delle norme del dispositivo tramite DevicePolicyManager.setAlwaysOnVpnPackage() , nel qual caso l'utente non deve fornire un consenso separato, ma DEVE solo ricevere una notifica.

Se le implementazioni del dispositivo implementano una funzionalità utente per attivare/disattivare la funzione "VPN sempre attiva" di un'app VPN di terze parti:

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

9.8.5. Identificatori dei dispositivi

Implementazioni del dispositivo:

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

9.8.6. Acquisizione dei contenuti

Android, tramite l'API di sistema ContentCaptureService o con altri mezzi proprietari, supporta un meccanismo per le implementazioni dei dispositivi per acquisire le seguenti interazioni tra le applicazioni e l'utente.

Testo e grafica visualizzati sullo schermo, inclusi, a titolo esemplificativo, notifiche e dati di assistenza tramite l'API AssistStructure.
Dati multimediali, come audio o video, registrati o riprodotti dal dispositivo.
Eventi di input (ad es. tastiera, mouse, gesti, voce, video e accessibilità).
Qualsiasi altro evento fornito da un'applicazione al sistema tramite l'API Content Capture o un'API proprietaria con funzionalità simili.
Qualsiasi testo o altro dato inviato tramite TextClassifier API a System TextClassifier, ovvero al servizio di sistema per comprendere il significato del testo, nonché per generare le successive azioni previste in base al testo.

Se le implementazioni dei dispositivi acquisiscono i dati sopra indicati:

[C-1-1] DEVE criptare tutti questi dati quando vengono memorizzati nel dispositivo. Questa crittografia PUÒ essere eseguita utilizzando la crittografia basata su file di Android o uno qualsiasi dei cifrari elencati come versione API 26+ descritti in Cipher SDK.
[C-1-2] NON DEVE eseguire il backup di dati non elaborati o criptati utilizzando i metodi di backup di Android o altri metodi di backup.
[C-1-3] DEVE inviare tutti questi dati e il log del dispositivo solo utilizzando un meccanismo che tutela la privacy. Il meccanismo che tutela la privacy è definito come "quello che consente solo l'analisi aggregata e impedisce la corrispondenza degli eventi registrati o dei risultati derivati con i singoli utenti", per impedire che i dati per utente siano ispezionabili (ad es. implementati utilizzando una tecnologia di privacy differenziale come RAPPOR).
[C-1-4] NON DEVE associare questi dati a un'identità utente (ad esempio Account) sul dispositivo, tranne con il consenso esplicito dell'utente ogni volta che i dati vengono associati.
[C-1-5] NON DEVE condividere questi dati con altre app, tranne con il consenso esplicito dell'utente ogni volta che vengono condivisi.
[C-1-6] DEVE fornire all'utente la possibilità di cancellare i dati raccolti dal ContentCaptureService o con mezzi proprietari se i dati sono memorizzati in qualsiasi forma sul dispositivo.

Se le implementazioni dei dispositivi includono un servizio che implementa l'API di sistema ContentCaptureService o qualsiasi servizio proprietario che acquisisce i dati come descritto sopra, devono:

[C-2-1] NON DEVE consentire agli utenti di sostituire il servizio di acquisizione dei contenuti con un'applicazione o un servizio installabile dall'utente e DEVE consentire solo al servizio preinstallato di acquisire tali dati.
[C-2-2] NON DEVE consentire ad app diverse dal meccanismo di servizio di acquisizione dei contenuti preinstallato di acquisire questi dati.
[C-2-3] DEVE fornire all'utente la possibilità di disattivare il servizio di acquisizione dei contenuti.
[C-2-4] NON DEVE omettere la possibilità per l'utente di gestire le autorizzazioni Android detenute dal servizio di acquisizione dei contenuti e seguire il modello di autorizzazioni Android descritto nella Sezione 9.1. Autorizzazione.
[C-SR] È FORTEMENTE CONSIGLIATO di mantenere separati i componenti del servizio di acquisizione dei contenuti, ad esempio non collegando il servizio o condividendo gli ID processo, da altri componenti del sistema, ad eccezione di quanto segue:
- Telefonia, Contatti, UI di sistema e contenuti multimediali

9.8.7. Accesso agli appunti

Implementazioni del dispositivo:

[C-0-1] NON DEVE restituire dati tagliati negli appunti (ad es. tramite l'API ClipboardManager) a meno che l'app non sia l'IME predefinito o l'app attualmente selezionata.

9.8.8. Località

Implementazioni del dispositivo:

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

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 visualizzare i dettagli di altre app installate (vedi Visibilità dei pacchetti nella documentazione dell'SDK Android).

Implementazioni del dispositivo:

[C-0-1] NON DEVE esporre a nessuna app che ha come target il livello API 30 o versioni successive dettagli su qualsiasi altra app installata, a meno che l'app non sia già in grado di visualizzare i dettagli sull'altra app installata tramite le API gestite. Sono inclusi, a titolo esemplificativo, i dettagli esposti da eventuali API personalizzate aggiunte dall'implementatore del dispositivo o accessibili tramite il file system.

9.8.10. Segnalazione di bug relativi alla connettività

Se le implementazioni dei dispositivi generano report sui bug utilizzando l'API di sistema BUGREPORT_MODE_TELEPHONY con BugreportManager,

[C-1-1] DEVE ottenere il consenso dell'utente ogni volta che viene chiamata l'API di sistema BUGREPORT_MODE_TELEPHONY per generare un report e NON DEVE chiedere all'utente di acconsentire a tutte le richieste future dell'applicazione.
[C-1-2] DEVE mostrare e ottenere il consenso esplicito dell'utente quando i report iniziano a essere generati e NON DEVE restituire il report generato all'app richiedente senza il consenso esplicito dell'utente.
[C-1-3] DEVE generare i report richiesti contenenti almeno le seguenti informazioni:
- Dump di TelephonyDebugService
- Dump di TelephonyRegistry
- Dump di WifiService
- ConnectivityService dump
- Un dump dell'istanza CarrierService del pacchetto chiamate (se associata)
- Buffer log del segnale radio
[C-1-4] NON DEVE includere quanto segue nei report generati:
- Qualsiasi tipo di informazione non correlata al debug della connettività.
- Log del traffico di applicazioni installate dall'utente o profili dettagliati di applicazioni/pacchetti installati dall'utente (gli UID sono accettabili, i nomi dei pacchetti no).
POTREBBE includere informazioni aggiuntive non associate a nessuna identità utente. (ad es. log del fornitore).

Se le implementazioni dei dispositivi includono informazioni aggiuntive (ad es.log del fornitore) nella segnalazione di bug e queste informazioni hanno un impatto su privacy/sicurezza/batteria/spazio di archiviazione/memoria:

[C-SR] Are STRONGLY RECOMMENDED to have a developer setting defaulted to disabled. L'AOSP soddisfa questo requisito fornendo l'opzione Enable verbose vendor logging nelle impostazioni sviluppatore per includere log aggiuntivi di fornitori relativi a un dispositivo specifico nelle segnalazioni di bug.

9.8.11. Condivisione dei blob di dati

Android, tramite BlobStoreManager, consente alle app di contribuire con blob di dati al sistema da condividere con un insieme selezionato di app.

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

[C-1-1] NON DEVE condividere i blob di dati appartenenti alle app oltre a quanto intendevano consentire (ovvero l'ambito dell'accesso predefinito e le altre modalità di accesso che possono essere specificate utilizzando BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() o BlobStoreManager.session#allowPublicAccess() NON DEVONO essere modificati). L'implementazione di riferimento AOSP soddisfa questi requisiti.
[C-1-2] NON DEVE inviare al di fuori del dispositivo o condividere con altre app gli hash sicuri dei blob di dati (che vengono utilizzati per controllare l'accesso).

9.9. Crittografia dell'archiviazione dei dati

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

9.9.1. Avvio diretto

Implementazioni del dispositivo:

[C-0-1] DEVE implementare le API della modalità Avvio diretto anche se non supportano la crittografia dell'archiviazione.
[C-0-2] Gli intent ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED DEVONO comunque essere trasmessi per segnalare alle applicazioni compatibili con l'avvio diretto che le posizioni di archiviazione con crittografia del dispositivo (DE) e con crittografia delle credenziali (CE) sono disponibili per l'utente.

9.9.2. Requisiti di crittografia

Implementazioni del dispositivo:

[C-0-1] DEVE criptare i dati privati dell'applicazione (partizione /data), nonché la partizione di archiviazione condivisa dell'applicazione (partizione /sdcard) se è una parte permanente e non rimovibile del dispositivo.
[C-0-2] DEVE abilitare la crittografia dell'archiviazione dei dati per impostazione predefinita al momento del completamento della configurazione iniziale da parte dell'utente.
[C-0-3] DEVE soddisfare il requisito di crittografia dell'archiviazione dei dati sopra indicato implementando uno dei due metodi di crittografia seguenti:
- Crittografia basata su file (FBE) e crittografia dei metadati, come descritto nella sezione 9.9.3.1.
- Crittografia a livello di blocco per utente, come descritto nella sezione 9.9.3.2.

9.9.3. Metodi di crittografia

Se le implementazioni dei dispositivi sono criptate:

[C-1-1] DEVE avviarsi senza richiedere le credenziali all'utente e consentire alle app compatibili con l'avvio diretto di accedere allo spazio di archiviazione con crittografia del dispositivo (DE) dopo la trasmissione del messaggio ACTION_LOCKED_BOOT_COMPLETED.
[C-1-2] DEVE consentire l'accesso allo spazio di archiviazione Credential Encrypted (CE) solo dopo che l'utente ha sbloccato il dispositivo fornendo le proprie credenziali (ad es. passcode, PIN, sequenza o impronta) e viene trasmesso il 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 a garanzia registrata o una ripresa all'avvio che soddisfi i requisiti della sezione 9.9.4.
[C-1-4] DEVE utilizzare l'avvio verificato.

9.9.3.1. Crittografia basata su file con crittografia dei metadati

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

[C-1-5] DEVE criptare i contenuti dei file e i metadati del file system utilizzando AES-256-XTS o Adiantum. AES-256-XTS si riferisce all'Advanced Encryption Standard con una lunghezza della chiave di crittografia di 256 bit, utilizzato in modalità XTS; la lunghezza completa della chiave è di 512 bit. Adiantum si riferisce ad Adiantum-XChaCha12-AES, come specificato all'indirizzo https://github.com/google/adiantum. I metadati del file system sono dati come dimensioni, proprietà, modalità e attributi estesi (xattr) dei file.
[C-1-6] DEVE criptare i nomi dei file utilizzando AES-256-CBC-CTS o Adiantum.
[C-1-12] Se il dispositivo dispone di istruzioni Advanced Encryption Standard (AES) (ad esempio estensioni di crittografia ARMv8 su dispositivi basati su ARM o AES-NI su dispositivi basati su x86), DEVONO essere utilizzate le opzioni basate su AES sopra indicate per la crittografia del nome file, dei contenuti del file e dei metadati del file system, non Adiantum.
[C-1-13] DEVE utilizzare una funzione di derivazione delle chiavi crittograficamente efficace e non reversibile (ad es. HKDF-SHA512) per derivare le eventuali sottochiavi necessarie (ad es. chiavi per file) dalle chiavi CE e DE. "Crittograficamente forte e non reversibile" significa che la funzione di derivazione della chiave ha una forza di sicurezza di almeno 256 bit e si comporta come una famiglia di funzioni pseudocasuali sui suoi input.
[C-1-14] NON DEVE utilizzare le stesse chiavi o sottochiavi di crittografia basata su file (FBE) per scopi crittografici diversi (ad es. sia per la crittografia che per la derivazione delle chiavi o per due algoritmi di crittografia diversi).
Le chiavi che proteggono le aree di archiviazione CE e DE e i metadati del file system:
[C-1-7] DEVE essere associato in modo crittografico a un keystore basato su hardware. Questo keystore DEVE essere associato all'Avvio verificato e alla radice di attendibilità hardware del dispositivo.
[C-1-8] Le chiavi CE DEVONO essere vincolate alle credenziali della schermata di blocco di un utente.
[C-1-9] Le chiavi CE DEVONO essere associate a un passcode predefinito quando l'utente non ha specificato le credenziali della schermata di blocco.
[C-1-10] DEVE essere univoca e distinta, in altre parole la chiave CE o DE di un utente non corrisponde a quella di un altro utente.
[C-1-11] DEVE utilizzare le cifrature, le lunghezze delle chiavi e le modalità supportate obbligatoriamente.
DOVREBBE rendere le app essenziali preinstallate (ad es. Sveglia, Telefono, Messenger) compatibili con l'avvio diretto.

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

9.9.3.2. Crittografia a livello di blocco per utente

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

[C-1-1] DEVE attivare il supporto multiutente come descritto nella sezione 9.5.
[C-1-2] DEVE fornire partizioni per utente, utilizzando partizioni non elaborate o volumi logici.
[C-1-3] DEVE utilizzare chiavi di crittografia uniche e distinte per utente per la crittografia dei dispositivi a blocchi sottostanti.
[C-1-4] DEVE utilizzare AES-256-XTS per la crittografia a livello di blocco delle partizioni utente.
Le chiavi che proteggono i dispositivi criptati a livello di blocco per utente:
[C-1-5] DEVE essere associato in modo crittografico a un keystore basato sulla crittografia hardware. Questo keystore DEVE essere associato all'Avvio verificato e alla radice di attendibilità hardware del dispositivo.
[C-1-6] MUST be bound to the corresponding user's lock screen credentials.

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

9.9.4. Riprendi all'avvio

Riprendi dopo il riavvio consente di sbloccare l'archivio CE di tutte le app, incluse quelle che non supportano ancora l'avvio diretto, dopo un riavvio avviato da un aggiornamento OTA. Questa funzionalità consente agli utenti di ricevere notifiche dalle app installate dopo il riavvio.

Un'implementazione di Resume-on-Reboot deve continuare a garantire che, quando un dispositivo cade nelle mani di un malintenzionato, sia estremamente difficile per quest'ultimo recuperare i dati dell'utente criptati con CE, anche se il dispositivo è acceso, l'archiviazione CE è sbloccata e l'utente ha sbloccato il dispositivo dopo aver ricevuto un aggiornamento OTA. Per la resistenza agli attacchi interni, presupponiamo anche che l'attaccante ottenga l'accesso alle chiavi di firma crittografica di trasmissione.

In particolare:

[C-0-1] L'archivio CE NON DEVE essere leggibile nemmeno per l'attaccante che ha fisicamente il dispositivo e quindi ha queste funzionalità e limitazioni:
- Può utilizzare la chiave di firma di qualsiasi fornitore o azienda per firmare messaggi arbitrari.
- Può causare la ricezione di un aggiornamento OTA da parte del dispositivo.
- Può modificare il funzionamento di qualsiasi hardware (AP, flash e così via), ad eccezione di quanto descritto di seguito, ma tale modifica comporta un ritardo di almeno un'ora e un ciclo di accensione che distrugge i contenuti della RAM.
- Non è possibile modificare il funzionamento dell'hardware antimanomissione (ad es. Titan M).
- Impossibile leggere la RAM del dispositivo live.
- Non può ottenere le credenziali dell'utente (PIN, sequenza, password) o far sì che vengano inserite.

Ad esempio, un'implementazione del dispositivo che implementa e rispetta tutte le descrizioni riportate qui sarà conforme a [C-0-1].

9.10. Integrità del dispositivo

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

[C-0-1] DEVE segnalare correttamente tramite il metodo dell'API di sistema PersistentDataBlockManager.getFlashLockState() se lo stato del bootloader consente il flashing dell'immagine di sistema. Lo stato FLASH_LOCK_UNKNOWN è riservato alle implementazioni dei dispositivi che eseguono l'upgrade da una versione precedente di Android in cui questo nuovo metodo API di sistema non esisteva.
[C-0-2] DEVE supportare l'Avvio verificato per l'integrità del dispositivo.

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

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

[C-1-1] DEVE dichiarare il flag della funzionalità della piattaforma android.software.verified_boot.
[C-1-2] DEVE eseguire la verifica a ogni sequenza di avvio.
[C-1-3] DEVE 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 le attuali raccomandazioni del NIST per gli algoritmi di hashing (SHA-256) e le dimensioni delle chiavi pubbliche (RSA-2048).
[C-1-6] NON DEVE consentire il completamento dell'avvio quando la verifica del sistema non va a buon fine, a meno che l'utente non acconsenta a tentare comunque l'avvio, nel qual caso i dati di eventuali blocchi di archiviazione non verificati NON DEVONO essere utilizzati.
[C-1-7] NON DEVE consentire la modifica delle partizioni verificate sul dispositivo, a meno che l'utente non abbia sbloccato esplicitamente il bootloader.
[C-SR] Se nel dispositivo sono presenti più chip discreti (ad es. radio, processore di immagini specializzato), è VIVAMENTE CONSIGLIATO verificare ogni fase del processo di avvio di ciascun chip.
[C-1-8] DEVE utilizzare un'archiviazione antimanomissione: per memorizzare se il bootloader è sbloccato. L'archiviazione a prova di manomissione indica che il bootloader può rilevare se l'archiviazione è stata manomessa dall'interno di Android.
[C-1-9] DEVE richiedere all'utente, durante l'utilizzo del dispositivo, una conferma fisica prima di consentire il passaggio dalla modalità bootloader bloccato alla modalità bootloader sbloccato.
[C-1-10] DEVE implementare la protezione dal rollback per le partizioni utilizzate da Android (ad es. partizioni di avvio e di sistema) e utilizzare l'archiviazione antimanomissione per memorizzare i metadati utilizzati per determinare la versione minima consentita del sistema operativo.
[C-SR] È VIVAMENTE CONSIGLIATO verificare tutti i file APK delle app con privilegi con una catena di attendibilità basata su partizioni protette da Avvio verificato.
[C-SR] È VIVAMENTE CONSIGLIATO di verificare gli artefatti eseguibili caricati da un'app con privilegi dall'esterno del file APK (ad esempio codice caricato dinamicamente o codice compilato) prima di eseguirli o È VIVAMENTE CONSIGLIATO di non eseguirli affatto.
DEVE implementare la protezione dal rollback per qualsiasi componente con firmware persistente (ad es. modem, fotocamera) e DEVE utilizzare l'archiviazione antimanomissione per archiviare i metadati utilizzati per determinare la versione minima consentita.

Se le implementazioni dei dispositivi sono già state lanciate senza supportare C-1-8 e C-1-10 su una versione precedente di Android e non è possibile aggiungere il supporto per questi requisiti con un aggiornamento del software di sistema, POTREBBERO essere esentate dai requisiti.

Il progetto Android Open Source a monte fornisce un'implementazione preferita di questa funzionalità nel repository external/avb/, che può essere integrata nel bootloader utilizzato per caricare Android.

Implementazioni del dispositivo:

[C-0-3] DEVE supportare la verifica crittografica dei contenuti dei file rispetto a una chiave attendibile senza leggere l'intero file.
[C-0-4] NON DEVE consentire l'esito positivo delle richieste di lettura di un file protetto quando il contenuto letto non viene verificato rispetto a una chiave attendibile.

Se le implementazioni dei dispositivi sono già state lanciate senza la possibilità di verificare il contenuto dei file rispetto a una chiave attendibile su una versione precedente di Android e non è possibile aggiungere il supporto per questa funzionalità con un aggiornamento del software di sistema, POTREBBERO essere esentate dal requisito. Il progetto Android Open Source upstream fornisce un'implementazione preferita di questa funzionalità basata sulla funzionalità fs-verity del kernel Linux.

Implementazioni del dispositivo:

[C-R] Sono CONSIGLIATI per supportare l'API Android Protected Confirmation.

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

[C-3-1] MUST report true for the ConfirmationPrompt.isSupported() API.
[C-3-2] DEVE garantire che il codice in esecuzione nel sistema operativo Android, incluso il suo kernel, dannoso o meno, non possa generare una risposta positiva senza l'interazione dell'utente.
[C-3-3] DEVE garantire che l'utente abbia potuto esaminare e approvare il messaggio richiesto anche nel caso in cui il sistema operativo Android, incluso il suo kernel, sia compromesso.

9.11. Chiavi e credenziali

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

[C-0-1] DEVE consentire l'importazione o la generazione di almeno 8192 chiavi.
[C-0-2] L'autenticazione della schermata di blocco DEVE limitare la frequenza dei tentativi e DEVE avere un algoritmo di backoff esponenziale. Oltre 150 tentativi non riusciti, il ritardo DEVE essere di almeno 24 ore per tentativo.
Non deve limitare il numero di chiavi che possono essere generate

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

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

[C-1-5] DEVE consentire all'utente di scegliere il timeout di sospensione per la transizione dallo stato sbloccato a quello bloccato, con un timeout minimo consentito fino a 15 secondi. I dispositivi per auto, che bloccano lo schermo ogni volta che l'unità principale viene spenta o l'utente viene cambiato, POTREBBERO NON avere la configurazione del timeout di sospensione.

9.11.1. Schermata di blocco e autenticazione sicure

L'implementazione di AOSP segue un modello di autenticazione a più livelli in cui l'autenticazione primaria basata su un fattore di conoscenza può essere supportata da una biometria secondaria forte o da modalità terziarie più deboli.

Implementazioni del dispositivo:

[C-SR] È VIVAMENTE CONSIGLIATO di impostare solo uno dei seguenti metodi come metodo di autenticazione principale:
- Un PIN numerico
- Una password alfanumerica
- Un pattern di scorrimento su una griglia di esattamente 3x3 punti

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

Se le implementazioni dei dispositivi aggiungono o modificano i metodi di autenticazione principali consigliati e utilizzano un nuovo metodo di autenticazione come modo sicuro per bloccare lo schermo, il nuovo metodo di autenticazione:

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

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco se basati su un segreto noto e utilizzano un nuovo metodo di autenticazione da trattare come un modo sicuro per bloccare lo schermo:

[C-3-1] L'entropia della lunghezza minima consentita degli input DEVE essere maggiore di 10 bit.
[C-3-2] L'entropia massima di tutti gli input possibili DEVE essere maggiore di 18 bit.
[C-3-3] Il nuovo metodo di autenticazione NON DEVE sostituire nessuno dei metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) implementati e forniti in AOSP.
[C-3-4] Il nuovo metodo di autenticazione DEVE essere disattivato quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_SOMETHING.
[C-3-5] I nuovi metodi di autenticazione DEVONO ripristinare i metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) ogni 72 ore o meno OPPURE comunicare chiaramente all'utente che alcuni dati non verranno sottoposti a backup 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 Convenienza).
[C-4-2] DEVE disporre di un meccanismo di fallback per utilizzare uno dei metodi di autenticazione principali consigliati basati su un segreto noto.
[C-4-3] DEVE essere disattivato e consentire solo l'autenticazione principale consigliata per sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio della funzionalità Keyguard chiamando il metodo DevicePolicyManager.setKeyguardDisabledFeatures() con uno 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 (precedentemente forte) come descritto nella sezione 7.3.10:

[C-5-1] I metodi DEVONO essere disattivati se l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] All'utente DEVE essere richiesta l'autenticazione principale consigliata (ad 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 nella sezione seguente.

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

[C-6-1] Deve essere presente un meccanismo di fallback per utilizzare uno dei metodi di autenticazione principali consigliati, basato su un segreto noto e che soddisfi i requisiti per essere considerato una schermata di blocco sicura.
[C-6-2] Il nuovo metodo DEVE essere disattivato e consentire solo a uno dei metodi di autenticazione principale consigliati di sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio con il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED.
[C-6-3] All'utente DEVE essere richiesta una delle modalità di autenticazione primaria consigliate (ad es. PIN, sequenza, password) almeno una volta ogni 4 ore o meno.
[C-6-4] Il nuovo metodo NON DEVE essere trattato come una schermata di blocco sicura e DEVE rispettare i vincoli elencati in C-8 di seguito.

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,

[C-7-1] DEVE essere presente un'indicazione chiara nel menu delle impostazioni e nella schermata di blocco quando il blocco del dispositivo è posticipato o può essere sbloccato da uno o più trust agent. Ad esempio, AOSP soddisfa questo requisito mostrando una descrizione testuale per le impostazioni "Blocco automatico" e "Tasto di accensione blocca istantaneamente" nel menu delle impostazioni e un'icona distinguibile nella schermata di blocco.
[C-7-2] DEVE rispettare e implementare completamente tutte le API dell'agente di attendibilità nella classe DevicePolicyManager, ad esempio la costante KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] NON DEVE implementare completamente la funzione TrustAgentService.addEscrowToken() su un dispositivo utilizzato come dispositivo personale principale (ad es. dispositivo portatile), ma PUÒ implementare completamente la funzione su implementazioni di dispositivi che vengono in genere condivise (ad es. Android TV o dispositivo per auto).
[C-7-4] DEVE criptare tutti i token archiviati aggiunti da TrustAgentService.addEscrowToken().
[C-7-5] NON DEVE archiviare la chiave di crittografia o il token di escrow sullo stesso dispositivo in cui viene utilizzata la chiave. Ad esempio, è consentito a una chiave memorizzata su uno smartphone sbloccare un account utente su una TV. Per i dispositivi per il settore automobilistico, non è consentito memorizzare il token di garanzia in nessuna parte del veicolo.
[C-7-6] DEVE informare l'utente delle implicazioni per la sicurezza prima di attivare il token di deposito a garanzia per decriptare l'archiviazione dei dati.
[C-7-7] DEVE disporre di un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali consigliati.
[C-7-8] All'utente DEVE essere richiesta l'autenticazione primaria consigliata (ad es.PIN, sequenza, password) almeno una volta ogni 72 ore o meno, a meno che non sia in discussione la sicurezza dell'utente (ad es. distrazione del conducente).
[C-7-9] All'utente DEVE essere richiesta l'autenticazione primaria consigliata (ad es.PIN, sequenza, password) come descritto in [C-1-7] e [C-1-8] nella sezione 7.3.10, a meno che non sia in discussione la sicurezza dell'utente (ad es. distrazione del conducente).
[C-7-10] NON DEVE essere trattato come una schermata di blocco sicura e DEVE rispettare i vincoli elencati in C-8 di seguito.
[C-7-11] NON DEVE consentire a Trust Agents sui dispositivi personali principali (ad es.portatili) di sbloccare il dispositivo e può utilizzarli solo per mantenere un dispositivo già sbloccato nello stato sbloccato per un massimo di 4 ore. L'implementazione predefinita di TrustManagerService in AOSP soddisfa questo requisito.
[C-7-12] DEVE utilizzare un canale di comunicazione con protezione criptata (ad es.UKEY2) per trasferire il token di deposito a garanzia dal dispositivo di archiviazione al dispositivo di destinazione.

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

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

9.11.2. StrongBox

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

Implementazioni del dispositivo con un processore sicuro dedicato:

[C-SR] Sono VIVAMENTE CONSIGLIATI per supportare StrongBox. StrongBox diventerà probabilmente un requisito in una release futura.

Se le implementazioni dei dispositivi supportano StrongBox:

[C-1-1] DEVE dichiarare FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] DEVE fornire un hardware sicuro dedicato utilizzato per il keystore e l'autenticazione utente sicura. L'hardware sicuro dedicato può essere utilizzato anche per altri scopi.
[C-1-3] DEVE avere una CPU discreta che non condivida cache, DRAM, coprocessori o altre risorse di core con il processore dell'applicazione (AP).
[C-1-4] DEVE garantire che qualsiasi periferica condivisa con l'AP non possa alterare in alcun modo l'elaborazione di StrongBox o ottenere informazioni da StrongBox. L'amministratore di Google Workspace potrebbe disattivare o bloccare l'accesso a StrongBox.
[C-1-5] DEVE avere un orologio interno con una precisione ragionevole (+/-10%) immune alla manipolazione da parte dell'AP.
[C-1-6] DEVE disporre di un generatore di numeri casuali che produca un output distribuito in modo uniforme e imprevedibile.
[C-1-7] DEVE essere a prova di manomissione, inclusa la resistenza alla penetrazione fisica e ai malfunzionamenti.
[C-1-8] DEVE essere resistente agli attacchi side-channel, inclusa la resistenza alla divulgazione di informazioni tramite i canali secondari di alimentazione, temporizzazione, radiazione elettromagnetica e radiazione termica.
[C-1-9] DEVE disporre di un archivio sicuro che garantisca riservatezza, integrità, autenticità, coerenza e aggiornamento dei contenuti. L'archivio NON DEVE poter essere letto o modificato, ad eccezione di quanto consentito dalle API StrongBox.
Per convalidare la conformità ai requisiti [C-1-3] - [C-1-9], le implementazioni dei dispositivi:
- [C-1-10] DEVE includere l'hardware certificato in base al profilo di protezione IC sicuro BSI-CC-PP-0084-2014 o valutato da un laboratorio di test accreditato a livello nazionale che incorpora la valutazione della vulnerabilità con potenziale di attacco elevato in base ai Common Criteria Application of Attack Potential to Smartcards.
- [C-1-11] DEVE includere il firmware valutato da un laboratorio di test accreditato a livello nazionale che incorpora la valutazione della vulnerabilità con elevato potenziale di attacco in base ai Common Criteria Application of Attack Potential to Smartcards.
- [C-SR] È FORTEMENTE CONSIGLIATO includere l'hardware valutato utilizzando un Security Target, un livello di garanzia di valutazione (EAL) 5, aumentato da AVA_VAN.5. È probabile che la certificazione EAL 5 diventerà un requisito in una release futura.
[C-SR] sono FORTEMENTE CONSIGLIATI per fornire resistenza agli attacchi interni (IAR), il che significa che un insider con accesso alle chiavi di firma del firmware non può produrre firmware che causino la perdita di segreti da parte di StrongBox, che aggirino i requisiti di sicurezza funzionali o che consentano in altro modo l'accesso a dati utente sensibili. Il modo consigliato per implementare IAR è consentire gli aggiornamenti firmware solo quando la password dell'utente principale viene fornita tramite IAuthSecret HAL.

9.11.3. Credenziali di identità

Il sistema di credenziali dell'identità è definito e ottenuto implementando tutte le API nel pacchetto android.security.identity.*. Queste API consentono agli sviluppatori di app di archiviare e recuperare i documenti di identità degli utenti. Implementazioni del dispositivo:

[C-SR] are STRONGLY RECOMMENDED to implement the Identity Credential System.

Se le implementazioni dei dispositivi implementano il sistema di credenziali dell'identità:

[C-0-1] MUST return non-null for the IdentityCredentialStore#getInstance() method.
[C-0-2] DEVE implementare l'Identity Credential System (ad es. le API android.security.identity.*) con codice che comunica con un'applicazione attendibile in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA.
[C-0-3] Le operazioni crittografiche necessarie per implementare l'Identity Credential System (ad es. le API android.security.identity.*) DEVONO essere eseguite interamente nell'applicazione attendibile e il materiale della chiave privata NON DEVE mai uscire dall'ambiente di esecuzione isolato, a meno che non sia specificamente richiesto da API di livello superiore (ad es. il metodo createEphemeralKeyPair()).
[C-0-4] L'applicazione attendibile DEVE essere implementata in modo che le sue proprietà di sicurezza non siano interessate (ad es. i dati delle credenziali non vengono rilasciati a meno che non siano soddisfatte le condizioni di controllo dell'accesso, i MAC non possono essere prodotti per dati arbitrari) anche se Android ha un comportamento anomalo o è compromesso.

9.12. Eliminazione dei dati

Tutte le implementazioni dei dispositivi:

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

9.13. Modalità di avvio sicuro

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

Le implementazioni del dispositivo sono:

[SR] VIVAMENTE CONSIGLIATO di implementare la modalità provvisoria.

Se le implementazioni dei dispositivi implementano la modalità di avvio protetto:

[C-1-1] DEVE fornire all'utente un'opzione per accedere alla modalità provvisoria in modo non interrompibile da app di terze parti installate sul dispositivo, tranne quando l'app di terze parti è un controller delle norme relative ai dispositivi e ha impostato il flag UserManager.DISALLOW_SAFE_BOOT su true.
[C-1-2] DEVE fornire all'utente la possibilità di disinstallare app di terze parti in modalità provvisoria.
DEVE fornire all'utente un'opzione per accedere alla modalità di avvio sicuro dal menu di avvio utilizzando un flusso di lavoro diverso da quello di un avvio normale.

9.14. Isolamento del sistema del veicolo

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

Lo scambio di dati può essere protetto implementando funzionalità di sicurezza al di sotto dei livelli del framework Android per impedire interazioni dannose o involontarie con questi sottosistemi.

9.15. Piani di abbonamento

"Piani di abbonamento" si riferisce ai dettagli del piano di fatturazione forniti da un operatore di telefonia mobile tramite SubscriptionManager.setSubscriptionPlans().

Tutte le implementazioni dei dispositivi:

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

9.16. Migrazione dei dati delle applicazioni

Se le implementazioni dei dispositivi includono una funzionalità per eseguire la migrazione dei dati da un dispositivo a un altro e non limitano i dati dell'applicazione che copia a quelli configurati dallo sviluppatore dell'applicazione nel manifest tramite l'attributo android:fullBackupContent,

[C-1-1] NON DEVE avviare trasferimenti di dati delle applicazioni da dispositivi su cui l'utente non ha impostato un'autenticazione principale come descritto in 9.11.1 Schermata di blocco e autenticazione sicure.
[C-1-2] DEVE confermare in modo sicuro l'autenticazione principale sul dispositivo di origine e confermare l'intenzione dell'utente di copiare i dati sul dispositivo di origine prima che vengano trasferiti.
[C-1-3] DEVE utilizzare l'attestazione 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 alla stessa applicazione sul dispositivo di destinazione, con lo stesso nome del pacchetto E certificato di firma.
[C-1-5] DEVE mostrare un'indicazione che i dati del dispositivo di origine sono stati migrati tramite una migrazione dei dati da dispositivo a dispositivo nel menu delle impostazioni. Un utente NON DEVE essere in grado di rimuovere questa indicazione.

10. Test di compatibilità del software

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

10.1. Compatibility Test Suite (CTS)

Implementazioni del dispositivo:

[C-0-1] DEVE superare la suite di test di compatibilità Android (CTS) disponibile nell'Android Open Source Project, utilizzando il software di spedizione finale sul dispositivo.
[C-0-2] DEVE garantire la compatibilità in caso di ambiguità nel CTS e per qualsiasi reimplementazione di parti del codice sorgente di riferimento.

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi software, il CTS potrebbe contenere bug. La suite di test di compatibilità avrà una versione indipendente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni della suite di test di compatibilità per Android 11.

Implementazioni del dispositivo:

[C-0-3] DEVE superare l'ultima versione di CTS disponibile al momento del completamento del software del dispositivo.
DEVE utilizzare l'implementazione di riferimento nell'albero Android Open Source il più possibile.

10.2. Strumento di verifica CTS

CTS Verifier è incluso in Compatibility Test Suite e deve essere eseguito da un operatore umano per testare funzionalità che non possono essere testate da un sistema automatizzato, come il corretto funzionamento di una fotocamera e dei sensori.

Implementazioni del dispositivo:

[C-0-1] DEVE eseguire correttamente tutti i casi applicabili nel programma di verifica CTS.

CTS Verifier include test per molti tipi di hardware, tra cui alcuni hardware opzionali.

Implementazioni del dispositivo:

[C-0-2] DEVE superare tutti i test per l'hardware in suo possesso; ad esempio, se un dispositivo possiede un accelerometro, DEVE eseguire correttamente lo scenario di test dell'accelerometro in CTS Verifier.

Gli scenari di test per le funzionalità indicate come facoltative in questo Compatibility Definition Document POSSONO essere ignorati o omessi.

[C-0-2] Ogni dispositivo e ogni build DEVE eseguire correttamente CTS Verifier, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori di dispositivi eseguano esplicitamente CTS Verifier su build che differiscono solo in modo banale. Nello specifico, le implementazioni del dispositivo che differiscono da un'implementazione che ha superato il CTS Verifier solo per l'insieme di impostazioni internazionali, brand e così via INCLUDONO il test CTS Verifier.

11. Software aggiornabile

[C-0-1] Le implementazioni del dispositivo DEVONO includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire upgrade "live", ovvero potrebbe essere necessario riavviare il dispositivo. Può essere utilizzato qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, uno qualsiasi dei seguenti approcci soddisferà questo requisito:
- Download "over-the-air (OTA)" con aggiornamento offline tramite riavvio.
- Aggiornamenti "in tethering" tramite USB da un PC host.
- Aggiornamenti "offline" tramite riavvio e aggiornamento da un file su un dispositivo di archiviazione rimovibile.
[C-0-2] Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. ovvero il meccanismo di aggiornamento DEVE preservare i dati privati e condivisi dell'applicazione. Tieni presente che il software Android upstream include un meccanismo di aggiornamento che soddisfa questo requisito.
[C-0-3] L'intero aggiornamento DEVE essere firmato e il meccanismo di aggiornamento sul dispositivo DEVE verificare l'aggiornamento e la firma rispetto a una chiave pubblica memorizzata sul dispositivo.
[C-SR] Il meccanismo di firma è FORTEMENTE CONSIGLIATO per eseguire l'hashing dell'aggiornamento con SHA-256 e convalidare l'hash rispetto alla chiave pubblica utilizzando ECDSA NIST P-256.

Se le implementazioni del dispositivo includono il supporto di una connessione dati senza limiti, ad esempio 802.11 o il profilo PAN (Personal Area Network) Bluetooth, allora:

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

Per le implementazioni dei dispositivi che vengono lanciate con Android 6.0 e versioni successive, il meccanismo di aggiornamento DOVREBBE supportare la verifica che l'immagine di sistema sia identica al risultato previsto dopo un aggiornamento OTA. L'implementazione OTA basata su blocchi nel progetto Android Open Source upstream, aggiunta a partire da Android 5.1, soddisfa questo requisito.

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

Se viene rilevato un errore nell'implementazione di un dispositivo dopo il suo rilascio, ma entro la sua ragionevole durata del prodotto, che viene determinata in consultazione con il team di compatibilità Android per influire sulla compatibilità delle applicazioni di terze parti, allora:

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

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

[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 del documento

Per un riepilogo delle modifiche alle sezioni individuali:

12.1. Suggerimenti per la visualizzazione del log delle modifiche

Le modifiche sono contrassegnate come segue:

CDD
Modifiche sostanziali ai requisiti di compatibilità.
Documenti
Modifiche estetiche o relative alla build.

Per una visualizzazione ottimale, aggiungi i parametri URL pretty=full e no-merges agli URL del log delle modifiche.

13. Contattaci

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

Definizione di compatibilità di Android 11 Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

1. Introduzione

1.1 Struttura del documento

1.1.1. Requisiti per tipo di dispositivo

1.1.2. ID requisito

1.1.3. ID requisito nella sezione 2

2. Tipi di dispositivi

2.1 Configurazioni dispositivo

2.2. Requisiti per i dispositivi portatili

2.2.1. Hardware

2.2.2. Multimediali

2.2.3. Software

2.2.4. Prestazioni e potenza

2.2.5. Modello di sicurezza

2.2.6. Compatibilità di strumenti e opzioni per sviluppatori

2.2.7 Classe di prestazioni dei contenuti multimediali portatili

2.2.7.1. Media

2.2.7.2. Fotocamera

2.2.7.3. Hardware

2.2.7.4. Rendimento

2.3. Requisiti della TV

2.3.1. Hardware

2.3.2. Multimediali

2.3.3. Software

2.3.4. Prestazioni e potenza

2.3.5. Modello di sicurezza

2.3.6. Compatibilità di strumenti e opzioni per sviluppatori

2.4. Requisiti dell'orologio

2.4.1. Hardware

2.4.2. Multimediali

2.4.3. Software

2.4.4. Prestazioni e potenza

2.4.5. Modello di sicurezza

2.5. Requisiti per il settore automobilistico

2.5.1. Hardware

2.5.2. Multimediali

2.5.3. Software

2.5.4. Prestazioni e potenza

2.5.5. Modello di sicurezza

2.5.6. Compatibilità di strumenti e opzioni per sviluppatori

2.6. Requisiti per i tablet

2.6.1. Hardware

2.6.2. Modello di sicurezza

2.6.2. Software

3. Software

3.1. Compatibilità API gestita

3.1.1. Estensioni Android

3.1.2. Libreria Android

3.2. Compatibilità API soft

3.2.1. Autorizzazioni

3.2.2. Parametri di build

3.2.3. Compatibilità degli intent

3.2.3.1. Common Application Intents

3.2.3.2. Risoluzione dell'intent

3.2.3.3. Spazi dei nomi degli intent

3.2.3.4. Broadcast Intents

3.2.3.5. Intent di applicazione condizionali

3.2.4. Attività su display secondari/multipli

3.3. Compatibilità con l'API nativa

3.3.1. Application Binary Interfaces

3.3.2. Compatibilità del codice nativo ARM a 32 bit

3.4. Compatibilità web

3.4.1. Compatibilità di WebView

3.4.2. Compatibilità dei browser

3.5. Compatibilità comportamentale delle API

3.5.1. Limitazione dell'applicazione

3.6. API Namespaces

3.7. Compatibilità del runtime

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

3.8.2. Widget

3.8.3. Notifiche

3.8.3.1. Presentazione delle notifiche

3.8.3.2. Servizio listener di notifiche

3.8.3.3. DND (Do Not Disturb, Non disturbare)

3.8.4. Cerca

3.8.5. Avvisi e notifiche di tipo toast

3.8.6. Temi

3.8.7. Sfondi animati

3.8.8. Passaggio da un'attività all'altra

Definizione di compatibilità di Android 11