Log delle modifiche del documento di definizione della compatibilità Android

Android 14

26 giugno 2024

2. Tipi di dispositivi

  • 2.2.1. Hardware:

    Visualizza revisione

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

    Visualizza revisione

    Crea nuovi requisiti

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

  • 2.4.1. Hardware:

    Visualizza revisione

    Crea nuovi requisiti

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

  • 2.5.1. Hardware:

    Visualizza revisione

    Crea nuovi requisiti

    Se le implementazioni dei dispositivi Auto e motori includono il supporto per Vulkan:

3. software

  • 3.2.2. Parametri build:

    Per il parametro ODM_SKU:

    Visualizza revisione

    Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare ^([0-9A-Za-z.,_-]+)$.

5. Compatibilità multimediale

  • 5.1.3. Dettagli codec audio:

    Sono stati aggiunti dettagli per il formato/codec Vorbis:

    Visualizza revisione

    Decodifica: supporto di contenuti mono, stereo, 5.0 e 5.1 con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz.
    Codifica: supporto di contenuti mono e stereo con frequenze di campionamento 8000, 12000, 160 Hz.

7. Compatibilità hardware

  • 7.1.4.2 Vulkan:

    Visualizza revisione

  • 7.7.1. Modalità periferica USB:

    Rimozione di:

    Visualizza revisione

    • NON DEVE implementare l'audio AOAv2 documentato nella documentazione del protocollo Android Open Accessory Protocol 2.0. L'audio AOAv2 è deprecato a partire dalla versione 8.0 di Android (livello API 26).

9. Compatibilità del modello di sicurezza

  • 9.7. Funzionalità di sicurezza:

    Rinumerato da [C-SR-1] a [C-SR-7] per rimuovere i contenuti duplicati e rimosso [C-SR-8]:

    Visualizza revisione

    • [C-SR-1] VIVAMENTE CONSIGLIATO per mantenere i dati kernel che vengono scritti solo durante l'inizializzazione, contrassegnati come di sola lettura dopo l'inizializzazione (ad es. __ro_after_init).

    • [C-SR-2] È VIVAMENTE CONSIGLIATO di randomizzare il layout del codice e della memoria del kernel, nonché di evitare esposizioni che comprometterebbero la randomizzazione (ad es. CONFIG_RANDOMIZE_BASE con entropia del bootloader tramite /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).

    • [C-SR-3] È VIVAMENTE CONSIGLIATO di abilitare l'integrità del flusso di controllo (CFI) nel kernel per fornire ulteriore protezione contro gli attacchi da riutilizzo del codice (ad es. CONFIG_CFI_CLANG e CONFIG_SHADOW_CALL_STACK).

    • [C-SR-4] È VIVAMENTE CONSIGLIATO di non disabilitare l'integrità del flusso di controllo (CFI), lo stack delle chiamate shadow (SCS) o la sanificazione dell'overflow intero (IntSan) sui componenti in cui è abilitata.

    • [C-SR-5] È VIVAMENTE CONSIGLIATO di abilitare CFI, SCS e IntSan per eventuali componenti aggiuntivi dello spazio utente sensibili alla sicurezza, come spiegato in CFI e IntSan.

    • [C-SR-6] È VIVAMENTE CONSIGLIATO per abilitare l'inizializzazione dello stack nel kernel per impedire l'uso di variabili locali non inizializzate (CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO). Inoltre, le implementazioni dei dispositivi NON DEVONO assumere il valore utilizzato dal compilatore per inizializzare gli utenti locali.

    • [C-SR-7] È VIVAMENTE CONSIGLIATO di abilitare l'inizializzazione dell'heap nel kernel per impedire usi di allocazioni di heap non inizializzate (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) e NON DEVONO assumere il valore utilizzato dal kernel per inizializzare queste allocazioni.

  • 9.11. Chiavi e credenziali:

    Visualizza revisione

    • [C-1-6] DEVE supportare uno dei seguenti elementi:
      • IKeymasterDevice 3.0
      • IKeymasterDevice 4.0
      • IKeymasterDevice 4.1
      • IKeyMintDevice versione 1 oppure
      • IKeyMintDevice versione 2.

  • 9.11.1. Schermata di blocco sicura, autenticazione e dispositivi virtuali:

    Visualizza revisione

    • [C-8-3] NON DEVONO esporre un'API per l'uso da parte di app di terze parti per modificare lo stato di blocco.

    Visualizza revisione

    • [C-12-4] DEVE chiamare TrustManagerService.revokeTrust()
      • Dopo un massimo di 24 ore dalla concessione della fiducia o
      • Dopo una finestra di inattività di 8 ore oppure
      • Se le implementazioni non utilizzano la sicurezza crittografica e il livello di precisione definito in [C-12-5], quando la connessione sottostante al dispositivo fisico vicino viene persa.
    • [C-12-5] Le implementazioni che si basano su una gamma sicura e accurata per soddisfare i requisiti di [C-12-4] DEVONO utilizzare una delle seguenti soluzioni:
      • Implementazioni che utilizzano la tecnologia UWB:
        • DEVE soddisfare i requisiti di conformità, certificazione, accuratezza e calibrazione per la tecnologia UWB descritti nella sezione 7.4.9.
        • DEVE utilizzare una delle modalità di sicurezza P-STS elencate in 7.4.9.
      • Implementazioni che utilizzano la rete Wi-Fi Nearby Awareness Networking (NAN):
        • DEVE soddisfare i requisiti di precisione descritti in 2.2.1 [7.4.2.5/H-SR-1], utilizzare la larghezza di banda a 160 MHz (o superiore) e seguire la procedura di configurazione della misurazione specificata in Calibrazione della presenza.
        • DEVE utilizzare LTF sicuro come definito in IEEE 802.11az.

8 aprile 2024

2. Tipi di dispositivi

  • 2.2.1. Hardware:

    Visualizza revisione

    Crea nuovi requisiti

    Se le implementazioni dei dispositivi portatili dichiarano FEATURE_BLUETOOTH_LE:

    • [7.4.3/H-1-3] DEVE misurare e compensare l'offset Rx per garantire che il RSSI BLE mediano sia -50dBm +/-15 dB a 1m 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 l'RSSI BLE media sia -50dBm +/-15 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e la trasmissione a ADVERTISE_TX_POWER_HIGH.

  • 2.2.5. Modello di sicurezza:

    Visualizza revisione

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

    • [9.8/H-1-6] NON DEVE consentire la trasmissione di più di 100 byte di dati dal servizio di rilevamento hotword su ogni risultato della hotword con successo, ad eccezione dei dati audio trasmessi attraverso HotwordAudioStream.

    Visualizza revisione

    Cambia [9.8/H-1-13] in:

    • [9.8/H-SR-3] È VIVAMENTE CONSIGLIATO di riavviare il processo che ospita il servizio di rilevamento hotword almeno una volta ogni ora o ogni 30 eventi di trigger hardware, a seconda dell'evento che si verifica per primo.

    Visualizza revisione

    Rimossi requisiti [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].

  • 2.2.7.2. Fotocamera:

    Visualizza revisione

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

    • [7.5/H-1-3] DEVE supportare la proprietà android.info.supportedHardwareLevel come FULL o migliore per la fotocamera principale posteriore e LIMITED o migliore per la fotocamera principale anteriore.

  • 2.3.2. Contenuti multimediali:

    Visualizza revisione

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

    • [5.8/T-0-1] DEVE impostare la modalità di uscita HDMI alla massima risoluzione per il formato pixel scelto compatibile con la frequenza di aggiornamento di 50 Hz o 60 Hz per il display esterno, a seconda della frequenza di aggiornamento del video per la regione in cui il dispositivo è venduto. DEVE 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.

3. software

5. Compatibilità multimediale

  • 5.3.8. Dolby Vision

    Visualizza revisione

    Se le implementazioni dei dispositivi dichiarano il supporto per il decoder Dolby Vision tramite HDR_TYPE_DOLBY_VISION, questi:

    • [C-1-3] DEVE impostare l'ID traccia dei livelli di base compatibili con le versioni precedenti (se presenti) in modo che corrisponda all'ID traccia del livello Dolby Vision combinato.

7. Compatibilità hardware

  • 7.1.1.1. Dimensioni e forma dello schermo:

    Visualizza revisione

    Se le implementazioni dei dispositivi supportano schermi in grado di configurare le dimensioni UI_MODE_TYPE_NORMAL e utilizzano display fisici con angoli arrotondati per eseguire il rendering di queste schermate, questi:

    • [C-1-1] DEVE garantire che sia soddisfatto almeno uno dei seguenti requisiti per ogni visualizzazione di questo tipo:
      • Quando una casella con 15 e 18 dp per 1518 dp è ancorata a ciascun angolo del display logico, almeno un pixel di ogni riquadro è visibile sullo schermo.

  • 7.4.3. Bluetooth

    Visualizza revisione

    Sono stati reintegrati i seguenti requisiti:

    Se le implementazioni dei dispositivi dichiarano FEATURE_BLUETOOTH_LE:

    • [C-SR-2] È VIVAMENTE CONSIGLIATO di misurare e compensare l'offset Rx per garantire che l'RSSI BLE media sia -60dBm +/-10 dB a 1 metro di distanza da un dispositivo di riferimento che trasmette a ADVERTISE_TX_POWER_HIGH, con dispositivi orientati in modo da essere su "piani paralleli" con schermi rivolti nella stessa direzione.

    • [C-SR-3] È VIVAMENTE CONSIGLIATO di misurare e compensare l'offset Tx per garantire che l'RSSI BLE media sia -60dBm +/-10 dB quando si esegue la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e la trasmissione a ADVERTISE_TX_POWER_HIGH, dove i dispositivi sono orientati in modo da essere su "piani paralleli" con schermi rivolti nella stessa direzione.

    Visualizza revisione

    Requisiti spostati da [C-10-3] e [C-10-4] a 2.2.1. Hardware.

    • [C-10-3] DEVE misurare e compensare l'offset Rx per garantire che il RSSI BLE 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 l'RSSI BLE mediano sia -55 dBm +/-10 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e la trasmissione a ADVERTISE_TX_POWER_HIGH.

20 novembre 2023

2. Tipi di dispositivi

  • 2.2.1. Hardware:

    Visualizza revisione

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

  • 2.2.7.2. Fotocamera:

    Visualizza revisione

    • [7.5/H-1-13] DEVE supportare la funzionalità LOGICAL_MULTI_CAMERA per la fotocamera posteriore principale se è presente più di una fotocamere posteriore RGB.

  • 2.3.2. Contenuti multimediali:

    Visualizza revisione

    • [5.8/T-0-1] DEVE impostare la modalità di uscita HDMI alla massima risoluzione per il formato SDR o HDR scelto che funziona con una frequenza di aggiornamento di 50 Hz o 60 Hz per il display esterno.

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

  • 2.4.5. Modello di sicurezza:

    Visualizza revisione

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

