Definizione di compatibilità con Android 15

1. Introduzione

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

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 un'organizzazione che sviluppa una soluzione hardware/software che esegue Android 15. Un'implementazione del dispositivo oppure "implementazione" è la soluzione hardware/software così sviluppata.

Per essere considerata compatibile con Android 15, 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 Da 4 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.

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

2.2.1. Hardware

Implementazioni di dispositivi portatili:

• [7.1.1.1/H-0-1] DEVE avere almeno uno Display compatibile con Android con misure di almeno 2,2" lato corto e 3,4" sul lato 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.

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

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

Se le implementazioni dei dispositivi portatili includono il supporto per Vulkan:

• [7.1.4.2/H-1-1] DEVE soddisfare i requisiti specificato dal profilo Baseline 2021 di Android.

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

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

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

• [7.4.3/H-SR-1] È VIVAMENTE CONSIGLIATO l'assistenza Estensione durata pacchetto di dati Bluetooth LE.

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

Termina nuovi requisiti

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 dichiarano FEATURE_BLUETOOTH_LE:

• [7.4.3/H-1-3] DEVE misurare e compensare Rx per garantire che il BLE RSSI media sia -50dBm +/-15 dB a 1 m di distanza da un dispositivo di riferimento in trasmissione alle ADVERTISE_TX_POWER_HIGH.
• [7.4.3/H-1-4] DEVE misurare e compensare i messaggi per garantire che il BLE RSSI media sia -50dBm +/-15 dB durante la scansione da un dispositivo di riferimento posizionato a una distanza di 1 m e trasmette alla ADVERTISE_TX_POWER_HIGH.

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se le implementazioni sui dispositivi portatili includono una porta USB che supporterà con un controller in funzione modalità periferica:

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

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se Per Implementazioni di dispositivi portatili che dichiarano android.hardware.audio.output e android.hardware.microphone, loro: consulta i requisiti RTL e TTL nella sezione 5.6.

• [5.6/H-1-1] DEVE avere un round-Trip continuo medio di latenza di 300 ms 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.

Termina nuovi requisiti

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 uso generico 7.10 attuatore lineare, questi:

• [7.10/H] Il posizionamento dell'attuatore deve essere posizionato vicino la posizione in cui solitamente viene tenuto o toccato con le mani.

• [7,10/H] DOVREBBE spostare l'attuatore aptico sull'asse X (sinistra-destra) dell'orientamento naturale del dispositivo.

Se le implementazioni dei dispositivi portatili hanno uno 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() su quelle di livello inferiore.

