Definizione di compatibilità con Android 14

1. Introduzione

Questo documento elenca i requisiti che devono essere soddisfatti per poter per essere compatibile con Android 14.

L'utilizzo di "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "NON DOVREBBE", "CONSIGLIATO", "MAGGIO" e "FACOLTATIVO" secondo lo standard IETF definito in RFC2119.

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

Per essere considerata compatibile con Android 14, il dispositivo le implementazioni DEVONO soddisfare i requisiti presentati nella presente Compatibilità Definizione, inclusi eventuali documenti incorporati tramite riferimento.

Laddove questa definizione o i test del software descritti in sezione 10 è silenziosa, ambigua o non è completo, è responsabilità dell'implementatore del dispositivo assicurarsi compatibilità con le implementazioni esistenti.

Per questo motivo, il progetto Android Open Source Project è l'implementazione preferita e di riferimento di Android. Dispositivo a coloro che implementano l'implementazione sono VIVAMENTE CONSIGLIATI di basare le loro implementazioni la maggior parte possibile sull'"upstream" di codice sorgente disponibile Progetto open source Android. Sebbene alcuni componenti possano ipoteticamente essere sostituiti con implementazioni alternative, è VIVAMENTE CONSIGLIATO di non seguire questa prassi, in quanto il superamento dei test del software diventerà più difficile. È responsabilità dell'implementatore di garantire la piena compatibilità comportamentale con l'implementazione standard di Android, incluse e oltre la Compatibility Test Suite. Infine, tieni presente che alcuni componenti sostituzioni e modifiche sono espressamente vietate dal presente documento.

Molte delle risorse collegate in questo documento derivano direttamente o indirettamente dall'SDK Android e sarà identico al informazioni nella documentazione dell'SDK. Nei casi in cui questa compatibilità La definizione o il Test Suite di compatibilità non sono d'accordo con l'SDK documentazione, la documentazione dell'SDK è considerata autorevole. Qualsiasi assistenza tecnica i dettagli forniti nelle risorse collegate in questo documento sono considerati come parte della presente Definizione di compatibilità.

1.1 Struttura dei documenti

1.1.1. Requisiti per tipo di dispositivo

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

Tutti gli altri requisiti che si applicano universalmente a qualsiasi dispositivo Android implementazioni, sono elencate nelle sezioni successive alla Sezione 2. Questi requisiti sono indicati come "Requisiti principali" in questo documento.

1.1.2. ID requisito

L'ID requisito è assegnato per i requisiti MUST.

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

Ogni ID è definito come di seguito:

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

1.1.3. ID requisito nella Sezione 2

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

ID di sezione che è seguito dall'ID requisito descritto sopra.

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

2. Tipi di dispositivi

Android Open Source Project fornisce uno stack software utilizzabile per un'ampia gamma di tipi di dispositivi e fattori di forma. Per supportare la sicurezza sui dispositivi: lo stack software, inclusi eventuali sistemi operativi sostitutivi o kernel alternativi implementazione, deve essere eseguita in un ambiente sicuro come descritto nella sezione 9 e altrove nel presente CDD. Esistono diversi tipi di dispositivi che hanno un ecosistema di distribuzione delle applicazioni relativamente migliore consolidato.

Questa sezione descrive questi tipi di dispositivi, nonché i requisiti aggiuntivi e consigli applicabili per ogni tipo di dispositivo.

Tutte le implementazioni su dispositivi Android che non rientrano in nessuna delle categorie descritte i tipi di dispositivi DEVONO comunque soddisfare tutti i requisiti indicati nelle altre sezioni di questo documento. Definizione di compatibilità.

2.1 Configurazioni dei dispositivi

Per le principali differenze nella configurazione hardware per dispositivo tipo, consulta i requisiti specifici del dispositivo che seguono in questa sezione.

2.2. Requisiti per gli smartphone

Un dispositivo portatile Android fa riferimento a un'implementazione del dispositivo Android che in genere viene utilizzato tenendolo in mano, come un lettore mp3, un telefono o tablet.

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

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

I requisiti aggiuntivi nel resto di questa sezione sono specifici per Android Implementazioni di dispositivi portatili.

2.2.1. Hardware

Implementazioni di dispositivi portatili:

• [7.1.1.1/H-0-1] DEVE avere almeno uno Display compatibile con Android che soddisfa tutti i requisiti descritti in questo documento. con un display che misura almeno 2,2" sul lato corto e 3,4" sul bordo lungo.

• [7.1.1.3/H-SR-1] È VIVAMENTE CONSIGLIATO a offrono agli utenti la possibilità di modificare le dimensioni di visualizzazione (densità dello schermo).

• [7.1.1.1/H-0-2] DEVE supportare la composizione della GPU di il buffer grafico è grande almeno quanto la più alta risoluzione di qualsiasi altro display.

Se le implementazioni dei dispositivi portatili richiedono il supporto dell'opzione High Dynamic Range viene mostrato fino a Configuration.isScreenHdr() , questi:

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

Implementazioni di dispositivi portatili:

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

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

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

Implementazioni di dispositivi portatili:

• [7.1.5/H-0-1] DEVE includere il supporto per le versioni precedenti compatibilità delle applicazioni come implementata dall'openstream di Android codice sorgente. Vale a dire che le implementazioni dei dispositivi NON DEVONO alterare gli attivatori o alle soglie alle quali viene attivata la modalità di compatibilità e NON DEVE alterare comportamento della modalità di compatibilità stessa.
• [7.2.1/H-0-1] DEVE includere il supporto per applicazioni di terze parti le applicazioni IME (Input Method Editor).
• [7.2.3/H-0-2] DEVE inviare sia la pressione normale che quella lunga evento della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano. Questi eventi NON DEVONO essere consumati dal sistema e POSSONO essere attivati dall'esterno del dispositivo Android (ad esempio, hardware esterno) tastiera collegata al dispositivo Android).
• [7.2.3/H-0-3] DEVE fornire la funzione Home tutti i display compatibili con Android che hanno la schermata Home.
• [7.2.3/H-0-4] DEVE fornire la funzione Indietro su tutte i display compatibili con Android e la funzione Recenti su almeno uno dei i display compatibili con Android.
• [7.2.4/H-0-1] DEVE supportare l'input del touchscreen.
• [7.2.4/H-SR-1] È VIVAMENTE CONSIGLIATO di lanciare app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService o un'attività che gestisce ACTION_ASSIST alla pressione prolungata di KEYCODE_MEDIA_PLAY_PAUSE oppure KEYCODE_HEADSETHOOK se l'attività in primo piano non gestisce gli eventi di pressione prolungata.
• [7.3.1/H-SR-1] È VIVAMENTE CONSIGLIATO di includere i modelli a 3 assi sull'accelerometro.

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

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

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

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

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

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

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

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

Implementazioni di dispositivi portatili:

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

Se i dispositivi supportano il protocollo NAN (Wi-Fi Nearby Awareness Networking) con la dichiarazione PackageManager.FEATURE_WIFI_AWARE e la posizione Wi-Fi (round Wi-Fi) Tempo di viaggio - RTT) dichiarando PackageManager.FEATURE_WIFI_RTT, dopodiché:

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

• [7.4.2.5/H-SR-1] CONSIGLIATO VIVAMENTE di segnalare gamma accurata entro +/-1 metro a 160 MHz di larghezza di banda al 90° percentile (come calcolato con la funzione di distribuzione cumulativa), +/-2 metri alla larghezza di banda di 80 MHz al 90° percentile, +/-4 metri a 40 MHz di larghezza di banda al 90° percentile e +/-8 metri di larghezza di banda a 20 MHz il 90° percentile a distanze di 10 cm, come osservato tramite API Android WifiRttManager#startRanging.

È CONSIGLIATA DI seguire i passaggi di configurazione della misurazione specificati in Calibrazione della presenza.

Se le implementazioni dei dispositivi portatili includono una videocamera logica che elenca funzionalità utilizzando CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, l'utente:

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

Implementazioni di dispositivi portatili:

• [7.6.1/H-0-1] DEVE avere almeno 4 GB di archiviazione permanente disponibile per i dati privati delle applicazioni (ovvero partizione "/data").
• [7.6.1/H-0-2] DEVE restituire "true" per ActivityManager.isLowRamDevice() quando è disponibile meno di 1 GB di memoria disponibile per il kernel e lo spazio utente.

Se le implementazioni dei dispositivi portatili dichiarano il supporto soltanto di un'ABI a 32 bit:

• [7.6.1/H-1-1] La memoria disponibile per il kernel e lo spazio utente DEVONO essere di almeno 416 MB se la visualizzazione predefinita usa framebuffer risoluzioni fino a qHD (ad es. FWVGA).

• [7.6.1/H-2-1] La memoria disponibile per il kernel e lo spazio utente DEVONO essere di almeno 592 MB se la visualizzazione predefinita usa framebuffer Risoluzioni fino a HD+ (ad es. HD, WSVGA).

• [7.6.1/H-3-1] La memoria disponibile per il kernel e lo spazio utente DEVONO essere di almeno 896 MB se la visualizzazione predefinita usa framebuffer risoluzioni fino a FHD (ad es. WSXGA+).

• [7.6.1/H-4-1] La memoria disponibile per il kernel e lo spazio utente DEVONO essere di almeno 1344 MB se la visualizzazione predefinita utilizza risoluzioni framebuffer fino a QHD (ad es. QWXGA).

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

• [7.6.1/H-5-1] La memoria disponibile per il kernel e spazio utente DEVONO essere di almeno 816 MB se il display predefinito utilizza risoluzioni framebuffer superiori a qHD (ad es. FWVGA).

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

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

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

Tieni presente che la "memoria disponibile per il kernel e lo spazio utente" di cui sopra si riferisce di memoria fornita oltre a quella già dedicata all'hardware come radio, video e così via, che non si trovano nel kernel sulle implementazioni dei dispositivi.

Se le implementazioni sui dispositivi portatili includono meno di 1 GB di memoria disponibili per il kernel e lo spazio utente, questi:

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

Se le implementazioni sui dispositivi portatili includono più di 1 GB di memoria disponibile al kernel e allo spazio utente, questi:

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

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

• [7.6.1/H-SR-1] È VIVAMENTE CONSIGLIATO di supportare solo uno spazio utente a 32 bit (entrambe le app e codice di sistema)

Se le implementazioni sui dispositivi portatili includono meno di 2 GB di memoria disponibile per del kernel e dello spazio utente, questi:

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

Implementazioni di dispositivi portatili:

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

Se le implementazioni dei dispositivi portatili includono una porta USB che supporta una periferica modalità, l'utente:

• [7.7.1/H-1-1] DEVE implementare l'accessorio Android Open (AOA) tramite Google Cloud CLI o tramite l'API Compute Engine.

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

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

Implementazioni di dispositivi portatili:

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

Se le implementazioni dei dispositivi portatili sono in grado di soddisfare tutte le prestazioni requisiti per il supporto della modalità VR e prevedono il relativo supporto:

• [7.9.1/H-1-1] DEVE dichiarare il parametro Flag funzionalità android.hardware.vr.high_performance.
• [7.9.1/H-1-2] DEVE includere un'applicazione è implementato android.service.vr.VrListenerService che può essere attivato dalla VR di applicazioni tramite android.app.Activity#setVrModeEnabled.

Se le implementazioni dei dispositivi portatili includono una o più porte USB-C nell'host e l'implementazione (classe audio USB), oltre ai requisiti della sezione 7.7.2, questi:

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

Funzione	Mappature	Contesto	Comportamento
A	Pagina utilizzo HID: 0x0C Utilizzo HID: 0x0CD Chiave kernel: KEY_PLAYPAUSE Chiave Android: KEYCODE_MEDIA_PLAY_PAUSE	Riproduzione di contenuti multimediali	Input: breve pressione Output: consente di riprodurre o mettere in pausa
			Input: pressione prolungata Output: avvia comando vocale Invii: android.speech.action.VOICE_SEARCH_HANDS_FREE se il dispositivo è bloccato o lo schermo è spento. Invii android.speech.RecognizerIntent.ACTION_WEB_SEARCH altrimenti
		Chiamata in arrivo	Input: breve pressione Output: accetta la chiamata
			Input: pressione prolungata Output: rifiuta la chiamata
		Chiamata in corso	Input: breve pressione Output: termina la chiamata
			Input: pressione prolungata Uscita: disattiva o riattiva l'audio del microfono.
B	Pagina utilizzo HID: 0x0C Utilizzo HID: 0x0E9 Chiave kernel: KEY_VOLUMEUP Chiave Android: VOLUME_UP	Riproduzione di contenuti multimediali, Chiamata in corso	Input: pressione breve o lunga Uscita: consente di aumentare il volume del sistema o delle cuffie.
C	Pagina utilizzo HID: 0x0C Utilizzo HID: 0x0EA Chiave kernel: KEY_VOLUMEDOWN Chiave Android: VOLUME_DOWN	Riproduzione di contenuti multimediali, Chiamata in corso	Input: pressione breve o lunga Uscita: consente di abbassare il volume del sistema o delle cuffie
D	Pagina utilizzo HID: 0x0C Utilizzo HID: 0x0CF Chiave kernel: KEY_VOICECOMMAND Chiave Android: KEYCODE_VOICE_ASSIST	Tutti. Può essere attivato in qualsiasi istanza.	Input: pressione breve o lunga Output: avvia il comando vocale

• [7.8.2.2/H-1-2] DEVE attivare ACTION_HEADSET_PLUG ma solo dopo che le interfacce audio USB e gli endpoint hanno enumerato in modo adeguato per identificare il tipo di terminale collegato.

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

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

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

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

quando l'API AudioManager.getDevices() viene chiamata mentre la periferica USB è hanno collegato:

• [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 ruolo isSink() se terminale audio USB è 0x0402.

• [7.8.2.2/H-4-3] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e ruolo isSource() se il terminale audio USB è 0x0402.

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

• [7.8.2.2/H-4-5] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_DEVICE e ruolo isSource() se il terminale audio USB è 0x604.

• [7.8.2.2/H-4-6] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_DEVICE e ruolo isSink() se il tipo di terminale audio USB è un tipo di terminale audio è 0x400.

• [7.8.2.2/H-4-7] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_DEVICE e ruolo isSource() se il terminale audio USB è 0x400.

• [7.8.2.2/H-SR-1] Sono VIVAMENTE CONSIGLIATE al momento del collegamento di un Periferica audio USB-C, per eseguire l'enumerazione dei descrittori USB, identificare di terminale e l'intent di trasmissione ACTION_HEADSET_PLUG in meno di 1000 millisecondi.

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

• [5.6/H-1-1] DEVE avere un round-Trip continuo medio latenza di 300 millisecondi meno di 5 misurazioni, con una deviazione media assoluta inferiore a 30 ms, oltre i seguenti percorsi di dati: "da speaker a microfono", Adattatore con loopback da 3,5 mm (se supportato), loopback USB (se supportato).

• [5.6/H-1-2] DEVE avere una latenza Tocco per tono media di 300 millisecondi o in meno su almeno 5 misurazioni sopra l'altoparlante al percorso dati del microfono.

Un attuatore a risonanza lineare (LRA) è un sistema a molle a singola massa che ha un frequenza di risonanza dominante, dove la massa si traduce nella direzione di movimento desiderato.

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

• [7,10/H] DOVREBBE spostare l'attuatore aptico sull'asse X (da sinistra a destra) del naturale Orientamento verticale .

Se le implementazioni dei dispositivi portatili hanno per scopo generico un attuatore aptico (LRA, linear resonant attuatore lineare asse X), questi:

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

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

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

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

• [7.10/H]* DEVE verificare e aggiornare, se necessario, il fallback per le primitive non supportate, come descritto in indicazioni per l'implementazione per le costanti.

2.2.2. Multimediale

Le implementazioni dei dispositivi portatili DEVONO supportare la codifica audio e decodificare i formati e renderli disponibili ad applicazioni di terze parti:

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] Profilo AAC MPEG-4 (AAC LC)
• [5.1/H-0-4] Profilo MPEG-4 HE AAC (AAC+)
• [5.1/H-0-5] AAC ELD (AAC a basso ritardo migliorato)

Le implementazioni dei dispositivi portatili DEVONO supportare la seguente codifica video formati e renderli disponibili ad applicazioni di terze parti:

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

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

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

2.2.3. Software

Implementazioni di dispositivi portatili:

• [3.2.3.1/H-0-1] DEVE avere un che gestisce ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, e ACTION_CREATE_DOCUMENT come descritto nei documenti relativi all'SDK e fornisce l'invito all'utente per accedere ai dati del fornitore di documenti utilizzando l'API DocumentsProvider.
• [3.2.3.1/H-0-2]* DEVE precaricare uno o più applicazioni o componenti di servizio con un gestore di intent, tutti i pattern di filtri per intent pubblici definiti dalla seguente applicazione intent elencati qui.
• [3.2.3.1/H-SR-1] Sono VIVAMENTE CONSIGLIATO di precaricare un'applicazione email in grado di gestire ACTION_SENDTO o ACTION_SEND o ACTION_SEND_MULTIPLE intent a inviare un'email.
• [3.4.1/H-0-1] DEVE fornire una risposta completa implementazione dell'API android.webkit.Webview.
• [3.4.2/H-0-1] DEVE includere un browser autonomo per la navigazione web generica di utenti.
• [3.8.1/H-SR-1] Sono VIVAMENTE CONSIGLIATE per implementare un'Avvio app predefinito che supporti il blocco delle scorciatoie in-app, widget e funzionalità widget.
• [3.8.1/H-SR-2] Sono VIVAMENTE CONSIGLIATE per implementare un'Avvio app predefinito che consenta di accedere rapidamente ai componenti aggiuntivi scorciatoie fornite da app di terze parti tramite ShortcutManager tramite Google Cloud CLI o tramite l'API Compute Engine.
• [3.8.1/H-SR-3] Sono VIVAMENTE CONSIGLIATE per includere un'app Avvio app predefinita che mostra badge per le icone delle app.
• [3.8.2/H-SR-1] Sono VIVAMENTE CONSIGLIATE per supportare i widget di app di terze parti.
• [3.8.3/H-0-1] DEVE consentire per informare gli utenti di eventi importanti tramite Notification e NotificationManager le classi API.
• [3.8.3/H-0-2] DEVE supportare le funzionalità notifiche.
• [3.8.3/H-0-3] DEVE supportare l'avviso notifiche.
• [3.8.3/H-0-4] DEVE includere un elemento area notifiche, che offre all'utente la possibilità di controllare direttamente (ad es. rispondere, posticipare, ignorare, bloccare) le notifiche tramite l'invito dell'utente, come pulsanti di azione o il pannello di controllo come implementato nell'AOSP.
• [3.8.3/H-0-5] DEVE visualizzare le scelte fornita tramite RemoteInput.Builder setChoices() nell'area notifiche.
• [3.8.3/H-SR-1] Sono VIVAMENTE CONSIGLIATE per visualizzare la prima opzione fornita tramite RemoteInput.Builder setChoices() nell'area notifiche senza ulteriori interazioni da parte dell'utente.
• [3.8.3/H-SR-2] Sono VIVAMENTE CONSIGLIATE per visualizzare tutte le scelte offerte da RemoteInput.Builder setChoices() nell'area notifiche quando l'utente espande tutte le notifiche nell'area area notifiche.
• [3.8.3.1/H-SR-1] Sono VIVAMENTE CONSIGLIATE per visualizzare le azioni per cui Notification.Action.Builder.setContextual è impostato come true in linea con le risposte visualizzate da Notification.Remoteinput.Builder.setChoices
• [3.8.4/H-SR-1] Sono VIVAMENTE CONSIGLIATE per implementare un assistente sul dispositivo per gestire l'azione di assistenza.

Se le implementazioni dei dispositivi portatili supportano le notifiche MediaStyle l'utente:

• [3.8.3.1/H-SR-2] Sono VIVAMENTE CONSIGLIATE per fornire un'autorizzazione dell'utente (ad esempio, selettore di output) a cui si accede UI di sistema che consente agli utenti di passare da un contenuto multimediale appropriato all'altro percorsi (ad esempio, dispositivi Bluetooth e percorsi forniti a MediaRouter2Manager). quando un'app pubblica una notifica MediaStyle con un token MediaSession.

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

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

Se le implementazioni dei dispositivi portatili supportano conversation notifications e li raggruppa in una sezione separata da quelli della modalità di avviso e della non conversazione silenziosa notifiche, l'utente:

• [3.8.4/H-1-1]* DEVE essere visualizzata notifiche di conversazioni prima delle notifiche non di conversazione con ad eccezione delle notifiche dei servizi in primo piano in corso importanza:alta notifiche.

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

• [3.8.10/H-1-1] DEVE visualizzare il pulsante di blocco Notifiche sullo schermo, incluso il modello di notifica multimediale.

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

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

Se le implementazioni dei dispositivi portatili includono il supporto ControlsProviderService e Control API e consentire ad applicazioni di terze parti di pubblicare controlli dei dispositivi, dopodiché:

• [3.8.16/H-1-1] DEVE dichiarare la funzionalità segnala android.software.controls e impostato su true.
• [3.8.16/H-1-2] DEVE fornire a un utente invito con la possibilità di aggiungere, modificare, selezionare e utilizzare il controlli dei dispositivi preferiti dai controlli registrati dalla terza parte tramite lo strumento ControlsProviderService e Control su quelle di livello inferiore.
• [3.8.16/H-1-3] DEVE fornire l'accesso a l'invito dell'utente entro tre interazioni da un Avvio app predefinito.

• [3.8.16/H-1-4] DEVE eseguire un rendering accurato in questa autorizzazione utente il nome e l'icona di ogni app di terze parti che fornisce i controlli tramite lo strumento ControlsProviderService dell'API di Google ed eventuali campi specificati forniti Control su quelle di livello inferiore.

• [3.8.16/H-1-5] DEVE fornire a un utente autorizzazione a disattivare l'impostazione di controlli dei dispositivi banali per l'autenticazione da i controlli registrati dalle applicazioni di terze parti tramite ControlsProviderService e Control API Control.isAuthRequired.

Al contrario, se le implementazioni dei dispositivi portatili non implementano tali controlli, l'utente:

• [3.8.16/H-2-1] DEVE segnalare null per ControlsProviderService e Control su quelle di livello inferiore.
• [3.8.16/H-2-2] DEVE dichiarare la funzionalità segnala android.software.controls e impostato su false.

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

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

Implementazioni di dispositivi portatili:

• [3.10/H-0-1] DEVE supportare l'accessibilità di terze parti i servizi di machine learning.
• [3.10/H-SR-1] È VIVAMENTE CONSIGLIATO di precaricare servizi di accessibilità sul dispositivo paragonabili o superiori a funzionalità di Switch Access e TalkBack (per le lingue supportate dal i servizi di accessibilità del motore di sintesi vocale, come forniti nella talkback aperta progetto di origine.
• [3.11/H-0-1] DEVE supportare l'installazione di di terze parti per la sintesi vocale.
• [3.11/H-SR-1] È VIVAMENTE CONSIGLIATO di includere Motore di sintesi vocale che supporta le lingue disponibili sul dispositivo.
• [3.13/H-SR-1] È VIVAMENTE CONSIGLIATO di includere Componente UI Impostazioni rapide.

Se le implementazioni dei dispositivi portatili Android dichiarano FEATURE_BLUETOOTH o assistenza di FEATURE_WIFI, questi:

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

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

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

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

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

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

Se le implementazioni dei dispositivi portatili Android dichiarano il supporto della videocamera tramite android.hardware.camera.any l'utente:

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

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

• [3.2.3.1/ H-1-1] DEVE avere un'attività che gestisca le Intent Settings#ACTION_SETTINGS_YOUR_DEEP_LINK_ACTIVITY quando la funzionalità di suddivisione è attiva. L'attività DEVE essere protetta da android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK e DEVE avvia l'attività dell'intent analizzato Impostazioni#EXTRA_SETTINGS_YOURDED_DEEP_LINK_INTENT_URI.

2.2.4. Prestazioni e potenza

• [8.1/H-0-1] Latenza fotogrammi coerente. Una latenza di frame incoerente o un ritardo nel rendering dei frame NON DEVONO verificarsi di più spesso non più di 5 frame al secondo e DEVONO essere al di sotto di 1 frame al secondo.
• [8.1/H-0-2] Latenza dell'interfaccia utente. Le implementazioni dei dispositivi DEVONO garantire un'esperienza utente a bassa latenza scorrendo una elenco di 10.000 voci dell'elenco come definito dalla suite per il test di compatibilità Android (CTS) in meno di 36 sec.
• [8.1/H-0-3] Cambio di attività. Quando sono state avviate diverse applicazioni, con il riavvio di un dopo l'avvio DEVE richiedere meno di un secondo.

Implementazioni di dispositivi portatili:

• [8.2/H-0-1] DEVE garantire che venga generata una sequenza in scrittura di almeno 5 MB/s.
• [8.2/H-0-2] DEVE garantire che venga eseguita la scrittura casuale di almeno 0,5 MB/s.
• [8.2/H-0-3] DEVE garantire una lettura sequenziale di almeno 15 MB/s.
• [8.2/H-0-4] DEVE garantire una lettura casuale di almeno 3,5 MB/s.

Se le implementazioni dei dispositivi portatili includono funzionalità per migliorare la potenza del dispositivo sistemi operativi inclusi in AOSP o che estendono le funzionalità incluse in AOSP, questi:

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

Implementazioni di dispositivi portatili:

• [8.4/H-0-1] DEVE fornire una profilo di alimentazione per componente che definisce il valore del consumo attuale di ciascun componente hardware e il consumo approssimativo della batteria causato componenti nel tempo, come documentato nel sito dell'Android Open Source Project.
• [8.4/H-0-2] DEVE segnalare tutta l'alimentazione valori di consumo in milliampere-ora (mAh).
• [8.4/H-0-3] DEVE segnalare la potenza della CPU per ogni UID di ciascun processo. Android Open Source Project soddisfa tramite l'implementazione del modulo kernel uid_cputime.
• [8.4/H-0-4] DEVE utilizzare questo consumo energetico disponibile tramite il adb shell dumpsys batterystats il comando shell allo sviluppatore dell'app.
• [8.4/H] DEVE essere attribuito alla componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.

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

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

Implementazioni di dispositivi portatili:

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

2.2.5. Modello di sicurezza

Implementazioni di dispositivi portatili:

• [9/H-0-1] DEVE dichiarare il android.hardware.security.model.compatible funzionalità.
• [9.1/H-0-1] DEVE consentire alle app di terze parti di accedere ai statistiche sull'utilizzo tramite l'autorizzazione android.permission.PACKAGE_USAGE_STATS e fornire un meccanismo accessibile all'utente per concedere o revocare l'accesso a tali app in risposta a android.settings.ACTION_USAGE_ACCESS_SETTINGS l'intento.

Implementazioni di dispositivi portatili:

• [9.11/H-0-2] DEVE eseguire il backup dell'implementazione dell'archivio chiavi con un ambiente di esecuzione isolato.
• [9.11/H-0-3] DEVE avere implementazioni di RSA, AES, Algoritmi crittografici ECDSA e HMAC e famiglia MD5, SHA1 e SHA-2 funzioni hash per un corretto supporto delle funzioni del sistema dell'archivio chiavi Android algoritmi in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L’isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante il quale il codice del kernel o dello spazio utente può accedere allo stato interno isolato, inclusa la DMA. L'open source di Android a monte Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o sicurezza esaminata da terze parti l'implementazione di un adeguato isolamento basato su hypervisor sono le opzioni di CPU e memoria disponibili.
• [9.11/H-0-4] DEVE eseguire la schermata di blocco l'autenticazione nell'ambiente di esecuzione isolato e solo quando operazione riuscita, consenti l'utilizzo delle chiavi legate all'autenticazione. Schermata di blocco le credenziali DEVONO essere archiviate in un modo che consenta solo l'esecuzione isolata. per eseguire l'autenticazione della schermata di blocco. L'upstream di Android Open Source Project fornisce Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
• [9.11/H-0-5] DEVE supportare l'attestazione chiave in cui la chiave di firma dell'attestazione è protetta da un hardware sicuro e la firma in un hardware protetto. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficiente di dispositivi da impedire l'utilizzo delle chiavi come identificatori dei dispositivi. Un modo per soddisfare questo requisito è condividere stessa chiave di attestazione,a meno che non vengano prodotto. Se vengono prodotte più di 100.000 unità di uno SKU, verrà chiave POTREBBE essere utilizzata per ogni 100.000 unità.

Tieni presente che se l'implementazione di un dispositivo è già stata avviata su un dispositivo Android precedente non è richiesto un archivio chiavi. supportata da un ambiente di esecuzione isolato e che supportano l'attestazione chiave, a meno che non dichiari la funzionalità android.hardware.fingerprint che richiede un archivio chiavi supportato da un ambiente di esecuzione isolato.

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

• [9.11/H-1-1] DEVE consentire all'utente di scegliere il video più breve timeout di sospensione, ovvero un tempo di transizione dallo stato sbloccato allo stato non superiore a 15 secondi.
• [9.11/H-1-2] DEVE fornire all'utente l'invito per nascondere notifiche e disattivare tutte le forme di autenticazione, ad eccezione di dell'autenticazione principale descritta in 9.11.1 Schermata di blocco sicura. L'AOSP soddisfa requisito come modalità di blocco.

Se le implementazioni sui dispositivi portatili includono più utenti e non dichiarano il flag funzionalità android.hardware.telephony, l'elemento:

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

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

• [9.5/H-3-1] NON DEVE supportare funzionalità limitate profili, ma DEVONO allinearsi con l'implementazione AOSP dei controlli per abilitare /disabilitare l'accesso di altri utenti alle chiamate vocali e agli SMS.

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

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

• [9.8/H-1-1] DEVE assicurarsi che il servizio di rilevamento hotword possa trasmettere solo i dati al sistema, ContentCaptureService, o un servizio di riconoscimento vocale sul dispositivo creato SpeechRecognizer#createOnDeviceSpeechRecognizer(),
• [9.8/H-1-2] DEVE assicurarsi che il servizio di rilevamento hotword possa trasmettere solo i dati audio del microfono o i dati da esso derivati al server di sistema tramite API HotwordDetectionService o a ContentCaptureService tramite API ContentCaptureManager.
• [9.8/H-1-3] NON DEVE fornire un audio del microfono superiore a 30 secondi per un singola richiesta attivata dall'hardware al servizio di rilevamento hotword.
• [9.8/H-1-4] NON DEVE fornire audio microfono con buffer più vecchio di 8 secondi per un una singola richiesta al servizio di rilevamento hotword.
• [9.8/H-1-5] NON DEVE fornire audio del microfono con buffer più vecchio di 30 secondi alla servizio di interazione vocale o entità simile.
• [9.8/H-1-6] NON DEVE consentire più di 100 byte di dati da trasmettere dal servizio di rilevamento hotword su ogni risultato della hotword tranne che per i dati audio trasmessi HotwordAudioStream.
• [9.8/H-1-7] NON DEVE consentire la trasmissione di più di 5 bit di dati all’esterno del servizio di rilevamento hotword su ogni risultato negativo della hotword.
• [9.8/H-1-8] DEVE consentire solo la trasmissione di dati dalla hotword di rilevamento di una richiesta di convalida della hotword dal server di sistema.
• [9.8/H-1-9] NON DEVE consentire a un'applicazione installabile dall'utente di fornire il di rilevamento hotword.
• [9.8/H-1-10] NON DEVE apparire nell'UI dei dati quantitativi sull'utilizzo del microfono da il servizio di rilevamento hotword.
• [9.8/H-1-11] DEVE registrare il numero di byte inclusi in ogni trasmissione dal servizio di rilevamento hotword per consentire l'ispezione per la sicurezza i ricercatori.
• [9.8/H-1-12] DEVE supportare una modalità di debug che registri i contenuti non elaborati di ogni dal servizio di rilevamento hotword per consentire l'ispezione degli ricercatori di sicurezza.
• [9.8/H-1-14] DEVE visualizzare l'indicatore del microfono, come descritto nella sezione 9.8.2, quando viene trasmesso alla voce un risultato della hotword con successo. un servizio di interazione o un'entità simile.

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

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

• [9.8/H-2-1] DEVE fornire all'utente una notifica esplicita per ogni frase della hotword supportati.
• [9.8/H-2-2] NON DEVE conservare i dati audio non elaborati o i dati da essi derivanti, attraverso il servizio di rilevamento hotword.
• [9.8/H-2-3] NON DEVE trasmettere dal servizio di rilevamento hotword, audio dati utilizzabili per ricostruire (completamente o parzialmente) l'audio, o contenuti audio non correlati alla hotword stessa, ad eccezione delle ContentCaptureService o voce sul dispositivo di riconoscimento dei volti delle celebrità basata su rigidi criteri di controllo.

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

• [9.8.2/H-4-1] DEVE visualizzare l'indicatore del microfono quando un'app accede ai dati audio dal microfono, ma non quando microfono è accessibile solo da HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService o app con i ruoli chiamati nella sezione 9.1 con l'identificatore CDD [C-4-X].
• [9.8.2/H-4-2] DEVE visualizzare l'elenco delle categorie Recenti e Attive di app che usano il microfono restituito PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali attribuzioni messaggi associati.

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

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

2.2.6. Compatibilità degli strumenti e delle opzioni per sviluppatori

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

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

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

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

2.2.7. Classe prestazioni contenuti multimediali portatili

Consulta la Sezione 7.11 per la definizione di classe di prestazione multimediale.

2.2.7.1. Contenuti multimediali

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

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

2.2.7.2. Fotocamera

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

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

2.2.7.3. Hardware

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

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

2.2.7.4. Prestazioni

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

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

2.3. Requisiti per la televisione

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

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

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

I requisiti aggiuntivi nel resto di questa sezione sono specifici per Android Implementazioni di dispositivi televisivi.

2.3.1. Hardware

Implementazioni di dispositivi televisivi:

• [7.2.2/T-0-1] DEVE supportare D-pad.
• [7.2.3/T-0-1] DEVE fornire i parametri Home e Back funzioni.
• [7.2.3/T-0-2] DEVE inviare sia la pressione normale che quella lunga evento della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano.
• [7.2.6.1/T-0-1] DEVE includere il supporto del gioco di controllo e dichiarano il flag della funzionalità android.hardware.gamepad.
• [7.2.7/T] DOVREBBE fornire un telecomando da cui gli utenti possono accedere alla navigazione non touch e input dei tasti di navigazione principali.

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

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

Implementazioni di dispositivi televisivi:

• [7.4.3/T-0-1] DEVE supportare il Bluetooth e Bluetooth LE
• [7.6.1/T-0-1] DEVE avere almeno 4 GB di archiviazione permanente disponibile per i dati privati delle applicazioni (ovvero partizione "/data").

Se le implementazioni dei televisori includono una porta USB che supporta la modalità host, l'utente:

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

Se le implementazioni sui dispositivi TV sono a 32 bit:

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

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

Se le implementazioni sui dispositivi TV sono a 64 bit:

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

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

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

Implementazioni di dispositivi televisivi:

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

2.3.2. Multimediale

Le implementazioni dei dispositivi televisivi DEVONO supportare la seguente codifica audio e decodificare i formati e renderli disponibili ad applicazioni di terze parti:

• [5.1/T-0-1] Profilo AAC MPEG-4 (AAC LC)
• [5.1/T-0-2] Profilo MPEG-4 HE AAC (AAC+)
• [5.1/T-0-3] AAC ELD (AAC a basso ritardo migliorato)

Le implementazioni dei dispositivi televisivi DEVONO supportare la seguente codifica video formati e renderli disponibili ad applicazioni di terze parti:

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

Implementazioni di dispositivi televisivi:

• [5.2.2/T-SR-1] È VIVAMENTE CONSIGLIATA all'assistenza Codifica H.264 per video con risoluzione 720p e 1080p a 30 frame al secondo.

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

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

Le implementazioni dei dispositivi televisivi DEVONO supportare la decodifica MPEG-2, come descritto in dettaglio Sezione 5.3.1, alle frequenze fotogrammi e alle risoluzioni standard per i video fino e tra cui:

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

Le implementazioni dei dispositivi televisivi DEVONO supportare la decodifica H.264, come descritto in dettaglio nella Sezione 5.3.4, a frequenze fotogrammi e risoluzioni standard per i video fino e tra cui:

• [5.3.4/T-1-1] HD 1080p a 60 frame al secondo con Profilo di riferimento
• [5.3.4/T-1-2] HD 1080p a 60 frame al secondo con Profilo principale
• [5.3.4/T-1-3] HD 1080p a 60 frame al secondo con Profilo alto livello 4.2

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

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

Se le implementazioni di dispositivi televisivi con decoder hardware H.265 supportano Decodifica H.265 e profilo di decodifica UHD, questi:

• [5.3.5/T-2-1] DEVE supportare il profilo di decodifica UHD a 60 frame al secondo con il profilo 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 frequenze fotogrammi e risoluzioni standard per i video fino e tra cui:

• [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 il protocollo VP9 come descritto nella Sezione 5.3.7, a frequenze fotogrammi video standard e risoluzioni fino a:

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

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

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

Implementazioni di dispositivi televisivi:

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

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

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

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

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

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

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

2.3.3. Software

Implementazioni di dispositivi televisivi:

• [3/T-0-1] DEVE dichiarare le caratteristiche android.software.leanback e android.hardware.type.television.
• [3.2.3.1/T-0-1] DEVE precaricare uno o più applicazioni o componenti di servizio con un gestore di intent, per tutte le Pattern di filtro per intent pubblici definiti dai seguenti intent dell'applicazione elencati qui.
• [3.4.1/T-0-1] DEVE fornire un indirizzo completo implementazione 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 il pulsante di blocco Notifiche sullo schermo, incluso il modello di notifica multimediale.

Implementazioni di dispositivi televisivi:

• [3.8.14/T-SR-1] Sono VIVAMENTE CONSIGLIATE per supportare la modalità multi-finestra in modalità Picture in picture (PIP).
• [3.10/T-0-1] DEVE supportare l'accessibilità di terze parti i servizi di machine learning.
• [3.10/T-SR-1] È VIVAMENTE CONSIGLIATO a precarica i servizi di accessibilità sul dispositivo in modo comparabile o superiore di Switch Access e TalkBack (per le lingue supportate il motore di sintesi vocale preinstallato), come previsto dalle nel progetto open source TalkBack.

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

• [3.11/T-SR-1] È VIVAMENTE CONSIGLIATO di includere Motore di sintesi vocale che supporta le lingue disponibili sul dispositivo.
• [3.11/T-1-1] DEVE supportare l'installazione di di terze parti per la sintesi vocale.

Implementazioni di dispositivi televisivi:

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

2.3.4. Prestazioni e potenza

• [8.1/T-0-1] Latenza fotogrammi coerente. Una latenza di frame incoerente o un ritardo nel rendering dei frame NON DEVONO verificarsi di più spesso non più di 5 frame al secondo e DEVONO essere al di sotto di 1 frame al secondo.
• [8.2/T-0-1] DEVE garantire che venga fornita una in scrittura di almeno 5 MB/s.
• [8.2/T-0-2] DEVE garantire che venga eseguita la scrittura casuale e prestazioni di almeno 0,5 MB/s.
• [8.2/T-0-3] DEVE garantire che venga fornita una di lettura di almeno 15 MB/s.
• [8.2/T-0-4] DEVE garantire una lettura casuale e prestazioni di almeno 3,5 MB/s.

Se le implementazioni dei dispositivi televisivi includono funzioni per migliorare la potenza del dispositivo sistemi operativi inclusi in AOSP o che estendono le funzionalità incluse in AOSP, questi:

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

Se le implementazioni dei dispositivi televisivi non hanno una batteria:

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

Se le implementazioni dei dispositivi televisivi:

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

Implementazioni di dispositivi televisivi:

• [8.4/T-0-1] DEVE fornire una profilo di alimentazione per componente che definisce il valore del consumo attuale di ciascun componente hardware e il consumo approssimativo della batteria causato componenti nel tempo, come documentato nel sito dell'Android Open Source Project.
• [8.4/T-0-2] DEVE segnalare tutta l'alimentazione valori di consumo in milliampere-ora (mAh).
• [8.4/T-0-3] DEVE segnalare la potenza della CPU per ogni UID di ciascun processo. Android Open Source Project soddisfa tramite l'implementazione del modulo kernel uid_cputime.
• [8.4/T] DEVE essere attribuita alla componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.
• [8.4/T-0-4] DEVE utilizzare questo consumo energetico disponibile tramite il adb shell dumpsys batterystats il comando shell allo sviluppatore dell'app.

2.3.5. Modello di sicurezza

Implementazioni di dispositivi televisivi:

• [9/T-0-1] DEVE dichiarare il android.hardware.security.model.compatible funzionalità.
• [9.11/T-0-1] DEVE eseguire il backup dell'implementazione dell'archivio chiavi con un ambiente di esecuzione isolato.
• [9.11/T-0-2] DEVE avere implementazioni di RSA, AES, Algoritmi crittografici ECDSA e HMAC e famiglia MD5, SHA1 e SHA-2 funzioni hash per un corretto supporto delle funzioni del sistema dell'archivio chiavi Android algoritmi in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L’isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante il quale il codice del kernel o dello spazio utente può accedere allo stato interno isolato, inclusa la DMA. L'open source di Android a monte Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o sicurezza esaminata da terze parti l'implementazione di un adeguato isolamento basato su hypervisor sono le opzioni di CPU e memoria disponibili.
• [9.11/T-0-3] DEVE eseguire la schermata di blocco l'autenticazione nell'ambiente di esecuzione isolato e solo quando operazione riuscita, consenti l'utilizzo delle chiavi legate all'autenticazione. Schermata di blocco le credenziali DEVONO essere archiviate in un modo che consenta solo l'esecuzione isolata. per eseguire l'autenticazione della schermata di blocco. L'upstream di Android Open Source Project fornisce Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
• [9.11/T-0-4] DEVE supportare l'attestazione chiave in cui la chiave di firma dell'attestazione è protetta da un hardware sicuro e la firma in un hardware protetto. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficiente di dispositivi da impedire l'utilizzo delle chiavi come identificatori dei dispositivi. Un modo per soddisfare questo requisito è condividere stessa chiave di attestazione,a meno che non vengano prodotto. Se vengono prodotte più di 100.000 unità di uno SKU, verrà chiave POTREBBE essere utilizzata per ogni 100.000 unità.

Tieni presente che se l'implementazione di un dispositivo è già stata avviata su un dispositivo Android precedente non è richiesto un archivio chiavi. supportata da un ambiente di esecuzione isolato e che supportano l'attestazione chiave, a meno che non dichiari la funzionalità android.hardware.fingerprint che richiede un archivio chiavi supportato da un ambiente di esecuzione isolato.

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

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

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

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

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

• [9.5/T-3-1] NON DEVE supportare funzionalità limitate profili, ma DEVONO allinearsi con l'implementazione AOSP dei controlli per abilitare /disabilitare l'accesso di altri utenti alle chiamate vocali e agli SMS.

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

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

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

• [9.8.2/T-5-1] DEVE visualizzare l'indicatore della fotocamera quando accede ai dati in diretta della videocamera, ma non quando la videocamera è a cui accedono le app che hanno i ruoli descritti nella Sezione 9.1 Autorizzazioni con identificatore CDD [C-3-X].
• [9.8.2/T-5-2] Non DEVE nascondere l'indicatore della fotocamera per app di sistema con interfacce utente visibili o interazione diretta degli utenti.

2.3.6. Compatibilità degli strumenti e delle opzioni per sviluppatori

Implementazioni di dispositivi televisivi:

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

2.4. Requisiti dell'orologio

Un dispositivo Android Watch fa riferimento a un'implementazione del dispositivo Android che essere indossato sul corpo, forse al polso.

Le implementazioni sui dispositivi Android sono classificate come smartwatch se soddisfano tutte le i seguenti criteri:

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

I requisiti aggiuntivi nel resto di questa sezione sono specifici per Android Implementazioni dispositivo dell'orologio.

2.4.1. Hardware

Implementazioni dell'orologio:

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

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

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

• [7.3.1/W-SR-1] È VIVAMENTE CONSIGLIATO di includere i componenti a 3 assi sull'accelerometro.

Se le implementazioni dello smartwatch includono un ricevitore GPS/GNSS e segnali il alle applicazioni tramite la funzionalità android.hardware.location.gps flag:

• [7.3.3/W-1-1] DEVONO riportare le misurazioni GNSS, non appena vengono anche se non è stata ancora segnalata una posizione calcolata da GPS/GNSS.
• [7.3.3/W-1-2] DEVE segnalare gli pseudorange e lo pseudointervallo del GNSS le tariffe, che in condizioni di cielo aperto dopo aver determinato la posizione, mentre se fermo o in movimento con una velocità inferiore a 0,2 m al secondo quadrato dell'accelerazione, 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 dello smartwatch includono un giroscopio a 3 assi:

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

Implementazioni dell'orologio:

• [7.4.3/W-0-1] DEVE supportare il Bluetooth.

• [7.6.1/W-0-1] DEVE avere almeno 1 GB di spazio di archiviazione permanente disponibile per i dati privati delle applicazioni (ovvero partizione "/data").

• [7.6.1/W-0-2] DEVE avere almeno 416 MB di memoria disponibile per il kernel e lo spazio utente.

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

• [7.8.2/W] POTREBBE avere un'uscita audio.

2.4.2. Multimediale

Nessun altro requisito.

2.4.3. Software

Implementazioni dell'orologio:

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

Implementazioni dell'orologio:

• [3.8.4/W-SR-1] Sono VIVAMENTE CONSIGLIATE per implementare un assistente sul dispositivo per gestire l'azione di assistenza.

Implementazioni su dispositivi dell'orologio che dichiarano l'android.hardware.audio.output flag funzionalità:

• [3.10/W-1-1] DEVE supportare l'accessibilità di terze parti i servizi di machine learning.
• [3.10/W-SR-1] È VIVAMENTE CONSIGLIATO di precaricare servizi di accessibilità sul dispositivo paragonabili o superiori a funzionalità di Switch Access e TalkBack (per le lingue supportate dal i servizi di accessibilità del motore di sintesi vocale), così come forniti nei progetto open source TalkBack.

Se le implementazioni dello smartwatch segnalano la funzionalità android.hardware.audio.output, l'utente:

• [3.11/W-SR-1] È VIVAMENTE CONSIGLIATO di includere Motore di sintesi vocale che supporta le lingue disponibili sul dispositivo.

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

2.4.4. Prestazioni e potenza

Se le implementazioni dello smartwatch includono funzionalità per migliorare la potenza del dispositivo sistemi operativi inclusi in AOSP o che estendono le funzionalità incluse in AOSP, questi:

• [8.3/W-SR-1] È VIVAMENTE CONSIGLIATO di fornire autorizzazione dell'utente per visualizzare tutte le app esenti da Standby delle app e Sospensione delle modalità di risparmio energetico.
• [8.3/W-SR-2] È VIVAMENTE CONSIGLIATO di fornire invito dell'utente ad attivare e disattivare la funzione di risparmio energetico.

Implementazioni dell'orologio:

• [8.4/W-0-1] DEVE fornire una profilo di alimentazione per componente che definisce il valore del consumo attuale di ciascun componente hardware e il consumo approssimativo della batteria causato componenti nel tempo, come documentato nel sito dell'Android Open Source Project.
• [8.4/W-0-2] DEVE segnalare tutta l'alimentazione valori di consumo in milliampere-ora (mAh).
• [8.4/W-0-3] DEVE segnalare la potenza della CPU per ogni UID di ciascun processo. Android Open Source Project soddisfa tramite l'implementazione del modulo kernel uid_cputime.
• [8.4/W-0-4] DEVE utilizzare questo consumo energetico disponibile tramite il adb shell dumpsys batterystats il comando shell allo sviluppatore dell'app.
• [8.4/W] DOVREBBE essere attribuite alle componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.

2.4.5. Modello di sicurezza

Implementazioni dell'orologio:

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

Se le implementazioni sui dispositivi Watch includono più utenti e non dichiarano il flag funzionalità android.hardware.telephony, l'elemento:

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

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

• [9.5/W-2-1] NON DEVE supportare funzionalità limitate profili, ma DEVONO allinearsi con l'implementazione AOSP dei controlli per abilitare /disabilitare 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 all'unità principale del veicolo in esecuzione Android come sistema operativo per tutto o parte del sistema e/o funzionalità di infotainment.

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

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

I requisiti aggiuntivi nel resto di questa sezione sono specifici per Android Implementazioni di dispositivi nel settore auto e motori.

2.5.1. Hardware

Implementazioni di dispositivi nel settore auto e motori:

• [7.1.1.1/A-0-1] DEVE avere uno schermo di almeno 6 pollici di diagonale.
• [7.1.1.1/A-0-2] DEVE avere un layout a dimensioni dello schermo di almeno 750 x 480 dp.
• [7.2.3/A-0-1] DEVE fornire la funzione Home e POTREBBE fornire le funzioni Indietro e Recenti.
• [7.2.3/A-0-2] DEVE inviare sia la pressione normale che quella lunga evento 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 parametro NIGHT_MODE il flag DEVE essere coerente con la modalità giorno/notte della dashboard e DEVE essere basato su input del sensore di luce ambientale. Il sensore di luce ambientale sottostante POTREBBE essere lo stesso come Fotometro.
• [7.3/A-0-3] DEVE fornire un campo informativo aggiuntivo sul sensore TYPE_SENSOR_PLACEMENT come parte delle informazioni aggiuntive del sensore per ogni sensore fornito.
• [7.3/A-SR1] POTREBBE ASPETTATIVA Posizione unendo GPS/GNSS a sensori aggiuntivi. Se Località è decisamente valutato, è VIVAMENTE CONSIGLIATO di implementare e segnalare Sensor corrispondente tipi e/o ID proprietà del veicolo in uso.

• [7.3/A-0-4] La posizione richiesto tramite LocationManager#requestLocationUpdates() NON DEVE essere abbinata alla mappa.

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

• [7.3/A-SR-1] È StrongLY_CONSIGLIATO di includere i tre assi accelerometro e giroscopio a 3 assi.

• [7.3/A-SR-2] È SOLTANTO_CONSIGLIATO l'implementazione e la segnalazione Sensore TYPE_HEADING.

Se le implementazioni dei dispositivi Automotive supportano OpenGL ES 3.1:

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

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

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

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

• [7.3.1/A-SR-1] È VIVAMENTE CONSIGLIATO di implementare le sensore composito per accelerometro ad asse limitato.

Se le implementazioni dei dispositivi Automotive includono un accelerometro con meno di su 3 assi:

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

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

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

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

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

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

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

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

• [7.3.3/A-3-1] DEVE determinare la posizione la prima volta il ricevitore GPS/GNSS sia acceso o dopo più di 4 giorni entro 60 secondi.
• [7.3.3/A-3-2] DEVE soddisfare i criteri relativi alla prima correzione, come descritto in 7.3.3/C-1-2 e 7.3.3/C-1-6 per tutte le altre richieste di posizione (ovvero richieste che non sono la prima volta in qualsiasi momento o dopo più di 4 giorni). Il requisito 7.3.3/C-1-2 è di solito si incontrano su veicoli senza connettività dati basata su una rete mobile, utilizzando le previsioni dell'orbita GNSS calcolate sul ricevitore o utilizzando l'ultima posizione nota di un veicolo, oltre alla possibilità di fare il conto per almeno 60 secondi con una precisione della posizione soddisfacente 7.3.3/C-1-3 o una combinazione di entrambe.

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

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

Implementazioni di dispositivi nel settore auto e motori:

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

• [7.4.3/A-SR-1] È VIVAMENTE CONSIGLIATA all'assistenza Profilo di accesso ai messaggi (MAP).

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

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

Implementazioni di dispositivi nel settore auto e motori:

• [7.6.1/A-0-1] DEVE avere almeno 4 GB di archiviazione permanente disponibile per i dati privati delle applicazioni (ovvero partizione "/data").

• [7.6.1/A] È necessario formattare la partizione dati per offrire prestazioni migliori e longevità dell'archiviazione flash, ad esempio utilizzando il file system f2fs.

Se le implementazioni dei dispositivi Automotive forniscono uno spazio di archiviazione esterno condiviso tramite un parte della memoria interna non rimovibile, questi:

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

Se le implementazioni dei dispositivi Automotive sono a 64 bit:

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

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

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

  • xhdpi o superiore su schermi piccoli/normali
  • hdpi o superiore su schermi grandi
  • mdpi o superiore su schermi molto grandi

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

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

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

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

Tieni presente che la "memoria disponibile per il kernel e lo spazio utente" di cui sopra si riferisce di memoria fornita oltre a quella già dedicata all'hardware come radio, video e così via, che non si trovano nel kernel sulle implementazioni dei dispositivi.

Implementazioni di dispositivi nel settore auto e motori:

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

Implementazioni di dispositivi nel settore auto e motori:

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

Implementazioni di dispositivi nel settore auto e motori:

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

2.5.2. Multimediale

Le implementazioni dei dispositivi automobilistici DEVONO supportare la seguente codifica audio e decodificare i formati e renderli disponibili ad applicazioni di terze parti:

• [5.1/A-0-1] Profilo AAC MPEG-4 (AAC LC)
• [5.1/A-0-2] Profilo MPEG-4 HE AAC (AAC+)
• [5.1/A-0-3] AAC ELD (AAC a basso ritardo migliorato)

Le implementazioni dei dispositivi per auto e motori DEVONO supportare la seguente codifica video formati e renderli disponibili ad applicazioni di terze parti:

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

Le implementazioni dei dispositivi per auto e motori DEVONO supportare la seguente decodifica video formati e renderli disponibili ad applicazioni di terze parti:

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

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

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

2.5.3. Software

Implementazioni di dispositivi nel settore auto e motori:

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

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

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

Se le implementazioni dei dispositivi Automotive forniscono un'API proprietaria utilizzando android.car.CarPropertyManager con android.car.VehiclePropertyIds, l'utente:

• [3/A-1-1] NON DEVE assegnare privilegi speciali al sistema l'utilizzo di tali proprietà da parte dell'applicazione o impedire ad applicazioni di terze parti dall'utilizzo di queste proprietà.
• [3/A-1-2] NON DEVE replicare la proprietà di un veicolo che già esiste nell'SDK.

Implementazioni di dispositivi nel settore auto e motori:

• [3.2.1/A-0-1] DEVE supportare e applicare in modo forzato tutti costanti di autorizzazioni come documentato nella pagina di riferimento delle autorizzazioni automobilistiche.

• [3.2.3.1/A-0-1] DEVE precaricare uno o più applicazioni o componenti di servizio con un gestore di intent, per tutte le Pattern di filtro per intent pubblici definiti dai seguenti intent dell'applicazione elencati qui.

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

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

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

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

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

Implementazioni di dispositivi nel settore auto e motori:

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

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

• [3.9.3/A-1-1] DEVE implementare tutte le Proprietà del ciclo di vita degli utenti
  • INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

Implementazioni di dispositivi nel settore auto e motori:

• [3.14/A-0-1] DEVE includere un framework dell'interfaccia utente per supportare app di terze parti che usano le API multimediali, come descritto nella sezione 3.14.
• [3.14/A-0-2] DEVE consentire all'utente di interagire in modo sicuro con applicazioni multimediali durante la guida.
• [3.14/A-0-3] DEVE supportare il protocollo CAR_INTENT_ACTION_MEDIA_TEMPLATE l'azione Intent implicito con CAR_EXTRA_MEDIA_PACKAGE extra.
• [3.14/A-0-4] DEVE fornire un'invito per entrare di un'applicazione multimediale preferenza attività, ma DEVE abilitarla solo quando le Limitazioni UX dell'auto non sono attive.
• [3.14/A-0-5] DEVE visualizzare messaggi di errore impostati da Applicazioni multimediali e DEVONO supportare gli extra facoltativi ERROR_RESOLUTION_ACTION_LABEL e ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] DEVE supportare un'invito di ricerca in-app per di app che supportano la ricerca.
• [3.14/A-0-7] DEVE rispettare CONTENT_STYLE_BROWSABLE_HINT e CONTENT_STYLE_PLAYABLE_HINT definizioni durante la visualizzazione di MediaBrowser nella gerarchia.

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

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

Implementazioni di dispositivi nel settore auto e motori:

• [3.8/A] POTREBBE limitare l'applicazione richiede di attivare la modalità a schermo intero come descritto in immersive documentation.
• [3.8/A] POTREBBE mantenere la barra di stato e la barra di navigazione sempre visibile.
• [3.8/A] POTREBBE limitare l'applicazione richiede di modificare i colori dietro gli elementi dell'interfaccia utente di sistema, per garantire questi elementi siano chiaramente visibili in ogni momento.

2.5.4. Prestazioni e potenza

Implementazioni di dispositivi nel settore auto e motori:

• [8.2/A-0-1] DEVE segnalare il numero di byte letti e scritti nello spazio di archiviazione permanente per l'UID di ciascun processo, in modo che le statistiche sono disponibili per gli sviluppatori tramite l'API di sistema android.car.storagemonitoring.CarStorageMonitoringManager. The Android Open Il progetto di origine soddisfa il requisito tramite il modulo kernel uid_sys_stats.
• [8.3/A-1-3] DEVE supportare la modalità Garage.
• [8.3/A] DOVREBBE essere in modalità garage per almeno 15 minuti dopo ogni guida, a meno che:
  • La batteria è scarica.
  • Nessun job inattivo pianificato.
  • Il conducente esce dalla modalità Garage.
• [8.4/A-0-1] DEVE fornire una profilo di alimentazione per componente che definisce il valore del consumo attuale di ciascun componente hardware e il consumo approssimativo della batteria causato componenti nel tempo, come documentato nel sito dell'Android Open Source Project.
• [8.4/A-0-2] DEVE segnalare tutta l'alimentazione valori di consumo in milliampere-ora (mAh).
• [8.4/A-0-3] DEVE segnalare l'alimentazione della CPU per ogni UID di ciascun processo. Android Open Source Project soddisfa tramite l'implementazione del modulo kernel uid_cputime.
• [8.4/A] DEVE essere attribuita ai componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.
• [8.4/A-0-4] DEVE utilizzare questo consumo energetico disponibile tramite il adb shell dumpsys batterystats il comando shell allo sviluppatore dell'app.

2.5.5. Modello di sicurezza

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

• [9.5/A-1-1] NON DEVE consentire agli utenti di interagire con né passare a Headless System User, tranne il provisioning dei dispositivi.
• [9.5/A-1-2] DEVE passare a Utente secondario prima del giorno BOOT_COMPLETED.
• [9.5/A-1-3] DEVE supportare la possibilità di creare un utente ospite anche quando è stato raggiunto il numero massimo di utenti su un dispositivo.

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

• [9.8.2/A-2-1] DEVE visualizzare l'indicatore della fotocamera quando accede ai dati in diretta della videocamera, ma non quando la videocamera viene a cui si accede da una o più app che hanno i ruoli come chiamato in Sezione 9.1 Autorizzazioni con identificatore CDD [C-4-X][C-3-X].
• [9.8.2/A-2-2] Non DEVE nascondere l'indicatore della fotocamera per app di sistema con interfacce utente visibili o interazione diretta degli utenti.

Implementazioni di dispositivi nel settore auto e motori:

• [9/A-0-1] DEVE dichiarare il android.hardware.security.model.compatible funzionalità.
• [9.11/A-0-1] DEVE eseguire il backup dell'implementazione dell'archivio chiavi con un ambiente di esecuzione isolato.
• [9.11/A-0-2] DEVE avere implementazioni di RSA, AES, Algoritmi crittografici ECDSA e HMAC e famiglia MD5, SHA1 e SHA-2 funzioni hash per un corretto supporto delle funzioni del sistema dell'archivio chiavi Android algoritmi in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L’isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante il quale il codice del kernel o dello spazio utente può accedere allo stato interno isolato, inclusa la DMA. L'open source di Android a monte Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o sicurezza esaminata da terze parti l'implementazione di un adeguato isolamento basato su hypervisor sono le opzioni di CPU e memoria disponibili.
• [9.11/A-0-3] DEVE eseguire la schermata di blocco l'autenticazione nell'ambiente di esecuzione isolato e solo quando operazione riuscita, consenti l'utilizzo delle chiavi legate all'autenticazione. Schermata di blocco le credenziali DEVONO essere archiviate in un modo che consenta solo l'esecuzione isolata. per eseguire l'autenticazione della schermata di blocco. L'upstream di Android Open Source Project fornisce Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
• [9.11/A-0-4] DEVE supportare l'attestazione chiave in cui la chiave di firma dell'attestazione è protetta da un hardware sicuro e la firma in un hardware protetto. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficiente di dispositivi da impedire l'utilizzo delle chiavi come identificatori dei dispositivi. Un modo per soddisfare questo requisito è condividere stessa chiave di attestazione,a meno che non vengano prodotto. Se vengono prodotte più di 100.000 unità di uno SKU, verrà chiave POTREBBE essere utilizzata per ogni 100.000 unità.

Tieni presente che se l'implementazione di un dispositivo è già stata avviata su un dispositivo Android precedente non è richiesto un archivio chiavi. supportata da un ambiente di esecuzione isolato e che supportano l'attestazione chiave, a meno che non dichiari la funzionalità android.hardware.fingerprint che richiede un un archivio chiavi supportato da un ambiente di esecuzione isolato.

Implementazioni di dispositivi nel settore auto e motori:

• [9.14/A-0-1] I messaggi DEVONO essere gestiti dal gatekeep da sottosistemi di veicoli del framework Android, ad esempio l'inserimento nella lista consentita dei messaggi consentiti tipi e origini dei messaggi.
• [9.14/A-0-2] DEVE essere il watchdog attacchi DoS da parte del framework Android o di app di terze parti. Questo protegge la rete del veicolo da software dannosi, il che potrebbe causare il malfunzionamento dei sottosistemi del veicolo.

2.5.6. Compatibilità degli strumenti e delle opzioni per sviluppatori

Implementazioni di dispositivi nel settore auto e motori:

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

2.6. Requisiti per i tablet

Un dispositivo tablet Android fa riferimento a un'implementazione su dispositivo Android che soddisfa generalmente tutti i seguenti criteri:

• Si usa tenendole con entrambe le mani.
• Non ha una configurazione clamshell o convertibile.
• Implementazioni della tastiera fisica utilizzate con la connessione del dispositivo tramite una connessione standard (ad es. USB, Bluetooth).

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

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

Le implementazioni dei tablet hanno requisiti simili a quelli dei dispositivi portatili implementazioni. Le eccezioni sono indicate con un asterisco (*) in questa sezione. come riferimento in questa sezione.

2.6.1. Hardware

Giroscopio

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

• [7.3.4/Tab-1-1] DEVE essere in grado di misurare l'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 del dispositivo portatile non sono applicabili ai tablet.

Modalità periferica USB (Sezione 7.7.1)

Se le implementazioni dei tablet includono una porta USB che supporta una periferica modalità, l'utente:

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

Modalità di realtà virtuale (Sezione 7.9.1)

Prestazioni elevate di realtà virtuale (Sezione 7.9.2)

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

2.6.2. Modello di sicurezza

Chiavi e credenziali (Sezione 9.11)

Consulta la Sezione [9.11].

Se le implementazioni sui tablet includono più utenti e non dichiarano il flag funzionalità android.hardware.telephony, l'elemento:

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

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

• [9.5/T-2-1] NON DEVE supportare funzionalità limitate profili, ma DEVONO allinearsi con l'implementazione AOSP dei controlli per abilitare /disabilitare 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ù applicazioni o componenti di servizio con un gestore di intent, per tutte le Pattern di filtro per intent pubblici definiti dai seguenti intent dell'applicazione elencati qui.

3. Software

3.1. Compatibilità delle API gestite

L'ambiente di esecuzione bytecode Dalvik gestito è il veicolo principale App per Android L'API (Application Programming Interface, interfaccia di programmazione di un'applicazione) di Android è di interfacce della piattaforma Android esposte alle applicazioni in esecuzione un ambiente di runtime gestito.

Implementazioni dei dispositivi:

• [C-0-1] DEVE fornire implementazioni complete, compresi tutti i documenti comportamentali, di qualsiasi API documentata esposta dall'SDK per Android o qualsiasi API decorata con l'indicatore "@SystemApi" nell'upstream di Android codice sorgente.

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

• [C-0-3] NON DEVE omettere API gestite, modificare le interfacce o le firme delle API, si discostano dal comportamento documentato o non prevedono operazioni, ad eccezione dei casi in cui specificatamente consentiti da questa Definizione di compatibilità.

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

• [C-0-5] NON DEVE consentire ad app di terze parti di usare interfacce non SDK, che sono definiti come metodi e campi nei pacchetti di linguaggio Java, nel classpath di avvio in AOSP e che non fanno parte del l'SDK. Sono incluse le API decorate con l'annotazione @hide ma non con un @SystemAPI, come descritto nei documenti dell'SDK privati e privati del pacchetto.

• [C-0-6] DEVE essere fornita con ogni interfaccia non SDK nello stesso account come forniti tramite i flag provvisori e di lista bloccata in prebuilts/runtime/appcompat/hiddenapi-flags.csv del ramo del livello API appropriato in AOSP.

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

  Tuttavia:

  • MAGGIO, se un'API nascosta non è presente o implementata in modo diverso sul dispositivo , sposta l'API nascosta nella lista bloccata oppure omettila da tutti gli elenchi con restrizioni.
  • MAGGIO, se nell'AOSP non esiste già un'API nascosta, aggiungi il API a qualsiasi elenco con restrizioni.

3.1.1. Estensioni Android

Android supporta l'estensione della superficie API gestita di un determinato livello API aggiornare la versione dell'estensione per quel livello API. La L'API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) restituisce il valore dell'estensione apiLevel fornita, se sono presenti estensioni corrispondenti livello API.

Implementazioni di dispositivi Android:

• [C-0-1] DEVE precaricare l'implementazione AOSP di entrambe le librerie condivise ExtShared e i servizi ExtServices con versioni superiori o uguali a il numero minimo di versioni consentite per ogni livello API. Ad esempio, Android 7.0 implementazioni nei dispositivi, l'esecuzione del livello API 24 DEVE includere almeno Versione 1.

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

• [C-0-3] DEVE supportare tutte le API definite dalle versioni delle estensioni restituito da android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) esattamente come le altre API gestite, in base alle i requisiti di cui alla sezione 3.1.

3.1.2. Raccolta Android

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

• [C-0-1] NON DEVE inserire la libreria org.apache.http.legacy nel bootclasspath.
• [C-0-2] DEVE aggiungere la libreria org.apache.http.legacy all'applicazione classpath solo quando l'app soddisfa una delle seguenti condizioni:
  • Ha come target il livello API 28 o un livello inferiore.
  • Dichiara nel file manifest che ha bisogno della libreria impostando il parametro Attributo android:name di <uses-library> a 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 una significativa API "soft" solo per il runtime, sotto forma di aspetti come intent, autorizzazioni e aspetti simili delle app per Android che non possono essere applicate in fase di compilazione dell'applicazione.

3.2.1. Autorizzazioni

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

3.2.2. Parametri build

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

• [C-0-1] Fornire valori coerenti e significativi su tutti i dispositivi implementazioni, la tabella seguente include ulteriori limitazioni sui formati di questi valori a cui le implementazioni dei dispositivi DEVONO essere conformi.

Parametro	Dettagli
VERSIONE.LANCIO	La versione del sistema Android attualmente in esecuzione, in formato leggibile formato. Questo campo DEVE avere uno dei valori stringa definiti in Stringhe di versione consentite per Android 14.
VERSIONE.SDK	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 14, questo campo DEVE avere il valore intero 14_INT.
VERSION.SDK_INT	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 14, questo campo DEVE avere il valore intero 14_INT.
VERSIONE.INCREMENTALE	Un valore scelto dall'implementatore del dispositivo che designa la build specifica del sistema Android attualmente in esecuzione, in formato leggibile. Questo value NON DEVE essere riutilizzato per diverse build rese disponibili agli utenti finali. R uso tipico di questo campo è indicare il numero di build o per generare la build è stato utilizzato l'identificatore della modifica del controllo del codice sorgente. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit stampabile e corrispondere l'espressione regolare "^={e" :\/~]+$.
DA TAVOLO	Un valore scelto dall'implementatore del dispositivo che identifica lo specifico hardware interno utilizzato dal dispositivo, in formato leggibile. Un possibile è utile per indicare la revisione specifica dell'alimentazione della scheda del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrisponde all'espressione regolare "^[a-zA-Z0-9_-]+$".
BRAND	Un valore che riflette il nome del brand associato al dispositivo come noto per gli utenti finali. DEVE essere in un formato leggibile e DOVREBBE rappresentare i il produttore del dispositivo o il brand aziendale con cui il dispositivo viene sul mercato. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere l'espressione regolare “^[a-zA-Z0-9_-]+$”.
SUPPORTO_ABIS	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) dell'ambiente nativo le API nel tuo codice. Consulta la sezione 3.3. API nativa Compatibilità.
SUPPORTO_32_BIT_ABIS	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) dell'ambiente nativo le API nel tuo codice. Consulta la sezione 3.3. API nativa Compatibilità.
SUPPORTATO_64_BIT_ABIS	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) di codice nativo. Consulta la sezione 3.3. Nativi Compatibilità delle API.
CPU_ABI	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) dell'ambiente nativo le API nel tuo codice. Consulta la sezione 3.3. API nativa Compatibilità.
CPU_ABI2	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) di codice nativo. Consulta la sezione 3.3. Nativi Compatibilità delle API.
DISPOSITIVO	Un valore scelto dall'implementatore del dispositivo contenente il nome dello sviluppo o nome in codice che identifica la configurazione delle funzionalità hardware dal design industriale. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e che corrispondano all'espressione regolare "^[a-zA-Z0-9_-]+$". Il nome di questo dispositivo NON DEVE cambiare durante la per tutta la durata del prodotto.
IMPRONTA	Una stringa che identifica in modo univoco questa build. DOVREBBE ragionevolmente essere e leggibili da una persona. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ad esempio: acme/mioprodotto/ mydevice:14/LMYXX/3359:userdebug/test-keys L'impronta NON DEVE includere spazi vuoti. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit.
HARDWARE	Il nome dell'hardware (dalla riga di comando del kernel o da /proc). it DEVE essere ragionevolmente leggibile. Il valore di questo campo DEVE essere codificabili come ASCII a 7 bit e corrispondono all'espressione regolare "^[a-zA-Z0-9_-]+$".
PRESENTATORE	Una stringa che identifica in modo univoco l'host su cui è stata basata la build, in formato leggibile. Non sono previsti requisiti sul formato specifico questo campo, tranne che NON DEVE essere nullo o con la stringa vuota ("").
ID	Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a uno specifico in un formato leggibile. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore sufficientemente che gli utenti finali possano distinguere tra build di software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere al “^[a-zA-Z0-9._-]+$”.
PRODUTTORE	Il nome commerciale del produttore di apparecchiature originali (OEM) della prodotto. Non sono previsti requisiti sul formato specifico di questo campo, tranne che NON DEVE essere null o la stringa vuota (""). Questo campo NON DEVE cambiare per tutta la durata del prodotto.
SOC_PRODUTTORE	Il nome commerciale del produttore dell'impianto principale sulla di chip (SOC) utilizzato nel prodotto. Dispositivi con lo stesso produttore SOC deve utilizzare lo stesso valore costante. Chiedere al produttore del SOC la costante corretta da usare. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit, DEVE corrispondere all'espressione regolare "^([0-9A-Za-z ]+)", NON DEVE iniziare o terminare con uno spazio vuoto, e NON DEVE essere uguale a "sconosciuto". Questo campo NON DEVE cambiare durante per tutta la durata del prodotto.
SOC_MODEL	Il nome del modello del sistema principale su un chip (SOC) utilizzato in del prodotto. I dispositivi con lo stesso modello SOC devono usare la stessa costante valore. Chiedi al produttore del SOC la costante corretta da utilizzare. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere al l'espressione regolare "^([0-9A-Za-z ._/+-]+)$", NON DEVE iniziare o terminare con uno spazio vuoto e NON DEVE essere uguale a "sconosciuto". Questo campo NON DEVE cambiare per tutta la durata del prodotto.
MODELLO	Un valore scelto dall'implementatore del dispositivo contenente il nome del noto all'utente finale. DEVE essere lo stesso nome con cui Il dispositivo viene commercializzato e venduto agli utenti finali. Non ci sono requisiti su il formato specifico di questo campo, tranne che NON DEVE essere nullo o stringa vuota (""). Questo campo NON DEVE cambiare durante per tutta la durata del prodotto.
PRODOTTO	Un valore scelto dall'implementatore del dispositivo contenente il nome dello sviluppo del prodotto specifico (SKU) che DEVE essere univoco all'interno brand. DEVE essere leggibile, ma non è necessariamente destinato alla visualizzazione dagli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrisponde all'espressione regolare "^[a-zA-Z0-9_-]+$". Questo prodotto il nome NON DEVE cambiare per tutta la durata del prodotto.
SKU ODM	Un valore facoltativo scelto dall'implementatore del dispositivo che contiene SKU (codice identificativo dell'articolo) utilizzato per monitorare configurazioni specifiche dei dispositivo, ad esempio le periferiche incluse con il dispositivo in vendita. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere al espressione regolare ^([0-9A-Za-z.,_-]+)$.
SERIE	DEVE restituire "UNKNOWN".
TAG	Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che consente di distinguere ulteriormente la build. I tag DEVONO essere codificabili come ASCII a 7 bit e corrispondono all'espressione regolare “^[a-zA-Z0-9._-]+” e DEVE avere uno dei valori corrispondenti alle tre tipiche piattaforme Android configurazioni di firma: chiavi di rilascio, chiavi dev e chiavi di test.
DURATA	Un valore che rappresenta il timestamp di quando è avvenuta la build.
MACCHINA	Un valore scelto dall'implementatore del dispositivo che specifica il runtime configurazione della build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni di runtime Android tipiche: utente, userdebug o eng.
UTENTE	Il nome o l'ID utente dell'utente (o dell'utente automatico) che ha generato la creare. Non sono previsti requisiti sul formato specifico di questo campo, tranne che NON DEVE essere null o la stringa vuota ("").
PATCH_DI_SICUREZZA	Un valore che indica il livello patch di sicurezza di una build. DEVE indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti tramite il Bollettino sulla sicurezza pubblica di Android. DEVE trovarsi il formato [AAAA-MM-GG], corrispondente a una stringa definita documentata Sicurezza pubblica Android Bollettino o nel Avvertenza sulla sicurezza di Android, ad esempio "2015-11-01".
Sistema operativo BASE	Un valore che rappresenta il parametro FINGERPRINT della build che è identico a questa build ad eccezione delle patch fornite nel Bollettino sulla sicurezza pubblica di Android. DEVE segnalare il valore corretto e se una build di questo tipo non esiste. Segnala una stringa vuota ("").
BOOTLOADER	Un valore scelto dall'implementatore del dispositivo che identifica lo specifico versione del bootloader interno utilizzata nel dispositivo, in formato leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere al espressione regolare “^[a-zA-Z0-9._-]+$”.
getRadioVersion()	DEVE (essere o restituire) un valore scelto dall'implementatore del dispositivo identificando la versione specifica della radio/modem interna utilizzata nel dispositivo; in un formato leggibile. Se un dispositivo non dispone di radio/modem DEVE restituire NULL. Il valore di questo campo DEVE essere codificabili come ASCII a 7 bit e corrispondono all'espressione regolare "^[a-zA-Z0-9._-,]+$”.
getSerial()	DEVE (essere o restituire) un numero di serie hardware, che DEVE essere disponibile e unici nei vari dispositivi con lo stesso MODELLO e PRODUTTORE. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9]+$".

3.2.3. Compatibilità degli intent

3.2.3.1. Application Intent comuni

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

Implementazioni dei dispositivi:

• [C-SR-1] CONSIGLIATO VIVAMENTE di precaricare una o più applicazioni o componenti del servizio con un gestore di intent, per tutti i filtri per intent pubblici pattern definiti dai seguenti intent dell'applicazione elencati qui e soddisfare le aspettative degli sviluppatori, ovvero soddisfare le aspettative come descritto nell'SDK.

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

3.2.3.2. Risoluzione dell'intenzione

• [C-0-1] Poiché Android è una piattaforma espandibile, le implementazioni dei dispositivi DEVONO consentire ogni pattern di intent riportato nella sezione 3.2.3.1 , ad eccezione delle Impostazioni, affinché le applicazioni di terze parti possano eseguire l'override. La l'implementazione open source di Android upstream lo consente per impostazione predefinita.

• [C-0-2] Gli utenti che implementano i dispositivi NON DEVONO assegnare privilegi speciali al sistema delle applicazioni l'utilizzo di questi pattern di intent o impedire le applicazioni di terze parti dall'associazione a e dall'assumere il controllo di questi pattern. Questo divieto include, a titolo esemplificativo, la disattivazione dell'utente "Selettore" che consente all'utente di scegliere tra più applicazioni che tutte per gestire 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 dei dispositivi POTREBBERO fornire attività predefinite per specifiche Pattern URI (ad es. http://play.google.com) quando l'attività predefinita fornisce un più specifico per l'URI dei dati. Ad esempio, un pattern di filtri per intent che specifica l'URI di dati "http://www.android.com" è più specifico dell'URL pattern di intent principale del browser per "http://".

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

• [C-0-4] DEVE tentare di convalidare eventuali filtri di intent eseguendo la passaggi di convalida definiti nella specifica Digital Asset Links come implementato dal gestore di pacchetti nell'open source di Android a monte progetto.
• [C-0-5] DEVE tentare la convalida dei filtri di intent durante l’installazione di l'applicazione e impostare tutti i filtri di intent URI convalidati correttamente gestori di app predefiniti per i relativi URI.
• POTREBBE impostare filtri di intent specifici per gli URI come gestori di app predefiniti per i relativi URI, se vengono verificati correttamente ma gli altri filtri URI candidati non vanno a buon fine verifica. Se l'implementazione avviene in questo modo, DEVE fornire il parametro override dei pattern per URI appropriati per l'utente nel menu delle impostazioni.
• DEVE fornire all'utente i controlli dei link alle app per ogni app nelle Impostazioni come che segue:
  • [C-0-6] L'utente DEVE essere in grado di eseguire l'override olistico dell'app predefinita comportamento dei link affinché un'app sia sempre aperta, sempre chiedere o mai aperta che deve essere applicato allo stesso modo a tutti i filtri per intent dell'URI candidato.
  • [C-0-7] L'utente DEVE essere in grado di visualizzare un elenco di intent URI candidati filtri corretti.
  • L'implementazione del dispositivo POTREBBE offrire all'utente la possibilità di: sostituiscono i filtri di intent dell'URI candidato specifici che sono stati correttamente verificati, sulla base di un filtro per intenzione.
  • [C-0-8] L'implementazione del dispositivo DEVE fornire agli utenti la possibilità di visualizza e sostituisci i filtri di intent specifici dell'URI candidato se il dispositivo consente l'esito positivo di alcuni filtri di intent dell'URI candidato la verifica, mentre altre potrebbero non andare a buon fine.

3.2.3.3. Spazi dei nomi per intent

• [C-0-1] Le implementazioni dei dispositivi NON DEVONO includere componenti Android che rispetta eventuali nuovi pattern di intent o di trasmissione utilizzando un attributo ACTION, CATEGORY o un'altra stringa chiave nello spazio dei nomi android.* o com.android.*.
• [C-0-2] Gli utenti che implementano i dispositivi NON DEVONO includere componenti Android che per rispettare i nuovi pattern di intent o di trasmissione utilizzando un attributo ACTION, CATEGORY o un'altra stringa chiave in uno spazio pacchetto appartenente a un'altra organizzazione.
• [C-0-3] Gli utenti che implementano i dispositivi NON DEVONO alterare o estendere l'intento modelli elencati nella sezione 3.2.3.1.
• Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano in modo chiaro gli spazi dei nomi e ovviamente associati alla propria organizzazione. Questo divieto è in modo analogo a quello specificato per le classi di linguaggio Java nella sezione 3.6.

3.2.3.4. Intent di trasmissione

Le applicazioni di terze parti si affidano alla piattaforma per trasmettere determinati intent ai avvisarli delle modifiche all'ambiente hardware o software.

Implementazioni dei dispositivi:

• [C-0-1] DEVE trasmettere gli intent di trasmissione pubblici elencati qui in risposta agli eventi di sistema appropriati, come descritto nella documentazione dell'SDK. Tieni presente che questo requisito non è in conflitto con la sezione 3.5 come delle applicazioni in background sono descritte anche nel riquadro documentazione. Inoltre, alcuni intent di broadcast sono condizionati all'hardware all'assistenza clienti, se il dispositivo supporta l'hardware necessario, DEVONO trasmettere il e fornire il comportamento in linea con la documentazione dell'SDK.

3.2.3.5. Application Intent condizionali

Android include impostazioni che consentono agli utenti di selezionare facilmente il proprio applicazioni predefinite, ad esempio per la schermata iniziale o gli SMS.

Ove opportuno, le implementazioni dei dispositivi DEVONO fornire impostazioni simili. ed essere compatibile con il pattern di filtro per intent e i metodi API descritti nella documentazione dell'SDK, come mostrato di seguito.

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

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

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

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

• [C-2-2] DEVE rispettare le android.telecom.action.CHANGE_DEFAULT_DIALER intenzione di mostrare una finestra di dialogo per consentire all'utente di modificare il valore predefinito del telefono un'applicazione.

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

• [C-2-3] DEVE rispettare android.telecom.action.CHANGE_PHONE_ACCOUNTS per fornire l'invito all'utente per configurare ConnectionServices associati a PhoneAccounts, come nonché un PhoneAccount predefinito che il fornitore di servizi di telecomunicazione per effettuare chiamate in uscita. L'implementazione AOSP soddisfa questo requisito inclusa l'opzione "Account per le chiamate" nel menu "Chiamate" menu delle impostazioni.

• [C-2-4] DEVE consentire android.telecom.CallRedirectionService per un'app che contiene android.app.role.CALL_REDIRECTION ruolo.

• [C-2-5] DEVE fornire all'utente l'invito a scegliere un'app che contenga la android.app.role.CALL_REDIRECTION ruolo.

• [C-2-6] DEVE rispettare android.intent.action.SENDTO e android.intent.action.VIEW e forniscono un'attività per inviare/visualizzare SMS.

• [C-SR-1] È VIVAMENTE CONSIGLIATO per rispettare android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_Button, android.intent.action.VIEW & android.intent.action.DIAL con un'applicazione dialer precaricata in grado di gestire questi intent fornire il fulfillment come descritto nell'SDK.

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

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

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

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

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

• [C-5-1] DEVE rispettare "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 le "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" e mostrare un'attività di sistema che richiede la modalità rilevabile.

Se le implementazioni dei dispositivi supportano la funzionalità DND:

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

Se le implementazioni del dispositivo consentono agli utenti di utilizzare metodi di immissione di terze parti nella dispositivo:

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

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

• [C-8-1] DEVE rispettare le android.settings.ACCESSIBILITY_SETTINGS l'intento di fornire un meccanismo accessibile all'utente che consenta di attivare e disattivare servizi di accessibilità di terze parti oltre all'accessibilità precaricata i servizi di machine learning.

Se le implementazioni del dispositivo includono il supporto per Wi-Fi Easy Connect ed espongono il di funzionalità alle app di terze parti, questi:

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

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

• [C-10-1] DEVE fornire nelle impostazioni un'interfaccia utente che gestisca le Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS che consente agli utenti di aggiungere o rimuovere applicazioni dalle applicazioni l'elenco di elementi consentiti.

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

• [C-11-1] DEVE avere un'attività che gestisca le Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS ma POTREBBE implementarlo come no-op.

Se le implementazioni dei dispositivi dichiarano il supporto della fotocamera tramite android.hardware.camera.any, l'utente:

• [C-12-3] DEVE gestire e DEVE consentire solo le app Android preinstallate per gestire i seguenti intent MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, e MediaStore.ACTION_VIDEO_CAPTURE come descritto nel documento dell'SDK.

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

• [C-13-1] DEVE rispettare l'intento android.app.action.ADD_DEVICE_ADMIN per richiamare una UI che spinga l'utente ad aggiungere l'amministratore del dispositivo al sistema (o consentendo al cliente di rifiutarlo).

• [C-13-2] DEVE rispettare le intenzioni android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION e svolgere un'attività che consenta di adempiere a tali intenzioni, come descritto nell'SDK qui.

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

• [C-14-1] DEVE implementare completamente AutofillService e AutofillManager le API e rispettare le API android.settings.REQUEST_SET_AUTOFILL_SERVICE mostrare un menu delle impostazioni predefinite dell'app 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 vuoi consentire app di terze parti per accedere alle statistiche sull'utilizzo, questi:

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

Se le implementazioni dei dispositivi intendono impedire l'uso di app, incluse quelle preinstallate di accesso alle statistiche sull'utilizzo, le app:

• [C-15-1] DEVE avere ancora un'attività che gestisca le android.settings.ACTION_USAGE_ACCESS_SETTINGS modello di intent, ma DEVE implementarlo come soluzione indipendente, ovvero avere una comportamento dell'utente quando l'accesso viene rifiutato.

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

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

Se le implementazioni del dispositivo supportano il VoiceInteractionService e ne includono di più di un'applicazione alla volta che utilizza questa API:

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

Se le implementazioni dei dispositivi segnalano la funzionalità android.hardware.audio.output, l'utente:

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

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

• DOVREBBE includere il supporto per i salvaschermo e fornire un'opzione di impostazioni per agli utenti di configurare salvaschermi in risposta al Intenzione android.settings.DREAM_SETTINGS.

3.2.4. Attività su display secondari/multipli

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

• [C-1-1] DEVE impostare android.software.activities_on_secondary_displays flag funzionalità.
• [C-1-2] DEVE garantire la compatibilità dell'API, analogamente a un'attività in esecuzione su sul display principale.
• [C-1-3] DEVE indirizzare la nuova attività allo stesso display dell'attività che quando la nuova attività viene lanciata senza specificare un target display tramite ActivityOptions.setLaunchDisplayId() tramite Google Cloud CLI o tramite l'API Compute Engine.
• [C-1-4] DEVE eliminare tutte le attività, quando un display con Display.FLAG_PRIVATE viene rimossa.
• [C-1-5] DEVE nascondere in modo sicuro i contenuti su tutti gli schermi quando il dispositivo è bloccato Con una schermata di blocco sicura, a meno che l'app non attivi la visualizzazione sopra il blocco. schermo con Activity#setShowWhenLocked() tramite Google Cloud CLI o tramite l'API Compute Engine.
• Dovrebbe avere android.content.res.Configuration che corrisponde a quel display per poter essere visualizzato, utilizzare correttamente e mantenere la compatibilità se un'attività viene avviata display secondario.

Se le implementazioni del dispositivo consentono di avviare attività Android normali su e uno secondario ha l'opzione android.view.Display.FLAG_PRIVATE Segnala:

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

3.3. Compatibilità API native

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

• [C-SR-1] VIVAMENTE CONSIGLIATO di usare le implementazioni delle librerie elencato di seguito dall'Android Open Source Project a monte.

3.3.1. Interfacce binarie dell'applicazione

Il bytecode Dalvik gestito può chiamare il codice nativo fornito nell'applicazione File .apk come file ELF .so compilato per l'hardware appropriato del dispositivo dell'architettura. Poiché il codice nativo dipende fortemente dal processore sottostante Android definisce una serie di interfacce binarie delle applicazioni (ABI, Application Binary Interfaces) Android NDK.

Implementazioni dei dispositivi:

• [C-0-1] DEVE essere compatibile con una o più ABI Android NDK definite.
• [C-0-2] DEVE includere il supporto del codice in esecuzione nell'ambiente gestito per nel codice nativo, utilizzando la Java Native Interface (JNI) standard la semantica.
• [C-0-3] DEVE essere compatibile con l'origine (ovvero compatibile con l'intestazione) e compatibile con i programmi binari (per ABI) con ogni libreria obbligatoria nell'elenco di seguito.
• [C-0-5] DEVE segnalare con precisione l'Application Binary Interface nativa (ABI) supportata dal dispositivo, tramite android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS parametri, ognuno separato da virgole elenco di ABI ordinate dalla più alla meno preferita.

• [C-0-6] DEVE segnalare, tramite i parametri sopra riportati, un sottoinsieme dei seguenti di ABI e NON DEVE segnalare le ABI non presenti nell'elenco.

  • armeabi (non più supportato come target dall'NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

  • libaaudio.so (supporto audio nativo AAudio)
  • libamidi.so (supporto MIDI nativo, se la funzionalità android.software.midi è rivendicato come descritto nella Sezione 5.9).
  • libandroid.so (supporto nativo attività Android)
  • libc (libreria C)
  • libcamera2ndk.so
  • libdl (linker dinamico)
  • libEGL.so (gestione della superficie OpenGL nativa)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (logging Android)
  • libmediandk.so (supporto delle API native per i media)
  • libm (libreria matematica)
  • libneuralnetworks.so (API Neural Networks)
  • libOpenMAXAL.so (supporto di OpenMAX AL 1.0.1)
  • libOpenSLES.so (supporto audio OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (supporto minimo per C++)
  • libvulkan.so (Vulkan)
  • libz (compressione Zlib)
  • Interfaccia JNI

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

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

• [C-0-10] NON DEVE esporre altre librerie native, implementate e forniti in AOSP come librerie di sistema per le app di terze parti che hanno come target l'API livello 24 o superiore in quanto riservati.

• [C-0-11] DEVE esportare tutti i dati di OpenGL ES 3.1 e Android Extension Pack simboli di funzione, come definito nel NDK, tramite la libreria libGLESv3.so. Si noti che sebbene tutti i simboli DEVONO essere presenti, la sezione 7.1.4.1 descrive in modo più dettagliato i requisiti necessari per l'implementazione completa di ogni sono previste le funzioni corrispondenti.

• [C-0-12] DEVE esportare i simboli di funzione per il core Vulkan 1.0 Funzione Vulkan 1.1 nonché VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 tramite la Raccolta libvulkan.so. Tieni presente che, anche se tutti i simboli DEVONO essere presenti, sezione 7.1.4.2 descrive in modo più dettagliato i requisiti per quando è prevista l'implementazione di ciascuna funzione corrispondente.

• DEVONO essere create utilizzando il codice sorgente e i file di intestazione disponibili nel Android Open Source Project a monte.

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

3.3.2. Compatibilità del codice nativo ARM a 32 bit

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

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

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

• [C-2-1] DEVE includere le seguenti righe in /proc/cpuinfo e NON DEVE alterano i valori sullo stesso dispositivo, anche quando vengono letti da altre ABI.

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

• [C-2-2] DEVE mantenere sempre disponibili le seguenti operazioni, anche nella in cui l'ABI è implementata su un'architettura ARMv8, tramite supporto CPU nativo o emulazione software:

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

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

3.4. Compatibilità web

3.4.1. Compatibilità con WebView

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

• [C-1-1] DEVE segnalare android.software.webview.
• [C-1-2] DEVE utilizzare la build del progetto Chromium dell'Android Open Source Project a monte su Android 14 per l'implementazione android.webkit.WebView tramite Google Cloud CLI o tramite l'API Compute Engine.

• [C-1-3] La stringa dello user agent riportata da WebView DEVE essere nel seguente formato:

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, come Gecko) 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) POTREBBE essere vuota, ma se non è vuota DEVE avere lo stesso valore di android.os.Build.MODEL.
  • "Build/$(BUILD)" POTREBBE essere omesso, ma se è presente $(BUILD) DEVE essere uguale al valore di android.os.Build.ID.
  • Il valore della stringa $(CHROMIUM_VER) DEVE essere la versione di Chromium nel progetto open source Android a monte.
  • Le implementazioni dei dispositivi POSSONO omettere "Mobile" nella stringa dello user agent.

• Il componente WebView DEVE includere il supporto per quante più funzioni HTML5 possibile e se supporta la funzione DEVE essere conforme alle Specifica HTML5.

• [C-1-4] DEVE eseguire il rendering dei contenuti forniti o dell'URL remoto in un processo diverso dall'applicazione che crea un'istanza di WebView. Nello specifico il processo del renderer separato DEVE avere privilegi inferiori, eseguire come ID utente separato, non hanno accesso alla directory dei dati dell'app, non hanno accesso diretto alla rete e hanno accesso solo al servizi di sistema tramite Binder. L'implementazione AOSP di WebView soddisfa questo requisito.

Tieni presente che se le implementazioni dei dispositivi sono a 32 bit o dichiarano il flag funzionalità android.hardware.ram.low, sono esenti dall'istruzione C-1-3.

3.4.2. Compatibilità del browser

Se le implementazioni del dispositivo includono un'applicazione del browser autonoma per il navigando sul web, questi:

• [C-1-1] DEVE supportare ognuna di queste API associate a HTML5:
  • operazione offline/cache dell'applicazione
  • <video> il tag
  • geolocalizzazione
• [C-1-2] DEVE supportare il file HTML5/W3C API webstorage e DOVREBBE supportare il formato HTML5/W3C API IndexedDB. Ricorda che, poiché il web gli enti per gli standard di sviluppo stanno effettuando la transizione a favore di IndexedDB rispetto webstorage, è previsto che IndexedDB diventi un componente obbligatorio in la versione futura di Android.
• POTREBBE spedire una stringa dello user agent personalizzata nell'applicazione browser autonoma.
• DOVREBBE implementare il supporto per il maggior numero di HTML5 possibile sulla versione autonoma Applicazione browser (basata sul browser WebKit upstream un'applicazione o una sostituzione di terze parti).

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

• [C-2-1] DEVE comunque supportare gli schemi di intenti pubblici, come descritto in sezione 3.2.3.1.

3.5. Compatibilità di comportamento delle API

Implementazioni dei dispositivi:

• [C-0-9] DEVE garantire che la compatibilità comportamentale dell'API venga applicata a tutti app installate, a meno che non siano limitate, come descritto nella Sezione 3.5.1.
• [C-0-10] NON DEVE implementare l'approccio della lista consentita che garantisce l'API compatibilità comportamentale solo per le app selezionate per dispositivo che implementano l'implementazione.

I comportamenti di ogni tipo di API (gestita, soft, nativa e web) devono essere in linea con l'implementazione preferita dell'architettura a monte Android Open Source Project. Alcune aree specifiche di compatibilità sono:

• [C-0-1] I dispositivi NON DEVONO modificare il comportamento o la semantica di un per intenzione standard.
• [C-0-2] I dispositivi NON DEVONO alterare la semantica del ciclo di vita o del ciclo di vita un particolare tipo di componente di sistema (come Service, Activity, ContentProvider e così via).
• [C-0-3] I dispositivi NON DEVONO modificare la semantica di un'autorizzazione standard.
• I dispositivi NON DEVONO alterare le limitazioni applicate alle applicazioni in background. Nello specifico, per le app in background:
  • [C-0-4] DEVONO interrompere l'esecuzione dei callback registrati dal per ricevere output dal GnssMeasurement e GnssNavigationMessage.
  • [C-0-5] DEVONO limitare la frequenza degli aggiornamenti che vengono forniti all'app tramite LocationManager o la classe API WifiManager.startScan() .
  • [C-0-6] Se l'app ha come target il livello API 25 o un livello superiore, NON DEVONO consentire la registrazione di broadcast receiver per le trasmissioni implicite di intent Android standard nel file manifest dell'app, a meno che la trasmissione l'intent richiede un valore "signature" o "signatureOrSystem" protectionLevel autorizzazione o sono sul elenco di esenzione.
  • [C-0-7] Se l'app ha come target il livello API 25 o versioni successive, DEVONO interrompersi. servizi in background dell'app, proprio come se l'app avesse chiamato servizi stopSelf() di sicurezza, a meno che l'app non venga inserita in una lista consentita temporanea per gestire un visibile all'utente.
  • [C-0-8] Se l'app ha come target il livello API 25 o un livello superiore, DEVONO e rilasciare i wakelock bloccati dall'app.
• [C-0-11] I dispositivi DEVONO restituire i seguenti fornitori di sicurezza come primi sette valori di array Security.getProviders() , nell'ordine specificato e con i nomi indicati (come restituito Provider.getName()) e classi, a meno che l'app non abbia modificato l'elenco tramite insertProviderAt() o removeProvider(). Dispositivi POTREBBE restituire fornitori aggiuntivi dopo l'elenco di provider specificato di seguito.
  1. AndroidNSSP: android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider - sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCSolution - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE: com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

L'elenco riportato sopra non è esaustivo. Test della Compatibility Test Suite (CTS) parti significative della piattaforma per compatibilità comportamentale, ma non tutte. È responsabilità dell'implementatore garantire la compatibilità comportamentale con Android Open Source Project. Per questo motivo, gli implementatori dei dispositivi DEVI usare il codice sorgente disponibile tramite Android Open Source Project dove possibile, invece di reimplementare parti significative del sistema.

3.5.1. Limitazione delle applicazioni

Se le implementazioni dei dispositivi implementano un meccanismo proprietario per limitare le app (ad esempio, la modifica o la limitazione di comportamenti API che descritti nell'SDK) e più restrittivo del bucket di standby delle app limitato:

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

• [C-1-3] Non DEVE applicare automaticamente queste limitazioni proprietarie senza Prove di prestazioni scadenti dell'integrità del sistema, ma POTREBBE applicare le limitazioni alle app al rilevamento di comportamenti non corretti per l'integrità del sistema, come wakelock bloccati, funzionamento a lungo termine servizi e altri criteri. I criteri POSSONO essere determinati dal dispositivo implementano gli strumenti, ma DEVONO essere correlati all'impatto dell'app sull'integrità del sistema. Altro criteri che non sono strettamente correlati all'integrità del sistema, ad esempio della popolarità nel mercato, NON DEVONO essere utilizzati come criterio.

• [C-1-4] Non DEVE applicare automaticamente queste limitazioni proprietarie per le app quando un utente ha disattivato manualmente le limitazioni delle app e POTREBBE suggerirgli l'utente di applicare queste restrizioni proprietarie.

• [C-1-5] DEVE informare gli utenti se queste limitazioni proprietarie vengono applicate ai automaticamente un'app. Tali informazioni DEVONO essere fornite nel periodo di 24 ore. che precede l'applicazione di queste restrizioni di proprietà.

• [C-1-6] DEVE restituire true per ActivityManager.isBackgroundRestricted() per qualsiasi chiamata API da un'app.

• [C-1-7] NON DEVE limitare l'app in primo piano utilizzata esplicitamente da per l'utente.

• [C-1-8] DEVE sospendere queste limitazioni proprietarie su un'app ogni volta che un l'utente inizia a usare esplicitamente l'app, posizionandola in primo piano un'applicazione.

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

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

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

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

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

3.5.2. Sospensione delle applicazioni

Se le implementazioni dei dispositivi includono l'ibernazione delle app inclusa in AOSP o estende la caratteristica inclusa in AOSP, allora:

• [C-1-1] DEVE soddisfare tutti i requisiti della sezione 3.5.1, ad eccezione delle [C-1-6] e [C-1-3].
• [C-1-2] DEVE applicare la limitazione sull'app a un utente solo se: Prova che l'utente non ha utilizzato l'app per un certo periodo di tempo. Questo è VIVAMENTE CONSIGLIATA di un mese o più. L'utilizzo DEVE essere definiti da un'interazione esplicita dell'utente tramite UtilizzoStats#getLastTimeVisibile() un'API o qualsiasi altro elemento che possa far uscire un'app dallo stato di interruzione forzata. tra cui associazioni di servizi, associazioni di fornitori di contenuti, trasmissioni esplicite e così via. che verrà monitorato da una nuova API UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] DEVE applicare limitazioni che riguardano tutti gli utenti del dispositivo quando è la prova che il pacchetto non è stato utilizzato da QUALSIASI utente per un periodo di nel tempo. Questa durata è VIVAMENTE CONSIGLIATA di un mese o più.
• [C-1-4] NON DEVE far sì che l'app non sia in grado di rispondere agli intenti delle attività, associazioni di servizi, richieste dei fornitori di contenuti o trasmissioni esplicite.

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

3.6. Spazi dei nomi API

Android segue le convenzioni dello spazio dei nomi dei pacchetti e delle classi definite linguaggio di programmazione. Per garantire la compatibilità con applicazioni di terze parti, gli utenti che implementano i dispositivi NON DEVONO apportare modifiche vietate (vedi di seguito) questi spazi dei nomi dei pacchetti:

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

Vale a dire:

• [C-0-1] NON DEVE modificare le API esposte pubblicamente sulla piattaforma Android cambiando qualsiasi metodo o firma delle classi oppure rimuovendo classi o classi campi.
• [C-0-2] NON DEVE aggiungere elementi esposti al pubblico (come classi o interfacce, campi o metodi a classi o interfacce esistenti) o o le API di sistema alle API negli spazi dei nomi sopra indicati. Un "esposizione pubblica elemento" è qualsiasi costrutto non decorato con "@hide" indicatore come usata nel codice sorgente Android upstream.

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

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

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

• [C-0-5] NON DEVE trovarsi in uno spazio dei nomi di proprietà di o fare riferimento a un altro dell'organizzazione. Ad esempio, gli utenti che implementano i dispositivi NON DEVONO aggiungere API alla com.google.* o spazio dei nomi simile: solo Google può farlo. Analogamente, Google NON DEVE aggiungere API ai server di altre aziende spazi dei nomi.
• [C-0-6] DEVONO essere pacchettizzati in una libreria condivisa Android in modo che solo le app che li usano esplicitamente (tramite il meccanismo <uses-library>) vengono influenzate dall'aumento dell'utilizzo della memoria da parte di queste API.

Gli implementatori dei dispositivi POSSONO aggiungere API personalizzate in lingue native, al di fuori dell'NDK API, ma quelle personalizzate:

• [C-1-1] NON DEVE trovarsi in una biblioteca NDK o in una biblioteca di proprietà di un altro utente dell'organizzazione come descritto qui

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

Tieni presente che le limitazioni precedenti corrispondono alle convenzioni standard per la denominazione API nel linguaggio di programmazione Java; questa sezione mira semplicemente a rafforzare queste convenzioni e renderle vincolanti attraverso l'inclusione in questa Definizione.

3.7. Compatibilità di runtime

Implementazioni dei dispositivi:

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

• [C-0-2] DEVE configurare i runtime Dalvik per allocare la memoria in conformità con la piattaforma Android upstream e come specificato la tabella seguente. (Vedi la sezione 7.1.1 per dimensioni e densità dello schermo).

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

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

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

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

3.8. Compatibilità con l'interfaccia utente

3.8.1. Avvio app (schermata Home)

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

Se le implementazioni del dispositivo consentono ad applicazioni di terze parti di sostituire il dispositivo schermata Home, l'utente:

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

Se le implementazioni del dispositivo includono un'Avvio app predefinito che supporta la funzionalità in-app bloccare le scorciatoie, queste:

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

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

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

Se le implementazioni del dispositivo implementano un'Avvio app predefinito che fornisce l'accesso alle scorciatoie aggiuntive fornite da app di terze parti tramite ScorciatoieManager API:

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

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

• [C-5-1] DEVE rispettare i NotificationChannel.setShowBadge() API. In altre parole, mostra un'invito visivo associata all'icona dell'app se è impostato su true e non mostra alcuno schema di badge dell'icona dell'app quando dei canali di notifica dell'app hanno impostato il valore false.
• POSSONO sostituire i badge dell'icona dell'app con lo schema di badge proprietario quando le applicazioni di terze parti indicano il supporto dello schema di badge di proprietà mediante l'uso di API di proprietà, ma DOVREBBE usare le risorse e i valori forniti tramite le API dei badge di notifica descritte nell'SDK , ad esempio Notification.Builder.setNumber() e Notification.Builder.setBadgeIconType() tramite Google Cloud CLI o tramite l'API Compute Engine.

Se le implementazioni dei dispositivi supportano monocromatico queste icone:

• [C-6-1] DEVE essere utilizzato solo quando un utente li abilita esplicitamente (ad es. tramite impostazioni o selettore sfondo).

3.8.2. Widget

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

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

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

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

• [C-1-3] DEVE essere in grado di visualizzare widget di formato 4 x 4 nelle dimensioni della griglia standard. Consulta le App Widget DesignGuidelines per maggiori dettagli nella documentazione dell'SDK Android.

• POSSONO supportare widget delle applicazioni nella schermata di blocco.

Se le implementazioni del dispositivo supportano i widget e i widget di app di terze parti bloccare le scorciatoie, queste:

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

3.8.3. Notifiche

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

3.8.3.1. Presentazione delle notifiche

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

• [C-1-1] DEVE supportare le notifiche che utilizzano funzionalità hardware, come descritto in la documentazione dell'SDK e nella misura possibile con l'implementazione del dispositivo hardware. Ad esempio, se l'implementazione di un dispositivo include una vibrazione, DEVE implementare correttamente le API di vibrazione. Se l'implementazione di un dispositivo non funziona dell'hardware, le API corrispondenti DEVONO essere implementate in modalità autonoma. Questo comportamento è più in dettaglio nella sezione 7.
• [C-1-2] DEVE eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) forniti nelle API o nel Guida di stile per l'icona della barra di stato/di sistema, anche se POTREBBE offrire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'implementazione open source di riferimento Android.
• [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 di NotificationChannel API documentata nell'SDK.
• [C-1-5] DEVE fornire un invito all'utente per bloccare e modificare un determinato notifiche dell'app di terze parti per ogni canale e livello del pacchetto dell'app.
• [C-1-6] DEVE anche fornire un invito all'utente per visualizzare la notifica eliminata i canali di notifica.

• [C-1-7] DEVE eseguire il rendering corretto di tutte le risorse (immagini, adesivi, icone e così via) forniti tramite Notification.MessagingStyle accanto al testo della notifica senza ulteriori interazioni da parte dell'utente. Per esempio, DEVE mostrare tutte le risorse, comprese le icone fornite tramite android.app.Person in una conversazione di gruppo impostata tramite setGroupConversation.

• [C-SR-1] È VIVAMENTE CONSIGLIATO di fornire all'utente un invito per controllare le notifiche esposte alle app a cui è stato concesso Autorizzazione listener di notifiche. La granularità DEVE essere tale che l'utente possa per ciascuno di questi listener di notifica i tipi di notifica collegato a questo listener. I tipi DEVONO includere "conversazioni", "avvisi", "silenzioso" e "importante in corso" notifiche.

• [C-SR-2] È VIVAMENTE CONSIGLIATO fornire un'invito che gli utenti specifichino app per cui non vuoi inviare notifiche a specifici listener di notifiche.

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

• DEVONO supportare notifiche avanzate.

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

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

• POTREBBE gestire soltanto la visibilità e le tempistiche relative alle notifiche delle app di terze parti Utenti di eventi importanti per mitigare problemi di sicurezza come le distrazioni alla guida.

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

Implementazioni dei dispositivi:

• [C-SR-4] È VIVAMENTE CONSIGLIATO di raggruppare e visualizzare conversation notifications in anticipo rispetto alle notifiche che non riguardano le conversazioni, ad eccezione di notifiche di servizi in primo piano in corso e importance:high notifiche.

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

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

Se le implementazioni dei dispositivi supportano le notifiche avanzate:

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

Le notifiche di avviso sono notifiche che vengono presentati all'utente man mano che arrivano, indipendentemente dalla piattaforma in cui vengono attiva. Se le implementazioni del dispositivo supportano gli avvisi notifiche, l'utente:

• [C-3-1] DEVE utilizzare la visualizzazione delle notifiche con avviso e le risorse come descritto in Notification.Builder API quando vengono visualizzate 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 il NotificationListenerService API che consentono alle app (una volta attivate esplicitamente dall'utente) di ricevere una copia dei tutte le notifiche non appena vengono pubblicate o aggiornate.

Implementazioni dei dispositivi:

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

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

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

3.8.3.3. DND (Non disturbare) / Modalità prioritaria

Se le implementazioni del dispositivo supportano la funzionalità DND (detta anche Modalità di priorità), questi:

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

3.8.4. API Assist

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

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

• [C-2-1] DEVE indicare chiaramente all'utente finale quando il contesto viene condiviso, in uno dei seguenti modi:
  • Ogni volta che l'app di assistenza accede al contesto, viene visualizzata una luce intorno ai bordi dello schermo che corrispondono o superano la durata e luminosità dell'implementazione di Android Open Source Project.
  • Per l'app di assistenza preinstallata, fornire meno inviti all'utente a due navigazioni di distanza l'input vocale predefinito e il menu delle impostazioni dell'app dell'assistente, e condividendo il contesto solo quando l'app di assistenza viene richiamata esplicitamente all'utente inserendo una hotword o un tasto di assistenza per la navigazione.
• [C-2-2] L'interazione designata per avviare l'app di assistenza come descritto nella sezione 7.2.3 DEVE lanciare l'app di assistenza, ovvero l'app che implementa VoiceInteractionService, o un'attività che gestisce l'intent ACTION_ASSIST.

3.8.5. Avvisi e toast

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

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

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

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

3.8.6. Temi

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

Android include "Holo" e "Material" famiglia di temi come un insieme di stili definiti che gli sviluppatori di applicazioni possono usare per Aspetto e design del tema Holo come definito dall'SDK Android.

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

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

• [C-1-3] DEVE impostare il parametro "sans- Serif" famiglia di caratteri su Roboto versione 2.x per le lingue supportato da Roboto o che fornisce un'invito all'utente per modificare il carattere utilizzato per il termine "sans- Serif" dalla famiglia di caratteri Roboto versione 2.x per i linguaggi supportati da Roboto.

• [C-1-4] DEVE generare tavolozze dinamiche dei colori tonali come specificato nell'AOSP documentazione di Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (vedi android.theme.customization.system_palette e android.theme.customization.theme_style).

• [C-1-5] DEVE generare tavolozze dinamiche delle tonalità dei colori utilizzando gli stili dei temi a colori enumerato in Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES documentazione (vedi android.theme.customization.theme_styles), ossia TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD eMONOCHROMATIC.

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

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

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

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

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

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

Android supporta un tema di varianti 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 delle loro app. Per offrire agli sviluppatori un'esperienza coerente configurazione, è importante che lo stile dell'icona della barra di stato sia mantenuto a diverse implementazioni sui dispositivi.

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

• [C-2-1] DEVE utilizzare il bianco per le icone di stato del sistema (come l'intensità del segnale e livello della batteria) e le notifiche emesse dal sistema, a meno che l'icona non sia indicare uno stato problematico o un'app richiede una barra di stato luminosa utilizzando WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS flag.
• [C-2-2] Le implementazioni sui dispositivi Android DEVONO cambiare il colore del sistema le icone di stato in nero (per maggiori dettagli, fai riferimento a R.style) quando un'app richiede una barra di stato luminosa.

3.8.7. Sfondi animati

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

L'hardware è considerato in grado di eseguire in modo affidabile gli sfondi animati se può essere eseguito tutti gli sfondi animati, senza limitazioni di funzionalità, a un frame ragionevole. senza effetti negativi su altre applicazioni. Se vengono applicate limitazioni causa l'arresto anomalo, il malfunzionamento e il consumo di sfondi e/o applicazioni un consumo eccessivo della batteria o della CPU oppure l'esecuzione con frequenze fotogrammi inaccettabili basse, è considerato in grado di eseguire sfondi animati. Ad esempio, alcune gli 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 Contesti OpenGL perché l'utilizzo dello sfondo animato di un contesto OpenGL potrebbe essere in conflitto con altre applicazioni che usano un contesto OpenGL.

• Implementazioni del dispositivo in grado di eseguire sfondi animati in modo affidabile come descritto sopra DOVREBBE implementare gli sfondi animati.

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

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

3.8.8. Cambio attività

Il codice sorgente Android upstream include schermata Panoramica, interfaccia utente a livello di sistema per il cambio delle attività e la visualizzazione degli accessi recenti di attività e attività usando una miniatura del grafico dell'applicazione nel momento in cui l'utente ha abbandonato l'applicazione per l'ultima volta.

Implementazioni dei dispositivi incluso il tasto di navigazione della funzione Recenti, come descritto in sezione 7.2.3 POTREBBE modificare l'interfaccia.

Se le implementazioni del dispositivo, incluso il tasto recente per la funzione, come descritto in sezione 7.2.3 alterano l'interfaccia, ovvero:

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

• DOVREBBE visualizzare il colore di evidenziazione, l'icona e il titolo dello schermo nei recenti.
• DEVONO mostrare un invito di chiusura ("x"), ma POTREBBE ritardarlo finché l'utente non interagisce con gli schermi.
• DEVI implementare una scorciatoia per passare facilmente all'attività precedente.
• DOVREBBE attivare l'azione di passaggio rapido tra i due utilizzati più di recente app, quando il tasto funzione Recenti viene toccato due volte.
• DOVREBBE attivare la modalità multi-finestra schermo diviso, se supportata, quando il tasto funzioni recenti è premuto a lungo.
• POTREBBE mostrare gli elementi recenti affiliati come un gruppo che si sposta insieme.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di usare gli utenti Android upstream (o un'interfaccia simile basata su miniature) per la schermata della panoramica.

3.8.9. Gestione degli input

Android include il supporto per Gestione degli input e il supporto per editor dei metodi di immissione di terze parti.

Se le implementazioni del dispositivo consentono agli utenti di utilizzare metodi di immissione di terze parti nella dispositivo:

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

3.8.10. Controllo contenuti multimediali schermata di blocco

L'API Remote Control Client è stata ritirata da Android 5.0 a favore delle Modello di notifica multimediale che permette l'integrazione delle applicazioni multimediali con i controlli di riproduzione visualizzato nella schermata di blocco.

3.8.11. Salvaschermi (in precedenza Sogni)

Consulta la sezione 3.2.3.5 per le impostazioni l'intenzione di configurare i salvaschermi.

3.8.12. Posizione

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

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

3.8.13. Unicode e Font

Android supporta i caratteri emoji definiti in Unicode 10.0.

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

• [C-1-1] DEVE essere in grado di visualizzare questi caratteri emoji in glifo a colori.
• [C-1-2] DEVE includere il supporto di:
  • carattere Roboto 2 con spessori diversi: Sans Serif-thin, Sans Serif-light, Sans Serif-medium, Sans Serif-Nero, Sans Serif condensato, Luce condensata Sans Serif per le lingue disponibili sul dispositivo.
  • Copertura completa di Unicode 7.0 in latino, greco e cirillico, incluse le Intervalli A, B, C e D estesi latini e tutti i glifi nella valuta di blocco di simboli di Unicode 7.0.
• [C-1-3] NON DEVE rimuovere o modificare NotoColorEmoji.tff nell'immagine di sistema. (È accettabile aggiungere un nuovo carattere dell'emoji per sostituire l'emoji in NotoColorEmoji.tff)
• DEVONO supportare la tonalità della pelle e le diverse emoji per la famiglia, come specificato Report tecnico Unicode n. 51.

Se le implementazioni dei dispositivi includono un IME, questi:

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

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

Se le implementazioni dei dispositivi includono il supporto per il birmano:

• [C-2-1] DEVE eseguire il rendering del testo con un carattere conforme a Unicode per impostazione predefinita; il carattere non conforme a Unicode NON DEVE essere impostato come carattere predefinito, a meno che l'utente lo sceglie nel selettore della lingua.
• [C-2-2] DEVE supportare un carattere Unicode e un carattere non conforme a Unicode se il carattere non conforme a Unicode sia supportato sul dispositivo. Non Unicode il carattere conforme NON DEVE rimuovere o sovrascrivere il carattere Unicode.
• [C-2-3] DEVE eseguire il rendering del testo con carattere non conforme a Unicode SOLO SE il codice in un linguaggio codice script Qaag (ad es. my-Qaag). Nessun altro codice ISO per lingua o regione (sia assegnati, non assegnati o riservati) possono essere utilizzati per fare riferimento a per il Myanmar (Birmania). Gli sviluppatori di app e gli autori di pagine web possono specificare my-Qaag come codice della lingua designata, proprio come fare per qualsiasi in un'altra lingua.

3.8.14. Multifinestre

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

• [C-1-1] DEVE implementare tali modalità multi-finestra in conformità con le i comportamenti dell'applicazione e le API descritti nell'SDK per Android documentazione di supporto per la modalità multi-finestra e di soddisfare i seguenti requisiti:
• [C-1-2] DEVE rispettare android:resizeableActivity impostato da un'app nel file AndroidManifest.xml come descritto in questo SDK.
• [C-1-3] NON DEVE offrire la modalità schermo diviso o formato libero se l'altezza dello schermo è inferiore a 440 dp e la larghezza dello schermo è inferiore a 440 dp.
• [C-1-4] Un'attività NON DEVE essere ridimensionata a dimensioni inferiori a 220 dp modalità multi-finestra diverse da Picture in picture.
• Le implementazioni dei dispositivi con dimensioni dello schermo xlarge DEVONO supportare il formato libero .

Se le implementazioni del dispositivo supportano la modalità o le modalità multi-finestra e lo schermo diviso modalità, l'utente:

• [C-2-2] DEVE ritagliare l'attività agganciata di un dispositivo multi-finestra a schermo diviso, ma DOVREBBE mostrare alcuni contenuti, se l'app Avvio app è la finestra con lo stato attivo.
• [C-2-3] DEVE rispettare la dichiarazione AndroidManifestLayout_minWidth dichiarata e AndroidManifestLayout_minHeight dell'applicazione di avvio di terze parti e non sostituirli per mostrare alcuni contenuti dell'attività agganciata alla base.

Se le implementazioni del dispositivo supportano le modalità multi-finestra e Picture in picture modalità multi-finestra:

• [C-3-1] DEVE avviare attività in modalità multi-finestra Picture in picture quando l'app è: * Livello API target 26 o superiore e dichiara android:supportsPictureInPicture * Livello API target 25 o inferiore e dichiara entrambi android:resizeableActivity e android:supportsPictureInPicture.
• [C-3-2] DEVE esporre le azioni nella UI di sistema come specificato dall'attività PIP corrente tramite setActions() tramite Google Cloud CLI o tramite l'API Compute Engine.
• [C-3-3] DEVE supportare proporzioni maggiori o uguali a 1:2,39 e inferiore o uguale a 2,39:1, come specificato dall'attività PIP mediante setAspectRatio() tramite Google Cloud CLI o tramite l'API Compute Engine.
• [C-3-4] DEVE utilizzare KeyEvent.KEYCODE_WINDOW per controllare la finestra PIP; Se la modalità PIP non è implementata, la chiave DEVE essere disponibili per l'attività in primo piano.
• [C-3-5] DEVE fornire all'utente l'invito per impedire la visualizzazione di un'app modalità PIP; l'implementazione AOSP soddisfa questo requisito nell'area notifiche.

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

  • I dispositivi con il valore Configuration.uiMode impostato su un valore diverso da UI_MODE_TYPE_TELEVISION DEVONO allocare una larghezza e un'altezza minime di 108 dp.
  • I dispositivi con il valore Configuration.uiMode impostato su UI_MODE_TYPE_TELEVISION DEVE allocare una larghezza minima di 240 dp e un'altezza minima di 135 dp.

3.8.15. Ritaglio display

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

Se le implementazioni dei dispositivi includono ritagli del display:

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

3.8.16. Controllo dei dispositivi

Android include ControlsProviderService e Control API per consentire ad applicazioni di terze parti di pubblicare controlli dei dispositivi per stato e azione per gli utenti.

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

3.8.17. Appunti

Implementazioni dei dispositivi:

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

Se le implementazioni dei dispositivi generano un'anteprima visibile agli utenti quando i contenuti vengono copiati negli appunti per qualsiasi elemento ClipData in cui ClipData.getDescription().getExtras() contiene android.content.extra.IS_SENSITIVE, l'utente:

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

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

3,9 Amministrazione dispositivo

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

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

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

3.9.1 Provisioning dei dispositivi

3.9.1.1 Provisioning dei proprietari del dispositivo

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

• [C-1-1] DEVE supportare la registrazione di un Client Policy Device (DPC) come App del proprietario del dispositivo come descritto di seguito:
  • Quando l'implementazione del dispositivo ha né utenti né dati utente configurati, questo:
    • [C-1-5] DEVE registrare l'applicazione DPC come app del proprietario del dispositivo oppure abilitare l'app DPC per scegliere se diventare il proprietario di un dispositivo o di un profilo, se il dispositivo dichiara il supporto NFC (Near Field Communication) tramite il flag funzionalità android.hardware.nfc e riceve un messaggio NFC contenente un record con tipo MIME MIME_TYPE_PROVISIONING_NFC
    • [C-1-8] DEVE inviare ACTION_GET_PROVISIONING_MODE dopo che il provisioning del proprietario del dispositivo viene attivato, in modo che L'app DPC può scegliere se diventare proprietario del dispositivo o profilo Proprietario, in base ai valori di android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, a meno che non possa essere determinato in un contesto che esiste una sola opzione valida.
    • [C-1-9] DEVE inviare il ACTION_ADMIN_POLICY_COMPLIANCE intent all'app del proprietario del dispositivo se viene stabilito un proprietario del dispositivo durante il provisioning, indipendentemente dal metodo di provisioning utilizzato. La l'utente non deve essere in grado di procedere con la configurazione guidata L'app del proprietario del dispositivo termina.
  • Quando l'implementazione del dispositivo ha utenti o dati utente:
    • [C-1-7] Non DEVE registrare alcuna applicazione DPC come app del proprietario del dispositivo non ci sono più.

• [C-1-2] DEVE mostrare un avviso informativo appropriato (come indicati in AOSP) e di ottenere il consenso dell'utente finale prima di utilizzare un'app. essere impostato come proprietario del dispositivo, a meno che non sia configurato in modo programmatico per la modalità demo retail prima dell'interazione dell'utente finale sullo schermo. Se le implementazioni del dispositivo dichiarano android.software.device_admin, ma anche includono una proprietà soluzione di gestione dei dispositivi e fornisce un meccanismo per promuovere un'applicazione configurata nella sua soluzione come "Proprietario del dispositivo" equivalente" al "Proprietario dispositivo" standard come riconosciuto dal set di dati Gestione criteri dispositivi API:

• [C-2-1] DEVE disporre di una procedura per verificare che l'app specifica promosso appartiene a una legittima gestione di dispositivi aziendali soluzione ed è stata configurata nella soluzione proprietaria di disporre dei diritti equivalenti di "Proprietario del dispositivo".

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

• [C-2-3] NON DEVE codificare il consenso o impedire l'utilizzo di app di altri proprietari di dispositivi.

3.9.1.2 Provisioning dei profili gestiti

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

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

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

• [C-1-3] DEVE fornire i seguenti inviti all'utente nelle Impostazioni per indicare all'utente quando una particolare funzione di sistema è stata disattivata Device Policy Controller (DPC):

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

• [C-1-4] DEVE avviare il gestore per ACTION_PROVISIONING_SUCCESSFUL per intent nel profilo di lavoro se viene stabilito un proprietario del profilo quando il provisioning viene avviato dall'android.app.action.PROVISION_MANAGED_PROFILE e il DPC abbia implementato il gestore.

• [C-1-5] DEVE inviare ACTION_PROFILE_PROVISIONING_COMPLETE la trasmissione al DPC del profilo di lavoro quando il provisioning viene avviato android.app.action.PROVISION_MANAGED_PROFILE l'intento.

• [C-1-6] DEVE inviare ACTION_GET_PROVISIONING_MODE dopo l'attivazione del provisioning del proprietario del profilo, in modo che l'app DPC può scegliere se diventare proprietario del dispositivo o del profilo, tranne quando Il provisioning viene attivato dall'intent android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] DEVE inviare ACTION_ADMIN_POLICY_COMPLIANCE intent al profilo di lavoro quando viene stabilito un proprietario del profilo durante indipendentemente dal metodo di provisioning utilizzato, ad eccezione di quando il provisioning viene attivato dall'intent android.app.action.PROVISION_MANAGED_PROFILE. L'utente non deve essere in grado di procedere nella configurazione guidata finché il profilo L'app del proprietario termina.

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

3.9.2 Supporto dei profili gestiti

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

• [C-1-1] DEVE supportare i profili gestiti tramite android.app.admin.DevicePolicyManager su quelle di livello inferiore.
• [C-1-2] DEVE consentire la creazione di un solo profilo gestito.
• [C-1-3] DEVE utilizzare un badge a forma di icona (simile al badge di lavoro upstream AOSP) per rappresentano le applicazioni e i widget gestiti e altri elementi UI con badge come Recenti e Notifiche.
• [C-1-4] DEVE mostrare un'icona di notifica (simile al lavoro a monte AOSP ) per indicare quando l'utente si trova all'interno di un'applicazione con profilo gestito.
• [C-1-5] DEVE mostrare un avviso popup che indichi che l'utente è nell'account profilo se e quando il dispositivo si attiva (ACTION_USER_PRESENT) e l'applicazione in primo piano si trova all'interno del profilo gestito.
• [C-1-6] Se esiste un profilo gestito, DEVE mostrare un invito visivo nella Selettore intent per consentire all'utente di inoltrare l'intent dalla piattaforma profilo all'utente principale o viceversa, se abilitato da Device Policy titolare.
• [C-1-7] Se esiste un profilo gestito, DEVE esporre il seguente utente Inviti sia per l'utente principale sia per il profilo gestito:
  • Dati separati per l'utilizzo di batteria, posizione, dati mobili e spazio di archiviazione per l'utente principale e il profilo gestito.
  • Gestione indipendente delle applicazioni VPN installate nell'istanza principale utente o profilo gestito.
  • Gestione indipendente delle applicazioni installate all'interno dell'utente principale o un profilo gestito.
  • Gestione indipendente degli account all'interno dell'utente principale o gestito profilo.
• [C-1-8] DEVE garantire che la tastiera, i contatti e i messaggi preinstallati le applicazioni possono cercare e cercare informazioni sul chiamante (se esistente) insieme a quelli del profilo principale, se Device Policy Controller lo consente.
• [C-1-9] DEVE garantire che soddisfi tutti i requisiti di sicurezza applicabile a un dispositivo su cui sono abilitati più utenti (vedi la sezione 9.5), anche se il profilo gestito non viene conteggiato come un altro utente oltre all'utente principale.

Se le implementazioni dei dispositivi dichiarano android.software.managed_users e android.software.secure_lock_screen, l'utente:

• [C-2-1] DEVE supportare la possibilità di specificare una riunione separata dalla schermata di blocco i seguenti requisiti per concedere l'accesso alle app in esecuzione in un solo per il profilo.
  • Le implementazioni dei dispositivi DEVONO rispettare le DevicePolicyManager.ACTION_SET_NEW_PASSWORD intent e mostrare un'interfaccia per configurare una schermata di blocco separata la credenziale per il profilo gestito.
  • Le credenziali della schermata di blocco del profilo gestito DEVONO utilizzare le stesse i meccanismi di archiviazione e gestione delle credenziali come profilo padre, come documentato Sito del progetto open source Android.
  • I criteri relativi alle password del DPC (controller criteri dispositivi) DEVE essere applicata solo alle credenziali della schermata di blocco del profilo gestito, a meno che richiamata sull'istanza DevicePolicyManager restituita getParentProfileInstance:
• Quando vengono visualizzati i contatti del profilo gestito in Registro chiamate preinstallato, UI in corso, Chiamata in corso e Chiamata senza risposta notifiche, contatti e app di messaggistica DOVREBBE essere contrassegnati con lo stesso badge utilizzato per indicare le applicazioni dei profili gestiti.

3.9.3 Supporto degli utenti gestiti

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

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

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

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

3.9.4 Requisiti del ruolo Gestione criteri dispositivi

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

• [C-1-1] DEVE supportare il ruolo di gestione dei criteri relativi ai dispositivi come definito in sezione 9.1. L'applicazione che contiene il ruolo di gestione dei criteri relativi ai dispositivi POTREBBE essere definito impostando config_devicePolicyManagement sul nome del pacchetto. Il nome del pacchetto DEVE essere seguito da : e dal certificato di firma, a meno che l'applicazione non sia precaricata.

Se per config_devicePolicyManagement non viene definito il nome di un pacchetto come descritti sopra:

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

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

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

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

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

3.10. Accessibilità

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

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

• [C-1-1] DEVE fornire un'implementazione dell'accessibilità di Android come descritto in API per l'accessibilità documentazione dell'SDK.
• [C-1-2] DEVE generare eventi di accessibilità e fornire gli opportuni AccessibilityEvent a tutti gli utenti registrati AccessibilityService come documentato nell'SDK.
• [C-1-4] DEVE fornire un'invito all'utente per controllare l'accessibilità che dichiarano AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_Pulsante. Tieni presente che, per le implementazioni sui dispositivi con una barra di navigazione del sistema, DOVREBBE consentire all'utente di avere la possibilità di inserire un pulsante nella console barra di navigazione per controllare questi servizi.

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

• [C-2-1] DEVE implementare questi servizi di accessibilità preinstallati come Accesso diretto all'avvio alle app se lo spazio di archiviazione dei dati è criptato con la crittografia basata su file (FBE).
• DEVE fornire un meccanismo nel flusso di configurazione pronto all'uso per consentire agli utenti di abilitare ai servizi di accessibilità pertinenti, nonché opzioni per regolare la dimensione del carattere, dimensioni di visualizzazione e gesti di ingrandimento.

3.11. Sintesi vocale

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

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

• [C-1-1] DEVE supportare il Framework di sintesi vocale Android su quelle di livello inferiore.

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

• [C-2-1] DEVE fornire l'invito all'utente per permettergli di selezionare una sintesi vocale per l'uso a livello di sistema.

3.12. Framework input TV

Android Television Input Framework (TIF) semplifica la distribuzione 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 la funzionalità TIF:

• [C-1-1] DEVE dichiarare la funzionalità della piattaforma android.software.live_tv.
• [C-1-2] DEVE supportare tutte le API TIF in modo che un'applicazione che utilizza queste API e gli input di terze parti basati su TIF può essere installato e utilizzato sul dispositivo.

3.13. Impostazioni rapide

Android mette a disposizione un componente UI Impostazioni rapide che consente di accedere rapidamente utilizzate di frequente o urgenti.

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

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

3.14. UI multimediale

Se le implementazioni del dispositivo includono applicazioni senza attivazione vocale (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 ottenuta tramite getTitle(), come descritto in MediaDescription. I titoli potrebbero essere abbreviati per rispettare le normative di sicurezza (ad es. distrazioni alla guida).

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

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

• [C-1-5] DEVE prendere in considerazione il doppio tocco di KEYCODE_HEADSETHOOK oppure KEYCODE_MEDIA_PLAY_PAUSE come KEYCODE_MEDIA_NEXT per MediaSession.Callback#onMediaButtonEvent.

3.15. App istantanee

Se le implementazioni del dispositivo supportano le app istantanee, DEVONO soddisfare quanto segue. requisiti:

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

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

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

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

3.16. Associazione dispositivo companion

Android include il supporto dell'accoppiamento di dispositivi associati per una gestione più efficace. associazione con i dispositivi associati e fornisce lo CompanionDeviceManager API per le app di accedere a questa funzionalità.

Se le implementazioni dei dispositivi supportano la funzionalità di accoppiamento del dispositivo associato, questi:

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

3.17. App pesanti

Se le implementazioni dei dispositivi dichiarano la funzionalità FEATURE_CANT_SAVE_STATE, allora:

• [C-1-1] DEVE avere installato una sola app che specifichi cantSaveState in esecuzione nel sistema. Se l'utente esce dall'app senza chiuderla esplicitamente (ad esempio premendo casa, lasciando un'attività attiva al sistema, anziché premere Indietro senza altre attività attive nel sistema), le implementazioni nei dispositivi DEVONO dare la priorità all'app nella RAM come avviene per altre gli elementi che si prevede rimangano in esecuzione, come i servizi in primo piano. Quando un'app di questo tipo è in background, il sistema può comunque attivare l'alimentazione funzionalità di gestione, come la limitazione di CPU e accesso alla rete.
• [C-1-2] DEVE fornire un'invito all'interfaccia utente per scegliere l'app che non parteciperai al meccanismo di salvataggio/ripristino dello stato normale una volta che l'utente avvia una seconda app dichiarata con cantSaveState .
• [C-1-3] NON DEVE applicare altre modifiche alle norme alle app che specificano cantSaveState, ad esempio modificando le prestazioni della CPU o l'assegnazione delle priorità di pianificazione.

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

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

3.18. Contatti

Android include Contacts Provider API per consentire alle applicazioni di gestire i dati di contatto memorizzati sul dispositivo. I dati di contatto inseriti direttamente nel dispositivo solitamente vengono sincronizzati con un web service, ma i dati POTREBBERO anche risiedere solo localmente sul dispositivo. I contatti archiviati solo sul dispositivo sono definiti locali contatti.

Contatti non elaborati sono "associati a" o "archiviata" un Account quando ACCOUNT_NAME, e ACCOUNT_TYPE, per i contatti non elaborati corrispondano Nome.account e Tipo.account campi dell'account.

Account locale predefinito: un account per i contatti non elaborati che sono archiviati solo su dispositivo e non sono associati a un Account nel AccountManager, che vengono create con valori null per ACCOUNT_NAME, e ACCOUNT_TYPE, colonne.

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

Implementazioni dei dispositivi:

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

Se le implementazioni dei dispositivi utilizzano un account locale personalizzato:

• [C-1-1] La ACCOUNT_NAME, dell'account locale personalizzato DEVE essere restituito da ContactsContract.RawContacts.getLocalAccountName
• [C-1-2] La ACCOUNT_TYPE, dell'account locale personalizzato DEVE essere restituito da ContactsContract.RawContacts.getLocalAccountType
• [C-1-3] Contatti non elaborati inseriti da applicazioni di terze parti con L'account locale predefinito (ovvero impostando valori nulli per ACCOUNT_NAME e ACCOUNT_TYPE) DEVONO essere inserite nella documentazione locale personalizzata Google Cloud.
• [C-1-4] I contatti non elaborati inseriti nell'account locale personalizzato non DEVONO essere quando vengono aggiunti o rimossi account.
• [C-1-5] Operazioni di eliminazione eseguite sull'account locale personalizzato DEVE comportare l'eliminazione immediata e definitiva dei contatti non elaborati (come se CALLER_IS_SYNCADAPTER è stato impostato su true), anche se il parametro CALLER\_IS\_SYNCADAPTER è stato impostato su false o non specificato.

4. Compatibilità con la confezione dell'applicazione

Implementazioni dei dispositivi:

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

  • Poiché il requisito di cui sopra può essere impegnativo, le implementazioni dei dispositivi vengono CONSIGLIATO di usare la gestione dei pacchetti dell'implementazione del riferimento AOSP di un sistema operativo completo.

• [C-0-2] DEVE supportare la verifica di ".apk" utilizzando Schema di firma dell'APK v3.1, Schema di firma dell'APK v3, Schema di firma dell'APK v2 e firma JAR.

• [C-0-3] NON DEVE estendere né il valore .apk, File manifest Android Dalvik bytecode, o formati bytecode RenderScript in modo tale da impedire che tali file l'installazione e l'esecuzione in modo corretto su altri dispositivi compatibili.

• [C-0-4] NON DEVE consentire app diverse da quella attuale "programma di installazione di record" affinché il pacchetto disinstalli automaticamente l'app senza conferma dell'utente, come documentato nell'SDK per DELETE_PACKAGE autorizzazione. Le uniche eccezioni riguardano la gestione delle app dello strumento di verifica dei pacchetti di sistema. PACKAGE_NEEDS_VERIFICATION e la gestione dell'app dello spazio di archiviazione ACTION_MANAGE_STORAGE l'intento.

• [C-0-5] DEVE avere un'attività che gestisca le android.settings.MANAGE_UNKNOWN_APP_SOURCES l'intento.

• [C-0-6] NON DEVE installare pacchetti dell'applicazione da sconosciuti fonti, a meno che l'app che richiede l'installazione soddisfa tutti i seguenti requisiti:

  • DEVE dichiarare lo REQUEST_INSTALL_PACKAGES autorizzazione o su android:targetSdkVersion impostato su 24 o su un valore inferiore.
  • DEVE essere stata concessa dall'utente l'autorizzazione a installare app da da fonti sconosciute.

• DEVE fornire un'invito all'utente per concedere/revocare l'autorizzazione a installare app da fonti sconosciute per ogni applicazione, ma POTREBBE scegliere di implementarle come autonomo e restituisce RESULT_CANCELED per startActivityForResult(), se l'implementazione del dispositivo non vuole offrire questa scelta agli utenti. Tuttavia, anche in questi casi DOVREBBE indicare all'utente il motivo per cui non c'è tale scelta presentata.

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

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

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

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

5. Compatibilità multimediale

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare i formati multimediali, gli encoder, i decoder, i tipi di file e i formati dei contenitori definiti nella sezione 5.1 per ogni codec dichiarato da MediaCodecList.
• [C-0-2] DEVE dichiarare e segnalare il supporto degli encoder, dei decoder disponibili ad applicazioni di terze parti MediaCodecList
• [C-0-3] DEVE essere in grado di decodificare e mettere a disposizione di terze parti correttamente app tutti i formati che è in grado di codificare. Sono inclusi tutti i bitstream generati dagli codificatori e i profili riportati CamcorderProfile

Implementazioni dei dispositivi:

• DOVREBBERO puntare alla latenza minima del codec, in altre parole,
  • NON DEVE consumare e memorizzare buffer di input e restituire solo buffer di input una volta elaborate.
  • NON DEVE conservare i buffer decodificati per un periodo superiore a quello specificato standard (ad es. SPS).
  • NON DEVE trattenere i buffer codificati per un tempo superiore a quello richiesto dal GOP alla struttura del centro di costo.

Tutti i codec elencati nella sezione di seguito sono forniti come software implementazioni nell'implementazione Android preferita dell'Android Open Progetto di origine.

Si tenga presente che né Google né l'Open Handset Alliance prevedono dichiarativa che questi codec sono esenti da brevetti di terze parti. Quelli si intende utilizzare questo codice sorgente in prodotti hardware o software che le implementazioni di questo codice, anche in software open source o shareware, potrebbero richiedere licenze di brevetto ai rispettivi titolari.

5.1. Codec multimediali

5.1.1. Codifica audio

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

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

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

Tutti i codificatori audio DEVONO supportare:

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

5.1.2. Decodifica audio

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

Se le implementazioni del dispositivo dichiarano supporto per android.hardware.audio.output, devono supportare la decodifica del seguenti formati audio:

• [C-1-1] Profilo AAC MPEG-4 (AAC LC)
• [C-1-2] Profilo MPEG-4 HE AAC (AAC+)
• [C-1-3] Profilo MPEG-4 HE AACv2 (AAC+ migliorato)
• [C-1-4] AAC ELD (Basso ritardo AAC migliorato)
• [C-1-11] xHE-AAC (Profilo HE AAC esteso ISO/IEC 23003-3, che include l'USAC Baseline Profile e l'ISO/IEC 23003-4 Dynamic Range. profilo di controllo)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE con audio ad alta risoluzione formati fino a 24 bit, frequenza di campionamento a 192 kHz e 8 canali. Tieni presente che questo requisito riguarda solo la decodifica e che un dispositivo puoi eseguire il sottocampionamento e il downmix durante la fase di riproduzione.
• [C-1-10] Opus

Se le implementazioni del dispositivo supportano la decodifica dei buffer di ingresso AAC dei da stream multicanale (ossia più di due canali) a PCM tramite l'impostazione predefinita Decoder audio AAC nell'API android.media.MediaCodec, quanto segue DEVE essere supportati:

• [C-2-1] La decodifica DEVE essere eseguita senza downmixing (ad esempio, un AAC 5.0 lo stream deve essere decodificato su cinque canali di PCM, uno stream 5.1 AAC deve essere decodificato a sei canali di PCM).
• [C-2-2] I metadati dell'intervallo dinamico DEVONO essere definiti nella sezione "Controllo intervallo dinamico" (RDC)" secondo lo standard ISO/IEC 14496-3 e i android.media.MediaFormat tasti DRC per configurare i comportamenti correlati all'intervallo dinamico del decoder audio. La Le chiavi AAC DRC sono state introdotte nell'API 21 e sono: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_ENCODED_TARGET_LEVEL.
• [C-SR-1] È VIVAMENTE CONSIGLIATO che i requisiti C-2-1 e C-2-2 di cui sopra siano soddisfatto da tutti i decoder audio AAC.

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

• [C-3-1] Il volume e i metadati DRC DEVONO essere interpretati e applicati secondo MPEG-D DRC Dynamic Range Control Profile Livello 1.
• [C-3-2] Il decoder DEVE comportarsi secondo la configurazione impostato con le seguenti android.media.MediaFormat chiavi: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_DRC_EFFECT_TYPE.

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

• POTREBBE supportare il controllo del volume e della gamma dinamica in base allo standard ISO/IEC 23003-4 Profilo di controllo intervallo dinamico.

Se viene supportato lo standard ISO/IEC 23003-4 e sia lo standard ISO/IEC 23003-4 che I metadati ISO/IEC 14496-3 sono presenti in un flusso di bit decodificato, quindi:

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

Tutti i decoder audio DEVONO supportare l'output:

• [C-6-1] Frame audio PCM a 16 bit nativi a 16 bit tramite il android.media.MediaCodec tramite Google Cloud CLI o tramite l'API Compute Engine.

Se le implementazioni del dispositivo supportano la decodifica dei buffer di ingresso AAC dei da stream multicanale (ossia più di due canali) a PCM tramite l'impostazione predefinita Decoder audio AAC nell'API android.media.MediaCodec, quanto segue DEVE essere supportate:

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

Se le implementazioni del dispositivo supportano decoder audio diversi dall'AAC predefinito decodificatore audio e sono in grado di trasmettere audio multicanale (ossia più di 2 canali) quando vengono caricati contenuti multicanale compressi, quindi:

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

5.1.3. Dettagli codec audio

Formato/Codec	Dettagli	Tipi di file/formati dei contenitori da supportare
Profilo AAC MPEG-4 (AAC LC)	Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento da 8 a 48 kHz.	3 GPP (0,3 gp) MPEG-4 (.mp4, .m4a) AAC non elaborato ADTS (.aac, ADIF non supportato) MPEG-TS (.ts, non ricercabile, solo decodifica) Matroska (solo .mkv, decodifica)
Profilo MPEG-4 HE AAC (AAC+)	Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento da 16 a 48 kHz.	3 GPP (0,3 gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profilo (AAC+ migliorato)	Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento da 16 a 48 kHz.	3 GPP (0,3 gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC a basso ritardo migliorato)	Supporto di contenuti in formato mono/stereo con frequenze di campionamento standard da 16 a 16 48 kHz.	3 GPP (0,3 gp) MPEG-4 (.mp4, .m4a)
USAC	Supporto di contenuti mono/stereo con frequenze di campionamento standard da 7,35 a 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	Da 4,75 a 12,2 kbps campionati a 8 kHz	3 GPP (0,3 gp)
AMR-WB	9 velocità da 6,60 kbit/s a 23,85 kbit/s campionati a 16 kHz, come definito AMR-WB, multi-frequenza adattiva - Codec vocale a banda larga	3 GPP (0,3 gp)
FLAC	Sia per l'encoder che per il decoder: almeno le modalità mono e stereo DEVONO essere supportati. Le frequenze di campionamento fino a 192 kHz DEVONO essere supportate; 16 e 24 bit risoluzione DEVE essere supportata. La gestione dei dati audio a 24 bit FLAC DEVE essere disponibili con la configurazione audio in virgola mobile.	FLAC (.flac) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (solo .mkv, decodifica)
MP3	Costante mono/stereo da 8-320 Kbps (CBR) o velocità in bit variabile (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (solo .mkv, decodifica)
MIDI	MIDI Type 0 e 1. DLS versione 1 e 2. XMF e XMF mobile. Supporto per formati di suonerie RTTTL/RTX, OTA e iMelody	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	Decodifica: supporto per contenuti mono, stereo, 5.0 e 5.1 con campionamento 8000, 12000, 16000, 24000 e 48000 Hz. Codifica: supporto di contenuti mono e stereo con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, solo decodifica) Matroska (.mkv) Webm (.webm)
PCM/WAVE	Il codec PCM DEVE supportare un PCM lineare a 16 bit e un numero in virgola mobile a 16 bit. MODA l’estrattore deve supportare un PCM lineare a 16-bit, 24-bit, 32-bit e un numero in virgola mobile a 32-bit (tariffe fino al limite dell'hardware). Le frequenze di campionamento DEVONO essere supportate da da 8 kHz a 192 kHz.	onda (.wav)
Opus	Decodifica: supporto per contenuti mono, stereo, 5.0 e 5.1 con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz. Codifica: supporto 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 delle immagini

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

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

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

Se le implementazioni del dispositivo supportano la codifica HEIC tramite android.media.MediaCodec per il tipo multimediale MIMETYPE_IMAGE_ANDROID_HEIC, l'utente:

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

5.1.5. Decodifica dell'immagine

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

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

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

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

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

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

5.1.6. Dettagli codec immagine

Formato/Codec	Dettagli	Tipi di file/formati container supportati
JPEG	Base+progressivo	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Raw - Una cruda verità		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Immagine, raccolta di immagini, sequenza di immagini	HEIF (.heif), HEIC (.heic)
AVIF (Profilo di riferimento)	Immagine, raccolta di immagini, sequenza di immagini del profilo di base	Container HEIF (.avif)

Codificatori e decoder di immagini esposti tramite l'API MediaCodec

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

• [C-SR-1] VIVAMENTE CONSIGLIATO per il supporto del formato colore RGB888 per la superficie di input .

• [C-1-3] DEVE supportare almeno uno dei componenti planari o semiplanari Formato colore YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). È VIVAMENTE CONSIGLIATO per supportare entrambi.

5.1.7. Codec video

• Per una qualità accettabile dello streaming video e delle videoconferenze sul web le implementazioni del dispositivo DEVONO usare un codec hardware VP8 che soddisfi i requisiti requisiti.

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

• [C-1-1] I codec video DEVONO supportare dimensioni bytebuffer di uscita e di input che ospitare il frame compresso e non compresso più grande fattibile, come dettato in base allo standard e alla configurazione, ma non in generale.

• [C-1-2] I codificatori e i decoder video DEVONO supportare lo standard YUV420 con formato 8:8:8, colore flessibile formati (COLOR_FormatYUV420Flexible) a CodecCapabilities.

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

• [C-SR-1] I codificatori e i decoder video sono VIVAMENTE CONSIGLIATI di supportare almeno uno di un colore planare o semiplanare YUV420 8:8:8 ottimizzato per l'hardware (YV12, NV12, NV21 o formato ottimizzato equivalente del fornitore).

• [C-1-5] Decodificatori video che supportano un formato con profondità di bit elevata (9+ bit per canale) DEVE supportare l'output di un formato equivalente a 8 bit se richiesto dall'applicazione. Ciò DEVE essere dimostrato dal supporto di Formato colore YUV420 8:8:8 tramite android.media.MediaCodecInfo.

Se le implementazioni del dispositivo pubblicizzano il supporto del profilo HDR tramite Display.HdrCapabilities, l'utente:

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

Se le implementazioni dei dispositivi pubblicizzano il supporto intra-aggiornamento tramite FEATURE_IntraRefresh in MediaCodecInfo.CodecCapabilities in questa classe:

• [C-3-1] DEVE supportare periodi di aggiornamento nell'intervallo 10-60 frame e funzionino accuratamente entro il 20% del periodo di aggiornamento configurato.

A meno che l'applicazione non specifichi diversamente utilizzando il file KEY_COLOR_FORMAT chiave di formato, implementazioni del decoder video:

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

5.1.8. Elenco codec video

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

5.1.9. Sicurezza del codec multimediale

Le implementazioni dei dispositivi DEVONO garantire la conformità alle funzioni di sicurezza del codec multimediale. come descritto di seguito.

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

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

• [C-1-1] DEVE fornire il supporto per i codec multimediali tramite OMX o Codec 2.0 API (o entrambe) come nel progetto open source Android e non disattivare né eludere le misure protettive di sicurezza. Nello specifico, ciò non significa che ogni codec DEVE utilizzare l'API OMX o Codec 2.0, solo che il supporto per almeno una di queste API DEVE essere disponibile e il supporto per includono le protezioni di sicurezza presenti.
• [C-SR-1] CONSIGLIATO VIVAMENTE di includere il supporto per l'API Codec 2.0.

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

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

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

• [C-3-1] DEVE includere il codec software corrispondente del Codec 2.0 della Android Open Source Project (se disponibile) per ogni tipo e formato multimediale (encoder o decoder) supportati dal dispositivo.
• [C-3-2] DEVONO contenere i codec software del Codec 2.0 nel codec software fornita nell'Android Open Source Project per rendere possibile per concedere in modo più limitato l'accesso ai codec software.
• [C-3-3] Codec i cui nomi iniziano con "c2.android". DEVE essere basato sul loro codice sorgente Android Open Source Project.

5.1.10. Caratterizzazione del codec multimediale

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

• [C-1-1] DEVE restituire i valori corretti di caratterizzazione del codec multimediale tramite MediaCodecInfo tramite Google Cloud CLI o tramite l'API Compute Engine.

In particolare:

• [C-1-2] Codec con nomi che iniziano con "OMX." DEVE utilizzare le API OMX con nomi conformi alle linee guida per la denominazione di OMX IL.
• [C-1-3] Codec con nomi che iniziano con "c2." DEVONO utilizzare l'API Codec 2.0 e hanno 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". DEVE NON essere caratterizzati come fornitore o con accelerazione hardware.
• [C-1-5] Codec eseguiti in un processo codec (fornitore o sistema) con l'accesso a driver hardware diversi dagli allocatori della memoria e dai mappatori NON DEVE essere definite solo software.
• [C-1-6] Codec non presenti nell'Android Open Source Project o non basati nel codice sorgente del progetto DEVE essere definito "fornitore".
• [C-1-7] I codec che utilizzano l'accelerazione hardware DEVONO essere caratterizzati con l'accelerazione hardware.
• [C-1-8] I nomi dei codec NON DEVONO essere fuorvianti. Ad esempio, i codec denominati "decoder" DEVONO supportare la decodifica e quelli denominati "encoder" DEVE supportare codifica. I codec con nomi contenenti formati multimediali DEVONO supportare tali formati.

Se le implementazioni dei dispositivi supportano i codec video:

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

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

5.2. Codifica video

Se le implementazioni dei dispositivi includono un display incorporato con diagonale di almeno 2,5 pollici o includere una porta di uscita video dichiarare il supporto di una videocamera tramite il android.hardware.camera.any flag funzionalità, questi:

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

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

• [C-2-1] DEVE supportare la velocità in bit configurabile dinamicamente.
• DOVREBBE supportare frequenze fotogrammi variabili, laddove il codificatore video DEVE determinare la durata istantanea dei frame basata sui timestamp dei buffer di input e alloca il proprio bucket di bit in base alla durata del frame.

Se le implementazioni del dispositivo supportano il codificatore video MPEG-4 SP e lo rendono disponibili per le app di terze parti, questi:

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

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

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

Se le implementazioni dei dispositivi forniscono la codifica HDR:

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

5.2.1. H.263

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

• [C-1-1] DEVE supportare la risoluzione QCIF (176 x 144) utilizzando Livello 45 del profilo di riferimento. La risoluzione SQCIF è facoltativa.
• DEVE supportare la velocità in bit configurabile dinamicamente per l'encoder supportato.

5.2.2. H.264

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

• [C-1-1] DEVE supportare il livello 3 del profilo di riferimento. Tuttavia, supporto per ASO (Ordine arbitrario delle sezioni), FMO (flessibile) Macroblock Ordering) e RS (Sezioni ridondanti) sono FACOLTATIVI. Inoltre, per mantenere la compatibilità con altri dispositivi Android, è consigliabile ASO, FMO e RS non vengono utilizzati per il profilo di riferimento dai codificatori.
• [C-1-2] DEVE supportare i profili di codifica video SD (Standard Definition) nella tabella seguente.
• DEVE supportare il livello del profilo principale 4.
• DEVONO supportare i profili di codifica video HD (High Definition) come indicati nella tabella seguente.

Se le implementazioni del dispositivo segnalano il supporto della codifica H.264 per 720p o 1080p risoluzione dei problemi tramite le API multimediali, questi:

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

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

5.2.3. VP8

Se le implementazioni del dispositivo supportano il codec VP8:

• [C-1-1] DEVE supportare i profili di codifica video SD.
• DEVONO supportare i seguenti profili di codifica video HD (alta definizione).
• [C-1-2] DEVE supportare la scrittura di file Matroska WebM.
• DOVREBBE fornire un codec VP8 hardware che soddisfa i Requisiti di programmazione hardware RTC del progetto WebM, per garantire qualità accettabile dei servizi di streaming video e di videoconferenze.

Se le implementazioni del dispositivo segnalano il supporto della codifica VP8 per 720p o 1080p risoluzione dei problemi tramite le API multimediali, questi:

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

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

5.2.4. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

• [C-1-2] DEVE supportare il livello 3 del profilo 0.
• [C-1-1] DEVE supportare la scrittura di file Matroska WebM.
• [C-1-3] DEVE generare dati CodecPrivate.
• DEVONO supportare i profili di decodifica HD come indicato nella tabella seguente.
• [C-SR-1] è VIVAMENTE CONSIGLIATO per il supporto dei profili di decodifica HD, indicato nella tabella seguente se è presente un codificatore hardware.

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

Se le implementazioni del dispositivo dichiarano di supportare il Profilo 2 o 3 tramite il API multimediali:

• Il supporto per il formato a 12 bit è FACOLTATIVO.

5.2.5. H.265

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

• [C-1-1] DEVE supportare il livello 3 del profilo principale fino al Risoluzione 512 x 512.
• DEVE supportare i profili di codifica HD come indicato nella tabella seguente.
• [C-SR-1] è VIVAMENTE CONSIGLIATO per supportare Profilo SD 720 x 480 e il Profili di codifica HD come indicato nella tabella seguente, se è presente un l'encoder 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 del dispositivo supportano i codec VP8, VP9, H.264 o H.265:

• [C-1-1] DEVE supportare la risoluzione video dinamica e il cambio di frequenza fotogrammi tramite le API Android standard all'interno dello stesso stream per tutti Codec H.264 e H.265 in tempo reale e fino alla massima risoluzione supportata da ciascun codec sul dispositivo.

5.3.1. MPEG-2

Se le implementazioni dei dispositivi supportano i decoder MPEG-2:

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

Se l'altezza riportata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, le implementazioni dei dispositivi:

• [C-2-1] DEVE supportare i profili di decodifica video HD 720p nei seguenti .
• [C-2-2] DEVE supportare i profili di decodifica video HD 1080p nei seguenti .

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

5.3.5. H.265 (HEVC)

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

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

Se l'altezza riportata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, allora:

• [C-2-1] Le implementazioni dei dispositivi DEVONO supportare almeno uno dei formati H.265 o VP9 decodifica di profili 720, 1080 e UHD.

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

Se le implementazioni del dispositivo dichiarano di supportare un profilo HDR tramite i contenuti multimediali API:

• [C-3-1] Le implementazioni dei dispositivi DEVONO accettare i metadati HDR richiesti dalle dell'applicazione, oltre a supportare l'estrazione e l'output dei contenuti HDR richiesti e i metadati dal flusso di bit e/o dal container.
• [C-3-2] Le implementazioni dei dispositivi DEVONO visualizzare correttamente i contenuti HDR sui schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

5.3.6. VP8

Se le implementazioni del dispositivo supportano il codec VP8:

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

Se l'altezza riportata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, allora:

• [C-2-1] Le implementazioni dei dispositivi DEVONO supportare i profili da 720p in seguente.
• [C-2-2] Le implementazioni dei dispositivi DEVONO supportare i profili 1080p in seguente.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	30 f/s (60 f/stelevisore)	30 (60 f/stelevisore)
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 seguente.
• DEVONO supportare i profili di decodifica HD come indicato nella tabella seguente.

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

• [C-2-1] DEVE supportare i profili di decodifica HD come indicato nelle .

Se l'altezza riportata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, allora:

• [C-3-1] Le implementazioni dei dispositivi DEVONO supportare almeno uno dei formati VP9 o H.265 decodifica dei profili 720, 1080 e UHD.

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

Se le implementazioni del dispositivo dichiarano di supportare VP9Profile2 o VP9Profile3 tramite "CodecProfileLevel" API multimediali:

• Il supporto per il formato a 12 bit è FACOLTATIVO.

Se le implementazioni del dispositivo dichiarano di supportare un profilo HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) tramite API multimediali:

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

5.3.8. Dolby Vision

Se le implementazioni del dispositivo dichiarano il supporto per il decoder Dolby Vision tramite HDR_TYPE_DOLBY_VISION , questi:

• [C-1-1] DEVE fornire un estrattore compatibile con Dolby Vision.
• [C-1-2] DEVE visualizzare correttamente i contenuti Dolby Vision sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).
• [C-1-3] DEVE impostare l'ID traccia di strati di base compatibili con le versioni precedenti (se presenti) in modo che siano uguali combinato con l'ID traccia del livello Dolby Vision.

5.3.9. AV1

5.4. Registrazione audio

Anche se alcuni dei requisiti descritti in questa sezione sono indicati come "DOVREBBE" a partire da Android 4.3, la definizione di compatibilità per le versioni future è in programma per cambiarle in DEVE. I dispositivi Android nuovi ed esistenti sono VIVAMENTE CONSIGLIATI per soddisfare questi requisiti, indicati come DOVRESTI, oppure non potrai raggiungere la compatibilità con Android dopo l'upgrade. completamente gestita.

5.4.1. Acquisizione audio non elaborata e informazioni del microfono

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

• [C-1-1] DEVE consentire l'acquisizione di contenuti audio non elaborati per qualsiasi flusso AudioRecord o AAudio INPUT aperto correttamente. DEVONO essere supportate almeno le seguenti caratteristiche:

  • Formato: PCM lineare, 16 bit
  • Frequenze di campionamento: 8000, 11025, 16000, 44100, 48000 Hz
  • Canali: mono
  • Sorgenti audio:DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, o VOICE_PERFORMANCE. Questo vale anche per i predefiniti di input equivalenti in AAudio, per ad esempio AAUDIO_INPUT_PRESET_CAMCORDER.

• DEVE consentire l'acquisizione di contenuti audio non elaborati con quanto segue: caratteristiche:

  • Formato: PCM lineare, 16 bit e 24 bit
  • Frequenze di campionamento: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48.000 Hz
  • Canali: un numero di canali uguale al numero di microfoni sul dispositivo

• [C-1-2] DEVE effettuare l'acquisizione a frequenze di campionamento superiori senza eseguire l'up-sampling.

• [C-1-3] DEVE includere un filtro anti-aliasing appropriato quando le frequenze di campionamento sopra indicate vengono acquisite tramite il downsampling.

• DOVREBBE consentire l'acquisizione di qualità radio AM e DVD di contenuti audio non elaborati, indica le seguenti caratteristiche:

  • Formato: PCM lineare, a 16 bit
  • Frequenze di campionamento: 22050, 48000 Hz
  • Canali: stereo

• [C-1-4] DEVE rispettare l'API MicrophoneInfo e inserisci correttamente le informazioni relative ai microfoni disponibili sul dispositivo accessibile alle applicazioni di terze parti tramite AudioManager.getMicrophones() per l'AudioRecord attivo utilizzando MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED o VOICE_PERFORMANCE. Se le implementazioni del dispositivo consentono l'acquisizione di audio non elaborato in qualità radio AM e DVD contenuti:

• [C-2-1] DEVE acquisire senza eseguire l'up-sampling a qualsiasi rapporto superiore a 16000:22050 o 44100:48000.

• [C-2-2] DEVE includere un filtro anti-aliasing appropriato per qualsiasi up-sampling o down-sampling.

5.4.2. Acquisisci per il riconoscimento vocale

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

• [C-1-1] DEVE acquisire android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION sorgente audio in una delle frequenze di campionamento, 44100 e 48000.
• [C-1-2] DEVE, per impostazione predefinita, disattivare l'elaborazione audio per la riduzione del rumore durante registrando uno stream audio dall'audio AudioSource.VOICE_RECOGNITION sorgente.

• [C-1-3] DEVE, per impostazione predefinita, disattivare qualsiasi controllo automatico del guadagno durante la registrazione uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.

• DOVREBBE mostrare caratteristiche di ampiezza e frequenza approssimativamente piatta nel campo delle medie frequenze: specificamente ±3dB da 100 Hz a 4000 Hz per e tutti i microfoni utilizzati per registrare la sorgente audio del riconoscimento vocale.

• [C-SR-1] È VIVAMENTE CONSIGLIATO di mostrare livelli di ampiezza nelle zone basse nell'intervallo di frequenza: specificatamente da ±20 dB da 30 Hz a 100 Hz rispetto alla gamma media di frequenza per ogni microfono usato per registrare la voce sorgente audio di riconoscimento.

• [C-SR-2] È VIVAMENTE CONSIGLIATO di mostrare livelli di ampiezza nelle zone alte gamma di frequenza: specificamente da ±30 dB da 4000 Hz a 22 KHz rispetto a la gamma di media frequenza per ogni microfono usato per registrare la voce sorgente audio di riconoscimento.

• DEVI impostare la sensibilità dell’ingresso audio in modo che una sorgente di tono sinusoidale a 1000 Hz suonata a 90 dB Livello di pressione sonora (SPL) (misurato a una distanza di 30 cm da accanto al microfono) offre una risposta ideale di RMS 2500 entro un intervallo di 1770 e 3530 per 16 campionamenti di bit (o -22,35 db ±3dB Full Scale per rappresentazione in virgola mobile/doppia precisione campioni) per ogni microfono usato per registrare il riconoscimento vocale sorgente audio.

• DOVREBBE registrare lo stream audio di riconoscimento vocale in modo che l'ampiezza PCM livelli di pressione lineare per la traccia di ingresso su un intervallo di almeno 30 dB compreso tra -18 da dB a +12 dB re 90 dB SPL al microfono.

• DEVI registrare lo stream audio con riconoscimento vocale con armoniche totali (THD) inferiore all'1% per 1 kHz a 90 dB livello di ingresso SPL a microfono.

Se le implementazioni del dispositivo dichiarano android.hardware.microphone e rumore tecnologie di soppressione (riduzione) ottimizzate per il riconoscimento vocale:

• [C-2-1] DEVE consentire che questo effetto audio sia controllabile con il metodo API android.media.audiofx.NoiseSuppressor.
• [C-2-2] DEVE identificare in modo univoco ciascuna tecnologia di soppressione del rumore implementazione tramite il campo AudioEffect.Descriptor.uuid.

5.4.3. Acquisisci per il reindirizzamento della riproduzione

Il corso android.media.MediaRecorder.AudioSource include il REMOTE_SUBMIX sorgente audio.

Se le implementazioni del dispositivo dichiarano sia android.hardware.audio.output che android.hardware.microphone, l'utente:

• [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 questo sorgente audio, acquisisce un mix di tutti gli stream audio, ad eccezione di quelli seguenti:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. Cancellatore dell'eco acustica

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

• DEVI implementare un cancellatore dell'eco acustico Tecnologia (AEC) ottimizzata per la comunicazione vocale e applicata al percorso di acquisizione durante l'acquisizione con AudioSource.VOICE_COMMUNICATION.

Se le implementazioni del dispositivo forniscono un Cancellazione dell'eco acustico, inserita nel percorso di acquisizione dell'audio quando AudioSource.VOICE_COMMUNICATION viene selezionato, questi:

• [C-SR-1] sono StrongLY_RECOMMENDED a dichiararlo tramite AcousticEchoCanceler Metodo API AcousticEchoCanceler.isAvailable()
• I [C-SR-2] sono StrongLY_RECOMMENDED per consentire la pubblicazione di questo effetto audio controllabile con AcousticEchoCanceler tramite Google Cloud CLI o tramite l'API Compute Engine.
• I [C-SR-3] sono StrongLY_RECOMMENDED per identificare in modo univoco ciascuna tecnologia AEC dell'implementazione tramite AudioEffect.Descriptor.uuid. .

5.4.5. Acquisizione simultanea

Se le implementazioni dei dispositivi dichiarano android.hardware.microphone,DEVONO implementare l'acquisizione simultanea come descritto in questo documento. Nello specifico:

• [C-1-1] DEVE consentire l'accesso simultaneo al microfono da parte di un acquisizione del servizio con AudioSource.VOICE_RECOGNITION e almeno uno l'acquisizione dell'applicazione con qualsiasi AudioSource.
• [C-1-2] DEVE consentire l'accesso simultaneo al microfono da parte di un che possiede un ruolo di Assistente e almeno un'applicazione acquisire con qualsiasi valore AudioSource ad eccezione di AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER.
• [C-1-3] DEVE disattivare l'audio dell'acquisizione per qualsiasi altra applicazione, ad eccezione di un servizio di accessibilità, mentre un'applicazione sta acquisendo AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER. Tuttavia, quando sta registrando un'app tramite AudioSource.VOICE_COMMUNICATION e poi un'altra app può acquisire la chiamata vocale se si tratta di un'app con privilegi (preinstallata) con autorizzazione CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Se due o più richieste vengono acquisite contemporaneamente e se nessuna delle due app ha un'interfaccia utente nella parte superiore, quella da cui è iniziato l'acquisizione più recente riceve audio.

5.5. Riproduzione audio

Android include il supporto per consentire alle app di riprodurre audio tramite l'audio periferica di uscita come definita nella sezione 7.8.2.

5.5.1. Riproduzione audio RAW

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

• [C-1-1] DEVE consentire la riproduzione di contenuti audio non elaborati con quanto segue: caratteristiche:

  • Formati di origine: PCM lineare, 16 bit, 8 bit, numero in virgola mobile
  • Canali: mono, stereo, configurazioni multicanale valide con un massimo di 8 canali
  • Frequenze di campionamento (in Hz):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 al canale configurazioni elencate sopra
    • 96000 in mono e stereo

5.5.2. Effetti audio

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

Se le implementazioni dei dispositivi dichiarano la funzionalità android.hardware.audio.output, l'utente:

• [C-1-1] DEVE supportare EFFECT_TYPE_EQUALIZER e le implementazioni EFFECT_TYPE_LOUDNESS_ENHANCER controllabili tramite le sottoclassi AudioEffect Equalizer e LoudnessEnhancer.
• [C-1-2] DEVE supportare l'implementazione dell'API del visualizzatore, controllabile tramite il corso Visualizer.
• [C-1-3] DEVE supportare l'implementazione di EFFECT_TYPE_DYNAMICS_PROCESSING controllabile tramite la sottoclasse AudioEffect DynamicsProcessing.

• DOVREBBE supportare EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, Implementazioni di EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controllabile tramite le AudioEffect sottoclassi BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.
• [C-SR-1] CONSIGLIATE VIVAMENTE per il supporto di effetti in rappresentazione in virgola mobile e multicanale.

5.5.3. Volume di uscita audio

Implementazioni di dispositivi nel settore auto e motori:

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

5.5.4. Offload audio

Se le implementazioni del dispositivo supportano la riproduzione con trasferimento audio, questi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di tagliare i contenuti audio gapless riprodotti tra due clip dello stesso formato quando specificato API gapless AudioTrack e il container multimediale per MediaPlayer.

5.6. Latenza audio

La latenza audio è il ritardo di un segnale audio che passa attraverso un sistema. Molte classi di applicazioni si basano su brevi latenze per ottenere dati effetti sonori.

Ai fini di questa sezione, utilizza le seguenti definizioni:

• latenza di output. L'intervallo tra la scrittura di un frame da parte di un'applicazione di dati in codice PCM e quando il suono corrispondente viene presentato ambiente a un trasduttore sul dispositivo, oppure il segnale esce dal dispositivo tramite una e possono essere osservate esternamente.
• latenza di output a freddo. Il tempo che intercorre tra l'avvio di un flusso di output e la di presentazione del primo frame in base ai timestamp, quando l'output audio il sistema è stato inattivo e si è spento prima della richiesta.
• latenza di output continua. la latenza di output per i frame successivi, dopo la riproduzione dell'audio sul dispositivo.
• latenza dell'input. L'intervallo tra il momento in cui un suono viene presentato da dall'ambiente al dispositivo quando un trasduttore o un segnale sul dispositivo entra nel dispositivo tramite una porta e quando un'applicazione legge il frame corrispondente di dati codificati PCM.
• input perso. La parte iniziale di un segnale di input che è inutilizzabile o non disponibile.
• latenza di input a freddo. Il tempo che intercorre tra l'avvio dello streaming e il momento in cui viene ricevuto il primo frame valido, quando il sistema di input audio è inattivo e prima della richiesta.

• latenza di input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.

• latenza di round trip continua. La somma della latenza di input continuo più latenza di output continua più un periodo di buffer. Il periodo di buffer consente il tempo impiegato dall'app per elaborare l'indicatore e il tempo necessario per mitigare la fase differenza tra i flussi di input e quelli di output.

• API OpenSL ES PCM buffer Queue L'insieme di strumenti legati al PCM OpenSL ES API in Android NDK.

• Un'API audio nativa audio. L'insieme API AAudio in Android NDK.

• Timestamp: Una coppia costituita dalla posizione relativa di un frame all'interno di un e il tempo stimato in cui il frame entra o esce dalla pipeline di elaborazione audio sull'endpoint associato. Vedi anche AudioTimestamp:

• glitch. Un'interruzione temporanea o un valore di campionamento errato del segnale audio. in genere causato da un buffer underrun per l'output, buffer overrun per l'ingresso o qualsiasi altra fonte di rumore digitale o analogico.

• deviazione media assoluta. La media del valore assoluto del deviazioni dalla media di un insieme di valori.

• latenza tocco per toni. Il tempo che intercorre tra il momento in cui viene toccato lo schermo e il momento in cui l'altoparlante sentirà un segnale acustico.

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

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

• [C-1-2] Latenza di output a freddo di 500 millisecondi o meno.

• [C-1-3] L'apertura di un flusso di output utilizzando AAudioStreamBuilder_openStream() DEVE in meno di 1000 ms.

Se le implementazioni dei dispositivi dichiarano android.hardware.audio.output che sono VIVAMENTE CONSIGLIATO di soddisfare o superare i seguenti requisiti:

• [C-SR-1] Latenza uscita a freddo pari o inferiore a 100 millisecondi per i dati dello speaker del tuo percorso di apprendimento.
• [C-SR-2] Latenza Tono per tocco di 80 millisecondi o meno.

Se le implementazioni dei dispositivi soddisfano i requisiti di cui sopra, dopo qualsiasi quando si utilizza l'API audio nativa AAudio per un output continuo latenza e latenza di output a freddo su almeno un audio supportato dispositivo di output, ovvero:

• [C-SR-5] VIVAMENTE CONSIGLIATO di segnalare l'audio a bassa latenza dichiarando Flag funzionalità android.hardware.audio.low_latency.
• [C-SR-6] VIVAMENTE CONSIGLIATO per soddisfare i requisiti della bassa latenza tramite l'API AAudio.
• [C-SR-7] VIVAMENTE CONSIGLIATO per garantire che per gli stream che ritornano AAUDIO_PERFORMANCE_MODE_LOW_LATENCY da AAudioStream_getPerformanceMode(), il valore restituito da AAudioStream_getFramesPerBurst() è inferiore o uguale al valore restituito da android.media.AudioManager.getProperty(String) per la chiave proprietà AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Se le implementazioni del dispositivo non soddisfano i requisiti per l'audio a bassa latenza tramite l'API AAudio Native Audio, questi:

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

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

• [C-3-1] Limita l'errore nei timestamp di input, come restituito AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 2 ms. "Errore" indica la deviazione dal valore corretto.
• [C-3-2] Latenza dell'input a freddo di 500 millisecondi o meno.
• [C-3-3] L'apertura di uno stream di input utilizzando AAudioStreamBuilder_openStream() DEVE in meno di 1000 ms.

Se le implementazioni dei dispositivi includono android.hardware.microphone, vengono VIVAMENTE CONSIGLIATO per soddisfare questi requisiti di input audio:

• [C-SR-8] Latenza input a freddo pari o inferiore a 100 millisecondi sul microfono percorso dati.

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

Se le implementazioni dei dispositivi dichiarano android.hardware.audio.output e android.hardware.microphone, l'utente:

• [C-SR-12] È VIVAMENTE CONSIGLIATO avere una latenza media di andata e ritorno continua di 50 millisecondi o meno su 5 misurazioni, con deviazione media assoluta meno di 10 msec, su almeno un percorso supportato.

5.7. Protocolli di rete

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

Per ogni codec e formato contenitore richiesto per l'implementazione su dispositivo assistenza, l'implementazione del dispositivo:

• [C-1-1] DEVE supportare il codec o il container tramite HTTP e HTTPS.

• [C-1-2] DEVE supportare i formati dei segmenti multimediali corrispondenti, come mostrato in la tabella dei formati dei segmenti multimediali riportata di seguito Protocollo di bozza di HTTP Live Streaming, versione 7.

• [C-1-3] DEVE supportare i corrispondenti formati payload RTSP, come mostrato in nella tabella RTSP riportata di seguito. Per le eccezioni, vedi le note a piè di pagina nella tabella sezione 5.1.

Formati dei segmenti multimediali

Formati dei segmenti	Riferimenti	Supporto codec richiesto
Stream di trasporto MPEG-2	ISO 13818	Codec video: AVC H264 MPEG-4 SP MPEG-2 Consulta la sezione 5.1.8 per maggiori dettagli su H264 AVC, MPEG2-4 SP, e MPEG-2. Codec audio: AAC Consulta la sezione 5.1.3 per informazioni dettagliate su AAC e sulle sue varianti.
AAC con inquadratura ADTS e tag ID3	ISO 13818-7	Vedi la sezione 5.1.1 per i dettagli su AAC e sulle sue varianti
WebVTT	WebVTT

RTSP (RTP, SDP)

Nome del profilo	Riferimenti	Supporto codec richiesto
AVC H264	RFC 6184	Vedi la sezione 5.1.8 per informazioni dettagliate sull'AVC H264
MP4A-LATM	RFC 6416	Vedi la sezione 5.1.3 per i dettagli su AAC e sulle sue varianti
H263-1998	RFC 3551 RFC 4629 RFC 2190	Vedi la sezione 5.1.8 per maggiori dettagli su H263
263-2000	RFC 4629	Vedi la sezione 5.1.8 per maggiori dettagli su H263
Retrospettiva	RFC 4867	Vedi la sezione 5.1.3 per dettagli su AMR-NB
AMR-WB	RFC 4867	Vedi la sezione 5.1.3 per dettagli su AMR-WB
MP4V-ES	RFC 6416	Vedi la sezione 5.1.8 per informazioni dettagliate su MPEG-4 SP
mpeg4-generico	RFC 3640	Vedi la sezione 5.1.3 per i dettagli su AAC e sulle sue varianti
MP2T	RFC 2250	Per maggiori dettagli, consulta MPEG-2 Transport Stream sotto Live Streaming HTTP

5.8 Contenuti multimediali sicuri

Se le implementazioni del dispositivo supportano l'output video sicuro e sono in grado di che supportano superfici sicure, possono:

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

Se le implementazioni del dispositivo dichiarano il supporto per Display.FLAG_SECURE e l'assistenza il protocollo display wireless, questi:

• [C-2-1] DEVE proteggere il collegamento con un meccanismo crittograficamente efficace, come HDCP 2.x o superiore per i display collegati tramite protocolli wireless come Miracast.

Se le implementazioni dei dispositivi dichiarano il supporto per Display.FLAG_SECURE e supportano un display esterno cablato, questi:

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

5.9 MIDI (Musical Instrument Digital Interface)

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

• [C-1-1] DEVE supportare il protocollo MIDI su tutti i trasporti hardware compatibili con MIDI per che forniscono una connettività generica non MIDI, dove tali trasporti sono:

  • Modalità host USB, sezione 7.7
  • MIDI over Bluetooth LE con ruolo centrale, sezione 7.4.3

• [C-1-2] DEVE supportare il trasporto del software MIDI tra app (dispositivi MIDI virtuali)

• [C-1-3] DEVE includere libamidi.so (supporto MIDI nativo)

• DEVE supportare la modalità periferica MIDI over USB, sezione 7.7

5.10. Audio professionale

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

• [C-1-1] DEVE segnalare il supporto della funzionalità android.hardware.audio.low_latency.
• [C-1-2] DEVE avere la latenza audio di andata e ritorno continua, come definito in sezione 5.6 Latenza audio di Massimo 25 millisecondi su almeno un percorso supportato.
• [C-1-3] DEVE includere una o più porte USB che supportano la modalità host USB e modalità periferica.
• [C-1-4] DEVE segnalare il supporto della funzionalità android.software.midi.
• [C-1-5] DEVE soddisfare i requisiti relativi a latenze e audio USB utilizzando Audio nativo audio API e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [C-1-6] DEVE avere una latenza dell'output a freddo pari o inferiore a 200 millisecondi.
• [C-1-7] DEVE avere una latenza dell'input freddo pari o inferiore a 200 millisecondi.

• [C-1-8] DEVE avere una latenza media tocco per toni di 80 millisecondi o meno del percorso dei dati dagli altoparlanti al microfono per almeno 5 misurazioni.

• [C-SR-1] È VIVAMENTE CONSIGLIATO di rispettare le latenze definite nella sezione 5.6 Latenza audio, di 20 millisecondi o inferiore, oltre 5 misurazioni con una deviazione media assoluta inferiore a 5 di millisecondi sopra il percorso tra l'altoparlante e il microfono.

• [C-SR-2] È VIVAMENTE CONSIGLIATO di soddisfare i requisiti dell'audio Pro per latenza audio andata e ritorno continua, latenza di input a freddo e output a freddo latenza e requisiti audio USB utilizzando l'API AAudio native audio sul percorso MMAP.

• [C-SR-3] È VIVAMENTE CONSIGLIATO di fornire un livello coerente di CPU mentre l'audio è attivo e il carico della CPU varia. Questo aspetto deve essere verificato utilizzando l'app per Android SynthMark. SynthMark utilizza un sintetizzatore software in esecuzione su un framework audio simulato che misura le prestazioni del sistema. Consulta le Documentazione di SynthMark per una spiegazione dei benchmark. SynthMark l'app deve essere eseguita utilizzando l'opzione "Test automatico" e ottenere i seguenti risultati:

  • voicemark.90 >= 32 voci
  • latenzamark.fixed.little <= 15 msec
  • latenzamark.dynamic.little <= 50 msec

• DEVE ridurre al minimo l'imprecisione e la deviazione dell'orologio audio rispetto all'ora standard.

• DEVE ridurre al minimo la deviazione del clock audio rispetto alla CPU CLOCK_MONOTONIC quando entrambi sono attivi.

• DEVE ridurre al minimo la latenza audio sui trasduttori sul dispositivo.

• DEVE ridurre al minimo la latenza audio in caso di audio digitale USB.

• DEVE documentare le misurazioni della latenza audio su tutti i percorsi.

• DEVE ridurre al minimo il tremolio nei tempi di ingresso del callback di completamento del buffer audio, in quanto incide sulla percentuale utilizzabile di larghezza di banda completa della CPU da parte del callback.

• DEVE fornire zero glitch audio in condizioni di normale utilizzo alla latenza segnalata.

• DEVE fornire zero differenze di latenza tra canali.

• DEVE ridurre al minimo la latenza media MIDI su tutti i trasporti.

• DEVE ridurre al minimo la variabilità della latenza MIDI sotto carico (jitter) su tutti i trasporti.

• DOVREBBE fornire timestamp MIDI precisi su tutti i trasporti.

• DEVE ridurre al minimo il rumore del segnale audio sui trasduttori sul dispositivo, tra cui immediatamente dopo l'avvio a freddo.

• DOVREBBE fornire una differenza di orologio audio pari a zero tra i lati di ingresso e di uscita endpoint corrispondenti, quando entrambi sono attivi. Esempi di corrispondenti I punti finali includono il microfono e l'altoparlante sul dispositivo o l'ingresso jack audio e output.

• DOVREBBE gestire i callback di completamento del buffer audio per i lati di ingresso e di uscita di endpoint corrispondenti sullo stesso thread quando entrambi sono attivi e inserisci il callback di output subito dopo il ritorno dal callback di input. Oppure: se non è possibile gestire i callback sullo stesso thread, inserisci il il callback di output poco dopo essere entrato nel callback di input per consentire per avere una tempistica coerente dei lati di input e output.

• DEVE ridurre al minimo la differenza di fase tra il buffering audio HAL per l'input e di output degli endpoint corrispondenti.

• DEVE ridurre al minimo la latenza al tocco.

• DEVE ridurre al minimo la variabilità della latenza al tocco sotto carico (jitter).

Se le implementazioni dei dispositivi soddisfano tutti i requisiti di cui sopra:

• [C-SR-4] VIVAMENTE CONSIGLIATO di segnalare il supporto della funzionalità android.hardware.audio.pro tramite android.content.pm.PackageManager .

Se le implementazioni del dispositivo includono un jack audio da 3,5 mm a 4 conduttori, questi:

• [C-2-1] DEVE avere una latenza media di audio andata e ritorno, come definita in sezione 5.6 Latenza audio, di massimo 20 millisecondi, oltre 5 misurazioni con una deviazione media assoluta inferiore a 5 millisecondi il percorso jack audio utilizzando Chiavetta di loopback audio.

• [C-SR-5] VIVAMENTE CONSIGLIATA di rispettare le sezione Specifiche dei dispositivi mobili (jack) della specifica delle cuffie audio con cavo (v1.1).

Se le implementazioni del dispositivo omettono un jack audio da 3,5 mm a 4 conduttori e Includono una o più porte USB che supportano la modalità host USB, gli elementi:

• [C-3-1] DEVE implementare la classe audio USB.
• [C-3-2] DEVE avere una latenza media di audio andata e ritorno continua di Massimo 25 millisecondi, oltre 5 misurazioni con deviazione media assoluta meno di 5 millisecondi sulla porta in modalità host USB utilizzando la classe audio USB. (La misurazione può essere eseguita utilizzando un adattatore USB-3,5 mm e un loopback audio Chiavetta o utilizzo di un'interfaccia audio USB con cavi patch che collegano input e output).
• [C-SR-6] È VIVAMENTE CONSIGLIATO per il supporto di I/O simultanei fino a 8 canali ciascuna direzione, frequenza di campionamento di 96 kHz e profondità a 24 bit o 32 bit, se utilizzati con periferiche audio USB che supportano anche questi requisiti.
• [C-SR-7] È VIVAMENTE CONSIGLIATO di soddisfare questo gruppo di requisiti utilizzando l'API AAudio native audio sul percorso MMAP.

Se le implementazioni dei dispositivi includono una porta HDMI:

• DOVREBBE supportare l'uscita in stereo e otto canali a 20 bit o profondità a 24 bit e 192 kHz senza perdita o ricampionamento della profondità di bit. in almeno una configurazione.

5.11. Acquisisci per i dati non elaborati

Android supporta la registrazione di audio non elaborato tramite il android.media.MediaRecorder.AudioSource.UNPROCESSED sorgente audio. Nel OpenSL ES, è possibile accedervi con la preimpostazione di registrazione SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Se le implementazioni del dispositivo intendono supportare una sorgente audio non elaborata e rendere a disposizione di app di terze parti, queste:

• [C-1-1] DEVE segnalare l'assistenza tramite il android.media.AudioManager proprietà PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] DEVE mostrare una frequenza approssimativamente piatta tra ampiezza e frequenza caratteristiche nella gamma di frequenza media: in particolare ±10 dB da da 100 Hz a 7000 Hz per ogni microfono utilizzato per registrare i sorgente audio.

• [C-1-3] DEVE mostrare livelli di ampiezza nella frequenza bassa in particolare da ±20 dB da 5 z a 100 Hz rispetto ai a media gamma di frequenza per ogni microfono usato per registrare sorgente audio non elaborata.

• [C-1-4] DEVE mostrare livelli di ampiezza nella frequenza alta in particolare da ±30 dB da 7000 Hz a 22 KHz rispetto alla a media gamma di frequenza per ogni microfono usato per registrare sorgente audio non elaborata.

• [C-1-5] DEVE impostare la sensibilità dell'ingresso audio in modo tale che una la sorgente sonora riprodotta a 94 dB Sound Pressure Level (SPL) produce una risposta con RMS di 520 per campioni a 16 bit (o di -36 dB scala completa per floating/doppio campioni di precisione) per ogni microfono usato per registrare i sorgente audio.

• [C-1-6] DEVE avere un rapporto segnale-rumore (SNR) a 60 dB o superiore per tutti i microfoni utilizzati per registrare la sorgente audio non elaborata. (mentre l'SNR viene misurato come differenza tra 94 dB SPL e l'equivalente SPL di autorumore, ponderato in base alla curva A).

• [C-1-7] DEVE avere una distorsione armonica totale (THD) minore che inferiore a 1% per il livello di ingresso di 1 kHZ a 90 dB SPL per ogni microfono utilizzato registrare la sorgente audio non elaborata.

• [C-1-8] DEVE non avere altre elaborazioni del segnale (ad esempio, il guadagno automatico Ctrl, Filtro High Pass o Cancellazione dell'eco) nel percorso diverso da moltiplicatore di livelli per portare il livello all'intervallo desiderato. In altre parole:

  • [C-1-9] Se nell’architettura è presente un’elaborazione del segnale per qualsiasi motivo, DEVE essere disattivato e introdurre effettivamente un ritardo pari a zero latenza aggiuntiva al percorso del segnale.
  • [C-1-10] Il moltiplicatore di livelli, sebbene possa essere sul percorso, NON DEVE introdurre ritardi o latenza nel percorso del segnale.

Tutte le misurazioni SPL vengono effettuate direttamente accanto al microfono sottoposto a test. In caso di più configurazioni del microfono, questi requisiti si applicano ciascun microfono.

Se le implementazioni del dispositivo dichiarano android.hardware.microphone ma non supportano le sorgenti audio non elaborate, ovvero:

• [C-2-1] DEVE restituire null per AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) , per indicare correttamente la mancanza di supporto.
• I [C-SR-1] sono comunque VIVAMENTE CONSIGLIATI per soddisfare molti dei requisiti per il percorso del segnale per l'origine della registrazione non elaborata.

5.12. Video HDR

Android 13 supporta le tecnologie HDR come descritto in un prossimo documento.

Formato pixel

Se un decodificatore video pubblicizza il supporto per COLOR_FormatYUVP010, allora:

• [C-1-1] DEVE supportare il formato P010 per lettura CPU (ImageReader, MediaImage, ByteBuffer). In Android 13, P010 è rilassato per consentire un passo arbitrario per Y e piani UV.

• [C-1-2] Il buffer di uscita P010 DEVE essere campionato dalla GPU (quando allocati con l'utilizzo di GPU_SAMPLING). Ciò consente la composizione della GPU e la mappatura dei toni da parte delle app.

Se un decodificatore video pubblicizza il supporto per COLOR_Format32bitABGR2101010, questo:

• [C-2-1] DEVE supportare il formato RGBA_1010102 per la superficie di output e leggibile dalla CPU (output ByteBuffer).

Se un codificatore video pubblicizza il supporto di COLOR_FormatYUVP010, questo:

• [C-3-1] DEVE supportare il formato P010 per la superficie di input e la scrittura su CPU Input (ImageWriter, MediaImage, ByteBuffer).

Se un codificatore video pubblicizza il supporto per COLOR_Format32bitABGR2101010, questo:

• [C-4-1] DEVE supportare il formato RGBA_1010102 per la superficie di input e la scrittura con CPU (ImageWriter, ByteBuffer). Nota: conversione tra vari trasferimenti per gli encoder NON sono richieste.

Requisiti per l'acquisizione HDR

Per tutti i codificatori video che supportano i profili HDR, le implementazioni sui dispositivi:

• [C-5-1] NON DEVE presupporre che i metadati HDR siano precisi. Ad esempio, il fotogramma codificato potrebbe avere pixel oltre il livello di luminanza massima, oppure il l'istogramma potrebbe non essere rappresentativo del frame.

• DOVREBBE aggregare i metadati dinamici HDR per generare immagini statiche HDR appropriate metadati per gli stream codificati e dovrebbero eseguirne l'output alla fine di ogni sessione di codifica.

Se le implementazioni del dispositivo supportano l'acquisizione HDR utilizzando le API CamcorderProfile allora:

• [C-6-1] DEVE supportare l'acquisizione HDR anche tramite le API Camera2.

• [C-6-2] DEVE supportare almeno un codificatore video con accelerazione hardware per ciascuna tecnologia HDR supportata.

• [C-6-3] DEVE supportare (almeno) l'acquisizione HLG.

• [C-6-4] DEVE supportare la scrittura dei metadati HDR (se applicabile ai tecnologia) nel file video acquisito. Per AV1, HEVC e DolbyVision Ciò significa includere i metadati nel flusso di bit codificato.

• [C-6-5] DEVE supportare P010 e COLOR_FormatYUVP010.

• [C-6-6] DEVE supportare la mappatura dei toni da HDR a SDR nell'impostazione predefinita decodificatore con accelerazione hardware per il profilo acquisito. In altre parole, Se un dispositivo è in grado di acquisire immagini HEVC HDR10+, il decoder HEVC predefinito DEVE essere in grado per decodificare lo stream acquisito in SDR.

Requisiti per l'editing HDR

Se le implementazioni dei dispositivi includono codificatori video che supportano l'editing HDR: l'utente:

• DEVONO utilizzare una latenza minima per generare i metadati HDR quando non presenti, e DOVREBBE gestire con grazia le situazioni in cui i metadati sono presenti frame e non per altri. Questi metadati DEVONO essere precisi (ad esempio, rappresentano l'effettiva luminanza massima e l'istogramma del fotogramma).

Se l'implementazione nel dispositivo include codec che supportano FEATURE_HdrEditing: quei codec:

• [C-7-1] DEVE supportare almeno un profilo HDR.

• [C-7-2] DEVE supportare FEATURE_HdrEditing per tutti i profili HDR pubblicizzati da quel codec. In altre parole, DEVONO supportare la generazione di metadati HDR quando non presente per tutti i profili HDR supportati che utilizzano i metadati HDR.

• [C-7-3] DEVE supportare i seguenti formati di input del codificatore video che conserva il segnale decodificato HDR:

  • RGBA_1010102 (già nella curva di trasferimento target) per entrambi gli input Surface e ByteBuffer e DEVONO pubblicizzare il supporto per COLOR_Formato32bitABGR2101010.

Se l'implementazione nel dispositivo include codec che supportano FEATURE_HdrEditing, il dispositivo:

• [C-7-4] DEVE pubblicizzare il supporto dell'estensione OpenGL EXT_YUV_target.

6. Compatibilità degli strumenti e delle opzioni per sviluppatori

6.1 Strumenti per sviluppatori

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare gli Strumenti per sviluppatori Android forniti in Android l'SDK.

• Android Debug Bridge (adb)

  • [C-0-2] DEVE supportare adb come documentato nell'SDK Android e nella shell forniti in AOSP, che possono essere usati dagli sviluppatori di app, tra cui dumpsys cmd stats
  • [C-0-11] DEVE supportare il comando shell cmd testharness. Upgrade in corso su dispositivi da una versione precedente di Android senza blocco dati permanente POTREBBE essere esente da C-0-11.
  • [C-0-3] NON DEVE alterare il formato o i contenuti del sistema del dispositivo eventi (batterystats , diskstats, fingerprint, graphicstats, netstats, notifica, procstats) registrati mediante il comando dumpsys.
  • [C-0-10] DEVE registrare, senza omettere, e apportare i seguenti eventi accessibile e disponibile per il comando shell cmd stats e StatsManager Classe API di sistema.
    • StatoattivitàForegroundChanged
    • Rilevata anomalia
    • Report AppBreadcrumb
    • Si è verificato un arresto anomalo dell'applicazione
    • AppStartOccurred
    • LivelloBatteria cambiato
    • Risparmio energeticoModeStateChanged
    • BleScanResultRicevuto
    • BleScanStateChanged
    • Stato di ricaricaModifica
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduleJobStateChanged
    • StatoScreenChanged
    • SyncStateChanged
    • SistemaElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • Si è verificato un allarme sveglia
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] Il daemon adb lato dispositivo DEVE essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile dall'utente per attivare il debug di Android Ponte.
  • [C-0-5] DEVE supportare ADB sicuro. Android include il supporto per ab. Secure adb abilita adb su host autenticati noti.
  • [C-0-6] DEVE fornire un meccanismo che consenta ad adb di essere connesso da un della macchina host. Nello specifico:

  Se le implementazioni dei dispositivi senza una porta USB supportano la modalità periferica:

  • [C-3-1] DEVE implementare adb tramite una rete locale (come Ethernet o Wi-Fi).
  • [C-3-2] DEVE fornire driver per Windows 7, 8 e 10, consentendo agli sviluppatori di connettersi al dispositivo utilizzando il protocollo adb.

  Se le implementazioni del dispositivo supportano le connessioni ADB a un computer host tramite Wi-Fi o Ethernet:

  • [C-4-1] DEVE avere il metodo AdbManager#isAdbWifiSupported() restituisce true.

  Se le implementazioni del dispositivo supportano le connessioni ADB a un computer host tramite Wi-Fi o Ethernet include almeno una videocamera, questi:

  • [C-5-1] DEVE avere il metodo AdbManager#isAdbWifiQrSupported() restituisce true.

• Dalvik Debug Monitor (DDMS)

  • [C-0-7] DEVE supportare tutte le funzionalità DDMS come documentato nell'SDK per Android. Poiché ddms utilizza adb, il supporto per ddms DEVE essere inattivo per impostazione predefinita, DEVE essere supportato ogni volta che l'utente attiva Android Debug Bridge, come illustrato in precedenza.

• SysTrace

  • [C-0-9] DEVE supportare lo strumento Systrace come documentato nell'SDK per Android. Systrace deve essere inattivo per impostazione predefinita e DEVE essere accessibile dall'utente per attivare Systrace.

• Perfetto

  • [C-SR-1] È VIVAMENTE CONSIGLIATO di esporre un /system/bin/perfetto il codice binario all'utente shell a cui cmdline rispetta la documentazione relativa al dispositivo perfetto.
  • [C-SR-2] Il programma binario perfetto è VIVAMENTE CONSIGLIATO di accettare come input di una configurazione protobuf conforme allo schema definito in la documentazione perfetta.
  • [C-SR-3] Il binario perfetto è VIVAMENTE CONSIGLIATO di scrivere come output traccia protobuf conforme allo schema definito in la documentazione perfetta.
  • [C-SR-4] È VIVAMENTE CONSIGLIATO di fornire, tramite il programma binario perfetto, almeno le origini dati descritte nella documentazione perfetta.

• Minore memoria

  • [C-0-12] DEVE scrivere un Atom LMK_KILL_OCCURRED_FIELD_NUMBER nella statistiche sui log quando un'app viene terminata dal Low Memory Killer.

• Modalità test Harness Se le implementazioni del dispositivo supportano il comando shell cmd testharness e eseguono cmd testharness enable, questi:

  • [C-2-1] DEVE restituire true per ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] DEVE implementare la modalità Test Harness come descritto in Documentazione relativa alla modalità di test Harness.

• Informazioni di lavoro delle GPU

  Implementazioni dei dispositivi:

  • [C-0-13] DEVE implementare il comando shell dumpsys gpu --gpuwork per visualizzare i dati di lavoro GPU aggregati restituiti dal kernel power/gpu_work_period tracepoint oppure non visualizzare nessun dato se il tracepoint non è supportato. L'AOSP è frameworks/native/services/gpuservice/gpuwork/.

Se le implementazioni dei dispositivi segnalano il supporto di Vulkan 1.0 o versioni successive tramite la android.hardware.vulkan.version flag funzionalità, che:

• [C-1-1] DEVE fornire un'invito allo sviluppatore dell'app per attivare/disattivare Livelli di debug della GPU.
• [C-1-2] DEVE, quando i livelli di debug della GPU sono abilitati, enumerare i livelli in librerie fornite da strumenti esterni (ovvero non facenti parte della piattaforma o dell'applicazione) presenti nell'elenco delle applicazioni di cui è possibile eseguire il debug directory di base su Supporta vkEnumerateInstancelayerProperties() e vkCreateInstance() metodi dell'API.

6.2. Opzioni sviluppatore

Android include il supporto per gli sviluppatori per configurare l'applicazione le impostazioni relative allo sviluppo.

Le implementazioni dei dispositivi DEVONO fornire un'esperienza coerente le Opzioni sviluppatore:

• [C-0-1] DEVE rispettare le android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo di applicazioni. L'upstream di Android nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avvia Opzioni sviluppatore dopo aver premuto sette (7) volte in Impostazioni > Informazioni sul dispositivo > Voce di menu Numero build.
• [C-0-2] DEVE nascondere le Opzioni sviluppatore per impostazione predefinita.
• [C-0-3] DEVE fornire un meccanismo chiaro che non dia priorità a un'app di terze parti anziché a un'altra per consentire allo Sviluppatore Opzioni. 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 da i documenti relativi all'SDK Android.
• DOVREBBE avere una notifica visiva continua per l'utente quando lo sviluppatore Le opzioni sono attivate e la sicurezza dell'utente è un problema.
• POTREBBE limitare temporaneamente l'accesso al menu Opzioni sviluppatore tramite visivamente nascondendo o disattivando il menu, per evitare distrazioni nei casi in cui la sicurezza dell'utente è preoccupante.

7. Compatibilità hardware

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

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

Se un'API nell'SDK interagisce con un componente hardware che viene dichiarato facoltativo e l'implementazione nei dispositivi non include questo componente:

• [C-0-2] Completa le definizioni della classe (come documentato dall'SDK) per il componente Le API DEVONO comunque essere presentate.
• [C-0-3] I comportamenti dell'API DEVONO essere implementati come autonomi in modo ragionevole moda.
• [C-0-4] I metodi API DEVONO restituire valori nulli ove consentito dall'SDK documentazione.
• [C-0-5] I metodi API DEVONO restituire implementazioni no-op per le classi in cui i valori nulli. non sono consentiti dalla documentazione dell'SDK.
• [C-0-6] I metodi API NON DEVONO generare eccezioni non documentate dall'SDK documentazione.
• [C-0-7] Le implementazioni dei dispositivi DEVONO riportare costantemente l'accuratezza dell'hardware di configurazione tramite getSystemAvailableFeatures() e hasSystemFeature(String) metodi nella android.content.pm.PackageManager per la stessa fingerprint build.

Un tipico esempio di scenario in cui si applicano questi requisiti è la telefonia API: anche su dispositivi diversi dagli smartphone, queste API devono essere implementate in modo ragionevole autonomo.

7.1 Display e grafica

Android include funzionalità che regolano automaticamente gli asset dell'applicazione e l'UI layout appropriati per il dispositivo per garantire che le applicazioni di terze parti funzionare bene su serie di configurazioni hardware. diverse configurazioni e display hardware. Un Il display compatibile con Android è uno schermo che implementa tutte le comportamenti e API descritti in Android Developers - Compatibilità dello schermo panoramica, sezione (7.1) e le relative sottosezioni, nonché qualsiasi ulteriore tipo di dispositivo comportamenti specifici documentati nella sezione 2 del presente documento CDD (CDD). Sui display compatibili con Android dove tutti i dispositivi di terze parti sono compatibili possono essere eseguite, le implementazioni dei dispositivi DEVONO implementare correttamente queste API e i comportamenti, come descritto in dettaglio 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 contrapposti angoli della parte illuminata del display.
• densità dei punti per pollice (dpi). Il numero di pixel inclusi in una linea intervallo orizzontale o verticale di 1", espresso in pixel per pollice (ppi o dpi). Dove dpi sono elencati i valori ppi e dpi, sia i DPI orizzontali che quelli verticali devono rientrare nei valori elencati intervallo.
• proporzioni. Il rapporto tra i pixel della dimensione più lunga e più corta dello schermo. Ad esempio, un display di 480 x 854 pixel 854/480 = 1,779, o approssimativamente "16:9".
• pixel indipendenti dalla densità (dp). La Un unità pixel virtuale normalizzato su uno schermo da 160 dpi densità dello schermo pari a 160. Per una certa densità d e un numero di pixel p, il numero di pixel indipendenti dalla densità dp, è calcolato come: pixel = dps * (densità/160) dp = (160 / d) * p .

7.1.1. Configurazione schermata

7.1.1.1. Dimensioni e forma dello schermo

Il framework dell'interfaccia utente di Android supporta una varietà di layout logici dello schermo e consente alle applicazioni di eseguire query sullo schermo della configurazione corrente dimensioni del layout tramite Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK e Configuration.smallestScreenWidthDp.

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare le dimensioni di layout corrette per il parametro Configuration.screenLayout come definito nella documentazione dell'SDK Android. In particolare, le implementazioni dei dispositivi DEVONO indicare la logica corretta dimensioni dello schermo in pixel indipendenti dalla densità (dp) come indicato di seguito:

  • Dispositivi con Configuration.uiMode impostato come qualsiasi valore diverso da UI_MODE_TYPE_WATCH e segnalazione di una dimensione small per il Configuration.screenLayout, DEVONO avere almeno 426 dp x 320 dp.
  • Dispositivi che segnalano una dimensione normal per Configuration.screenLayout, DEVE avere almeno 480 dp x 320 dp.
  • Dispositivi che segnalano una dimensione large per Configuration.screenLayout, DEVE avere almeno 640 dp x 480 dp.
  • Dispositivi che segnalano una dimensione xlarge per Configuration.screenLayout, DEVE avere almeno 960 dp x 720 dp.

• [C-0-2] DEVE rispettare correttamente le richieste dichiarato supporto delle dimensioni dello schermo tramite <supports-screens> nel file AndroidManifest.xml, come descritto nella documentazione dell'SDK Android.

• POTREBBE avere display compatibili con Android con angoli arrotondati.

Se le implementazioni del dispositivo supportano schermate in grado di UI_MODE_TYPE_NORMAL configurazione delle dimensioni e includono contenuti compatibili con Android utilizza display fisici con angoli arrotondati per il rendering di questi schermi, l'utente:

• [C-1-1] DEVE garantire che almeno uno dei seguenti requisiti viene soddisfatta per ciascuno di questi tipi di visualizzazione:

  • Il raggio degli angoli arrotondati è inferiore o uguale a 38 dp.
  • Quando 1518 dp di 1518 La casella dp è ancorata a ciascun angolo del display logico, almeno uno di ciascun riquadro sia visibile sullo schermo.

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

Per informazioni dettagliate sulla corretta implementazione delle API sidecar o di estensione, consulta alla documentazione pubblica di Window Manager Jetpack.

7.1.1.3. Densità schermo

Il framework della UI di Android definisce un insieme di densità logiche standard per gli sviluppatori di applicazioni come target delle risorse dell'applicazione.

Implementazioni dei dispositivi:

• [C-0-1] Per impostazione predefinita, le implementazioni dei dispositivi DEVE segnalare solo uno dei Le densità del framework Android elencate DisplayMetrics tramite l'API DENSITY_DEVICE_STABLE e questo valore deve essere un valore statico per ogni display fisico. NON DEVONO cambiare in nessun momento; tuttavia, Tuttavia il dispositivo POTREBBE Segnalano una densità arbitraria diversa DisplayMetrics.density in base alle modifiche alla configurazione del display apportate dall'utente (ad ad esempio le dimensioni di visualizzazione) impostate dopo l'avvio iniziale.

Se le implementazioni dei dispositivi forniscono c'è un'invito modificare le dimensioni di visualizzazione del dispositivo,:

• [C-1-1] Le dimensioni del display NON DEVONO essere ridimensionate NON DEVE scalare il display superiore a 1,5 volte la densità nativa della DENSITY_DEVICE_STABLE o produrre una dimensione minima effettiva dello schermo inferiore a 320 dp (equivalente a sw320dp del qualificatore di risorsa), a seconda dell'evento che si verifica per primo.
• [C-1-2] Le dimensioni del display NON DEVONO essere ridimensionate NON DEVE scalare il display inferiore a 0,85 volte la densità nativa di DENSITY_DEVICE_STABLE.
• Per garantire una buona usabilità e dimensioni dei caratteri coerenti, SI CONSIGLIA di utilizzare la seguente scalabilità delle opzioni di display nativo (nel rispetto dei limiti sopra specificati)
  • Piccola: 0,85x
  • Valore predefinito: 1x (scala display nativa)
  • Grande: 1,15x
  • Più grande: 1,3x
  • Il più grande 1,45x

7.1.2. Metriche di visualizzazione

Se le implementazioni del dispositivo includono i display compatibili con Android o l'output video agli schermi di display compatibili con Android, i seguenti:

• [C-1-1] DEVE segnalare i valori corretti per tutti i display compatibili con Android definite nelle metriche API android.util.DisplayMetrics.

Se le implementazioni del dispositivo non includono uno schermo incorporato o un output video, l'utente:

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

7.1.3. Orientamento schermo

Implementazioni dei dispositivi:

• [C-0-1] DEVE indicare gli orientamenti dello schermo supportati (android.hardware.screen.portrait e/o android.hardware.screen.landscape) e DEVE segnalare almeno uno supportato orientamento. Ad esempio, un dispositivo con orientamento orizzontale fisso come un televisore o un laptop, DOVREBBE segnala android.hardware.screen.landscape.
• [C-0-2] DEVE segnalare il valore corretto per lo stato attuale del dispositivo orientamento, ogni volta che viene eseguita una query 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 su schermo verticale o orizzontale orientamento. Ciò significa che il dispositivo deve rispettare la richiesta dell'applicazione relativa a una schermata specifica orientamento.
• [C-1-2] NON DEVE modificare le dimensioni o la densità dello schermo segnalate quando cambi l'orientamento.
• POTREBBE selezionare l'orientamento verticale o orizzontale come impostazione predefinita.

7.1.4. Accelerazione delle schede grafiche 2D e 3D

7.1.4.1 OpenGL ES

Implementazioni dei dispositivi:

• [C-0-1] DEVE identificare correttamente le versioni OpenGL ES supportate (1.1, 2.0, 3.0, 3.1, 3.2) tramite le API gestite (ad esempio tramite GLES10.getString()) e le API native.
• [C-0-2] DEVE includere il supporto per tutte le API gestite corrispondenti e API native per ogni versione OpenGL ES da supportare.

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

• [C-1-1] DEVE supportare sia OpenGL ES 1.1 che 2.0, come incorporati e dettagliati nella documentazione relativa all'SDK per Android.
• [C-SR-1] È VIVAMENTE CONSIGLIATO il supporto di OpenGL ES 3.1.
• DEVE supportare OpenGL ES 3.2.

I test dEQP OpenGL ES sono partizionati in una serie di elenchi di test, ognuno con una data/un numero di versione associato. Si trovano nella struttura di origine Android all'indirizzo external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt. Un dispositivo che supporta OpenGL ES a un livello auto-segnalato indica che può passare il valore dEQP in tutti gli elenchi di test di questo livello e di quelli precedenti.

Se le implementazioni del dispositivo supportano una qualsiasi delle versioni OpenGL ES:

• [C-2-1] DEVE segnalare tramite le API gestite OpenGL ES e le API native altre estensioni OpenGL ES implementate e, al contrario, DEVONO NON segnalare le stringhe di estensioni non supportate.
• [C-2-2] DEVE supportare EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer EGL_ANDROID_get_native_client_buffer EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable e EGL_ANDROID_GLES_layers.
• [C-2-3] DEVE segnalare la versione massima dei test dEQP OpenGL ES supportato tramite il flag delle funzionalità android.software.opengles.deqp.level.
• [C-2-4] DEVE supportare almeno la versione 132383489 (dal 1° marzo 2020) come segnalato nel flag delle funzionalità android.software.opengles.deqp.level.
• [C-2-5] DEVE superare tutti i test dEQP OpenGL ES negli elenchi di test tra le versioni 132383489 e la versione specificata nel android.software.opengles.deqp.level flag funzionalità, per ciascuno supportato Versione OpenGL ES.
• [C-SR-2] È VIVAMENTE CONSIGLIATO di supportare i EGL_KHR_partial_update e Estensioni OES_EGL_image_external.

• DEVE generare report precisi tramite il metodo getString(), qualsiasi texture di compressione supportato, che in genere è specifico del fornitore.

• DOVREBBE supportare EGL_IMG_context_priority e Estensioni EGL_EXT_protected_content.

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

• [C-3-1] DEVE esportare i simboli di funzione corrispondenti per questa versione in oltre ai simboli di funzione OpenGL ES 2.0 nella libreria libGLESv2.so.
• [C-SR-3] CONSIGLIATO VIVAMENTE per il supporto di OES_EGL_image_external_essl3 .

Se le implementazioni dei dispositivi supportano OpenGL ES 3.2:

• [C-4-1] DEVE supportare completamente il pacchetto di estensioni Android OpenGL ES.

Se le implementazioni dei dispositivi supportano il pacchetto di estensioni Android OpenGL ES nei relativi nella loro interezza:

• [C-5-1] DEVE identificare l'assistenza tramite android.hardware.opengles.aep flag funzionalità.

Se le implementazioni del dispositivo espongono il supporto per EGL_KHR_mutable_render_buffer estensione, questi:

• [C-6-1] DEVE supportare anche EGL_ANDROID_front_buffer_auto_refresh .

7.1.4.2 Vulkan

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

Se le implementazioni dei dispositivi supportano OpenGL ES 3.1:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di includere il supporto per Vulkan 1.3.
• [C-4-1] NON DEVE supportare una versione della variante Vulkan (ovvero la variante parte della versione core Vulkan DEVE essere pari a zero).

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

• [C-SR-2] È VIVAMENTE CONSIGLIATO di includere il supporto per Vulkan 1.3.

I test Vulkan dEQP sono partizionati in una serie di elenchi di test, ciascuno con una data/versione associata. Si trovano nella struttura di origine Android all'indirizzo external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt. Un dispositivo che supporta Vulkan a un livello autodichiarato indica che può passare il parametro dEQP in tutti gli elenchi di test di questo livello e di quelli precedenti.

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

• [C-1-1] DEVE segnalare il valore intero corretto con i android.hardware.vulkan.level e android.hardware.vulkan.version i flag delle funzionalità.
• [C-1-2] DEVE enumerare almeno un VkPhysicalDevice per il Vulkan l'API nativa vkEnumeratePhysicalDevices().
• [C-1-3] DEVE implementare completamente Vulkan 1.0 API Vulkan 1.1 per ogni VkPhysicalDevice.
• [C-1-4] DEVE enumerare gli strati, contenuti nelle librerie native denominate come libVkLayer*.so nella directory della libreria nativa del pacchetto dell'applicazione, tramite le API native Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties().
• [C-1-5] NON DEVE enumerare gli strati forniti dalle librerie al di fuori del un pacchetto dell'applicazione o fornire altri modi per tracciare o intercettare API Vulkan, a meno che l'applicazione non abbia l'attributo android:debuggable impostato come true o come metadati com.android.graphics.injectLayers.enable impostata su true .
• [C-1-6] DEVE segnalare tutte le stringhe di estensioni supportate tramite le API native Vulkan e, al contrario, NON DEVONO segnalare le stringhe di estensioni che non supportano correttamente.
• [C-1-7] DEVE supportare VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, e le estensioni VK_KHR_incremental_present.
• [C-1-8] DEVE segnalare la versione massima dei test Vulkan dEQP supportato tramite il flag delle funzionalità android.software.vulkan.deqp.level.
• [C-1-9] DEVE supportare almeno la versione 132317953 (a partire dal 1° marzo 2019) come indicato nel flag della funzionalità android.software.vulkan.deqp.level.
• [C-1-10] DEVE superare tutti i test Vulkan dEQP negli elenchi di test tra la versione 132317953 e la versione specificata nel Flag funzionalità android.software.vulkan.deqp.level.
• [C-1-11] NON DEVE enumerare il supporto per VK_KHR_video_queue, le estensioni VK_KHR_video_decode_queue o VK_KHR_video_encode_queue.
• [C-SR-3] CONSIGLIATO VIVAMENTE per il supporto di VK_KHR_driver_properties e VK_GOOGLE_display_timing.

• [C-1-12] NON DEVE enumerare il supporto per l'estensione VK_KHR_performance_query.

• [C-SR-4] È VIVAMENTE CONSIGLIATO per soddisfare i requisiti specificati da il profilo Android Baseline 2022.

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

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

Se le implementazioni dei dispositivi includono il supporto per Vulkan 1.1 e dichiari uno dei I flag delle funzionalità Vulkan descritti qui , l'utente:

• [C-3-1] DEVE esporre il supporto per il semaforo e l'handle esterni SYNC_FD. e l'estensione VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

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

7.1.4.4 Accelerazione della grafica 2D

Android include un meccanismo che consente alle applicazioni di dichiarare abilitare l'accelerazione hardware per la grafica 2D nei campi Applicazione, Attività, Finestra o livello di vista attraverso l'uso di un tag manifest android:hardwareAccelerated o chiamate API dirette.

Implementazioni dei dispositivi:

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

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

Implementazioni dei dispositivi:

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

7.1.4.5 Display ad ampia gamma

Se le implementazioni dei dispositivi richiedono il supporto di display ad ampia gamma di Configuration.isScreenWideColorGamut() , questi:

• [C-1-1] DEVE avere un display con calibrazione del colore.
• [C-1-2] DEVE avere un display la cui gamma copre la gamma di colori sRGB interamente nello spazio 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 xyY CIE 1931.
• [C-1-4] DEVE supportare OpenGL ES 3.1 o 3.2 e segnalarlo correttamente.
• [C-1-5] DEVE pubblicizzare il supporto di 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 estensioni.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare GL_EXT_sRGB.

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

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

7.1.5. Modalità di compatibilità delle applicazioni legacy

Android specifica una “modalità di compatibilità” in cui il framework opera in un 'normale' modalità equivalente a dimensioni dello schermo (larghezza di 320 dp) per i vantaggi della versione applicazioni non sviluppate per le versioni precedenti di Android antecedenti indipendenza dalle dimensioni degli schermi.

7.1.6. Tecnologia dello schermo

La piattaforma Android include API che consentono alle applicazioni di eseguire il rendering la grafica su un display compatibile con Android. I dispositivi DEVONO supportare tutte queste funzionalità API definite dall'SDK Android, salvo se espressamente consentito in questo documento.

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

• [C-0-1] DEVE essere in grado di eseguire il rendering di grafica a colori a 16 bit.
• DOVREBBE supportare display con grafica a colori a 24 bit.
• [C-0-2] DEVE essere in grado di visualizzare le animazioni.
• [C-0-3] DEVE avere proporzioni pixel (PAR) tra 0,9 e 1,15. In altre parole, le proporzioni dei pixel DEVONO essere quasi quadrate (1,0) con una tolleranza del 10 ~ 15%.

7.1.7. Display secondari

Android include il supporto di display secondari compatibili con Android per l'attivazione funzionalità di condivisione multimediale e API di sviluppo per l'accesso a display esterni.

Se le implementazioni dei dispositivi supportano un display esterno tramite cavo, wireless o una connessione display aggiuntiva incorporata,:

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

7.2. Dispositivi di immissione

Implementazioni dei dispositivi:

• [C-0-1] DEVE includere un meccanismo di input, come un touchscreen o navigazione non touch, per navigare tra gli elementi dell'interfaccia utente.

7.2.1. Tastiera

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

• [C-1-1] DEVE dichiarare lo android.software.input_methods flag funzionalità.
• [C-1-2] DEVE implementare completamente Input Management Framework
• [C-1-3] DEVE avere una tastiera software preinstallata.

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE includere una tastiera hardware che non corrisponde a uno dei formati specificati in android.content.res.Configuration.keyboard (QWERTY o 12 tasti).
• DEVE includere ulteriori implementazioni della tastiera su schermo.
• POTREBBE includere una tastiera hardware.

7.2.2. Navigazione non touch

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

Implementazioni dei dispositivi:

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

Se le implementazioni del dispositivo non dispongono di navigazioni non touch, questi:

• [C-1-1] DEVE fornire un meccanismo di interfaccia utente ragionevole e alternativo per Selezione e modifica del testo, compatibili con i motori di gestione degli input. La l'implementazione open source di Android a monte include un meccanismo di selezione adatta all'uso con dispositivi privi di input di navigazione non touch.

7.2.3. Tasti di navigazione

La sezione Home, Recenti, e Indietro funzioni generalmente fornite tramite un'interazione con un pulsante fisico dedicato o una parte distinta del touchscreen, sono essenziali per Android del paradigma di navigazione e, di conseguenza, le implementazioni dei dispositivi:

• [C-0-1] DEVE fornire un invito all'utente per avviare le applicazioni installate che presentano un'attività con <intent-filter> impostato con ACTION=MAIN e CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER per dispositivo televisivo implementazioni. La funzione Home DEVE essere il meccanismo per questo invito dell'utente.
• DOVREBBE fornire i pulsanti per le funzioni Recenti e Indietro.

Se vengono fornite le funzioni Home, Recenti o Indietro, queste:

• [C-1-1] DEVE essere accessibile con una singola azione (ad es. tocco, doppio clic o gesto) quando una di queste è accessibile.
• [C-1-2] DEVE fornire una chiara indicazione di quale singola azione potrebbe attivare ciascuna funzione. Un'icona visibile impressa sul pulsante che mostra un software nella barra di navigazione dello schermo o che l'utente segue una la procedura demo passo passo durante l'esperienza di configurazione immediata esempi di questa indicazione.

Implementazioni dei dispositivi:

• [C-SR-1] è VIVAMENTE CONSIGLIATO di non fornire il meccanismo di input per Funzione di menu in quanto è stata ritirata a favore della barra delle azioni da Android 4.0.

• [C-SR-2] È VIVAMENTE CONSIGLIATO di fornire tutte le funzioni di navigazione annullabili. "Annullabile" definisce la capacità dell'utente di impedire che funzione di navigazione (ad es. tornare alla schermata Home, tornare indietro e così via) se lo scorrimento non viene rilasciato oltre una certa soglia.

Se le implementazioni dei dispositivi forniscono la funzione Menu, queste:

• [C-2-1] DEVE visualizzare il pulsante di overflow di azione ogni volta che l'azione 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 dell'azione visualizzato selezionando il pulsante extra nella barra delle azioni, ma POTREBBE eseguire il rendering il popup di overflow delle azioni in una posizione modificata sullo schermo quando visualizzato selezionando la funzione Menu.

Se le implementazioni del dispositivo non offrono la funzione Menu, per retrocedere compatibilità, questi:

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

Se le implementazioni dei dispositivi forniscono la funzione di assistenza, l'utente:

• [C-4-1] DEVE rendere la funzione di assistenza accessibile con una singola azione (ad esempio tocco, doppio clic o gesto) quando gli altri tasti di navigazione sono accessibili.
• [C-SR-3] VIVAMENTE CONSIGLIATO di usare la pressione prolungata sulla funzione HOME, poiché dell'interazione designata.

Se le implementazioni del dispositivo utilizzano una diversa porzione dello schermo per visualizzare tasti di navigazione, questi:

• [C-5-1] I tasti di navigazione DEVONO utilizzare una parte distinta dello schermo, non disponibili per le applicazioni e NON DEVE 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 soddisfi i requisiti definiti nella sezione 7.1.1.
• [C-5-3] DEVE rispettare i flag impostati dall'app tramite View.setSystemUiVisibility() API, in modo che questa porzione distinta dello schermo (ovvero la barra di navigazione) sia nascosta correttamente come documentato in l'SDK.

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() DEVE essere utilizzato solo per segnalare l'area di riconoscimento dei gesti della schermata Home.
• [C-6-2] Gesti che iniziano all'interno di un rettangolo di esclusione fornito dall' all'applicazione in primo piano tramite View#setSystemGestureExclusionRects(), ma al di fuori di WindowInsets#getMandatorySystemGestureInsets(), NON DEVE essere intercettato per la funzione di navigazione finché l'esclusione rect è consentito entro il limite massimo di esclusione specificato in documentazione di View#setSystemGestureExclusionRects()
• [C-6-3] DEVE inviare all'app in primo piano un MotionEvent.ACTION_CANCEL una volta che i tocchi iniziano a essere intercettati per un gesto di sistema, Se all'app in primo piano è stata inviata in precedenza un MotionEvent.ACTION_DOWN .
• [C-6-4] DEVE fornire all'utente l'invito a passare a un'immagine navigazione basata su pulsanti (ad esempio in Impostazioni).
• DOVREBBE offrire la funzione Home come scorrimento verso l'alto dal bordo inferiore orientamento corrente dello schermo.
• DOVREBBE offrire la funzione Recenti come scorrimento verso l'alto e pressione prima del rilascio, da nella stessa area del gesto Home.
• Gesti che iniziano tra WindowInsets#getMandatorySystemGestureInsets() NON DEVONO essere interessati dai retti di esclusione forniti in primo piano tramite View#setSystemGestureExclusionRects().

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

• [C-7-1] La funzione di navigazione DEVE essere Indietro e fornita come scorri dai bordi sinistro e destro dell'orientamento corrente dello schermo.
• [C-7-2] Se a sinistra o a sinistra sono disponibili pannelli di sistema con possibilità di scorrimento personalizzati i bordi destri, DEVONO essere posizionati nella parte superiore dello schermo, con un'indicazione visiva chiara e persistente che il trascinamento richiama il citati in precedenza, e quindi non Indietro. Un riquadro di sistema POTREBBE configurato da un utente in modo che venga visualizzato sotto il terzo superiore dello schermo ma il pannello del sistema NON DEVE utilizzare una lunghezza superiore a 1/3 dei bordi.
• [C-7-3] Quando l'app in primo piano ha lo View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT oppure i flag WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE impostati, lo scorrimento dai bordi DEVE comportarsi come implementato in AOSP, documentati nell'SDK.
• [C-7-4] Quando l'app in primo piano ha lo View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT oppure i flag WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE impostati, i riquadri di sistema a scorrimento personalizzati DEVONO essere nascosti finché l'utente non inserisce annulla l'attenuazione delle barre di sistema (ovvero barra di navigazione e di stato) come implementate in AOSP.

Se è disponibile la funzione di navigazione a ritroso e l'utente annulla la visualizzazione gesto, quindi:

• [C-8-1] DEVE essere chiamato OnBackInvokedCallback.onBackCancelled().
• [C-8-2] NON DEVE essere chiamato OnBackInvokedCallback.onBackInvoked().
• [C-8-3] L'evento KEYCODE_BACK NON DEVE essere inviato.

Se viene fornita la funzione di navigazione a ritroso, mentre l'applicazione in primo piano sì NON hai registrato un OnBackInvokedCallback, allora:

• Il sistema DEVE fornire un'animazione per l'applicazione in primo piano che suggerisce che l'utente sta tornando indietro, come fornito in AOSP.

Se le implementazioni del dispositivo forniscono supporto per l'API di sistema setNavBarMode per consenti a qualsiasi app di sistema con autorizzazione android.permission.STATUS_BAR di impostare il barra di navigazione, quindi:

• [C-9-1] DEVE fornire assistenza per le icone adatte ai bambini o basate su pulsanti come indicato nel codice AOSP.

7.2.4. Ingresso touchscreen

Android supporta vari sistemi di input del puntatore, ad esempio: touchscreen, touchpad e dispositivi di input tocco falsi. Implementazioni di dispositivi basati su touchscreen sono associate a un display in modo che l'utente abbia l'impressione manipolare gli elementi sullo schermo. Dato che l'utente tocca direttamente lo schermo, il sistema non richiede inviti aggiuntivi per indicare gli oggetti manipolati.

Implementazioni dei dispositivi:

• DOVREBBE avere un sistema di input del puntatore (simile al mouse o al tocco).
• DEVONO supportare puntatori monitorati in modo completamente indipendente.

Se le implementazioni del dispositivo includono un touchscreen (singolo tocco o migliore) su principale compatibile con Android, questi:

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

Se le implementazioni del dispositivo includono un touchscreen che può monitorare più di un solo tocco su un display principale compatibile con Android, questi:

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

Se le implementazioni dei dispositivi si basano su un dispositivo di input esterno come un mouse o Trackball (ovvero che non tocca direttamente lo schermo) per l'immissione su un compatibile con Android e soddisfare i requisiti di tocco fittizio in sezione 7.2.5, questi:

• [C-3-1] NON DEVE segnalare eventuali flag di funzionalità che iniziano con android.hardware.touchscreen.
• [C-3-2] DEVE segnalare solo android.hardware.faketouch.
• [C-3-3] DEVE segnalare TOUCHSCREEN_NOTOUCH per la Configuration.touchscreen API.

7.2.5. Input tocco fittizio

L'interfaccia touch falso fornisce un sistema di input dell'utente che approssima un sottoinsieme di touchscreen. Ad esempio, un mouse o un telecomando che guida un cursore sullo schermo approssima il tocco, ma richiede all'utente di prima puntare o seleziona lo stato attivo e fai clic. Numerosi dispositivi di input come mouse, trackpad e giroscopio air mouse, gyro-pointer, joystick e trackpad multi-touch possono supportare interazioni tattili. Android include la costante di funzionalità android.hardware.faketouch, che corrisponde a un non-touch ad alta fedeltà un dispositivo di input (basato su puntatore), ad esempio un mouse o un trackpad, che sia in grado di gestire emulare input basati sul tocco (incluso il supporto gesti di base) e indicare che il dispositivo supporta un sottoinsieme emulato di funzionalità touchscreen.

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

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

Se le implementazioni del dispositivo dichiarano il supporto per android.hardware.faketouch, l'utente:

• [C-1-1] DEVE indicare le posizioni assolute dello schermo X e Y della posizione del puntatore e visualizzare un puntatore visivo sullo schermo.
• [C-1-2] DEVE segnalare l'evento touch con il codice di azione che specifica la modifica di stato che si verifica sul puntatore 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, consente agli utenti di emulare il tocco su un oggetto sullo schermo.
• [C-1-4] DEVE supportare i puntatori verso il basso, verso l'alto, verso il basso e poi verso l'alto nella stessa posizione su un oggetto dello schermo, entro una certa soglia di tempo, consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo.
• [C-1-5] DEVE supportare il puntatore verso il basso in un punto qualsiasi dello schermo, puntatore si sposta in qualsiasi altro punto arbitrario sullo schermo, seguito da un puntatore che consente agli utenti di emulare il trascinamento al tocco.
• [C-1-6] DEVE supportare il puntatore verso il basso, quindi consentire agli utenti di spostare rapidamente in un'altra posizione dello schermo e poi punta il puntatore verso l'alto sullo schermo, che consente agli utenti di far scagliare un oggetto sullo schermo.

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

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

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

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

7.2.6. Supporto del controller di gioco

7.2.6.1. Mappature pulsanti

Implementazioni dei dispositivi:

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

Se le implementazioni nei dispositivi incorporano un controller o vengono fornite con un controller separato nella confezione che fornirebbero un mezzo per inserire tutti gli eventi elencati nelle tabelle seguenti, questi:

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

Pulsante	Utilizzo HID2	Pulsante Android
R1	0x09 0x0001	KEYCODE_PULSANTE_A (96)
M1	0x09 0x0002	KEYCODE_PULSANTE_B (97)
X1	0x09 0x0004	KEYCODE_PULSANTE_X (99)
A1	0x09 0x0005	KEYCODE_PULSANTE_Y (100)
D-pad in alto1 D-pad in basso1	0x01 0x00393	AXIS_HAT_Y4
D-pad sx1 D-pad destro1	0x01 0x00393	AXIS_HAT_X4
Pulsante sulla spalla sinistra1	0x09 0x0007	KEYCODE_PULSANTE_L1 (102)
Pulsante sulla spalla destra1	0x09 0x0008	KEYCODE_PULSANTE_R1 (103)
Clic sulla levetta sinistra1	0x09 0x000E	KEYCODE_button_THUMBL (106)
Clic sulla levetta destra1	0x09 0x000F	KEYCODE_Button_THUMBR (107)
Indietro1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Gli utilizzi HID sopra indicati devono essere dichiarati all'interno di un Gioco pad CA (0x01 0x0005).

3 Questo utilizzo deve avere un minimo logico di 0, Massimo logico di 7, un minimo fisico di 0, un massimo fisico di 315, in gradi e con dimensioni del report pari a 4. Il valore logico è definito come rotazione in senso orario allontanandolo dall'asse verticale; ad esempio, un valore logico 0 rappresenta l'assenza di rotazione e la pressione del pulsante Su, mentre un valore logico di 1 rappresenta una rotazione di 45 gradi ed entrambi i tasti Freccia su e Sinistra premuto.

4 MotionEvent

Controlli analogici1	Utilizzo HID	Pulsante Android
Trigger sinistro	0x02 0x00C5	AXIS_LTRIGGER
Grilletto destro	0x02 0x00C4	AXIS_RTRIGGER
Joystick sinistro	0x01 0x0030 0x01 0x0031	AXIS_X ASSE_Y
Joystick destro	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Telecomando

Consulta la Sezione 2.3.1 per i requisiti specifici del dispositivo.

7.3. Sensori

Se le implementazioni dei dispositivi includono un particolare tipo di sensore con un l'API corrispondente per sviluppatori di terze parti, l'implementazione DEVONO implementare l'API come descritto nella documentazione relativa all'SDK Android e la documentazione relativa ai sensori open source di Android.

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare con precisione la presenza o l'assenza di sensori in base alle android.content.pm.PackageManager .
• [C-0-2] DEVE restituire un elenco accurato dei sensori supportati tramite SensorManager.getSensorList() e metodi simili.
• [C-0-3] DEVE comportarsi in modo ragionevole per tutte le altre API dei sensori (ad esempio, restituendo true o false a seconda dei casi quando le applicazioni tentano di registrare listener, non chiama i listener dei sensori quando i sensori corrispondenti non sono presente; e così via).

Se le implementazioni dei dispositivi includono un particolare tipo di sensore con un l'API corrispondente per sviluppatori di terze parti, questi:

• [C-1-1] DEVE segnalare tutte le misurazioni del sensore utilizzando i valori del Sistema internazionale di unità (metrica) pertinenti per ogni tipo di sensore 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 per il caso di uno stream del sensore con un la latenza massima richiesta di 0 ms quando il processore dell'applicazione è attivo. Questo ritardo non include eventuali ritardi dei filtri.
• [C-1-3] DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time del sensore da attivare. Per questo campione è accettabile hanno un'accuratezza pari a 0.
• [C-1-4] Per qualsiasi API indicata nella documentazione relativa all'SDK per Android come sensore continuo, le implementazioni dei dispositivi DEVONO fornire continuamente i campioni periodici di dati che DEVONO avere un tremolio inferiore al 3%, in cui il tremolio è definito come la deviazione standard della differenza valori di timestamp segnalati tra eventi consecutivi.
• [C-1-5] DEVE garantire che lo stream di eventi del sensore NON DEVE impedire alla CPU del dispositivo di entrare in stato di sospensione o di riattivarsi lo stato di sospensione.
• [C-1-6] DEVE segnalare l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta l'ora in cui si è verificato l'evento e la sincronizzazione con Orologio SystemClock.elapsedRealtimeNano().
• [C-SR-1] È VIVAMENTE CONSIGLIATO di avere un errore di sincronizzazione del timestamp inferiore a 100 millisecondi e DEVE avere un errore di sincronizzazione del timestamp inferiore a 1 millisecondo.
• Quando sono attivati più sensori, il consumo di corrente NON DEVE superare la somma del consumo di corrente riportato dal singolo sensore.

L'elenco riportato sopra non è esaustivo. il comportamento documentato dell'SDK per Android e la documentazione open source di Android sensori è da prendere in considerazione autorevole.

Se le implementazioni dei dispositivi includono un particolare tipo di sensore con un l'API corrispondente per sviluppatori di terze parti, questi:

• [C-1-6] DEVE impostare una risoluzione diversa da zero per tutti i sensori e indicare il valore tramite Sensor.getResolution() API.

Alcuni tipi di sensori sono composti, ovvero possono essere ricavati dai dati forniti da uno o più sensori. Alcuni esempi sono il sensore di orientamento e sensore di accelerazione lineare).

Implementazioni dei dispositivi:

• DOVREBBE implementare questi tipi di sensori, quando includere i prerequisiti dei sensori fisici, come descritto nei tipi di sensori.

Se le implementazioni dei dispositivi includono un sensore composito:

• [C-2-1] DEVE implementare il sensore come descritto nella documentazione documentazione sui sensori composti.

Se le implementazioni dei dispositivi includono un particolare tipo di sensore con un l'API corrispondente per sviluppatori di terze parti e il sensore ne segnala solo una , le implementazioni dei dispositivi:

• [C-3-1] DEVE impostare la risoluzione su 1 per il sensore e segnalare il valore tramite Sensor.getResolution() API.

Se le implementazioni dei dispositivi includono un particolare tipo di sensore che supporta Informazioni aggiuntive sul sensore#TYPE_VEC3_CALIBRATION e il sensore è esposto a sviluppatori di terze parti, questi:

• [C-4-1] NON DEVE includere alcuna calibrazione fissa definita di fabbrica nei dati forniti.

Se le implementazioni dei dispositivi includono una combinazione di accelerometro a 3 assi, Sensore giroscopico a 3 assi o sensore magnetometro:

• [C-SR-2] VIVAMENTE CONSIGLIATO per garantire l'accelerometro, il giroscopio e magnetometro hanno una posizione relativa fissa, in modo che, se il dispositivo viene trasformabili (ad es. pieghevoli), gli assi dei sensori rimangono allineati e coerenti con il sistema di coordinate dei sensori su tutti i dispositivi possibili degli stati di trasformazione.

7.3.1. Accelerometro

Implementazioni dei dispositivi:

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

Se le implementazioni dei dispositivi includono un accelerometro, questi:

• [C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
• [C-1-3] DEVE rispettare le Sistema di coordinate dei sensori Android come descritto in dettaglio nelle API Android.
• [C-1-4] DEVE essere in grado di misurare dalla caduta libera fino a quattro volte gravità(4 g) o più su qualsiasi asse.
• [C-1-5] DEVE avere una risoluzione di almeno 12 bit.
• [C-1-6] DEVE avere una deviazione standard non superiore a 0,05 m/s^, dove la deviazione standard deve essere calcolata per asse sui campioni raccolti in un periodo di almeno 3 secondi con la frequenza di campionamento più elevata.
• DEVI segnalare eventi fino ad almeno 200 Hz.
• DEVE avere una risoluzione di almeno 16 bit.
• DEVE essere calibrata durante l'uso se le caratteristiche cambiano nel il ciclo di vita e compensato, nonché preservare i parametri di compensazione tra un riavvio e l'altro.
• DEVONO essere compensati in base alla temperatura.

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

• [C-2-1] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER.
• [C-SR-4] È VIVAMENTE CONSIGLIATO di implementare TYPE_SIGNIFICANT_MOTION sensore composito.
• [C-SR-5] È VIVAMENTE CONSIGLIATO di implementare e segnalare Sensore TYPE_ACCELEROMETER_UNCALIBRATED. I dispositivi Android sono VIVAMENTE CONSIGLIATO di soddisfare questo requisito per poter eseguire l'upgrade della futura release della piattaforma, per cui potrebbe diventare OBBLIGATORIO.
• DOVREBBE implementare TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR TYPE_STEP_COUNTER sensori compositi come descritto nel documento relativo all'SDK Android.

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

• [C-3-1] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER_LIMITED_AXES.
• [C-SR-6] È AVVERTENZA_CONSIGLIATO per l'implementazione e la segnalazione Sensore TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Se le implementazioni del dispositivo includono un accelerometro a 3 assi e uno dei TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR Sono stati implementati TYPE_STEP_COUNTER sensori compositi:

• [C-4-1] La somma dei loro il consumo energetico DEVE essere sempre inferiore a 4 mW.
• DOVREBBE essere al di sotto di 2 mW e 0,5 mW quando il dispositivo è in modalità dinamica in una condizione statica.

Se le implementazioni del dispositivo includono un accelerometro a 3 assi e un sensore giroscopio a 3 assi, l'utente:

• [C-5-1] DEVE implementare TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION sensori compositi.
• [C-SR-7] È VIVAMENTE CONSIGLIATO di implementare le 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-6-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

7.3.2. Magnetometro

Implementazioni dei dispositivi:

• [C-SR-1] Si consiglia vivamente di includere un magnetometro a 3 assi (compasso).

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

• [C-1-1] DEVE implementare il sensore TYPE_MAGNETIC_FIELD.
• [C-1-2] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 10 Hz e DEVONO segnalare eventi fino ad almeno 50 Hz.
• [C-1-3] DEVE essere conforme al sistema di coordinate dei sensori Android come descritto in dettaglio API Android.
• [C-1-4] DEVE essere in grado di misurare tra -900 μT e +900 μT su ciascun prima della saturazione.
• [C-1-5] DEVE avere un valore di offset con ferro duro inferiore a 700 μT e DOVREBBE inferiore a 200 μT, posizionando il magnetometro lontano da campi magnetici dinamici (indotti dalla corrente) e statici (indotti da magneti).
• [C-1-6] DEVE avere una risoluzione uguale o più densa di 0,6 μT.
• [C-1-7] DEVE supportare la calibrazione online e la compensazione del ferro duro il bias e conservare i parametri di compensazione tra i riavvii del dispositivo.
• [C-1-8] DEVE avere applicato la compensazione del ferro morbido—la calibrazione può essere durante l'uso o la produzione del dispositivo.
• [C-1-9] DEVE avere una deviazione standard, calcolata per asse su campioni raccolti in un periodo di almeno 3 secondi con il campionamento più rapido non superiore a 1, 5 μT; DEVE avere una deviazione standard non superiore a 0,5 μT.
• [C-1-10] DEVE implementare il parametro TYPE_MAGNETIC_FIELD_UNCALIBRATED sensore.

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi, un accelerometro e un sensore giroscopico a 3 assi, questi:

• [C-2-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

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

• POTREBBE implementare il sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi, un accelerometro e Sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR, questi:

• [C-3-1] DEVE consumare meno di 10 mW.
• DOVREBBE consumare meno di 3 mW quando il sensore è registrato per la modalità batch a 10 Hz.

7.3.3. GPS

Implementazioni dei dispositivi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di includere un ricevitore GPS/GNSS.

Se le implementazioni del dispositivo includono un ricevitore GPS/GNSS e segnala la funzionalità alle applicazioni tramite il flag delle funzionalità android.hardware.location.gps, questi:

• [C-1-1] DEVE supportare gli output di localizzazione a una frequenza 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 (indicatori forti, multipath trascurabile, HDOP < 2) entro 10 secondi (rapido alla prima correzione), quando la connessione a una velocità dati pari a 0,5 Mbps o superiore è di 0,5 Mbps a internet. Questo requisito viene generalmente soddisfatto tramite l'uso di forma di tecnica GPS/GNSS assistito o prevista per ridurre al minimo il tempo di blocco GPS/GNSS (i dati di assistenza includono ora di riferimento, posizione di riferimento ed efemerie/orologio satellite).
  • [C-1-6] Dopo aver effettuato questo calcolo della posizione, il dispositivo le implementazioni DEVONO determinarne la posizione, in cielo aperto, all'interno 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 senza connessione dati e/o dopo un ciclo di spegnimento e riaccensione.

• In condizioni di cielo aperto, dopo aver determinato la posizione, se il veicolo è fermo o che si sposta con un'accelerazione inferiore a 1 metro al secondo quadrato:

  • [C-1-3] DEVE essere in grado di determinare la posizione entro 20 metri e la velocità entro 0,5 metri al secondo, almeno il 95% delle volte.
  • [C-1-4] DEVE monitorare e segnalare contemporaneamente tramite GnssStatus.Callback almeno 8 satelliti da una costellazione.
  • DOVREBBE essere in grado di tracciare contemporaneamente almeno 24 satelliti, da più costellazioni (ad es. GPS + almeno una di Glonass, Beidou, Galileo).

• [C-SR-2] È VIVAMENTE CONSIGLIATO di continuare a fornire i normali dati GPS/GNSS la posizione degli output tramite le API GNSS Location Provider durante una chiamata di emergenza chiamata.

• [C-SR-3] È VIVAMENTE CONSIGLIATO di registrare le misurazioni GNSS di tutti costellazioni monitorate (come riportato nei messaggi GnssStatus), ad eccezione delle SBAS.

• [C-SR-4] È VIVAMENTE CONSIGLIATO di segnalare AGC e frequenza del GNSS misurazione.

• [C-SR-5] È VIVAMENTE CONSIGLIATO di riportare tutte le stime di accuratezza (incluse Orientamento, Velocità e Verticale) come parte di ogni posizione GPS/GNSS.

• [C-SR-6] È VIVAMENTE CONSIGLIATO di registrare le misurazioni GNSS, non appena vengono trovate, anche se non è ancora stata rilevata una posizione calcolata da GPS/GNSS segnalato.

• [C-SR-7] È VIVAMENTE CONSIGLIATO di segnalare gli pseudorange e tariffe di pseudointervallo, ovvero, in condizioni di cielo aperto dopo aver determinato la posizione, se il veicolo è fermo o si muove con meno di 0,2 m al secondo quadrato dell'accelerazione, sono sufficienti per calcolare la posizione entro 20 metri e la velocità entro 0,2 metri al secondo, almeno il 95% delle volte.

7.3.4. Giroscopio

Implementazioni dei dispositivi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di includere un sensore giroscopico.

Se le implementazioni dei dispositivi includono un giroscopio, questi:

• [C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
• [C-1-4] DEVE avere una risoluzione di almeno 12 bit.
• [C-1-5] DEVE essere compensato in temperatura.
• [C-1-6] DEVE essere calibrato e compensato durante l'uso e preservare il dei parametri di compensazione tra i riavvii dei dispositivi.
• [C-1-7] DEVE avere una varianza non superiore a 1e-7 rad^2 / s^2 per Hz (varianza per Hz o rad^2 / s). La varianza può variare con frequenza di campionamento, ma DEVE essere vincolato da questo valore. In altre parole, se Misurare la varianza del giroscopio con una frequenza di campionamento di 1 Hz, non DOVREBBE essere maggiore rispetto a 1e-7 rad^2/s^2.
• [C-SR-2] L’errore di calibrazione è VIVAMENTE CONSIGLIATO essere inferiore a 0,01 rad/s quando il dispositivo è fermo a temperatura ambiente.
• [C-SR-3] È VIVAMENTE CONSIGLIATO avere una risoluzione di almeno 16 bit.
• DEVI segnalare eventi fino ad almeno 200 Hz.

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

• [C-2-1] DEVE implementare il sensore TYPE_GYROSCOPE.
• [C-SR-4] È vivamente consigliata l'implementazione di TYPE_GYROSCOPE_UNCALIBRATED sensore.

Se le implementazioni del dispositivo includono un giroscopio con meno di 3 assi:

• [C-3-1] DEVE implementare e segnalare il sensore TYPE_GYROSCOPE_LIMITED_AXES.
• [C-SR-5] È FORTEMENTE_CONSIGLIATO l'implementazione e la segnalazione Sensore TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Se le implementazioni del dispositivo includono un giroscopio a 3 assi, un sensore dell'accelerometro e un sensore magnetometro,

• [C-4-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

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

• [C-5-1] DEVE implementare TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION sensori compositi.
• [C-SR-6] È VIVAMENTE CONSIGLIATO di implementare le TYPE_GAME_ROTATION_VECTOR sensore composito.

7.3.5. Barometro

Implementazioni dei dispositivi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di includere un barometro (la pressione dell'aria sensore).

Se le implementazioni dei dispositivi includono un barometro, questi:

• [C-1-1] DEVE implementare e segnalare il sensore TYPE_PRESSURE.
• [C-1-2] DEVE essere in grado di inviare eventi a 5 Hz o superiore.
• [C-1-3] DEVE essere compensato in temperatura.
• [C-SR-2] VIVAMENTE CONSIGLIATA di poter riportare le misurazioni di pressione nelle da 300 hPa a 1100 hPa.
• DEVE avere una precisione assoluta di 1 hPa.
• DOVREBBE avere una precisione relativa di 0,12hPa nell'intervallo di 20hPa. (equivalente a una precisione di ~1 m su un cambiamento di ~ 200 m sul livello del mare).

7.3.6. Termometro

Se le implementazioni del dispositivo includono un termometro ambientale (sensore di temperatura), l'utente:

• [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) dal punto in cui l'utente interagisce con il in gradi Celsius.

Se le implementazioni dei dispositivi includono un sensore del termometro che misura una temperatura diversa dalla temperatura ambiente, come la temperatura della CPU, questi:

• [C-2-1] NON DEVE definire SENSOR_TYPE_AMBIENT_TEMPERATURE per il sensore di temperatura.

Se le implementazioni del dispositivo includono un sensore per il monitoraggio della temperatura cutanea, allora:

• [C-SR-1] È VIVAMENTE CONSIGLIATO per supportare i PowerManager.getThermalHeadroom tramite Google Cloud CLI o tramite l'API Compute Engine.

7.3.7. Fotometro

• Le implementazioni dei dispositivi POTREBBERO includere un fotometro (sensore della luce ambientale).

7.3.8. Sensore di prossimità

• Le implementazioni dei dispositivi POTREBBERO includere un sensore di prossimità.

Se le implementazioni dei dispositivi includono un sensore di prossimità e riportano solo lettura binaria "vicino" o "lontano", questi:

• [C-1-1] DEVE misurare la vicinanza di un oggetto nella stessa direzione del schermo. Vale a dire che il sensore di prossimità DEVE essere orientato per rilevare oggetti vicino allo schermo, in quanto lo scopo principale di questo tipo di sensore è rilevare uno smartphone in uso da parte dell'utente. Se le implementazioni dei dispositivi includono un sensore di prossimità con qualsiasi altro orientamento, NON DEVE essere accessibile attraverso questa API.
• [C-1-2] DEVE avere una precisione di almeno 1 bit.
• [C-1-3] DEVE usare 0 centimetri come lettura più vicina e 5 centimetri come valore lettura approfondita.
• [C-1-4] DEVE segnalare un intervallo e una risoluzione massimi pari a 5.

7.3.9. Sensori ad alta affidabilità

Se le implementazioni dei dispositivi includono un insieme di sensori di qualità superiore, come definito in questa sezione e li rende disponibili ad app di terze parti, devono:

• [C-1-1] DEVE identificare la funzionalità tramite Flag funzionalità android.hardware.sensor.hifi_sensors.

Se le implementazioni dei dispositivi dichiarano android.hardware.sensor.hifi_sensors, l'utente:

• [C-2-1] DEVE avere un sensore TYPE_ACCELEROMETER che:

  • DEVE avere un intervallo di misurazione compreso tra almeno -8 g e +8 g e VIVAMENTE CONSIGLIATO di impostare un intervallo di misurazione compreso tra -16 g e +16g.
  • DEVE avere una risoluzione di misurazione di almeno 2048 LSB/g.
  • DEVE avere una frequenza di misurazione minima di 12,5 Hz o inferiore.
  • DEVONO 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 riattivazione di questo sensore con un buffering capacità di almeno 3000 eventi del sensore.
  • DEVE avere un consumo energetico per i batch non inferiore a 3 mW.
  • [C-SR-1] È VIVAMENTE CONSIGLIATO avere una larghezza di banda di misurazione di 3dB pari a almeno l'80% della frequenza di Nyquist e dello spettro del rumore bianco. e larghezza di banda.
  • DEVONO avere una camminata casuale di accelerazione inferiore a 30 μg √Hz testata temperatura ambiente.
  • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 1 mg/°C.
  • DEVE avere una non linearità della linea di best-fit pari a ≤ 0,5%, e una variazione di sensibilità rispetto alla temperatura di ≤ 0,03%/C°.
  • DOVREBBE avere una sensibilità tra gli assi trasversali di < 2,5 % e variazione del sensibilità asse trasversale < 0,2% nell'intervallo di temperatura di funzionamento del dispositivo.

• [C-2-2] DEVE avere un elemento TYPE_ACCELEROMETER_UNCALIBRATED con lo stesso requisiti di qualità come 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.
  • DEVONO 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-2] È VIVAMENTE CONSIGLIATO avere una larghezza di banda di misurazione di 3dB pari a almeno l'80% della frequenza di Nyquist e dello spettro del rumore bianco. e larghezza di banda.
  • DEVE avere una frequenza di camminata casuale inferiore a 0,001 °/s √Hz testata in camera la temperatura dell'acqua.
  • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 0,05 °/ s / °C.
  • DEVE avere una variazione di sensibilità rispetto alla temperatura ≤ 0,02% / °C.
  • DEVE avere una non linearità della linea di best-fit pari a ≤ 0,2%.
  • DEVE avere una densità del rumore ≤ 0,007 °/s/√Hz.
  • DEVE avere un errore di calibrazione inferiore a 0,002 rad/s in 10 ~ 40 °C con dispositivo fermo.
  • DEVE avere una sensibilità g inferiore a 0,1°/s/g.
  • DOVREBBE avere una sensibilità tra gli assi trasversali di < 4,0 % e sensibilità trasversale variante < 0,3% nell'intervallo di temperatura di funzionamento del dispositivo.

• [C-2-4] DEVE avere un elemento TYPE_GYROSCOPE_UNCALIBRATED della stessa qualità requisiti come TYPE_GYROSCOPE.

• [C-2-5] DEVE avere un sensore TYPE_GEOMAGNETIC_FIELD che:

  • DEVE avere un intervallo di misurazione compreso tra almeno -900 e +900 μT.
  • DEVE avere una risoluzione di misurazione di almeno 5 LSB/uT.
  • DEVE avere una frequenza di misurazione minima di 5 Hz o inferiore.
  • DEVE avere una frequenza di misurazione massima di 50 Hz o superiore.
  • DEVE avere un rumore di misurazione non superiore a 0,5 uT.

• [C-2-6] DEVE avere un dispositivo TYPE_MAGNETIC_FIELD_UNCALIBRATED della stessa qualità requisiti come TYPE_GEOMAGNETIC_FIELD e inoltre:

  • DEVE implementare una forma non riattivazione di questo sensore con un buffering capacità di almeno 600 eventi del sensore.
  • [C-SR-3] È VIVAMENTE CONSIGLIATO avere uno spettro di rumore bianco da 1 Hz a almeno 10 Hz quando la frequenza del report è di 50 Hz o superiore.

• [C-2-7] DEVE avere un sensore TYPE_PRESSURE che:

  • DEVE avere un intervallo di misurazione compreso tra almeno 300 e 1100 hPa.
  • DEVE avere una risoluzione di misurazione di almeno 80 LSB/hPa.
  • DEVE avere una frequenza di misurazione minima di 1 Hz o inferiore.
  • DEVE avere una frequenza di misurazione massima di 10 Hz o superiore.
  • DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz.
  • DEVE implementare una forma non riattivazione di questo sensore con un buffering capacità di almeno 300 eventi del sensore.
  • DEVE avere un consumo energetico per i batch non inferiore a 2 mW.

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

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

  • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo statico e 1,5 mW quando il dispositivo è in movimento.

• [C-2-10] DEVE avere un sensore TYPE_STEP_DETECTOR che:

  • DEVE implementare una forma non riattivazione di questo sensore con un buffering capacità di almeno 100 eventi del sensore.
  • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo statico e 1,5 mW quando il dispositivo è in movimento.
  • DEVE avere un consumo energetico per i batch non inferiore a 4 mW.

• [C-2-11] DEVE avere un sensore TYPE_STEP_COUNTER che:

  • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo statico e 1,5 mW quando il dispositivo è in movimento.

• [C-2-12] DEVE avere un sensore TILT_DETECTOR che:

  • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo statico e 1,5 mW quando il dispositivo è in movimento.

• [C-2-13] Il timestamp dello stesso evento fisico segnalato L'accelerometro, il giroscopio e il magnetometro DEVONO essere entro 2, 5 millisecondi l'uno dall'altro. Il timestamp dello stesso evento fisico segnalato da l'accelerometro e il giroscopio DEVONO essere entro 0,25 millisecondi da e l'altro.

• [C-2-14] DEVE avere contemporaneamente i timestamp degli eventi del sensore giroscopio come sottosistema della fotocamera ed entro 1 millisecondi dall'errore.

• [C-2-15] DEVE consegnare i campioni alle applicazioni entro 5 millisecondi da il tempo in cui i dati sono disponibili su uno qualsiasi dei sensori fisici sopra indicati all'applicazione.

• [C-2-16] NON DEVE avere un consumo energetico superiore a 0,5 mW con dispositivo statico e 2,0 mW quando il dispositivo è in movimento quando è attiva una qualsiasi combinazione dei seguenti sensori:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] POTREBBE avere un sensore TYPE_PROXIMITY, ma se presente DEVE avere con una capacità di buffer minima di 100 eventi del sensore.

Tieni presente che tutti i requisiti di consumo energetico di questa sezione non includono il consumo massimo da parte del processore di applicazione. Comprende il potere tracciata dall'intera catena del sensore: il sensore, eventuali circuiti di supporto, sistema di elaborazione dei sensori dedicato, ecc.

Se le implementazioni dei dispositivi includono il supporto diretto dei sensori, questi:

• [C-3-1] DEVE dichiarare correttamente il supporto dei tipi di canali diretti segnala il livello delle tariffe tramite la isDirectChannelTypeSupported e getHighestDirectReportRateLevel tramite Google Cloud CLI o tramite l'API Compute Engine.
• [C-3-2] DEVE supportare almeno uno dei due tipi di canali diretti dei sensori per tutti i sensori che dichiarano il supporto per il canale diretto dei sensori.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DOVREBBE supportare la segnalazione degli eventi tramite il canale diretto dei sensori per i (variante non 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 Documentazione relativa alla misurazione della sicurezza biometrica.

Se le implementazioni dei dispositivi includono una schermata di blocco sicura:

• DEVE includere un sensore biometrico

I sensori biometrici possono essere classificati come Classe 3 (in precedenza Strong), Classe 2 (in precedenza Debole) o Classe 1 (in precedenza Comodità) sulla base dei tassi di accettazione di spoofing e impostori e sulla sicurezza una pipeline biometrica. Questa classificazione determina le funzionalità Il sensore biometrico deve interfacciarsi con la piattaforma e con terze parti diverse applicazioni. I sensori devono soddisfare i requisiti aggiuntivi descritti di seguito se vogliono essere classificate come Classe 1, Classe 2 o Classe 3. Sia la biometria di Classe 2 che quella di Classe 3 offrono funzionalità aggiuntive, descritti di seguito.

Se le implementazioni dei dispositivi mettono a disposizione di terze parti un sensore biometrico tramite android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, l'utente:

• [C-4-1] DEVE soddisfare i requisiti per i sistemi biometrici 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 sezione Authenticators (Autenticazione) e le relative combinazioni. Al contrario, NON DEVE rispettare o riconoscere le costanti intere trasmesse al canAuthenticate(int) e setAllowedAuthenticators(int) metodi diversi da quelli documentati come costanti pubbliche Autenticazione e le relative combinazioni.
• [C-4-3] DEVE implementare ACTION_BIOMETRIC_ENROLL un'azione sui dispositivi con biometria di Classe 3 o Classe 2. Questa azione DEVE presentare solo i punti di ingresso per registrarsi alla Classe 3 o biometria di Classe 2.

Se le implementazioni dei dispositivi supportano la biometria passiva, questi:

• [C-5-1] DEVE richiedere un passaggio di conferma aggiuntivo per impostazione predefinita (ad es. la pressione di un pulsante).
• [C-SR-1] È VIVAMENTE CONSIGLIATO di avere un'impostazione che consenta agli utenti di: sostituiscono la preferenza relativa all'applicazione e richiedono sempre passaggio di conferma.
• [C-SR-2] È VIVAMENTE CONSIGLIATO di garantire l'azione di conferma tale da impedire lo spoofing del sistema operativo o del kernel. Ad esempio, ciò significa che l'azione di conferma basata su un pulsante fisico viene instradato tramite un pin di input/output generico (GPIO) un elemento sicuro (SE) che non può essere guidato da altri mezzi che non della pressione del pulsante fisico.
• [C-5-2] DEVE implementare inoltre un flusso di autenticazione implicita (senza passaggio di conferma) corrispondente a setConfirmationRequired(boolean), quali applicazioni possono impostare per l'utilizzo per i flussi di accesso.

Se le implementazioni dei dispositivi hanno più sensori biometrici, questi:

• [C-SR-3] È VIVAMENTE CONSIGLIATO di richiedere la conferma di un solo dato biometrico per autenticazione (ad esempio, se sono disponibili sia i sensori dell'impronta che i sensori del volto) sul dispositivo, onAuthenticationSucceeded devono essere inviati dopo che una di queste è stata confermata).

Affinché le implementazioni dei dispositivi consentano l'accesso alle chiavi dell'archivio chiavi di terze parti, questi:

• [C-6-1] DEVE soddisfare i requisiti per la Classe 3 definiti nella presente di seguito.
• [C-6-2] DEVE presentare solo la biometria di Classe 3 quando l'autenticazione richiede BIOMETRIC_strong, o l'autenticazione viene richiamata con un CryptoObject.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 1 (in precedenza Convenience):

• [C-1-1] DEVE avere un tasso di accettazione falsa inferiore allo 0,002%.
• [C-1-2] DEVE comunicare che questa modalità potrebbe essere meno sicura di un PIN sicuro. pattern o password ed elenca chiaramente i rischi che comporta l'attivazione, se i tassi di accettazione di spoofing e impostori sono superiori al 7%, secondo quanto Protocolli del test di biometria di Android.
• [C-1-9] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) dopo non più di venti prove false e non meno di novanta secondi di backoff per la verifica biometrica, una prova falsa è quella con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a un dato biometrico registrato.
• [C-SR-4] È VIVAMENTE CONSIGLIATO di abbassare il numero totale di false prove per la verifica biometrica specificata in [C-1-9] se lo spoofing e l'impostatore i tassi di accettazione sono superiori al 7%, come misurato dalla biometria di Android di test dei protocolli.
• [C-1-3] DEVE limitare la frequenza dei tentativi di verifica biometrica, laddove una prova falsa è quella con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrispondono ai dati biometrici registrati.
• [C-SR-5] È VIVAMENTE CONSIGLIATO di limitare i tentativi di frequenza per almeno 30 secondi dopo cinque false prove per la verifica biometrica per il numero massimo di false prove per [C-1-9], dove una prova falsa è una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a biometrico registrato.
• [C-SR-6] È VIVAMENTE CONSIGLIATO di avere tutte le logiche di limitazione della frequenza in TEE.

• [C-1-10] DEVE disabilitare la biometria una volta che il backoff dell'autenticazione primaria è attivato per la prima volta come descritto in [C-0-2] della sezione 9.11.

• [C-1-11] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 30%, con (1) un tasso di accettazione di spoofing e impostore per la presentazione di livello A strumenti di attacco (PAI) non superiori al 30% e (2) una parodia e il tasso di accettazione di impostori delle specie PAI di livello B non supera il 40%, misurate dai protocolli Android Biometrics Test Protocol.

• [C-1-4] DEVE impedire l'aggiunta di nuovi dati biometrici senza prima stabilire un una catena di fiducia chiedendo all'utente di confermare l'esistenza o aggiungere un nuovo dispositivo la credenziale (PIN/sequenza/password) protetta da TEE; l'Android Open L'implementazione del progetto di origine fornisce il meccanismo nel framework per farlo Ecco.

• [C-1-5] DEVE rimuovere completamente tutti i dati biometrici identificabili di un utente Quando l'account dell'utente viene rimosso (anche tramite un ripristino dei dati di fabbrica).

• [C-1-6] DEVE rispettare la segnalazione individuale relativa ai dati biometrici (ad esempio 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) ogni 24 ore o meno. Nota: l'upgrade dei dispositivi con Android 9 o versioni precedenti DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) una volta ogni 72 ore o meno.

• [C-1-8] DEVE richiedere all'utente il certificato principale consigliato autenticazione (ad es. PIN, sequenza, password) o biometria di Classe 3 (FORTE) dopo una delle seguenti azioni:

  • un periodo di timeout di inattività di 4 ore OPPURE
  • 3 tentativi di autenticazione biometrica non riusciti.
  • Il periodo di timeout per inattività e il conteggio delle autenticazione non riuscite vengono reimpostati dopo una conferma delle credenziali del dispositivo. Nota: l'upgrade dei dispositivi con Android 9 o versioni precedenti POTREBBE esente da C-1-8.

• [C-SR-7] Si consiglia VIVAMENTE di utilizzare la logica nel framework fornito da Android Open Source Project per applicare i vincoli specificati [C-1-7] e [C-1-8] per i nuovi dispositivi.

• [C-SR-8] È VIVAMENTE CONSIGLIATO avere un tasso di rifiuto errato inferiore a 10%, come misurato sul dispositivo.

• [C-SR-9] È VIVAMENTE CONSIGLIATO avere una latenza inferiore a 1 secondo, misurata dal rilevamento dei dati biometrici allo sblocco dello schermo, per ogni biometrico registrato.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 2 (in precedenza Debole):

• [C-2-1] DEVE soddisfare tutti i requisiti della Classe 1 di cui sopra.

• [C-2-2] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 20%, con (1) un tasso di accettazione di spoofing e impostore le specie di strumenti di attacco di presentazione (PAI) di livello A non superiori al 20%, e (2) un tasso di accettazione di spoofing e impostori di specie PAI di livello B non superiore al 30%, come misurato in Protocolli del test di biometria di Android.

• [C-2-3] DEVE eseguire la corrispondenza biometrica in un ambiente di esecuzione isolato al di fuori di Android di un utente o di uno spazio kernel, come il Trusted Execution Environment (TEE), oppure su un chip con un canale sicuro verso l'ambiente di esecuzione isolato o su una macchina virtuale protetta che soddisfa i requisiti della Sezione 9.17.
• [C-2-4] DEVE avere tutti i dati identificabili criptati e crittografi autenticati in modo che non possano essere acquisiti, letti o alterati al di fuori l'ambiente di esecuzione isolato o un chip con un canale sicuro isolato come documentato nell'implementazione linee guida sul sito Android Open Source Project o una macchina virtuale protetta controllata da hypervisor che soddisfi i requisiti della Sezione 9.17.
• [C-2-5] Per la biometria basata su fotocamera, mentre l'autenticazione biometrica o è in corso la registrazione:
  • DEVE utilizzare la videocamera in una modalità che impedisca la visualizzazione dei fotogrammi viene letto o alterato al di fuori dell'ambiente di esecuzione isolato o di un chip da un canale sicuro all'ambiente di esecuzione isolato o una macchina virtuale protetta controllata da hypervisor che soddisfi i requisiti della Sezione 9.17.
  • Per le soluzioni RGB con fotocamera singola, i fotogrammi della fotocamera POSSONO essere leggibili al di fuori dell'ambiente di esecuzione isolato per supportare le operazioni come l'anteprima per la registrazione, ma NON DEVE comunque essere modificabile.
• [C-2-6] NON DEVE consentire alle applicazioni di terze parti di distinguere tra registrazioni biometriche individuali.
• [C-2-7] NON DEVE consentire l'accesso non criptato a dati biometrici identificabili o qualsiasi dato da essi derivato (come gli incorporamenti) al Responsabile del trattamento delle applicazioni al di fuori del contesto del TEE o la macchina virtuale protetta controllata dall'hypervisor che soddisfa i requisiti della Sezione 9.17. Non sono esclusi gli upgrade dei dispositivi lanciati con Android 9 o versioni precedenti da C-2-7.

• [C-2-8] DEVE avere una pipeline di elaborazione sicura, la compromissione del sistema o del kernel non può consentire l'inserimento diretto dei dati autenticarsi erroneamente come utente. Nota: se le implementazioni dei dispositivi sono già state lanciate su Android 9 o precedenti e non possono soddisfare il requisito C-2-8 tramite un software di sistema aggiornamento, POTREBBERO essere esentati dal requisito.

• [C-SR-10] È VIVAMENTE CONSIGLIATO di includere il rilevamento di attività per tutti modalità biometriche e rilevamento dell'attenzione per la biometria del volto.

• [C-2-9] DEVE rendere il sensore biometrico disponibile a terze parti diverse applicazioni.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 3 (in precedenza Strong), questi:

• [C-3-1] DEVE soddisfare tutti i requisiti della Classe 2 di cui sopra, ad eccezione delle [C-1-7] e [C-1-8].
• [C-3-2] DEVE avere un'implementazione di keystore supportata da hardware.
• [C-3-3] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 7%, con (1) un tasso di accettazione di spoofing e impostore le specie di strumenti di attacco di presentazione (PAI) di livello A non superiori al 7%, e 2) un tasso di accettazione di spoofing e impostore delle specie PAI di livello B non superiore a del 20%, come misurato dal Protocolli del test di biometria di Android.
• [C-3-4] DEVE richiedere all'utente il certificato principale consigliato autenticazione (ad es. PIN, sequenza, password) ogni 72 ore o meno.
• [C-3-5] DEVE generare di nuovo l'ID Authenticator per tutti i dati biometrici di Classe 3 supportati sul dispositivo, se uno di questi è nuova registrazione.
• [C-3-6] È necessario attivare le chiavi di archivi di chiavi biometrici per terze parti diverse applicazioni.

Se le implementazioni del dispositivo contengono un sensore di impronte digitali integrato nel display, l'utente:

• [C-SR-11] È VIVAMENTE CONSIGLIATO per evitare che l'area toccabile di UDFPS di interferire con la navigazione con tre pulsanti( che alcuni utenti potrebbero richiedere accessibilità).

7.3.11. Sensore di posizione

Implementazioni dei dispositivi:

• POTREBBE supportare il sensore di posa con 6 gradi di libertà.

Se le implementazioni del dispositivo supportano il sensore di posizione con 6 gradi di libertà, questi:

• [C-1-1] DEVE implementare e segnalare TYPE_POSE_6DOF sensore.
• [C-1-2] DEVE essere più preciso del solo vettore di rotazione.

7.3.12. Sensore dell'angolo della cerniera

Se le implementazioni dei dispositivi supportano un sensore per l'angolo della cerniera, questi:

• [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 risveglio sensore per getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Se le implementazioni del dispositivo includono il supporto per 802.1.15.4 ed espongono il funzionalità a un'applicazione di terze parti, questi:

7.4. Connettività dei dati

7.4.1. Telefonia

"Telefonia", come utilizzato dalle API Android, e il presente documento fa riferimento nello specifico a hardware per effettuare chiamate vocali e inviare SMS o stabilire dati mobili tramite una rete GSM o CDMA (ad es. GSM, CDMA, LTE, NR). Un dispositivo che supporta il servizio "Telefonia" può scegliere di offrire alcuni o tutti i servizi di chiamata, messaggistica e dati in base al prodotto.

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

• Android POTREBBE essere utilizzato su dispositivi che non includono hardware per la telefonia. Questo Android è compatibile con dispositivi diversi dagli smartphone.

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

• [C-1-1] DEVE dichiarare il flag della funzionalità android.hardware.telephony e di altre funzionalità secondarie secondo la tecnologia.
• [C-1-2] DEVE implementare il supporto completo dell'API per la tecnologia in questione.
• DEVONO consentire tutti i tipi di servizi cellulari disponibili (2G, 3G, 4G, 5G, ecc.) durante le chiamate di emergenza (indipendentemente dai tipi di rete impostati SetAllowedNetworkTypeBitmap()).

Se le implementazioni dei dispositivi non includono hardware per la telefonia:

• [C-2-1] DEVE implementare le API complete in modalità autonoma.

Se le implementazioni del dispositivo supportano eUICC o eSIM/SIM incorporate e includono un meccanismo proprietario per rendere la funzionalità eSIM disponibile per terze parti sviluppatori:

• [C-3-1] DEVE dichiarare il android.hardware.telephony.euicc flag funzionalità.

Se le implementazioni dei dispositivi non impostano la proprietà di sistema ro.telephony.iwlan\_operation\_mode su "legacy", allora:

• [C-4-1] NON DEVE segnalare "NETWORK_TYPE_IWLAN" tramite NetworkRegistrationInfo#getAccessNetworkTechnology() quando NetworkRegistrationInfo#getTransportType() è segnalato come "TRANSPORT_TYPE_WWAN" per la stessa istanza NetworkRegistrationInfo.

Se le implementazioni dei dispositivi supportano un singolo sottosistema IP multimediale (IMS) sia per il servizio di telefonia multimediale (MMTEL) che per le funzionalità RCS (Rich Communication Services) e devono essere conformi con i requisiti dell'operatore di telefonia mobile relativi all'utilizzo di un Registrazione IMS per tutto il traffico di segnalazione IMS:

• [C-5-1] DEVE dichiarare lo android.hardware.telephony.ims flag funzionalità e fornire un'implementazione completa API ImsService per API User Capability Exchange MMTEL e RCS.
• [C-5-2] DEVE dichiarare lo android.hardware.telephony.ims.singlereg il flag funzionalità e fornisce un'implementazione completa dell'API SipTransport, l'API GbaService, indicazioni al portatore dedicate utilizzando IRadio 1.6 HAL e mediante un server di configurazione automatica (ACS) o un altro provisioning proprietario meccanismo di attenzione utilizzando l'API di configurazione IMS.

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

• [C-6-1] La SmsManager#sendTextMessage e SmsManager#sendMultipartTextMessage DEVE comportare chiamate corrispondenti a CarrierMessagingService per fornire funzionalità di messaggistica di testo. SmsManager#sendMultimediaMessage e SmsManager#downloadMultimediaMessage DEVE comportare chiamate corrispondenti a CarrierMessagingService per fornire funzionalità di messaggistica multimediale.
• [C-6-2] L'applicazione designata da android.provider.Telephony.Sms#getDefaultSmsPackage DEVE utilizzare SmsManager API per l'invio e la ricezione di SMS e MMS. Riferimento AOSP l'implementazione in pacchetti/app/messaggistica soddisfa questo requisito.
• [C-6-3] L’applicazione che risponde Intent#ACTION_DIAL DEVE supportare l'inserimento di codici tastiera arbitrarie formattati come *#*#CODE#*#* e attivino una query TelephonyManager#ACTION_SECRET_CODE la trasmissione.
• [C-6-4] L’applicazione che risponde Intent#ACTION_DIAL DEVE utilizzare VoicemailContract.Voicemails#TRANSCRIPTION per mostrare la trascrizione della segreteria trascritta agli utenti se supporta la lettura trascrizioni di messaggi vocali.
• [C-6-5] DEVE rappresentare tutte le SubscriptionInfo con un valore equivalente UUID del gruppo come un unico abbonamento in tutte le proposte visibili all'utente che mostrano e controllo dei dati della scheda SIM. Esempi di tali inviti includono le impostazioni che corrispondono Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS o EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
• [C-6-6] NON DEVE mostrare o consentire il controllo di SubscriptionInfo con un UUID gruppo non null e un po' opportunistico in qualsiasi invito visibile all'utente Consentire la configurazione o il controllo delle impostazioni della scheda SIM.

Se le implementazioni dei dispositivi segnalano la funzionalità android.hardware.telephony e fornire una barra di stato del sistema, quindi:

• [C-7-1] DEVE selezionare un abbonamento attivo e rappresentativo per un determinato UUID gruppo da mostrare all'utente in tutte le proposte che forniscono lo stato della SIM informazioni. Esempi di tali inviti includono la rete cellulare nella barra di stato icona del segnale o riquadro Impostazioni rapide.
• [C-SR-1] È VIVAMENTE CONSIGLIATO che l'abbonamento rappresentativo sia scelto per essere abbonamento dati attivo a meno che il dispositivo non fornisca una voce durante la quale è VIVAMENTE CONSIGLIATO che il rappresentante è l'abbonamento di Active Voice.

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

• [C-6-7] DEVE essere in grado di aprire e utilizzare contemporaneamente il numero di canali logici (20 in totale) per ogni UICC in base allo standard ETSI TS 102 221.
• [C-6-8] NON DEVE applicare nessuno dei seguenti comportamenti alle app dell'operatore attive (come indicato da TelephonyManager#getCarrierServicePackageName) automaticamente o senza la conferma esplicita dell'utente:
  • Revocare o limitare l'accesso alla rete
  • Revoca autorizzazioni
  • Limita l'esecuzione di app in background o in primo piano oltre le funzionalità di gestione dell'alimentazione esistenti incluse in AOSP
  • Disattivare o disinstallare l'app

Se le implementazioni dei dispositivi segnalano la funzionalità android.hardware.telephony e tutti attivi, abbonamenti non opportunistici che condividono un UUID di gruppo sono disabilitati, rimosso fisicamente dal dispositivo o contrassegnato come opportunistico, il dispositivo:

• [C-8-1] DEVE disattivare automaticamente tutti i dispositivi attivi rimanenti opportunistico abbonamenti nello stesso gruppo.

Se le implementazioni dei dispositivi includono la telefonia GSM, ma non la telefonia CDMA:

• [C-9-1] NON DEVE dichiarare PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] DEVE lanciare un IllegalArgumentException al tentativo di impostare qualsiasi Tipi di rete 3GPP2 nelle maschere di bit dei tipi di rete preferiti o consentiti.
• [C-9-3] DEVE restituire una stringa vuota da TelephonyManager#getMeid

Se le implementazioni del dispositivo supportano eUICC con più porte e profili, questi:

• [C-10-1] DEVE dichiarare il android.hardware.telephony.euicc.mep flag funzionalità.

7.4.1.1. Compatibilità con blocco numerico

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

• [C-1-1] DEVE includere il supporto del blocco dei numeri
• [C-1-2] DEVE implementare completamente BlockedNumberContract e l'API corrispondente, come descritto nella documentazione dell'SDK.

• [C-1-3] DEVE bloccare tutte le chiamate e i messaggi da un numero di telefono in "BlockNumberProvider" senza alcuna interazione con le app. L'unica eccezione si verifica quando il blocco del numero viene temporaneamente rimosso, come descritto nell'SDK. documentazione.

• [C-1-4] DEVE scrivere nel provider del registro chiamate della piattaforma per una chiamata bloccata e DEVE filtrare le chiamate con BLOCKED_TYPE visualizzazione predefinita del registro chiamate nell'app Telefono preinstallata.

• [C-1-5] NON DEVE scrivere al provider di telefonia per un messaggio bloccato.

• [C-1-6] DEVE implementare un'interfaccia utente per la gestione dei numeri bloccata, che venga aperta con l'intent restituito da 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 dei servizi di telefonia, una singola istanza, sul dispositivo. Tutti l'interfaccia utente correlata al blocco DEVE essere nascosta per gli utenti secondari e l'elenco degli utenti bloccati DEVE essere nascosto essere comunque rispettati.

• DOVRESTI eseguire la migrazione dei numeri bloccati al fornitore quando un dispositivo si aggiorna ad Android 7.0.

• DEVE fornire un invito all'utente per mostrare le chiamate bloccate nel app tastiera.

7.4.1.2. API Telecom

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

• [C-1-1] DEVE supportare le API ConnectionService descritte nell'SDK.
• [C-1-2] DEVE visualizzare una nuova chiamata in arrivo e fornire all'utente l'invito a accettare o rifiutare la chiamata in arrivo mentre l'utente è impegnata in una chiamata creato da un'app di terze parti che non supporta la funzionalità di sospensione specificato tramite CAPABILITY_SUPPORT_HOLD
• [C-1-3] DEVE avere un'applicazione che implementa InCallService.

• [C-SR-1] È VIVAMENTE CONSIGLIATO di informare l'utente che, rispondendo a una una chiamata in arrivo interromperà una chiamata in corso.

  L'implementazione di AOSP soddisfa questi requisiti tramite una notifica di avviso. che indica all'utente che rispondendo a una chiamata in arrivo verrà o un'altra chiamata.

• [C-SR-2] È VIVAMENTE CONSIGLIATO di 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 EXTRA_LOG_SELF_MANAGED_CALLS extra nel codice da PhoneAccount a true.

• [C-SR-3] È VIVAMENTE CONSIGLIATO per gestire la gestione Eventi KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK per il android.telecom le API come indicato di seguito:

  • Chiama il numero Connection.onDisconnect() Quando viene rilevata una breve pressione dell'evento chiave durante una chiamata in corso.
  • Chiama il numero Connection.onAnswer() quando viene rilevata una breve pressione dell'evento chiave durante una chiamata in arrivo.
  • Chiama il numero Connection.onReject() Quando viene rilevata una pressione prolungata dell'evento chiave durante una chiamata in arrivo.
  • Attiva/disattiva lo stato di disattivazione dell'audio di CallAudioState.

7.4.1.3. Offload keepalive NAT-T cellulare

Implementazioni dei dispositivi:

• DEVE includere il supporto per l'offload keepalive della rete mobile.

Se le implementazioni dei dispositivi includono il supporto per l'offload keepalive cellulare e espone la funzionalità ad app di terze parti, queste:

• [C-1-1] DEVE supportare l'API SocketKeepAlive.
• [C-1-2] DEVE supportare almeno uno slot keepalive simultaneo su rete cellulare.
• [C-1-3] DEVE supportare tutti gli slot keepalive di telefonia mobile simultanei supportate da Cellular Radio HAL.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare almeno tre keepalive cellulare slot per istanza radio.

Se le implementazioni dei dispositivi non includono il supporto per l'offload keepalive della rete cellulare, l'utente:

• [C-2-1] DEVE restituire ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementazioni dei dispositivi:

• DEVE includere il supporto per una o più forme di 802.11.

Se le implementazioni dei dispositivi includono il supporto per 802.11 ed espongono funzionalità a un'applicazione di terze parti, questi:

• [C-1-1] DEVE implementare l'API Android corrispondente.
• [C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.wifi.
• [C-1-3] DEVE implementare l'API multicast come descritto nella documentazione dell'SDK.
• [C-1-4] DEVE supportare il DNS multicast (mDNS) e NON filtrare i pacchetti mDNS (224.0.0.251 o ff02::fb) in qualsiasi momento di funzionamento, anche quando lo schermo non è in stato attivo, a meno che questi pacchetti vengano eliminati o filtrati necessarie per rimanere entro gli intervalli di consumo energetico richiesti dalle normative requisiti applicabili al mercato di destinazione. Per le implementazioni di dispositivi Android Television, quando sono in stato di alimentazione in standby.
• [C-1-5] NON DEVE trattare WifiManager.enableNetwork() chiamata al metodo API come indicazione sufficiente per cambiare il metodo attualmente attivo Network utilizzato per impostazione predefinita per il traffico dell'applicazione e che viene restituito di ConnectivityManager Metodi API come getActiveNetwork e registerDefaultNetworkCallback. In altre parole, POSSONO disabilitare solo l’accesso a Internet fornito da qualsiasi altro fornitore di rete (ad es. dati mobili) se la convalida viene eseguita correttamente che la rete Wi-Fi fornisca l'accesso a Internet.
• [C-1-6] VIVAMENTE CONSIGLIATE, quando ConnectivityManager.reportNetworkConnectivity() viene richiamato il metodo API, rivaluta l'accesso a Internet su Network e una volta che la valutazione determina che l'elemento Network corrente non fornisce più Accedi a internet, passa a una qualsiasi altra rete disponibile (ad es. una rete mobile dati) che fornisce l'accesso a Internet.
• [C-1-7] DEVE randomizzare l’indirizzo MAC sorgente e il numero di sequenza del probe di richiesta, una volta all'inizio di ogni scansione, mentre STA disconnesso.
• [C-1-8] DEVE utilizzare un indirizzo MAC coerente (NON DEVE randomizzare l'indirizzo MAC) indirizzo a metà della scansione).
• [C-1-9] DEVE ripetere il numero di sequenza della richiesta di probe come di consueto (in sequenza) tra le richieste di probe in una scansione.
• [C-1-10] DEVE randomizzare il numero di sequenza della richiesta di un probe tra l’ultimo probe richiesta di una scansione e la prima richiesta di probe della scansione successiva.
• [C-SR-1] CONSIGLIATO VIVAMENTE di randomizzare l’indirizzo MAC di origine utilizzato tutte le comunicazioni STA con un punto di accesso (AP) durante l'associazione e associati.
  • Il dispositivo DEVE utilizzare un indirizzo MAC randomizzato diverso per ogni SSID (FQDN per Passpoint) con cui comunica.
  • Il dispositivo DEVE offrire all'utente la possibilità di controllare randomizzazione per SSID (FQDN per Passpoint) con randomizzate e DEVE impostare la modalità predefinita per i nuovi configurazioni casuali da randomizzare.
• [C-SR-2] CONSIGLIATO VIVAMENTE di usare un BSSID casuale per tutti gli AP che creare.
  • L'indirizzo MAC DEVE essere randomizzato e mantenuto in base all'SSID utilizzato AP.
  • Il DISPOSITIVO POTREBBE offrire all'utente un'opzione per disattivare questa funzione. Se viene fornita questa opzione, la randomizzazione DEVE essere abilitata per impostazione predefinita.

Se le implementazioni del dispositivo includono il supporto per la modalità di risparmio energetico del Wi-Fi come definito secondo lo standard IEEE 802.11:

• DEVI disattivare la modalità di risparmio energetico del Wi-Fi ogni volta che un'app acquisisce Serratura WIFI_MODE_FULL_HIGH_PERF o WIFI_MODE_FULL_LOW_LATENCY serratura tramite WifiManager.createWifiLock() e WifiManager.WifiLock.acquire() le API e il blocco sono attivi.
• [C-3-2] La latenza media di round trip tra i dispositivi e un punto di accesso quando il dispositivo è in un blocco a bassa latenza Wi-Fi La modalità (WIFI_MODE_FULL_LOW_LATENCY) DEVE essere inferiore a di latenza durante una modalità di blocco High Perf del Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] CONSIGLIATE VIVAMENTE per ridurre al minimo la latenza di round trip del Wi-Fi ogni volta che viene acquisito un blocco a bassa latenza (WIFI_MODE_FULL_LOW_LATENCY) ed è in vigore.

Se le implementazioni del dispositivo supportano il Wi-Fi e lo utilizzano per la ricerca della posizione, l'utente:

• [C-2-1] DEVE fornire un invito all'utente per abilitare/disabilitare il valore letto tramite WifiManager.isScanAlwaysAvailable API.

7.4.2.1. Wi-Fi Direct

Implementazioni dei dispositivi:

• DOVREBBE includere il supporto per Wi-Fi Direct (peer-to-peer Wi-Fi).

Se le implementazioni dei dispositivi includono il supporto per Wi-Fi Direct:

• [C-1-1] DEVE implementare l'API Android corrispondente come descritto nella documentazione dell'SDK.
• [C-1-2] DEVE segnalare la funzionalità hardware android.hardware.wifi.direct.
• [C-1-3] DEVE supportare il normale funzionamento del Wi-Fi.
• [C-1-4] DEVE supportare contemporaneamente operazioni Wi-Fi e Wi-Fi Direct.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di randomizzare l'indirizzo MAC di origine per tutti di nuove connessioni Wi-Fi Direct.

7.4.2.2. Configurazione del collegamento diretto tramite tunnel Wi-Fi

Implementazioni dei dispositivi:

• DEVE includere il supporto di Configurazione del collegamento diretto tramite tunnel Wi-Fi (TDLS) come descritto nella Documentazione dell'SDK Android.

Se le implementazioni dei dispositivi includono il supporto per TDLS e TDLS è abilitato dal l'API WiFiManager,

• [C-1-1] DEVE dichiarare il supporto per TDLS tramite WifiManager.isTdlsSupported.
• DOVREBBE usare TDLS solo quando è possibile E vantaggioso.
• DOVREBBE avere un po' di euristica e NON usare TDLS quando le sue prestazioni potrebbero è peggio che passare attraverso un punto di accesso Wi-Fi.

7.4.2.3. Sensibile al Wi-Fi

Implementazioni dei dispositivi:

• DEVE includere il supporto per Wi-Fi Aware.

Se le implementazioni del dispositivo includono il supporto per Wi-Fi Aware ed espongono il di terze parti alle app di terze parti, questi:

• [C-1-1] DEVE implementare le API WifiAwareManager come descritto nei Documentazione SDK.
• [C-1-2] DEVE dichiarare il flag della funzionalità android.hardware.wifi.aware.
• [C-1-3] DEVE supportare contemporaneamente operazioni Wi-Fi e Wi-Fi Aware.
• [C-1-4] DEVE randomizzare a intervalli l'indirizzo dell'interfaccia di gestione di Wi-Fi Aware per un massimo di 30 minuti e ogni volta che il Wi-Fi Aware è attivo, a meno che non di distanza è in corso o è attivo un percorso dati Aware (la randomizzazione non è previsto per tutto il periodo in cui il percorso dati è attivo).

Se le implementazioni dei dispositivi includono il supporto per Wi-Fi Aware e Posizione Wi-Fi come descritto nella Sezione 7.4.2.5 e espone queste funzionalità ad app di terze parti, dopodiché:

• [C-2-1] DEVE implementare le API di rilevamento della posizione: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint Wi-Fi

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

• [C-1-1] DEVE includere il supporto per Passpoint Wi-Fi.
• [C-1-2] DEVE implementare le API WifiManager relative a Passpoint come descritti nella documentazione dell'SDK.
• [C-1-3] DEVE supportare lo standard IEEE 802.11u, in particolare alla scoperta e selezione della rete, ad esempio la pubblicità generica Service (GAS) e Access Network Query Protocol (ANQP).
• [C-1-4] DEVE dichiarare il flag di funzionalità android.hardware.wifi.passpoint.
• [C-1-5] DEVE seguire l'implementazione di AOSP per scoprire, associare e associare alle reti Passpoint.
• [C-1-6] DEVE supportare almeno il seguente sottoinsieme di provisioning dispositivo protocolli come definiti nel Wi-Fi Alliance Passpoint R2: EAP-TTLS autenticazione e SOAP-XML.
• [C-1-7] DEVE elaborare il certificato del server AAA come descritto in Specifiche Hotspot 2.0 R3.
• [C-1-8] DEVE supportare il controllo utente del provisioning tramite il selettore Wi-Fi.
• [C-1-9] DEVE mantenere le configurazioni Passpoint persistenti tra i riavvii.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare i termini e le condizioni di accettazione.
• [C-SR-2] È VIVAMENTE CONSIGLIATO per il supporto della funzionalità Informazioni sulla sede.

Se viene fornita un'opzione di controllo utente per la disattivazione di Passpoint globale, le implementazioni:

• [C-3-1] DEVE attivare Passpoint per impostazione predefinita.

7.4.2.5. Posizione Wi-Fi (tempo di andata e ritorno Wi-Fi - RTT)

Implementazioni dei dispositivi:

• DEVE includere il supporto della posizione Wi-Fi.

Se le implementazioni del dispositivo includono il supporto della posizione Wi-Fi ed espongono il di terze parti alle app di terze parti, questi:

• [C-1-1] DEVE implementare le API WifiRttManager come descritto nei Documentazione SDK.
• [C-1-2] DEVE dichiarare il flag della funzionalità android.hardware.wifi.rtt.
• [C-1-3] DEVE randomizzare l'indirizzo MAC sorgente per ogni burst RTT che viene eseguito mentre l'interfaccia Wi-Fi su cui è in esecuzione non è associato a un punto di accesso.
• [C-1-4] DEVE essere preciso entro i 2 metri alla larghezza di banda di 80 MHz al 68° percentile (come calcolato con la funzione di distribuzione cumulativa).
• [C-SR-1] È VIVAMENTE CONSIGLIATO di segnalarlo con precisione, entro 1,5 metri alla larghezza di banda di 80 MHz al 68° percentile (come calcolato funzione di distribuzione cumulativa).

7.4.2.6. Offload keepalive Wi-Fi

Implementazioni dei dispositivi:

• DEVE includere il supporto per l'offload keepalive Wi-Fi.

Se le implementazioni del dispositivo includono il supporto per l'offload keepalive Wi-Fi ed espongono la funzionalità ad app di terze parti, queste:

• [C-1-1] DEVE supportare l'API SocketKeepAlive.
• [C-1-2] DEVE supportare almeno tre slot keepalive simultanei tramite Wi-Fi

Se le implementazioni dei dispositivi non includono il supporto per l'offload keepalive Wi-Fi, l'utente:

• [C-2-1] DEVE restituire ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocollo di provisioning dei dispositivi)

Implementazioni dei dispositivi:

• DEVE includere il supporto per DPP (Wi-Fi Easy Connect).

Se le implementazioni del dispositivo includono il supporto per Wi-Fi Easy Connect ed espongono il di funzionalità alle app di terze parti, questi:

• [C-1-1] DEVE avere il valore WifiManager#is EasyConnectSupported() restituisce true.

7.4.2.8. Convalida certificati server Wi-Fi aziendali

Se il certificato del server Wi-Fi non è convalidato o il server Wi-Fi nome di dominio non impostato, implementazioni dispositivo:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di non offrire all'utente la possibilità di aggiungi manualmente una rete Wi-Fi aziendale nell'app Impostazioni.

7.4.2.9. Trust On First Use (TOFU)

Se le implementazioni del dispositivo supportano la funzionalità Trust al primo utilizzo (TOFU) e consente all'utente di definire configurazioni WPA/WPA2/WPA3-Enterprise, allora:

• [C-4-1] DEVE fornire all'utente un'opzione per scegliere di utilizzare TOFU.

7.4.3. Bluetooth

Se le implementazioni del dispositivo supportano il profilo audio Bluetooth:

• DEVE supportare i codec audio avanzati e i codec audio Bluetooth (ad es. LDAC)

Se le implementazioni dei dispositivi supportano HFP, A2DP e AVRCP, questi:

• DEVONO supportare almeno 5 dispositivi connessi in totale.

Se le implementazioni dei dispositivi dichiarano android.hardware.vr.high_performance questa funzionalità:

• [C-1-1] DEVE supportare Bluetooth 4.2 e Bluetooth LE estensione lunghezza dati.

Android include il supporto per Bluetooth e Bluetooth Low Energy.

Se le implementazioni dei dispositivi includono il supporto per Bluetooth e Bluetooth A bassa energia:

• [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.
• DOVREBBE implementare profili Bluetooth pertinenti come A2DP, AVRCP, OBEX, HFP e così via in base al dispositivo.

Se le implementazioni dei dispositivi includono il supporto per Bluetooth Low Energy (BLE):

• [C-3-1] DEVE dichiarare la funzionalità hardware android.hardware.bluetooth_le.
• [C-3-2] DEVE attivare il Bluetooth basato su GATT (attributo generico attributo) come descritto nella documentazione dell'SDK e android.bluetooth.
• [C-3-3] DEVE segnalare il valore corretto per BluetoothAdapter.isOffloadedFilteringSupported() per indicare se logica di filtro per ScanFilter le classi API sono implementate.
• [C-3-4] DEVE segnalare il valore corretto per BluetoothAdapter.isMultipleAdvertisementSupported() per indicare se la pubblicità a bassa energia è supportata.

• [C-3-5] DEVE implementare un timeout RPA (Resolvable Private Address) non più per più di 15 minuti e ruota l'indirizzo al timeout per proteggere la privacy degli utenti se il dispositivo utilizza attivamente la tecnologia BLE per la scansione o la pubblicità. Per prevenire gli attacchi al tempo, anche gli intervalli di timeout DEVONO essere randomizzati tra 5 e 15 minuti.

• DOVREBBE supportare lo scarico della logica di filtro sul chipset Bluetooth durante l'implementazione dell'API ScanFilter.

• DOVREBBE supportare lo scarico della scansione in batch sul chipset Bluetooth.

• DEVE supportare più annunci con almeno 4 aree annuncio.

Se le implementazioni del dispositivo supportano Bluetooth LE e lo utilizzano per scansione della posizione:

• [C-4-1] DEVE fornire un'invito all'utente per abilitare/disabilitare il valore letto tramite l'API di sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se le implementazioni dei dispositivi includono il supporto per Bluetooth LE e gli apparecchi acustici Profilo, come descritto in Supporto audio degli apparecchi acustici con Bluetooth LE:

• [C-5-1] DEVE restituire true per BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Se le implementazioni dei dispositivi includono il supporto per Bluetooth o Bluetooth Low Energy, l'utente:

• [C-6-1] DEVE limitare l'accesso ai metadati Bluetooth (ad esempio, risultati) che potrebbero essere usati per risalire alla posizione del dispositivo, a meno che l'app che ha inviato la richiesta supera correttamente un android.permission.ACCESS_FINE_LOCATION del controllo delle autorizzazioni in base al suo stato attuale in primo piano o in background.

Se le implementazioni dei dispositivi includono il supporto per Bluetooth o Bluetooth Low Energy e il file manifest dell'app non include una dichiarazione dello sviluppatore che indichi che la posizione non viene ricavata dal Bluetooth, dopodiché:

• [C-6-2] DEVE limitare l'accesso al Bluetooth dietro il android.permission.ACCESS_FINE_LOCATION.

Se le implementazioni del dispositivo restituiscono true per API BluetoothAdapter.isLeAudioSupported(), quindi:

• [C-7-1] DEVE supportare il client unicast.
• [C-7-2] DEVE supportare 2 MB di PHY.
• [C-7-3] DEVE supportare LE Extended Advertising.
• [C-7-4] DEVE supportare almeno 2 connessioni CIS in una CIG.
• [C-7-5] DEVE abilitare il client unicast BAP, il coordinatore impostato CSIP, il server MCP, Controller VCP e server CCP contemporaneamente.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di abilitare il client unicast HAP.

Se le implementazioni del dispositivo restituiscono true per API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), quindi:

• [C-8-1] DEVE supportare almeno 2 collegamenti BIS in un GRANDE.
• [C-8-2] DEVE abilitare la sorgente di trasmissione BAP, l'assistente di trasmissione BAP contemporaneamente.
• [C-8-3] DEVE supportare LE la pubblicità periodica.

Se le implementazioni del dispositivo restituiscono true per API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), quindi:

• [C-9-1] DEVE supportare il trasferimento periodico della sincronizzazione della pubblicità.
• [C-9-2] DEVE supportare LE la pubblicità periodica.

Se le implementazioni dei dispositivi dichiarano FEATURE_BLUETOOTH_LE:

• [C-10-1] DEVE avere misurazioni RSSI entro +/-9dB per il 95% della misurazioni a 1 m di distanza da un dispositivo di riferimento che trasmette a ADVERTISE_TX_POWER_HIGH in linea con l'ambiente visivo.

• [C-10-2] DEVE includere correzioni Rx/Tx per ridurre le deviazioni per canale in modo che le misurazioni su ciascuno dei 3 canali, su ciascuna delle antenne (se vengono utilizzati multipli), sono entro +/-3 dB l'uno dall'altro per il 95% le misurazioni.

• [C-SR-2] È VIVAMENTE CONSIGLIATO di misurare e compensare l'offset Rx a garantire che il BLE RSSI media sia -60dBm +/-10 dB a 1 m di distanza da un dispositivo di riferimento che trasmette alle ADVERTISE_TX_POWER_HIGH, dove i dispositivi vengono orientati in modo tale da essere su "piani paralleli" con schermi rivolti verso lo stesso .

• [C-SR-3] È VIVAMENTE CONSIGLIATO di misurare e compensare la differenza di trasmissione con assicura che l'RSSI BLE mediano sia -60dBm +/-10 dB quando si esegue la scansione da un riferimento dispositivo posizionato a 1 m di distanza e trasmettendo a ADVERTISE_TX_POWER_HIGH, dove i dispositivi sono orientati in modo che siano accesi "aerei paralleli" con schermi rivolti nella stessa direzione.

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

È CONSIGLIATA DI seguire i passaggi di configurazione della misurazione specificati in Requisiti per la calibrazione della presenza di persone.

7.4.4. Near Field Communication

Implementazioni dei dispositivi:

• DEVE includere un ricetrasmettitore e l'hardware correlato per Near Field Communication Comunicazioni (NFC).
• [C-0-1] DEVE implementare android.nfc.NdefMessage e API android.nfc.NdefRecord anche se non supportano NFC o dichiarare la caratteristica android.hardware.nfc poiché le classi rappresentano una di rappresentazione dei dati indipendente dal protocollo.

Se le implementazioni del dispositivo includono hardware NFC e si prevede di renderlo disponibile a di terze parti, devono:

• [C-1-1] DEVE segnalare la funzionalità android.hardware.nfc dal Metodo android.content.pm.PackageManager.hasSystemFeature().
• DEVE essere in grado di leggere e scrivere messaggi NDEF tramite il seguente NFC standard come riportato di seguito:
• [C-1-2] DEVE essere in grado di agire come lettore/autore del forum NFC (come definito dalle specifiche tecniche del forum NFC NFCForum-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Tipi di tag del forum NFC 1, 2, 3, 4, 5 (definiti dal forum NFC)

• [C-SR-1] VIVAMENTE CONSIGLIATO per essere in grado di leggere e scrivere NDEF messaggi e dati non elaborati tramite i seguenti standard NFC. Tieni presente che mentre gli standard NFC sono indicati come VIVAMENTE CONSIGLIATI, Si prevede che la definizione di compatibilità per una versione futura modifichi queste impostazioni a DEVE. Questi standard sono facoltativi in questa versione, ma saranno obbligatori nelle versioni future. Dispositivi nuovi ed esistenti che eseguono questa versione di Android è vivamente incoraggiata a soddisfare questi requisiti ora, quindi potrà eseguire l'upgrade alle future release della piattaforma.

• [C-1-13] DEVE effettuare un sondaggio per tutte le tecnologie supportate durante la scoperta dell'NFC .

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

• DOVREBBE essere in grado di leggere il codice a barre e l'URL (se codificato) di Codice a barre NFCThinfilm prodotti di big data e machine learning.

Tieni presente che i link disponibili pubblicamente non sono disponibili per JIS, ISO e NFC Specifiche del forum citate sopra.

Android supporta la modalità HCE (NFC Host Card Emulation).

Se le implementazioni del dispositivo includono un chipset del controller NFC in grado di eseguire l'HCE (per NfcA e/o NfcB) e supportano il routing AID (Application ID) (ID applicazione), questi:

• [C-2-1] DEVE segnalare la costante della funzionalità android.hardware.nfc.hce.
• [C-2-2] DEVE supportare le API NFC HCE come nell'SDK Android.

Se le implementazioni del dispositivo includono un chipset del controller NFC in grado di eseguire l'HCE per NfcF e implementano la funzionalità per applicazioni di terze parti, questi:

• [C-3-1] DEVE segnalare la costante della funzionalità android.hardware.nfc.hcef.
• [C-3-2] DEVE implementare le API di emulazione schede NFC come definito nell'SDK Android.

Se le implementazioni del dispositivo includono il supporto NFC generale, come descritto in e supportare le tecnologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF su MIFARE Classic) nel ruolo di lettore/scrittore, l'agenzia:

• [C-4-1] DEVE implementare le API Android corrispondenti, come documentato da l'SDK per Android.
• [C-4-2] DEVE segnalare la funzionalità com.nxp.mifare dal android.content.pm.PackageManager.hasSystemFeature() . Tieni presente che questa non è una funzione Android standard e, di conseguenza, non vengono visualizzate come costante nella classe android.content.pm.PackageManager.

7.4.5. Protocolli di rete e API

7.4.5.1. Capacità di rete minima

Implementazioni dei dispositivi:

• [C-0-1] DEVE includere il supporto di una o più forme di networking di dati. In particolare, le implementazioni dei dispositivi DEVONO includere il supporto almeno uno standard di dati in grado di funzionare a 200 Kbit/sec o superiore. Esempi di le tecnologie che soddisfano questo requisito includono EDGE, HSPA, EV-DO, 802.11g, Ethernet e PAN Bluetooth.
• DEVE includere anche il supporto per almeno un dato wireless comune standard, come 802.11 (Wi-Fi), quando uno standard di rete fisico (come Ethernet) è la connessione dati principale.
• POTREBBE implementare più di una forma di connettività dati.

7.4.5.2. IPv6

Implementazioni dei dispositivi:

• [C-0-2] DEVE includere uno stack di rete IPv6 e supportare IPv6 comunicazione tramite API gestite, come java.net.Socket java.net.URLConnection, oltre alle API native, come AF_INET6 prese di corrente.
• [C-0-3] DEVE abilitare IPv6 per impostazione predefinita.
  • DEVE garantire che la comunicazione IPv6 sia affidabile quanto IPv4, ad esempio:
    • [C-0-4] DEVE mantenere la connettività IPv6 in modalità sospensione.
    • [C-0-5] La limitazione di frequenza NON DEVE causare la perdita di IPv6 del dispositivo connettività su qualsiasi rete conforme a IPv6 che utilizza durate RA di almeno 180 secondi.
• [C-0-6] DEVE fornire alle applicazioni di terze parti la connettività diretta IPv6 alla rete quando si è connessi a una rete IPv6, senza alcun tipo di indirizzo o la traduzione delle porte avviene localmente sul dispositivo. Entrambe le API gestite, come Socket#getLocalAddress o Socket#getLocalPort) e le API NDK come getsockname() o IPV6_PKTINFO DEVONO restituire l'indirizzo e la porta effettivamente utilizzati per inviare e ricevere pacchetti ed è visibile come IP di origine e porta ai server internet (web).

Il livello richiesto di supporto IPv6 dipende dal tipo di rete, come mostrato in i seguenti requisiti.

Se le implementazioni del dispositivo supportano il Wi-Fi:

• [C-1-1] DEVE supportare il funzionamento a doppio stack e solo IPv6 su Wi-Fi.

Se le implementazioni dei dispositivi supportano Ethernet:

• [C-2-1] DEVE supportare il funzionamento a doppio stack e solo IPv6 su o Ethernet.

Se le implementazioni dei dispositivi supportano la rete dati:

• [C-3-1] DEVE supportare l'operazione IPv6 (solo IPv6 e probabilmente a doppio stack) cellulare.

Se le implementazioni dei dispositivi supportano più di un tipo di rete (ad es. Wi-Fi e rete dati), queste:

• [C-4-1] DEVE soddisfare contemporaneamente i requisiti di cui sopra su ogni rete quando il dispositivo è connesso contemporaneamente a più tipi di rete.

7.4.5.3. Captive portal

Un captive portal è una rete che richiede l'accesso per poter di avere accesso a internet.

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

• [C-1-1] DEVE fornire un'applicazione captive portal per gestire l'intento ACTION_CAPTIVE_PORTAL_SIGN_IN e visualizzare la pagina di accesso al captive portal inviando questo intento 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, tra cui rete mobile/mobile, Wi-Fi, Ethernet o Bluetooth.
• [C-1-3] DEVE supportare l'accesso a captive portal utilizzando DNS in testo in chiaro se il dispositivo è configurato per l'uso della modalità con restrizioni DNS privato.
• [C-1-4] DEVE utilizzare il DNS criptato, in base alla documentazione dell'SDK per android.net.LinkProperties.getPrivateDnsServerName e android.net.LinkProperties.isPrivateDnsActive per tutto il traffico di rete che non comunica esplicitamente con il captive portal.
• [C-1-5] DEVE garantire che, mentre l'utente accede a un captive, di Google, la rete predefinita utilizzata dalle applicazioni (restituita ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback, e viene utilizzato per impostazione predefinita dalle API di networking Java, come java.net.Socket, e le API native come connect()) è qualsiasi altra rete disponibile che fornisca l'accesso a internet, se disponibile.

7.4.6. Impostazioni sincronizzazione

Implementazioni dei dispositivi:

• [C-0-1] DEVE avere la sincronizzazione automatica principale attivata per impostazione predefinita, il metodo getMasterSyncAutomatically() restituisce "true".

7.4.7. Risparmio dati

Se le implementazioni dei dispositivi includono una connessione a consumo, si tratta di:

• [C-SR-1] VIVAMENTE CONSIGLIATO per offrire la modalità Risparmio dati.

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

• [C-1-1] DEVE supportare tutte le API in ConnectivityManager come descritto nella documentazione dell'SDK

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

• [C-2-1] DEVE restituire il valore RESTRICT_BACKGROUND_STATUS_DISABLED per ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NON DEVE trasmettere ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Secure Element

Se le implementazioni dei dispositivi supportano la funzionalità Open Mobile API proteggere gli elementi e renderli disponibili ad app di terze parti, ovvero:

• [C-1-1] DEVE enumerare i lettori di elementi sicuri disponibili tramite API android.se.omapi.SEService.getReaders().

• [C-1-2] DEVE dichiarare i flag funzionalità corretti tramite android.hardware.se.omapi.uicc per il dispositivo con Secure Element basati su UICC, android.hardware.se.omapi.ese per il dispositivo con Secure Element basati su eSE, android.hardware.se.omapi.sd per il dispositivo con elementi di sicurezza basati su SD.

7.4.9. UWB

Se le implementazioni dei dispositivi includono il supporto per 802.1.15.4 ed espongono la funzionalità a un'applicazione di terze parti, allora:

• [C-1-1] DEVE implementare l'API Android corrispondente in android.uwb.
• [C-1-2] DEVE segnalare il flag funzionalità hardware android.hardware.uwb.
• [C-1-3] DEVE supportare tutti i profili UWB pertinenti definiti in Android implementazione.
• [C-1-4] DEVE fornire un'invito all'utente per consentire all'utente di attivare/disattivare la tecnologia UWB stato acceso/spento.
• [C-1-5] DEVE imporre che le app che usano radio UWB abbiano l'autorizzazione UWB_RANGING (in gruppo di autorizzazioni NEARBY_DEVICE).
• [C-SR-1] È VIVAMENTE CONSIGLIATO di superare la conformità e di certificazione definiti da organizzazioni standard, tra cui FIRA, CCC e CSA.
• [C-1-6] DEVE garantire che le misurazioni della distanza siano entro +/-15 cm per il 95% delle misurazioni nell'ambiente in linea di vista a 1 m di distanza in una camera non riflettente.
• [C-1-7] DEVE garantire che la mediana delle misurazioni della distanza a 1 m dal dispositivo di riferimento si trova entro [0,75 m, 1,25 m], dove i dati di fatto la distanza è misurata dal bordo superiore del dispositivo durevole. rivolto verso l'alto e inclinato di 45 gradi.
• [C-SR-2] È VIVAMENTE CONSIGLIATO di seguire i passaggi di configurazione della misurazione specificato in Requisiti per la calibrazione della presenza di persone.

7.5. Fotocamere

Se le implementazioni dei dispositivi includono almeno una fotocamera:

• [C-1-1] DEVE dichiarare il flag della funzionalità android.hardware.camera.any.
• [C-1-2] DEVE essere possibile che un'applicazione allochi contemporaneamente 3 bitmap RGBA_8888 uguali alle dimensioni delle immagini prodotte sensore della fotocamera con la risoluzione più grande del dispositivo, mentre la fotocamera è aperta per lo scopo dell'anteprima di base e dell'acquisizione.
• [C-1-3] DEVE garantire che l'applicazione della videocamera predefinita preinstallata gestire gli intent MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, o MediaStore.ACTION_VIDEO_CAPTURE, è responsabile della rimozione della posizione dell'utente nei metadati dell'immagine prima l'invio all'applicazione ricevente quando quest'ultima non hanno ACCESS_FINE_LOCATION.

Se le implementazioni dei dispositivi supportano la funzionalità di output HDR a 10 bit:

• [C-2-1] DEVE supportare almeno il profilo HLG HDR per ogni dispositivo dotato di fotocamera che supporta output a 10 bit.
• [C-2-2] DEVE supportare l’output a 10 bit per il modulo primario posteriore o fotocamera anteriore principale.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare l'output a 10 bit sia per videocamere.
• [C-2-3] DEVE supportare gli stessi profili HDR per tutti Fotocamere secondarie fisiche compatibili con BACKWARD_COMPATIBLE di una fotocamera logica e la fotocamera logica.

Per i dispositivi con fotocamere logica che supportano la tecnologia HDR a 10 bit e implementano API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, questi:

• [C-3-1] DEVE supportare il passaggio tra tutti i supporti fisici compatibili videocamere tramite il controllo CONTROL_ZOOM_RATIO sulla fotocamera logica.

7.5.1. Fotocamera posteriore

Implementazioni dei dispositivi:

• DEVE includere una fotocamera posteriore.

Se le implementazioni del dispositivo includono almeno una fotocamera posteriore:

• [C-1-1] DEVE segnalare il flag di funzionalità android.hardware.camera e android.hardware.camera.any.
• [C-1-2] DEVE avere una risoluzione di almeno 2 megapixel.
• DEVONO implementare la messa a fuoco automatica hardware o software. nel driver della fotocamera (trasparente al software dell'applicazione).
• POTREBBERO avere hardware a fuoco fisso o EDOF (profondità di campo estesa).
• POSSONO includere un flash.

Se la fotocamera include il flash:

• [C-2-1] il flash NON DEVE essere acceso mentre L'istanza android.hardware.Camera.PreviewCallback è stata registrata su una superficie di anteprima della fotocamera, a meno che l'applicazione non l'abbia esplicitamente attivata 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 l'applicazione della fotocamera di sistema integrata del dispositivo, ma soltanto per terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

Implementazioni dei dispositivi:

• POTREBBE includere una fotocamera anteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera anteriore:

• [C-1-1] DEVE segnalare il flag di funzionalità android.hardware.camera.any e android.hardware.camera.front.
• [C-1-2] DEVE avere una risoluzione di almeno VGA (640x480 pixel).
• [C-1-3] NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Camera e NON DEVONO configurare l'API per trattare una fotocamera anteriore come la fotocamera posteriore predefinita, anche se è l'unica sul dispositivo.
• [C-1-4] L'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto al orientamento specificato dall'applicazione quando quella corrente ha ha richiesto esplicitamente che la fotocamera display può essere ruotato tramite una chiamata android.hardware.Camera.setDisplayOrientation() . Al contrario, l'anteprima DEVE essere sottoposta a mirroring con il valore predefinito del dispositivo asse orizzontale quando l'applicazione corrente non richiede esplicitamente che il display della Fotocamera venga ruotato tramite una chiamata al android.hardware.Camera.setDisplayOrientation() .
• [C-1-5] NON DEVE rispecchiare gli stream video o l'immagine statica acquisiti finali ai callback delle applicazioni o impegnate nello spazio di archiviazione multimediale.
• [C-1-6] DEVE eseguire il mirroring dell'immagine visualizzata nel postview nello stesso modo come stream di immagini di anteprima della fotocamera.
• POTREBBERO includere funzionalità (come messa a fuoco automatica, flash e così via) disponibili per fotocamere posteriori come descritto nella sezione 7.5.1.

Se le implementazioni dei dispositivi possono essere ruotate dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input utente):

• [C-2-1] L'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto a l'orientamento corrente del dispositivo.

7.5.3. Videocamera esterna

Implementazioni dei dispositivi:

• POTREBBE includere il supporto di una videocamera esterna che non corrisponde necessariamente sempre connessi.

Se le implementazioni dei dispositivi includono il supporto per una fotocamera esterna:

• [C-1-1] DEVE dichiarare il flag funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any.
• [C-1-2] DEVE supportare USB Video Class (UVC 1.0 o superiore) se l'interfaccia videocamera si collega tramite la porta host USB.
• [C-1-3] DEVE superare i test CTS della videocamera con una videocamera esterna fisica connesso. I dettagli dei test CTS della fotocamera sono disponibili all'indirizzo source.android.com.
• DEVONO supportare le compressione video come MJPEG per consentire il trasferimento di Stream non codificati di alta qualità (ovvero immagini non elaborate o compresse in modo indipendente flussi di dati).
• POTREBBE supportare più fotocamere.
• POTREBBE supportare la codifica video basata su fotocamera.

Se la codifica video basata su fotocamera è supportata:

• [C-2-1] A simultanea lo stream non codificato / MJPEG (a risoluzione QVGA o superiore) DEVE essere accessibile l'implementazione del dispositivo.

7.5.4. Comportamento dell'API Camera

Android include due pacchetti API per accedere alla fotocamera: il più recente l'API android.hardware.camera2 espongono all'app il controllo della fotocamera di livello inferiore, che includono flussi burst/streaming zero-copy efficienti 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 come dovrebbe essere ancora disponibile per le app da utilizzare. Dispositivo Android le implementazioni DEVONO garantire il supporto continuo dell'API come descritto in in questa sezione e nell'SDK Android.

Tutte le funzionalità comuni nella classe android.hardware.Camera deprecata e il pacchetto android.hardware.camera2 più recente DEVE avere prestazioni equivalenti e qualità 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 lo stesso. Funzionalità che dipendono dalla diversa semantica delle due API non sono necessari per la velocità o la qualità della corrispondenza, ma DEVONO corrispondere il più possibile il più possibile.

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per API correlate alla fotocamera, per tutte le fotocamere disponibili. Implementazioni dei dispositivi:

• [C-0-1] DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per l'anteprima Dati forniti ai callback dell'applicazione quando un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] DEVE essere inoltre nel formato di codifica NV21 quando un'applicazione registra un android.hardware.Camera.PreviewCallback istanza e il sistema chiama il metodo onPreviewFrame() e l'anteprima è YCbCr_420_SP, ovvero i dati nel byte [] passati in onPreviewFrame(). Vale a dire che NV21 DEVE essere l'impostazione predefinita.
• [C-0-3] DEVE supportare il formato YV12 (come indicato dal costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera per entrambi fotocamere anteriori e posteriori per android.hardware.Camera. (l'hardware il codificatore video e la fotocamera possono utilizzare qualsiasi formato pixel nativo, ma il dispositivo l'implementazione DEVE supportare la conversione a YV12.)
• [C-0-4] DEVE supportare android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG come output tramite API android.media.ImageReader per android.hardware.camera2 dispositivi che pubblicizza REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities.
• [C-0-5] DEVE comunque implementare l'API Camera completa. incluse nella documentazione relativa all'SDK Android, indipendentemente dal fatto che il dispositivo include la messa a fuoco automatica hardware o altre funzionalità. Ad esempio, le videocamere che senza messa a fuoco automatica DEVE comunque chiamare qualsiasi registrato android.hardware.Camera.AutoFocusCallback istanza (anche se non ha pertinenza rispetto a una fotocamera senza messa a fuoco automatica. Tieni presente che vale per la visualizzazione frontale fotocamere; ad esempio, anche se la maggior parte delle fotocamere anteriori non supporta della messa a fuoco automatica, i callback API devono essere ancora "falsi" come descritto.
• [C-0-6] DEVE riconoscere e rispettare il nome di ciascun parametro definita come una costante android.hardware.Camera.Parameters e il corso android.hardware.camera2.CaptureRequest. Al contrario, le implementazioni dei dispositivi NON DEVONO rispettare o riconoscere le costanti delle stringhe. passati a un metodo android.hardware.Camera.setParameters() diverso da quelli documentate come costanti su android.hardware.Camera.Parameters. Vale a dire che le implementazioni nei dispositivi DEVONO supportare tutti i parametri standard della fotocamera se l'hardware in uso consente e NON DEVE supportare tipi di parametri personalizzati per la videocamera. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini utilizzando le tecniche di imaging HDR (High Dynamic Range) DEVE supportare il parametro della fotocamera Camera.SCENE_MODE_HDR.
• [C-0-7] DEVE segnalare il livello di assistenza adeguato ai android.info.supportedHardwareLevel come descritto nell'SDK per Android e segnalare la proprietà flag delle funzionalità framework.
• [C-0-8] DEVE dichiarare anche le capacità individuali della fotocamera di android.hardware.camera2 tramite Proprietà android.request.availableCapabilities e dichiarare i flag di funzionalità appropriati; DEVE definire il flag funzionalità se uno dei dispositivi della videocamera collegati supporta la funzionalità.
• [C-0-9] DEVE trasmettere Camera.ACTION_NEW_PICTURE ogni volta che la fotocamera scatta una nuova foto e l'ingresso del l'immagine è stata aggiunta al media store.
• [C-0-10] DEVE trasmettere Camera.ACTION_NEW_VIDEO intent ogni volta che la videocamera registra un nuovo video e l'ingresso del l'immagine è stata aggiunta al media store.
• [C-0-11] DEVE avere tutte le videocamere accessibili tramite il android.hardware.Camera API accessibile anche tramite android.hardware.camera2 tramite Google Cloud CLI o tramite l'API Compute Engine.
• [C-0-12] DEVE garantire che l'aspetto facciale NON sia alterato, ad esempio ma non limitatamente alla modifica della geometria e della tonalità della pelle del viso Rafforzamento della pelle per qualsiasi android.hardware.camera2 oppure android.hardware.Camera tramite Google Cloud CLI o tramite l'API Compute Engine.
• [C-SR-1] Per i dispositivi con più fotocamere RGB in vicino e rivolto nella stessa direzione, è VIVAMENTE CONSIGLIATO di supportare una fotocamera logica che elenca funzionalità CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, composto da tutte le telecamere RGB rivolte in quella direzione come dispositivi secondari fisici.

Se le implementazioni del dispositivo forniscono ad app di terze parti un'API della fotocamera di proprietà, l'utente:

• [C-1-1] DEVE implementare l'API della fotocamera di questo tipo utilizzando android.hardware.camera2 tramite Google Cloud CLI o tramite l'API Compute Engine.
• POTREBBE fornire tag e/o estensioni del fornitore a android.hardware.camera2 tramite Google Cloud CLI o tramite l'API Compute Engine.

7.5.5. Orientamento fotocamera

Se le implementazioni del dispositivo hanno una fotocamera anteriore o posteriore, ad esempio:

• [C-1-1] DEVE essere orientato in modo che la dimensione lunga della fotocamera sia allineata con la dimensione lunga dello schermo. Vale a dire che quando il dispositivo è in posizione orizzontale le videocamere DEVONO acquisire le immagini con l'orientamento orizzontale. Questo si applica indipendentemente dall'orientamento naturale del dispositivo. vale a dire che si applica dispositivi principali con orientamento orizzontale e verticale.

I dispositivi che soddisfano tutti i seguenti criteri sono esenti dal requisito di cui sopra:

• Il dispositivo implementa schermi a geometria variabile, ad esempio pieghevoli o incernierati vengono visualizzati i video.
• Quando lo stato di piegatura o cerniera di un dispositivo cambia, il dispositivo passa da orientamenti da principale verticale a orizzontale-primario (o viceversa).

7.6 Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

Implementazioni dei dispositivi:

• [C-0-1] DEVE includere un elemento Gestione dei download che le applicazioni POSSONO usare per scaricare file di dati e DEVONO essere in grado di scarica singoli file di almeno 100 MB per impostazione predefinita "cache" in ogni località.

7.6.2. Archiviazione condivisa delle applicazioni

Implementazioni dei dispositivi:

• [C-0-1] DEVE offrire spazio di archiviazione che sia condiviso dalle applicazioni, spesso definito anche come come "unità di archiviazione esterna condivisa", "spazio di archiviazione condiviso dell'applicazione" o dal programma Linux percorso "/sdcard" su cui è montato.
• [C-0-2] DEVE essere configurato con l'archiviazione condivisa montata per impostazione predefinita, in altre "pronte all'uso", a prescindere dal fatto che lo spazio di archiviazione sia implementato o meno un componente di archiviazione interna o un supporto di archiviazione rimovibile (ad esempio, Secure slot per scheda digitale).
• [C-0-3] DEVE montare l'archivio condiviso dell'applicazione direttamente sul percorso Linux sdcard o includi un link simbolico Linux da sdcard al montaggio effettivo punto di accesso.
• [C-0-4] DEVE attivare archiviazione con ambito per impostazione predefinita app che hanno come target il livello API 29 o versioni successive, tranne che nei seguenti casi:
  • Quando l'app ha richiesto android:requestLegacyExternalStorage="true" nel file manifest.
• [C-0-5] DEVE oscurare i metadati di posizione, come i tag GPS Exif, memorizzati file multimediali quando tali file sono accessibili tramite MediaStore, tranne quando l'app per le chiamate dispone dell'autorizzazione ACCESS_MEDIA_LOCATION.

Le implementazioni dei dispositivi POSSONO soddisfare i requisiti di cui sopra utilizzando uno dei seguenti:

• Dispositivo di archiviazione rimovibile accessibile all'utente, ad esempio uno slot per schede SD (Secure Digital).
• Una parte dello spazio di archiviazione interno (non rimovibile) implementato nel Android Open Source Project (AOSP).

Se le implementazioni del dispositivo utilizzano l'archiviazione rimovibile per soddisfare quanto sopra requisiti, devono:

• [C-1-1] DEVE implementare un avviso popup o un popup all'interfaccia utente che avvisa l'utente se nello slot non è inserito alcun supporto di archiviazione.
• [C-1-2] DEVE includere un supporto di archiviazione in formato FAT (ad esempio, scheda SD) oppure mostrare sulla confezione e altro materiale disponibile al momento dell'acquisto che lo spazio di archiviazione medium deve essere acquistato separatamente.

Se le implementazioni del dispositivo utilizzano una parte dello spazio di archiviazione non rimovibile per soddisfare i requisiti di cui sopra:

• DEVI usare l'implementazione AOSP dell'applicazione interna condivisa archiviazione.
• POTREBBE condividere lo spazio di archiviazione con i dati privati dell'applicazione.

Se le implementazioni del dispositivo hanno una porta USB con supporto della modalità periferica USB, l'utente:

• [C-3-1] DEVE fornire un meccanismo per accedere ai dati nell'applicazione spazio di archiviazione condiviso da un computer host.
• DEVONO esporre in modo trasparente i contenuti di entrambi i percorsi di archiviazione Servizio di scansione di contenuti multimediali di Android e android.provider.MediaStore.
• POSSONO utilizzare un archivio di massa USB, ma DEVONO usare Media Transfer Protocol per soddisfare questo requisito.

Se le implementazioni del dispositivo hanno una porta USB con modalità periferica USB e supporto Media Transfer Protocol:

• DEVE essere compatibile con l'host Android MTP di riferimento, Trasferimento di file Android.
• DEVI segnalare una classe di dispositivi USB pari a 0x00.
• DEVI segnalare un nome di interfaccia USB di "MTP".

7.6.3. Spazio di archiviazione utilizzabile

Se si prevede che il dispositivo sia mobile a differenza della televisione, Le implementazioni sui dispositivi sono:

• [C-SR-1] VIVAMENTE CONSIGLIATO di implementare lo spazio di archiviazione una posizione stabile a lungo termine, poiché scollegarli accidentalmente può causare la perdita/il danneggiamento dei dati.

Se la porta del dispositivo di archiviazione rimovibile si trova in un luogo stabile a lungo termine, ad esempio all'interno del vano batterie o di un'altra copertura protettiva, Le implementazioni sui dispositivi sono:

• [C-SR-2] VIVAMENTE CONSIGLIATA di implementare spazio di archiviazione utilizzabile.

7.7 USB

Se le implementazioni dei dispositivi hanno una porta USB:

• DEVE supportare la modalità periferica USB e la modalità host USB.
• DEVE supportare la disattivazione della segnalazione dati tramite USB.

7.7.1. Modalità periferica USB

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità periferica:

• [C-1-1] La porta DEVE essere collegabile a un host USB che dispone di un porta USB di tipo A o C.
• [C-1-2] DEVE segnalare il valore corretto di iSerialNumber nello standard USB descrittore del dispositivo tramite android.os.Build.SERIAL.
• [C-1-3] DEVE rilevare caricabatteria da 1,5 A e 3,0 A in base alla resistenza di tipo C standard e DEVONO rilevare cambiamenti nella pubblicità se supportano USB Type-C.
• [C-SR-1] La porta DEVE usare il fattore di forma USB micro-B, micro-AB o Tipo-C. I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare queste requisiti per poter eseguire l'upgrade alle future release della piattaforma.
• [C-SR-2] La porta DEVE essere situata nella parte inferiore del dispositivo (in base all'orientamento naturale) o attiva la rotazione dello schermo del software per tutte le app (inclusa la schermata Home), in modo che il display possa spostarsi correttamente Il dispositivo è orientato con la porta in basso. Android nuovi ed esistenti dispositivi sono CONSIGLIATI VIVAMENTE per soddisfare questi requisiti, pertanto poter eseguire l'upgrade a release future della piattaforma.
• [C-SR-3] DOVREBBE implementare il supporto per assorbire 1,5 A di corrente durante il cicalino HS e il traffico come specificato nella Specifica relativa alla ricarica della batteria USB, revisione 1.2. I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare queste requisiti per poter eseguire l'upgrade alle future release della piattaforma.
• [C-SR-4] VIVAMENTE CONSIGLIATO di non supportare le proprietà metodi di ricarica che modificano la tensione Vbus oltre i livelli predefiniti o alterano ruoli sink/source come tali potrebbero causare problemi di interoperabilità con caricabatterie o dispositivi che supportano i metodi standard USB Power Delivery. Mentre viene definita "FORTEMENTE CONSIGLIATA". Nelle versioni future di Android potrebbe RICHIEDERE tutti i dispositivi di tipo C per supportare l'interoperabilità completa con caricabatterie di tipo C.
• [C-SR-5] VIVAMENTE CONSIGLIATO per supportare Power Delivery per i dati e il ruolo di alimentazione quando supportano le modalità USB di tipo C e host USB.
• DOVREBBE supportare Power Delivery per la ricarica ad alta tensione e il supporto per Modalità alternative come display out.
• DEVI implementare l'API e la specifica Android Open Accessory (AOA) come documentato nella documentazione dell'SDK Android.

Se le implementazioni del dispositivo includono una porta USB e implementano l'AOA specifica, questi:

• [C-2-1] DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.accessory
• [C-2-2] La classe di archiviazione di massa USB DEVE includere la stringa "android" al fine della descrizione dell'interfaccia iInterface stringa dell'archivio di massa USB

7.7.2. Modalità host USB

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host:

• [C-1-1] DEVE implementare l'API Android USB Host come documentato nel SDK Android e DEVONO dichiarare il supporto per la funzionalità hardware android.hardware.usb.host
• [C-1-2] DEVE implementare il supporto per collegare periferiche USB standard, in altre parole, DEVONO:
  • Avere una porta di tipo C sul dispositivo o spedire cavi che ne permettono l'adattamento a una porta USB Type-C standard (dispositivo USB Type-C).
  • Avere un dispositivo di tipo A integrato o disporre di cavi adatti per l'adattamento a una porta USB tipo A standard.
  • Avere una porta micro-AB sul dispositivo, che DEVE essere spedita con un cavo di adattamento a una porta standard di tipo A.
• [C-1-3] NON DEVE essere fornito con un adattatore che converte da USB di tipo A o porte micro-AB a una porta di tipo C (presa).
• [C-SR-1] È VIVAMENTE CONSIGLIATO di implementare le Classe audio USB come documentato nella documentazione dell'SDK Android.
• DOVREBBE supportare la ricarica del dispositivo periferico USB connesso mentre si trova nell'host ; che pubblicizzi una corrente di fonte di almeno 1,5 A, come specificato nella sezione Parametri di terminazione Specifiche per il cavo e il connettore USB Type-C, revisione 1.2 per USB Type-C o utilizzando l'intervallo della corrente di uscita CDP (Charging Downstream Port) come specificato nel Specifiche relative alla ricarica della batteria USB, revisione 1.2 per i connettori Micro-AB.
• DOVREBBE implementare e supportare gli standard USB Type-C.

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host e classe audio:

• [C-2-1] DEVE supportare la classe USB HID.
• [C-2-2] DEVE supportare il rilevamento e la mappatura dei seguenti dati HID specificati nelle Tabelle di utilizzo HID USB e la Richiesta di utilizzo del comando vocale al KeyEvent costanti come di seguito:
  • Pagina utilizzo (0xC) ID utilizzo (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Pagina di utilizzo (0xC) ID utilizzo (0x0E9): KEYCODE_VOLUME_UP
  • ID di utilizzo della pagina di utilizzo (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • Pagina di utilizzo (0xC) ID utilizzo (0x0CF): KEYCODE_VOICE_ASSIST

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host e il framework Storage Access Framework (SAF), che:

• [C-3-1] DEVE riconoscere eventuali dispositivi MTP (Media Transfer Protocol) collegati da remoto dispositivi e rendi i relativi contenuti accessibili tramite ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT intent. .

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host e di tipo C:

• [C-4-1] DEVE implementare la funzionalità Dual Role Port come definita dalla Specifiche di tipo C (sezione 4.5.1.3.3). Per Dual porte dei ruoli: nei dispositivi dotati di jack audio da 3, 5 mm, (modalità host) POTREBBE essere disattivato per impostazione predefinita, ma DEVE essere possibile per per abilitarla.
• [C-SR-2] VIVAMENTE CONSIGLIATO per il supporto di DisplayPort, DOVREBBE supportare il supporto USB con velocità di trasferimento dei dati SuperSpeed e CONSIGLIATI VIVAMENTE per supportare la funzionalità Power Delivery per lo scambio di ruoli nei dati e nell'alimentazione.
• [C-SR-3] CONSIGLIATO VIVAMENTE di NON supportare la modalità accessorio per adattatore audio descritto nell'Appendice A delle Specifiche per il cavo e il connettore USB Type-C, revisione 1.2.
• DOVREBBE implementare il modello Try.* più appropriato per i fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DOVREBBE implementare la funzione modello trial.SNK.

7.8 Audio

7.8.1. Microfono

Se le implementazioni dei dispositivi includono un microfono, questi:

• [C-1-1] DEVE segnalare la costante della funzionalità android.hardware.microphone.
• [C-1-2] DEVE soddisfare i requisiti di registrazione audio in sezione 5.4.
• [C-1-3] DEVE soddisfare i requisiti di latenza audio in sezione 5.6.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare la registrazione quasi a ultrasuoni come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono un microfono:

• [C-2-1] NON DEVE segnalare la costante della funzionalità android.hardware.microphone.
• [C-2-2] DEVE implementare l'API Registrazione audio almeno in modalità autonoma, in base alle sezione 7.

7.8.2. Uscita audio

Se le implementazioni del dispositivo includono un altoparlante o un'uscita audio/multimediale porta per una periferica di uscita audio come un jack audio da 3,5 mm a 4 conduttori o Porta in modalità host USB che utilizza la classe audio USB:

• [C-1-1] DEVE segnalare la costante della funzionalità android.hardware.audio.output.
• [C-1-2] DEVE soddisfare i requisiti per la riproduzione audio in sezione 5.5.
• [C-1-3] DEVE soddisfare i requisiti di latenza audio in sezione 5.6.
• [C-SR-1] VIVAMENTE CONSIGLIATA per la riproduzione in quasi a ultrasuoni, come descritto nella sezione 7.8.3.

Se le implementazioni del dispositivo non includono un altoparlante o una porta di uscita audio:

• [C-2-1] NON DEVE segnalare la funzionalità android.hardware.audio.output.
• [C-2-2] DEVE implementare le API relative all'output audio almeno in modalità autonoma.

Ai fini di questa sezione, viene utilizzata una "porta di output" è un un'interfaccia fisica ad esempio un jack audio da 3, 5 mm, una porta in modalità host USB o HDMI con classe audio USB. Supporto per l'uscita audio tramite protocolli basati su radio come Bluetooth, Una rete Wi-Fi o cellulare non è idonea per includere una "porta di uscita".

7.8.2.1. Porte audio analogiche

Per essere compatibile con auricolari e altri accessori audio utilizzando il connettore audio da 3,5 mm su tutto l'ecosistema Android, se le implementazioni includono una o più porte audio analogiche, queste:

• [C-SR-1] CONSIGLIATO VIVAMENTE di includere almeno uno dei Porta audio da 3,5 mm a 4 conduttori.

Se le implementazioni del dispositivo hanno un jack audio da 3,5 mm a 4 conduttori, questi:

• [C-1-1] DEVE supportare la riproduzione audio su cuffie e auricolari stereo con un microfono.
• [C-1-2] DEVE supportare i connettori audio TRRS con l'ordine di pin-out CTIA.
• [C-1-3] DEVE supportare il rilevamento e la mappatura ai codici chiave per dopo 3 intervalli di impedenza equivalente tra il microfono e la terra cavi 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 su un inserto, ma solo dopo che tutti i contatti sul connettore toccano i segmenti pertinenti sul jack.
• [C-1-5] DEVE essere in grado di pilotare almeno 150 mV ± 10% della tensione di uscita un'impedenza dell'altoparlante da 32 ohm.
• [C-1-6] DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V ~ 2,9 V.
• [C-1-7] DEVE rilevare e mappare il codice chiave per le seguenti intervallo di impedenza equivalente tra il microfono e i conduttori di terra sulla presa audio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR-2] È VIVAMENTE CONSIGLIATO il supporto di prese audio con OMTP PIN-out.
• [C-SR-3] È VIVAMENTE CONSIGLIATO per il supporto della registrazione audio da stereo cuffie con microfono.

Se i dispositivi hanno un jack audio da 3,5 mm a 4 conduttori e supportano un microfono e trasmetti l'evento android.intent.action.HEADSET_PLUG con valore extra impostato su 1:

• [C-2-1] DEVE supportare il rilevamento del microfono sull'audio collegato accessorio.

7.8.2.2. Porte audio digitali

Consulta la Sezione 2.2.1 per i requisiti specifici del dispositivo.

7.8.3. Quasi a ultrasuoni

L'audio a ultrasuoni è la banda da 18,5 kHz a 20 kHz.

Implementazioni dei dispositivi:

• DEVE segnalare correttamente il supporto di funzionalità audio quasi a ultrasuoni tramite AudioManager.getProperty come segue:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND è "true", i seguenti requisiti DEVONO essere soddisfatti VOICE_RECOGNITION e UNPROCESSED sorgenti audio:

• [C-1-1] La risposta di potenza media del microfono nella banda da 18,5 kHz a 20 kHz DEVE essere non più di 15 dB al di sotto della risposta a 2 kHz.
• [C-1-2] Rapporto tra segnale e rumore non ponderato del microfono tra 18,5 kHz e 20 kHz per un tono da 19 kHz a -26 dBFS DEVE essere non inferiore a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND è "true":

• [C-2-1] La risposta media dell'altoparlante nella banda 18,5 kHz - 20 kHz DEVE essere non inferiore a 40 dB al di sotto della risposta a 2 kHz.

7.8.4. Integrità del segnale

Implementazioni dei dispositivi:

• DOVREBBE fornire un percorso del segnale audio privo di glitch per entrambi gli input e stream di output sui dispositivi portatili, come definito da "zero glitch" misurata durante un test di un minuto per percorso. Esegui il test con OboeTester "Test glitch automatico".

Il test richiede un dongle di loopback audio, utilizzato direttamente in un jack da 3,5 mm e/o in combinazione con un adattatore da USB-C a 3,5 mm. Tutte le porte di uscita audio DEVONO essere testate.

OboeTester al momento supporta i percorsi AAudio, quindi le seguenti combinazioni DEVONO essere testate per rilevare eventuali glitch usando AAudio:

Modalità prestazioni	Condivisione	Frequenza di campionamento in uscita	Occasionalmente	Margini di uscita
BASSO_LATEENZA	ESCLUSIVA	NON SPECIFICATO	1	2
BASSO_LATEENZA	ESCLUSIVA	NON SPECIFICATO	2	1
BASSO_LATEENZA	CONDIVISO	NON SPECIFICATO	1	2
BASSO_LATEENZA	CONDIVISO	NON SPECIFICATO	2	1
NESSUNO	CONDIVISO	48000	1	2
NESSUNO	CONDIVISO	48000	2	1
NESSUNO	CONDIVISO	44100	1	2
NESSUNO	CONDIVISO	44100	2	1
NESSUNO	CONDIVISO	16000	1	2
NESSUNO	CONDIVISO	16000	2	1

Uno stream affidabile DEVE soddisfare i seguenti criteri per il rapporto segnale-rumore rapporto (SNR) e distorsione armonica totale (THD) per il seno a 2000 Hz.

Trasduttore	THD	SNR (SNR)
altoparlante principale integrato, misurato utilizzando un microfono esterno di riferimento	< 3,0%	>= 50 dB
microfono principale integrato, misurato utilizzando un altoparlante esterno di riferimento	< 3,0%	>= 50 dB
jack analogici da 3,5 mm integrati, testato con adattatore di loopback	< 1%	>= 60 dB
Adattatori USB forniti con lo smartphone, testati utilizzando l'adattatore di loopback	< 1,0%	>= 60 dB

7.9 Realtà virtuale

Android include API e strutture per creare la "realtà virtuale" (VR) applicazioni, incluse esperienze VR di alta qualità su dispositivi mobili. Dispositivo le implementazioni DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

7.9.1. Modalità realtà virtuale

Android include il supporto per Modalità VR, una funzionalità che gestisce il rendering stereoscopico delle notifiche e disattiva componenti UI di sistema monoculare mentre un'applicazione VR è incentrata sull'utente.

7.9.2. Modalità realtà virtuale - Alte prestazioni

Se le implementazioni dei dispositivi supportano la modalità VR:

• [C-1-1] DEVE avere almeno 2 core fisici.
• [C-1-2] DEVE dichiarare la funzionalità android.hardware.vr.high_performance.
• [C-1-3] DEVE supportare la modalità di prestazioni sostenute.
• [C-1-4] DEVE supportare OpenGL ES 3.2.
• [C-1-5] DEVE supportare android.hardware.vulkan.level 0.
• DOVREBBE supportare android.hardware.vulkan.level 1 o versioni successive.
• [C-1-6] DEVE implementare EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace, ed esporre le estensioni 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 esponi le estensioni nell'elenco delle estensioni GL disponibili.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di implementare GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, ed esponi le estensioni nell'elenco delle estensioni GL disponibili.
• [C-SR-2] CONSIGLIATE VIVAMENTE per il supporto di Vulkan 1.1.
• [C-SR-3] È VIVAMENTE CONSIGLIATO di implementare VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, e lo esponi nell'elenco delle estensioni Vulkan disponibili.
• [C-SR-4] CONSIGLIATO VIVAMENTE di esporre almeno una famiglia di code Vulkan in cui flags contengono sia VK_QUEUE_GRAPHICS_BIT che VK_QUEUE_COMPUTE_BIT, e queueCount è almeno 2.
• [C-1-7] La GPU e il display DEVONO essere in grado di sincronizzare l'accesso all'interfaccia front buffer in modo tale che il rendering a occhio alternato dei contenuti VR a 60 fps con due i contesti di rendering saranno mostrati senza artefatti di strappo visibili.
• [C-1-9] DEVE implementare il supporto per AHardwareBuffer flag AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT come descritto nell'NDK.
• [C-1-10] DEVE implementare il supporto per AHardwareBuffer s con qualsiasi combinazione dei flag di utilizzo AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT per almeno i seguenti formati: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] È VIVAMENTE CONSIGLIATO per supportare l'allocazione di AHardwareBuffer con più di uno strato, flag e formati specificati in C-1-10.
• [C-1-11] DEVE supportare la decodifica H.264 di almeno 3840 x 2160 a 30 f/s, compresso a una media di 40 Mbps (equivalente a 4 istanze 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 compressa 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 restituiscono valori precisi per la temperatura cutanea.
• [C-1-14] DEVE avere uno schermo incorporato e la sua risoluzione DEVE essere almeno 1920 x 1080.
• [C-SR-6] È VIVAMENTE CONSIGLIATO avere una risoluzione del display di almeno 2560 x 1440.
• [C-1-15] Il display DEVE aggiornarsi di almeno 60 Hz in modalità VR.
• [C-1-17] Il display DEVE supportare una modalità a bassa persistenza con ≤ 5 millisecondi persistenza; la persistenza è definita come la quantità di tempo che emette luce da un pixel.
• [C-1-18] DEVE supportare Bluetooth 4.2 e Bluetooth LE estensione lunghezza dati sezione 7.4.3.
• [C-1-19] DEVE supportare e segnalare correttamente Tipo di canale diretto per tutti i seguenti tipi di sensori predefiniti:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] CONSIGLIATE VIVAMENTE per il supporto TYPE_HARDWARE_BUFFER tipo di canale diretto per tutti i tipi di canale diretto elencati sopra.
• [C-1-21] DEVE soddisfare i requisiti di giroscopio, accelerometro e magnetometro requisiti per android.hardware.hifi_sensors, come specificato in sezione 7.3.9.
• [C-SR-8] CONSIGLIATE VIVAMENTE per il supporto dei Funzionalità android.hardware.sensor.hifi_sensors.
• [C-1-22] DEVE avere una latenza end-to-end tra movimenti e fotoni non superiore a 28 millisecondi.
• [C-SR-9] È VIVAMENTE CONSIGLIATO avere una latenza end-to-end tra movimenti e fotoni non superiore a 20 millisecondi.
• [C-1-23] DEVE avere un rapporto primo fotogramma, ossia il rapporto tra luminosità dei pixel sul primo frame dopo una transizione dal nero al il bianco e la luminosità dei pixel bianchi in stato stabile, di almeno l'85%.
• [C-SR-10] È VIVAMENTE CONSIGLIATO avere una percentuale di primo fotogramma di almeno il 90%.
• POTREBBE fornire un core esclusivo al primo piano e POTREBBE supportare l'API Process.getExclusiveCores per restituire Il numero di core CPU esclusivi del primo piano un'applicazione.

Se è supportato un core esclusivo, il core:

• [C-2-1] Non DEVE consentire l'esecuzione di altri processi dello spazio utente al suo interno (ad eccezione dei driver di dispositivo usati dall'applicazione), ma POTREBBE consentire alcuni kernel processi da eseguire in base alle esigenze.

7.10. Tecnologia aptica

7.11. Classe di rendimento dei media

La classe di prestazioni multimediali dell'implementazione del dispositivo può essere ricavata da l'API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Requisiti per la classe di rendimento multimediale sono definite per ogni versione di Android a partire da R (versione 30). Il valore speciale 0 indica che il dispositivo non è un classe di prestazione multimediale.

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

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

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

• [C-1-3] DEVE soddisfare tutti i requisiti della "Classe di rendimento multimediale" descritto nella sezione 2.2.7.

In altre parole, la classe di rendimento dei media in Android T è definita solo per dispositivi portatili con versione T, S o R.

Consulta la sezione 2.2.7 per informazioni specifiche sul dispositivo i tuoi requisiti.

8. Prestazioni e potenza

Alcuni criteri minimi per le prestazioni e l'alimentazione sono fondamentali per l'esperienza utente e influire sulle ipotesi di base che gli sviluppatori avrebbero quando sviluppano dell'app.

8.1. Coerenza dell'esperienza utente

È possibile fornire all'utente finale un'interfaccia utente semplice se esistono requisiti minimi per garantire una frequenza frame e tempi di risposta coerenti per applicazioni e giochi. Le implementazioni dei dispositivi, a seconda del tipo, POTREBBE avere requisiti misurabili per la latenza dell'interfaccia utente e l'attività passaggio come descritto nella sezione 2.

8.2. Prestazioni accesso file I/O

Fornire una base comune per prestazioni di accesso ai file coerenti sul archiviazione privata dei dati delle applicazioni (/data partizione) consente agli sviluppatori di app creare un'aspettativa adeguata che aiuterebbe la progettazione del software. Dispositivo implementazioni, a seconda del tipo di dispositivo, POTREBBERO avere determinati requisiti descritta nella sezione 2 per le seguenti e scrivere le operazioni:

• Prestazioni di scrittura sequenziale. Misurato scrivendo un file da 256 MB utilizzando Buffer di scrittura da 10 MB.
• Prestazioni di scrittura casuale. Misurato scrivendo un file da 256 MB con 4 kB nel buffer di scrittura.
• Prestazioni di lettura sequenziale. Misurato leggendo un file da 256 MB con Buffer di scrittura da 10 MB.
• Prestazioni di lettura casuale. Misurato leggendo un file da 256 MB con 4 kB nel buffer di scrittura.

8.3. Modalità di risparmio energetico

Se le implementazioni dei dispositivi includono funzionalità per migliorare la gestione dell'alimentazione dei dispositivi incluse in AOSP (ad es. App Standby Bucket, Doze) o estendono le funzionalità applicare limitazioni più forti rispetto al bucket di standby per le app RESTRICTED:

• [C-1-1] NON DEVE discostarsi dall'implementazione AOSP per l'attivazione, la manutenzione, gli algoritmi di riattivazione e l'uso di impostazioni di sistema globali Configurazione dispositivo di standby delle app e di risparmio energetico.
• [C-1-2] NON DEVE discostarsi dall'implementazione AOSP per l'uso o DeviceConfig per gestire la limitazione di job, allarmi per le app in ogni bucket per l'utilizzo in standby delle app.
• [C-1-3] NON DEVE deviare dall'implementazione AOSP per il numero Bucket standby delle app utilizzata per lo standby delle app.
• [C-1-4] DEVE implementare i bucket standby delle app e Sospensione come descritto in Gestione alimentazione.
• [C-1-5] DEVE restituire true per PowerManager.isPowerSaveMode() quando il dispositivo è in modalità di risparmio energetico.
• [C-1-6] DEVE fornire l'autorizzazione all'utente per visualizzare tutte le app esenti dalle modalità di risparmio energetico di standby delle app e sospensione o da qualsiasi ottimizzazione della batteria e DEVE implementare ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS di chiedere all'utente di consentire a un'app di ignorare la batteria ottimizzazioni.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di fornire l'invito all'utente per attivare e disattivare la funzione di risparmio energetico.
• [C-SR-2] È VIVAMENTE CONSIGLIATO di fornire all'utente l'invito per visualizzare App esenti dalle modalità di risparmio energetico di Standby delle app e Sospensione.

Se le implementazioni dei dispositivi estendono le funzionalità di gestione dell'alimentazione incluse in AOSP e tale estensione applica restrizioni più rigorose rispetto a il bucket in standby dell'app Rare, consulta la sezione 3.5.1.

Oltre alle modalità di risparmio energetico, le implementazioni dei dispositivi Android MAGGIO implementare uno o tutti i 4 stati di potenza a riposo come definiti dall'Advanced Configurazione e interfaccia di alimentazione (ACPI).

Se le implementazioni del dispositivo implementano gli stati di alimentazione S4 come definito dalle ACPI:

• [C-1-1] DEVE entrare in questo stato solo dopo che l'utente ha intrapreso un'azione esplicita per mettere il dispositivo in stato di inattività (ad esempio chiudendo un coperchio che si trova fisicamente parte del dispositivo oppure lo spegnimento di un veicolo o di un televisore) e prima che l'utente riattiva il dispositivo (ad esempio aprendo il coperchio o ruotando il veicolo o la televisione di nuovo).

Se le implementazioni del dispositivo implementano gli stati di alimentazione S3 come definito dalle ACPI:

• [C-2-1] DEVE soddisfare i requisiti C-1-1 di cui sopra, oppure DEVE entrare nello stato S3 solo quando la terza parte le applicazioni non hanno bisogno delle risorse di sistema (ad esempio, lo schermo, CPU).

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

  Ad esempio, mentre le applicazioni di terze parti chiedono di mantenere lo schermo fino a FLAG_KEEP_SCREEN_ON o mantieni la CPU in esecuzione PARTIAL_WAKE_LOCK, il dispositivo NON DEVE entrare nello stato S3 a meno che, come descritto in C-1-1, l'utente ha intrapreso un'azione esplicita per inserire il dispositivo in un non attivo. Al contrario, quando un'attività che app di terze parti implementare tramite JobScheduler sia attivato o Firebase Cloud Messaging pubblicati su app di terze parti, il dispositivo DEVE uscire dallo stato S3 a meno che l'utente ha messo il dispositivo in stato non attivo. Non sono esaustivi di esempio e AOSP implementa ampi segnali di riattivazione che innescano un risveglio in questo stato.

8.4. Contabilità consumo energetico

Una contabilità e un report più accurati del consumo energetico forniscono sviluppatore di app sia gli incentivi che gli strumenti per ottimizzare il consumo di energia pattern dell'applicazione.

Implementazioni dei dispositivi:

• [C-SR-1] VIVAMENTE CONSIGLIATO per fornire un profilo di potenza per componente che definisce il valore del consumo attuale di ciascun componente hardware e il consumo approssimativo della batteria causato componenti nel tempo, come documentato nel sito dell'Android Open Source Project.
• [C-SR-2] VIVAMENTE CONSIGLIATO per indicare tutti i valori di consumo energetico in milliampere ore (mAh).
• [C-SR-3] VIVAMENTE CONSIGLIATO di segnalare il consumo energetico della CPU per ogni UID di processo. Android Open Source Project soddisfa il requisito tramite le implementazione del modulo kernel uid_cputime.
• [C-SR-4] VIVAMENTE CONSIGLIATO di rendere disponibile questo consumo di energia tramite adb shell dumpsys batterystats il comando shell allo sviluppatore dell'app.
• DOVREBBERO essere attribuite al componente hardware stesso se non è in grado di attribuire il consumo di energia del componente hardware a un'applicazione.

8.5. Prestazioni costanti

Le prestazioni possono variare notevolmente per le app a lunga esecuzione ad alte prestazioni, a causa delle altre app in esecuzione in background o della limitazione della CPU a causa dei limiti di temperatura. Android include interfacce programmatiche che, quando il dispositivo sia in grado, l'applicazione in primo piano può richiedere che di ottimizzare l'allocazione delle risorse per far fronte a tali fluttuazioni.

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare in modo preciso il supporto della modalità di rendimento sostenuto. tramite PowerManager.isSustainedPerformanceModeSupported() API.

• DEVE supportare la modalità di rendimento sostenuto.

Se le implementazioni dei dispositivi registrano il supporto della modalità Rendimento sostenuto:

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

Se le implementazioni del dispositivo includono due o più core CPU:

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

Se le implementazioni del dispositivo supportano la prenotazione di un core esclusivo per il un'applicazione in primo piano, questi:

• [C-2-1] DEVE segnalare tramite Process.getExclusiveCores() Metodo API: i numeri ID dei core esclusivi che possono essere prenotati dall'applicazione in primo piano.
• [C-2-2] Non DEVE consentire alcun processo dello spazio utente, ad eccezione dei driver di dispositivo utilizzata dall'applicazione per essere eseguita sui core esclusivi, ma POTREBBE consentire alcune dei processi kernel in modo che vengano eseguiti se necessario.

Se le implementazioni del dispositivo non supportano un core esclusivo:

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

9. Compatibilità del modello di sicurezza

Implementazioni dei dispositivi:

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

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

Se le implementazioni dei dispositivi dichiarano android.hardware.security.model.compatible questa funzionalità:

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

9.1. Autorizzazioni

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare il modello di autorizzazioni Android e il modello di ruoli Android come definito nella documentazione per gli sviluppatori di Android. In particolare, DEVE applicare in modo forzato ogni autorizzazione e ruolo definiti come descritto in documentazione relativa all'SDK; nessuna autorizzazione e nessun ruolo può essere omesso, alterato o ignorato.

• POTREBBE aggiungere ulteriori autorizzazioni, purché le nuove stringhe degli ID autorizzazione non sono nello spazio dei nomi android.\*.

• [C-0-2] Autorizzazioni con protectionLevel di PROTECTION_FLAG_PRIVILEGED DEVE essere concessa solo alle app preinstallate nei percorsi con privilegi del immagine di sistema (nonché file APEX) ed essere all'interno del sottoinsieme delle autorizzazioni incluse nella lista consentita per ogni app. L'implementazione AOSP soddisfa questo requisito leggendo e rispettando le autorizzazioni incluse nella lista consentita per ogni app dai file etc/permissions/ e utilizzando il percorso system/priv-app come percorso con privilegi elevati.

Le autorizzazioni con un livello di protezione pericoloso sono autorizzazioni di runtime. Candidature con targetSdkVersion > in fase di runtime.

Implementazioni dei dispositivi:

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

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

  • Vengono installati al momento della spedizione del dispositivo E

  • Il consenso dell'utente può essere ottenuto prima che l'applicazione usa l'autorizzazione,

    OPPURE

  • Le autorizzazioni di runtime sono concesse In base alle norme predefinite di concessione di autorizzazioni o per ricoprire un ruolo di piattaforma.

• [C-0-6] DEVE concedere l'autorizzazione android.permission.RECOVER_KEYSTORE solo per le app di sistema che registrano un Recovery Agent adeguatamente protetto. R l'agente di ripristino adeguatamente protetto è definito come un agente software sul dispositivo che si sincronizza con uno spazio di archiviazione remoto esterno al dispositivo, dotato di un hardware sicuro con protezione equivalente o più forte di quella che è descritti in Servizio Google Cloud Key Vault per prevenire attacchi di forza bruta al fattore di conoscenza della schermata di blocco.

Implementazioni dei dispositivi:

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

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

In particolare, le implementazioni dei dispositivi:

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

Le uniche eccezioni alle proprietà relative all'autorizzazione di accesso alla posizione per Android riportate sopra riguardano App che non accedono alla posizione per ricavarne o identificare la posizione dell'utente. nello specifico:

• Quando le app contengono l'autorizzazione RADIO_SCAN_WITHOUT_LOCATION.
• Ai fini della configurazione e dell'impostazione dei dispositivi, in cui le app di sistema contengono i Autorizzazione NETWORK_SETTINGS o NETWORK_SETUP_WIZARD.

Le autorizzazioni possono essere contrassegnate come limitate, che ne alterano il comportamento.

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

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

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

• [C-0-12] NON DEVE fornire funzioni o API personalizzate per bypassare limitazioni relative alle autorizzazioni definite in setPermissionPolicy e setPermissionGrantState su quelle di livello inferiore.

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

• [C-0-14] DEVE assegnare ruoli solo ad applicazioni con funzionalità che devono soddisfare i requisiti dei ruoli.

• [C-0-15] Non DEVE definire ruoli che siano duplicati o funzionalità soprainsieme ruoli definiti dalla piattaforma.

Se i dispositivi segnalano android.software.managed_users, questi:

• [C-1-1] NON DEVE avere le seguenti autorizzazioni concesse automaticamente dal amministratore:
  • Località (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Fotocamera (CAMERA)
  • Microfono (RECORD_AUDIO)
  • Sensore del corpo (BODY_SENSORS)
  • Attività fisica (ACTIVITY_RECOGNITION)

Se le implementazioni del dispositivo permettono all'utente di scegliere quali app disegna sopra altre app con un'attività che gestisce ACTION_MANAGE_OVERLAY_PERMISSION l'intento:

• [C-2-1] DEVE garantire che tutte le attività con filtri per intent per il parametro ACTION_MANAGE_OVERLAY_PERMISSION hanno la stessa schermata UI, indipendentemente dall'app iniziale o da qualsiasi le informazioni che fornisce.

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

• [C-3-1] DEVE mostrare un disclaimer durante la configurazione del dispositivo completamente gestito (configurazione del proprietario del dispositivo) in cui si afferma che l'amministratore IT avrà la possibilità di consentire alle app di controllare le impostazioni dello smartphone, tra cui microfono, fotocamera e posizione, con opzioni che consentono all'utente di continuare la configurazione o uscire dalla configurazione A MENO CHE amministratore ha disattivato il controllo delle autorizzazioni sul dispositivo.

Se le implementazioni dei dispositivi preinstallano eventuali pacchetti contenenti i ruoli System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence o System Visual Intelligence, i pacchetti:

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

9.2. UID e isolamento dei processi

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare l'applicazione per Android modello sandbox, in cui ogni applicazione viene eseguita come un UID Unixstyle univoco. e in un processo separato.
• [C-0-2] DEVE supportare l'esecuzione di più applicazioni dello stesso ID utente Linux, a condizione che le applicazioni siano firmate correttamente. e costruito, come definito Informazioni di riferimento su sicurezza e autorizzazioni.

9.3. Autorizzazioni del file system

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare l'accesso ai file Android di autorizzazioni come definito Informazioni di riferimento su sicurezza e autorizzazioni.

9.4 Ambienti di esecuzione alternativi

Le implementazioni dei dispositivi DEVONO mantenere la coerenza della sicurezza di Android e di autorizzazione, anche se includono ambienti di runtime che eseguono applicazioni che usano altri software o tecnologie rispetto a Dalvik Executable Formato o codice nativo. In altre parole:

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

• [C-0-2] NON DEVE essere concesso l'accesso alle risorse ai runtime alternativi protetta da autorizzazioni non richieste nell'AndroidManifest.xml del runtime tramite <uses-permission> meccanismo di attenzione.

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

• [C-0-4] I runtime alternativi DEVONO rispettare il modello sandbox di Android usando un runtime alternativo NON DEVONO riutilizzare la sandbox di qualsiasi altra app installata sul dispositivo, ad eccezione di tramite i meccanismi Android standard di ID utente condiviso e certificato di firma.

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

• [C-0-6] I runtime alternativi NON DEVONO essere avviati con, concessi o concessi alle altre applicazioni qualsiasi privilegio del super user (root) o di qualsiasi altro ID utente.

• [C-0-7] Quando i file .apk di runtime alternativi vengono inclusi in immagine di sistema delle implementazioni dei dispositivi, DEVE essere firmata con una chiave dal token utilizzato per firmare altre applicazioni incluse con il dispositivo implementazioni.

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

• [C-0-9] Quando un'applicazione deve utilizzare una risorsa dispositivo per per cui esiste un'autorizzazione Android corrispondente (ad esempio Fotocamera, GPS e così via), il runtime alternativo DEVE informare l'utente che l'applicazione sarà in grado di per accedere alla risorsa.

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

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

• I runtime alternativi POTREBBERO fornire un'unica sandbox Android condivisa da tutti che utilizzano il runtime alternativo.

9.5 Supporto di più utenti

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

• Le implementazioni dei dispositivi POSSONO, ma NON DEVONO attivare la funzionalità multiutente se utilizzano supporti rimovibili per l'archiviazione esterna principale.

Se le implementazioni dei dispositivi includono il supporto per più utenti, questi:

• [C-1-2] DEVE, per ogni utente, implementare un modello coerente con il modello di sicurezza della piattaforma Android, come definito Documento di riferimento per sicurezza e autorizzazioni nelle API.
• [C-1-3] DEVE avere uno spazio di archiviazione per le applicazioni condiviso separato e isolato (ovvero /sdcard) per ogni istanza utente.
• [C-1-4] DEVE garantire che le applicazioni di proprietà di ed in esecuzione per conto di un l'utente specificato non può elencare, leggere o scrivere nei file di proprietà di qualsiasi altro utente, anche se i dati di entrambi gli utenti sono archiviati sullo stesso volume o file system.
• [C-1-5] DEVE crittografare i contenuti della scheda SD quando è attiva la funzionalità multiutente utilizzando una chiave archiviata solo su supporti non rimovibili e accessibili solo al sistema se le implementazioni nei dispositivi utilizzano supporti rimovibili per le API di archiviazione esterne. Dal momento che ciò renderà i contenuti illeggibili da parte di un PC host, le implementazioni dei dispositivi verrà richiesto di passare a MTP o a un sistema simile per fornire ai PC host l'accesso ai dati dell'utente corrente.

Se le implementazioni dei dispositivi includono il supporto per più utenti, per tutti gli utenti tranne quelli creati appositamente per eseguire due istanze della stessa app:

• [C-2-1] DEVE avere uno spazio di archiviazione per le applicazioni condiviso separato e isolato (ossia /sdcard) per ogni istanza utente.
• [C-2-2] DEVE garantire che le applicazioni di proprietà di ed in esecuzione su di un determinato utente non possono elencare, leggere o scrivere sui file di proprietà da qualsiasi altro utente, anche se i dati di entrambi gli utenti vengono archiviati nello stesso volume o file system.

Le implementazioni dei dispositivi POSSONO creare un singolo profilo utente aggiuntivo di tipo android.os.usertype.profile.CLONE per l'utente principale (e solo per l'utente principale) per l'esecuzione di doppie istanze della stessa app. Queste istanze doppie condividono lo spazio di archiviazione parzialmente isolato, all'utente finale in Avvio app contemporaneamente e apparire nella stessa visualizzazione Recenti. Ad esempio, può essere usato per consentire all'utente di installare due le istanze di una sola app su un dispositivo dual SIM.

Se le implementazioni dei dispositivi creano il profilo utente aggiuntivo di cui sopra, allora:

• [C-3-1] DEVE fornire accesso solo allo spazio di archiviazione o ai dati già accessibile al profilo utente principale o di sua proprietà profilo utente aggiuntivo.
• [C-3-2] NON DEVE avere questo profilo come profilo di lavoro.
• [C-3-3] DEVE avere isolato le directory di dati private dell'app dall'elemento principale account utente.
• [C-3-4] NON DEVE consentire la creazione del profilo utente aggiuntivo se vi sono è stato eseguito il provisioning di un proprietario del dispositivo (vedi la sezione 3.9.1) o consenti l'accesso a un proprietario del dispositivo senza rimuovere prima il profilo utente aggiuntivo.

9.6. Avviso SMS premium

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

Se le implementazioni del dispositivo dichiarano il supporto per android.hardware.telephony, l'utente:

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

9.7 Funzionalità per la sicurezza

Le implementazioni dei dispositivi DEVONO garantire la conformità alle funzioni di sicurezza sia nel del kernel e della piattaforma come descritto di seguito.

Android Sandbox include funzionalità che utilizzano il sistema operativo Linux migliorato per la sicurezza (SELinux), sistema di controllo dell'accesso obbligatorio (MAC), sandboxing seccomp e altro le funzionalità di sicurezza del kernel Linux. Implementazioni dei dispositivi:

• [C-0-1] DEVE mantenere la compatibilità con le applicazioni esistenti, anche quando SELinux o qualsiasi altra funzione di sicurezza è implementata sotto la piattaforma il modello di machine learning.
• [C-0-2] NON DEVE avere un'interfaccia utente visibile quando un la violazione rilevata e bloccata correttamente dalla funzionalità di sicurezza implementati al di sotto del framework Android, ma POTREBBERO avere un’interfaccia utente visibile Quando si verifica una violazione della sicurezza sbloccata che porta a un exploit.
• [C-0-3] NON DEVE implementare SELinux o qualsiasi altra funzionalità di sicurezza sotto il framework Android configurabile dall'utente o dallo sviluppatore di app.
• [C-0-4] NON DEVE consentire un'applicazione che possa interessare un'altra applicazione tramite un'API (ad esempio un'API di amministrazione dei dispositivi) per configurare un criterio che danneggia la compatibilità.
• [C-0-5] DEVE suddividere il framework multimediale in più processi in modo che è possibile concedere l'accesso in modo più limitato per ogni processo descritto nel sito di Android Open Source Project.
• [C-0-6] DEVE implementare un meccanismo di sandboxing dell'applicazione kernel che consente di filtrare le chiamate di sistema utilizzando un criterio configurabile da i programmi multithread. L'Android Open Source Project upstream soddisfa questo requisito mediante l'attivazione di seccomp-BPF con threadgroup di sincronizzazione (TSYNC) come descritto nella sezione Configurazione del kernel di source.android.com.

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

• [C-0-7] DEVE implementare meccanismi di protezione dall'overflow del buffer dello stack del kernel. Esempi di questi meccanismi sono CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] DEVE implementare rigide protezioni della memoria del kernel dove è possibile il codice è di sola lettura, i dati di sola lettura non sono eseguibili e non scrivibili dati scrivibili non sono eseguibili (ad es. CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] DEVE implementare dimensioni dell'oggetto statiche e dinamiche controllo dei limiti delle copie tra spazio utente e spazio kernel (ad es. CONFIG_HARDENED_USERCOPY) su dispositivi originariamente spediti con livello API 28 o superiore.
• [C-0-10] NON DEVE eseguire la memoria dello spazio utente durante l'esecuzione in modalità kernel (ad es. hardware PX o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi inizialmente erano di livello API 28 o superiore.
• [C-0-11] NON DEVE leggere o scrivere la memoria dello spazio utente al di fuori delle normali API di accesso usercopy (ad esempio, PAN hardware emulata tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) su dispositivi originariamente forniti con livello API 28 o superiore.
• [C-0-12] DEVE implementare l'isolamento della tabella delle pagine del kernel se l'hardware vulnerabile a CVE-2017-5754 su tutti i dispositivi inizialmente venduti con livello API 28 o superiore (ad es. CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0).

• [C-0-13] DEVE implementare la protezione avanzata della previsione dei rami se l'hardware vulnerabile a CVE-2017-5715 su tutti i dispositivi inizialmente venduti con livello API 28 o superiore (ad es. CONFIG_HARDEN_BRANCH_PREDICTOR).

• [C-SR-1] VIVAMENTE CONSIGLIATA per mantenere i dati kernel che viene scritto solo durante l'inizializzazione, contrassegnato come sola lettura dopo inizializzazione (ad es. __ro_after_init).

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

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

• [C-SR-4] È VIVAMENTE CONSIGLIATO di non disattivare l'integrità del flusso di controllo (CFI), Shadow Call Stack (SCS) o Sanitizzazione dell'overflow intero (IntSan) on componenti in cui è abilitato.

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

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

• [C-SR-7] È VIVAMENTE CONSIGLIATO di abilitare l'inizializzazione dell'heap nel kernel per impedire l'uso di allocazioni heap non inizializzate (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) e NON DEVONO presupporre il valore utilizzato da al kernel per inizializzare queste allocazioni.

Se le implementazioni del dispositivo usano un kernel Linux in grado di supportare SELinux:

• [C-1-1] DEVE implementare SELinux.
• [C-1-2] DEVE impostare SELinux sulla modalità di applicazione globale.
• [C-1-3] DEVE configurare tutti i domini in modalità di applicazione forzata. Nessuna modalità permissiva domini consentiti, inclusi quelli specifici di un dispositivo/fornitore.
• [C-1-4] NON DEVE modificare, omettere o sostituire le regole non consentite presenti all'interno della cartella di sistema/sepolicy fornita nell'upstream Android Open Source il progetto (AOSP) e il criterio DEVONO essere compilati con tutte le regole continue, sia per i domini AOSP SELinux sia per i domini specifici per dispositivo/fornitore.
• [C-1-5] DEVE eseguire applicazioni di terze parti che hanno come target il livello API 28 o superiore nelle sandbox SELinux per app con restrizioni SELinux per app su ogni privata dei dati dell'applicazione.
• DEVE mantenere il criterio SELinux predefinito fornito nel criterio system/sepolicy dell'Android Open Source Project a monte e aggiungerla per la propria configurazione specifica per il dispositivo.

Se le implementazioni dei dispositivi utilizzano un kernel diverso da Linux o Linux senza SELinux, l'utente:

• [C-2-1] DEVE utilizzare un sistema di controllo degli accessi obbligatorio che equivalente a SELinux.

Se le implementazioni dei dispositivi utilizzano dispositivi I/O in grado di rispettare il DMA, questi:

• [C-SR-9] È VIVAMENTE CONSIGLIATO di isolare ciascun dispositivo I/O in grado di supportare la DMA, utilizzando un IOMMU (ad es. SMMU ARM).

Android contiene diverse funzionalità di difesa in profondità fondamentali per il dispositivo sicurezza. Inoltre, Android si concentra sulla riduzione delle classi chiave di bug comuni che contribuiscono a compromettere la qualità e la sicurezza.

Per ridurre i bug di memoria, le implementazioni del dispositivo:

• [C-SR-10] È VIVAMENTE CONSIGLIATO di essere testati utilizzando un errore di memoria dello spazio utente strumenti di rilevamento come MTE per dispositivi ARMv9, HWASan per dispositivi ARMv8+ o ASan per altri tipi di dispositivi.
• [C-SR-11] È VIVAMENTE CONSIGLIATO di essere testati utilizzando un errore di memoria del kernel di rilevamento automatico come KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS per Dispositivi ARMv9, CONFIG_KASAN_SW_TAGS per dispositivi ARMv8 o CONFIG_KASAN_GENERIC per altri tipi di dispositivi).
• [C-SR-12] È VIVAMENTE CONSIGLIATO di utilizzare strumenti di rilevamento degli errori di memoria in come MTE, GWP-ASan e KFENCE.

Se le implementazioni dei dispositivi utilizzano un TEE basato su TrustZone ARM:

• [C-SR-13] È VIVAMENTE CONSIGLIATO di usare un protocollo standard per la memoria condivisione tra Android e TEE, come il framework del firmware ARM per Armv8-A (FF-A).
• [C-SR-14] È VIVAMENTE CONSIGLIATO di limitare le applicazioni attendibili accede alla memoria che è stata condivisa esplicitamente con loro tramite la procedura protocollo. Se il dispositivo supporta il livello di eccezione ARM S-EL2, questo deve essere applicato dal gestore della partizione sicura. In caso contrario, applicati dal TEE OS.

9.8 Privacy

9.8.1. Cronologia di utilizzo

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

Implementazioni dei dispositivi:

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

Android archivia gli eventi di sistema utilizzando StatsLog identificatori e gestisce tale cronologia tramite StatsManager e API di sistema IncidentManager.

Implementazioni dei dispositivi:

• [C-0-2] DEVE includere solo i campi contrassegnati con DEST_AUTOMATIC nella report sugli incidenti creato dalla classe dell'API System IncidentManager.
• [C-0-3] Non DEVE utilizzare gli identificatori di eventi di sistema per registrare altri eventi rispetto a quanto descritto in StatsLog Documenti dell'SDK. Se vengono registrati altri eventi di sistema, questi POSSONO utilizzare un diverso identificatore di atomi nell'intervallo tra 100.000 e 200.000.

9.8.2. Registrazione in corso…

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE precaricare o distribuire immediatamente componenti software che inviare informazioni private dell'utente (ad es. sequenze di tasti, testo visualizzato schermo, segnalazione di bug) dal dispositivo senza il consenso dell'utente o notifiche continue.
• [C-0-2] DEVE mostrare un avviso relativo all'utente e ottenere il suo consenso esplicito in modo che tutte le informazioni sensibili visualizzate sullo schermo dell'utente vengano acquisiteche includano esattamente lo stesso messaggio di AOSP ogni volta ogni volta che si effettua una sessione per acquisire la schermata trasmissione o registrazione dello schermo è abilitato avviato tramite MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay(), o API proprietarie. NON DEVE fornire agli utenti un invito a disattivare la futura visualizzazione del consenso dell'utente.
• [C-0-3] DEVE avere una notifica fissa per l'utente durante la trasmissione dello schermo o la registrazione dello schermo. AOSP soddisfa questo requisito mostrando una icona di notifica continua nella barra di stato.

Se le implementazioni dei dispositivi includono funzionalità nel sistema che acquisisce i contenuti visualizzati sullo schermo e/o registra lo stream audio vengono riprodotti su un dispositivo diverso da quello tramite l'API di sistema ContentCaptureService oppure altri mezzi proprietari descritti in Sezione 9.8.6 Dati ambientali e a livello di sistema operativo:

• [C-1-1] DEVE avere una notifica fissa all'utente ogni volta che si verifica è attivata e sta registrando/registrando attivamente.

Se le implementazioni del dispositivo includono un componente già abilitato, in grado di registrare l'audio ambientale e/o registrare l'audio riprodotto sul dispositivo per dedurre informazioni utili sul contesto dell'utente, questi:

• [C-2-1] NON DEVE memorizzare nello spazio di archiviazione permanente sul dispositivo o trasmettere dispositivo l'audio RAW registrato o qualsiasi formato che possa essere riconvertito l'audio originale o un quasi facsimile, salvo esplicito consenso dell'utente.

Un "indicatore del microfono" fa riferimento a una visualizzazione sullo schermo, che è costantemente visibile per l'utente e non può essere oscurato, cosa che gli utenti interpretano perché è attivo un microfono. use(tramite testo, colore, icona o qualche combinazione univoci).

Un "indicatore della fotocamera" si riferisce a una visualizzazione sullo schermo, che è costantemente visibile alle l'utente e non può essere oscurata, cosa che gli utenti interpretano perché la fotocamera è in uso (tramite testo, colore, icona o qualche combinazione univoci).

Dopo il primo secondo visualizzato, un indicatore può cambiare visivamente, come stanno diventando più piccoli e non devono necessariamente mostrare i contenuti come presentati in origine capito.

L'indicatore del microfono potrebbe essere unito a una fotocamera visualizzata attivamente indicatore, a condizione che testo, icone o colori indichino all'utente che l'utilizzo del microfono è iniziato.

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

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

• [C-SR-1] È VIVAMENTE CONSIGLIATO di mostrare l'indicatore del microfono quando un'app accede ai dati audio dal microfono, ma non quando quest'ultimo è accessibile solo da HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o app che ricoprono i ruoli descritti nella sezione 9.1 Autorizzazioni con identificatore CDD [C-3-X]. .
• [C-SR-2] È VIVAMENTE CONSIGLIATO di visualizzare l'elenco delle categorie Recenti e Attive di app che usano il microfono restituito PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali attribuzioni messaggi associati.
• [C-SR-3] CONSIGLIATO VIVAMENTE di non nascondere l'indicatore del microfono per app di sistema con interfacce utente visibili o interazione diretta degli utenti.

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

• [C-SR-4] È VIVAMENTE CONSIGLIATO di mostrare l'indicatore della fotocamera quando un'app accede ai dati in diretta della videocamera, ma non quando quest'ultima è accessibile dalle app con i ruoli descritti nella Sezione 9.1 Autorizzazioni con CDD identificatore [C-3-X].
• [C-SR-5] È VIVAMENTE CONSIGLIATO di mostrare le app recenti e attive utilizzando fotocamera restituita da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.
• [C-SR-6] CONSIGLIATO VIVAMENTE di non nascondere l'indicatore della fotocamera per il sistema App con interfacce utente visibili o interazione diretta degli utenti.

9.8.3. Connettività

Se le implementazioni del dispositivo hanno una porta USB con supporto della modalità periferica USB, l'utente:

• [C-1-1] DEVE presentare un'interfaccia utente che chieda il consenso dell'utente prima consentendo l'accesso ai contenuti dell'archivio condiviso tramite la porta USB.

9.8.4. Traffico di rete

Implementazioni dei dispositivi:

• [C-0-1] DEVE preinstallare gli stessi certificati radice per il sistema attendibile Archivio dell'autorità di certificazione (CA) come fornito nel progetto open source Android a monte.
• [C-0-2] DEVE essere fornito con un archivio CA radice dell'utente vuoto.
• [C-0-3] DEVE mostrare all'utente un avviso che indichi il traffico di rete potrebbe essere monitorata quando viene aggiunta una CA radice dell'utente.

Se il traffico dei dispositivi viene instradato tramite VPN, le implementazioni dei dispositivi:

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

Se le implementazioni dei dispositivi hanno un meccanismo abilitato per impostazione predefinita, instrada il traffico di dati di rete attraverso un server proxy o un gateway VPN (ad esempio durante il precaricamento di un servizio VPN con android.permission.CONTROL_VPN concesso), questi:

• [C-2-1] DEVE chiedere il consenso dell'utente prima di attivare questo meccanismo. a meno che la VPN non sia attivata dal controller dei criteri dei dispositivi tramite DevicePolicyManager.setAlwaysOnVpnPackage() . In questo caso l'utente non deve fornire un consenso separato, ma DEVE ricevere solo una notifica.

Se le implementazioni del dispositivo implementano l'autorizzazione dell'utente per attivare "VPN sempre attiva" di un'app VPN di terze parti, questi:

• [C-3-1] DEVE disattivare l'autorizzazione utente per le app che non supportano servizio VPN sempre attivo nel file AndroidManifest.xml tramite l'impostazione del SERVICE_META_DATA_SUPPORTS_ALWAYS_ON a false.

9.8.5. Identificatori dei dispositivi

Implementazioni dei dispositivi:

• [C-0-1] DEVE impedire l'accesso al numero di serie del dispositivo e, se applicabile, IMEI/MEID, numero di serie della SIM e International Mobile Identità dell'abbonato (IMSI) di un'app, a meno che quest'ultima non soddisfi uno dei seguenti requisiti requisiti:
  • è un'app dell'operatore firmata e verificata dai produttori di dispositivi.
  • ha ricevuto l'autorizzazione READ_PRIVILEGED_PHONE_STATE.
  • dispone dei privilegi dell'operatore secondo quanto definito in Privilegi degli operatori UICC.
  • è un proprietario del dispositivo o del profilo a cui è stato concesso il Autorizzazione READ_PHONE_STATE.
  • (Solo per il numero di serie della SIM/ICCID) è previsto il requisito dei regolamenti locali che l'app rilevi cambiamenti nell'identità dell'abbonato.

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

Android, tramite le API di sistema ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query o da un altro mezzi proprietari, supporta un meccanismo per implementazioni per acquisire le seguenti interazioni di dati tra applicazioni e l'utente dati sensibili:

• Testo e grafica visualizzati sullo schermo, inclusi, a titolo esemplificativo, delle notifiche e dei dati relativi agli eventi indiretti tramite AssistStructure tramite Google Cloud CLI o tramite l'API Compute Engine.
• Dati multimediali, ad esempio audio o video, registrati o riprodotti dal dispositivo.
• Eventi di input (ad es. tasto, mouse, gesto, voce, video e accessibilità).

• Eventuali testi o altri dati inviati tramite TextClassifier API a System TextClassifier, ovvero al servizio di sistema per comprendere il significato del testo, oltre a generare le azioni successive previste in base il testo.
• Dati indicizzati dall'implementazione della piattaforma AppSearch, inclusi, a titolo esemplificativo limitatamente a testo, grafici, dati multimediali o altri dati simili.

Se le implementazioni del dispositivo acquisiscono uno qualsiasi dei dati sopra indicati:

• [C-1-1] DEVE crittografare tutti questi dati quando sono memorizzati nel dispositivo. Questo la crittografia POTREBBE essere effettuata usando la crittografia basata su file di Android o qualsiasi delle crittografie elencate come versione API 26 o successive descritte nell'SDK Cipher.
• [C-1-2] NON DEVE eseguire il backup dei dati non elaborati o criptati utilizzando Metodi di backup di Android o qualsiasi altro metodo .
• [C-1-3] DEVE inviare solo tutti questi dati e il log dispositivo che utilizza un meccanismo che tutela la privacy, ad eccezione dei casi con il consenso esplicito dell'utente ogni volta che i dati vengono condiviso. Il meccanismo di tutela della privacy è definita come "quelle che consentono solo l'analisi in forma aggregata e impediscono la corrispondenza di eventi registrati o di risultati derivati per singoli utenti", per impedisce che i dati per utente siano introspezionabili (ad es. implementati utilizzando una tecnologia di privacy differenziale come RAPPOR).
• [C-1-4] NON DEVONO associare questi dati a identità utente (ad esempio come Account) sul dispositivo, salvo che con il consenso esplicito dell'utente ogni volta che i dati vengono associati.
• [C-1-5] NON DEVE condividere questi dati con altri componenti del sistema operativo che non Rispetta i requisiti descritti nella sezione corrente (9.8.6 Acquisizione di contenuti A livello di sistema operativo e Ambient ), tranne con il consenso esplicito dell'utente ogni momento in cui viene condiviso. A meno che tale funzionalità non sia creato come API Android SDK (AmbientContext, HotwordDetectionService).
• [C-1-6] DEVE fornire all'utente il permesso di cancellare i dati che il ContentCaptureService l'implementazione o mezzi proprietari raccolgono se quando la i dati vengono memorizzati in qualsiasi formato sul dispositivo. Se l'utente sceglie di cancellare i dati, DEVE rimuovere tutti i dati storici raccolti dati.
• [C-1-7] DEVE fornire all'utente l'invito a disattivare i dati, raccolti tramite AppSearch o mezzi proprietari dalla visualizzazione sulla piattaforma Android ad es. Avvio app.
• [C-SR-1] CONSIGLIATO VIVAMENTE di NON richiedere l'autorizzazione INTERNET.
• [C-SR-2] CONSIGLIATO VIVAMENTE di accedere a internet solo tramite API strutturate supportate da implementazioni open source disponibili pubblicamente.

Se le implementazioni del dispositivo includono un servizio che implementa l'API di sistema ContentCaptureService, AppSearchManager.index o qualsiasi servizio di proprietà che acquisisce i dati come descritto sopra:

• [C-2-1] NON DEVE consentire agli utenti di sostituire i servizi con un installabile dall'utente e DEVE consentire soltanto servizi preinstallati per acquisire questi dati.
• [C-2-2] NON DEVE consentire app diverse dai servizi preinstallati meccanismo di acquisizione dei dati.
• [C-2-3] DEVE fornire l'invito all'utente per disabilitare i servizi.
• [C-2-4] NON DEVE omettere l'autorizzazione dell'utente a gestire le autorizzazioni Android che sono di proprietà dei servizi e seguono le autorizzazioni di Android. come descritto nella Sezione 9.1. Autorizzazione.

• [C-SR-3] È VIVAMENTE CONSIGLIATO per mantenere i servizi separati dagli altri componenti di sistema(ad es. gli ID servizio o i processi di condivisione non vincolano) ad eccezione di quanto segue:

  • Telefonia, contatti, UI di sistema e contenuti multimediali

9.8.7. Accesso agli appunti

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE restituire dati troncati dagli appunti (ad esempio, tramite ClipboardManager API) a meno che la terza parte app è l'IME predefinito o è l'app attualmente attiva.

• [C-0-2] DEVE cancellare i dati degli Appunti al massimo 60 minuti dopo l'ultima volta che sono stati inseriti negli appunti o letti dagli appunti.

9.8.8. Posizione

La posizione include informazioni nella classe di posizione Android( come Latitude, Longitudine e Altitudine), nonché identificatori che possono essere convertiti in Posizione. La localizzazione può essere uguale a quella del sistema DGPS (Differential Global Positioning System) o approssimative rispetto alle località a livello di paese (ad esempio località del codice paese - Centro clienti - Dispositivo mobile Codice paese).

Di seguito è riportato un elenco dei tipi di località che derivano direttamente dal posizione geografica o che possono essere convertiti in quella di un utente. Non si tratta di un elenco completo ma dovrebbe essere usato come esempio su ciò che la geolocalizzazione può derivare indirettamente da:

• GPS/GNSS/DGPS/PPP
  • soluzione di posizionamento globale o sistema di navigazione satellitare globale oppure Soluzione di posizionamento globale differenziale
  • Sono inclusi anche le misurazioni GNSS non elaborate e lo stato GNSS
    • La posizione precisa può essere ricavata dalle misurazioni GNSS non elaborate
• Tecnologie wireless con identificatori univoci come:
  • Punti di accesso Wi-Fi (MAC, BSSID, nome o SSID)
  • Bluetooth/BLE (MAC, BSSID, nome o SSID)
  • UWB (MAC, BSSID, nome o SSID)
  • ID ripetitore cellulare (3G, 4G, 5G... Compreso tutti i modem cellulari futuri tecnologie che hanno identificatori univoci)

Come punto di riferimento principale, vediamo le API Android che richiedono Autorizzazioni ACCESS_FINE_Location o ACCESS_COARSE_Location.

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE attivare/disattivare l'impostazione di geolocalizzazione del dispositivo e il Wi-Fi/Bluetooth delle impostazioni di scansione senza il consenso esplicito o l'avvio dell'utente.
• [C-0-2] DEVE fornire all'utente l'autorizzazione per accedere alla località correlata Informazioni tra cui richieste di posizione recenti, autorizzazioni a livello di app e utilizzo della scansione Wi-Fi/Bluetooth per determinare la posizione.
• [C-0-3] DEVE garantire che l'applicazione che utilizza l'API Emergency Location Bypass [LocationRequest.setLocationSettings ignored()] è un'emergenza avviata dall'utente sessione (ad es. componi il 911 o invia un SMS al 911). Nel settore auto e motori, invece, un veicolo MAG avvia una sessione di emergenza senza interazione dell'utente attiva nella richiesta viene rilevato un incidente/incidente (ad es. per soddisfare i requisiti di eCall).
• [C-0-4] DEVE preservare la capacità dell'API Emergency Location Bypass di eludere le impostazioni di geolocalizzazione del dispositivo senza modificare le impostazioni.
• [C-0-5] DEVE pianificare una notifica che ricorda all'utente dopo un'app in lo sfondo abbia avuto accesso alla sua posizione utilizzando Autorizzazione [ACCESS_BACKGROUND_LOCATION].

9.8.9. App installate

Le app per Android che hanno come target il livello API 30 o versioni successive non possono vedere i dettagli relativi ad altri installate per impostazione predefinita (vedi Visibilità dei pacchetti nella documentazione dell'SDK).

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE essere esposta a dettagli relativi al livello API 30 o successivo per il targeting delle app su qualsiasi altra app installata, a meno che l'app non sia già in grado di vedere i dettagli sull'altra app installata tramite le API gestite. Ciò include, tra l'altro, non limitatamente ai dettagli esposti dalle API personalizzate aggiunte dal dispositivo o accessibile tramite il file system.
• [C-0-2] NON DEVE concedere ad alcuna app, leggere o scrivere l'accesso ai file in altri una directory dedicata specifica per l'app nella memoria esterna. Le uniche eccezioni sono le seguenti:
  • L'autorità del fornitore di archiviazione esterna (ad esempio app come DocumentsUI).
  • Download Provider che utilizza l'autorità del provider "download" per scaricare file nello spazio di archiviazione delle app.
  • Le app MTP (Media Transfer Protocol) con firma a piattaforma che utilizzano il protocollo l'autorizzazione con privilegi ACCESS_MTP per consentire il trasferimento di file su su un altro dispositivo.
  • App che installano altre app e hanno l'autorizzazione INSTALL_PACKAGES possono accedere solo alle directory "obb" allo scopo di gestire File di espansione APK.

9.8.10. Report sui bug relativi alla connettività

Se le implementazioni dei dispositivi dichiarano il flag funzionalità android.hardware.telephony, l'utente:

• [C-1-1] DEVE supportare la generazione di report di bug relativi alla connettività tramite BUGREPORT_MODE_TELEPHONY con BugreportManager.
• [C-1-2] DEVE ottenere il consenso degli utenti ogni volta che BUGREPORT_MODE_TELEPHONY viene utilizzata per generare un report e NON DEVE richiedere all'utente di acconsentire a tutte le in futuro da parte dell'applicazione.
• [C-1-3] NON DEVE restituire il report generato all'app richiedente senza consenso esplicito dell'utente.
• [C-1-4] I report generati utilizzando BUGREPORT_MODE_TELEPHONY DEVONO contenere almeno le seguenti informazioni:
  • Dump TelephonyDebugService
  • Dump TelephonyRegistry
  • Dump WifiService
  • Dump ConnectivityService
  • Un dump dell'istanza CarrierService del pacchetto chiamante (se vincolata)
  • Buffer log radio
  • SubscriptionManagerService dump
• [C-1-5] NON DEVE includere quanto segue nei report generati:
  • Qualsiasi tipo di informazione non direttamente correlata alla connettività il debug del machine learning.
  • Qualsiasi tipo di log del traffico di applicazioni installate dall'utente o profili dettagliati di applicazioni o pacchetti installati dall'utente (gli UID sono validi, i nomi dei pacchetti sono ).
• POTREBBE includere informazioni aggiuntive che non sono associate ad alcun utente e identità di base. (ad es., log dei fornitori).

Se le implementazioni dei dispositivi includono informazioni aggiuntive (ad es. i log dei fornitori) nei segnalazioni di bug e che le informazioni includono privacy/sicurezza/batteria/spazio di archiviazione/memoria impatto, questi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di utilizzare un'impostazione sviluppatore predefinita disattivata. L'implementazione del riferimento AOSP soddisfa questo requisito fornendo il Enable verbose vendor logging opzione nelle impostazioni sviluppatore per includere log aggiuntivi dei fornitori specifici del dispositivo nelle segnalazioni di bug.

9.8.11. Condivisione dei BLOB di dati

Android, tramite BlobStoreManager consente alle app di contribuire alla condivisione di BLOB di dati nel sistema con un insieme di app.

Se le implementazioni dei dispositivi supportano i blob di dati condivisi come descritto Documentazione SDK, l'utente:

• [C-1-1] NON DEVE condividere BLOB di dati appartenenti ad app diverse da quelle di cui consentire (ovvero l'ambito dell'accesso predefinito che possono essere specificate utilizzando BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess(), o BlobStoreManager.session#allowPublicAccess() NON DEVONO essere modificati). L'implementazione del riferimento AOSP soddisfa questi i tuoi requisiti.
• [C-1-2] NON DEVE inviare al di fuori del dispositivo o condividere con altre app gli hash sicuri di BLOB di dati (utilizzati per controllare l'accesso).

9.8.12. Riconoscimento della musica

Android, tramite l'API di sistema MusicRecognitionManager, supporta un meccanismo per implementazioni sui dispositivi per richiedere il riconoscimento musicale, una volta registrato l'audio; e delegano il riconoscimento musicale a un'app privilegiata che implementa API MusicRecognitionService.

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

• [C-1-1] DEVE imporre che il chiamante di MusicRecognitionManager contenga il Autorizzazione MANAGE_MUSIC_RECOGNITION
• [C-1-2] DEVE richiedere che un singolo riconoscimento musicale preinstallato l'applicazione implementa MusicRecognitionService.
• [C-1-3] NON DEVE consentire agli utenti di sostituire MusicRecognitionManagerService o MusicRecognitionService con un'applicazione o un servizio installabile dall'utente.
• [C-1-4] DEVE garantire che quando MusicRecognitionManagerService accede a registrazione audio e la inoltra all'applicazione che implementa MusicRecognitionService, l'accesso all'audio viene tracciato tramite chiamate di AppOpsManager.noteOp / startOp.

Se le implementazioni sul dispositivo di MusicRecognitionManagerService o MusicRecognitionService archivia tutti i dati audio acquisiti, pertanto:

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

9.8.13. SensorPrivacyManager

Se le implementazioni del dispositivo forniscono all'utente un'autorizzazione software per disattivare l'ingresso della videocamera e/o del microfono per l'implementazione del dispositivo:

• [C-1-1] DEVE restituire esattamente "true" per i relativi supportsSensorToggle() API.
• [C-1-2] DEVE, quando un'app tenta di accedere a un microfono o una fotocamera bloccati, presentare all'utente un'invito all'utente non ignorabile che indica che il sensore è bloccato e richiede una scelta per continuare bloccare o sbloccare in base all'implementazione AOSP che soddisfa requisito.
• [C-1-3] DEVE trasmettere alle app dati audio e della videocamera vuoti (o falsi) soltanto e non segnalare un codice di errore dovuto al fatto che l'utente non accende la fotocamera né il microfono tramite l'autorizzazione dell'utente presentata in [C-1-2] di cui sopra.

9,9 Crittografia archiviazione dati

Tutti i dispositivi DEVONO soddisfare i requisiti della sezione 9.9.1. I dispositivi che sono stati lanciati a livello di API prima di questo documento vengono esenti dai requisiti di cui alle sezioni 9.9.2 e 9.9.3; invece DEVE soddisfare i requisiti della sezione 9.9 del Regolamento relativo alla compatibilità con Android. Documento di definizione corrispondente al livello API su cui è stato avviato il dispositivo.

9.9.1. Avvio diretto

Implementazioni dei dispositivi:

• [C-0-1] DEVE implementare le API in modalità di avvio diretto anche se non supportano Storage Encryption.

• [C-0-2] La ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED Gli intent DEVONO comunque essere trasmessi per segnalare che le applicazioni sensibili all'avvio diretto Le posizioni di archiviazione dei dispositivi con crittografia DE e con crittografia CE disponibili per l'utente.

9.9.2. Requisiti di crittografia

Implementazioni dei dispositivi:

• [C-0-1] DEVE criptare l'applicazione come privata (partizione /data), nonché la partizione dello spazio di archiviazione condiviso dell'applicazione (partizione /sdcard) se si tratta di una parte permanente e non rimovibile del dispositivo.
• [C-0-2] DEVE abilitare la crittografia dell'archiviazione dei dati per impostazione predefinita al momento l'utente abbia completato l'esperienza di configurazione immediata.

• [C-0-3] DEVE soddisfare i requisiti di crittografia specificati sopra per l'archiviazione dei dati requisito implementando uno dei seguenti due metodi di crittografia:

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

9.9.3. Metodi di crittografia

Se le implementazioni dei dispositivi sono criptate, queste:

• [C-1-1] DEVE avviarsi senza richiedere all'utente le credenziali e Consentire alle app sensibili all'avvio diretto di accedere allo spazio di archiviazione con crittografia dei dispositivi (DE) dopo la trasmissione del messaggio ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] DEVE consentire l'accesso all'archivio con credenziali con crittografia CE solo dopo l'utente ha sbloccato il dispositivo fornendo le proprie credenziali. (ad es. passcode, PIN, sequenza o impronta) e ACTION_USER_UNLOCKED viene trasmesso.
• [C-1-13] NON DEVE offrire alcun metodo per sbloccare lo spazio di archiviazione protetto da CE senza le credenziali fornite dall'utente, una chiave di deposito a garanzia registrata o una di riprendere al riavvio dell'implementazione soddisfacendo i requisiti in 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 nei dispositivi utilizzano la crittografia basata su file con la crittografia dei metadati, l'utente:

• [C-1-5] DEVE crittografare i contenuti e i metadati del file system utilizzando AES-256-XTS o Adiantum. AES-256-XTS si riferisce all'Advanced Encryption Standard con una lunghezza di chiave di crittografia a 256 bit, gestita in modalità XTS; per l'intera durata a 512 bit. Adiantum si riferisce ad Adiantum-XChaCha12-AES, come specificato in https://github.com/google/adiantum. I metadati di file system sono dati come dimensioni, proprietà, modalità e attributi estesi (xattrs).
• [C-1-6] DEVE crittografare i nomi dei file utilizzando AES-256-CBC-CTS, AES-256-HCTR2, o Adiantum.
• [C-1-12] Se il dispositivo utilizza Advanced Encryption Standard (AES) (ad esempio le estensioni di crittografia ARMv8 su dispositivi basati su ARM oppure AES-NI su dispositivi basati su x86), quindi le opzioni basate su AES di cui sopra per il nome del file, i contenuti dei file e la crittografia dei metadati del file system, non Adiantum.
• [C-1-13] DEVE utilizzare una chiave crittograficamente stabile e non reversibile funzione di derivazione (ad es. HKDF-SHA512) per ricavare le sottochiavi necessarie (ad es. per file) dalle chiavi CE e DE. "criptograficamente efficace non reversibile" significa che la funzione di derivazione delle chiavi ha un livello di sicurezza elevato di almeno 256 bit e si comporta come una funzione pseudocasuale famiglia sui suoi input.
• [C-1-14] NON DEVE utilizzare le stesse chiavi o sottochiavi di crittografia basata su file (FBE) per diversi scopi crittografici (ad esempio, sia per la crittografia che per la chiave o per due diversi algoritmi di crittografia).
• [C-1-15] DEVE garantire che tutti i blocchi non eliminati di contenuti di file criptati nello spazio di archiviazione permanente sono state criptate usando combinazioni di chiavi di crittografia vettore di inizializzazione (IV) che dipende sia dal file che dall'offset all'interno del file. Inoltre, tutte queste combinazioni DEVONO essere distinte, ad eccezione dei casi in cui la crittografia viene eseguita utilizzando hardware di crittografia in linea che supporta solo Lunghezza IV di 32 bit.
• [C-1-16] DEVE garantire che tutti i nomi file criptati non eliminati sui file spazio di archiviazione in directory distinte sono state criptate usando combinazioni distinte di crittografia e vettore di inizializzazione (IV).

• [C-1-17] DEVE garantire che tutti i metadati del file system criptato vengano bloccati lo spazio di archiviazione permanente è stato criptato utilizzando combinazioni distinte di chiave di crittografia e il vettore di inizializzazione (IV).

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

  • [C-1-7] DEVE essere crittograficamente associato a un archivio chiavi supportato da hardware. Questo archivio chiavi DEVE essere associato all'Avvio verificato e all'hardware del dispositivo radice di attendibilità.
  • [C-1-8] Le chiavi CE DEVONO essere associate alle credenziali della schermata di blocco di un utente.
  • [C-1-9] Le chiavi CE DEVONO essere associate a un passcode predefinito quando l'utente credenziali della schermata di blocco non specificate.
  • [C-1-10] DEVE essere univoco e distinto, in altre parole nessun certificato CE o DE dell'utente corrisponde a qualsiasi chiave CE o DE di qualsiasi altro utente.
  • [C-1-11] DEVONO utilizzare le crittografie, le lunghezze delle chiavi e diverse.
  • [C-1-12] DEVE essere resettato in modo sicuro durante lo sblocco e il blocco del bootloader come descritto qui.

• DEVONO creare app essenziali preinstallate (ad es. Sveglia, Telefono, Messenger) Sensibile all'avvio diretto.

Il progetto open source Android a monte offre un'implementazione preferita Crittografia basata su file basata sul kernel Linux "fscrypt" funzionalità di crittografia, e della crittografia dei metadati basata sul kernel Linux "dm-default-key" funzionalità.

9.9.3.2. Crittografia a livello di blocco per utente

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

• [C-1-1] DEVE abilitare il supporto multiutente come descritto nella sezione 9.5.
• [C-1-2] DEVE fornire partizioni per utente, utilizzando partizioni non elaborate o come volumi logici.
• [C-1-3] DEVE utilizzare chiavi di crittografia univoche e distinte per utente per la crittografia dei dispositivi a blocchi sottostanti.

• [C-1-4] DEVE utilizzare AES-256-XTS per la crittografia a livello di blocco dell'utente partizioni di Compute Engine.

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

  • [C-1-5] DEVE essere crittograficamente associato a un archivio chiavi supportato da hardware. Questo archivio chiavi DEVE essere associato all'Avvio verificato e all'hardware del dispositivo radice di attendibilità.
  • [C-1-6] DEVE essere associato alla schermata di blocco dell'utente corrispondente e credenziali.

La crittografia a livello di blocco per utente può essere implementata utilizzando il kernel Linux "dm-crypt" più funzionalità rispetto alle partizioni per utente.

9.9.4. Riprendi al riavvio

La funzionalità Riprendi al riavvio consente di sbloccare lo spazio di archiviazione CE di tutte le app, incluse quelle che non supportano ancora l'avvio diretto, dopo un riavvio avviato da un'agenzia di viaggi online. Questo consente agli utenti di ricevere notifiche dalle app installate dopo il riavvio.

L'implementazione della funzionalità Riprendi al riavvio deve continuare per garantire che, quando dispositivo cade nelle mani di un aggressore, è estremamente difficile un malintenzionato per recuperare i dati criptati CE dell'utente, anche se il dispositivo è alimentato attiva, l'archiviazione CE è sbloccata e l'utente ha sbloccato il dispositivo dopo aver ricevuto un'agenzia di viaggi online. Per la resistenza agli attacchi interni, supponiamo anche che l’aggressore acceda per trasmettere le chiavi di firma crittografiche.

Nello specifico:

• [C-0-1] L’archiviazione CE NON DEVE essere leggibile anche per l’aggressore che ha fisicamente il dispositivo e presenta le seguenti funzionalità e limitazioni:

  • Puoi usare la chiave di firma di qualsiasi fornitore o azienda per firmare in modo arbitrario messaggi.
  • Può causare la ricezione di una OTA da parte del dispositivo.
  • Può modificare il funzionamento di qualsiasi hardware (AP, Flash ecc.) ad eccezione di descritto di seguito, ma tale modifica comporta un ritardo di almeno ora e un ciclo di spegnimento e spegnimento che distrugge i contenuti della RAM.
  • Impossibile modificare il funzionamento dell'hardware antimanomissione (ad es. Titan M).
  • Impossibile leggere la RAM del dispositivo in uso.
  • Non possono ottenere la credenziale dell'utente (PIN, sequenza, password) o altrimenti viene inserito.

A titolo di esempio, un'implementazione di un dispositivo che implementa e sia conforme delle descrizioni disponibili qui sarà conforme con [C-0-1].

9.10. Integrità del dispositivo

I seguenti requisiti garantiscono la trasparenza sullo stato del e l'integrità del dispositivo. Implementazioni dei dispositivi:

• [C-0-1] DEVE essere registrato correttamente tramite il metodo API di sistema PersistentDataBlockManager.getFlashLockState() se il suo bootloader consente il flashing dell'immagine di sistema.

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

Se le implementazioni dei dispositivi sono già state lanciate senza supportare l'Avvio verificato su una versione precedente di Android e non possiamo aggiungere il supporto funzione con un aggiornamento software di sistema, POTREBBERO essere esentati dalla requisito.

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

• [C-1-1] DEVE dichiarare il flag 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 sia radice di attendibilità e arrivare fino alla partizione di sistema.
• [C-1-4] DEVE implementare ogni fase della verifica per controllare l'integrità e l'autenticità di tutti i byte nella fase successiva prima di eseguire il codice alla fase successiva.
• [C-1-5] DEVE utilizzare algoritmi di verifica efficaci come gli attuali Consigli del NIST per gli algoritmi di hashing (SHA-256) e la chiave pubblica (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 vengono eventuali blocchi di archiviazione non verificati DEVONO essere utilizzati.
• [C-1-7] NON DEVE consentire la modifica delle partizioni verificate sul dispositivo a meno che l'utente non abbia sbloccato esplicitamente il bootloader.
• [C-SR-1] Se nel dispositivo sono presenti più chip discreti (ad es. radio, un processore di immagine specializzato), il processo di avvio di ognuno di questi chip VIVAMENTE CONSIGLIATO di verificare ogni fase al momento dell'avvio.
• [C-1-8] DEVE usare una memoria che evidenzia le manomissioni: per memorizzare se il il bootloader è sbloccato. L'archiviazione a prova di manomissione significa che il bootloader può rilevare se lo spazio di archiviazione è stato manomesso dall'interno di Android.
• [C-1-9] DEVE inviare un messaggio all'utente mentre utilizza il dispositivo, e richiedono una conferma fisica prima di consentire una transizione da bootloader dalla modalità di blocco alla modalità di sblocco del bootloader.
• [C-1-10] DEVE implementare la protezione rollback per le partizioni usate da Android (ad es. avvio, partizioni di sistema) e usa un'archiviazione che evidenzia le manomissioni per l'archiviazione Metadati utilizzati per determinare la versione minima consentita del sistema operativo.
• [C-1-11] DEVE cancellare in modo sicuro tutti i dati utente durante lo sblocco del bootloader e blocco, come da "9.12. "Data Deletion" (Eliminazione dati) (incluse la partizione dei dati utente e spazi NVRAM).
• [C-SR-2] È VIVAMENTE CONSIGLIATO di verificare tutti i file APK di app con privilegi con una catena di attendibilità radicata in partizioni protette da Avvio verificato.
• [C-SR-3] È VIVAMENTE CONSIGLIATO di verificare eventuali artefatti eseguibili caricati un'app con privilegi esterni al file APK (ad esempio, codice caricato dinamicamente o codice compilato) prima di eseguirli o VIVAMENTE CONSIGLIATO di non eseguirli del tutto.
• DEVI implementare la protezione dal rollback per qualsiasi componente con firmware (ad es. modem, fotocamera) e DOVREBBE usare un'archiviazione che evidenzia le manomissioni per e archiviare i metadati utilizzati per determinare la versione minima consentita.

Se le implementazioni dei dispositivi sono già state lanciate senza il supporto di C-1-8 tramite C-1-11 su una versione precedente di Android e non può aggiungere supporto per questi requisiti con un aggiornamento software di sistema, POTREBBERO essere esentati dalle i tuoi requisiti.

Il progetto open source Android a monte offre un'implementazione preferita questa funzionalità nel external/avb/ integrato nel bootloader usato per il caricamento, Android.

Implementazioni sui dispositivi

Se le implementazioni del dispositivo sono in grado di verificare il file per pagina, allora:

• [C-0-3 C-2-1] verificare crittograficamente il contenuto del file con una chiave attendibile senza leggere l'intero file.

• [C-0-4 C-2-2] NON DEVE consentire il parametro richieste di lettura su un file protetto, che abbiano esito positivo quando i contenuti letti non effettuare la verifica utilizzando una chiave attendibile non è verificato in base a [C-2-1] sopra.

Se le implementazioni dei dispositivi sono già state lanciate senza la possibilità di verificare dei file a fronte di una chiave attendibile in una versione precedente di Android e non possono aggiungere per il supporto di questa funzionalità con un aggiornamento software di sistema, POTREBBERO essere esentati dal requisito. Il progetto open source Android a monte fornisce implementazione preferita di questa funzione basata sulla funzionalità del kernel Linux fs-verity.

Implementazioni dei dispositivi:

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

Se le implementazioni del dispositivo supportano la conferma Android Protected API:

• [C-3-1] DEVE segnalare true per ConfirmationPrompt.isSupported() tramite Google Cloud CLI o tramite l'API Compute Engine.

• [C-3-2] DEVE garantire che il codice eseguito nel sistema operativo Android, incluse le relative del kernel, dannoso o di altro tipo, non può generare una risposta positiva senza interazione dell'utente.

• [C-3-3] DEVE garantire che l'utente sia riuscito a esaminare e approvare i messaggio richiesto anche nel caso in cui il sistema operativo Android, incluso il kernel, è compromesso.

9.11. Chiavi e credenziali

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

• [C-0-1] DEVE consentire almeno 8.192 chiavi da importare o generare.
• [C-0-2] L'autenticazione della schermata di blocco DEVE implementare un intervallo di tempo tra un tentativo non riuscito e l'altro. Con n come conteggio dei tentativi non riusciti, il tempo DEVE essere di almeno 30 secondi per 9 < n < 30. Per n > 29, il valore dell'intervallo di tempo DEVE essere di almeno 30*2^floor((n-30)/10)) secondi o almeno 24 ore, a seconda di quale sia la durata minore.
• Non deve limitare il numero di chiavi che possono essere generate

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

• [C-1-1] DEVE eseguire il backup dell'implementazione dell'archivio chiavi con una dell'ambiente di esecuzione.
• [C-1-2] DEVE avere implementazioni di RSA, AES, ECDSA, ECDH (se IKeyMintDevice è supportato), 3DES, e algoritmi crittografici HMAC e hash di famiglia MD5, SHA1 e SHA-2. per supportare correttamente le funzioni del sistema dell'archivio chiavi Android algoritmi in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L’isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante il quale il codice del kernel o dello spazio utente può accedere allo stato interno isolato, inclusa la DMA. L'open source di Android a monte Il progetto (AOSP) soddisfa questo requisito utilizzando un'implementazione fiduciosa, ma un'altra soluzione basata su ARM TrustZone o una soluzione sicura esaminata da terze parti l'implementazione di un adeguato isolamento basato su hypervisor sono le opzioni di CPU e memoria disponibili.
• [C-1-3] DEVE eseguire l'autenticazione della schermata di blocco negli dell'ambiente di esecuzione e, solo in caso di esito positivo, consentire l'accesso chiave da usare. Le credenziali della schermata di blocco DEVONO essere memorizzate in un che consenta solo all'ambiente di esecuzione isolato di eseguire la schermata di blocco autenticazione. L'Android Open Source Project a monte offre Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
• [C-1-4] DEVE supportare l'attestazione della chiave in cui è presente la chiave di firma dell'attestazione protetti da hardware sicuri e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise tra un numero sufficientemente elevato di per impedire che le chiavi vengano utilizzate come identificatori dei dispositivi. Sola andata soddisfare questo requisito è condividere la stessa chiave di attestazione, a meno che vengono prodotte almeno 100.000 unità di uno SKU. Se sono 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 avviata su un dispositivo Android precedente non è richiesto un archivio chiavi. supportata da un ambiente di esecuzione isolato e che supportano l'attestazione chiave, a meno che non dichiari la funzionalità android.hardware.fingerprint che richiede un archivio chiavi supportato da un ambiente di esecuzione isolato.

• [C-1-5] DEVE consentire all'utente di scegliere il timeout della sospensione per la transizione da il dispositivo è sbloccato in stato di blocco, con un timeout minimo consentito fino a 15 secondi. Dispositivi automobilistici, che bloccano lo schermo ogni volta che l'unità principale se l'utente è disattivato o l'utente viene cambiato, NON POTREBBE avere il timeout di sospensione configurazione.
• [C-1-6] DEVE supportare uno dei seguenti elementi:
  • IKeymasterDevice 3.0
  • IKeymasterDevice 4.0
  • IKeymasterDevice 4.1
  • IKeyMintDevice versione 1 oppure
  • IKeyMintDevice versione 2.
• [C-SR-1] È VIVAMENTE CONSIGLIATO di supportare IKeyMintDevice versione 1.

9.11.1. Schermata di blocco sicura, autenticazione e dispositivi virtuali

L'implementazione di AOSP segue un modello di autenticazione a più livelli in cui l'autenticazione primaria basata su knowledge base può essere supportata da un biometrici forti secondari o con modalità terziarie più deboli.

Implementazioni dei dispositivi:

• [C-SR-1] CONSIGLIATO VIVAMENTE di impostare solo una delle seguenti opzioni come autenticazione principale :

  • Un PIN numerico
  • Una password alfanumerica

  • Una sequenza di scorrimento su una griglia di 3 x 3 punti esatti

    Tieni presente che i metodi di autenticazione illustrati sopra sono indicati come metodi di autenticazione principali di questo documento.

Se le implementazioni dei dispositivi aggiungono o modificano l'autenticazione principale consigliata e usano un nuovo metodo di autenticazione come metodo sicuro per bloccare lo schermo, il nuovo metodo di autenticazione:

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

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco se è basata su un secret noto e utilizza una nuova da trattare come modo sicuro per bloccare lo schermo:

• [C-3-1] L'entropia della lunghezza massima 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) implementate e fornite in AOSP.
• [C-3-4] Il nuovo metodo di autenticazione DEVE essere disattivato quando L'applicazione Device Policy Controller (DPC) ha impostato la password sui requisiti DevicePolicyManager.setRequiredPasswordComplexity() con una costante di complessità più restrittiva PASSWORD_COMPLEXITY_NONE oppure tramite DevicePolicyManager.setPasswordQuality() con una costante più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] I nuovi metodi di autenticazione DEVONO fare riferimento metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) ogni 72 ore o meno OPPURE comunicarle chiaramente al all'utente che non verrà eseguito il backup di alcuni dati per conservare la privacy dei loro dati.

Se le implementazioni dei dispositivi aggiungono o modificano l'autenticazione principale consigliata per sbloccare la schermata di blocco e utilizzare un nuovo metodo di autenticazione, in base alla biometria da trattare come un modo sicuro per bloccare lo schermo, il nuovo :

• [C-4-1] DEVE soddisfare tutti i requisiti descritti nella sezione 7.3.10 per la Classe 1 (in precedenza Comodità).
• [C-4-2] DEVE disporre di un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali basati su un secret noto.
• [C-4-3] DEVE essere disattivato e consentire solo l'istanza principale consigliata l'autenticazione per sbloccare lo schermo quando il controller dei criteri dei dispositivi (DPC, Device Policy Controller) l'applicazione ha impostato il criterio relativo alla funzionalità di blocco della tastiera chiamando il metodo DevicePolicyManager.setKeyguardDisabledFeatures() , con una delle segnalazioni biometriche associate (ad es. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE o KEYGUARD_DISABLE_IRIS).

Se i metodi di autenticazione biometrica non soddisfano i requisiti Per la Classe 3 (in precedenza Strong), come descritto in sezione 7.3.10:

• [C-5-1] I metodi DEVONO essere disattivati se il controller dei criteri dei dispositivi (DPC) l'applicazione ha impostato i criteri di qualità relativi ai requisiti delle password tramite il metodo DevicePolicyManager.setRequiredPasswordComplexity() con un bucket di complessità più restrittivo di PASSWORD_COMPLEXITY_LOW oppure utilizzando DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK,
• [C-5-2] L'utente DEVE richiedere l'offerta principale consigliata l'autenticazione (ad es. PIN, sequenza, password) come descritto in [C-1-7] e [C-1-8] nella sezione 7.3.10.
• [C-5-3] I metodi NON DEVONO essere trattati come una schermata di blocco sicura e DEVONO Soddisfare i requisiti che iniziano con C-8 in questa sezione di seguito.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco e un nuovo metodo di autenticazione è basato su un token fisico o la località:

• [C-6-1] DEVONO avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali basati su un secret noto e i requisiti da considerare come una schermata di blocco sicura.
• [C-6-2] Il nuovo metodo DEVE essere disattivato e consentire soltanto uno dei seguenti metodi di autenticazione principali consigliati per sbloccare lo schermo quando L'applicazione Device Policy Controller (DPC) ha impostato il criterio con una delle seguenti opzioni:
  • La DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) metodo
  • La DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_NONE.
  • La DevicePolicyManager.setRequiredPasswordComplexity() con un bucket di complessità più restrittivo rispetto PASSWORD_COMPLEXITY_NONE.
• [C-6-3] L'utente DEVE essere sottoposto a verifica per uno dei requisiti principali consigliati metodi di autenticazione (ad es. PIN, sequenza, password) almeno una volta ogni Massimo 4 ore. Quando un token fisico soddisfa requisiti per le implementazioni di TrustAgent in C-X, restrizioni relative al timeout definiti in C-9-5.
• [C-6-4] Il nuovo metodo NON DEVE essere considerato una schermata di blocco sicura e DEVE segui i vincoli elencati in C-8 di seguito.

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

• [C-7-1] DEVE avere indicazioni chiare nel menu Impostazioni e sulla serratura schermata quando il blocco del dispositivo viene posticipato o può essere sbloccato da agenti di attendibilità. Ad esempio, AOSP soddisfa questo requisito mostrando una descrizione testuale per l'impostazione "Blocca automaticamente" e "Blocco istantaneo con tasto di accensione" nel impostazioni del dispositivo e un'icona distinguibile nella schermata di blocco.
• [C-7-2] DEVE rispettare e implementare completamente tutte le API di trust agent nella DevicePolicyManager, come KEYGUARD_DISABLE_TRUST_AGENTS costante.
• [C-7-3] NON DEVE implementare completamente TrustAgentService.addEscrowToken() funzionare su un dispositivo utilizzato come dispositivo personale principale (ad esempio, portatile) ma POTREBBE implementare completamente la funzione sul dispositivo implementazioni che sono tipicamente condivise (ad es. Android Television o auto e motori).
• [C-7-4] DEVE crittografare tutti i token memorizzati aggiunti da TrustAgentService.addEscrowToken().
• [C-7-5] NON DEVE archiviare la chiave di crittografia o il token del deposito a garanzia sul sullo stesso dispositivo su cui viene utilizzata la chiave. Ad esempio, è consentita Una chiave memorizzata su uno smartphone per sbloccare un account utente su una TV. Per i dispositivi Auto e motori, non è consentito archiviare il token del deposito a garanzia su qualsiasi parte del veicolo.
• [C-7-6] DEVE informare l'utente delle implicazioni relative alla sicurezza prima abilitando il token del deposito a garanzia per decriptare l'archiviazione dei dati.
• [C-7-7] DEVE disporre di un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali.
• [C-7-8] L'utente DEVE essere sottoposto a una richiesta di verifica di uno dei metodi di autenticazione principale consigliati (ad es. PIN, sequenza, password) almeno una volta ogni 72 ore o meno, a meno che per la sicurezza dell'utente (ad esempio, non si distragga dal conducente) è un problema.
• [C-7-9] L'utente DEVE essere sottoposto a verifica per uno dei metodi di autenticazione (ad es. PIN, sequenza, password) come descritto in [C-1-7] e [C-1-8] nella sezione 7.3.10, a meno che la sicurezza dell'utente (ad es. la distrazione del conducente) è un problema.
• [C-7-10] NON DEVE essere considerato una schermata di blocco sicura e DEVE seguire le i vincoli elencati in C-8 di seguito.
• [C-7-11] NON DEVE consentire TrustAgent sui dispositivi personali principali (ad esempio, una mano) per sbloccare il dispositivo e può utilizzarle solo per consente di mantenere un dispositivo già sbloccato in stato sbloccato per un massimo di per un massimo di 4 ore. L'implementazione predefinita TrustManagerService in AOSP soddisfa questo requisito.
• [C-7-12] DEVE utilizzare una crittografia sicura (ad es.UKEY2) canale di comunicazione per passare il token del deposito a garanzia dallo spazio 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 utilizza un nuovo metodo di autenticazione per sbloccare il keyguard:

• [C-8-1] Il nuovo metodo DEVE essere disattivato quando il controller dei criteri dei dispositivi (DPC) ha impostato la norma di qualità delle password tramite DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_NONE o tramite DevicePolicyManager.setRequiredPasswordComplexity() con una costante di complessità più restrittiva "PASSWORD_COMPLEXITY_NONE".
• [C-8-2] NON DEVONO reimpostare i timer per la scadenza della password impostati dal DevicePolicyManager.setPasswordExpirationTimeout()
• [C-8-3] NON DEVONO esporre un’API per l’utilizzo da parte di app di terze parti ai modificare lo stato del blocco.

Se le implementazioni del dispositivo consentono alle applicazioni di creare display virtuale e non supportano eventi di input associati, ad esempio tramite VirtualDeviceManager, l'utente:

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

Se le implementazioni del dispositivo consentono alle applicazioni di creare display virtuali secondari e supportano l'input associato ad esempio tramite VirtualDeviceManager, questi:

• [C-10-1] DEVE supportare stati di blocco separati per ogni dispositivo virtuale
• [C-10-2] DEVE disconnettere tutti i dispositivi virtuali in caso di timeout per inattività
• [C-10-3] DEVE avere un timeout per inattività
• [C-10-4] DEVE bloccare tutti i display quando l'utente avvia una blocco, ad esempio tramite l'autorizzazione dell'utente per il blocco richiesta per i dispositivi portatili (vedi Sezione 2.2.5[9.11/H-1-2])
• [C-10-5] DEVE avere istanze di dispositivi virtuali separate per utente
• [C-10-6] DEVE disabilitare la creazione di eventi di input associati tramite VirtualDeviceManager quando indicato da DevicePolicyManager.setNearbyAppStreamingPolicy
• [C-10-7] DEVE utilizzare appunti separati unicamente per ogni dispositivo virtuale (o disattiva gli appunti per i dispositivi virtuali)
• [C-10-11] DEVE disattivare l'interfaccia utente di autenticazione sui dispositivi virtuali, tra cui inserimento del fattore di conoscenza e prompt biometrico
• [C-10-12] DEVONO limitare gli intent avviati da un dispositivo virtuale alla visualizzazione solo sullo stesso dispositivo virtuale
• [C-10-13] Non DEVE utilizzare uno stato di blocco dispositivo virtuale come autenticazione utente con il sistema Android Keystore. Consulta: KeyGenParameterSpec.Builder.setUserAuthentication*.

Quando le implementazioni del dispositivo consentono all'utente di trasferire l'account principale il knowledge-factor dell'autenticazione da un dispositivo di origine a un dispositivo di destinazione, Per la configurazione iniziale del dispositivo di destinazione, questi:

• [C-11-1] DEVE crittografare il fattore di conoscenza con garanzie di protezione simili a descritti in Servizio Google Cloud Key Vault sulla sicurezza durante il trasferimento il fattore di conoscenza dal dispositivo di origine a quello di destinazione, non può essere decriptato o utilizzato per sbloccare da remoto in uno dei due dispositivi.
• [C-11-2] DEVE, sul dispositivo di origine , chiedere all'utente di confermare il fattore di conoscenza del dispositivo di origine prima di trasferire il fattore di conoscenza al dispositivo di destinazione.
• [C-11-3] DEVE essere presente su un dispositivo di destinazione privo di autenticazione principale impostata knowledge-factor, chiedere all’utente di confermare un knowledge-factor trasferito su il dispositivo target prima di impostare quel fattore di conoscenza come il knowledge-factor dell'autenticazione per il dispositivo di destinazione e prima di disponibili tutti i dati trasferiti da un dispositivo di origine.

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

• [C-12-1] DEVE chiamare grantTrust() con il flag soltanto quando è collegato a un dispositivo fisico approssimativo con una schermata di blocco propria e quando l'utente ha ha autenticato la propria identità nella schermata di blocco. I dispositivi proxy possono Utilizzare meccanismi di rilevamento sul polso o sul corpo dopo lo sblocco da parte dell'utente una volta sola per soddisfare il requisito di autenticazione dell'utente.
• [C-12-2] DEVE inserire l'implementazione del dispositivo in TrustState.TRUSTABLE stato quando lo schermo è spento (ad esempio tramite la pressione di un pulsante o un display timeout) e TrustAgent non ha revocato il trust. L'AOSP soddisfa questo requisito.
• [C-12-3] DEVE spostare il dispositivo solo da TrustState.TRUSTABLE alla stato TrustState.TRUSTED se TrustAgent continua a concedere il trust in base a i requisiti di C-12-1.
• [C-12-4] DEVE chiamare TrustManagerService.revokeTrust()
  • Dopo un massimo di 24 ore dalla concessione della fiducia o
  • Dopo una finestra di inattività di 8 ore oppure
  • Se le implementazioni non utilizzano la sicurezza crittografica e l'intervallo preciso, come definito in [C-12-5], quando la connessione sottostante al dispositivo fisico vicino.
• [C-12-5] Implementazioni che si basano su una gamma sicura e accurata per soddisfare i requisiti di [C-12-4] DEVONO utilizzare una delle seguenti soluzioni:
  • Implementazioni che utilizzano la tecnologia UWB:
    • DEVE soddisfare i requisiti di conformità, certificazione, accuratezza requisiti di calibrazione per UWB descritto nella sezione 7.4.9.
    • DEVE utilizzare una delle modalità di sicurezza P-STS elencate in 7.4.9.
  • Implementazioni che utilizzano la rete Wi-Fi Nearby Awareness Networking (NAN):
    • DEVE soddisfare i requisiti di accuratezza in 2.2.1 [7.4.2.5/H-SR-1], utilizza la larghezza di banda di 160 MHz (o superiore) e segui i passaggi di configurazione della misurazione specificati in Calibrazione della presenza.
    • DEVE utilizzare il formato LTF sicuro come definito nella IEEE 802.11az.

Se le implementazioni del dispositivo consentono alle applicazioni di creare display virtuali secondari e supportano l'input associato ad esempio tramite VirtualDeviceManager e i display non sono contrassegnati con VIRTUAL_DISPLAY_FLAG_SECURE,:

• [C-13-8] DEVE bloccare le attività con l'attributo android:canDisplayOnRemoteDevices o con i metadati android.activity.can_display_on_remote_devices impostati su false per impedirne l'avvio sulla rete virtuale. dispositivo.
• [C-13-9] DEVE bloccare le attività che non abilitano esplicitamente i flussi di dati che indicano contenuti sensibili, anche tramite SurfaceView#setSecure, FLAG_SECURE o SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS non devono essere sul dispositivo virtuale.
• [C-13-10] DEVE disattivare l'installazione delle app avviata dai dispositivi virtuali.

Se le implementazioni del dispositivo supportano stati di alimentazione separati del display tramite DeviceStateManager E supporti stati di blocco del display separati tramite KeyguardDisplayManager, l'utente:

• [C-SR-2] È VIVAMENTE CONSIGLIATO di utilizzare una riunione delle credenziali requisiti definiti nella sezione 9.11.1 o almeno una riunione biometrica Specifiche di classe 1 definite nella sezione 7.3.10 per consentire sblocco dal display predefinito del dispositivo.
• [C-SR-3] È VIVAMENTE CONSIGLIATO di limitare lo sblocco separato del display tramite un timeout del display definito.
• [C-SR-4] È VIVAMENTE CONSIGLIATO per consentire all'utente di bloccare a livello globale tutti i display tramite blocco dal dispositivo portatile principale.

9.11.2. StrongBox

Il sistema Android Keystore consente agli sviluppatori di app di archiviare le chiavi di crittografia in un processore dedicato sicuro dell'ambiente di esecuzione isolato descritto sopra. Un tale un processore sicuro dedicato si chiama "StrongBox". Requisiti C-1-3 a C-1-11 di seguito definiscono i requisiti che un dispositivo deve soddisfare per sono considerati StrongBox.

Implementazioni del dispositivo dotate di un processore sicuro dedicato:

• [C-SR-1] È VIVAMENTE CONSIGLIATO per il supporto di StrongBox. StrongBox diventerà probabilmente un requisito in una release futura.

Se le implementazioni del dispositivo supportano StrongBox:

• [C-1-1] DEVE dichiarare FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] DEVE fornire hardware sicuro dedicato che viene utilizzato per un archivio chiavi e un'autenticazione sicura degli utenti. La suite di strumenti per la sicurezza hardware può essere utilizzato anche per altri scopi.

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

• [C-1-4] DEVE garantire che le periferiche condivise con il punto di accesso non possano l'elaborazione di StrongBox in qualsiasi modo o ottenere qualsiasi informazione da StrongBox. L'AP 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 avere un vero generatore di numeri casuali che produca a distribuzione uniforme e imprevedibile.

• [C-1-7] DEVE avere resistenza alla manomissione, inclusa la resistenza contro penetrazione fisica e glitch.

• [C-1-8] DEVE avere una resistenza nel canale laterale, inclusa quella contro perdite di informazioni tramite alimentazione, temporizzazione, radiazione elettromagnetica e canali laterali delle radiazioni.

• [C-1-9] DEVE disporre di un'archiviazione sicura che garantisca riservatezza, l'integrità, l'autenticità, la coerenza e la freschezza dei contenuti. Lo spazio di archiviazione NON DEVE essere letto o alterato, ad eccezione di come consentito dalle API StrongBox.

• Per convalidare la conformità da [C-1-3] a [C-1-9], implementazioni:

  • [C-1-10] DEVE includere l'hardware certificato per la conformità ai Profilo di protezione IC sicuro BSI-CC-PP-0084-2014 oppure valutate da un laboratorio di test accreditato a livello nazionale che incorpora una valutazione di vulnerabilità con un potenziale di attacco elevato secondo Applicazione dei criteri comuni del potenziale di attacco a Smartcard.
  • [C-1-11] DEVE includere il firmware che viene valutato da un un laboratorio di test accreditato a livello nazionale che incorpora un la potenziale valutazione delle vulnerabilità secondo Applicazione dei criteri comuni del potenziale di attacco alle smartcard.
  • [C-SR-2] È VIVAMENTE CONSIGLIATO di includere l'hardware valutati utilizzando un obiettivo di sicurezza, un livello di affidabilità della valutazione (EAL) 5, ampliato da AVA_VAN.5. la certificazione EAL 5 probabilmente diventerà un requisito in una release futura.
  • [C-SR-3] È VIVAMENTE CONSIGLIATO per fornire resistenza agli attacchi interni (IAR), il che significa che un utente interno con accesso alla firma del firmware I tasti non possono produrre un firmware che causa la perdita di StrongBox segreti, per bypassare i requisiti di sicurezza funzionale o attivare l'accesso a dati utente sensibili. Il metodo consigliato per implementare IAR consente gli aggiornamenti firmware solo quando la password dell'utente principale viene fornita tramite IAuthSecret HAL.

9.11.3. Credenziale identità

Identity Credential System è definito e ottenuto implementando tutte API nel android.security.identity.* pacchetto. Queste API consentono agli sviluppatori di app di archiviare e recuperare l'identità dell'utente documenti. Implementazioni dei dispositivi:

• [C-SR-1] È VIVAMENTE CONSIGLIATO di implementare la credenziale di identità Sistema.

Se le implementazioni del dispositivo implementano il sistema delle credenziali di identità, questi:

• [C-1-1] DEVE restituire un valore diverso da null per IdentityCredentialStore#getInstance() .

• [C-1-2] DEVE implementare il sistema di credenziali di identità (ad esempio, android.security.identity.* API) con codice che comunica con un fornitore attendibile in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L’isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante il quale il codice del kernel o dello spazio utente può accedere allo stato interno isolato, inclusa la DMA.

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

• [C-1-4] L’applicazione attendibile DEVE essere implementata in modo tale che le proprietà di sicurezza non sono interessate (ad esempio, i dati delle credenziali non vengono rilasciati se non vengono soddisfatte le condizioni di controllo dell'accesso, non è possibile generare MAC per dati arbitrari) anche se Android presenta un comportamento anomalo o è compromesso.

L'Android Open Source Project upstream fornisce un riferimento implementazione di un'applicazione attendibile (libeica) utilizzabili per implementare il sistema di credenziali dell'identità.

9.12. Eliminazione dei dati

Tutte le implementazioni sui dispositivi:

• [C-0-1] DEVE fornire agli utenti un meccanismo per eseguire un "ripristino dei dati di fabbrica".
• [C-0-2] DEVE eliminare tutti i dati sul file system dei dati utente quando si esegue una "Ripristino dati di fabbrica".
• [C-0-3] DEVE eliminare i dati in modo tale da soddisfare i relativi standard di settore come NIST SP800-88 quando si esegue un Reimposta".
• [C-0-4] DEVE attivare il precedente "Ripristino dati di fabbrica" del processo quando DevicePolicyManager.wipeData() L'API viene chiamata dall'app Device Policy Controller dell'utente principale.
• POTREBBE fornire un'opzione di cancellazione dei dati rapida che esegue solo una cancellazione logica dei dati.

9.13. Modalità di avvio protetto

Android offre la modalità di avvio protetto, che consente agli utenti di avviare una determinata modalità dove possono essere eseguite solo le app di sistema preinstallate e tutte le app di terze parti le app sono disattivate. Questa modalità, nota come "modalità di avvio protetto", fornisce all'utente funzionalità per disinstallare le app di terze parti potenzialmente dannose.

Le implementazioni dei dispositivi sono:

• [C-SR-1] VIVAMENTE CONSIGLIATA di implementare la modalità di avvio protetto.

Se le implementazioni dei dispositivi implementano la modalità di avvio protetto, questi:

• [C-1-1] DEVE fornire all'utente un'opzione per attivare la modalità di avvio protetto in modo che non possa essere interrotto da installate sul dispositivo, tranne quando l'app di terze parti è un Device Policy Controller e ha impostato UserManager.DISALLOW_SAFE_BOOT segnalato come true.

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

• DOVREBBE offrire all'utente un'opzione per attivare la modalità di avvio protetto dal utilizzando un flusso di lavoro diverso da quello di un normale avvio.

9.14. Isolamento dei sistemi per veicoli automobilistici

I dispositivi Android Automotive dovrebbero scambiare dati con veicoli critici utilizzando l'HAL del veicolo per inviare e ricevere messaggi sulle reti di veicoli come il bus CAN.

Lo scambio di dati può essere protetto implementando funzioni di sicurezza di seguito Livelli di framework Android per impedire interazioni dannose o non intenzionali con questi sottosistemi.

9.15. Piani di abbonamento

"Piani di abbonamento" fare riferimento ai dettagli del piano relazione di fatturazione forniti da un operatore di telefonia mobile SubscriptionManager.setSubscriptionPlans()

Tutte le implementazioni sui dispositivi:

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

9.16. Migrazione dei dati delle applicazioni

Se le implementazioni dei dispositivi includono la possibilità di migrare i dati da un dispositivo a su un altro dispositivo e non limitare i dati dell'applicazione che vengono copiati configurate dallo sviluppatore dell'applicazione nel file manifest android:fullBackupContent l'attributo:

• [C-1-1] NON DEVE avviare trasferimenti dei dati dell'applicazione da Dispositivi su cui l'utente non ha impostato un'autenticazione principale descritti in 9.11.1 Schermata di blocco sicura e autenticazione.
• [C-1-2] DEVE confermare in modo sicuro l'autenticazione principale sull'origine dispositivo e verificare con l'intenzione dell'utente di copiare i dati nell'origine dispositivo prima del trasferimento dei dati.
• [C-1-3] DEVE utilizzare l'attestazione del token di sicurezza per garantire che sia la fonte dispositivo e dispositivo di destinazione nella migrazione tra dispositivi dispositivi Android legittimi e avere un bootloader bloccato.
• [C-1-4] DEVE eseguire la migrazione dei dati dell'applicazione soltanto alla stessa applicazione sul dispositivo di destinazione, con lo stesso nome di pacchetto E lo stesso certificato di firma.
• [C-1-5] DEVE mostrare un'indicazione che il dispositivo di origine contiene dati di dati da dispositivo a dispositivo nel menu delle impostazioni. Un utente NON DEVE essere in grado di rimuovere questa indicazione.

9.17. Framework di virtualizzazione di Android

Se il dispositivo implementa il supporto per le API Android Virtualization Framework (android.system.virtualmachine.*), l'host Android:

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

• [C-1-4] DEVE consentire solo il codice e le le app con privilegiNON DEVONO consentire codice non attendibile (ad es. app di terze parti) per creare e eseguire una macchina virtuale protetta VM VM Nota: questo aspetto potrebbe cambiare nelle future release di Android.

Se il dispositivo implementa il supporto per le API Android Virtualization Framework (android.system.virtualmachine.*), qualsiasi macchina virtuale protetta VM VM dell'istanza:

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

• [C-2-5] DEVE implementare Protected Virtual Machine VM VM meccanismi di difesa in profondità (ad es. SELinux per pVM) anche per sistemi operativi non Microdroid.
• [C-2-6] DEVE garantire che la pVM non riesca che il firmware si rifiuta di avviarsi se non è in grado di eseguire la verifica le immagini iniziali che verrà eseguita dalla VM non possono essere verificate. La verifica DEVE essere eseguita all'interno della VM.
• [C-2-7] DEVE garantire che la pVM non si avvii il firmware si rifiuta se l'integrità dell'istanza.img è compromessa.

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

• [C-3-1] DEVE garantire che le pagine di memoria vengano fornite esclusivamente di proprietà di una VM (pVM o VM host) sono accessibili solo dalla macchina stessa o dall'hypervisor, non da altre macchine virtuali, protetti o non protetti. NON DEVE consentire ad alcuna VM di accedere a una pagina appartenente a un'altra (ad es. altra pVM o hypervisor), a meno che non sia esplicitamente condivisa dalla pagina proprietario. Include la VM host. Questo vale sia per gli accessi a CPU che per DMA.
• [C-3-2] DEVE cancellare una pagina dopo che è utilizzata da una pVM e prima che venga restituito all'host (ad esempio, la pVM viene eliminata).
• [C-3-3SR-1] È VIVAMENTE CONSIGLIATO per garantire DEVONO garantire che il firmware pVM venga caricato ed eseguito prima di qualsiasi codice in una pVM.
• [C-3-4] DEVE garantire che ogni VM generi un secret per VM che {Boot Certificate Chain (BCC) and Compound Device Identifier (CDI) fornito a un'istanza pVM possa essere ottenuto solo da quella specifica istanza VM e modifiche al ripristino dei dati di fabbrica e OTA.

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

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

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

• [C-5-1] DEVE essere in grado di supportare le compilazioni isolate ma potrebbe disattivare la funzionalità Compilation isolate nella spedizione sul dispositivo di un aggiornamento del runtime ART.

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

• [C-SR-26-2] È CONSIGLIATO VIVAMENTE l'uso di DICE come meccanismo di derivazione dei secret per VM. I DICE devono essere corretti, ovvero devono fornire i valori corretti.

10. Test di compatibilità del software

Le implementazioni dei dispositivi DEVONO superare tutti i test descritti in questa sezione. Tuttavia, tieni presente che nessun pacchetto di test è del tutto completo. Per questo motivo, CONSIGLIATO VIVAMENTE gli utenti che implementano i dispositivi sono il numero minimo possibile di modifiche al riferimento e implementazione di Android disponibile tramite Android Open Source Project. In questo modo ridurrai il rischio di introdurre bug che creano incompatibilità richiedere la rielaborazione e potenziali aggiornamenti del dispositivo.

10.1 Suite di test di compatibilità

Implementazioni dei dispositivi:

• [C-0-1] DEVE superare la suite per il test di compatibilità Android (CTS). disponibili dall'Android Open Source Project, utilizzando la spedizione finale sul dispositivo.

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

Il CTS è progettato per essere eseguito su un dispositivo reale. Come per qualsiasi software, il CTS potrebbe contenere insetti. Il CTS verrà sottoposto al controllo delle versioni la Definizione di compatibilità e più revisioni del CTS possono essere rilasciate Android 14.

Implementazioni dei dispositivi:

• [C-0-3] DEVE superare l'ultima versione CTS disponibile al momento in cui il dispositivo l'avvio del software.

• DEVE usare l'implementazione del riferimento nell'albero open source di Android il più possibile.

10.2. Verificatore CTS

Lo strumento di verifica CTS è incluso nella suite di test di compatibilità. è destinato a essere eseguito da un operatore umano per testare funzionalità che non possono essere viene testato da un sistema automatizzato, come il corretto funzionamento di una videocamera e i sensori.

Implementazioni dei dispositivi:

• [C-0-1] DEVE eseguire correttamente tutti i casi applicabili nello strumento di verifica CTS.

CTS Verifier effettua test per molti tipi di hardware, tra cui alcuni che è facoltativo.

Implementazioni dei dispositivi:

• [C-0-2] DEVONO superare tutti i test sull'hardware in possesso; ad esempio, se un dispositivo è dotato di accelerometro, DEVE eseguire correttamente Scenario di test dell'accelerometro nello strumento di verifica CTS.

Scenari di test per le funzionalità indicate come facoltative da questa definizione di compatibilità Il documento POTREBBE essere ignorato o omesso.

• [C-0-2] Ogni dispositivo e ogni build DEVONO eseguire correttamente lo strumento di verifica CTS, come indicato sopra. Tuttavia, poiché molte build sono molto simili, device non è previsto che eseguano esplicitamente lo strumento di verifica CTS sulle build che differiscono solo per aspetti banali. Nello specifico, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato lo strumento di verifica CTS solo insieme di impostazioni internazionali, branding e così via. POTREBBE omettere il test del verificatore CTS.

11. Software aggiornabile

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

  • "over-the-air (OTA)" di download con aggiornamento offline tramite riavvio.
  • "Con tethering" gli aggiornamenti tramite USB da un PC host.
  • "Offline" tramite riavvio e aggiornamento da un file nella memoria rimovibile.

• [C-0-2] Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati dell'utente e i dati di Google Cloud. Vale a dire che il meccanismo di aggiornamento DEVE conservare i dati privati dell'applicazione e dati condivisi dall'applicazione. Nota che il software Android upstream include meccanismo di aggiornamento che soddisfi questo requisito.

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

• [C-SR-1] Il meccanismo di firma è VIVAMENTE CONSIGLIATO per eseguire l'hashing dell'aggiornamento con SHA-256 e convalidare l'hash in base alla chiave pubblica utilizzando ECDSA NIST P-256.

Se le implementazioni del dispositivo includono il supporto di un sistema di monitoraggio dei dati di rete come il profilo 802.11 o Bluetooth PAN (Personal Area Network), dopodiché:

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

Le implementazioni dei dispositivi DEVONO verificare che l'immagine di sistema sia identica binaria al risultato previsto in seguito a un'OTA. OTA basata su blocchi nell'Android Open Source Project a monte, aggiunta a partire da Android 5.1.

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

Se viene rilevato un errore in un'implementazione del dispositivo dopo che questo è stato rilasciato, entro la ragionevole durata del prodotto, determinata in consultazione con il team per la compatibilità Android per influire sulla compatibilità dei applicazioni, quindi:

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

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

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

12. Log delle modifiche del documento

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

• Log delle modifiche dei documenti

13. Contattaci

Puoi partecipare forum sulla compatibilità con Android e chiedere chiarimenti o sollevare eventuali problemi che a tuo parere non corrispondono al documento copertura.