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