6. Compatibilità degli strumenti e delle opzioni per sviluppatori

  • 6.1. Strumenti per sviluppatori:

    Visualizza revisione

    • [C-0-12] DEVE scrivere un Atom LMK_KILL_OCCURRED_FIELD_NUMBER nella

    Visualizza revisione

    • [C-0-13] DEVE implementare il comando shell dumpsys gpu --gpuwork per visualizzare

9. Compatibilità del modello di sicurezza

  • 9.7. Funzionalità di sicurezza:

    Visualizza revisione

    Se le implementazioni del dispositivo utilizzano un kernel Linux in grado di supportare SELinux, questi:

    Visualizza revisione

    Se le implementazioni dei dispositivi utilizzano un kernel diverso da Linux o Linux senza SELinux:

4 ottobre 2023

2. Tipi di dispositivi

  • 2.2. Requisiti per gli smartphone:

    Visualizza revisione

    Le implementazioni dei dispositivi Android vengono classificate come dispositivi portatili se soddisfano tutti i seguenti criteri:

    • Avere una dimensione dello schermo in diagonale fisica compresa tra 4 pollici da 3,3 pollici (o 2,5 pollici per le implementazioni di dispositivi fornite con livello API 29 o precedenti) a 8 pollici.

    Crea nuovi requisiti

    • Disporre di un'interfaccia di immissione touchscreen.

  • 2.2.1. Hardware:

    Visualizza 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 con misure di almeno 2,2" sul lato corto e 3,4" su quello lungo.

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

    • [7.1.1.1/H-1-1]* DEVE rendere lo schermo logico reso disponibile per le applicazioni di terze parti di almeno 50 mm sul bordo corto e 72 mm sul bordo lungo. I dispositivi con livello API Android 29 o precedente con livello API Android 29 o precedente POTREBBERO 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 rendere lo schermo logico reso disponibile per le applicazioni di terze parti di almeno 7,1 cm sul bordo corto. I dispositivi con livello API Android 29 o precedente con livello API Android 29 o precedente POTREBBERO essere esentati da questo requisito.

    Crea nuovi requisiti

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

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

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

    • [5.6/H-1-1] DEVE avere una latenza media di andata e ritorno continua di 300 millisecondi o inferiore a 5 misurazioni, con deviazione media assoluta inferiore a 30 ms, sui seguenti percorsi dati: "da altoparlante a microfono", adattatore di loopback da 3,5 mm (se supportato), loopback USB (se supportato).

    • [5.6/H-1-2] DEVE avere una latenza media tocco per toni di 300 millisecondi o meno su almeno 5 misurazioni sul percorso dati da speaker a microfono.

    Se le implementazioni dei dispositivi portatili includono almeno un attuatore aptico:

    Se le implementazioni dei dispositivi portatili includono almeno un attuatore lineare risonante 7.10 per uso generico:

    • [7.10/H] DEVE posizionare l'attuatore vicino al punto in cui il dispositivo viene solitamente tenuto o toccato con le mani.

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

    Se le implementazioni dei dispositivi portatili hanno un attuatore aptico per uso generico , che è un attuatore a risonanza lineare (LRA) sull'asse X:

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

  • 2.2.2. Contenuti multimediali:

    Visualizza revisione

    Le implementazioni dei dispositivi portatili DEVONO supportare i seguenti formati di codifica video e renderli disponibili ad 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 ad applicazioni di terze parti:

    • [5.3/H-0-6] AV1

  • 2.2.3. chiusi:

    Visualizza revisione

    Se le implementazioni dei dispositivi, incluso il tasto di navigazione recente della funzione, come descritto in dettaglio nella sezione 7.2.3, modificano l'interfaccia:

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

    Se le implementazioni dei dispositivi portatili includono il supporto per le API ControlsProviderService e Control e consentono ad applicazioni di terze parti di pubblicare controlli dei dispositivi, questi:

    • [3.8.16/H-1-6] Le implementazioni dei dispositivi DEVONO mostrare con precisione l'invito all'utente come segue:
      • Se il dispositivo ha impostato config_supportsMultiWindow=true e l'app dichiara i metadati META_DATA_PANEL_ACTIVITY nella dichiarazione ControlsProviderService, incluso il valore ComponentName di un'attività valida (come definita dall'API), l'app DEVE incorporare detta attività in questa offerta utente.
      • Se l'app non dichiara metadati META_DATA_PANEL_ACTIVITY, DEVE visualizzare i campi specificati come forniti dall'API ControlsProviderService così come eventuali campi specificati forniti dalle API Controllo.
    • [3.8.16/H-1-7] Se l'app dichiara i metadati META_DATA_PANEL_ACTIVITY, DEVE passare il valore dell'impostazione definita in [3.8.16/H-1-5] utilizzando EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS quando si avvia l'attività incorporata.

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

  • 2.2.4. Prestazioni e potenza:

    Visualizza revisione

    Implementazioni di dispositivi portatili:

    • [8.5/H-0-1] DEVE fornire l'affdenza dell'utente nel menu Impostazioni per visualizzare tutte le app con servizi in primo piano attivi o i job 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'app che esegue un job in primo piano avviato dall'utente.
      • Alcune app POTREBBERO essere esentate dall'interruzione o dall'elenco in un invito all'utente come descritto nel documento SDK.

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

  • 2.2.5. Modello di sicurezza:

    Visualizza revisione

    Se le implementazioni dei dispositivi dichiarano il supporto per android.hardware.telephony:

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

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

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

    Se le implementazioni dei dispositivi portatili sono impostate su UserManager.isHeadlessSystemUserMode su true,

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

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

    • [9.8/H-1-1] DEVE assicurarsi che il servizio di rilevamento hotword possa trasmettere dati soltanto al sistema, ContentCaptureService, o al servizio di riconoscimento vocale sul dispositivo creato da SpeechRecognizer#createOnDeviceSpeechRecognizer().
    • [9.8/H-1-6] NON DEVE consentire la trasmissione di più di 100 byte di dati (esclusi i flussi audio) dal servizio di rilevamento della hotword per ogni risultato della hotword con successo.

    • [9.8/H-1-15] DEVE garantire che gli stream audio forniti con risultati hotword successivi siano trasmessi in modo unidirezionale 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 della hotword senza indicazioni sull'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 (completamente o parzialmente) l'audio o contenuti audio non correlati alla hotword stessa, ad eccezione del ContentCaptureService o del 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 fotocamera, possono:

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

  • 2.2.7.1. Contenuti multimediali:

    Visualizza revisione

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

    Crea nuovi requisiti

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

    • [5.1/H-1-1] DEVE pubblicizzare il numero massimo di sessioni di decoder video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-2] DEVE supportare 6 istanze di sessioni di decodifica video hardware a 8 bit (SDR) (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 3 sessioni a risoluzione 1080p a 30 fps e 3 sessioni a 4K di risoluzione a 30 fps, a meno che non sia AV1. I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30 f/s.
    • [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() e VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-4] DEVE supportare 6 istanze di sessioni del codificatore video hardware a 8 bit (SDR) (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 4 sessioni a risoluzione 1080p a 30 f/s e 2 sessioni a 4K di risoluzione a 30 fps, a meno che I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30 f/s.
    • [5.1/H-1-5] DEVE pubblicizzare il numero massimo di sessioni di codifica e decodifica video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-6] DEVE supportare 6 istanze di sessioni di decodificatore video hardware a 8 bit (SDR) e di codificatore video hardware (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 3 sessioni a risoluzione 4K a 30 f/s (tranne AV1), di cui al massimo 2 sessioni encoder e 1 sessione encoder. I codec AV1 devono supportare solo la risoluzione 1080p, ma devono comunque supportare 6 istanze a 1080p30 f/s.
    • [5.1/H-1-19] DEVE supportare 3 istanze del decodificatore video hardware a 10 bit (HDR) e sessioni del codificatore video hardware (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a una risoluzione di 4K a 30 f/s (a meno che AV1) di cui al massimo una sessione encoder configurata per un input AV1 La generazione di metadati HDR da parte dell'encoder non è necessaria se la codifica dalla superficie GL. Le sessioni codec AV1 sono necessarie solo per supportare la risoluzione a 1080p anche se questo requisito prevede la risoluzione 4K.
    • [5.1/H-1-7] DEVE avere una latenza di inizializzazione del codec di 40 ms o inferiore per una sessione di codifica video a 1080p o inferiore per tutti i codificatori video hardware sotto carico. "Carica qui" è una sessione simultanea di transcodifica solo video da 1080p a 720p che utilizza codec video hardware insieme all'inizializzazione della registrazione audio-video a 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 di 30 ms o inferiore per una sessione di codifica audio con velocità in bit a 128 Kbps o inferiore per tutti i codificatori audio sotto carico. "Carica qui" è una sessione simultanea di transcodifica solo video da 1080p a 720p che utilizza codec video hardware insieme all'inizializzazione della registrazione audio-video a 1080p.
    • [5.1/H-1-9] DEVE supportare 2 istanze di sessioni di decodifica video hardware sicure (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a risoluzione 4K a 30 fps (a meno che AV1) per contenuti HDR a 8 bit (SDR) e HDR a 10 bit. Le sessioni codec AV1 sono necessarie solo per supportare la risoluzione a 1080p anche se questo requisito prevede la risoluzione 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 decodifica video hardware sicura (4 istanze in totale) (AVC, HEVC, VP9, AV1 o versioni successive) in qualsiasi combinazione di codec in esecuzione contemporaneamente a 3 sessioni a risoluzione 4K a 0 f/s a 0 f/s e una sessione pn 0 f/s a 0 f/s a risoluzione sicura a 0 f/s a 0 f/s a 30 fps con risoluzione AV1 sicura Le sessioni codec AV1 sono necessarie solo per supportare la risoluzione a 1080p anche se questo requisito prevede la risoluzione 4K.
    • [5.1/H-1-11] DEVE supportare un decodificatore 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 di 40 ms o inferiore per una sessione di decodifica video a 1080p o inferiore per tutti i decoder video hardware quando sotto carico. Per caricamento qui si intende una sessione di transcodifica simultanea da 1080p a 720p solo video che utilizza codec video hardware insieme all'inizializzazione della riproduzione audio-video a 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 di 30 ms o inferiore per una sessione di decodifica audio con velocità in bit inferiore o di 128 kbps per tutti i decoder audio quando sotto carico. "Carica qui" è una sessione simultanea di transcodifica solo video da 1080p a 720p che utilizza codec video hardware insieme all'inizializzazione della riproduzione audio-video a 1080p.
    • [5.1/H-1-14] DEVE supportare il decodificatore hardware AV1, Main 10, Livello 4.1 e grana della pellicola.
    • [5.1/H-1-15] DEVE avere almeno 1 decodificatore video hardware che supporti 4K60.
    • [5.1/H-1-16] DEVE avere almeno un codificatore video hardware che supporta 4K60.
    • [5.3/H-1-1] NON DEVE perdere più di 1 fotogramma in 10 secondi (ovvero meno dello 0,167% di riduzione dei fotogrammi) per una sessione video 4K a 60 f/s 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 f/s sotto carico per una sessione in 4K.
    • [5.6/H-1-1] DEVE avere una latenza tocco-to-tono di 80 millisecondi o inferiore utilizzando il test del tocco per tono 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 un audio >=24 bit per l'uscita stereo su jack audio da 3,5 mm, se presente, e tramite audio USB, se supportato attraverso l'intero percorso dati per configurazioni a bassa latenza e streaming. Per la configurazione a bassa latenza, l'app deve utilizzare AAudio in modalità di callback a bassa latenza. Per la configurazione dello streaming, l'app deve utilizzare Java AudioTrack. Nelle configurazioni a bassa latenza e in streaming, il sink di output dell'HAL deve accettare AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT o AUDIO_FORMAT_PCM_FLOAT come formato di output di destinazione.
    • [5.6/H-1-4] DEVE supportare dispositivi audio USB >=4 canali (utilizzati dai controller DJ per l'anteprima dei brani).
    • [5.6/H-1-5] DEVE supportare dispositivi MIDI conformi alla classe e dichiarare il flag della funzionalità MIDI.
    • [5.6/H-1-9] DEVE supportare almeno il missaggio a 12 canali. Ciò implica la possibilità di aprire un'AudioTrack con maschera a 7.1.4 canali e di suddividere correttamente tutti i canali in stereo o di eseguirne il downmix.
    • [5.6/H-SR] È VIVAMENTE CONSIGLIATO di supportare il mix a 24 canali e almeno il supporto per le maschere 9.1.6 e 22.2.
    • [5.7/H-1-2] DEVE supportare MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL con le seguenti funzionalità di decrittografia dei contenuti.
    Dimensione minima del campione 4 MiB
    Numero minimo di sottocampioni: H264 o HEVC 28
    Numero minimo di sottocampioni - VP9 9
    Numero minimo di sottocampioni - AV1 288
    Dimensione minima del buffer del sottocampione 1 MiB
    Dimensione minima del buffer di crittografia generico 500 KiB
    Numero minimo di sessioni simultanee 30
    Numero minimo di chiavi per sessione 20
    Numero totale minimo di chiavi (tutte le sessioni) 80
    Numero totale minimo di chiavi DRM (tutte le sessioni) 6
    Dimensione messaggio 16 KiB
    Frame decriptati al secondo 60 f/s
    • [5.1/H-1-17] DEVE avere almeno un decodificatore di immagini hardware che supporti il profilo di base AVIF.
    • [5.1/H-1-18] DEVE supportare il codificatore AV1 in grado di codificare fino a una risoluzione di 480p a 30 fps e 1 Mbps.
    • [5.12/H-1-1] DEVE [5.12/H-SR] È vivamente consigliato supportare la funzionalità Feature_HdrEditing per tutti i codificatori hardware AV1 e HEVC presenti sul dispositivo.
    • [5.12/H-1-2] DEVE supportare il formato colore RGBA_1010102 per tutti i codificatori 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] DEVONO avere almeno sei overlay hardware nell'HWC (Data Processing Unit) dell'unità di elaborazione dei dati (DPU), con almeno 2 di questi in grado di visualizzare contenuti 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 AVC o HEVC hardware:

    • [5.2/H-2-1] DEVE soddisfare il target di qualità minimo definito dalle curve di distorsione della velocità del codificatore video per i codec AVC e HEVC hardware, come definito nella prossima documentazione.

  • 2.2.7.2. Fotocamera:

    Visualizza revisione

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

    • [7.5/H-1-1] DEVE avere una fotocamera posteriore principale con una risoluzione di almeno 12 megapixel che supporti l'acquisizione video a 4K a 30 f/s. La fotocamera posteriore principale è quella posteriore con l'ID fotocamera più basso.
    • [7.5/H-1-2] DEVE avere una fotocamera anteriore principale con una risoluzione di almeno 6 megapixel e supportare l'acquisizione video a 1080p a 30 f/s. La fotocamera anteriore principale è quella anteriore con l'ID fotocamera più basso.
    • [7.5/H-1-3] DEVE supportare la proprietà android.info.supportedHardwareLevel come COMPLETA o migliore per entrambe le fotocamere principali.
    • [7.5/H-1-4] DEVE supportare CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME per entrambe le fotocamere principali.
    • [7.5/H-1-5] DEVE avere una latenza di acquisizione JPEG della fotocamera2 < 1000 900 ms per una risoluzione a 1080p, misurata dal PerformanceTest della fotocamera CTS in condizioni di illuminazione ITS (3000K) per entrambe le videocamere principali.
    • [7.5/H-1-6] DEVE avere una latenza di avvio di camera2 (apertura della fotocamera al primo frame di anteprima) < 500 ms, misurata dal PerformanceTest della fotocamera CTS in condizioni di illuminazione ITS (3000K) per entrambe le fotocamere principali.
    • [7.5/H-1-8] DEVE supportare CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW e android.graphics.ImageFormat.RAW_SENSOR per la fotocamera posteriore principale.
    • [7.5/H-1-9] DEVE avere una fotocamera principale posteriore che supporta 720p o 1080p a 240 f/s.
    • [7.5/H-1-10] DEVE avere uno ZOOM_RATIO minimo < 1,0 per le fotocamere principali se è presente una videocamera RGB ultrawide rivolta nella stessa direzione.
    • [7.5/H-1-11] DEVE implementare lo streaming front-back simultaneo sulle videocamere principali.
    • [7.5/H-1-12] DEVE supportare CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION sia per la fotocamera anteriore principale che per quella posteriore principale.
    • [7.5/H-1-13] DEVE supportare la funzionalità LOGICAL_MULTI_CAMERA per le fotocamere principali se ci sono più di 1 videocamera RGB rivolte nella stessa direzione.
    • [7.5/H-1-14] DEVE supportare la funzionalità STREAM_USE_CASE sia per la fotocamera anteriore che per quella posteriore principale.
    • [7.5/H-1-15] DEVE supportare Bokeh e le estensioni per la modalità notturna tramite le estensioni CameraX e Camera2 per le fotocamere principali.
    • [7.5/H-1-16] DEVE supportare la funzionalità DYNAMIC_RANGE_TEN_BIT per le fotocamere principali.
    • [7.5/H-1-17] DEVE supportare CONTROL_SCENE_MODE_FACE_PRIORITY e il rilevamento dei volti (STATISTICS_FACE_DETECT_MODE_SIMPLE o STATISTICS_FACE_DETECT_MODE_FULL) per le videocamere principali.

  • 2.2.7.3. Hardware:

    Visualizza revisione

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

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

  • 2.2.7.4. Rendimento:

    Visualizza revisione

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

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

  • 2.3.2. Contenuti multimediali:

    Visualizza revisione

    Le implementazioni dei dispositivi televisivi DEVONO supportare i seguenti formati di codifica video e renderli disponibili ad 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:

  • 2.4.5. Modello di sicurezza:

    Visualizza revisione

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

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

  • 2.5.1. Hardware:

    Visualizza revisione

    Se le implementazioni dei dispositivi includono il supporto per le trasmissioni radio AM/FM ed espongono la funzionalità a qualsiasi applicazione, questi:

    • [7.4.10/A-0-1] DEVE dichiarare il supporto per FEATURE_BROADCAST_RADIO.

    Una videocamera per esterni è una videocamera che riproduce scene al di fuori dell'implementazione del dispositivo, come la fotocamera di retrovisione.

    Implementazioni di dispositivi nel settore auto e motori:

    • DEVE includere una o più videocamere per la vista esterna.

    Se le implementazioni dei dispositivi nel settore auto e motori includono una videocamera per esterni, per una fotocamera di questo tipo:

    • [7.5/A-1-1] NON DEVONO avere le fotocamere per esterni accessibili tramite le API Android Camera, a meno che non rispettino i requisiti principali della fotocamera.
    • [7.5/A-SR-1] CONSIGLIATO VIVAMENTE di non ruotare o eseguire il mirroring orizzontalmente dell'anteprima della fotocamera.
    • [7.5/A-SR-2] È VIVAMENTE CONSIGLIATO avere una risoluzione di almeno 1,3 megapixel.
    • DEVONO avere hardware a fuoco fisso o EDOF (profondità di campo estesa).
    • È possibile che nel driver della fotocamera sia implementata la messa a fuoco automatica hardware o software.

    Se le implementazioni dei dispositivi per auto e motori includono una o più telecamere di visione esterna e caricano il servizio Exterior View System (EVS), per una videocamera di questo tipo:

    • [7.5/A-2-1] NON DEVE ruotare o rispecchiare orizzontalmente l'anteprima della fotocamera.

    Implementazioni di dispositivi nel settore auto e motori:

    • POTREBBERO includere una o più videocamere disponibili per applicazioni di terze parti.

    Se le implementazioni dei dispositivi per auto e motori includono almeno una fotocamera e la rendono disponibile ad applicazioni di terze parti, questi:

    • [7.5/A-3-1] DEVE segnalare il flag funzionalità android.hardware.camera.any.
    • [7.5/A-3-2] Non DEVE dichiarare la fotocamera come fotocamera di sistema.
    • POTREBBERO supportare fotocamere esterne descritte nella sezione 7.5.3.
    • POTREBBERO includere funzionalità (come la messa a fuoco automatica ecc.) disponibili per le fotocamere posteriori come descritto nella sezione 7.5.1.

    Per fotocamera posteriore si intende una videocamera rivolta verso il mondo che può essere collocata in qualsiasi punto del veicolo e rivolta verso l'esterno dell'abitacolo, ovvero immagini scene all'estremità della carrozzeria del veicolo, come la telecamera di retrovisione.

    Per fotocamera anteriore si intende una fotocamera rivolta all'utente che può essere collocata in qualsiasi punto del veicolo ed è rivolta all'interno dell'abitacolo, ovvero immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.

    Implementazioni di dispositivi nel settore auto e motori:

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

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

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

    Se le implementazioni dei dispositivi per auto e motori includono almeno una fotocamera rivolta all'utente, per una fotocamera di questo tipo:

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

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

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

    Se le implementazioni dei dispositivi per auto e motori includono una fotocamera non accessibile tramite l'API android.hardware.Camera o android.hardware.camera2, questi elementi:

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

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

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

    Se le implementazioni dei dispositivi per auto e motori includono una o più fotocamere accessibili tramite il servizio Extended View System e l'API android.hardware.Camera o android.hardware.Camera2, per una fotocamera di questo tipo:

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

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

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

  • 2.5.3. chiusi:

    Visualizza revisione

    Implementazioni di dispositivi nel settore auto e motori:

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

  • 2.5.5. Modello di sicurezza:

    Visualizza revisione

    Se le implementazioni dei dispositivi per auto e motori dichiarano android.hardware.microphone, :

    • [9.8.2/A-1-1] DEVE visualizzare l'indicatore del microfono quando un'app accede ai dati audio dal microfono, ma non quando il microfono è accessibile solo da HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o dalle app che hanno i ruoli descritti 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 con interfacce utente visibili o interazione diretta dell'utente.
    • [9.8.2/A-1-3] DEVE fornire all'utente l'autorizzazione ad attivare il microfono nell'app Impostazioni.

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

    • [9.8.2/A-2-1] DEVE visualizzare l'indicatore della videocamera quando un'app accede ai dati della videocamera in diretta, ma non quando la videocamera viene accessibile solo da app che hanno i ruoli definiti descritti nella Sezione 9.1 Autorizzazioni con identificatore CDD [C-4-X][C-3-X].

    • [9.8.2/A-2-3] DEVE fornire all'utente l'autorizzazione ad attivare/disattivare la fotocamera nell'app Impostazioni.
    • [9.8.2/A-2-4] DEVONO visualizzare le app recenti e attive che utilizzano la fotocamera come restituiti da PermissionManager.getIndicatorAppOpUsageData(), insieme a eventuali messaggi di attribuzione associati.

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

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

3. software

  • 3.1. Compatibilità delle API gestite:

    Visualizza revisione

    Implementazioni dei dispositivi:

    • [C-0-8] NON DEVE supportare l'installazione di applicazioni che hanno come target un livello API inferiore a 23.

  • 3.2.3.5. Application Intent condizionali:

    Visualizza revisione

    Se le implementazioni dei dispositivi registrano android.hardware.nfc.uicc o android.hardware.nfc.ese, questi:

  • 3.3.1. Interfacce binarie dell'applicazione:

    Visualizza revisione

    Implementazioni dei dispositivi:

    • [C-0-12] DEVE esportare i simboli di funzione per i simboli principali della funzione Vulkan 1.0 Vulkan 1.1, nonché per le estensioni VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 tramite la libreria libvulkan.so. Tieni presente che, anche se DEVONO essere presenti tutti i simboli, la sezione 7.1.4.2 descrive in modo più dettagliato i requisiti relativi a quando è prevista la completa implementazione di ciascuna funzione corrispondente.

  • 3.8.6. Temi:

    Visualizza revisione

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

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

  • 3.8.8. Cambio di attività:

    Visualizza revisione

    Se le implementazioni dei dispositivi, incluso il tasto di navigazione recente della funzione, come descritto nella sezione 7.2.3, modificano l'interfaccia:

  • 3.9.2 Supporto dei profili gestiti:

    Visualizza revisione

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

    • [C-1-10] DEVE garantire che i dati degli screenshot vengano salvati nello spazio di archiviazione del profilo di lavoro quando viene acquisito uno screenshot con una finestra topActivity con stato attivo (quella con cui l'utente ha interagito per ultimo tra tutte le attività) e che appartenga a un'app del profilo di lavoro.
    • [C-1-11] NON DEVE acquisire altri contenuti dello schermo (barra di sistema, notifiche o contenuti del profilo personale), ad eccezione della finestra/finestre dell'applicazione del profilo di lavoro durante il salvataggio di uno screenshot nel profilo di lavoro (per garantire che i dati del profilo personale non vengano salvati nel profilo di lavoro).

  • 3.9.5 Framework per la risoluzione dei criteri relativi ai dispositivi: nuova sezione

    Visualizza revisione

    Se le implementazioni dei dispositivi registrano android.software.device_admin o android.software.managed_users, questi:

    • [C-1-1] DEVE risolvere i conflitti dei criteri dei dispositivi come documentato nella documentazione AOSP.

5. Compatibilità multimediale

  • 5.1.4. Codifica delle immagini:

    Visualizza revisione

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

    • [C-0-4] AVIF
      • I dispositivi devono supportare BITRATE_MODE_CQ e Baseline Profile.

  • 5.1.5. Decodifica dell'immagine:

    Visualizza revisione

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

    [C-0-7] AVIF (Profilo Baseline)

  • 5.1.6. Dettagli codec immagine:

    Visualizza revisione

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

  • 5.1.8. Elenco codec video:

    Visualizza revisione

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

  • 5.1.10. Caratterizzazione del codec multimediale:

    Visualizza revisione

    Se le implementazioni dei dispositivi supportano i codec video:

    • [C-2-1] Tutti i codec video DEVONO pubblicare dati sulla frequenza fotogrammi raggiungibili per le seguenti dimensioni, se supportati dal codec:
    SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p UHD
    Risoluzione video
    • 176 x 144 px (H263, MPEG2, MPEG4)
    • 352 x 288 px (encoder MPEG4, H263, MPEG2)
    • 320 x 180 px (VP8, VP8)
    • 320 x 240 px (altro)
    • 704 x 576 px (H263)
    • 640 x 360 px (VP8, VP9)
    • 640 x 480 px (codificatore MPEG4)
    • 720 x 480 px (altro, AV1)
    • 1408 x 1152 px (H263)
    • 1280 x 720 px (altro, AV1)
    		 1920 x 1080 px (diverso da MPEG4, AV1) 3840 x 2160 px (HEVC, VP9, AV1)

  • 5.2. Codifica video:

    Visualizza revisione

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

    • NON DEVE essere, su due finestre scorrevoli, superiore al 15% della velocità in bit tra gli intervalli intraframe (I-frame).
    • NON DEVE superare il 100% della velocità in bit in una finestra scorrevole di 1 secondo.

    Se le implementazioni dei dispositivi supportano qualsiasi codificatore video e lo rendono disponibile per app di terze parti e imposta
    MediaFormat.KEY_BITRATE_MODE su BITRATE_MODE_VBR in modo che il codificatore funzioni in modalità a velocità in bit variabile, se questo non influisce sulla qualità minima la velocità in bit codificata :

    • [C-5-1] DEVE NON DEVE essere, oltre una finestra scorrevole, di oltre il 15% rispetto alla velocità in bit tra gli intervalli di intraframe (I-frame).
    • [C-5-2] DEVE NON superare il 100% della velocità in bit su una finestra scorrevole di 1 secondo.

    Se le implementazioni dei dispositivi supportano qualsiasi codificatore video e lo rendono disponibile per app di terze parti e impostano MediaFormat.KEY_BITRATE_MODE su BITRATE_MODE_CBR in modo che il codificatore funzioni in modalità con velocità in bit costante, la velocità in bit codificata:

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

  • 5.2.1. H.263:

    Visualizza revisione

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

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

  • 5.2.5. H.265:

    Visualizza revisione

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

    • [C-1-1] DEVE supportare il livello 3 del profilo principale fino alla risoluzione 512 x 512.
    • DEVE supportare i profili di codifica HD come indicato nella seguente tabella.
    • I [C-SR-1] sono VIVAMENTE CONSIGLIATI per supportare il profilo SD 720 x 480 e i profili di codifica HD, come indicato nella tabella seguente, se è presente un codificatore hardware.

  • 5.2.6. AV1: nuova sezione

    Visualizza revisione

    Se le implementazioni dei dispositivi supportano il codec AV1:

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

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

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

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

    • [C-2-1] DEVE supportare fino al profilo di codifica HD1080p incluso nella tabella seguente:
    SD HD 720p HD 1080p UHD
    Risoluzione video 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
    Frequenza fotogrammi video 30 fps 30 fps 30 fps 30 fps
    Velocità in bit video 5 Mbps 8 Mbps 16 Mbps 50 Mbit/s

  • 5.3.2. H.263:

    Visualizza revisione

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

    • [C-1-1] DEVE supportare il livello di profilo di base 30 (risoluzioni CIF, QCIF e SQCIF a 30 f/s 384 kbps) e livello 45 (risoluzioni QCIF e SQCIF a 30 f/s 128 kbps).

  • 5.3.9. AV1:

    Visualizza revisione

    Se le implementazioni dei dispositivi supportano il codec AV1:

    • [C-1-1] DEVE supportare il profilo 0 incluso il contenuto a 10 bit.

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

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

    Se le implementazioni dei dispositivi forniscono supporto per il codec AV1 con un decoder con accelerazione hardware:

    • [C-2-1] DEVE essere in grado di decodificare almeno i profili di decodifica video HD a 720p dalla tabella seguente quando l'altezza riportata dal metodo Display.getSupportedModes() è uguale o superiore a 720p.
    • [C-2-2] DEVE essere in grado di decodificare almeno i profili di decodifica video HD a 1080p dalla tabella seguente quando l'altezza riportata dal metodo Display.getSupportedModes() è uguale o superiore a 1080p.
    SD HD 720p HD 1080p UHD
    Risoluzione video 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
    Frequenza fotogrammi video 30 fps 30 fps 30 fps 30 fps
    Velocità in bit video 5 Mbps 8 Mbps 16 Mbps 50 Mbit/s

    Se le implementazioni del dispositivo supportano il profilo HDR tramite le API Media, l'implementazione di questi dispositivi:

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

  • 5.4.2. Acquisizione per il riconoscimento vocale:

    Visualizza revisione

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

    • DOVREBBE impostare la sensibilità dell'ingresso audio in modo che una sorgente di tono sinusoidale a 1000 Hz venga riprodotta a 90 dB di livello di pressione sonora (SPL) (misurata a una distanza di 30 cm accanto al microfono) restituisce una risposta ideale di RMS 2500 per ciascun

  • 5.5.2. Effetti audio:

    Visualizza revisione

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

    • [C-1-4] DEVE supportare gli effetti audio con input e output floating.
    • [C-1-5] DEVE assicurarsi che gli effetti audio supportino più canali fino al numero di canali del mixer, noto anche come FCC_LIMIT.

  • 5.6. Latenza audio:

    Visualizza revisione

    Se le implementazioni dei dispositivi dichiarano android.hardware.audio.output, È VIVAMENTE CONSIGLIATO di soddisfare o superare i seguenti requisiti:

    • [C-SR-4] Il timestamp di output restituito da AudioTrack.getTimestamp e AAudioStream_getTimestamp è preciso con un valore di +/- 1 ms.

    • [C-SR-4] Le latenze di andata e ritorno calcolate in base ai timestamp di input e output restituiti da AAudioStream_getTimestamp sono VIVAMENTE CONSIGLIATE di non superare i 30 msec della latenza di andata e ritorno misurata per AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY per speaker, cuffie con cavo e wireless.

7. Compatibilità hardware

  • 7.1. Display e grafica:

    Visualizza revisione

    Android include funzionalità che regolano automaticamente gli asset delle applicazioni e i layout dell'interfaccia utente in modo appropriato per il dispositivo per garantire che le applicazioni di terze parti funzionino correttamente su serie di configurazioni hardware. serie di display e configurazioni hardware. Un display compatibile con Android è uno schermo che implementa tutti i comportamenti e le API descritti in Android Developers - Panoramica sulla compatibilità dello schermo, in questa sezione (7.1) e nelle relative sottosezioni, nonché in qualsiasi altro comportamento specifico per tipo di dispositivo documentato nella sezione 2 di questo CDD. Sui display compatibili con Android in cui possono essere eseguite tutte le applicazioni di terze parti compatibili con Android, le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in dettaglio in questa sezione.

    Crea nuovi requisiti

    Implementazioni dei dispositivi:

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

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

    • dimensione diagonale fisica. La distanza in pollici tra due angoli contrapposti della parte illuminata del display.
    • densità dei punti per pollice (dpi). Il numero di pixel inclusi in un'area lineare orizzontale o verticale di 1", espresso in pixel per pollice (ppi o dpi). Quando sono elencati i valori dpi ppi e dpi, i dpi orizzontali e verticali devono rientrare nell'intervallo elencato.
    • proporzioni. Il rapporto tra i pixel della dimensione più lunga e la dimensione più breve dello schermo. Ad esempio, un display di 480 x 854 pixel corrisponde a 854/480 = 1,779, ovvero a "16:9".
    • pixel indipendenti dalla densità (dp). L' unità pixel virtuale normalizzata per uno schermo da 160 dpi con una densità dello schermo pari a 160. Per alcuni valori di densità d e numero di pixel p, il numero di pixel indipendenti dalla densità dp viene calcolato come segue: pixel = dps * (density/160) dp = (160 / d) * p .

  • 7.1.1.1. Dimensioni e forma dello schermo:

    Visualizza revisione

    Se le implementazioni dei dispositivi supportano schermi che supportano la UI_MODE_TYPE_NORMAL configurazione delle dimensioni e includono schermi compatibili con Android utilizzano display fisici con gli angoli arrotondati per il rendering di questi schermi, che:

    • [C-1-1] DEVE garantire che sia soddisfatto almeno uno dei seguenti requisiti per ogni display di questo tipo:
    • Il raggio degli angoli arrotondati è inferiore o uguale a 38 dp.

    • Quando un riquadro di 15 x 15 dp è ancorato in ogni angolo del display logico, almeno un pixel di ciascun riquadro è visibile sullo schermo.

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

    Crea nuovi requisiti

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

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

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

    Se le implementazioni dei dispositivi includono uno o più display compatibili con Android pieghevoli o che includono una cerniera pieghevole tra più pannelli display e se la cerniera o la piegatura attraversa una finestra dell'applicazione a schermo intero, questi:

    • [C-3-1] DEVE segnalare la posizione, i limiti e lo stato della cerniera o di piegare le estensioni o le API collaterali all'applicazione.

    Se le implementazioni dei dispositivi includono una o più aree pieghevoli compatibili con Android o includono una cerniera pieghevole tra più aree di pannelli compatibili con Android e le mettono a disposizione delle applicazioni, queste:

    • [C-4-1] DEVE implementare la versione corretta del livello API Window Manager Extensions, come descritto nella prossima documentazione.

  • 7.1.1.2. Proporzioni dello schermo: rimosse

  • 7.1.1.3. Densità schermo:

    Visualizza revisione

    Implementazioni dei dispositivi:

    • [C-0-1] Per impostazione predefinita, le implementazioni dei dispositivi DEVONO segnalare solo una delle densità del framework Android elencate DisplayMetrics tramite l'DENSITY_DEVICE_STABLEAPI e questo valore deve essere un valore statico per ogni display fisico NON DEVE essere modificato in qualsiasi momento; tuttavia, comunque, la configurazione iniziale del dispositivo è diversa.DisplayMetrics.density

    • Le implementazioni dei dispositivi DEVONO definire la densità del framework Android standard numericamente più vicina alla densità fisica dello schermo, a meno che questa densità logica non spinga le dimensioni dello schermo riportate al di sotto del minimo supportato. Se la densità del framework Android standard numericamente più vicina alla densità fisica risulta in una dimensione dello schermo inferiore a quella minima supportata (larghezza di 320 dp), le implementazioni dei dispositivi DEVONO segnalare la densità successiva del framework Android standard più basso.

    Crea nuovi requisiti

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

    Se le implementazioni dei dispositivi forniscono esiste un'autorizzazione per modificare le dimensioni di visualizzazione del dispositivo, :

    • [C-1-1] Le dimensioni del display NON DEVONO essere ridimensionate NON DEVONO scalare il display oltre 1,5 volte la densità nativa della DENSITY_DEVICE_STABLE o produrre una dimensione minima effettiva dello schermo inferiore a 320 dp (equivalente al qualificatore risorsa sw320dp), a seconda dell'evento che si verifica per primo.
    • [C-1-2] Le dimensioni del display NON DEVONO essere ridimensionate NON DEVE scalare il display inferiore a 0,85 volte la densità nativa di DENSITY_DEVICE_STABLE.

  • 7.1.4.2 Vulkan:

    Visualizza revisione

    Se le implementazioni dei dispositivi includono il supporto per Vulkan 1.0 o versioni successive, questi:

    • [C-1-3] DEVE implementare completamente le API Vulkan 1.0 Vulkan 1.1 per ogni API enumerata VkPhysicalDevice.

    • [C-1-5] NON DEVE enumerare i livelli forniti dalle librerie al di fuori del pacchetto dell'applicazione, né fornire altri modi per tracciare o intercettare l'API Vulkan, a meno che l'applicazione non abbia l'attributo android:debuggable impostato su true o i metadati com.android.graphics.injectLayers.enable impostati su true .

    • DOVREBBE supportare VkPhysicalDeviceProtectedMemoryFeatures e VK_EXT_global_priority.

    • [C-SR-5] È VIVAMENTE CONSIGLIATO di supportare VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory e VK_EXT_global_priority.

    • [C-SR-6] Ti consigliamo VIVAMENTE di usare SkiaVk con HWUI.

    Se le implementazioni dei dispositivi includono il supporto per Vulkan 1.1 e dichiarano uno qualsiasi dei flag delle funzionalità di Vulkan descritti qui , questi:

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

  • 7.3.10. Sensori biometrici:

    Visualizza revisione

    Se le implementazioni dei dispositivi hanno più sensori biometrici, questi:

    • [C-7-1] DEVE, quando un dato biometrico è in blocco (ovvero la biometria è disabilitata fino a quando l'utente non si sblocca con l'autenticazione principale) o un blocco vincolato al tempo (ovvero la biometria è temporaneamente disattivata fino a quando l'utente non attende un intervallo di tempo) a causa di un numero eccessivo di tentativi non riusciti, bloccare anche tutte le altre biometrie di una classe biometrica inferiore. Nel caso del blocco vincolato al tempo, l'orario di backoff per la verifica biometrica DEVE essere il tempo di backoff massimo di tutti i dati biometrici in blocco vincolato al tempo.

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

    • [C-7-2] DEVE richiedere all'utente l'autenticazione primaria consigliata (ad es. PIN, sequenza, password) per reimpostare il contatore di blocco in caso di blocco biometrico. La biometria di Classe 3 POTREBBE essere autorizzata a reimpostare il contatore del blocco per un dato biometrico bloccato della stessa classe o di una classe inferiore. La biometria di Classe 2 o Classe 1 NON DEVE essere consentita per completare un'operazione di blocco di reimpostazione per qualsiasi biometria.

    Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 1 (in precedenza Convenience),:

    • [C-1-12] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 40% per specie di strumenti di attacco di presentazione (PAI), come misurato dai protocolli Android Biometrics Tests.

    • [C-SR-13] È VIVAMENTE CONSIGLIATO di avere un tasso di accettazione di spoofing e impostori non superiore al 30% per ogni specie di strumenti di attacco di presentazione (PAI), come misurato dai protocolli Android Biometrics Tests.

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

    • [C-SR-17] Ti consigliamo vivamente di implementare le nuove interfacce AIDL (come IFace.aidl e IFingerprint.aidl).

    Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 2 (in precedenza Debole):

    • [C-SR-15] È VIVAMENTE CONSIGLIATO di avere un tasso di accettazione di spoofing e impostori non superiore al 20% per specie di strumento di attacco di presentazione (PAI), come misurato dai protocolli Android Biometrics Tests.

    • [C-2-3] DEVE eseguire la corrispondenza biometrica in un ambiente di esecuzione isolato al di fuori dello spazio utente o kernel Android, come il Trusted Execution Environment (TEE), oppure su un chip con un canale sicuro verso l'ambiente di esecuzione isolato o su una macchina virtuale protetta che soddisfi i requisiti della Sezione 9.17.
    • [C-2-4] DEVE avere tutti i dati identificabili crittografati e autenticati in modo crittografico, in modo che non possano essere acquisiti, letti o alterati al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro per l'ambiente di esecuzione isolato come documentato nelle linee guida per l'implementazione sul sito del progetto open source Android o una macchina virtuale protetta controllata da hypervisor che soddisfi i requisiti della Sezione 9.17.
    • [C-2-5] Per la biometria basata su fotocamera, durante l'autenticazione o la registrazione basate su dati biometrici:
      • DEVE utilizzare la fotocamera in una modalità che impedisca la lettura o l'alterazione dei fotogrammi della videocamera al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro verso l'ambiente di esecuzione isolato oppure una macchina virtuale protetta controllata dall'hypervisor che soddisfi i requisiti della sezione 9.17.
      • Per le soluzioni RGB a fotocamera singola, i fotogrammi della fotocamera POSSONO essere leggibili al di fuori dell'ambiente di esecuzione isolato per supportare operazioni come l'anteprima per la registrazione, ma NON DEVONO comunque essere modificabili.
    • [C-2-7] NON DEVE consentire l'accesso non criptato a dati biometrici identificabili o a qualsiasi dato derivato da questi ultimi (come gli incorporamenti) al processore di applicazioni al di fuori del contesto del TEE o della macchina virtuale protetta controllata dall'hypervisor che soddisfa i requisiti della sezione 9.17. I dispositivi aggiornati su Android 9 o versioni precedenti non sono esenti da C-2-7.

    Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Classe 3 (in precedenza Strong):

    • [C-SR-16] È VIVAMENTE CONSIGLIATO di avere un tasso di accettazione di spoofing e impostori non superiore al 7% per specie di strumenti di attacco di presentazione (PAI), come misurato dai protocolli Android Biometrics Tests.

  • 7.3.13. IEEE 802.1.15.4 (UWB):

    Visualizza revisione

    Se le implementazioni dei dispositivi includono il supporto per 802.1.15.4 ed espongono la funzionalità a un'applicazione di terze parti:

    • [C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.uwb.
    • [C-1-3] DEVE supportare tutti i seguenti set di configurazione (combinazioni predefinite di parametri FIRA UCI) definiti nell'implementazione AOSP.
      • CONFIG_ID_1: intervallo unicast STATIC STS DS-TWR definito da FiRa, modalità differita, intervallo con intervallo di 240 ms.
      • CONFIG_ID_2: intervallo STATIC STS DS-TWR one-to-many definito da FiRa, modalità differita, intervallo con intervallo di 200 ms. Caso d'uso tipico: lo smartphone interagisce con molti smart device.
      • CONFIG_ID_3: come CONFIG_ID_1, ad eccezione dei dati relativi all'angolo di arrivo (AoA) non vengono riportati.
      • CONFIG_ID_4: come CONFIG_ID_1, ad eccezione della modalità di sicurezza P-STS attivata.
      • CONFIG_ID_5: come CONFIG_ID_2, ad eccezione della modalità di sicurezza P-STS attivata.
      • CONFIG_ID_6: come CONFIG_ID_3, ad eccezione della modalità di sicurezza P-STS attivata.
      • CONFIG_ID_7: come CONFIG_ID_2, ad eccezione del fatto che è abilitata la modalità chiave del controllo individuale P-STS.
    • [C-1-4] DEVE fornire un'invito all'utente per consentire all'utente di attivare/disattivare lo stato della radio UWB.
    • [C-1-5] DEVE imporre che le app che utilizzano radio UWB contengano l'autorizzazione UWB_RANGING (nel gruppo di autorizzazioni NEARBY_DEVICES).

    Il superamento dei test di conformità e certificazione pertinenti definiti dalle organizzazioni standard, tra cui FIRA, CCC e CSA, contribuisce a garantire il corretto funzionamento dello standard 802.1.15.4.

  • 7.4.1. Telefonia:

    Visualizza revisione

    "Telefonia", come utilizzato dalle API Android, e il presente documento si riferisce specificamente all'hardware relativo all'effettuazione di chiamate vocali e all'invio di SMS o alla definizione di dati mobili tramite una rete mobile (ad es. GSM, CDMA, LTE, NR)GSM o CDMA. Un dispositivo che supporta "Telefonia" può scegliere di offrire alcuni o tutti i servizi di chiamata, messaggistica e dati in base al prodotto.

    tramite una rete GSM o CDMA. Anche se queste chiamate vocali possono o non possono essere a commutazione di pacchetto,sono ai fini di Android considerate indipendenti da qualsiasi connettività dati che potrebbe essere implementata utilizzando la stessa rete. In altre parole,le API e le funzionalità di "telefonia" di Android fanno riferimento specificatamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni dei dispositivi che non possono effettuare chiamate o inviare/ricevere SMS non sono considerate dispositivi di telefonia, indipendentemente dal fatto che utilizzino o meno una rete mobile per la connettività dati.

  • 7.4.2. IEEE 802.11 (Wi-Fi):

    Visualizza revisione

    Se le implementazioni dei dispositivi includono il supporto per 802.11 ed espongono la funzionalità a un'applicazione di terze parti, questi:

    • [C-1-4] DEVE supportare il DNS multicast (mDNS) e NON filtrare i pacchetti mDNS (224.0.0.251 o ff02::fb) in qualsiasi momento, anche quando lo schermo non è in stato attivo, a meno che non sia necessario eliminare o filtrare questi pacchetti per rimanere entro gli intervalli di consumo di energia applicabili alle normative di riferimento. Per implementazioni di dispositivi Android Television, anche in stato di alimentazione in standby.

  • 7.4.3. Bluetooth

    Visualizza revisione

    Se le implementazioni dei dispositivi dichiarano FEATURE_BLUETOOTH_LE:

    • [C-SR-2] È VIVAMENTE CONSIGLIATO di misurare e compensare l'offset Rx per garantire che il RSSI BLE mediano sia -60dBm +/-10 dB a 1 metro di distanza da un dispositivo di riferimento che trasmette a ADVERTISE_TX_POWER_HIGH, con dispositivi orientati in modo da essere su "piani paralleli" con schermi rivolti nella stessa direzione.
    • [C-SR-3] È VIVAMENTE CONSIGLIATO di misurare e compensare l'offset Tx per garantire che l'RSSI BLE media sia -60dBm +/-10 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e la trasmissione a ADVERTISE_TX_POWER_HIGH, dove i dispositivi sono orientati in modo da essere su "piani paralleli" con schermi rivolti nella stessa direzione.

    • [C-10-3] DEVE misurare e compensare l'offset Rx per garantire che il RSSI BLE 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 l'RSSI BLE mediano sia -55 dBm +/-10 dB durante la scansione da un dispositivo di riferimento posizionato a 1 m di distanza e la trasmissione a ADVERTISE_TX_POWER_HIGH.

    Se le implementazioni dei dispositivi supportano Bluetooth versione 5.0:

    • [C-SR-4] È VIVAMENTE CONSIGLIATO di fornire assistenza per:
    • LE 2M PHY
    • Codec LE PHY
    • Estensione pubblicità LE
    • Pubblicità periodica
    • Almeno 10 insiemi di annunci.
    • Almeno 8 connessioni simultanee LE. Ogni connessione può essere associata a entrambi i ruoli di topologia di connessione.
    • Privacy del livello di link LE
    • Una dimensione "elenco di risoluzione" di almeno 8 voci

  • 7.4.9. UWB:

    Visualizza 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 o 1,25 m], dove la distanza di dati empirici reali è misurata dal bordo superiore del DUT. rivolto verso l'alto e inclinato di 45 gradi.

  • 7.5.1. Fotocamera posteriore:

    Visualizza revisione

    Una fotocamera posteriore è una fotocamera che si trova sul lato del dispositivo opposto al display, ovvero immagini scene all'altro lato del dispositivo, come una videocamera tradizionale.

    Una videocamera posteriore è rivolta verso il mondo e riproduce scene sul lato opposto del dispositivo, come una videocamera tradizionale; sui dispositivi portatili, è una videocamera sul lato del dispositivo di fronte al display.

  • 7.5.2. Fotocamera anteriore:

    Visualizza revisione

    Una fotocamera anteriore è una videocamera situata sullo stesso lato del dispositivo del display, ovvero una videocamera solitamente utilizzata per immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.

    Una fotocamera anteriore è una videocamera rivolta all'utente che in genere viene utilizzata per acquisire immagini dell'utente, ad esempio per videoconferenze e applicazioni simili; sui dispositivi portatili, si tratta di una videocamera situata sullo stesso lato del dispositivo del display.

  • 7.5.3. Fotocamera esterna:

    Visualizza revisione

    Una videocamera esterna è una videocamera che può essere collegata o scollegata fisicamente dall'implementazione del dispositivo in qualsiasi momento e rivolta in qualsiasi direzione, ad esempio le videocamere USB.

  • 7.5.4. Comportamento dell'API Camera:

    Visualizza revisione

    Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API relative alle fotocamere, per tutte le videocamere disponibili. Implementazioni dei dispositivi:

    • [C-SR-1] Per i dispositivi con più fotocamere RGB vicino e rivolte nella stessa direzione, è VIVAMENTE CONSIGLIATO di supportare un dispositivo fotocamera logica che elenca la funzionalità CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, composto da tutte le fotocamere RGB rivolte in quella direzione come sottodispositivi fisici.

  • 7.5.5. Orientamento della fotocamera:

    Visualizza revisione

    I dispositivi che soddisfano tutti i seguenti criteri sono esenti dal requisito di cui sopra:

    • Implementazioni di dispositivi che non possono essere ruotate dall'utente, ad esempio i dispositivi auto e motori.

  • 7.10. Tecnologia aptica:

    Visualizza revisione

    I dispositivi da tenere in mano o da indossare possono includere un attuatore aptico per uso generico, disponibile per le applicazioni, allo scopo di attirare l'attenzione tramite suonerie, allarmi, notifiche e feedback tattili generali.

    Se le implementazioni dei dispositivi NON includono un attuatore aptico per uso generico:

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

    Se le implementazioni dei dispositivi NON includono almeno uno di questi attuatori aptici per uso generico, questi:

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

    Consulta la Sezione 2.2.1 per i requisiti specifici del dispositivo.

9. Compatibilità del modello di sicurezza

  • 9.1. Autorizzazioni:

    Visualizza revisione

    Implementazioni dei dispositivi:

    • [C-0-4] DEVE avere una sola implementazione di entrambe le interfacce utente.

    Se le implementazioni dei dispositivi preinstallano eventuali pacchetti contenenti i ruoli System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence o System Visual Intelligence, i pacchetti:

    • [C-4-1] DEVE soddisfare tutti i requisiti descritti per le implementazioni dei dispositivi nelle sezioni "9.8.6 Acquisizione di contenuti" "9.8.6 Dati ambientali e a livello di sistema operativo e 9.8.15 Implementazioni di API con sandbox".

    • [C-4-2] NON DEVE avere l'autorizzazione android.permission.INTERNET. Questo è più difficile rispetto a quanto indicato nella sezione 9.8.6.
    • [C-4-3] NON DEVE essere vincolato ad altre app, ad eccezione delle seguenti app di sistema: Bluetooth, Contatti, Contenuti multimediali, Telefonia, SystemUI e componenti che forniscono API internet. Questo valore è più rigoroso rispetto a quanto indicato nella sezione 9.8.6 VIVAMENTE CONSIGLIATA.

    Se le implementazioni del dispositivo includono un'applicazione predefinita per supportare i VoiceInteractionService, questi:

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

  • 9.5. Supporto di più utenti:

    Visualizza revisione

    Se le implementazioni dei dispositivi creano il profilo utente aggiuntivo discusso sopra:

    • [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 una tariffa utente per eliminare tutti i dati del profilo clone.
    • [C-4-7] DEVE disinstallare tutte le app Clone, eliminare le directory dei dati privati dell'app e i relativi contenuti, ed eliminare i dati del profilo Clone, se l'utente sceglie di eliminare interi dati del profilo Clone.
    • DOVREBBE richiedere all'utente di eliminare tutti i dati del profilo clone quando viene eliminata l'ultima app clone.
    • [C-4-8] DEVE informare l'utente che i dati dell'app verranno eliminati quando l'applicazione di clonazione verrà disinstallata oppure offrire agli utenti un'opzione per conservare i dati dell'app quando l'applicazione viene disinstallata dal dispositivo.
    • [C-4-9] DEVE eliminare le directory dei dati private dell'app e i relativi contenuti se l'utente sceglie di eliminare i dati durante la disinstallazione.

    • [C-4-14] DEVONO avere autorizzazioni e gestione dello spazio di archiviazione separate per le applicazioni in esecuzione in questo profilo aggiuntivo

    • [C-4-5] DEVONO consentire solo alle applicazioni nel profilo aggiuntivo che hanno un'attività Avvio app di accedere ai contatti che sono già accessibili per il profilo utente principale.

  • 9.7. Funzionalità di sicurezza:

    Visualizza revisione

    Una tecnologia di sicurezza della memoria è una tecnologia che mitiga almeno le seguenti classi di bug con una probabilità elevata (> 90%) nelle applicazioni che utilizzano l'opzione manifest android:memtagMode:

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

    Implementazioni dei dispositivi:

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

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

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

      • memtag: è stata attivata una tecnologia di sicurezza della memoria come definita sopra
      • memtag-once: una tecnologia Memory Safety come definita sopra è abilitata temporaneamente e viene disattivata automaticamente al successivo riavvio
      • memtag-off: una tecnologia di sicurezza della memoria come definita sopra è disattivata

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

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

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

    • [C-SR-16] È VIVAMENTE CONSIGLIATO di mostrare un'impostazione sviluppatore che imposti memtag-una volta e riavvii il dispositivo. Con un bootloader compatibile, il progetto open source Android soddisfa i requisiti riportati sopra tramite il protocollo bootloader MTE.

    • [C-SR-17] È VIVAMENTE CONSIGLIATO di mostrare un'impostazione nel menu Impostazioni di sicurezza che consenta all'utente di abilitare memtag.

  • 9.8.2. Registrazione:

    Visualizza revisione

    Implementazioni dei dispositivi:

    • [C-0-2] DEVE visualizzare un avviso relativo all'utente e ottenere il consenso esplicito dell'utente consentendo l'acquisizione di qualsiasi informazione sensibile visualizzata sullo schermo dell'utenteche include esattamente lo stesso messaggio di AOSP ogni volta ogni volta che una sessione per acquisire lo schermo trasmissione o registrazione dello schermo attivata/attivata {}MediaProjection.createVirtualDisplay()VirtualDeviceManager.createVirtualDisplay() NON DEVE offrire agli utenti una possibilità di disattivare la futura visualizzazione del consenso dell'utente.

    • [C-SR-1] È VIVAMENTE CONSIGLIATO di mostrare un avviso all'utente che è esattamente lo stesso messaggio implementato in AOSP ma PUÒ essere modificato purché il messaggio avvisi chiaramente l'utente che vengono acquisite informazioni sensibili sullo schermo dell'utente.

    • [C-0-4] NON DEVE fornire agli utenti un'invito per disabilitare le richieste future del consenso dell'utente per l'acquisizione dello schermo, a meno che la sessione non venga avviata da un'app di sistema che l'utente ha autorizzato a associate() con il profilo del dispositivo android.app.role.COMPANION_DEVICE_APP_STREAMING o android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING.

  • 9.8.6. Dati ambientali e a livello di sistema operativo: questa sezione è stata rinominata da Acquisizione di contenuti e ricerca di app a Dati ambientali e a livello di sistema operativo.

    Visualizza revisione

    Android, tramite le API di sistema ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query o con altri mezzi proprietari, supporta un meccanismo che consente alle implementazioni di dispositivi di acquisire le seguenti interazioni di dati delle applicazioni tra le applicazioni e l'utente dati sensibili:

    • Qualsiasi schermata o altri dati inviati tramite AugmentedAutofillService al sistema.
    • Qualsiasi schermata o altri dati accessibili tramite l'API Content Capture.
    • Qualsiasi schermata o altro dato accessibile tramite l'API FieldClassificationService
    • Tutti i dati dell'applicazione trasmessi al sistema tramite l'API AppSearchManager e accessibili tramite AppSearchGlobalManager.query.

    • Eventuali altri eventi forniti da un'applicazione al sistema tramite l'API Content Capture o l'API AppSearchManager, un'API Android e un'API proprietaria con funzionalità simili.

    • Dati audio ottenuti a seguito dell'uso di SpeechRecognizer#onDeviceSpeechRecognizer() da parte dell'implementazione del riconoscimento vocale.
    • Dati audio ottenuti in background (continua) tramite AudioRecord, SoundTrigger o altre API audio; non viene quindi mostrato un indicatore visibile all'utente
    • Dati della videocamera ottenuti in background (continua) tramite CameraManager o altre API Camera; non viene visualizzato un indicatore visibile all'utente

    Se le implementazioni del dispositivo acquisiscono uno qualsiasi dei dati sopra indicati:

    • [C-1-3] DEVE inviare tutti questi dati e il log dal dispositivo utilizzando un meccanismo che tutela la privacy, salvo con il consenso esplicito dell'utente ogni volta che i dati vengono condivisi. Il meccanismo di tutela della privacy è definito come "quelli che consentono solo l'analisi in forma aggregata e impediscono la corrispondenza di eventi registrati o risultati derivati per i singoli utenti", per impedire che qualsiasi dato per utente sia introspettabile (ad es. implementato utilizzando una tecnologia di privacy differenziale come RAPPOR).

    • [C-1-5] NON DEVE condividere questi dati con altri componenti del sistema operativo che non rispettano i requisiti descritti nella sezione corrente (9.8.6 Acquisizione di contenuti Dati ambientali e a livello di sistema operativo), salvo che con il consenso esplicito dell'utente ogni volta che questi vengono condivisi. A meno che questa funzionalità non sia creata come un'API SDK Android (AmbientContext, HotwordDetectionService).

    • [C-1-6] DEVE fornire all'utente il permesso di cancellare i dati che l'implementazione o i mezzi proprietari raccolgono se quando i dati vengono archiviati in qualsiasi forma sul dispositivo.ContentCaptureService Se l'utente sceglie di cancellare i dati, DEVE rimuovere tutti i dati storici raccolti.

    • [C-SR-3] È VIVAMENTE CONSIGLIATO di implementarlo con l'API Android SDK o un repository open source simile di proprietà dell'OEM e / o da eseguire in un'implementazione con sandbox (consulta la sezione 9.8.15 Implementazioni API con sandbox).

    Android, tramite SpeechRecognizer#onDeviceSpeechRecognizer(), offre la possibilità di eseguire il riconoscimento vocale sul dispositivo senza coinvolgere la rete. Qualsiasi implementazione di SpeechRiconoscimento on-device DEVE seguire i criteri descritti in questa sezione.

  • 9.8.10. Segnalazione di bug relativi alla connettività:

    Visualizza revisione

    Se le implementazioni dei dispositivi dichiarano il flag funzionalità android.hardware.telephony, :

    • [C-1-4] I report generati utilizzando BUGREPORT_MODE_TELEPHONY DEVONO contenere almeno le seguenti informazioni:
      • SubscriptionManagerService dump

  • 9.8.14. Gestore delle credenziali: rimosso

  • 9.8.15. Implementazioni di API con sandbox: nuova sezione

    Visualizza revisione

    Android, tramite una serie di API di delega, fornisce un meccanismo per elaborare dati ambientali e sicuri a livello di sistema operativo. Tale elaborazione può essere delegata a un APK preinstallato con accesso privilegiato e capacità di comunicazione ridotte, nota come implementazione delle API con sandbox.

    Qualsiasi implementazione di API con sandbox:

    • [C-0-1] NON DEVE richiedere l'autorizzazione per INTERNET.
    • [C-0-2] DEVE accedere a internet solo tramite API strutturate supportate da implementazioni open source disponibili pubblicamente che utilizzano meccanismi che tutelano la privacy o indirettamente tramite API SDK per Android. Il meccanismo che tutela la privacy è definito come "quelli che consentono solo l'analisi in forma aggregata e impediscono la corrispondenza di eventi registrati o risultati derivati per i singoli utenti", per impedire che qualsiasi dato per utente sia introspezionabile (ad es. implementato utilizzando una tecnologia di privacy differenziale come RAPPOR).
    • [C-0-3] DEVE mantenere i servizi separati dagli altri componenti di sistema (ad es. non associare il servizio o gli ID processo di condivisione), ad eccezione dei seguenti elementi:
      • Telefonia, contatti, UI di sistema e contenuti multimediali
    • [C-0-4] NON DEVE consentire agli utenti di sostituire i servizi con un'applicazione o un servizio installabile dall'utente
    • [C-0-5] DEVE consentire solo ai servizi preinstallati di acquisire questi dati. A meno che la funzionalità di sostituzione non sia integrata in AOSP (ad esempio per le app per l'assistente digitale).
    • [C-0-6] NON DEVE consentire ad app diverse dal meccanismo dei servizi preinstallati di acquisire questi dati. A meno che tale funzionalità di acquisizione non sia implementata con un'API SDK Android.
    • [C-0-7] DEVE fornire l'autorizzazione all'utente per disabilitare i servizi.
    • [C-0-8] NON DEVE omettere l'autorizzazione dell'utente per gestire le autorizzazioni Android di cui sono in possesso i servizi e seguire il modello di autorizzazioni Android descritto nella Sezione 9.1. Autorizzazione.

  • 9.8.16. Dati audio e della videocamera continui: nuova sezione

    Visualizza revisione

    In aggiunta ai requisiti descritti nelle sezioni 9.8.2 Registrazione, 9.8.6 Dati ambientali e a livello di sistema operativo e 9.8.15 Implementazioni API con sandbox, implementazioni che utilizzano dati audio ottenuti in background (continua) tramite AudioRecord, SoundTrigger o altre API Audio O dati della videocamera ottenuti in background (continua) tramite CameraManager o altre API Camera:

    • [C-0-1] DEVE applicare un indicatore corrispondente (videocamera e/o microfono come indicato nella sezione 9.8.2 Registrazione), a meno che:
    • [C-SR-1] CONSIGLIamo VIVAMENTE di richiedere il consenso dell'utente per ogni funzionalità che utilizza questi dati e di essere disabilitato per impostazione predefinita.
    • [C-SR-2] VIVAMENTE CONSIGLIATO di applicare lo stesso trattamento (ovvero seguire le limitazioni descritte nei punti 9.8.2 Registrazione, 9.8.6 Dati ambientali e a livello di sistema operativo, 9.8.15 Implementazioni dell'API Sandboxed e 9.8.16 Dati continui relativi ad audio e fotocamera) ai dati della videocamera provenienti da un dispositivo indossabile remoto.

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

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

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

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

  • 9.8.17. Telemetria: nuova sezione

    Visualizza revisione

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

    StatisticheManager offre anche un modo per raccogliere dati classificati come sensibili alla privacy dai dispositivi con un meccanismo di tutela della privacy. In particolare, l'API StatsManager::query offre la possibilità di eseguire query su categorie di metriche limitate definite in StatisticheLog.

    Qualsiasi query di implementazione e raccolta di metriche limitate da StatsManager:

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

  • 9.10. Integrità del dispositivo:

    Visualizza revisione

    Implementazioni sui dispositivi

    Se le implementazioni dei dispositivi sono in grado di verificare i contenuti dei file per singola pagina,:

    • [C-0-3 C-2-1] supporta la verifica crittografica del contenuto del file con una chiave attendibile senza leggere l'intero file.

    • [C-0-4 C-2-2] NON DEVE consentire la riuscita delle richieste di lettura su un file protetto quando i contenuti di lettura non vengono verificati in base a una chiave attendibile non viene verificato in base a [C-2-1] di cui sopra.

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

  • 9.11. Chiavi e credenziali:

    Visualizza revisione

    Il sistema Android Keystore consente agli sviluppatori di app di archiviare le chiavi di crittografia in un container e di utilizzarle in operazioni di crittografia tramite l'API KeyChain o l'API Keystore. Implementazioni dei dispositivi:

    • [C-0-3] DEVE limitare il numero di tentativi di autenticazione principale non riusciti.
    • [C-SR-2] È VIVAMENTE CONSIGLIATO di implementare un limite superiore di 20 tentativi di autenticazione principali non riusciti e, se gli utenti acconsentono e attivano la funzionalità, eseguire un "ripristino dei dati di fabbrica" dopo aver superato il limite di tentativi di autenticazione principali non riusciti.

    Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco in base a un secret noto e utilizzano un nuovo metodo di autenticazione da considerare come modo sicuro per bloccare lo schermo:

    • [C-SR-3] È VIVAMENTE CONSIGLIATO che il PIN abbia almeno 6 cifre o, equivalente, un'entropia di 20 bit.
    • [C-2-1] Un PIN di lunghezza inferiore a 6 cifre NON DEVE consentire l'inserimento automatico senza interazione dell'utente per evitare di rivelare la lunghezza del PIN.

  • 9.11.1. Schermata di blocco sicura, autenticazione e dispositivi virtuali:

    Visualizza revisione

    Implementazioni dei dispositivi:

    • [C-0-1] DEVE limitare il numero di tentativi di autenticazione principale non riusciti.
    • [C-SR-5] È VIVAMENTE CONSIGLIATO di implementare un limite superiore di 20 tentativi di autenticazione principali non riusciti e, se gli utenti acconsentono e attivano la funzionalità, eseguire un "ripristino dei dati di fabbrica" dopo aver superato il limite di tentativi di autenticazione primari non riusciti.

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

    • [C-SR-6] È VIVAMENTE CONSIGLIATO che il PIN abbia almeno 6 cifre o, equivalente, un'entropia di 20 bit.
    • [C-SR-7] UN PIN di lunghezza inferiore a 6 cifre è VIVAMENTE CONSIGLIATO DI NON consentire l'inserimento automatico senza interazione dell'utente ed evitare di rivelare la lunghezza del PIN.

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

    [C-7-8] L'utente DEVE essere sottoposto a una richiesta di verifica di uno dei metodi di autenticazione principale consigliati (ad es.PIN, sequenza, password) almeno una volta ogni 72 ore o meno, a meno che la sicurezza dell'utente (ad es. la distrazione del conducente) non sia preoccupante.

    Se le implementazioni dei dispositivi consentono alle applicazioni di creare display virtuali secondari e supportano eventi di input associati, ad esempio tramite VirtualDeviceManager e i display non sono contrassegnati con VIRTUAL_DISPLAY_FLAG_SECURE, questi:

    [C-13-10] DEVE disattivare l'installazione delle app avviate da dispositivi virtuali.

  • 9.17. Framework di virtualizzazione di Android:

    Visualizza revisione

    Se il dispositivo implementa il supporto per le API Android Virtualization Framework (android.system.virtualmachine.*), l'host Android:

    • [C-1-1] DEVE supportare tutte le API definite dal pacchetto android.system.virtualmachine.
    • [C-1-2] NON DEVE modificare il modello Android SELinux e di autorizzazione per la gestione delle macchine virtuali protette (pVM).

    • [C-1-3] NON DEVE modificare, omettere o sostituire le regole non consentite all'interno del sistema/sepolicy fornito nell'Android Open Source Project (AOSP) upstream e il criterio DEVE essere compilato con tutte le regole non consentite presenti.

    • [C-1-4] DEVONO consentire solo il codice firmato dalla piattaforma e le app con privilegiNON DEVONO consentire codice non attendibile (ad es. app di terze parti) di creare ed eseguire una macchina virtuale protettapVM. Nota: questo aspetto potrebbe cambiare nelle future release di Android.

    • [C-1-5] NON DEVE consentire a una macchina virtuale protetta pVM di eseguire codice che non fa parte dell'immagine di fabbrica o dei relativi aggiornamenti. Tutto ciò che non è coperto da Avvio verificato di Android (ad esempio, i file scaricati da internet o installate tramite sideload) NON DEVE essere consentito per l'esecuzione in una macchina virtuale protetta .

    • [C-1-5] DEVE consentire solo a una pVM non di cui non è possibile eseguire il debug di eseguire il codice dall'immagine di fabbrica o dagli aggiornamenti della relativa piattaforma, che includono anche eventuali aggiornamenti alle app con privilegi.

    Se il dispositivo implementa il supporto per le API Android Virtualization Framework (android.system.virtualmachine.*), qualsiasi istanza Protected Virtual Machine pVM :

    • [C-2-1] DEVE essere in grado di eseguire tutti i sistemi operativi disponibili nell'APEX di virtualizzazione in una macchina virtuale protetta .
    • [C-2-2] NON DEVE consentire a una macchina virtuale protetta pVM di eseguire un sistema operativo non firmato dall'implementatore del dispositivo o dal fornitore del sistema operativo.
    • [C-2-3] NON DEVE consentire a una macchina virtuale protetta pVM di eseguire dati come codice (ad es. SELinux non consentire mai execmem).

    • [C-2-4] NON DEVE modificare, omettere o sostituire le regole non consentite all'interno del sistema/sepolicy/microdroid fornito nell'Android Open Source Project (AOSP) a monte.

    • [C-2-5] DEVE implementare meccanismi di difesa in profondità Protected Virtual Machine pVM (ad es. SELinux per pVM) anche per i sistemi operativi non microdroidi.
    • [C-2-6] DEVE garantire che la pVM non riesca che il firmware si rifiuta di avviarsi se non è in grado di verificare le immagini iniziali che la VM non potrà essere eseguita. La verifica DEVE essere eseguita all'interno della VM.
    • [C-2-7] DEVE garantire che la pVM non si avvii il firmware si rifiuta se l'integrità dell'istanza.img è compromessa.

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

    • [C-3-1] DEVE garantire che le pagine di memoria di proprietà esclusiva di una VM (pVM o VM host) siano accessibili solo alla macchina virtuale stessa o all'hypervisor, non da altre macchine virtuali protette o non protette. NON DEVE consentire a nessuna pVM di accedere a una pagina che appartiene a un'altra entità (ossia un'altra pVM o un hypervisor), a meno che non venga condivisa esplicitamente dal proprietario della pagina. Include la VM host. Questo vale sia per gli accessi a CPU che per DMA.
    • [C-3-2] DEVE cancellare una pagina dopo che è stata utilizzata da una pVM e prima che venga restituita all'host (ad esempio, la pVM viene eliminata).
    • [C-3-3SR-1] È VIVAMENTE CONSIGLIATO per garantire DEVONO garantire che il firmware pVM venga caricato ed eseguito prima di qualsiasi codice in una pVM.
    • [C-3-4] DEVE garantire che ogni VM generi un secret per VM che {Boot Certificate Chain (BCC) and Compound Device Identifier (CDI) fornito a un'istanza pVM possa essere ottenuto solo da quella specifica istanza VM e modifiche al ripristino dei dati di fabbrica e OTA.

    Se il dispositivo implementa il supporto per le API Android Virtualization Framework, in tutte le aree:

    • [C-4-1] NON DEVE fornire a una VM una funzionalità che consente di aggirare il Modello di sicurezza Android.

    Se il dispositivo implementa il supporto per le API Android Virtualization Framework:

    • [C-5-1] DEVE essere in grado di supportare le compilazioni isolate ma potrebbe disattivare la funzionalità Compilation isolate nella spedizione sul dispositivo di un aggiornamento del runtime ART.

    Se il dispositivo implementa il supporto per le API Android Virtualization Framework, per Key Management:

    • [C-6-1] DEVE eseguire il rooting della catena DICE in un punto che l'utente non possa modificare, anche sui dispositivi sbloccati. (per garantire che non sia possibile falsificarlo).

    • [C-SR-26-2] È CONSIGLIATO VIVAMENTE l'uso di DICE come meccanismo di derivazione dei secret per VM. DICE DEVE funzionare correttamente, ovvero fornire i valori corretti.

Torna all'inizio