Androide 14
8 aprile 2024
2. Tipi di dispositivi
Vedi revisione
Inizia nuovi requisiti
Se le implementazioni del dispositivo portatile dichiarano
FEATURE_BLUETOOTH_LE,:- [ 7.4 .3/H-1-3] DEVE misurare e compensare l'offset Rx per garantire che il BLE RSSI mediano sia -50 dBm +/-15 dB a 1 m di distanza da un dispositivo di riferimento che trasmette a
ADVERTISE_TX_POWER_HIGH. - [ 7.4 .3/H-1-4] DEVE misurare e compensare l'offset Tx per garantire che il BLE RSSI mediano sia -50 dBm +/-15 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e trasmettendo a
ADVERTISE_TX_POWER_HIGH.
- [ 7.4 .3/H-1-3] DEVE misurare e compensare l'offset Rx per garantire che il BLE RSSI mediano sia -50 dBm +/-15 dB a 1 m di distanza da un dispositivo di riferimento che trasmette a
Vedi revisione
Se le implementazioni dei dispositivi portatili supportano l'API di sistema
HotwordDetectionServiceo un altro meccanismo per il rilevamento di hotword senza indicazione di accesso al microfono:- [9.8/H-1-6] NON DEVE consentire la trasmissione di più di 100 byte di dati dal servizio di rilevamento hotword su ciascun risultato hotword riuscito , ad eccezione dei dati audio passati attraverso HotwordAudioStream .
Vedi revisione
Cambia [9.8/H-1-13] in:
- [9.8/H-SR-3] Si CONSIGLIA FORTEMENTE di riavviare il processo che ospita il servizio di rilevamento hotword almeno una volta ogni ora o ogni 30 eventi di attivazione hardware, a seconda di quale evento si verifica per primo.
Vedi revisione
Rimossi i requisiti [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].
Vedi revisione
Se le implementazioni del dispositivo portatile restituiscono
android.os.Build.VERSION_CODES.Uperandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, allora:- [ 7.5 /H-1-3] DEVE supportare la proprietà
android.info.supportedHardwareLevelcomeFULLo migliore per la fotocamera principale posteriore eLIMITEDo migliore per la fotocamera principale anteriore.
- [ 7.5 /H-1-3] DEVE supportare la proprietà
Vedi revisione
Se le implementazioni del dispositivo televisivo non dispongono di uno schermo integrato, ma supportano invece uno schermo esterno collegato tramite HDMI,:
- [ 5.8 /T-0-1] È NECESSARIO impostare la modalità di uscita HDMI sulla risoluzione più alta per il formato pixel scelto che funzioni con una frequenza di aggiornamento di 50 Hz o 60 Hz per il display esterno, a seconda della frequenza di aggiornamento video per la regione in cui viene venduto il dispositivo in.
È NECESSARIO impostare la modalità di uscita HDMI per selezionare la risoluzione massima che può essere supportata con una frequenza di aggiornamento di 50 Hz o 60 Hz.
- [ 5.8 /T-0-1] È NECESSARIO impostare la modalità di uscita HDMI sulla risoluzione più alta per il formato pixel scelto che funzioni con una frequenza di aggiornamento di 50 Hz o 60 Hz per il display esterno, a seconda della frequenza di aggiornamento video per la regione in cui viene venduto il dispositivo in.
3. Software
3.5.1. Limitazione dell'applicazione :
Vedi revisione
- Requisito rimosso [C-1-9]
5. Compatibilità multimediale
Vedi revisione
Se le implementazioni del dispositivo dichiarano il supporto per il decoder Dolby Vision tramite
HDR_TYPE_DOLBY_VISION,:- [C-1-3] DEVE impostare l' ID della traccia degli strati di base compatibili con le versioni precedenti (se presenti) in modo che sia lo stesso dell'ID della traccia dello strato Dolby Vision combinato.
7. Compatibilità hardware
7.1.1.1. Dimensioni e forma dello schermo :
Vedi revisione
Se le implementazioni del dispositivo supportano schermi in grado di supportare la configurazione delle dimensioni
UI_MODE_TYPE_NORMALe utilizzano display fisici con angoli arrotondati per eseguire il rendering di questi schermi, essi:- [C-1-1] DEVE garantire che almeno uno dei seguenti requisiti sia soddisfatto per ciascuno di questi display:
- Quando
un riquadro da 15e 18 dp per1518 dp è ancorato a ciascun angolo della visualizzazione logica, sullo schermo è visibile almeno un pixel di ciascun riquadro.
- Quando
- [C-1-1] DEVE garantire che almeno uno dei seguenti requisiti sia soddisfatto per ciascuno di questi display:
Vedi revisione
Ripristinati i seguenti requisiti:
Se le implementazioni del dispositivo dichiarano
FEATURE_BLUETOOTH_LE,:[C-SR-2] Si CONSIGLIA FORTEMENTE di misurare e compensare l'offset Rx per garantire che il BLE RSSI mediano sia -60 dBm +/-10 dB a 1 m di distanza da un dispositivo di riferimento che trasmette a
ADVERTISE_TX_POWER_HIGH, dove i dispositivi sono orientati in modo tale da essere su "piani paralleli" con schermi rivolti nella stessa direzione.[C-SR-3] Si CONSIGLIA FORTEMENTE di misurare e compensare l'offset Tx per garantire che il BLE RSSI mediano sia -60 dBm +/-10 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e trasmettendo a
ADVERTISE_TX_POWER_HIGH, dove i dispositivi sono orientati in modo tale che si trovino su "piani paralleli" con gli schermi rivolti nella stessa direzione.
Vedi revisione
Requisiti spostati [C-10-3] e [C-10-4] in 2.2.1. Hardware .
- [C-10-3] DEVE misurare e compensare l'offset Rx per garantire che il BLE RSSI mediano sia -55 dBm +/-10 dB a 1 m di distanza da un dispositivo di riferimento che trasmette a
ADVERTISE_TX_POWER_HIGH. - [C-10-4] DEVE misurare e compensare l'offset Tx per garantire che il BLE RSSI mediano sia -55 dBm +/-10 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e trasmettendo a
ADVERTISE_TX_POWER_HIGH.
20 novembre 2023
2. Tipi di dispositivi
Vedi revisione
Se le implementazioni dei dispositivi portatili dichiarano il supporto di qualsiasi ABI a 64 bit (con o senza ABI a 32 bit):
Vedi revisione
- [ 7.5 /H-1-13] DEVE supportare la funzionalità
LOGICAL_MULTI_CAMERAper la fotocamera principale posteriore se sono presenti più di 1 fotocamera posteriore RGB.
- [ 7.5 /H-1-13] DEVE supportare la funzionalità
Vedi revisione
[ 5.8 /T-0-1] È NECESSARIO impostare la modalità di uscita HDMI sulla risoluzione più alta per il formato SDR o HDR scelto che funzioni con una frequenza di aggiornamento di 50 Hz o 60 Hz per il display esterno.
È NECESSARIO impostare la modalità di uscita HDMI per selezionare la risoluzione massima che può essere supportata con una frequenza di aggiornamento di 50 Hz o 60 Hz.
Vedi revisione
- [9/W-0-1] DEVE dichiarare la
android.hardware.security.model.compatible feature.
- [9/W-0-1] DEVE dichiarare la
6. Compatibilità degli strumenti e delle opzioni per sviluppatori
Vedi revisione
- [C-0-12] DEVE scrivere un atom
LMK_KILL_OCCURRED_FIELD_NUMBERnel
Vedi revisione
- [C-0-13] DEVE implementare il comando shell
dumpsys gpu --gpuworkda visualizzare
- [C-0-12] DEVE scrivere un atom
9. Compatibilità del modello di sicurezza
9.7. Caratteristiche di sicurezza :
Vedi revisione
Se le implementazioni del dispositivo utilizzano un kernel Linux in grado di supportare SELinux,:
Vedi revisione
Se le implementazioni del dispositivo utilizzano kernel diversi da Linux o Linux senza SELinux,:
4 ottobre 2023
2. Tipi di dispositivi
Vedi revisione
Le implementazioni dei dispositivi Android sono classificate come palmari se soddisfano tutti i seguenti criteri:
- Avere una dimensione dello schermo con diagonale fisica compresa tra 4 pollici
e 3,3 pollici (o 2,5 pollici per le implementazioni del dispositivo fornite con il livello API 29 o precedente)e 8 pollici.
Inizia nuovi requisiti
- Avere un'interfaccia di input touchscreen.
- Avere una dimensione dello schermo con diagonale fisica compresa tra 4 pollici
Vedi revisione
Implementazioni di dispositivi portatili:
- [ 7.1 .1.1/H-0-1] DEVE avere almeno un
display compatibile con Android che soddisfi tutti i requisiti descritti in questo documento.display che misuri almeno 2,2" sul lato corto e 3,4" sul lato lungo.
Se le implementazioni dei dispositivi portatili supportano la rotazione dello schermo del software,:
- [ 7.1 .1.1/H-1-1]* DEVE fare in modo che lo schermo logico reso disponibile per le applicazioni di terze parti sia di almeno 2 pollici sul lato corto e 2,7 pollici sul lato lungo. I dispositivi forniti con il livello API Android 29 o precedente POSSONO essere esentati da questo requisito.
Se le implementazioni dei dispositivi portatili non supportano la rotazione dello schermo del software,:
- [ 7.1 .1.1/H-2-1]* DEVE fare in modo che lo schermo logico reso disponibile per applicazioni di terze parti sia di almeno 2,7 pollici sul lato corto. I dispositivi forniti con il livello API Android 29 o precedente POSSONO essere esentati da questo requisito.
Inizia nuovi requisiti
[ 7.1 .1.1/H-0-3]* DEVE mappare ogni display
UI_MODE_NORMALreso disponibile per applicazioni di terze parti su un'area di visualizzazione fisica libera che sia di almeno 2,2 pollici sul lato corto e 3,4 pollici sul lato lungo.[ 7.1 .1.3/H-0-1]* DEVE impostare il valore di
DENSITY_DEVICE_STABLEsu un valore pari o superiore al 92% rispetto alla densità fisica effettiva del display corrispondente.
Se le implementazioni del dispositivo portatile dichiarano
android.hardware.audio.outputeandroid.hardware.microphone, essi:[ 5.6 /H-1-1] DEVE avere una latenza media di andata e ritorno continua di 300 millisecondi o meno su 5 misurazioni, con una deviazione assoluta media inferiore a 30 ms , sui seguenti percorsi dati: "dall'altoparlante al microfono", 3,5 mm adattatore loopback (se supportato), loopback USB (se supportato).
[ 5.6 /H-1-2] DEVE avere una latenza media da tocco a tono di 300 millisecondi o meno su almeno 5 misurazioni sul percorso dati dall'altoparlante al microfono.
Se le implementazioni dei dispositivi portatili includono almeno un attuatore tattile, questi:
- [ 7.10 /H]* NON DOVREBBE utilizzare un attuatore tattile (vibratore) con massa rotante eccentrica (ERM).
- [ 7.10 /H]* DOVREBBE implementare tutte le costanti pubbliche per una sensazione tattile chiara in android.view.HapticFeedbackConstants , vale a dire (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START e GESTURE_END ).
- [ 7.10 /H]* DOVREBBE implementare tutte le costanti pubbliche per una sensazione tattile chiara in android.os.VibrationEffect , vale a dire (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK e EFFECT_DOUBLE_CLICK) e tutte le costanti pubbliche
PRIMITIVE_*possibili per una sensazione tattile ricca in android.os.VibrationEffect.Composition , vale a dire ( CLIC, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Alcune di queste primitive, come LOW_TICK e SPIN, possono essere realizzabili solo se il vibratore può supportare frequenze relativamente basse. - [7.10/H]* DOVREBBE seguire la guida per mappare le costanti pubbliche in android.view.HapticFeedbackConstants alle costanti android.os.VibrationEffect consigliate, con le relazioni di ampiezza corrispondenti.
- [ 7.10 /H]* DOVREBBE seguire la valutazione della qualità per le API createOneShot() e createWaveform() .
- [ 7.10 /H]* DOVREBBE verificare che il risultato dell'API pubblica android.os.Vibrator.hasAmplitudeControl() rifletta correttamente le capacità del vibratore.
- [ 7.10 /H]* DOVREBBE posizionare l'attuatore vicino alla posizione in cui il dispositivo viene generalmente tenuto o toccato con le mani.
Se le implementazioni dei dispositivi portatili includono almeno un attuatore risonante lineare 7.10 per uso generale , questi:
- [ 7.10 /H] DOVREBBE posizionare l'attuatore vicino alla posizione in cui il dispositivo viene generalmente tenuto o toccato con le mani.
- [ 7.10 /H] DOVREBBE spostare l'attuatore tattile sull'asse X (sinistra-destra) dell'orientamento
verticalenaturale del dispositivo .
Se le implementazioni dei dispositivi portatili dispongono di un attuatore tattile per uso generale che è un attuatore risonante lineare dell'asse X (LRA), essi:
- [ 7.10 /H] DOVREBBE avere la frequenza di risonanza dell'LRA dell'asse X inferiore a 200 Hz.
- [ 7.1 .1.1/H-0-1] DEVE avere almeno un
Vedi revisione
Le implementazioni dei dispositivi portatili DEVONO supportare i seguenti formati di codifica video e renderli disponibili per applicazioni di terze parti:
- [ 5.2 /H-0-3] AV1
Le implementazioni dei dispositivi portatili DEVONO supportare i seguenti formati di decodifica video e renderli disponibili per applicazioni di terze parti:
- [ 5.3 /H-0-6] AV1
Vedi revisione
Se le implementazioni del dispositivo, incluso il tasto di navigazione delle funzioni recenti come descritto in dettaglio nella sezione 7.2.3, alterano l'interfaccia, queste:
- [ 3.8 .3/H-1-1] DEVE implementare il comportamento di blocco dello schermo e fornire all'utente un menu di impostazioni per attivare/disattivare la funzionalità.
Se le implementazioni dei dispositivi portatili includono il supporto per
ControlsProviderServicee le APIControle consentono ad applicazioni di terze parti di pubblicare controlli del dispositivo , allora:- [ 3.8 .16/H-1-6] Le implementazioni del dispositivo DEVONO rappresentare accuratamente l'affordance dell'utente come segue:
- Se il dispositivo ha impostato
config_supportsMultiWindow=truee l'app dichiara i metadatiMETA_DATA_PANEL_ACTIVITYnella dichiarazioneControlsProviderService, incluso il ComponentName di un'attività valida (come definito dall'API), l'app DEVE incorporare tale attività in questa affordance dell'utente. - Se l'app non dichiara metadati
META_DATA_PANEL_ACTIVITY, DEVE eseguire il rendering dei campi specificati forniti dall'APIControlsProviderServicenonché di tutti i campi specificati forniti dalle API di controllo .
- Se il dispositivo ha impostato
- [ 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] utilizzandoEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLSall'avvio dell'attività incorporata.
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 di funzionalità
android.software.telecom. - [ 7.4.1.2 /H-0-2] DEVE implementare il framework delle telecomunicazioni .
2.2.4. Prestazioni e potenza :
Vedi revisione
Implementazioni di dispositivi portatili:
- [ 8.5 /H-0-1] DEVE fornire un'affordance utente
nel menu Impostazioniper vedere tutte le app con servizi in primo piano attivi o processi avviati dall'utente, inclusa la durata di ciascuno di questi servizi da quando è stato avviato come descritto nel documento SDK .e la possibilità di arrestare un'app che esegue un servizio in primo piano o un processo avviato dall'utente.con la possibilità di arrestare un'app che esegue un servizio in primo piano e visualizzare tutte le app che hanno servizi in primo piano attivi e la durata di ciascuno di questi servizi da quando è stato avviato, come descritto nel documento SDK .- Alcune app POTREBBERO essere esentate dall'arresto o dall'inclusione nell'elenco delle offerte utente, come descritto nel documento SDK .
- [ 8.5 /H-0-1] DEVE fornire un'affordance utente
- [ 8.5 /H-0-2]DEVE fornire un'affordance all'utente per arrestare un'app che esegue un servizio in primo piano o un processo avviato dall'utente.
Vedi revisione
Se le implementazioni del dispositivo dichiarano il supporto per android.hardware.telephony ,:
- [ 9.5 /H-1-1] NON DEVE impostare
UserManager.isHeadlessSystemUserModesutrue.
Se le implementazioni del dispositivo dispongono di una schermata di blocco sicura e includono uno o più agenti attendibili, che implementano l'API TrustAgentService System, essi:
- [ 9.11.1 /H-1-1] DEVE richiedere all'utente uno dei metodi di autenticazione primari consigliati (ad esempio: PIN, sequenza, password) più frequentemente di una volta ogni 72 ore.
Se le implementazioni dei dispositivi portatili impostano UserManager.isHeadlessSystemUserMode su true , essi
Se le implementazioni dei dispositivi portatili supportano l'API di sistema HotwordDetectionService o un altro meccanismo per il rilevamento di hotword senza indicazione di accesso al microfono:
- [9.8/H-1-1] DEVE assicurarsi che il servizio di rilevamento hotword possa trasmettere dati solo al sistema,
ContentCaptureServiceo al servizio di riconoscimento vocale sul dispositivo creato daSpeechRecognizer#createOnDeviceSpeechRecognizer(). - [9.8/H-1-6] NON DEVE consentire che più di 100 byte di dati (esclusi i flussi audio) vengano trasmessi dal servizio di rilevamento hotword per ciascun risultato hotword riuscito.
- [9.8/H-1-15] DEVE garantire che i flussi audio forniti sui risultati hotword riusciti siano trasmessi unidirezionali dal servizio di rilevamento hotword al servizio di interazione vocale.
Se le implementazioni del dispositivo includono un'applicazione che utilizza l'API di sistema HotwordDetectionService o un meccanismo simile per il rilevamento di hotword senza indicazione dell'utilizzo del microfono, l'applicazione:
- [9.8/H-2-3] NON DEVE trasmettere dal servizio di rilevamento hotword, dati audio, dati che possono essere utilizzati per ricostruire (totalmente o parzialmente) l'audio, o contenuti audio non correlati alla hotword stessa, ad eccezione del
ContentCaptureServiceo servizio di riconoscimento vocale sul dispositivo.
Se le implementazioni dei dispositivi portatili supportano l'API di sistema VisualQueryDetectionService o un altro meccanismo per il rilevamento delle query senza indicazione di accesso al microfono e/o alla videocamera:
- [9.8/H-3-1] DEVE assicurarsi che il servizio di rilevamento delle query possa trasmettere dati solo al sistema, o
ContentCaptureServiceo al servizio di riconoscimento vocale sul dispositivo (creato daSpeechRecognizer#createOnDeviceSpeechRecognizer()). - [9.8/H-3-2] NON DEVE consentire la trasmissione di informazioni audio o video da
VisualQueryDetectionService, ad eccezione diContentCaptureServiceo del servizio di riconoscimento vocale sul dispositivo. - [9.8/H-3-3] DEVE visualizzare un avviso per l'utente nell'interfaccia utente del sistema quando il dispositivo rileva l'intenzione dell'utente di interagire con l'applicazione Digital Assistant (ad esempio rilevando la presenza dell'utente tramite la fotocamera).
- [9.8/H-3-4] DEVE visualizzare un indicatore del microfono e visualizzare la query dell'utente rilevata nell'interfaccia utente subito dopo averla rilevata.
- [9.8/H-3-5] NON DEVE consentire a un'applicazione installabile dall'utente di fornire il servizio di rilevamento delle query visive.
Vedi revisione
Se le implementazioni del dispositivo portatile restituiscono android.os.Build.VERSION_CODES.T per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , allora:
- DEVE soddisfare i requisiti multimediali elencati nella sezione 2.2.7.1 del CDD di Android 13 .
Inizia nuovi requisiti
Se le implementazioni del dispositivo portatile restituisconoandroid.os.Build.VERSION_CODES.U per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , allora:- [5.1/H-1-1] DEVE pubblicizzare il numero massimo di sessioni di decodificatore video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi
CodecCapabilities.getMaxSupportedInstances()eVideoCapabilities.getSupportedPerformancePoints(). - [5.1/H-1-2] DEVE supportare 6 istanze di sessioni di decoder video hardware a 8 bit (SDR) (AVC, HEVC, VP9, AV1 o successivo) in qualsiasi combinazione di codec in esecuzione contemporaneamente con 3 sessioni con risoluzione 1080p a 30 fps e 3 sessioni con risoluzione 4K a 30 fps, a meno che AV1. I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30fps.
- [5.1/H-1-3] DEVE pubblicizzare il numero massimo di sessioni di codificatore video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi
CodecCapabilities.getMaxSupportedInstances()eVideoCapabilities.getSupportedPerformancePoints(). - [5.1/H-1-4] DEVE supportare 6 istanze di sessioni di codificatore video hardware a 8 bit (SDR) (AVC, HEVC, VP9, AV1 o successivo) in qualsiasi combinazione di codec in esecuzione contemporaneamente con 4 sessioni con risoluzione 1080p a 30 fps e 2 sessioni con risoluzione 4K a 30 fps, a meno che AV1. I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30fps.
- [5.1/H-1-5] DEVE pubblicizzare il numero massimo di sessioni di codifica e decodifica video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi
CodecCapabilities.getMaxSupportedInstances()eVideoCapabilities.getSupportedPerformancePoints(). - [5.1/H-1-6] DEVE supportare 6 istanze di decoder video hardware a 8 bit (SDR) e sessioni di codifica video hardware (AVC, HEVC, VP9, AV1 o successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente con 3 sessioni a 4K Risoluzione a 30 fps (a meno che non sia AV1), di cui al massimo 2 sono sessioni di codifica e 3 sessioni con risoluzione 1080p. I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30fps.
- [5.1/H-1-19] DEVE supportare 3 istanze di decoder video hardware a 10 bit (HDR) e sessioni di codifica video hardware (AVC, HEVC, VP9, AV1 o successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente con una risoluzione di 4K a 30 fps (a meno che AV1) di cui al massimo 1 è una sessione di codifica, che può essere configurata nel formato di input RGBA_1010102 tramite una superficie GL. La generazione di metadati HDR da parte del codificatore non è necessaria se si codifica dalla superficie GL. Le sessioni del codec AV1 devono supportare solo la risoluzione 1080p anche quando questo requisito richiede 4K.
- [5.1/H-1-7] DEVE avere una latenza di inizializzazione del codec pari o inferiore a 40 ms per una sessione di codifica video 1080p o inferiore per tutti i codificatori video hardware quando sotto carico. Il caricamento qui è definito come una sessione simultanea di transcodifica solo video da 1080p a 720p utilizzando codec video hardware insieme all'inizializzazione della registrazione audio-video 1080p. Per il codec Dolby Vision, la latenza di inizializzazione del codec DEVE essere pari o inferiore a 50 ms.
- [5.1/H-1-8] DEVE avere una latenza di inizializzazione del codec pari o inferiore a 30 ms per una sessione di codifica audio con bitrate pari o inferiore a 128 kbps per tutti i codificatori audio quando sono sotto carico. Il caricamento qui è definito come una sessione simultanea di transcodifica solo video da 1080p a 720p utilizzando codec video hardware insieme all'inizializzazione della registrazione audio-video 1080p.
- [5.1/H-1-9] DEVE supportare 2 istanze di sessioni di decoder video hardware sicure (AVC, HEVC, VP9, AV1 o successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a risoluzione 4K a 30 fps (a meno che AV1) per entrambi 8- bit (SDR) e contenuti HDR a 10 bit. Le sessioni del codec AV1 devono supportare solo la risoluzione 1080p anche quando questo requisito richiede 4K.
- [5.1/H-1-10] DEVE supportare 3 istanze di sessioni di decodificatore video hardware non sicure insieme a 1 istanza di sessione di decodificatore video hardware sicuro (4 istanze in totale) (AVC, HEVC, VP9, AV1 o successivo) in qualsiasi codec combinazione eseguita contemporaneamente con 3 sessioni con risoluzione 4K a 30 fps (a meno che non sia AV1) che include una sessione con decodificatore sicuro e 1 sessione nn sicura con risoluzione 1080p a 30 fps dove al massimo 2 sessioni possono essere in HDR a 10 bit. Le sessioni del codec AV1 devono supportare solo la risoluzione 1080p anche quando questo requisito richiede 4K.
- [5.1/H-1-11] DEVE supportare un decoder sicuro per ogni decoder hardware AVC, HEVC, VP9 o AV1 sul dispositivo.
- [5.1/H-1-12] DEVE avere una latenza di inizializzazione del codec pari o inferiore a 40 ms per una sessione di decodifica video a 1080p o inferiore per tutti i decoder video hardware quando sotto carico. Il caricamento qui è definito come una sessione simultanea di transcodifica solo video da 1080p a 720p utilizzando codec video hardware insieme all'inizializzazione della riproduzione audio-video 1080p. Per il codec Dolby Vision, la latenza di inizializzazione del codec DEVE essere pari o inferiore a 50 ms.
- [5.1/H-1-13] DEVE avere una latenza di inizializzazione del codec pari o inferiore a 30 ms per una sessione di decodifica audio con bitrate pari o inferiore a 128 kbps per tutti i decoder audio quando sono sotto carico. Il caricamento qui è definito come una sessione simultanea di transcodifica solo video da 1080p a 720p utilizzando codec video hardware insieme all'inizializzazione della riproduzione audio-video 1080p.
- [5.1/H-1-14] DEVE supportare il decodificatore hardware AV1 Main 10, Livello 4.1 e la grana della pellicola.
- [5.1/H-1-15] DEVE avere almeno 1 decoder video hardware che supporti 4K60.
- [5.1/H-1-16] DEVE avere almeno 1 codificatore video hardware che supporti 4K60.
- [5.3/H-1-1] NON DEVE perdere più di 1 fotogramma in 10 secondi (ovvero meno dello 0,167% di calo di fotogrammi) per una sessione video 4K a 60 fps sotto carico.
- [5.3/H-1-2] NON DEVE perdere più di 1 fotogramma in 10 secondi durante una modifica della risoluzione video in una sessione video a 60 fps sotto carico per una sessione 4K.
- [5.6/H-1-1] DEVE avere una latenza tap-to-tone pari o inferiore a 80 millisecondi utilizzando il test tap-to-tone di CTS Verifier.
- [5.6/H-1-2] DEVE avere una latenza audio di andata e ritorno di 80 millisecondi o meno su almeno un percorso dati supportato.
- [5.6/H-1-3] DEVE supportare audio >=24 bit per l'uscita stereo su jack audio da 3,5 mm se presente e su audio USB se supportato attraverso l'intero percorso dati per configurazioni a bassa latenza e streaming. Per la configurazione a bassa latenza, AAudio deve essere utilizzato dall'app in modalità di callback a bassa latenza. Per la configurazione dello streaming, l'app deve utilizzare una traccia audio Java. Sia nella configurazione a bassa latenza che in quella di streaming, il sink di output HAL deve accettare
AUDIO_FORMAT_PCM_24_BIT,AUDIO_FORMAT_PCM_24_BIT_PACKED,AUDIO_FORMAT_PCM_32_BIToAUDIO_FORMAT_PCM_FLOATper il formato di output di destinazione. - [5.6/H-1-4] DEVE supportare dispositivi audio USB >=4 canali (utilizzato dai controller DJ per l'anteprima dei brani).
- [5.6/H-1-5] DEVE supportare dispositivi MIDI conformi alla classe e dichiarare il flag di funzionalità MIDI.
- [5.6/H-1-9] DEVE supportare almeno 12 canali di missaggio. Ciò implica la possibilità di aprire una traccia audio con maschera di canale 7.1.4 e spazializzare o effettuare il downmix di tutti i canali in stereo in modo corretto.
- [5.6/H-SR] Sono FORTEMENTE RACCOMANDATI per supportare il mixaggio a 24 canali con almeno il supporto per le maschere di canale 9.1.6 e 22.2.
- [5.7/H-1-2] DEVE supportare
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALLcon le funzionalità di decrittografia dei contenuti riportate di seguito.
| Dimensione minima del campione | 4 MB |
| Numero minimo di sottocampioni: H264 o HEVC | 32 |
| Numero minimo di sottocampioni - VP9 | 9 |
| Numero minimo di sottocampioni - AV1 | 288 |
| Dimensione minima del buffer del sottocampione | 1 MB |
| Dimensione minima del buffer crittografico generico | 500 KiB |
| Numero minimo di sessioni simultanee | 30 |
| Numero minimo di chiavi per sessione | 20 |
| Numero totale minimo di chiavi (tutte le sessioni) | 80 |
| Numero totale minimo di chiavi DRM (tutte le sessioni) | 6 |
| Dimensione del messaggio | 16 KiB |
| Frame decrittografati al secondo | 60 fps |
- [5.1/H-1-17] DEVE avere almeno 1 decodificatore di immagini hardware che supporti il profilo di base AVIF.
- [5.1/H-1-18] DEVE supportare l'encoder AV1 che può codificare con una risoluzione fino a 480p a 30 fps e 1 Mbps.
-
[5.12/H-1-1] DEVE[5.12/H-SR] Sono fortemente consigliati per supportare la funzioneFeature_HdrEditingper tutti gli encoder hardware AV1 e HEVC presenti sul dispositivo. - [5.12/H-1-2] DEVE supportare il formato colore RGBA_1010102 per tutti gli encoder hardware AV1 e HEVC presenti sul dispositivo.
- [5.12/H-1-3] DEVE pubblicizzare il supporto per l'estensione EXT_YUV_target per campionare da texture YUV sia a 8 che a 10 bit.
- [7.1.4/H-1-1] DEVE avere almeno 6 overlay hardware nel compositore hardware (HWC) dell'unità di elaborazione dati (DPU), di cui almeno 2 in grado di visualizzare contenuto video a 10 bit.
Se le implementazioni dei dispositivi portatili restituiscono android.os.Build.VERSION_CODES.U per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS e includono il supporto per un codificatore hardware AVC o HEVC, allora:
- [5.2/H-2-1] DEVE soddisfare l'obiettivo di qualità minimo definito dalle curve di distorsione della velocità del codificatore video per i codec hardware AVC e HEVC, come definito nella prossima documentazione.
Vedi revisione
android.os.Build.VERSION_CODES.U per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , allora:- [ 7.5 /H-1-1] DEVE avere una fotocamera principale posteriore con una risoluzione di almeno 12 megapixel che supporti l'acquisizione video a 4k a 30 fps. La fotocamera posteriore principale è quella con l'ID fotocamera più basso.
- [ 7.5 /H-1-2] DEVE avere una fotocamera principale frontale con una risoluzione di almeno 6 megapixel e supportare l'acquisizione video a 1080p@30fps. La fotocamera frontale principale è quella con l'ID fotocamera più basso.
- [ 7.5 /H-1-3] DEVE supportare la proprietà
android.info.supportedHardwareLevelcome COMPLETA o migliore per entrambe le fotocamere principali. - [ 7.5 /H-1-4] DEVE supportare
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIMEper entrambe le fotocamere principali. - [ 7.5 /H-1-5] DEVE avere una latenza di acquisizione JPEG della fotocamera2 < 1000
900ms per una risoluzione 1080p misurata dal PerformanceTest della fotocamera CTS in condizioni di illuminazione ITS (3000K) per entrambe le fotocamere principali. - [ 7.5 /H-1-6] DEVE avere una latenza di avvio della telecamera 2 (apertura della telecamera al primo fotogramma di anteprima) < 500 ms misurata dal PerformanceTest della telecamera CTS in condizioni di illuminazione ITS (3000 K) per entrambe le telecamere primarie.
- [ 7.5 /H-1-8] DEVE supportare
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAWeandroid.graphics.ImageFormat.RAW_SENSORper la fotocamera posteriore principale. - [ 7.5 /H-1-9] DEVE avere una fotocamera principale rivolta all'indietro che supporti 720p o 1080p a 240 fps.
- [ 7.5 /H-1-10] DEVE avere ZOOM_RATIO minimo < 1.0 per le fotocamere primarie se è presente una fotocamera RGB ultrawide rivolta nella stessa direzione.
- [ 7.5 /H-1-11] DEVE implementare lo streaming fronte-retro simultaneo sulle fotocamere primarie.
- [ 7.5 /H-1-12] DEVE supportare
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATIONsia per la fotocamera principale anteriore che per quella posteriore principale. - [ 7.5 /H-1-13] DEVE supportare la funzionalità
LOGICAL_MULTI_CAMERAper le telecamere primarie se sono presenti più di 1 telecamere RGB rivolte nella stessa direzione. - [ 7.5 /H-1-14] DEVE supportare la funzionalità
STREAM_USE_CASEsia per la fotocamera principale anteriore che per quella posteriore principale. - [ 7.5 /H-1-15] DEVE supportare le estensioni della modalità
Bokeh eNotte tramite le estensioni CameraX e Camera2 per le fotocamere primarie. - [ 7.5 /H-1-16] DEVE supportare la funzionalità DYNAMIC_RANGE_TEN_BIT per le fotocamere primarie.
- [ 7.5 /H-1-17] DEVE supportare CONTROL_SCENE_MODE_FACE_PRIORITY e il rilevamento del volto ( STATISTICS_FACE_DETECT_MODE_SIMPLE o STATISTICS_FACE_DETECT_MODE_FULL ) per le fotocamere principali.
Vedi revisione
android.os.Build.VERSION_CODES.U per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , allora:- [7.1.1.1/H-2-1] DEVE avere una risoluzione dello schermo di almeno 1080p.
- [7.1.1.3/H-2-1] DEVE avere una densità dello schermo di almeno 400 dpi.
- [7.1.1.3/H-3-1] DEVE avere un display HDR che supporti almeno 1000 nit in media.
- [7.6.1/H-2-1] DEVE avere almeno 8 GB di memoria fisica.
Vedi revisione
android.os.Build.VERSION_CODES.U per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , allora:- [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 sequenziale parallela con prestazioni di lettura 2x e scrittura 1x di almeno 50 MB/s.
Vedi revisione
Le implementazioni dei dispositivi televisivi DEVONO supportare i seguenti formati di codifica video e renderli disponibili per applicazioni di terze parti:
- [ 5.2 /T-0-3] AV1
Le implementazioni dei dispositivi televisivi DEVONO supportare i seguenti formati di decodifica video e renderli disponibili ad applicazioni di terze parti:
- [ 5.3.2 /T-0-7] AV1
Vedi revisione
Se le implementazioni del dispositivo dispongono di una schermata di blocco sicura e includono uno o più agenti attendibili, che implementano l'API TrustAgentService System, essi:
- [ 9.11.1 /W-1-1] DEVE richiedere all'utente uno dei metodi di autenticazione primari consigliati (ad esempio: PIN, sequenza, password) più frequentemente di una volta ogni 72 ore.
Vedi revisione
Se le implementazioni del dispositivo includono il supporto per le trasmissioni radio AM/FM ed espongono la funzionalità a qualsiasi applicazione, esse:
- [ 7.4
.10/A-0-1] DEVE dichiarare il supporto perFEATURE_BROADCAST_RADIO.
Una telecamera per la visione esterna è una telecamera che riprende scene esterne all'implementazione del dispositivo, come la telecamera per la retromarcia.
Implementazioni di dispositivi automobilistici:
- DOVREBBE includere una o più telecamere per la visione esterna.
Se le implementazioni dei dispositivi automobilistici includono una telecamera per la visione esterna, per tale telecamera:
- [ 7.5 /A-1-1] NON DEVE avere telecamere per la visione esterna accessibili tramite le API della fotocamera Android , a meno che non siano conformi ai requisiti principali della fotocamera.
- [ 7.5 /A-SR-1] Si CONSIGLIA FORTEMENTE di non ruotare o specchiare orizzontalmente l'anteprima della fotocamera.
- [ 7.5 /A-SR-2] È FORTEMENTE CONSIGLIATO avere una risoluzione di almeno 1,3 megapixel.
- DOVREBBE avere hardware a fuoco fisso o EDOF (profondità di campo estesa).
- PUÒ avere la messa a fuoco automatica hardware o software implementata nel driver della fotocamera.
Se le implementazioni di dispositivi automobilistici includono una o più telecamere per la visione esterna e caricano il servizio Exterior View System (EVS), per tale telecamera:
- [ 7.5 /A-2-1] NON DEVE ruotare o specchiare orizzontalmente l'anteprima della fotocamera.
Implementazioni di dispositivi automobilistici:
- PUÒ includere una o più fotocamere disponibili per applicazioni di terze parti.
Se le implementazioni dei dispositivi automobilistici includono almeno una fotocamera e la rendono disponibile ad applicazioni di terze parti, allora:
- [ 7.5 /A-3-1] DEVE segnalare il flag di funzionalità
android.hardware.camera.any. - [ 7.5 /A-3-2] NON DEVE dichiarare la fotocamera come fotocamera di sistema .
- PUÒ supportare le telecamere esterne descritte nella sezione 7.5.3 .
- POSSONO includere funzionalità (come la messa a fuoco automatica, ecc.) disponibili per le fotocamere posteriori come descritto nella sezione 7.5.1 .
Per telecamera posteriore si intende una telecamera rivolta al mondo che può essere posizionata in qualsiasi punto del veicolo ed è rivolta verso l'esterno dell'abitacolo del veicolo; ovvero, riprende scene sul lato opposto della carrozzeria del veicolo, come la telecamera per la retromarcia.
Per fotocamera frontale si intende una fotocamera rivolta all'utente che può essere posizionata in qualsiasi punto del veicolo ed è rivolta verso l'interno dell'abitacolo del veicolo; cioè immagina l'utente, ad esempio per videoconferenze e applicazioni simili.
Implementazioni di dispositivi automobilistici:
- [7.5/A-SR-1] È FORTEMENTE RACCOMANDATO di includere una o più telecamere rivolte al mondo.
- PUÒ includere una o più fotocamere rivolte all'utente.
- [7.5/A-SR-2] Sono FORTEMENTE CONSIGLIATI per supportare lo streaming simultaneo di più telecamere.
Se le implementazioni dei dispositivi automobilistici includono almeno una telecamera rivolta verso il mondo, per tale telecamera:
- [7.5/A-1-1] DEVE essere orientato in modo che la dimensione lunga della fotocamera sia allineata con il piano XY degli assi del sensore automobilistico Android.
- [7.5/A-SR-3] È FORTEMENTE CONSIGLIATO avere hardware a fuoco fisso o EDOF (profondità di campo estesa).
- [7.5/A-1-2] DEVE avere la fotocamera principale rivolta al mondo come fotocamera rivolta al mondo con l'ID fotocamera più basso.
Se le implementazioni dei dispositivi automobilistici includono almeno una telecamera rivolta all'utente, per tale telecamera:
- [7.5/A-2-1] La fotocamera principale rivolta all'utente DEVE essere quella con l'ID fotocamera più basso.
- PUÒ essere orientato in modo che la dimensione lunga della fotocamera sia allineata con il piano XY degli assi dei sensori automobilistici Android.
Se le implementazioni dei dispositivi automobilistici includono una fotocamera accessibile tramite l'API android.hardware.Camera o android.hardware.camera2 , allora:
- [7.5/A-3-1] DEVE essere conforme ai requisiti principali della fotocamera nella sezione 7.5.
Se le implementazioni dei dispositivi automobilistici includono una fotocamera che non è accessibile tramite l'API android.hardware.Camera o android.hardware.camera2 , allora:
- [7.5/A-4-1] DEVE essere accessibile tramite il servizio Extended View System.
Se le implementazioni dei dispositivi automobilistici includono una o più telecamere accessibili tramite il servizio Extended View System, per tale telecamera:
- [7.5/A-5-1] NON DEVE ruotare o specchiare orizzontalmente l'anteprima della telecamera.
- [7.5/A-SR-4] È FORTEMENTE CONSIGLIATO avere una risoluzione di almeno 1,3 megapixel.
Se le implementazioni dei dispositivi automobilistici includono una o più fotocamere accessibili sia tramite il servizio Extended View System che tramite l'API android.hardware.Camera o android.hardware.Camera2 , per tale fotocamera:
- [7.5/A-6-1] DEVE riportare lo stesso ID telecamera.
Se le implementazioni dei dispositivi automobilistici forniscono un'API della fotocamera proprietaria,:
- [7.5/A-7-1] DEVE implementare tale API della fotocamera utilizzando l'API
android.hardware.camera2o l'API Extended View System.
Vedi revisione
Implementazioni di dispositivi automobilistici:
- [ 3.8 /A-0-1] NON DEVE consentire agli utenti secondari completi che non sono l'utente in primo piano corrente di avviare attività e avere accesso all'interfaccia utente su qualsiasi display.
Vedi revisione
Se le implementazioni dei dispositivi automobilistici dichiarano android.hardware.microphone , essi:
- [ 9.8.2 /A-1-1] DEVE visualizzare l'indicatore del microfono quando un'app accede ai dati audio dal microfono, ma non quando al microfono accedono solo
HotwordDetectionService,SOURCE_HOTWORD,ContentCaptureServiceo app che ricoprono i ruoli indicati nella sezione 9.1 con identificatore CDD [C-4-X]. - [ 9.8.2 /A-1-2] Non DEVE nascondere l'indicatore del microfono per le app di sistema che hanno interfacce utente visibili o interazione diretta con l'utente.
- [ 9.8.2 /A-1-3] DEVE fornire all'utente la possibilità di attivare/disattivare il microfono nell'app Impostazioni.
Se le implementazioni dei dispositivi automobilistici dichiarano android.hardware.camera.any , allora:
- [ 9.8.2 /A-2-1] DEVE visualizzare l'indicatore della telecamera quando un'app accede ai dati della telecamera in tempo reale, ma non quando alla telecamera accedono solo le app che detengono i ruoli
definitinella Sezione 9.1 Autorizzazioni con identificatore CDD [C-4-X][C-3-X].
- [ 9.8.2 /A-2-3] DEVE fornire all'utente la possibilità di attivare/disattivare la fotocamera nell'app Impostazioni.
- [ 9.8.2 /A-2-4] DEVE visualizzare le app recenti e attive che utilizzano la fotocamera come restituito da
PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione ad esse associati.
Se le implementazioni del dispositivo dispongono di una schermata di blocco sicura e includono uno o più agenti attendibili, che implementano l'API TrustAgentService System:
- [ 9.11.1 /A-1-1] DEVE richiedere all'utente uno dei metodi di autenticazione primari consigliati (ad esempio: PIN, sequenza, password) più frequentemente di una volta ogni 336 ore.
3. Software
3.1. Compatibilità API gestite :
Vedi revisione
Implementazioni del dispositivo:
- [C-0-8] NON DEVE supportare l'installazione di applicazioni destinate a un livello API inferiore a 23.
3.2.3.5. Intenti di applicazione condizionale :
Vedi revisione
Se le implementazioni del dispositivo riportano
android.hardware.nfc.uiccoandroid.hardware.nfc.ese, essi:- [C-19-1] DEVE implementare l'API dell'intento NfcAdapter.ACTION_TRANSACTION_DETECTED (come "EVT_TRANSACTION" definito dalla specifica tecnica TS.26 della GSM Association - Requisiti del dispositivo NFC) .
3.3.1. Interfacce binarie dell'applicazione :
Vedi revisione
Implementazioni del dispositivo:
- [C-0-12] È NECESSARIO esportare i simboli di funzione per i simboli di funzione
Vulkan 1.0Vulkan 1.1 di base, nonché le estensioniVK_KHR_surface,VK_KHR_android_surface,VK_KHR_swapchain,VK_KHR_maintenance1eVK_KHR_get_physical_device_properties2attraverso la librerialibvulkan.so. Si noti che mentre tutti i simboli DEVONO essere presenti, la sezione 7.1.4.2 descrive in maggior dettaglio i requisiti per quando è prevista la completa implementazione di ciascuna funzione corrispondente.
- [C-0-12] È NECESSARIO esportare i simboli di funzione per i simboli di funzione
Vedi revisione
Se le implementazioni del dispositivo includono uno schermo o un output video,:
- [C-1-5] DEVE generare tavolozze tonali di colore dinamiche utilizzando gli stili di tema colore elencati nella documentazione di
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES(vediandroid.theme.customization.theme_styles), vale a direTONAL_SPOT,VIBRANT,EXPRESSIVE,SPRITZ,RAINBOW,FRUIT_SALADeMONOCHROMATIC.
- [C-1-5] DEVE generare tavolozze tonali di colore dinamiche utilizzando gli stili di tema colore elencati nella documentazione di
Vedi revisione
Se le implementazioni del dispositivo, incluso il tasto di navigazione delle funzioni recenti come descritto in dettaglio nella sezione 7.2.3, alterano l'interfaccia, queste:
- [C-1-2] DEVE implementare il comportamento di blocco dello schermo e fornire all'utente un menu di impostazioni per attivare/disattivare la funzionalità.
3.9.2 Supporto profili gestiti :
Vedi revisione
Se le implementazioni del dispositivo dichiarano
android.software.managed_users,:- [C-1-10] DEVE garantire che i dati dello screenshot vengano salvati nell'archivio del profilo di lavoro quando uno screenshot viene acquisito con una finestra
topActivityche ha il focus (quella con cui l'utente ha interagito per ultima tra tutte le attività) e appartiene a un profilo di lavoro app . - [C-1-11] NON DEVE acquisire nessun altro contenuto dello schermo (barra di sistema, notifiche o qualsiasi contenuto del profilo personale) ad eccezione della finestra/finestre dell'applicazione del profilo di lavoro quando si salva uno screenshot nel profilo di lavoro (per garantire che i dati del profilo personale siano non salvato nel profilo di lavoro).
- [C-1-10] DEVE garantire che i dati dello screenshot vengano salvati nell'archivio del profilo di lavoro quando uno screenshot viene acquisito con una finestra
3.9.5 Quadro di risoluzione delle policy relative ai dispositivi : nuova sezione
Vedi revisione
Se le implementazioni del dispositivo segnalano
android.software.device_adminoandroid.software.managed_users, allora:- [C-1-1] DEVE risolvere i conflitti relativi ai criteri del dispositivo come documentato nella documentazione AOSP.
5. Compatibilità multimediale
5.1.4. Codifica delle immagini :
Vedi revisione
Le implementazioni del dispositivo DEVONO supportare la codifica della seguente immagine:
- [C-0-4] AVIF
- I dispositivi devono supportare
BITRATE_MODE_CQe Baseline Profile.
- I dispositivi devono supportare
- [C-0-4] AVIF
5.1.5. Decodifica delle immagini :
Vedi revisione
Le implementazioni del dispositivo DEVONO supportare la decodifica della seguente codifica di immagini:
[C-0-7] AVIF (profilo di base)
5.1.6. Dettagli sui codec immagine :
Vedi revisione
Formato/Codec Dettagli Tipi di file/formati contenitore supportati JPEG Base+progressivo JPEG (.jpg) GIF GIF (.gif) PNG PNG (.png) BMP BMP (.bmp) WebP WebP (.webp) Crudo 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 base) Immagine, raccolta di immagini, sequenza di immagini Profilo di base Contenitore HEIF (.avif) Vedi revisione
Formato/Codec Dettagli Tipi di file/formati contenitore da supportare H.263 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, solo decodifica)
H.264AV Per i dettagli vedere le sezioni 5.2 e 5.3 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- MPEG-2 TS (.ts, non ricercabile)
- Matroska (.mkv, solo decodifica)
H.265HEVC Vedere la sezione 5.3 per i dettagli - MPEG-4 (.mp4)
- Matroska (.mkv, solo decodifica)
MPEG-2 Profilo principale - MPEG2-TS (.ts, non ricercabile)
- MPEG-4 (.mp4, solo decodifica)
- Matroska (.mkv, solo decodifica)
MPEG-4SP - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, solo decodifica)
VP8 Per i dettagli vedere le sezioni 5.2 e 5.3 - WebM (.webm)
- Matroska (.mkv)
VP9 Vedere la sezione 5.3 per i dettagli - WebM (.webm)
- Matroska (.mkv)
AV1 Per i dettagli vedere la sezione 5.2 e la sezione 5.3 - MPEG-4 (.mp4)
- Matroska (.mkv, solo decodifica)
5.1.10. Caratterizzazione del codec multimediale :
Vedi revisione
Se le implementazioni del dispositivo supportano i codec video:
- [C-2-1] Tutti i codec video DEVONO pubblicare i dati sulla frequenza dei fotogrammi ottenibili per le seguenti dimensioni se supportati dal codec:
SD (bassa qualità) SD (alta qualità) HD720p HD1080p UHD Risoluzione video - 176 x 144 px (H263, MPEG2, MPEG4)
- 352 x 288 px (codificatore MPEG4, H263, MPEG2)
- 320 x 180px (VP8, VP8)
- 320 x 240 px (altro)
- 704 x 576px (H263)
- 640 x 360px (VP8, VP9)
- 640 x 480 px (codificatore MPEG4)
- 720 x 480 px (altro, AV1 )
- 1408x1152px (H263)
- 1280 x 720 px (altro, AV1 )
1920 x 1080 px (diverso da MPEG4, AV1 ) 3840 x 2160 px (HEVC, VP9, AV1 ) Vedi revisione
Se le implementazioni del dispositivo supportano qualsiasi codificatore video e lo rendono disponibile per app di terze parti, queste:- NON DOVREBBE essere, su due finestre scorrevoli, più del 15% sopra il bitrate tra gli intervalli intraframe (I-frame).
- NON DOVREBBE essere superiore al 100% del bitrate in una finestra scorrevole di 1 secondo.
Se le implementazioni del dispositivo supportano qualsiasi codificatore video e lo rendono disponibile per app di terze parti, imposta il file
MediaFormat.KEY_BITRATE_MODEsuBITRATE_MODE_VBRin modo che l'encoder funzioni in modalità bitrate variabile, quindi, purché non influisca sul pavimento di qualità minima , il bitrate codificato:-
[C-5-1] non dovrebbeessere , oltre una finestra scorrevole, oltre il 15% rispetto ai bitrati tra intervalli intraframe (I-Frame). -
[C-5-2] non deveessere superiore al 100% rispetto al bitrate su una finestra scorrevole di 1 secondo.
Se le implementazioni del dispositivo supportano qualsiasi codificatore video e lo rendi disponibili per app di terze parti e impostare
MediaFormat.KEY_BITRATE_MODEsuBITRATE_MODE_CBRin modo che il codificatore funzioni in modalità bitrate costante, quindi il bitrate codificato:-
[C-6-1] deveessere fortemente raccomandato che [C-SR-2] non sia superiore al 15% rispetto al bitrate target su una finestra scorrevole di 1 secondo.
Vedi revisione
Se le implementazioni del dispositivo supportano gli encoder H.263 e lo rendono disponibile per le app di terze parti, loro:
- [C-1-1] deve supportare la risoluzione QCIF (176 x 144) usando il livello di profilo di base 45. La risoluzione SQCIF è facoltativa.
-
Dovrebbe supportare bitrati dinamicamente configurabili per l'encoder supportato.
Vedi revisione
Se le implementazioni del dispositivo supportano il codec H.265, loro:
- [C-1-1] deve supportare il livello del profilo principale 3 fino a 512 x 512 risoluzione .
-
Dovrebbe supportare i profili di codifica HD come indicato nella tabella seguente. - [C-SR-1] sono fortemente raccomandati per supportare il profilo SD 720 x 480 e i profili di codifica HD come indicato nella tabella seguente se esiste un encoder hardware.
5.2.6. AV1 : nuova sezione
Vedi revisione
Se le implementazioni del dispositivo supportano il codec AV1, allora:
- [C-1-1] deve supportare il profilo principale incluso il contenuto a 8 bit e a 10 bit.
[C-1-2] deve pubblicare i dati sulle prestazioni, cioè i dati sulle prestazioni del rapporto tramite
getSupportedFrameRatesFor()ogetSupportedPerformancePoints()API per risoluzioni supportate nella tabella seguente.[C-1-3] deve accettare i metadati HDR e superarlo nel bitstream
Se l'encoder AV1 è accelerato hardware, allora:
- [C-2-1] deve supportare fino al profilo di codifica HD1080p dalla tabella seguente:
SD HD 720p HD 1080p UHD Risoluzione video 720 x 480 px 1280 x 720 pixel 1920 x 1080 pixel 3840 x 2160 px Rate di frame video 30 fps 30 fps 30 fps 30 fps Bitrate video 5 Mbps 8 Mbps 16 Mbps 50 Mbps Vedi revisione
Se le implementazioni del dispositivo supportano decodificatori H.263, loro:
- [C-1-1] deve supportare il profilo di base Livello 30 (CIF, QCIF e SQCIF Resolutions @ 30FPS 384kbps) e Livello 45 (Resolutions QCIF e SQCIF @ 30fps 128kbps) .
Vedi revisione
Se le implementazioni del dispositivo supportano il codec AV1, loro:- [C-1-1] deve supportare il profilo 0 incluso il contenuto a 10 bit.
Se le implementazioni del dispositivo supportano il codec AV1 e lo rendi disponibili per applicazioni di terze parti, loro:
- [C-1-1] deve supportare il profilo principale incluso il contenuto a 8 bit e a 10 bit.
Se le implementazioni del dispositivo forniscono supporto per il codec AV1 con un decodificatore accelerato hardware, allora: loro:
- [C-2-1] deve essere in grado di decodificare almeno i profili di decodifica video HD 720p dalla tabella sottostante quando l'altezza riportata da
Display.getSupportedModes()il metodo è uguale o maggiore di 720p. - [C-2-2] deve essere in grado di decodificare almeno i profili di decodifica video HD 1080p dalla tabella sottostante quando l'altezza riportata da
Display.getSupportedModes()il metodo è uguale o maggiore di 1080p.
SD HD 720p HD 1080p UHD Risoluzione video 720 x 480 px 1280 x 720 pixel 1920 x 1080 pixel 3840 x 2160 px Rate di frame video 30 fps 30 fps 30 fps 30 fps Bitrate video 5 Mbps 8 Mbps 16 Mbps 50 Mbps Se le implementazioni del dispositivo supportano il profilo HDR tramite le API multimediali, allora:
- [C-3-1] deve supportare l'estrazione e l'output di metadati HDR dal bitstream e/o dal contenitore.
- [C-3-2] deve visualizzare correttamente il contenuto HDR sulla schermata del dispositivo o sulla porta di uscita video standard (ad esempio HDMI).
5.4.2. Cattura per il riconoscimento vocale :
Vedi revisione
Se le implementazioni del dispositivo dichiarano
android.hardware.microphone, loro:- Dovrebbe impostare la sensibilità di input audio in modo tale che una sorgente di tono sinusoidale da 1000 Hz sia stata riprodotta a 90 dB del livello di pressione sonora (SPL) (misurata
a una distanza di 30 cm dalmicrofono ) produce una risposta ideale di RMS 2500 all'interno di un intervallo di 1770 e 3530 per campioni a 16 bit (o -22,35 db ± 3db su scala piena per campioni di punto galleggiante/doppia precisione) per ogni microfono utilizzato per registrare la sorgente audio di riconoscimento vocale.
- Dovrebbe impostare la sensibilità di input audio in modo tale che una sorgente di tono sinusoidale da 1000 Hz sia stata riprodotta a 90 dB del livello di pressione sonora (SPL) (misurata
Vedi revisione
Se le implementazioni del dispositivo dichiarano la funzione
android.hardware.audio.output, loro:- [C-1-4] deve supportare gli effetti audio con input e output a punto mobile.
- [C-1-5] deve assicurarsi che gli effetti audio supportino più canali fino al conteggio dei canali del mixer noto anche come FCC_LIMIT.
Vedi revisione
Se le implementazioni del dispositivo dichiarano
android.hardware.audio.output, sono fortemente raccomandati per soddisfare o superare i seguenti requisiti:- [C-SR-4] Il timestamp di output restituito da AudioTrack.getTimestamp e
AAudioStream_getTimestampè accurato a +/- 1 ms.
- [C-SR-4] Le latenze di andata e ritorno calcolate basate su timestamp di input e output restituiti da
AAudioStream_getTimestampsono fortemente consigliate per essere entro 30 msec dalla latenza di andata e ritorno misurata perAAUDIO_PERFORMANCE_MODE_NONEeAAUDIO_PERFORMANCE_MODE_LOW_LATENCYper gli altoparlanti, per i semi wirelet aaudio.
- [C-SR-4] Il timestamp di output restituito da AudioTrack.getTimestamp e
7. Compatibilità hardware
Vedi revisione
Android include strutture che regolano automaticamente le risorse dell'applicazione e i layout dell'interfaccia utente in modo appropriato per il dispositivo per garantire che le applicazioni di terze parti funzionino bene su una
varietà di configurazioni hardware .varietà di display e configurazioni hardware. Un display compatibile con Android è una schermata che implementa tutti i comportamenti e le API descritti negli sviluppatori Android-Panoramica della compatibilità dello schermo , questa sezione (7.1) e le sue sottosezioni, nonché qualsiasi comportamento specifico di tipo dispositivo aggiuntivo documentato questo cdd.Sui visualizzazioni compatibili con Android in cui possono essere eseguite tutte le applicazioni compatibili con Android di terze parti, le implementazioni del dispositivo devono implementare correttamente queste API e comportamenti, come dettagliato in questa sezione.Avvia nuovi requisiti
Implementazioni del dispositivo:
- [C-0-1] deve, per impostazione predefinita, rendere applicazioni di terze parti solo su display compatibili con Android.
Le unità a cui si fa riferimento i requisiti in questa sezione sono definite come segue:
- dimensione diagonale fisica . La distanza in pollici tra due angoli opposti della porzione illuminata del display.
-
punti per pollice (dpi)densità . Il numero di pixel racchiusi da un arco orizzontale lineare o verticale di 1 " , espresso da pixel per pollice (PPI o DPI) . Laddove sono elencati i valoriDPIPPI e DPI , sia DPI orizzontale che verticale deve rientrare nell'intervallo elencato . - proporzioni . Il rapporto dei pixel della dimensione più lunga e della dimensione più corta dello schermo. Ad esempio, un display di 480x854 pixel sarebbe 854/480 = 1.779 o all'incirca "16: 9".
- Pixel indipendente dalla densità (DP) .
L'unità pixel virtuale normalizzata a una densità dello schermodello schermo da 160 dpidi 160. Per un po 'di densità D e un numero di pixel P, il numero di pixel indipendenti dalla densità DP, viene calcolato come:pixel = dps * (densità/160)dp = (160 / d) * p .
7.1.1.1. Dimensione e forma dello schermo :
Vedi revisione
Se le implementazioni del dispositivo supportano le schermate in grado di configurazione di dimensioni
UI_MODE_TYPE_NORMALeincludonodisplay fisici con compatibili Android con angoli arrotondati per rendere queste schermate , loro:- [C-1-1] deve garantire che almeno uno dei seguenti requisiti sia soddisfatto per ciascuno di questi display :
- Il raggio degli angoli arrotondati è inferiore o uguale a 38 dp.
Quando una scatola da 15 dp per 15 dp è ancorata ad ogni angolo del display logico, sullo schermo è visibile almeno un pixel di ogni scatola.
Dovrebbe includere la convenienza degli utenti per passare alla modalità di visualizzazione con gli angoli rettangolari.
Avvia nuovi requisiti
Se le implementazioni del dispositivo sono in grado solo della configurazione della tastiera
NO_KEYSe intendono segnalare il supporto per la configurazione della modalità UIUI_MODE_TYPE_NORMAL, loro:- [C-4-1] deve avere una dimensione del layout, escluse eventuali ritagli di visualizzazione, di almeno 596 dp x 384 dp o più.
Se le implementazioni del dispositivo includono un display compatibile con Android che è pieghevole o include una cerniera pieghevole tra più pannelli di visualizzazione e rende disponibili tali display per rendere app di terze parti, loro:
- [C-2-1] deve implementare l'ultima versione stabile disponibile dell'API Extensions o la versione stabile dell'API Sidecar da utilizzare dalla libreria Jetpack di Windows Manager .
Se le implementazioni del dispositivo includono un display compatibile con Android che è pieghevole o include una cerniera pieghevole tra più pannelli di visualizzazione e se la cerniera o la piega attraversano una finestra dell'applicazione a schermo intero, loro:
- [C-3-1] deve segnalare la posizione, i limiti e lo stato della cerniera o la piega attraverso estensioni o API Sidecar all'applicazione.
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 del pannello di visualizzazione compatibili con Android e rendono disponibili tali aree di visualizzazione, loro: loro:
- [C-4-1] deve implementare la versione corretta del livello API estensioni di Window Manager come descritto nella prossima documentazione.
7.1.1.2. Proprietà dello schermo : rimosso
7.1.1.3. Densità dello schermo :
Vedi revisione
Implementazioni del dispositivo:
- [C-0-1]
Per impostazione predefinita, le implementazioni del dispositivodevono segnalaresolouna delle densità del framework Android che sono elencate suDisplayMetricstramite l' APIDENSITY_DEVICE_STABLEe questo valore deve essere un valore statico per ciascun display fisiconon deve cambiare in qualsiasi momento; Tuttavia,tuttavia , il dispositivo può segnalare una diversadensità arbitrariaDisplayMetrics.densityin base alle modifiche alla configurazione del display apportate dall'utente (ad esempio, dimensione del display) impostata dopo l'avvio iniziale.
- Le implementazioni del dispositivo dovrebbero definire la densità del framework Android standard che è numericamente più vicina alla densità fisica dello schermo, a meno che tale densità logica non spinga la dimensione dello schermo riportata al di sotto del minimo supportato. Se la densità del framework Android standard che è numericamente più vicina alla densità fisica si traduce in una dimensione dello schermo inferiore alla più piccola dimensione dello schermo compatibile supportata (larghezza 320 dp), le implementazioni del dispositivo dovrebbero segnalare la successiva densità di framework Android standard più bassa.
Avvia nuovi requisiti
- Dovrebbe definire la densità del framework Android standard che è numericamente più vicino alla densità fisica dello schermo o un valore che mappare alla stessa misurazione equivalente del campo di vista angolare di un dispositivo portatile.
Se le implementazioni del dispositivo forniscono
unaconvenienza per modificare le dimensioni del display del dispositivo , loro :- [C-1-1]
La dimensione del display non deve essere ridimensionata,non è necessario ridimensionare il display maggiore di 1,5 volteDENSITY_DEVICE_STABLEdensità nativao produrre una dimensione di schermo minima efficace inferiore a 320 dp (equivalente alla qualificatore di risorse SW320dp), qualunque sia prima. - [C-1-2]
La dimensione del display non deve essere ridimensionata,non è necessario ridimensionare il display inferiore a 0,85 volte ladensità nativaDENSITY_DEVICE_STABLE.
- [C-0-1]
Vedi revisione
Se le implementazioni del dispositivo includono il supporto per Vulkan
1.0 o superiore, loro:[C-1-3] deve implementare pienamente le API
Vulkan 1.0Vulkan 1.1 per ciascunVkPhysicalDeviceenumerato.[C-1-5] non devono elencare i livelli forniti dalle librerie al di fuori del pacchetto dell'applicazione o fornire altri modi per tracciare o intercettare l'API Vulkan, a meno che l'applicazione non abbia l'attributo
android:debuggableimpostato cometrueo il metadaticom.android.graphics.injectLayers.enableimpostata sutrue.
- Dovrebbe supportare
VkPhysicalDeviceProtectedMemoryFeatureseVK_EXT_global_priority.
- [C-1-13] deve soddisfare i requisiti specificati dal profilo Android Baseline 2021 .
[C-SR-5] sono fortemente raccomandati per supportare
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemoryeVK_EXT_global_priority.[C-SR-6] sono fortemente raccomandati di utilizzare
SkiaVkcon HWUI.
Se le implementazioni del dispositivo includono il supporto per Vulkan 1.1 e dichiarano una qualsiasi delle flag di caratteristiche vulkan qui descritte , loro: loro:
- [C-SR-7] sono fortemente raccomandati per rendere disponibile l'estensione
VK_KHR_external_fence_fdper le applicazioni di terze parti e consentire all'applicazione di esportare un payload di recinzione e importare il payload Fence da descrittori di file POSIX come descritto qui .
Vedi revisione
Se le implementazioni del dispositivo hanno più sensori biometrici, loro:
[C-7-1] deve, quando un biometrico è in blocco (cioè il biometrico è disabilitato fino a quando l'utente si sblocca con l'autenticazione primaria) o il blocco legato al tempo (ovvero il biometrico è temporaneamente disabilitato fino a quando l'utente non attende un intervallo di tempo) A causa di troppi tentativi falliti, bloccano anche tutte le altre biometrie di una classe biometrica inferiore. Nel caso del blocco legato al tempo, il tempo di backoff per la verifica biometrica deve essere il tempo di backoff massimo di tutta la biometria nel blocco legato al tempo.
[C-SR-12] sono fortemente raccomandati, quando un biometrico è in blocco (cioè il biometrico è disabilitato fino a quando l'utente non si sblocca con l'autenticazione primaria) o il blocco legato al tempo (cioè il biometrico viene temporaneamente disabilitato fino a quando l'utente attende un tempo intervallo) a causa di troppi tentativi falliti, di bloccare anche tutte le altre biometrie della stessa classe biometrica. Nel caso del blocco legato al tempo, il tempo di backoff per la verifica biometrica è fortemente raccomandato per essere il tempo di backoff massimo di tutte le biometrie nel blocco legato al tempo.
[C-7-2] deve sfidare l'utente per l'autenticazione primaria consigliata (EG: PIN, Pattern, Password) per reimpostare il contatore di blocco per un blocco biometrico. La biometria di classe 3 può essere autorizzata a ripristinare il contatore di blocco per un biometrico bloccato della stessa o di classe inferiore. La biometria di classe 2 o di classe 1 non è consentita di completare un'operazione di blocco di ripristino per qualsiasi biometria.
Se le implementazioni del dispositivo desiderano trattare un sensore biometrico come classe 1 (precedentemente comodità ), loro:
[C-1-12] deve avere una parodia e un tasso di accettazione di imposter non superiore al 40% per specie di strumento di attacco di presentazione (PAI) , misurato dai protocolli di test di biometria Android .
[C-SR-13] è fortemente raccomandato per avere una parodia e un tasso di accettazione di imposter non superiore al 30% per specie di strumento di attacco di presentazione (PAI) , misurato dai protocolli di test di biometrica Android .
[C-SR-14] sono fortemente raccomandati per rivelare la classe biometrica del sensore biometrico e i rischi corrispondenti di abilitarlo.
[C-SR-17] sono fortemente raccomandati per implementare le nuove interfacce AIDL (come,
IFace.aidleIFingerprint.aidl).
Se le implementazioni del dispositivo desiderano trattare un sensore biometrico come classe 2 (precedentemente debole ), loro:
- [C-SR-15] si raccomanda fortemente di avere una parodia e un tasso di accettazione di imposter non superiore al 20% per specie di strumento di attacco di presentazione (PAI) , misurato dai protocolli di test di biometria Android .
- [C-2-3] deve eseguire la corrispondenza biometrica in un ambiente di esecuzione isolato al di fuori dello spazio di utente Android o kernel, come l'ambiente di esecuzione affidabile (TEE)
osu un chip con un canale sicuro per l'ambiente di esecuzione isolato o su Macchina virtuale che soddisfa i requisiti nella sezione 9.17 . - [C-2-4] deve avere tutti i dati identificabili crittografati e autenticati crittograficamente in modo tale da non poter essere acquisiti, letti o modificati al di fuori dell'ambiente di esecuzione isolato o un chip con un canale sicuro nell'ambiente di esecuzione isolato come documentato nelle linee guida di implementazione Sul sito del progetto open source Android o una macchina virtuale protetta controllata da Hypervisor che soddisfa i requisiti nella Sezione 9.17 .
- [C-2-5] per la biometria basata sulla telecamera, mentre l'autenticazione o l'iscrizione a base biometrica sta avvenendo:
- Deve azionare la fotocamera in una modalità che impedisce ai frame della fotocamera di essere letti o modificati al di fuori dell'ambiente di esecuzione isolato o un chip con un canale sicuro all'ambiente di esecuzione isolato o una macchina virtuale protetta controllata dall'hypervisor che soddisfa i requisiti nella sezione 9.17 .
- Per le soluzioni a videocamera RGB, i telai della fotocamera possono essere leggibili al di fuori dell'ambiente di esecuzione isolato per supportare operazioni come l'anteprima per l'iscrizione, ma non devono ancora essere alterabili.
- [C-2-7] non deve consentire l'accesso non crittografato a dati biometrici identificabili o eventuali dati derivati da esso (come gli incorporamenti) al processore di applicazione al di fuori del contesto del TEE o della macchina virtuale protetta controllata dall'hypervisor che soddisfa i requisiti nella sezione 9.17 . I dispositivi di aggiornamento lanciati su Android versione 9 o precedente non sono esentati da C-2-7.
Se le implementazioni del dispositivo desiderano trattare un sensore biometrico come classe 3 (precedentemente forte ), loro:
- [C-SR-16] è fortemente raccomandato per avere una parodia e un tasso di accettazione di imposter non superiore al 7% per specie di strumento di attacco di presentazione (PAI) , misurato dai protocolli di test di biometria Android .
7.3.13. IEEE 802.1.15.4 (UWB) :
Vedi revisione
Se le implementazioni del dispositivo includono il supporto per 802.1.15.4 ed esporre la funzionalità a un'applicazione di terze parti, loro:
- [C-1-2] deve segnalare il flag di funzionalità hardware
android.hardware.uwb. - [C-1-3] deve supportare tutti i seguenti set di configurazione (combinazioni predefinite di parametri FIRA UCI ) definite nell'implementazione AOSP.
-
CONFIG_ID_1: unicastSTATIC STS DS-TWRdefinito FIRA, Modalità differita, intervallo di distanza 240 ms. -
CONFIG_ID_2:STATIC STS DS-TWRstatica definita da FIRA, in modalità differita, intervallo di distanza 200 ms. Caso d'uso tipico: lo smartphone interagisce con molti dispositivi intelligenti. -
CONFIG_ID_3: uguale aCONFIG_ID_1, tranne i dati ango-di-arrival (AOA) non vengono riportati. -
CONFIG_ID_4: comeCONFIG_ID_1, tranne che la modalità di sicurezza P-STS è abilitata. -
CONFIG_ID_5: comeCONFIG_ID_2, tranne che la modalità di sicurezza P-STS è abilitata. -
CONFIG_ID_6: comeCONFIG_ID_3, tranne che la modalità di sicurezza P-STS è abilitata. -
CONFIG_ID_7: comeCONFIG_ID_2, tranne P-STS La modalità chiave del controllo individuale è abilitata.
-
- [C-1-4] deve fornire una convenienza dell'utente per consentire all'utente di attivare la radio UWB ON/OFF.
- [C-1-5] deve applicare che le app che utilizzano la radio UWB detengono l'autorizzazione
UWB_RANGING(ai sensi del gruppo di autorizzazioneNEARBY_DEVICES).
Il superamento delle pertinenti test di conformità e certificazione definite da organizzazioni standard, tra cui FIRA , CCC e CSA aiuta a garantire correttamente le funzioni 802.1.15.4.
- [C-1-2] deve segnalare il flag di funzionalità hardware
Vedi revisione
"Telefonia" utilizzata dalle API Android e questo documento si riferisce specificamente all'hardware relativo al posizionamento delle chiamate vocali e all'invio di messaggi SMS o alla creazione di dati mobili tramite un cellulare (EG GSM, CDMA, LTE, NR) GSM o CDMA. Un dispositivo a supporto della "telefonia" può scegliere di offrire alcuni o tutti i servizi di chiamata, messaggistica e dati adatti al prodotto.
tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano essere o meno a commutazione dei pacchetti, sono ai fini di Android considerati indipendenti da qualsiasi connettività di dati che può essere implementata utilizzando la stessa rete. In altre parole, la funzionalità di "telefonia" Android e le API si riferiscono specificamente a chiamate vocali e SMS. Ad esempio, le implementazioni del dispositivo che non possono effettuare chiamate o inviare/ricevere messaggi SMS non sono considerate un dispositivo di telefonia, indipendentemente dal fatto che utilizzino una rete cellulare per la connettività dei dati.Vedi revisione
Se le implementazioni del dispositivo includono il supporto per 802.11 ed esporre la funzionalità a un'applicazione di terze parti, loro:
- [C-1-4] deve supportare DNS multicast (MDNS) e non deve filtrare i pacchetti MDNS (224.0.0.251 o FF02 :: FB ) in qualsiasi momento dell'operazione, incluso quando lo schermo non è in uno stato attivo, a meno che non si lasci cadere o non Il filtraggio di questi pacchetti è necessario per rimanere entro gli intervalli di consumo di energia richiesti dai requisiti normativi applicabili al mercato target.
Per le implementazioni di dispositivi televisivi Android, anche quando si trova negli stati di potenza di standby.
- [C-1-4] deve supportare DNS multicast (MDNS) e non deve filtrare i pacchetti MDNS (224.0.0.251 o FF02 :: FB ) in qualsiasi momento dell'operazione, incluso quando lo schermo non è in uno stato attivo, a meno che non si lasci cadere o non Il filtraggio di questi pacchetti è necessario per rimanere entro gli intervalli di consumo di energia richiesti dai requisiti normativi applicabili al mercato target.
Vedi revisione
Se le implementazioni del dispositivo dichiarano caratteristiche_bluetooth_le, loro:
- [C-SR-2] sono fortemente raccomandati per misurare e compensare l'offset RX per garantire che la mediana RSSI sia -60dbm +/- 10 db a una distanza di 1 m da un dispositivo di riferimento che trasmette su
ADVERTISE_TX_POWER_HIGH, dove i dispositivi sono orientati in modo che siano in modo che siano in modo tale che lo siano Su "aerei paralleli" con schermi che affrontano la stessa direzione. - [C-SR-3] sono fortemente raccomandati per misurare e compensare l'offset TX per garantire che la mediana RSSI sia -60dbm +/- 10 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e trasmette su
ADVERTISE_TX_POWER_HIGH, dove i dispositivi sono orientati in modo tale che siano su "aerei paralleli" con schermi che affrontano la stessa direzione.
- [C-10-3] deve misurare e compensare l'offset RX per garantire che la mediana RSSI sia -55dbm +/- 10 dB a una distanza di 1 m da un dispositivo di riferimento che trasmette su
ADVERTISE_TX_POWER_HIGH. - [C-10-4] deve misurare e compensare l'offset TX per garantire che la mediana RSSI sia -55dbm +/- 10 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e trasmette su
ADVERTISE_TX_POWER_HIGH.
Se le implementazioni del dispositivo supportano Bluetooth versione 5.0, allora:
- [C-SR-4] sono fortemente raccomandati per fornire supporto per:
- Le 2m phy
- Le codec phy
- Estensione pubblicitaria le
- Pubblicità periodica
- Almeno 10 set di pubblicità
- Almeno 8 connessioni simultanee Le. Ogni connessione può essere in entrambi i ruoli di topologia di connessione.
- Privacy di Leyer Link
- Una dimensione di "elenco di risoluzione" di almeno 8 voci
- [C-SR-2] sono fortemente raccomandati per misurare e compensare l'offset RX per garantire che la mediana RSSI sia -60dbm +/- 10 db a una distanza di 1 m da un dispositivo di riferimento che trasmette su
Vedi revisione
- [C-1-7] deve garantire che la mediana delle misurazioni della distanza a 1 m dal dispositivo di riferimento sia entro [0,75 m, 1,25 m], dove la distanza di verità a terra viene misurata dal bordo superiore del DUT.
tenuto a faccia in su e inclinati di 45 gradi.
- [C-1-7] deve garantire che la mediana delle misurazioni della distanza a 1 m dal dispositivo di riferimento sia entro [0,75 m, 1,25 m], dove la distanza di verità a terra viene misurata dal bordo superiore del DUT.
7.5.1. Telecamera posteriore :
Vedi revisione
Una fotocamera posteriore è una fotocamera situata sul lato del dispositivo di fronte al display; Cioè, immagini scene sul lato opposto del dispositivo, come una fotocamera tradizionale.
Una fotocamera posteriore è una fotocamera rivolta al mondo che immagini scene sul lato opposto del dispositivo, come una fotocamera tradizionale; Su dispositivi portatili, questa è una fotocamera situata sul lato del dispositivo di fronte al display.
Vedi revisione
Una fotocamera frontale è una fotocamera situata sullo stesso lato del dispositivo del display; Cioè, una fotocamera in genere utilizzata per immaginare l'utente, ad esempio per le videoconferenze e applicazioni simili.
Una fotocamera frontale è una fotocamera rivolta all'utente che viene generalmente utilizzata per immaginare l'utente, ad esempio per la videoconferenza e applicazioni simili; Su dispositivi portatili, questa è una fotocamera situata sullo stesso lato del dispositivo del display.
Vedi revisione
Una fotocamera esterna è una fotocamera che può essere fisicamente collegata o staccata dall'implementazione del dispositivo in qualsiasi momento e può affrontare qualsiasi direzione; come telecamere USB.
7.5.4. Comportamento dell'API della fotocamera :
Vedi revisione
Le implementazioni del dispositivo devono implementare i seguenti comportamenti per le API relative alla fotocamera, per tutte le telecamere disponibili. Implementazioni del dispositivo:
- [C-SR-1] Per dispositivi con più telecamere RGB nelle immediate vicinanze e di fronte alla stessa direzione, si consiglia vivamente di supportare un dispositivo logico della telecamera che elenca la capacità
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, costituito da tutte le cameriche RGB che affrontano quella direzione di quella direzione RGB come sotto-dispositivi fisici.
- [C-SR-1] Per dispositivi con più telecamere RGB nelle immediate vicinanze e di fronte alla stessa direzione, si consiglia vivamente di supportare un dispositivo logico della telecamera che elenca la capacità
7.5.5. Orientamento della telecamera :
Vedi revisione
I dispositivi che soddisfano tutti i seguenti criteri sono esenti dal requisito sopra:
- Implementazioni del dispositivo che non sono in grado di essere ruotate dall'utente come i dispositivi automobilistici.
Vedi revisione
I dispositivi destinati a essere portatili o indossati possono includere un attuatore haptico per uso generale, disponibile per le applicazioni a fini, tra cui attirare l'attenzione attraverso suonerie, allarmi, notifiche e feedback del tocco generale.
Se le implementazioni del dispositivo non includono un attuatore tattile di tale scopo generale, loro:
- [7.10/c] deve restituire falso per
Vibrator.hasVibrator().
Se le implementazioni del dispositivo includono almeno uno di questi attuatori tattili per uso generale, loro:
- [C-1-1] deve restituire vero per
Vibrator.hasVibrator(). - Non dovrebbe utilizzare un attuatore tattile di massa rotante eccentrica (ERM) (vibratore).
- Dovrebbero implementare tutte le costanti pubbliche per gli Haptics Clear in
android.view.HapticFeedbackConstantsNamely (CLOCK_TICK,CONTEXT_CLICK,KEYBOARD_PRESS,KEYBOARD_RELEASE,KEYBOARD_TAP,LONG_PRESS,TEXT_HANDLE_MOVE,VIRTUAL_KEY,VIRTUAL_KEY_RELEASE,CONFIRM,REJECT,GESTURE_STARTeGESTURE_END). - Dovrebbero implementare tutte le costanti pubbliche per gli taptici chiari in
android.os.VibrationEffectvale a dire (EFFECT_TICK,EFFECT_CLICK,EFFECT_HEAVY_CLICKedEFFECT_DOUBLE_CLICK) e tutte le costanti pubbliche fattibili perPRIMITIVE_*per ricchi Haptics inandroid.os.VibrationEffect.Compositionnamely (CLICK,TICK,LOW_TICK,QUICK_FALL,QUICK_RISE,SLOW_RISE,SPIN,THUD). Alcune di queste primitive, comeLOW_TICKeSPINpossono essere realizzabili solo se il vibratore può supportare frequenze relativamente basse. - Dovrebbe seguire la guida per la mappatura delle costanti pubbliche in
android.view.HapticFeedbackConstantsalle costantiandroid.os.VibrationEffectraccomandate, con le corrispondenti relazioni di ampiezza. - Dovrebbe usare queste mappature di costanti tattili collegate.
- Dovrebbe seguire la valutazione della qualità per le API
createOneShot()ecreateWaveform(). - Dovrebbe verificare che il risultato dell'API pubblica
android.os.Vibrator.hasAmplitudeControl()rifletta correttamente le capacità del loro vibratore. - Dovrebbe verificare le capacità per la scalabilità dell'ampiezza eseguendo
android.os.Vibrator.hasAmplitudeControl().
Se le implementazioni del dispositivo seguono la mappatura delle costanti tattili, loro:
- Dovrebbe verificare lo stato di implementazione eseguendo
android.os.Vibrator.areAllEffectsSupported()eandroid.os.Vibrator.arePrimitivesSupported()API. - Dovrebbe eseguire una valutazione di qualità per le costanti tattili.
- Dovrebbe verificare e aggiornare se necessario la configurazione di fallback per le primitive non supportate come descritto nella guida di implementazione per le costanti.
- Dovrebbe fornire supporto a fallback per mitigare il rischio di fallimento come descritto qui .
Vedere la Sezione 2.2.1 per i requisiti specifici del dispositivo.
- [7.10/c] deve restituire falso per
9. Compatibilità del modello di sicurezza
Vedi revisione
Implementazioni del dispositivo:
- [C-0-4] deve avere una e solo un'implementazione di entrambe le interfacce utente.
Se le implementazioni del dispositivo preinstallano qualsiasi pacchetto che contiene una qualsiasi delle informazioni sull'interfaccia utente del sistema , l'intelligenza audio ambientale del sistema , l'intelligenza audio del sistema , l'intelligenza di notifica del sistema , l'intelligenza del testo del sistema o i ruoli di intelligenza visiva del sistema , i pacchetti:
- [C-4-1] deve soddisfare tutti i requisiti descritti per le implementazioni del dispositivo nelle sezioni
"9.8.6 Content Capture""9.8.6 Dati a livello di sistema operativo e ambientale e implementazioni API Sandboxed 9.8.15".
- [C-4-2] non deve avere il permesso Android.permission.internet. Questo è più severo del fortemente consigliato elencato nella sezione 9.8.6.
- [C-4-3] non deve legarsi ad altre app, ad eccezione delle seguenti app di sistema: Bluetooth, contatti, media, telefonia, sistema e componenti che forniscono API Internet. Questo è più severo del fortemente consigliato elencato nella sezione 9.8.6.
Se le implementazioni del dispositivo includono un'applicazione predefinita per supportare il
VoiceInteractionService, loro:- [C-5-1] non deve concedere
ACCESS_FINE_LOCATIONcome impostazione predefinita per tale applicazione.
Vedi revisione
Se le implementazioni del dispositivo creano il profilo utente aggiuntivo discusso sopra, allora:
- [C-4-5] deve distinguere visivamente le icone dell'applicazione a doppia istanza quando le icone vengono presentate agli utenti.
- [C-4-6] deve fornire un'abilità utente per eliminare interi dati del profilo clone.
- [C-4-7] deve disinstallare tutte le app cloni, eliminare le directory dei dati delle app private e il loro contenuto ed eliminare i dati del profilo clone, quando l'utente sceglie di eliminare i dati del profilo clone interi.
- Dovrebbe richiedere all'utente di eliminare i dati del profilo clone intero quando viene eliminata l'ultima app clone.
- [C-4-8] deve informare l'utente che i dati delle app verranno eliminati quando l'applicazione clone non è disinstallata o fornire un'opzione agli utenti per mantenere i dati delle app quando l'applicazione non è disinstallata dal dispositivo.
- [C-4-9] deve eliminare le directory dei dati delle app private e il loro contenuto, quando l'utente sceglie di eliminare i dati durante la disinstallazione.
[C-4-1] deve consentire la gestione degli intenti di seguito provenienti dal profilo aggiuntivo dalle applicazioni dell'utente primario sul dispositivo:
-
Intent.ACTION_VIEW -
Intent.ACTION_SENDTO -
Intent.ACTION_SEND -
Intent.ACTION_EDIT -
Intent.ACTION_INSERT -
Intent.ACTION_INSERT_OR_EDIT -
Intent.ACTION_SEND_MULTIPLE -
Intent.ACTION_PICK -
Intent.ACTION_GET_CONTENT -
MediaStore.ACTION_IMAGE_CAPTURE -
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] deve ereditare tutte le restrizioni degli utenti della politica del dispositivo e le restrizioni non utente selezionate (elenco di seguito) applicate sull'utente primario del dispositivo su questo profilo utente aggiuntivo.
[C-4-3] deve consentire solo la scrittura di contatti da questo profilo aggiuntivo tramite i seguenti intenti:
[C-4-4] non deve avere sincronizzazione di contatto in esecuzione per le applicazioni in esecuzione in questo profilo utente aggiuntivo.
- [C-4-14] deve avere l'autorizzazione e la gestione di archiviazione separate per le applicazioni in esecuzione in questo profilo aggiuntivo
- [C-4-5] deve consentire solo le applicazioni nel profilo aggiuntivo che hanno un'attività di avvio per accedere ai contatti già accessibili al profilo utente principale.
9.7. Caratteristiche di sicurezza :
Vedi revisione
Una tecnologia di sicurezza della memoria è una tecnologia che mitiga almeno le seguenti classi di bug con una probabilità elevata (> 90%) in applicazioni che utilizzano l'opzione Manifest
android:memtagMode:- Overflow tampone heap
- Utilizzare dopo gratuito
- doppio libero
- Wild Free (privo di un puntatore non malloc)
Implementazioni del dispositivo:
- [C-SR-15] sono fortemente raccomandati per impostare
ro.arm64.memtag.bootctl_supported.
Se le implementazioni del dispositivo impostano la proprietà del sistema
ro.arm64.memtag.bootctl_supportedsu true, loro:[C-3-1] deve consentire alla proprietà del sistema
arm64.memtag.bootctldi accettare un elenco separato da virgola dei seguenti valori, con l'effetto desiderato applicato sul successivo riavvio successivo:-
memtag: una tecnologia di sicurezza della memoria come definita sopra è abilitata -
memtag-once: una tecnologia di sicurezza della memoria come definita sopra è abilitata transitoriamente ed è automaticamente disabilitata, successivo riavvio -
memtag-off: una tecnologia di sicurezza della memoria come definita sopra è disabilitata
-
[C-3-2] deve consentire all'utente shell di impostare
arm64.memtag.bootctl.[C-3-3] deve consentire a qualsiasi processo di leggere
arm64.memtag.bootctl.[C-3-4] deve impostare
arm64.memtag.bootctlsullo stato attualmente richiesto al momento dell'avvio, deve anche aggiornare la proprietà, se l'implementazione del dispositivo consente di modificare lo stato senza modificare la proprietà del sistema.[C-SR-16] è fortemente raccomandato per mostrare un'impostazione sviluppatore che imposta Memtag-Once e riavvia il dispositivo. Con un bootloader compatibile, il progetto open source Android soddisfa i requisiti di cui sopra attraverso il protocollo di bootloader MTE .
- [C-SR-17] sono fortemente consigliati per mostrare un'impostazione nel menu Impostazioni di sicurezza che consente all'utente di abilitare
memtag.
Vedi revisione
Implementazioni del dispositivo:
- [C-0-2] deve visualizzare un avviso dell'utente e ottenere un consenso esplicito
dell'utenteconsentendo qualsiasi informazione sensibile visualizzata sullo schermo dell'utenteabilitatoLa fusione dello schermo o la registrazione dello schermoèabilitataavviata tramiteMediaProjection.createVirtualDisplay(),VirtualDeviceManager.createVirtualDisplay()o API proprietarie.Non deve fornire agli utenti una convenienza per disabilitare la visualizzazione futura del consenso dell'utente.
[C-SR-1] sono fortemente consigliati di visualizzare un avviso dell'utente che è esattamente lo stesso messaggio implementato in AOSP ma può essere modificato fintanto che il messaggio avverte chiaramente l'utente che vengono acquisite qualsiasi informazione sensibile sullo schermo dell'utente.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()with theandroid.app.role.COMPANION_DEVICE_APP_STREAMINGor theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMINGdevice profile.
- [C-0-2] deve visualizzare un avviso dell'utente e ottenere un consenso esplicito
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
ContentCaptureService,AugmentedAutofillService,AppSearchGlobalManager.query, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillServiceto the system. - Any screen or other data accessible via
Content CaptureAPI. - Any screen or other data accessible via
FieldClassificationServiceAPI - Any application data passed to the system via the
AppSearchManagerAPI and accessible viaAppSearchGlobalManager.query.
- Any other events that an application provides to the system via the
Content CaptureAPI or orAppSearchManagerAPI a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord,SoundTriggeror other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is condiviso. Unless such functionality is built as an Android SDK API (AmbientContext,HotwordDetectionService).[C-1-6] MUST provide user affordance to erase such data that the
ContentCaptureServiceifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephonyfeature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONYMUST contain at least the following information:-
SubscriptionManagerServicedump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. Autorizzazione .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService,WearableSensingService,VisualQueryDetector). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORDas an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANTrole. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionServiceand/orVisualQueryDetectionServiceAndroid APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::queryAPI provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATSpermission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Implementazioni del dispositivo:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Implementazioni del dispositivo:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
If device implementations have a secure lock screen and include one or more trust agent, which implements the
TrustAgentServiceSystem API, they:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of preoccupazione.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachinepackage. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. La verifica deve essere eseguita all'interno della VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the