• [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
• [5.2/H-0-3] AV1

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
• [5.3/H-0-6] AV1

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 del dispositivo, incluso il tasto Recenti, funzionano come tasto di navigazione descritti nella sezione 7.2.3, che modificano l'interfaccia:

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

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.

• [3.8.16/H-1-6] Implementazioni dei dispositivi DEVE restituire con precisione l'invito dell'utente come segue:

  • Se il dispositivo ha impostato config_supportsMultiWindow=true e l'app dichiara i metadati META_DATA_PANEL_ACTIVITY nel ControlsProviderService , incluso il valore ComponentName di un'attività valida (come definita dall'API), l'app DEVE incorporare detto dell'attività in questa invito dell'utente.
  • Se l'app non dichiara metadati META_DATA_PANEL_ACTIVITY: DEVE eseguire il rendering dei campi specificati come fornito ControlsProviderService dell'API di Google ed eventuali campi specificati forniti API di controllo.

• [3.8.16/H-1-7] Se l'app dichiara i metadati META_DATA_PANEL_ACTIVITY, DEVE passare il valore dell'impostazione definita in [3.8.16/H-1-5] utilizzando EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS all'avvio dell'attività incorporata.

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.

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

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

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 un'autorizzazione utente per vedere tutte le app con uno dei due 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.

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

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 revocare l'accesso a queste app in risposta android.settings.ACTION_USAGE_ACCESS_SETTINGS l'intento.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

• [9/H-0-2] DEVE rispettare l'intent android.settings.CREDENTIAL_PROVIDER per consentire la selezione di un provider preferito per Gestore delle credenziali. Questo fornitore sarà abilitato per la compilazione automatica e sarà anche la posizione predefinita in cui salvare le nuove credenziali inserite tramite Gestore delle credenziali.

• [9/H-0-3] DEVE supportare almeno 2 provider di credenziali simultanei. e fornisci un invito all'utente nell'app Impostazioni per attivare o disattivare i provider.

Termina nuovi requisiti

Se le implementazioni del dispositivo dichiarano il supporto per android.hardware.telephony, l'utente:

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

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, SHA-1 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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [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 tra abbastanza grande da impedire alle chiavi prevenuto dall'utilizzo come permanente 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à POTREBBE essere utilizzata ogni 100.000 unità.

  Nota: per soddisfare questo requisito, devi condividere la stessa chiave di attestazione per un determinato SKU,a meno che non ne vengano prodotte almeno 100.000. Se vengono prodotte più di 100.000 unità dello SKU, una chiave diversa PUÒ essere utilizzata per ogni gruppo di 100.000 unità dopo di che. In alternativa, è possibile utilizzare la soluzione Remote Key Provisioning Eseguire il provisioning di chiavi di attestazione di breve durata sul dispositivo.

Termina nuovi requisiti

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 del dispositivo hanno una schermata di blocco sicura e includono uno o più agenti di attendibilità, che implementano l'API di sistema TrustAgentService, questi:

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

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.

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

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

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Impostazioni limitate

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

• Installazione dopo il download tramite un'applicazione (ad esempio, un'applicazione di messaggistica o un browser) diverso da uno "store" applicazione identificata da PackageManager come PACKAGE_DOWNLOADED_FILE
• Installazione da un file locale (ad esempio, l'applicazione è stata trasferita tramite sideload) identificato da PackageManager come PACKAGE_SOURCE_LOCAL_FILE

Per le autorizzazioni applicate e i relativi identificatori associati elencati di seguito:

• Sveglie e promemoria: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
• Accesso a tutti i file: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
• Mostra sopra altre app: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
• Installa app sconosciute: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
• Gestione dei contenuti multimediali: AppOpsManager.OPSTR_MANAGE_MEDIA
• Modifica le impostazioni di sistema: AppOpsManager.OPSTR_WRITE_SETTINGS
• Picture in picture: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
• Attiva schermo: AppOpsManager.OPSTR_TURN_SCREEN_ON
• Notifiche a schermo intero: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
• Controllo Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
• Accessibilità: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
• Listener di notifica: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
• Accesso ai dati di utilizzo: AppOpsManager.OPSTR_GET_USAGE_STATS
• Amministratore del dispositivo: Manifest.permission.BIND_DEVICE_ADMIN
• Non disturbare: Manifest.permission.MANAGE_NOTIFICATIONS

Queste applicazioni sono contrassegnate dalla dicitura "Applicazioni coperte" per i requisiti elencati in questa sezione.

Implementazioni dei dispositivi:

• [9.8/H-0-1] DEVE implementare le Impostazioni limitate come descritto sopra per le seguenti:

  • Autorizzazioni speciali
    .
    • Accessibilità (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
    • Listener di notifica (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
    • App di amministrazione del dispositivo (Manifest.permission.BIND_DEVICE_ADMIN)
    • Mostra sopra altre app (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
    • Accesso ai dati di utilizzo (AppOpsManager.OPSTR_GET_USAGE_STATS)
  • Ruoli (app predefinite)
    .
    • Telefono (RoleManager.ROLE_DIALER)
    • SMS (RoleManager.ROLE_SMS)
  • Autorizzazioni di runtime
    .
    • Runtime SMS (Manifest.permission_group.SMS)

• [9.8/H-0-2] DEVE abilitare Impostazioni limitate come impostazione predefinita e vengono VIVAMENTE CONSIGLIATO di non avere alcun invito all'utente che permette per disattivare le Impostazioni con restrizioni per tutte le applicazioni.

• [9.8/H-0-3] DEVE garantire che l'utente venga confermata per ogni dell'applicazione coperta prima di concedere una qualsiasi delle autorizzazioni applicate.

• [9.8/H-0-4] DEVE consentire solo la conferma all'utente per attivare le impostazioni limitate dalla pagina AppInfo dell'Applicazione coperta, utilizzando l'API EnhancedConfirmationManager.

• [9.8/H-0-5] È VIVAMENTE CONSIGLIATO di integrare e chiamare AdvancedConfirmationManager per tutte le autorizzazioni speciali, per determinare in modo dinamico se si tratta di un'impostazione con restrizioni.

  • Sveglie e promemoria: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
  • Accesso a tutti i file: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
  • Mostra sopra altre app: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
  • Installa app sconosciute: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
  • Gestione dei contenuti multimediali: AppOpsManager.OPSTR_MANAGE_MEDIA
  • Modifica le impostazioni di sistema: AppOpsManager.OPSTR_WRITE_SETTINGS
  • Picture in picture: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
  • Attiva schermo: AppOpsManager.OPSTR_TURN_SCREEN_ON
  • Notifiche a schermo intero: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
  • Controllo Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
  • Accessibilità: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
  • Listener di notifica: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
  • Accesso ai dati di utilizzo: AppOpsManager.OPSTR_GET_USAGE_STATS
  • Amministratore del dispositivo: Manifest.permission.BIND_DEVICE_ADMIN
  • Non disturbare: Manifest.permission.MANAGE_NOTIFICATIONS

di Gemini Advanced.

Nota: l'Android Open Source Project (AOSP) upstream soddisfa questo requisito impostando config_enhancedConfirmationModeEnabled di true nella file di configurazione, e l'integrazione EnhancedConfirmationManager all'API.

Termina nuovi requisiti

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, di riconoscimento vocale o on-device 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 (esclusi gli stream audio) da trasmettere dal servizio di rilevamento hotword su ogni risultato della hotword.
• [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-1-15] DEVE garantire che gli stream audio siano forniti su una hotword riuscita vengono trasmessi in modo unidirezionale dal servizio di rilevamento hotword al servizio di interazione vocale.

• [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 riconoscimento vocale sul dispositivo di riconoscimento dei volti delle celebrità basata su rigidi criteri di controllo.

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

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

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.
• [9.8.2/H-4-3] Non DEVE nascondere l'indicatore del microfono per app di sistema con interfacce utente visibili o interazione diretta degli utenti.
• [9.8.2/H-4-4] DEVE visualizzare l'elenco delle categorie Recenti e Attive app che usano il microfono come restituito da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.

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

• [9.8.2/H-5-1] DEVE visualizzare l'indicatore della fotocamera quando 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.
• [9.8.2/H-5-3] Non DEVE nascondere l'indicatore della fotocamera per app di sistema con interfacce utente visibili o interazione diretta degli utenti.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

• [9.10/H-1-1] DEVE verificare tutte le partizioni di sola lettura montate durante la sequenza di avvio di Android e il digest VBMeta deve includere nel calcolo tutte queste partizioni verificate.

di Gemini Advanced.

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

Termina nuovi requisiti

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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 programma 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 in la documentazione perfetta.
  • [6.1/H-0-6]* Il daemon tracciato perfetto DEVE essere attivata per impostazione predefinita (proprietà di sistema persist.traced.enable).

Termina nuovi requisiti

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.U 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 14.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [5.1/H-1-2] DEVE supportare 6 istanze del decodificatore video hardware a 8 bit (SDR) (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 3 sessioni a risoluzione 1080p a 30 fps e 3 sessioni a 4k risoluzione@30 f/s, tranne AV1. Per tutte le sessioni, NON DEVE essere presente più di un frame. cala al secondo. I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare sei istanze a 1080p30 f/s.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [5.1/H-1-4] DEVE supportare 6 istanze del codificatore video hardware a 8 bit (SDR) (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 4 sessioni a risoluzione 1080p a 30 fps e 2 sessioni a 4k risoluzione@30 f/s, tranne AV1. Per tutte le sessioni, NON DEVE essere presente più di un frame. cala al secondo. I codec AV1 devono solo supportare la risoluzione 1080p, ma sono comunque necessaria per supportare 6 istanze a 1080p30 f/s.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [5.1/H-1-6] DEVE supportare 6 istanze del decodificatore video hardware a 8 bit (SDR) e codificatori video hardware (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 3 sessioni a 4K a 30 fps (a meno che AV1), di cui al massimo 2 sono sessioni dell'encoder e 3 sessioni con una risoluzione di 1080p. Per tutte le sessioni, NON DEVE essere presente più di un frame. cala al secondo. I codec AV1 devono solo supportare la risoluzione 1080p, ma sono comunque necessaria per supportare 6 istanze a 1080p30 f/s.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [5.1/H-1-19] DEVE supportare 3 istanze del decodificatore video hardware a 10 bit (HDR) e codificatori video hardware (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a una risoluzione di 4K a 30 f/s (a meno che AV1) di cui al massimo una è una sessione del codificatore, che può essere configurata in Formato di input RGBA_1010102 attraverso una superficie GL. Per in tutte le sessioni, NON DEVE essere ignorato più di un frame per al secondo. Generazione di metadati HDR da parte dell'encoder non è necessario se la codifica dalla superficie GL. Le sessioni codec AV1 necessario per supportare la risoluzione 1080p anche quando questo requisito richiede per 4K.

Termina nuovi requisiti

• [5.1/H-1-7] DEVE avere una latenza di inizializzazione del codec di 40 ms o meno per un Sessione di codifica video a 1080p o inferiore per tutti i codificatori video hardware quando sotto carico. Per caricare qui si intende una risoluzione simultanea di solo video da 1080p a 720p sessione di transcodifica utilizzando codec video hardware insieme alla piattaforma l'inizializzazione della registrazione audio-video. Per il codec Dolby Vision, il codec la latenza di inizializzazione DEVE essere pari o inferiore a 50 ms.
• [5.1/H-1-8] DEVE avere una latenza di inizializzazione del codec di 30 ms o meno per Sessione di codifica audio a 128 Kbps o con velocità in bit inferiore per tutti i codificatori audio quando sotto carico. Per caricare qui si intende una risoluzione simultanea di solo video da 1080p a 720p sessione di transcodifica utilizzando codec video hardware insieme alla piattaforma l'inizializzazione della registrazione audio-video.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [5.1/H-1-9] DEVE supportare 2 istanze del decodificatore video hardware sicuro (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a risoluzione 4K a 30 fps (a meno che AV1) sia per 8-bit (SDR) che per Contenuti HDR a 10 bit. Per tutte le sessioni, NON DEVE essere presente più di un frame. cala al secondo. Le sessioni codec AV1 sono necessarie solo per supportare la risoluzione 1080p anche quando questo requisito richiede il 4K.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [5.1/H-1-10] DEVE supportare 3 istanze di decodificatore video hardware non protetto sessioni insieme a 1 istanza di sessione di decodifica video hardware sicura (4 istanze in totale) (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 3 sessioni a risoluzione 4K a 30 f/s (tranne AV1) che include una sessione decoder sicura e 1 sessione nn-secure a 1080p risoluzione a 30 fps dove al massimo 2 sessioni possono essere in HDR a 10 bit. Per tutte le sessioni, NON DEVE essere presente più di un frame. cala al secondo. Le sessioni codec AV1 sono necessarie solo per supportare la risoluzione 1080p anche quando questo requisito richiede il 4K.

Termina nuovi requisiti

• [5.1/H-1-11] DEVE supportare un decodificatore sicuro per ogni hardware AVC, HEVC, VP9 o AV1 sul dispositivo.
• [5.1/H-1-12] DEVE avere una latenza di inizializzazione del codec di 40 ms o meno per un Sessione di decodifica video a 1080p o inferiore per tutti i decodificatori video hardware quando sotto carico. Il caricamento qui corrisponde a una risoluzione simultanea da 1080p a 720p sessione di transcodifica solo video utilizzando codec video hardware insieme al Inizializzazione della riproduzione audio-video a 1080p. Per il codec Dolby Vision, il codec la latenza di inizializzazione DEVE essere pari o inferiore a 50 ms.
• [5.1/H-1-13] DEVE avere una latenza di inizializzazione del codec di 30 ms o meno per un Sessione di decodifica audio a 128 Kbps o con velocità in bit inferiore per tutti i decoder audio quando sotto carico. Per caricare qui si intende una risoluzione simultanea di solo video da 1080p a 720p sessione di transcodifica utilizzando codec video hardware insieme alla piattaforma inizializzazione della riproduzione audio/video.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [5.1/H-1-22] DEVE supportare la codifica, la decodifica, l'editing GPU e la visualizzazione dei video contenuti nelle proporzioni verticali, indipendentemente dai metadati di rotazione la videocamera più grande supportata o 4K, a seconda di quale sia inferiore. Nota: questo include i profili HDR se il codec supporta HDR. I codec AV1 sono necessari solo per supportare la risoluzione 1080p. Questo requisito riguarda solo codec hardware, GPU e la DPU.

Termina nuovi requisiti

• [5.3/H-1-1] NON DEVE cadere più di 1 fotogramma in 10 secondi (ossia, meno di caduta di fotogrammi dello 0,167%) per una sessione video 4K a 60 f/s sotto carico.
• [5.3/H-1-2] NON DEVE saltare più di 1 fotogramma in 10 secondi durante un video variazione della risoluzione in una sessione video a 60 f/s sotto carico per una sessione in 4K.
• [5.6/H-1-1] DEVE avere una latenza tocco per toni di 80 millisecondi o meno utilizzando il test del tocco su tono di CTS Verifier.
• [5.6/H-1-2] DEVE avere una latenza audio di andata e ritorno di 80 millisecondi o in almeno un percorso dei dati supportato.
• [5.6/H-1-3] DEVE supportare un audio >= 24 bit per un'uscita stereo superiore a 3,5 mm se presenti e tramite audio USB se supportato attraverso tutti i dati per configurazioni a bassa latenza e flussi di dati. Per la bassa latenza AAudio deve essere usato dall'app con un callback a bassa latenza . Per la configurazione dello streaming, occorre utilizzare Java AudioTrack l'app. Sia nelle configurazioni a bassa latenza che in quelle di flussi di dati, l'HAL il sink di output deve accettare AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT o AUDIO_FORMAT_PCM_FLOAT per il formato di output di destinazione.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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

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

• [5.1/H-1-17] DEVE avere almeno 1 decodificatore di immagini hardware che supporti il formato AVIF Profilo di riferimento.
• [5.1/H-1-18] DEVE supportare il codificatore AV1 in grado di codificare fino a 480p a 30 f/s e 1 Mbps.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [5.1/H-1-20] DEVE supportare lo standard Feature_HdrEditing per tutti i codificatori hardware AV1 e HEVC presenti sul dispositivo in 4K o alla massima risoluzione supportata dalla fotocamera, a seconda di quale delle due opzioni è inferiore.

Termina nuovi requisiti

• [5.12/H-SR] È vivamente consigliato supportare il supporto Feature_HdrEditing per tutti i codificatori hardware AV1 e HEVC presenti sul dispositivo.
• [5.12/H-1-2] DEVE supportare il formato colore RGBA_1010102 per tutto l'hardware AV1 e Codificatori HEVC presenti sul dispositivo.
• [5.12/H-1-3] DEVE pubblicizzare il supporto dell'estensione EXT_YUV_target per campione da texture YUV a 8 e 10 bit.
• [7.1.4/H-1-1] DEVE avere almeno 6 overlay hardware nell'elaborazione del display (DPU), di cui almeno due sono in grado di visualizzare contenuti video a 10 bit.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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

2.2.7.2. Fotocamera

Se le implementazioni dei dispositivi portatili restituiscono android.os.Build.VERSION_CODES.U 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 14.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [7.5/H-1-18] DEVE supportare JPEG_R per la parte posteriore e fotocamere anteriori principali.
• [7.5/H-1-19] DEVE supportare CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION per 1080p HLG10 anteprima con dimensione massima JPEG 16:9 e per anteprima HLG10 a 720p con combinazioni di stream JPEG con proporzioni massime di 16:9 per l'annuncio principale fotocamera posteriore.
• [7.5/H-1-20] DEVE per impostazione predefinita l'output JPEG_R per l'output fotocamere posteriori e anteriori principali nell'app Fotocamera nativa.

Termina nuovi requisiti

2.2.7.3. Hardware

Se le implementazioni dei dispositivi portatili restituiscono android.os.Build.VERSION_CODES.U 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.3 di Android 14.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

• [7.1.1.3/H-3-1] DEVE avere un display HDR che supporta almeno 1000 nit media.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

2.2.7.4. Prestazioni

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

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

2.2.7.5. Grafica

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

• [7.1.4.1/H-1-1]
  Questo requisito è stato ritirato da Android 15 (sperimentale AOSP).
• [7.1.4.1/H-1-2] DEVE supportare la EGL_IMG_context_priority: e EGL_EXT_protected_content estensioni.
• [7.1.4.1/H-1-3] DEVE supportare VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory: e VK_KHR_global_priority.

Termina nuovi requisiti

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 una distanza di circa 3 metri (i "polsi all'indietro" o "3 metri di distanza" 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
• [5.2/T-0-3] AV1

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
• [5.3.2/T-0-7] AV1

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 la modalità di uscita HDMI su risoluzione più alta per il formato pixel scelto che funziona con 50 Hz o 60 Hz frequenza di aggiornamento per il display esterno, in base a quella del video la regione in cui viene venduto il dispositivo.
• [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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Implementazioni di dispositivi televisivi:

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

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Android Television Input Framework (TIF) semplifica il distribuzione di contenuti in diretta ai dispositivi Android TV. Il TIF offre uno standard API per creare moduli di input che controllano i dispositivi Android Television.

Implementazioni di dispositivi televisivi:

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

Android Television Tuner Framework (TF) unifica la gestione dei contenuti live su Tuner con i contenuti in streaming dall'IP sui dispositivi Android TV. Il framework Turner fornisce un'API standard per creare servizi di input che usano Android Television Tuner.

Se le implementazioni dei dispositivi supportano Tuner, questi:

• [3/T-1-1] DEVE supportare tutte le API Tuner Framework in modo che che utilizza queste API può essere installata e utilizzata sul dispositivo.

Termina nuovi requisiti

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, SHA-1 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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [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 tra abbastanza grande da impedire alle chiavi prevenuto dall'utilizzo come permanente 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à POTREBBE essere utilizzata ogni 100.000 unità.

  Nota: per soddisfare questo requisito, devi condividere la stessa chiave di attestazione per un determinato SKU,a meno che non ne vengano prodotte almeno 100.000. Se vengono prodotte più di 100.000 unità dello SKU, una chiave diversa PUÒ essere utilizzata per ogni gruppo di 100.000 unità dopo di che. In alternativa, è possibile utilizzare la soluzione Remote Key Provisioning Eseguire il provisioning di chiavi di attestazione di breve durata sul dispositivo.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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 in la documentazione perfetta.
  • [6.1/T-0-5] Il daemon tracciato perfetto DEVE essere abilitato per impostazione predefinita (proprietà di sistema persist.traced.enable).

Termina nuovi requisiti

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 dei dispositivi Watch includono il supporto per Vulkan:

• [7.1.4.2/W-1-1] DEVE soddisfare i requisiti specificato dal profilo Baseline 2021 di Android.

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.

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

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

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se le implementazioni dei dispositivi Automotive supportano la modalità multiutente simultanea (dove più utenti Android possono interagire con il dispositivo contemporaneamente, ognuno con il proprio display config_multiuserVisibleBackgroundUsers è abilitato), questi:

• [7.1.1.1/A-1-1] DEVE avere una schermata separata di almeno 6 pollici di diagonale fisica per ogni zona degli occupanti per il schermata principale. Deve essere codificato come CarOccupantZoneManager.DISPLAY_TYPE_MAIN per ogni zona degli occupanti.
• [7.1.1.1/A-1-2] DEVE avere un layout a dimensioni dello schermo di almeno 750 dp x 480 dp per ogni display principale.

Termina nuovi requisiti

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 il supporto per Vulkan:

• [7.1.4.2/A-1-1] DEVE soddisfare i requisiti specificato dal profilo Baseline 2021 di Android.

Implementazioni di dispositivi nel settore auto e motori:

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [7.1.7/A-0-1] DEVE configurare display secondari nella linea dello sguardo del conducente, FLAG_PRIVATE.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [7.2.3/A-0-1] DEVE fornire La home page e Indietro,e POTREBBE fornire Indietro e il Funzioni recenti.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se le implementazioni dei dispositivi Automotive supportano la modalità multiutente simultanea (dove più utenti Android possono interagire con il dispositivo contemporaneamente, ognuno con il proprio display config_multiuserVisibleBackgroundUsers è abilitato), questi:

• [7.3/A-1-1] DEVE impostare il valore NIGHT_MODE: segnalare il valore in modo coerente con la modalità giorno/notte della dashboard su tutti i display, compresi quelli dei sedili posteriori.

Termina nuovi requisiti

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 intervallo di misurazione del giroscopio a +/-250 dps per massimizzare la risoluzione possibile.

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

• [7.3.4/A-SR-2] È VIVAMENTE CONSIGLIATO di implementare 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).

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [7.4.3/A-SR-1] È VIVAMENTE CONSIGLIATA all'assistenza Profilo di accesso ai messaggi (MAP) se il dispositivo si trova nella zona degli occupanti del conducente.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se le implementazioni dei dispositivi Automotive supportano la modalità multiutente simultanea (dove più utenti Android possono interagire con il dispositivo contemporaneamente, ognuno con il proprio display config_multiuserVisibleBackgroundUsers è abilitato), questi:

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

Termina nuovi requisiti

Implementazioni di dispositivi nel settore auto e motori:

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

Se le implementazioni del dispositivo includono il supporto per la trasmissione radio AM/FM ed espongono la funzionalità a qualsiasi applicazione, devono:

• [7,4/A-1-1] DEVE dichiarare il supporto per FEATURE_BROADCAST_RADIO.

Per fotocamera posteriore si intende una fotocamera rivolta verso il mondo che può essere collocata in qualsiasi posto sul veicolo ed è rivolto verso l'esterno dell'abitacolo; cioè immagini di scena all'estremità della carrozzeria del veicolo, come la fotocamera di retrovisione.

Per fotocamera anteriore si intende una fotocamera rivolta all'utente, che può essere posizionata in qualsiasi posto sul veicolo ed è rivolto verso l'interno dell'abitacolo; ecco fatto immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.

Implementazioni di dispositivi nel settore auto e motori:

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

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

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

Se le implementazioni dei dispositivi Auto e motori includono almeno una fotocamera, rivolto verso l'utente, per una videocamera di questo tipo:

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

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

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

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

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

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

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

Se le implementazioni dei dispositivi per auto e motori includono una o più fotocamere che sono accessibile tramite il servizio di sistema di visualizzazione estesa e android.hardware.Camera o l'API android.hardware.Camera2, per una videocamera di questo tipo:

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

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

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

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 (/data partizione).

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se le implementazioni dei dispositivi Automotive supportano la modalità multiutente simultanea (dove più utenti Android possono interagire con il dispositivo contemporaneamente, ognuno con il proprio display config_multiuserVisibleBackgroundUsers è abilitato), questi:

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

Termina nuovi requisiti

Se le implementazioni dei dispositivi Automotive sono a 64 bit:

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

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

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

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

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

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

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

  • 560 dpi o superiore su schermi piccoli/normali
  • 400 dpi o superiore su schermi di grandi dimensioni
  • xhdpi o superiore su schermi 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.

Termina nuovi requisiti

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se le implementazioni dei dispositivi Automotive supportano la modalità multiutente simultanea (dove più utenti Android possono interagire con il dispositivo contemporaneamente, ognuno con il proprio display config_multiuserVisibleBackgroundUsers è abilitato), questi:

• [7.8.2/A-1-1] DEVE avere un dispositivo di uscita audio per ogni per i sistemi di più utenti in contemporanea.
• [7.8.2/A-1-2] DEVE avere una zona audio Driver che copra i lo speaker dell'abitacolo. La zona passeggero anteriore può condividere l'audio del conducente o può avere una propria uscita audio.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se le implementazioni dei dispositivi Automotive supportano la modalità multiutente simultanea (dove più utenti Android possono interagire con il dispositivo contemporaneamente, ognuno con il proprio display config_multiuserVisibleBackgroundUsers è abilitato), questi:

• [5.5.3/A-1-1] DEVE definire curve di volume identiche per tutti gli stream di output audio mappati allo stesso gruppo di volume come definito nel di configurazione dell'audio dell'auto.

Termina nuovi requisiti

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Se le implementazioni dei dispositivi Automotive supportano la modalità multiutente simultanea (dove più utenti Android possono interagire con il dispositivo contemporaneamente, ognuno con il proprio display config_multiuserVisibleBackgroundUsers è abilitata), Per gli utenti secondari completi che non sono l'utente corrente in primo piano ma hanno accesso all'interfaccia utente per il display, questi:

• [3.8/A-1-1] DEVE implementare il seguente elenco predefinito di UserRestrictions:

  • DISALLOW_CONFIG_LOCALE
  • DISALLOW_CONFIG_BLUETOOTH
  • DISALLOW_BLUETOOTH
  • DISALLOW_CAMERA_TOGGLE
  • DISALLOW_MICROPHONE_TOGGLE

• [3.8/A-1-2] NON DEVE consentire a quell'utente di modificare le seguenti impostazioni per qualsiasi altro utente, tramite le impostazioni o un'API:

  • modalità giorno/notte
  • impostazioni internazionali
  • data
  • ora
  • fuso orario
  • le funzionalità di colore del display (tra cui luminosità, luminosità notturna, Benessere digitale scala di grigi e Riduci colori vivaci)

Termina nuovi requisiti

Implementazioni di dispositivi nel settore auto e motori:

• [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.microphone, l'utente:

• [9.8.2/A-1-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 indicati in sezione 9.1 con l'identificatore CDD [C-4-X].
• [9.8.2/A-1-2] Non DEVE nascondere l'indicatore del microfono per app di sistema con interfacce utente visibili o interazione diretta degli utenti.
• [9.8.2/A-1-3] DEVE fornire un'invito all'utente per attivare/disattivare microfono nell'app Impostazioni.

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 accedono le app con i ruoli definiti in Sezione 9.1 Autorizzazioni con identificatore CDD [C-4-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.
• [9.8.2/A-2-3] DEVE fornire all'utente l'autorizzazione ad attivare/disattivare la fotocamera nell'app Impostazioni.
• [9.8.2/A-2-4] DEVE visualizzare le app recenti e attive che utilizzano la fotocamera così come sono state restituite. da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.

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, SHA-1 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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [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 tra abbastanza grande da impedire alle chiavi prevenuto dall'utilizzo come permanente 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à POTREBBE essere utilizzata ogni 100.000 unità.

  Nota: per soddisfare questo requisito, devi condividere la stessa chiave di attestazione per un determinato SKU,a meno che non ne vengano prodotte almeno 100.000. Se vengono prodotte più di 100.000 unità dello SKU, una chiave diversa PUÒ essere utilizzata per ogni gruppo di 100.000 unità dopo di che. In alternativa, è possibile utilizzare la soluzione Remote Key Provisioning Eseguire il provisioning di chiavi di attestazione di breve durata sul dispositivo.

Termina nuovi requisiti

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.

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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 in la documentazione perfetta.
  • [6.1/A-0-5] Il daemon tracciato perfetto DEVE essere abilitato per impostazione predefinita (proprietà di sistema persist.traced.enable).

Termina nuovi requisiti

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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 i comportamenti di qualsiasi API documentata esposta SDK per Android o qualsiasi API decorata con "@SystemApi" indicatore nell'Android a monte 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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-0-8] NON DEVE supportare l'installazione di applicazioni destinate a un livello API meno di 23 24.

Termina nuovi requisiti

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 indicate nella sezione 3.1, Android include anche un importante elemento "soft" API, 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 15.
VERSIONE.SDK	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 15, questo campo DEVE avere il valore intero 15_INT.
VERSION.SDK_INT	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 15, questo campo DEVE avere il valore intero 15_INT.
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 espressione regolare ^[^ :\/~]+$.
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_-]+$.
ABIS_SUPPORTATO	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à.
SUPPORTO_64_BIT_ABIS	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) di il 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 il 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:15/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 dell'espressione ^[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 ("").
SICUREZZA_PATCH	Un valore che indica il livello patch di sicurezza di una build. DEVE indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti 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".
BASE_OS	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 consentono ogni pattern di intent a cui si fa riferimento nella sezione 3.2.3.1; ad eccezione delle Impostazioni, che deve essere sostituito da applicazioni di terze parti. 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 del "Selettore" utente 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 rispetto 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 e 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 e 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 il comando '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 e 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.

Se le implementazioni dei dispositivi segnalano android.hardware.nfc.uicc o android.hardware.nfc.ese, l'utente:

• [C-19-1] DEVE implementare NfcAdapter.ACTION_TRANSACTION_DETECTED API Intent (come "EVT_TRANSACTION" definita dalle specifiche tecniche dell'associazione GSM TS.26 - Requisiti per i dispositivi NFC).

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

• [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 nucleo 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 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 15 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. come 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 "Widget App" 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. Per 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 prevedono che l'utente autorizzi il posticipo delle 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 create 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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

3.8.3.4. Protezione delle notifiche sensibili

Le informazioni di notifica sensibili includono contenuti quali password monouso, codici di conferma monouso e codici di autenticazione o reimpostazione simili che possono apparire in: notifiche agli utenti.

Se le implementazioni del dispositivo consentono ad app di terze parti di informare gli utenti di eventi importanti; l'utente:

• [C-1-1] DEVE oscurare le informazioni sensibili di notifica affinché non vengano trasmesse a listener di notifiche, a meno che il servizio listener sia uno dei seguenti:

  • App firmate dal sistema con uid < 10.000
  • UI di sistema
  • Conchiglia
  • App del dispositivo associato designata (definita da CompanionDeviceManager)
  • Ruolo SYSTEM_AUTOMOTIVE_PROJECTION
  • Ruolo SYSTEM_NOTIFICATION_INTELLIGENCE
  • Ruolo HOME

L'implementazione di AOSP NotificationAssistantServices esemplificano e rispettano questi requisiti. Consulta android.ext.services.notification per vedere un esempio.

Termina nuovi requisiti

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. 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 applicare stili di un'intera attività o applicazione.

Android include un "Holo" e "Materiale" 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 il campo "Material" famiglia di temi 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 un'opzione "Predefinito dispositivo" famiglia di temi come un 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à utilizzando un'immagine in 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 di 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 i caratteri non conformi a Unicode, comunemente noti come "Zawgyi", per il rendering di 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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se le implementazioni dei dispositivi includono più di una le aree di visualizzazione e le rende disponibili per le app, queste:

• [C-4-1] DEVE supportare la modalità multi-finestra.

Se le implementazioni dei dispositivi supportano le modalità multi-finestra:

• [C-5-1] DEVE implementare la versione corretta delle estensioni di Window Manager di API come descritto in WindowManager Estensioni.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Android include funzioni che consentono la sicurezza applicazioni attivano applicazioni controller dei criteri dei dispositivi da 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 API Device Policy Manager.

Se le implementazioni dei dispositivi implementano l'intera gamma di amministrazione del dispositivo 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.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

• [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
  • Icona dell'applicazione DPC.

• [C-1-4] DEVE lanciare 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. Assistenza per i 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.
• [C-1-10] DEVE garantire che i dati degli screenshot vengano salvati nel profilo di lavoro spazio di archiviazione quando si acquisisce uno screenshot topActivity finestra con stato attivo (l'ultima con cui l'utente ha interagito tra tutte le attività) e a cui appartiene un'app del profilo di lavoro.
• [C-1-11] NON DEVE acquisire altri contenuti dello schermo (barra di sistema, notifiche o contenuti del profilo personale), ad eccezione del profilo di lavoro finestra/finestre dell'applicazione quando salvi uno screenshot nel profilo di lavoro (per garantire che i dati i dati del profilo non vengono salvati nel profilo di lavoro).

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 per gli 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 per la gestione dei criteri relativi ai 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.9.5. Framework per la risoluzione dei criteri relativi ai dispositivi

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

• [C-1-1] DEVE risolvere i conflitti dei criteri relativi ai dispositivi come documentato in Framework di risoluzione di Device Policy.

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

3.12. Framework input TV

Android Television Input Framework (TIF) semplifica il distribuzione di contenuti in diretta ai dispositivi Android TV. Il TIF offre uno standard API 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.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-1-3] DEVE fornire gli inviti all'utente affinché possa selezionare/confermare un sia presente e operativo, che DEVE utilizzare lo stesso messaggio implementato in AOSP senza aggiunta o modificata.

Termina nuovi requisiti

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

3,19. Impostazioni della lingua

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE fornire all'utente alcun invito per selezionare un genere specifico trattamento linguistico per le lingue che non supportano il genere specifico le traduzioni. Consulta le risorse grammaticali per ulteriori informazioni.

Termina nuovi requisiti

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.

di Gemini Advanced.

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

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
• [C-0-4] AVIF
  • I dispositivi devono supportare BITRATE_MODE_CQ e Baseline Profile.

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, profilo di riferimento della sequenza di immagini	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 (diverse 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 nei dispositivi supportano qualsiasi codificatore video e lo mettono a disposizione app di terze parti e imposta
Da MediaFormat.KEY_BITRATE_MODE a BITRATE_MODE_VBR in modo che l'encoder operi in modalità a velocità in bit variabile, quindi purché ciò non influisca sulla qualità minima richiesta, la velocità in bit codificata :

• NON DOVREBBE essere superiore a uno finestra scorrevole, oltre il 15% in più della velocità in bit tra intraframe (I-frame) intervalli.
• NON DEVE essere superiore a 100% rispetto alla velocità in bit su una finestra scorrevole di 1 secondo.

Se le implementazioni nei dispositivi supportano qualsiasi codificatore video e lo mettono a disposizione app di terze parti e impostare Da MediaFormat.KEY_BITRATE_MODE a BITRATE_MODE_CBR in modo che il codificatore operi in modalità a velocità in bit costante, quindi la velocità in bit codificata:

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

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.

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.
• [C-SR-1] è VIVAMENTE CONSIGLIATO per supportare Profilo SD 720 x 480 e 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.2.6. AV1

Se le implementazioni dei dispositivi supportano il codec AV1:

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

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

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

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

• [C-2-1] DEVE supportare fino al profilo di codifica HD1080p incluso dal riportata di seguito:

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

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 fps 384 Kbps) e Livello 45 (QCIF e risoluzioni SQCIF a 30 fps 128 Kbps).

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

• [C-1-1] DEVE supportare Main Profile Level 3.1 e Baseline Profile. 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/s^televisore)
Velocità in bit video	800 kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

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

• [C-1-1] DEVE supportare il livello principale 3 del profilo principale e 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/s^televisore con decodifica hardware H.265)	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se le implementazioni del dispositivo dichiarano di supportare un profilo HDR tramite 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/s^televisore)	30 (60 f/s^televisore)
Velocità in bit video	800 kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

• [C-1-1] DEVE supportare i profili di decodifica video SD come indicato nella 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/s^televisore con decodifica hardware VP9)	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se le implementazioni 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, l'utente:

• [C-1-1] DEVE fornire un estrattore compatibile con Dolby Vision.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-1-2] DEVE visualizzare correttamente i contenuti in Dolby Vision o sul dispositivo schermo o su un display esterno collegato tramite una porta di uscita video standard (ad es. HDMI).

Termina nuovi requisiti

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

Se le implementazioni dei dispositivi supportano il codec AV1 e lo rendono disponibile ad applicazioni di terze parti, questi:

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

Se le implementazioni del dispositivo forniscono supporto per il codec AV1 con un hardware decoder accelerato, allora:

• [C-2-1] DEVE essere in grado di decodificare almeno i profili di decodifica video HD 720p da la tabella seguente quando l'altezza riportata da Display.getSupportedModes() è uguale o superiore a 720p.
• [C-2-2] DEVE essere in grado di decodificare almeno i profili di decodifica video in HD a 1080p dalla tabella seguente quando l'altezza riportata da Display.getSupportedModes() è uguale o superiore a 1080p.

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

Se le implementazioni del dispositivo supportano il profilo HDR tramite le API Media, l'utente:

• [C-3-1] DEVE supportare l'estrazione e l'output di metadati HDR dai bitstream e/o container.
• [C-3-2] DEVE visualizzare correttamente i contenuti HDR sullo schermo del dispositivo o su una porta di uscita video standard (ad esempio, HDMI).

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 riprodotto a 90 dB Livello di pressione sonora (SPL) (misurato 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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-1-4] DEVE supportare gli effetti audio con di input e output in virgola mobile, quando l'effetto vengono restituiti alla pipeline audio del framework. Si riferisce ai tipici effetti insert o aux come l'equalizzatore. Il comportamento equivalente è elevato è consigliato quando i risultati dell'effetto non sono visibili dall'audio del framework (ad esempio effetti di post-elaborazione o download di effetti).

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-1-5] DEVE assicurarsi che gli effetti audio supportino più canali fino a il numero di canali del mixer, noto anche come FCC_LIMIT, quando i risultati dell'effetto vengono restituiti alla pipeline audio del framework. Questo si riferisce ai tipici effetti insert o aux, ma esclude effetti speciali come come effetti di downmix, upmix e spazializzazione, che cambiano il numero di canali. Il comportamento equivalente è consigliato quando gli effetti non sono visibili pipeline audio del framework (ad esempio, effetti).

Termina nuovi requisiti

• 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 (MAD). La media del valore assoluto del deviazioni dalla media di un insieme di valori.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• La latenza tocco per tono (TTL), misurata da CTS Verifier, è il tempo tra il momento in cui viene toccato lo schermo e il momento in cui viene generato un segnale acustico l'altoparlante suona il tocco. La media di questa metrica viene calcolata su 5 misurazioni utilizzando Un'API audio nativa audio per l'output.

• La latenza Round-Trip (RTL), misurata dallo strumento di verifica CTS, è la media Latenza continua su 5 misurazioni, misurata su un percorso di loopback che alimenta l'output all'input, utilizzando l'API AAudio native audio. I percorsi di loopback sono:

  • Altoparlante/microfo: altoparlante integrato nel microfono integrato.
  • Analogico: jack analogico da 3,5 mm e un adattatore di loopback.
  • USB: adattatore da USB a 3,5 mm e un adattatore loopback o un adattatore audio USB cavi di interfaccia e di loopback.

• FEATURE_AUDIO_PRO La funzionalità android.hardware.audio.pro è dichiarate.

• MPC. Classe di rendimento dei media

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• latenza del tracciamento dei movimenti della testa. L'ora in cui prende dal movimento della testa acquisito dall'unità di misura inerziale (IMU) ai trasduttori delle cuffie il rilevamento del cambiamento del suono causato da questo movimento.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-1-4] Latenze di andata e ritorno calcolate in base a input e output i timestamp restituiti da AAudioStream_getTimestamp DEVONO essere entro 200 msec da la latenza di andata e ritorno misurata per AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY per altoparlanti, con cavo e wireless cuffie.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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 sullo speaker percorso dati.

• [C-SR-2] Latenza Tono per tocco di 80 millisecondi o inferiore.

• [C-SR-4] Latenze di andata e ritorno calcolate in base a input e output i timestamp restituiti da AAudioStream_getTimestamp sono VIVAMENTE CONSIGLIATI a 30 msec dalla latenza di round trip misurata AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY per altoparlanti, cuffie con cavo e wireless.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Nella tabella seguente sono definiti i requisiti per la tecnologia RTL per il dispositivo portatile implementazioni come definito nella sezione 2.2.1 che dichiarano android.hardware.audio.output e android.hardware.microphone.

Dispositivo e dichiarazioni	RTL (ms)	MAD (ms)	Percorsi di loopback
A mano	250	30	altoparlante/microfono, analogico da 3,5 mm (se supportato), USB (se supportato)
>= MPC_T (14)	80	15	almeno un percorso
FUNZIONALITÀ_AUDIO_LOW_LATENCY	50	10	almeno un percorso
FUNZIONE_AUDIO_PRO	25	5	almeno un percorso
FUNZIONE_AUDIO_PRO	20	5	analogico (se supportato)
FUNZIONE_AUDIO_PRO	25	5	USB (se analogica non supportata)

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Nella tabella seguente vengono definiti i requisiti per il TTL del dispositivo portatile implementazioni come definito nella sezione 2.2.1 che dichiarano android.hardware.audio.output e android.hardware.microphone.

Dispositivo e dichiarazioni	TTL (ms)
A mano	250
>= MPC_T (14)	80
MPC_S (13)	100
FUNZIONE_AUDIO_PRO	80

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se le implementazioni dei dispositivi includono il supporto per spatial audio con rilevamento della testa e dichiarare la PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY flag:

• [C-4-1] DEVE presentare un tracciamento della testa massimo per una latenza degli aggiornamenti audio di 300 ms.

Termina nuovi requisiti

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 bozza 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 di Gemini Advanced. Consulta la sezione 5.1.8 per maggiori dettagli su H264 AVC, MPEG2-4 SP, e MPEG-2. Codec audio: AAC di Gemini Advanced. 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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-1-2] DEVE avere l'audio di andata e ritorno continuo latenza, soddisfare la latenza requisiti per FEATURE_AUDIO_PRO come definiti nella sezione 5.6 Latenza audio di Massimo 25 millisecondi su almeno uno supportato del tuo percorso di apprendimento.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-1-5] DEVE soddisfare latenze e audio USB Requisiti di latenza utilizzando Audio nativo audio API e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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 .

Termina nuovi requisiti

Se le implementazioni del dispositivo includono un jack audio da 3,5 mm a 4 conduttori, questi:

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-2-2] [C-SR-5] CONSIGLIATO VIVAMENTE a DEVE rispetta la sezione Specifiche dei dispositivi mobili (jack) della specifica delle cuffie audio con cavo (v1.1).

Termina nuovi requisiti

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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.

Termina nuovi requisiti

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

di Gemini Advanced.

Nota: in Android 13, P010 è più rilassato per consentire un passo arbitrario per sui piani Y e UV. (Questo formato P010 POTREBBE essere ottimizzato e diverso dalla formato Fotocamera 2 P010.

Se un codificatore video pubblicizza il supporto per COLOR_Format32bitABGR2101010, questo:

• [C-4-1] DEVE supportare il formato RGBA_1010102 per la superficie di input e 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.

• DEVE aggregare i metadati dinamici HDR per generare un'immagine statica HDR appropriata 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)

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [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
  • InputDeviceUsageReported
  • JobStateChanged
  • TastieraConfigurata
  • KeyboardSystemsEventReported
  • PluggedStateChanged
  • ScheduleJobStateChanged
  • StatoScreenChanged
  • SyncStateChanged
  • SistemaElapsedRealtime
  • Utilizzo del touchpad
  • UidProcessStateChanged
  • WakelockStateChanged
  • Si è verificato un allarme sveglia
  • WifiLockStateChanged
  • WifiMulticastLockStateChanged
  • WifiScanStateChanged

Termina nuovi requisiti

• [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 per 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 possono funzionare bene su una vasta gamma di display e configurazioni 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).

Implementazioni dei dispositivi:

• [C-0-1] DEVE, per impostazione predefinita, eseguire il rendering delle applicazioni di terze parti Display compatibili con Android.

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à. Il numero di pixel inclusi in una linea intervallo orizzontale o verticale di 1", espresso in pixel per pollice (ppi o dpi). Dove sono elencati i valori ppi e dpi, sia i DPI orizzontali che quelli verticali devono rientrare nell'intervallo elencato.
• 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). Un'unità pixel virtuale normalizzata per una densità dello schermo di 160. Per una certa densità D, e un numero di pixel p, cioè il numero di pixel indipendenti dalla densità dp, è calcolato come: 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 dei dispositivi supportano schermate in grado di Configurazione delle dimensioni di UI_MODE_TYPE_NORMAL e utilizzare display fisici con angoli arrotondati per eseguire il rendering di questi schermi, l'utente:

• [C-1-1] DEVE garantire che almeno uno dei seguenti requisiti viene soddisfatta per ciascuna di queste visualizzazioni:

  • Il raggio degli angoli arrotondati è inferiore o uguale a 38 dp.
  • Quando una casella di 18 dp x 18 dp è ancorata a ciascun angolo della dello schermo, almeno un pixel di ciascun riquadro sia visibile sullo schermo.

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

Se le implementazioni del dispositivo supportano soltanto la configurazione da tastiera NO_KEYS, e intendi segnalare il supporto per la modalità UI UI_MODE_TYPE_NORMAL configurazione:

• [C-4-1] DEVE avere le dimensioni del layout, esclusi eventuali ritagli display, di almeno 596 dp x 384 dp o superiore.

Per informazioni dettagliate sulla corretta implementazione delle API sidecar o di estensione, consulta alla documentazione pubblica di Window Manager Jetpack.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se le implementazioni del dispositivo includono una o più aree di visualizzazione compatibili con Android che sono pieghevoli o includono una cerniera pieghevole tra più Aree di visualizzazione dei pannelli compatibili con Android e rendile disponibili ai possono:

• [C-4-1] DEVE implementare la versione corretta delle estensioni di Window Manager Livello API come descritto in Estensioni WindowsManager.

Termina nuovi requisiti

7.1.1.2. Proporzioni dello schermo

Questa sezione è stata eliminata in Android 14.

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] DEVE segnalare una delle densità del framework Android elencate su DisplayMetrics tramite l'API DENSITY_DEVICE_STABLE e deve essere statico per ogni visualizzazione fisica. Tuttavia il dispositivo POTREBBE Segnala un altro 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.

• DEVE definire la densità del framework Android standard numericamente più vicino alla densità fisica dello schermo o un valore che verrebbe mappato le stesse misurazioni del campo visivo angolare equivalente di un dispositivo portatile.

Se le implementazioni dei dispositivi forniscono un'autorizzazione cambiano le dimensioni di visualizzazione del dispositivo, questi:

• [C-1-1] NON DEVE scalare il display di oltre 1,5 volte 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] NON DEVE scalare il display inferiore a 0,85 volte il valore 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 relativo allo stato attuale 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. In altre parole, 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:

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-1-1] DEVE supportare entrambi OpenGL ES 1.1 e 2.0, 3.0 e 3.1 come incorporati e dettagliati nella documentazione relativa all'SDK per Android.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-SR-1] È VIVAMENTE CONSIGLIATO il supporto di OpenGL ES 3.1.

Termina nuovi requisiti

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

• [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 le 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 com.android.graphics.injectLayers.enable dei metadati impostato 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.
• [C-SR-5] È VIVAMENTE CONSIGLIATO di supportare VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory e VK_EXT_global_priority.
• [C-SR-6] Ti consigliamo VIVAMENTE di usare SkiaVk con HWUI.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se le implementazioni dei dispositivi includono il supporto per Vulkan:

• [C-SR-8] CONSIGLIATO VIVAMENTE di non modificare il caricatore Vulkan.
• [C-1-14] NON DEVE enumerare le estensioni dei dispositivi Vulkan di tipo "KHR", "GOOGLE" o "ANDROID" a meno che queste estensioni non siano incluse Flag funzionalità android.software.vulkan.deqp.level.

Termina nuovi requisiti

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

• [C-2-1] NON DEVE dichiarare nessuno dei flag delle funzionalità Vulkan (ad es. android.hardware.vulkan.level 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 Le segnalazioni delle funzionalità Vulkan descritte 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.

• [C-SR-7] È VIVAMENTE CONSIGLIATO di rendere VK_KHR_external_fence_fd l'estensione disponibile per le applicazioni di terze parti e attivare l'applicazione per esportare il payload del recinto e importarlo dal file POSIX descrittori come descritto qui.

7.1.4.3. RenderScript

Implementazioni dei dispositivi:

• [C-0-1] DEVE 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(), l'utente:

• [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 '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 il parametro 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 HID^2	Pulsante Android
R^1	0x09 0x0001	KEYCODE_PULSANTE_A (96)
M^1	0x09 0x0002	KEYCODE_PULSANTE_B (97)
X^1	0x09 0x0004	KEYCODE_PULSANTE_X (99)
A^1	0x09 0x0005	KEYCODE_PULSANTE_Y (100)
D-pad in alto^1 D-pad in basso^1	0x01 0x0039^3	AXIS_HAT_Y^4
D-pad sx1 D-pad destro^1	0x01 0x0039^3	AXIS_HAT_X^4
Pulsante sulla spalla sinistra^1	0x09 0x0007	KEYCODE_PULSANTE_L1 (102)
Pulsante sulla spalla destra^1	0x09 0x0008	KEYCODE_PULSANTE_R1 (103)
Clic sulla levetta sinistra^1	0x09 0x000E	KEYCODE_button_THUMBL (106)
Clic sulla levetta destra^1	0x09 0x000F	KEYCODE_Button_THUMBR (107)
Indietro^1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Gli utilizzi HID 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 analogici^1	Utilizzo HID	Pulsante Android
Trigger sinistro	0x02 0x00C5	AXIS_LTRIGGER
Grilletto destro	0x02 0x00C4	AXIS_RTRIGGER
Joystick sinistro	0x01 0x0030 0x01 0x0031	AXIS_X 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 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 gravity(4g) o più su qualsiasi asse.
• [C-1-5] DEVE avere una risoluzione di almeno 12 bit.
• [C-1-6] DEVE avere una deviazione standard non superiore a 0,05 m/s^, dove la deviazione standard deve essere calcolata 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 o superiore a 0,5 Mbps è attiva una connessione 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 binario "vicino" o "lontano" che leggono:

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-4-4] DEVE consentire alle applicazioni di aggiungere contenuti personalizzati a BiometricPrompt con i formati di visualizzazione dei contenuti PromptContentView. La visualizzazione dei contenuti formati NON DEVONO essere estesi per consentire immagini, link, contenuti interattivi, o altri tipi di contenuti multimediali che non fanno già parte del BiometricPrompt tramite Google Cloud CLI o tramite l'API Compute Engine. Modifiche stilistiche che non alterano, oscurano o troncano questo elemento (ad esempio, la modifica della posizione, della spaziatura interna, dei margini tipografia).

Termina nuovi requisiti

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-7-1] DEVE, quando un dato biometrico è bloccato (ovvero è disattivato fino a quando l'utente non si sblocca con l'autenticazione principale) o il blocco vincolato al tempo (ad es. i dati biometrici vengono temporaneamente disattivati finché l'utente non attende un po' di tempo) intervallo) a causa di un numero eccessivo di tentativi non riusciti, blocca anche tutti gli altri biometria di una classe biometrica di livello inferiore. In caso di blocco vincolato al tempo, il tempo di backoff per la verifica biometrica DEVE essere il tempo di backoff massimo di tutti i dati biometrici in blocco vincolato al tempo.

• [C-SR-12] Sono VIVAMENTE CONSIGLIATE, quando un dato biometrico è in blocco (ad es. la biometria è disattivata finché l'utente non si sblocca con l'autenticazione principale) oppure blocco vincolato al tempo (ovvero i dati biometrici vengono temporaneamente disattivati fino al l'utente attende un intervallo di tempo) a causa di un numero eccessivo di tentativi non riusciti, a bloccare tutti gli altri dati biometrici della stessa classe biometrica. Nel caso di blocco vincolato al tempo, il tempo di backoff per la verifica biometrica è VIVACE CONSIGLIATO che sia il tempo di backoff massimo di tutti i dati biometrici nei limiti di tempo in blocco.

• [C-7-2] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) per reimpostare il contatore di blocco per un dato biometrico non riescono ad accedere. La biometria di Classe 3 POTREBBE essere autorizzata a reimpostare il blocco contatore per un dato biometrico bloccato di classe o inferiore. Classe 2 o NON DEVE essere consentita la biometria di Classe 1 per completare un blocco reimpostato per la biometria.

• [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%, misurati con i protocolli Android Biometrics Test.
• [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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [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). o quando viene richiesta l'autenticazione primaria consigliata (ad es. PIN, sequenza, password) vengono rimossi.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [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 esempio PIN, sequenza, password) una volta ogni 72 ore o meno.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-1-8] DEVE richiedere all'utente il certificato principale consigliato l'autenticazione (ad esempio PIN, sequenza, password) o l'autenticazione biometrica 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: upgrade dei dispositivi lanciato con la versione 9 di Android o precedenti POTREBBERO essere esentati da C-1-8.

Termina nuovi requisiti

• [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 falso inferiore al 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.
• [C-1-12] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 40% specie di strumento di attacco per presentazione (PAI), misurati dalla Protocolli del test biometrico di Android.
• [C-SR-13] È VIVAMENTE CONSIGLIATO di fare una parodia il tasso di accettazione degli impostori non supera il 30% specie di strumento di attacco per presentazione (PAI), misurati dalla Protocolli del test biometrico di Android.
• [C-SR-8] È VIVAMENTE CONSIGLIATO avere un tasso di rifiuto falso inferiore al 10%, come misurato sul dispositivo.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-1-15] DEVE consentire agli utenti di rimuovere uno o più dati biometrici registrazioni.

Termina nuovi requisiti

• [C-SR-14] È VIVAMENTE CONSIGLIATO di divulgare la classe biometrica del sensore biometrico e i relativi rischi associati all'attivazione.

• [C-SR-17] È VIVAMENTE CONSIGLIATO di implementare le nuove interfacce AIDL (ad es. IFace.aidl e IFingerprint.aidl).

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-SR-15] È VIVAMENTE CONSIGLIATO di chiedere una parodia o un impostore tasso di accettazione non superiore al 20% specie di strumento di attacco per presentazione (PAI), misurati dalla Protocolli del test biometrico 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), su un chip con un canale sicuro verso l'ambiente di esecuzione isolato oppure su una macchina virtuale protetta che soddisfi 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 su una macchina virtuale protetta controllato da un 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 con un canale sicuro all'ambiente di esecuzione isolato Macchina virtuale controllata da hypervisor che soddisfa 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 della macchina virtuale protetta controllata da hypervisor che soddisfi 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 esempio 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.

• [C-SR-16] È VIVAMENTE CONSIGLIATO di chiedere una parodia o un impostore tasso di accettazione non superiore a Il 7% per specie di strumenti di attacco di presentazione (PAI), misurata in base alla Protocolli del test biometrico di Android. 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:

• [C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.uwb.
• [C-1-3] DEVE supportare tutti i seguenti set di configurazione (predefinito) combinazioni dei parametri FIRA UCI) definita nell'implementazione AOSP.
  • CONFIG_ID_1: intervallo unicast STATIC STS DS-TWR definito da FiRa, modalità differita, con intervallo di 240 ms.
  • CONFIG_ID_2: intervallo STATIC STS DS-TWR one-to-many definito da FiRa, modalità differita, con intervallo di 200 ms. Caso d'uso tipico: smartphone interagisce con molti smart device.
  • CONFIG_ID_3: uguale a CONFIG_ID_1, ad eccezione dell'angolo di arrivo (AoA) non vengono registrati.
  • CONFIG_ID_4: come CONFIG_ID_1, ad eccezione della modalità di sicurezza P-STS è in un bucket con il controllo delle versioni attivo.
  • CONFIG_ID_5: come CONFIG_ID_2, ad eccezione della modalità di sicurezza P-STS è in un bucket con il controllo delle versioni attivo.
  • CONFIG_ID_6: come CONFIG_ID_3, ad eccezione della modalità di sicurezza P-STS è in un bucket con il controllo delle versioni attivo.
  • CONFIG_ID_7: uguale a CONFIG_ID_2, ad eccezione del controllo individuale P-STS sia attivata.
• [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 il blocco delle app che utilizzano la radio UWB UWB_RANGING (nel gruppo di autorizzazioni NEARBY_DEVICES).

Superare i test di conformità e certificazione pertinenti definiti dallo standard organizzazioni, tra cui FIRA, CCC e CSA aiuta a garantire che lo standard 802.1.15.4 funzioni correttamente.

7.4. Connettività dei dati

7.4.1. Telefonia

"Telefonia" come viene usato dalle API Android e il presente documento fa riferimento nello specifico a hardware per effettuare chiamate vocali e inviare SMS oppure dati mobili tramite cellulare (ad es. GSM, CDMA, LTE, NR)GSM o CDMA in ogni rete. Un dispositivo che supporti la funzionalità "Telefonia" puoi scegliere di offrire alcune o tutte le servizi di chiamata, messaggistica e dati in base al prodotto.

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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

• [C-1-4] DEVE supportare mDNS e NON filtrare i pacchetti mDNS (224.0.0.251 o ff02::fb) in qualsiasi momento di funzionamento, anche quando schermo non sia in stato attivo, a meno che il blocco multicast non sia tenuto e i pacchetti sono filtrati dall'APF. I pacchetti non devono soddisfare Operazioni mDNS attualmente richieste dalle applicazioni tramite NsdManager su quelle di livello inferiore. Tuttavia, il dispositivo POTREBBE filtrare i pacchetti mDNS se necessario per rimanere entro gli intervalli di consumo energetico richiesti dai requisiti normativi applicabile al mercato target.

Termina nuovi requisiti

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

È 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 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 tramite 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 DUT.
• [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

Una fotocamera posteriore è una videocamera rivolta verso il mondo che riproduce scene da lontano del dispositivo, come una fotocamera tradizionale; sui dispositivi portatili, cioè le videocamere che si trova sul lato del dispositivo di fronte al display.

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

Una fotocamera anteriore è una fotocamera rivolta all'utente, solitamente utilizzata per acquisire immagini l'utente, ad esempio per videoconferenze e applicazioni simili; su dispositivo portatile dispositivi, ovvero una fotocamera situata sullo stesso lato del dispositivo del display.

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 all'orientamento corrente del dispositivo.

7.5.3. Videocamera esterna

Una videocamera esterna è una videocamera che può essere collegata o scollegata fisicamente l'implementazione dei dispositivi in qualsiasi momento e possano essere rivolte in qualsiasi direzione; ad esempio USB videocamere.

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 messa a fuoco automatica, i callback dell'API devono essere ancora "faked" 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 diverse fotocamere RGB 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 viene applicata 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).
• Implementazioni dei dispositivi che non possono essere ruotate dall'utente, come come dispositivi automobilistici.

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	&lt; 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

I dispositivi destinati a essere tenuti in mano o indossati possono includere una tecnologia aptica per uso generico disponibile per le applicazioni, anche per attirare l'attenzione tramite suonerie, sveglie, notifiche e feedback tattili generali.

Se le implementazioni del dispositivo NON includono un attuatore aptico per uso generico, l'utente:

• [7.10/C] DEVE restituire false per Vibrator.hasVibrator().

Se le implementazioni dei dispositivi includono almeno uno di questi tipi di feedback aptico per uso generico dell'attuatore, questi:

• [C-1-1] DEVE restituire true per Vibrator.hasVibrator().
• NON utilizzare un attuatore aptico aptico (vibratore) a massa rotante eccentrica (ERM).
• DEVE implementare tutte le costanti pubbliche per ottenere una tecnologia aptica chiara tra android.view.HapticFeedbackConstants ossia (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START e GESTURE_END).
• DEVE implementare tutte le costanti pubbliche per ottenere una tecnologia aptica chiara tra android.os.VibrationEffect ossia (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK e EFFECT_DOUBLE_CLICK) e tutte le costanti PRIMITIVE_* pubbliche idonee per Tecnologia aptica avanzata tra android.os.VibrationEffect.Composition ossia (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Alcune di queste primitive, come LOW_TICK e SPIN è fattibile solo se la vibrazione è in grado di supportare un livello di frequenza cardiaca.
• DEVE seguire le linee guida per la mappatura delle costanti pubbliche tra android.view.HapticFeedbackConstants al valore consigliato android.os.VibrationEffect costanti, con le corrispondenti relazioni di ampiezza.
• DEVI utilizzare queste mappature della costante aptica collegata.
• DEVE seguire la valutazione della qualità per createOneShot() e createWaveform() su quelle di livello inferiore.
• DEVI verificare che il risultato del pubblico android.os.Vibrator.hasAmplitudeControl() L'API riflette correttamente le capacità della vibrazione.
• DEVI verificare le funzionalità per la scalabilità dell'ampiezza eseguendo android.os.Vibrator.hasAmplitudeControl().

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

• DEVI verificare lo stato dell'implementazione eseguendo android.os.Vibrator.areAllEffectsSupported() e android.os.Vibrator.arePrimitivesSupported() su quelle di livello inferiore.
• DEVI eseguire una valutazione della qualità per le costanti aptiche.
• DEVI verificare e aggiornare, se necessario, la configurazione di riserva per primitive non supportate, come descritto nelle linee guida per l'implementazione per le costanti.
• DOVREBBE fornire assistenza di riserva per ridurre il rischio di errore come descritto qui

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-SR-1] Autorizzazioni con protectionLevel di PROTECTION_SIGNATURE è VIVAMENTE CONSIGLIATO di concedere l'accesso solo a:

  • Le app preinstallate nell'immagine di sistema (così come file APEX).
  • App incluse nella lista consentita con autorizzazioni consentite se non sono incluse in l'immagine di sistema.
  di Gemini Advanced.
  Nota: questo requisito DEVE essere incluso nella release del 25 trimestre. L'implementazione AOSP soddisfa questo requisito leggendo e rispettando le autorizzazioni incluse nella lista consentita per ogni app dai file etc/permissions/.

Termina nuovi requisiti

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 in modo invisibile all'utente 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 Dati ambientali e a livello di sistema operativo e 9.8.15 Implementazioni API con sandbox".

Se le implementazioni del dispositivo includono un'applicazione predefinita per supportare i VoiceInteractionService l'utente:

• [C-5-1] NON DEVE concedere ACCESS_FINE_LOCATION come impostazione predefinita un'applicazione.

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 di un profilo utente aggiuntivo se è stato eseguito il provisioning di un proprietario del dispositivo (vedi la sezione 3.9.1) o consenti un proprietario del dispositivo senza rimuovere prima il profilo utente aggiuntivo.

Se le implementazioni dei dispositivi creano il profilo utente aggiuntivo di cui sopra, allora:

• [C-4-1] DEVE consentire gli intent indicati di seguito provenienti dall'URL aggiuntivo profilo gestito dalle applicazioni dell'utente principale sul dispositivo:

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] DEVE ereditare tutte le limitazioni relative agli utenti per i criteri relativi ai dispositivi e aver selezionato restrictions(list below) non utente applicato all'utente principale del dispositivo a questo profilo utente aggiuntivo.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] DEVE consentire la scrittura di contatti da questo profilo aggiuntivo soltanto tramite i seguenti intent:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] NON DEVE avere le sincronizzazioni dei contatti in esecuzione per le applicazioni questo profilo utente aggiuntivo.

• [C-4-5] DEVE consentire solo le applicazioni nel profilo aggiuntivo che hanno un all'attività dell'Avvio app per accedere ai contatti già accessibili profilo utente principale.

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

Una tecnologia di sicurezza della memoria è una tecnologia che mitiga almeno i seguenti fattori: classi di bug con una probabilità alta (> 90%) nelle applicazioni che usano android:memtagMode opzione del file manifest:

• overflow del buffer heap
• utilizzare dopo le spese
• doppio senza costi
• wild free (privo di un puntatore non-malloc)

Implementazioni dei dispositivi:

• [C-SR-15] È VIVAMENTE CONSIGLIATO di impostare ro.arm64.memtag.bootctl_supported.

Se le implementazioni dei dispositivi impostano la proprietà di sistema ro.arm64.memtag.bootctl_supported su true, ovvero:

• [C-3-1] DEVE consentire alla proprietà di sistema arm64.memtag.bootctl di accettare un elenco separato da virgole dei seguenti valori, con l'effetto desiderato applicata al riavvio successivo:

  • memtag: è stata attivata una tecnologia di sicurezza della memoria come definita sopra
  • memtag-once: una tecnologia di sicurezza della memoria come definita sopra è temporaneamente abilitato e viene automaticamente disattivato riavvio
  • memtag-off: una tecnologia di sicurezza della memoria come definita sopra è disattivata

• [C-3-2] DEVE consentire all'utente shell di impostare arm64.memtag.bootctl.

• [C-3-3] DEVE consentire a qualsiasi processo di leggere arm64.memtag.bootctl.

• [C-3-4] DEVE impostare arm64.memtag.bootctl sullo stato attualmente richiesto all'avvio, DEVE aggiornare anche la proprietà, se l'implementazione del dispositivo consente di modificare lo stato senza cambiare la proprietà di sistema.

• [C-SR-16] È VIVAMENTE CONSIGLIATO di mostrare un'Impostazione sviluppatore che imposti Memorizza una volta e riavvia il dispositivo. Con un bootloader compatibile, Android Open Source Project soddisfa i requisiti illustrati sopra tramite le Protocollo bootloader MTE.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se un dispositivo dichiara android.hardware.telephony, supporta il segnale radio funzionalità CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK e include un modem cellulare che supporta le connessioni 2G, il dispositivo implementazione:

• [C-SR-17] È VIVAMENTE CONSIGLIATO di fornire all'utente il permesso di disabilitare e attivare il 2G.

• [C-SR-18] È VIVAMENTE CONSIGLIATO di non sostituire l'invito dell'utente a disattivare e attivare il 2G tramite qualsiasi altra entità del dispositivo, ad eccezione di un dispositivo amministratore che utilizza UserManager.DISALLOW_CELLULAR_2G

• [C-SR-19] È VIVAMENTE CONSIGLIATO di chiamare TelephonyManager.setAllowedNetworkTypesForReason con motivo ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G per raggiungere questo obiettivo requisito.

• [C-SR-20] È VIVAMENTE CONSIGLIATO per determinare il supporto del modem cellulare per 2G chiamando TelephonyManager.getSupportedRadioAccessFamily Consulta Disattivare il 2G della i dettagli.

di Gemini Advanced.

Nota: i requisiti VIVAMENTE CONSIGLIATI (da C-SR-17 a C-SR-20) diventano DEVI in Android 25T2.

Termina nuovi requisiti

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 consenso esplicito dell'utente consentendo a qualsiasi informazione sensibile visualizzata sullo schermo dell'utente ogni volta che si verifica una sessione per acquisire la schermata viene avviata MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay(), o API proprietarie.

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

• [C-SR-1] È VIVAMENTE CONSIGLIATO di mostrare un avviso per l'utente che corrisponda esattamente lo stesso messaggio implementato in AOSP ma PUÒ essere modificato finché avvisa chiaramente l'utente che qualsiasi informazione sensibile nel suo della finestra di dialogo.

• [C-0-4] NON DEVE fornire agli utenti un invito per disabilitare i prompt futuri di l'utente acconsente all'acquisizione della schermata, a meno che la sessione non venga avviata da app di sistema a cui l'utente ha consentito associate() con android.app.role.COMPANION_DEVICE_APP_STREAMING o il android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING profilo del dispositivo.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Implementazioni dei dispositivi:

• [C-0-7] NON DEVE registrare, proiettare o trasmettere informazioni sensibili quali:
  • Contenuti sensibili elencati in Sezione 3.8.3.4 Protezione dalle notifiche sensibili
  • Finestre delle attività delle app contenenti password uniche
  • Contenuti sensibili come nome utente, password, e dati della carta di credito

Termina nuovi requisiti

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" si riferisce a una visualizzazione sullo schermo, che è sempre 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 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.
  • a cui è stata concessa 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. Dati ambientali e a livello di sistema operativo

Android, tramite le API di sistema, supporta un meccanismo per implementazioni per acquisire i seguenti 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 schermate o altri dati inviati tramite AugmentedAutofillService alle di un sistema operativo completo.

• Qualsiasi schermata o altri dati accessibili tramite Content Capture su quelle di livello inferiore.

• Eventuali dati dell'applicazione trasmessi al sistema tramite l'API AppSearchManager e accessibile tramite AppSearchGlobalManager.query.

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

• Dati audio ottenuti in seguito all'utilizzo SpeechRecognizer#onDeviceSpeechRecognizer() del riconoscimento vocale Implementazione.

• Dati audio ottenuti in background (continua) fino al giorno AudioRecord, SoundTrigger o altre API audio e che non risultino visibili agli utenti. indicatore

• Dati della videocamera ottenuti in background (continua) tramite CameraManager o altre API Camera e ciò non comporta la visualizzazione di un indicatore visibile all'utente

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 tutti questi dati solo dalla dispositivo che utilizza un meccanismo che tutela la privacy, ad eccezione 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 di eventi registrati o risultati derivati per singoli utenti", a 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 Dati ambientali e a livello di sistema operativo), salvo con il consenso esplicito dell'utente ogni momento in cui viene condiviso. A meno che tale funzionalità non sia creato come un'API SDK Android (AmbientContext, HotwordDetectionService).
• [C-1-6] DEVE fornire all'utente il permesso di cancellare i dati che l'implementazione o i mezzi proprietari vengono raccolti quando i dati vengono memorizzati in qualsiasi formato sul dispositivo. Se l'utente sceglie di cancellare i dati, DEVE rimuovere tutti i dati storici raccolti e i dati di Google Cloud.

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

• [C-SR-4] È VIVAMENTE CONSIGLIATO di implementarlo con l'API SDK Android o un simile repository open source di proprietà di OEM; e / o essere eseguita in un Implementazione con sandbox (vedi 9.8.15 Implementazioni API con sandbox).

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 detenute dai 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... incluso tutti i futuri modem cellulari) 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à delle API di bypass della località di emergenza 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 del provider che usa i "download" autorità del fornitore 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 può accedere solo a "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
  • Dump SubscriptionManagerService
• [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 delle 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 del dispositivo 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.8.14. N/D

9.8.15. Implementazioni di API con sandbox

Android, attraverso una serie di API di delega, fornisce un meccanismo per elaborare Dati ambientali e a livello di sistema operativo. Tale trattamento può essere delegato a un un APK con accesso privilegiato e capacità di comunicazione ridotte, noto come Implementazione dell'API con sandbox

Qualsiasi implementazione di API con sandbox:

• [C-0-1] NON DEVE richiedere l'autorizzazione per INTERNET.
• [C-0-2] DEVE accedere a internet solo tramite API strutturate supportate da implementazioni open source disponibili pubblicamente usando o indirettamente tramite le API SDK di Android. La tutela della privacy meccanismo di attenzione è definito come "quelle che consentono solo l'analisi in forma aggregata impedire la corrispondenza di eventi registrati o risultati derivati per singoli utenti", per impedire che i dati per utente siano introspezionabili (ad es. implementati utilizzando una tecnologia di privacy differenziale come RAPPOR).
• [C-0-3] DEVE mantenere i servizi separati dagli altri componenti di sistema (ad es. non vincolano gli ID servizio o condivisione processo), ad eccezione degli ID processo seguenti:
  • Telefonia, contatti, UI di sistema e contenuti multimediali
• [C-0-4] NON DEVE consentire agli utenti di sostituire i servizi con un applicazione o servizio installabile dall'utente
• [C-0-5] DEVE consentire solo ai servizi preinstallati di acquisire questi dati. A meno che la funzionalità di sostituzione non sia integrata in AOSP (ad esempio per le tecnologie app dell'assistente).
• [C-0-6] NON DEVE consentire app diverse dai servizi preinstallati meccanismo di acquisizione dei dati. A meno che tale capacità di acquisizione viene implementata con un'API Android SDK.
• [C-0-7] DEVE fornire l'autorizzazione all'utente per disabilitare i servizi.
• [C-0-8] NON DEVE omettere l'autorizzazione dell'utente a gestire le autorizzazioni Android che sono di proprietà dei servizi e seguono il modello di autorizzazioni Android descritti in Sezione 9.1. Autorizzazione.

9.8.16. Dati audio e della videocamera continui

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Oltre ai requisiti descritti in 9.8.2 Registrazione, 9.8.6 a livello di sistema operativo e e 9.8.15 Implementazioni API con sandbox, implementazioni utilizzare dati audio ottenuti in background (continuamente) mediante AudioRecord, SoundTrigger o altre API Audio O dati relativi alla videocamera ottenuti in sfondo (continua) tramite CameraManager o altre API Camera:

Se le implementazioni del dispositivo acquisiscono uno qualsiasi dei dati come descritto nella sezione 9.8.2 o sezione 9.8.6, e qualora tali implementazioni utilizzino i dati Audio ottenuti nei background (continua) mediante AudioRecord, SoundTrigger o altre API Audio OPPURE Dati della fotocamera ottenuti in background (continua) tramite CameraManager o altre API Camera:

Termina nuovi requisiti

• [C-0-1] DEVE applicare un indicatore corrispondente (fotocamera e/o microfono per la sezione 9.8.2 Registrazione), a meno che:
  • Questo accesso viene eseguito in un'implementazione con sandbox (vedi 9.8.15 Implementazione di API con sandbox), mediante un pacchetto che contiene uno dei seguenti ruoli: Intelligence UI di sistema, Intelligenza audio di sistema, Intelligence audio di sistema, System Notification Intelligence, System Text Intelligence, o Intelligenza visiva del sistema.
  • L'accesso viene eseguito tramite una sandbox, implementato e applicati tramite meccanismi in AOSP (HotwordDetectionService, WearableSensingService e VisualQueryDetector).
  • L'accesso audio viene concesso per scopi di assistenza da parte del Applicazione dell'assistente, che fornisce SOURCE_HOTWORD come sorgente audio.
  • L'accesso viene eseguito dal sistema e implementato codice open source.
• [C-SR-1] CONSIGLIamo VIVAMENTE di richiedere il consenso dell'utente per ogni la funzionalità che utilizza tali dati ed essere disabilitata per impostazione predefinita.
• [C-SR-2] VIVAMENTE CONSIGLIATO di applicare lo stesso trattamento (ovvero seguire limitazioni descritte in 9.8.2 Registrazione, 9.8.6 Dati ambientali e a livello di sistema operativo, 9.8.15 Implementazioni API con sandbox e 9.8.16 Audio continuo e videocamera di dati) ai dati della videocamera provenienti da un dispositivo indossabile remoto.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

Se i dati della videocamera vengono forniti da un dispositivo indossabile remoto e vi si accede in un formato non criptato al di fuori del sistema operativo Android, implementazione con sandbox o con sandbox di funzionalità create da WearableSensingManager, allora:

Se le implementazioni del dispositivo ricevono dati dalla fotocamera o dal microfono da un telecomando dispositivo indossabile e l'accesso ai dati è in formato non criptato al di fuori del Sistema operativo Android, implementazione con sandbox o funzionalità con sandbox create WearableSensingManager, l'utente:

Termina nuovi requisiti

• [C-1-1] DEVE indicare al dispositivo indossabile remoto di visualizzare un altro indicatore.

Se i dispositivi offrono la possibilità di interagire con un'applicazione per assistente digitale senza la parola chiave assegnata (per la gestione di query generiche dell'utente o l'analisi la presenza dell'utente tramite la videocamera), devono:

• [C-2-1] DEVE garantire che tale implementazione sia fornita da un pacchetto che contiene Ruolo android.app.role.ASSISTANT.
• [C-2-2] DEVE garantire che tale implementazione utilizzi HotwordDetectionService e/o VisualQueryDetectionService API Android.

9.8.17. Telemetry

Android memorizza i log di sistema e delle app utilizzando le API StatisticheLog. Questi log sono gestiti tramite le API StatisticheManager che possono essere utilizzate da applicazioni di sistema con privilegi.

StatisticheManager offre anche un modo per raccogliere i dati classificati come privacy sensibili da dispositivi con un meccanismo che tutela la privacy. In particolare, L'API StatsManager::query offre la possibilità di eseguire query su una metrica limitata categorie definite in StatisticheLog.

Qualsiasi query di implementazione e raccolta di metriche limitate da Statistiche Manager:

• [C-0-1] DEVE essere l'unica applicazione/implementazione sul dispositivo e tenere l'autorizzazione READ_RESTRICTED_STATS.
• [C-0-2] DEVE inviare solo i dati di telemetria e il registro del dispositivo utilizzando un meccanismo di tutela della privacy. Il meccanismo di tutela della privacy è definito come "che consentono solo l'analisi in forma aggregata e impediscono la corrispondenza di eventi registrati o risultati derivati per singoli utenti", per evitare che i dati per utente siano introspezionabili (ad es. implementati utilizzando tecnologie per la privacy come RAPPOR).
• [C-0-3] NON DEVONO associare questi dati a identità utente (ad esempio, Account) sul dispositivo.
• [C-0-4] NON DEVE condividere questi dati con altri componenti del sistema operativo che non dei requisiti descritti nella sezione corrente (9.8.17 Tutela della privacy telemetria).
• [C-0-5] DEVE fornire un'invito all'utente per attivare/disattivare la tutela della privacy la raccolta, l'uso e la condivisione dei dati telemetrici.
• [C-0-6] DEVE fornire all'utente il permesso di cancellare tali dati che vengono raccolti se i dati vengono memorizzati in qualsiasi forma sul dispositivo. Se l'utente ha scelto di cancellare i dati, DEVE rimuovere tutti i dati attualmente memorizzati del dispositivo.
• [C-0-7] DEVE comunicare l'implementazione di un protocollo di tutela della privacy sottostante. in un repository open source.
• [C-0-8 ]DEVE applicare i criteri di traffico in uscita dei dati in questa sezione per limitare la raccolta di dati nelle categorie di metriche limitate definite in StatisticheLog.

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.

di Gemini Advanced.

Nota: le implementazioni dei dispositivi fornite con un livello API 28 o precedente e che non soddisfare i requisiti della sezione 9.9.2 tramite un aggiornamento software di sistema DEVE soddisfare i requisiti nella sezione 9.9 del documento sulla definizione della compatibilità Android corrispondente al livello API a cui è stato spedito il dispositivo.

9.9.3. Metodi di crittografia

Se le implementazioni dei dispositivi sono criptate, queste:

• [C-1-1] DEVE avviarsi senza richiedere 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 dei file e i metadati del file system utilizzando AES-256-XTS o Adiantum. AES-256-XTS si riferisce all'Advanced Encryption Standard con una lunghezza di chiave di crittografia a 256 bit, gestita in modalità XTS; per l'intera durata è di 512 bit.Adiantum si riferisce ad Adiantum-XChaCha12-AES, come specificato https://github.com/google/adiantum. I metadati del 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 nome file, contenuti dei file e la crittografia dei metadati del file system DEVONO essere utilizzati, 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 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à.

Nota: le implementazioni dei dispositivi fornite con livello API 28 o precedenti non soddisfare i requisiti della sezione 9.9.3 tramite un aggiornamento software di sistema DEVE soddisfare i requisiti nella sezione 9.9 del Documento di definizione della compatibilità Android corrispondente al livello API a cui è stato spedito il dispositivo.

9.9.3.2. Crittografia a livello di blocco per utente

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

• [C-1-1] DEVE abilitare il supporto multiutente come descritto nella sezione 9.5.
• [C-1-2] DEVE fornire partizioni per utente, utilizzando partizioni non elaborate o 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 può 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 per questa 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-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).

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [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-14] DEVE verificare la firma almeno una volta per avvio per le autorizzazioni elencate pacchetti elencati come require-strict-signature nella configurazione di sistema.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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 il supporto di questi requisiti con un aggiornamento software di sistema, POTREBBERO essere esentati dalle i tuoi requisiti.

Termina nuovi 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.

Se le implementazioni del dispositivo sono in grado di verificare il file per pagina, allora:

• [C-2-1] supportano la verifica crittografica del contenuto del file senza leggere il l'intero file.

• [C-2-2] NON DEVE consentire il parametro di lettura su un file protetto andranno a buon fine se i contenuti di lettura non verificati ai sensi di [C-2-1] di cui sopra.

• [C-2-4] DEVE restituire il checksum del file in O(1) per i file abilitati.

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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

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.

Termina nuovi requisiti

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, l'intervallo di tempo DEVE essere di almeno 30 secondi per 9 < n < 30. Per n > 29, il valore dell'intervallo di tempo DEVE essere 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, SHA-1 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.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [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 abbastanza grande da impedire alle chiavi prevenuto dall'utilizzo come permanente identificatori dei dispositivi.

  Nota: per soddisfare questo requisito, devi condividere la stessa chiave di attestazione per un determinato SKU a meno che non alle almeno 100.000 unità di un dato quelli prodotti. Se sono più di 100.000 unità di un che vengono prodotti, POTREBBE essere utilizzata una chiave diversa per ogni gruppo 100.000 unità in seguito. In alternativa, la soluzione Remote Key Provisioning può essere utilizzata per chiavi di attestazione al dispositivo.

Termina nuovi requisiti

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.

• [C-0-1] DEVE limitare il numero di tentativi di autenticazione principale non riusciti.

• [C-SR-5] È VIVAMENTE CONSIGLIATO di implementare un limite superiore di 20 errori i tentativi di autenticazione principali e, se gli utenti acconsentono e attivano la funzionalità, eseguire un "ripristino dei dati di fabbrica" dopo aver superato il limite di errori principali tentativi di autenticazione.

Se le implementazioni del dispositivo impostano un PIN numerico come principale consigliato di autenticazione, quindi:

• [C-SR-6] È VIVAMENTE CONSIGLIATO IL PIN contenere almeno 6 cifre oppure equivalente a un'entropia a 20 bit.
• [C-SR-7] UN PIN di lunghezza inferiore a 6 cifre è VIVAMENTE CONSIGLIATO da NON consenti l'inserimento automatico senza interazione dell'utente per evitare di rivelare il PIN lunghezza.

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 qualsiasi delle segnalazioni biometriche associate (come 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-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 trasferire 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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-10-6] DEVE disabilitare la creazione dell'input associato eventi tramite VirtualDeviceManager quando indicato tramite lo streaming di app come indicato da DevicePolicyManager.setNearbyAppStreamingPolicy.

Termina nuovi requisiti

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-10-7] DEVE:
  • Disattiva utilizzo appunti
  • Attiva appunti separati per ogni dispositivo che li supporta

• [C-10-7] DEVE utilizzare appunti separati unicamente per ogni dispositivo virtuale (o disattiva gli appunti per i dispositivi virtuali)

Termina nuovi requisiti

• [C-10-11] DEVE disattivare l'interfaccia utente di autenticazione sui dispositivi virtuali, tra cui inserimento del fattore di conoscenza e prompt biometrico

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-10-12] DEVONO limitare gli intent avviati da un dispositivo virtuale alla visualizzazione solo sullo stesso dispositivo virtuale

Termina nuovi requisiti

• [C-10-13] Non DEVE utilizzare uno stato di blocco dispositivo virtuale come autenticazione utente con il sistema Android Keystore. Consulta KeyGenParameterSpec.Builder.setUserAuthentication*.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-10-14] DEVE fornire un invito all'utente per abilitare la condivisione degli appunti tra dispositivi prima di condividere i dati degli appunti tra dispositivi fisici e virtuali se il dispositivo sta implementando un blocco condiviso condiviso.
• [C-10-15] DEVE mostrare le notifiche quando si accede ai dati degli appunti attraverso dispositivi e DEVONO rendere i contenuti inaccessibili dopo un minuto misurato dalla tempo di condivisione iniziale.

Termina nuovi requisiti

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 i metadati android.activity.can_display_on_remote_devices impostati su false per impedire l'avvio sull'istanza virtuale dispositivo.

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-13-9] DEVE bloccare le attività che non abilitano esplicitamente i flussi di dati che indicano contenuti sensibili, anche tramite SurfaceView#setSecure e FLAG_SECUREoppure SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS l'avvio sul dispositivo virtuale.

Termina nuovi requisiti

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:

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

• [C-1-10] DEVE includere l'hardware certificato per la conformità ai Profilo di protezione IC sicuro BSI-CC-PP-0084-2014 o BSI-CC-PP-0117-2022, o è 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.

Termina nuovi requisiti

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

Crea nuovi requisiti per la versione 15 (sperimentale AOSP)

9.17. Framework di virtualizzazione di Android

API Android Virtualization Framework (AVF) (android.system.virtualmachine.*) supportano entrambe le macchine virtuali protette (pVM) e macchine virtuali non protette (non-pVM) secondo i le seguenti proprietà di sistema:

Se il criterio ro.boot.hypervisor.vm.supported viene impostato su true, le VM non pVM vengono supportati.

Se il criterio ro.boot.hypervisor.protected_vm.supported viene impostato su true, le pVM vengono supportati.

Nota: un'implementazione su dispositivo senza software EL2 può abilitare le VM non pVM entrando in GKI su EL2.

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare le API Android Virtualization Framework (android.system.virtualmachine.*) per pVM, non pVM e l'esistenza di entrambi.

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

• [C-1-1] DEVE supportare tutte le API definite dal android.system.virtualmachine pacchetto.

• [C-0-2] [C-1-2] NON DEVE modificare il modello di autorizzazione e il modello Android SELinux per di Protected Macchine virtuali(pVM sia pVM che non pVM).
• [C-0-4] [C-1-4] DEVE consentire solo il codice e le privilegio app preinstallate nella partizione di sola lettura per creare ed eseguire una VM macchine virtuali. Nota: questo aspetto potrebbe cambiare nelle future release di Android.
• [C-0-5] [C-1-5] DEVE consentire solo a una pVM non di cui non è possibile eseguire il debug di eseguire il codice dal produttore dell'immagine o della relativa piattaforma che includono anche eventuali aggiornamenti alle privilegio preinstallato app.

Se il dispositivo implementa il supporto per Android API Virtualization Framework (android.system.virtualmachine.*), poi Qualsiasi istanza pVM:

• [C-0-6] [C-2-1] DEVE essere in grado di eseguire tutti i sistemi operativi disponibili nella virtualizzazione APEX in una pVM.
• [C-0-7] [C-2-2] NON DEVE consentire a una pVM di eseguire un sistema operativo non firmato dal o fornitore del sistema operativo.
• [C-0-8] [C-2-3] NON DEVE consentire a una pVM di eseguire dati come codice (ad es. SELinux non consente mai execmem).
• [C-0-9] [C-2-5] DEVE implementare meccanismi di difesa in profondità pVM (ad es. SELinux per pVM) anche per sistemi operativi diversi dai microdroidi.
• [C-0-10] [C-2-6] DEVE garantire che la pVM non si avvii se le immagini che verrà eseguita dalla VM non potranno essere verificati. La verifica DEVE essere eseguita all'interno della VM.
• [C-0-11] [C-2-7] DEVE garantire che la pVM non si avvii se l'integrità di instance.img è compromesso.

Se il dispositivo implementa il supporto per Android API Virtualization Framework (android.system.virtualmachine.*), poi L'hypervisor:

• [C-0-12] [C-3-1] DEVE garantire che le pagine di memoria siano di proprietà esclusiva di una VM (pVM o VM hostpVM ospite o host) o l'hypervisor siano accessibili solo dalla macchina virtuale stessa o dall'hypervisor, non altre macchine virtuali, protette o non protette.
• [C-0-13] [C-3-2] DEVE cancellare una pagina dopo essere stata utilizzata da una pVM e prima che venga restituita all'host (ad esempio, la pVM viene eliminata).
• [C-0-14] [C-SR-1] È VIVAMENTE CONSIGLIATO a DEVE garantire che Il firmware pVM viene caricato ed eseguito prima di qualsiasi codice in una pVM.
• [C-0-15] [C-3-4] DEVE garantire che ogni VM pVM ricava una per VM segreto che significa che (catena di certificati di avvio) (BCC) e Compound Device Identifier (CDI) forniti a un'istanza pVM può essere derivato solo da quella determinata VM Istanza pVM e modifiche al ripristino dei dati di fabbrica e in caso di OTA.

Le API Android Virtualization Framework (AVF) (android.system.virtualmachine.*) consentono alle applicazioni di creare macchine virtuali (VM) on-device che si caricano ed eseguono come payload.

Se le implementazioni dei dispositivi impostano FEATURE_VIRTUALIZATION_FRAMEWORK su true:

• [C-1-6] DEVE garantire che android.system.virtualmachine.VirtualMachineManager.getCapabilities() restituisce almeno uno dei seguenti valori:
  • CAPABILITY_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM

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 la compilazione isolata, ma potrebbe disattivarla Funzione di compilazione isolata sulla spedizione del dispositivo.

Se il dispositivo implementa il supporto per Android API del framework di virtualizzazione, quindi per Gestione delle chiavi:

• [C-SR-2] È VIVAMENTE CONSIGLIATO di usare DICE come derivazione del secret per VM meccanismo di attenzione.

• [C-0-16] DEVE implementare la protezione rollback per le partizioni usate dalla VM protetta (ad es.avvio, firmware pVM), utilizzando uno spazio di archiviazione che evidenzia le manomissioni per l'archiviazione i metadati utilizzati per determinare la versione minima consentita della partizione inclusa la versione di sicurezza della partizione nel rispettivo DICE certificato equivalente.

Termina nuovi requisiti

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

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.