Definizione di compatibilità di Android 10

1. Introduzione

Questo documento elenca i requisiti che devono essere soddisfatti affinché i dispositivi siano compatibili con Android 10.

L'utilizzo di "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" è conforme allo standard IETF definito in RFC2119.

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

Per essere considerate compatibili con Android 10, le implementazioni dei dispositivi DEVONO soddisfare i requisiti presentati in questa Definizione di compatibilità, inclusi tutti i documenti incorporati tramite riferimento.

Se questa definizione o i test software descritti nella sezione 10 sono silenziosi, ambigui o incompleti, è responsabilità dell'implementatore del dispositivo garantire la compatibilità con le implementazioni esistenti.

Per questo motivo, l'Android Open Source Project è sia l'implementazione di riferimento che quella preferita di Android. È VIVAMENTE CONSIGLIATO agli implementatori di dispositivi di basare le proprie implementazioni, nella misura massima possibile, sul codice sorgente "upstream" disponibile nell'Android Open Source Project. Sebbene alcuni componenti possano essere teoricamente sostituiti con implementazioni alternative, è VIVAMENTE CONSIGLIATO di non seguire questa pratica, in quanto superare i test del software diventerà molto più difficile. È responsabilità dell'implementatore garantire la piena compatibilità comportamentale con l'implementazione Android standard, inclusa e oltre la Compatibility Test Suite. Infine, tieni presente che alcune sostituzioni e modifiche dei componenti sono esplicitamente vietate da questo documento.

Molte delle risorse a cui viene fatto riferimento in questo documento derivano direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni contenute nella documentazione dell'SDK. Nei casi in cui questa definizione di compatibilità o la suite di test di compatibilità non sono in linea con la documentazione dell'SDK, quest'ultima è considerata autorevole. Qualsiasi dettaglio tecnico fornito nelle risorse collegate in questo documento è considerato parte di questa Definizione di compatibilità.

1.1 Struttura del documento

1.1.1. Requisiti per tipo di dispositivo

La sezione 2 contiene tutti i requisiti applicabili a un tipo di dispositivo specifico. Ogni sottosezione della Sezione 2 è dedicata a un tipo di dispositivo specifico.

Tutti gli altri requisiti, che si applicano universalmente a qualsiasi implementazione di dispositivi Android, sono elencati nelle sezioni successive alla Sezione 2. In questo documento, questi requisiti sono indicati come "Requisiti principali".

1.1.2. ID requisito

L'ID requisito viene assegnato ai requisiti MUST.

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

Ogni ID è definito come segue:

  • ID tipo di dispositivo (vedi di più in 2. Tipi di dispositivi)
    • C: Core (requisiti applicati a qualsiasi implementazione di dispositivi Android)
    • H: Dispositivo Android portatile
    • T: Dispositivo Android Television
    • R: Implementazione di Android Automotive
    • W: Android Watch implementation
    • Scheda: implementazione del tablet Android
  • ID condizione
    • Quando il requisito è incondizionato, questo ID viene impostato su 0.
    • Quando il requisito è condizionale, viene assegnato il numero 1 alla prima condizione e il numero aumenta di 1 all'interno della stessa sezione e dello stesso tipo di dispositivo.
  • ID requisito
    • Questo ID inizia da 1 e viene incrementato di 1 all'interno della stessa sezione e della stessa condizione.

1.1.3. ID requisito nella sezione 2

L'ID requisito nella sezione 2 inizia con l'ID sezione corrispondente, seguito dall'ID requisito descritto sopra.

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

2. Tipi di dispositivo

Sebbene l'Android Open Source Project fornisca uno stack software che può essere utilizzato per una varietà di tipi di dispositivi e fattori di forma, esistono alcuni tipi di dispositivi che hanno un ecosistema di distribuzione delle applicazioni relativamente più consolidato.

Questa sezione descrive questi tipi di dispositivi, nonché i requisiti e i consigli aggiuntivi applicabili a ciascun tipo.

Tutte le implementazioni di dispositivi Android che non rientrano in nessuno dei tipi di dispositivi descritti DEVONO comunque soddisfare tutti i requisiti delle altre sezioni di questa Definizione di compatibilità.

2.1 Configurazioni dispositivo

Per le principali differenze nella configurazione hardware in base al tipo di dispositivo, consulta i requisiti specifici per il dispositivo riportati di seguito in questa sezione.

2.2. Requisiti per i dispositivi portatili

Un dispositivo portatile Android si riferisce a un'implementazione di un dispositivo Android che viene in genere utilizzato tenendolo in mano, ad esempio un lettore MP3, uno smartphone o un tablet.

Le implementazioni di dispositivi Android sono classificate come portatili se soddisfano tutti i seguenti criteri:

  • Avere una fonte di alimentazione che fornisca mobilità, ad esempio una batteria.
  • Avere una dimensione dello schermo diagonale fisica compresa tra 2,5 e 8 pollici.

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

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

2.2.1. Hardware

Implementazioni di dispositivi portatili:

  • [7.1.1.1/H-0-1] DEVE avere almeno un display compatibile con Android di almeno 6,35 cm di dimensioni diagonali fisiche e ogni display compatibile con Android DEVE soddisfare tutti i requisiti descritti in questo documento.
  • [7.1.1.3/H-SR] Sono FORTEMENTE CONSIGLIATE per offrire agli utenti la possibilità di modificare le dimensioni del display (densità dello schermo).

Se le implementazioni di dispositivi portatili dichiarano il supporto per display High Dynamic Range tramite Configuration.isScreenHdr():

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

Implementazioni di dispositivi portatili:

  • [7.1.5/H-0-1] DEVE includere il supporto per la modalità di compatibilità delle applicazioni legacy implementata dal codice sorgente open source Android upstream. ovvero le implementazioni del dispositivo NON DEVONO alterare i trigger o le soglie in corrispondenza dei quali viene attivata la modalità di compatibilità e NON DEVONO alterare il comportamento della modalità di compatibilità stessa.
  • [7.2.1/H-0-1] DEVE includere il supporto per le applicazioni Input Method Editor (IME) di terze parti.
  • [7.2.3/H-0-3] DEVE fornire la funzione Home su tutti i display compatibili con Android che forniscono la schermata Home.
  • [7.2.3/H-0-4] DEVE fornire la funzione Indietro su tutti i display compatibili con Android e la funzione Recenti su almeno uno dei display compatibili con Android.
  • [7.2.3/H-0-2] DEVE inviare sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano. Questi eventi NON DEVONO essere utilizzati dal sistema e POSSONO essere attivati al di fuori del dispositivo Android (ad es. tastiera hardware esterna collegata al dispositivo Android).
  • [7.2.4/H-0-1] DEVE supportare l'input touchscreen.
  • [7.2.4/H-SR] È VIVAMENTE CONSIGLIATO di avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService, o un'attività che gestisce ACTION_ASSIST con la pressione prolungata di KEYCODE_MEDIA_PLAY_PAUSE o KEYCODE_HEADSETHOOK se l'attività in primo piano non gestisce questi eventi di pressione prolungata.
  • [7.3.1/H-SR] È FORTEMENTE CONSIGLIATO includere un accelerometro a 3 assi.

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

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

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

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

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

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

Implementazioni di dispositivi portatili che possono effettuare una chiamata vocale e indicare un valore diverso da PHONE_TYPE_NONE in getPhoneType:

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

Implementazioni di dispositivi portatili:

  • [7.3.11/H-SR] Sono CONSIGLIATI per supportare il sensore di postura con 6 gradi di libertà.
  • [7.4.3/H] DEVE includere il supporto per Bluetooth e Bluetooth LE.

Se le implementazioni di dispositivi portatili includono una connessione a consumo:

  • [7.4.7/H-1-1] DEVE fornire la modalità Risparmio dati.

Se le implementazioni di dispositivi portatili includono un dispositivo fotocamera logico che elenca le funzionalità utilizzando CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, queste:

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

Implementazioni di dispositivi portatili:

  • [7.6.1/H-0-1] DEVE avere almeno 4 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione (ovvero la partizione "/data").
  • [7.6.1/H-0-2] DEVE restituire "true" per ActivityManager.isLowRamDevice() quando la memoria disponibile per il kernel e lo spazio utente è inferiore a 1 GB.

Se le implementazioni dei dispositivi portatili dichiarano il supporto di una sola ABI a 32 bit:

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

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

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

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

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

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

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

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

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

Tieni presente che la "memoria disponibile per il kernel e lo spazio utente" sopra indicata si riferisce allo spazio di memoria fornito in aggiunta a qualsiasi memoria già dedicata a componenti hardware come radio, video e così via che non sono sotto il controllo del kernel nelle implementazioni del dispositivo.

Se le implementazioni di dispositivi portatili includono una memoria disponibile per il kernel e lo spazio utente inferiore o uguale a 1 GB:

  • [7.6.1/H-9-1] DEVE dichiarare il flag funzionalità android.hardware.ram.low.
  • [7.6.1/H-9-2] DEVE avere almeno 1,1 GB di spazio di archiviazione non volatile per i dati privati dell'applicazione (ovvero la partizione "/data").

Se le implementazioni di dispositivi portatili includono più di 1 GB di memoria disponibile per il kernel e lo spazio utente:

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

Implementazioni di dispositivi portatili:

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

Se le implementazioni di dispositivi portatili includono una porta USB che supporta la modalità periferica:

  • [7.7.1/H-1-1] DEVE implementare l'API Android Open Accessory (AOA).

Se le implementazioni di dispositivi portatili includono una porta USB che supporta la modalità host:

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

Implementazioni di dispositivi portatili:

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

Se le implementazioni di dispositivi portatili sono in grado di soddisfare tutti i requisiti di prestazioni per supportare la modalità VR e includono il supporto,

  • [7.9.1/H-1-1] DEVE dichiarare il flag funzionalità android.hardware.vr.high_performance.
  • [7.9.1/H-1-2] DEVE includere un'applicazione che implementi android.service.vr.VrListenerService che può essere attivata dalle applicazioni VR tramite android.app.Activity#setVrModeEnabled.

Se le implementazioni di dispositivi portatili includono una o più porte USB-C in modalità host e implementano (classe audio USB), oltre ai requisiti della sezione 7.7.2, devono:

  • [7.8.2.2/H-1-1] DEVE fornire la seguente mappatura del software dei codici HID:
Funzione Mappature Contesto Comportamento
A Pagina di utilizzo HID: 0x0C
Utilizzo HID: 0x0CD
Tasto del kernel: KEY_PLAYPAUSE
Tasto Android: KEYCODE_MEDIA_PLAY_PAUSE 		Riproduzione di contenuti multimediali Input: pressione breve
Output: riproduci o metti in pausa
Input: tieni premuto
Output: avvia il comando vocale
Invio: android.speech.action.VOICE_SEARCH_HANDS_FREE se il dispositivo è bloccato o lo schermo è spento. In caso contrario, invia android.speech.RecognizerIntent.ACTION_WEB_SEARCH
Chiamata in arrivo Input: pressione breve
Output: accetta chiamata
Input: tieni premuto
Output: rifiuta chiamata
Chiamata in corso Input: pressione breve
Output: termina la chiamata
Input: premi a lungo
Output: disattiva o riattiva l'audio del microfono
B Pagina di utilizzo HID: 0x0C
Utilizzo HID: 0x0E9
Chiave del kernel: KEY_VOLUMEUP
Chiave Android: VOLUME_UP 		Riproduzione di contenuti multimediali, Chiamata in corso Input: pressione breve o lunga
Output: aumenta il volume del sistema o delle cuffie
C Pagina di utilizzo HID: 0x0C
Utilizzo HID: 0x0EA
Chiave del kernel: KEY_VOLUMEDOWN
Chiave Android: VOLUME_DOWN 		Riproduzione di contenuti multimediali, Chiamata in corso Input: pressione breve o lunga
Output: diminuisce il volume del sistema o delle cuffie
D Pagina di utilizzo HID: 0x0C
Utilizzo HID: 0x0CF
Chiave kernel: KEY_VOICECOMMAND
Chiave Android: KEYCODE_VOICE_ASSIST 		Tutti. Può essere attivato in qualsiasi istanza. Input: pressione breve o lunga
Output: avvia il comando vocale
  • [7.8.2.2/H-1-2] DEVE attivare ACTION_HEADSET_PLUG all'inserimento di un connettore, ma solo dopo che le interfacce e gli endpoint audio USB sono stati enumerati correttamente per identificare il tipo di terminale connesso.

Quando vengono rilevati i tipi di terminale audio USB 0x0302, questi:

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

Quando vengono rilevati i tipi di terminale audio USB 0x0402:

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

Quando viene chiamata l'API AudioManager.getDevices() mentre la periferica USB è connessa:

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

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

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

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

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

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

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

  • [7.8.2.2/H-SR] Sono FORTEMENTE CONSIGLIATI al momento della connessione di una periferica audio USB-C, per eseguire l'enumerazione dei descrittori USB, identificare i tipi di terminale e trasmettere l'intent ACTION_HEADSET_PLUG in meno di 1000 millisecondi.

2.2.2. Multimediale

Le implementazioni dei dispositivi portatili DEVONO supportare i seguenti formati di codifica e decodifica audio e renderli disponibili per le applicazioni di terze parti:

  • [5.1/H-0-1] AMR-NB
  • [5.1/H-0-2] AMR-WB
  • [5.1/H-0-3] Profilo MPEG-4 AAC (AAC LC)
  • [5.1/H-0-4] Profilo MPEG-4 HE AAC (AAC+)
  • [5.1/H-0-5] AAC ELD (enhanced low delay AAC)

Le implementazioni dei dispositivi portatili DEVONO supportare i seguenti formati di codifica video e renderli disponibili per le applicazioni di terze parti:

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

Le implementazioni dei dispositivi portatili DEVONO supportare i seguenti formati di decodifica video e renderli disponibili per le applicazioni di terze parti:

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

2.2.3. Software

Implementazioni di dispositivi portatili:

  • [3.2.3.1/H-0-1] DEVE avere un'applicazione che gestisca gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE e ACTION_CREATE_DOCUMENT come descritto nei documenti dell'SDK e fornire all'utente la possibilità di accedere ai dati del provider di documenti utilizzando l'API DocumentsProvider.
  • [3.4.1/H-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.
  • [3.4.2/H-0-1] DEVE includere un'applicazione browser autonoma per la navigazione web generale degli utenti.
  • [3.8.1/H-SR] È FORTEMENTE CONSIGLIATO implementare un Avvio app predefinito che supporti il blocco in-app di scorciatoie, widget e widgetFeatures.
  • [3.8.1/H-SR] È VIVAMENTE CONSIGLIATO di implementare un launcher predefinito che fornisca un accesso rapido alle scorciatoie aggiuntive fornite da app di terze parti tramite l'API ShortcutManager.
  • [3.8.1/H-SR] È FORTEMENTE CONSIGLIATO includere un'app di avvio predefinita che mostri i badge per le icone delle app.
  • [3.8.2/H-SR] Sono FORTEMENTE CONSIGLIATI per supportare i widget di app di terze parti.
  • [3.8.3/H-0-1] DEVE consentire alle app di terze parti di notificare agli utenti eventi importanti tramite le classi API Notification e NotificationManager.
  • [3.8.3/H-0-2] MUST support rich notifications.
  • [3.8.3/H-0-3] DEVE supportare le notifiche heads-up.
  • [3.8.3/H-0-4] DEVE includere una barra delle notifiche che consenta all'utente di controllare direttamente (ad es. rispondere, posticipare, chiudere, bloccare) le notifiche tramite funzionalità utente come pulsanti di azione o il pannello di controllo implementato in AOSP.
  • [3.8.3/H-0-5] DEVE mostrare le scelte fornite tramite RemoteInput.Builder setChoices() nell'area notifiche.
  • [3.8.3/H-SR] È FORTEMENTE CONSIGLIATO di mostrare la prima scelta fornita tramite RemoteInput.Builder setChoices() nella barra delle notifiche senza ulteriori interazioni dell'utente.
  • [3.8.3/H-SR] È FORTEMENTE CONSIGLIATO di mostrare tutte le scelte fornite tramite RemoteInput.Builder setChoices() nell'area notifiche quando l'utente espande tutte le notifiche nell'area notifiche.
  • [3.8.3.1/H-SR] È FORTEMENTE CONSIGLIATO visualizzare le azioni per le quali Notification.Action.Builder.setContextual è impostato come true in linea con le risposte visualizzate da Notification.Remoteinput.Builder.setChoices.
  • [3.8.4/H-SR] È VIVAMENTE CONSIGLIATO di implementare un assistente sul dispositivo per gestire l'azione Assist.

Se le implementazioni di dispositivi portatili supportano l'azione Assistente,

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

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

  • [3.8.10/H-1-1] DEVE mostrare le notifiche della schermata di blocco, incluso il modello di notifica multimediale.

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

  • [3.9/H-1-1] DEVE implementare l'intera gamma di criteri di amministrazione dei dispositivi definiti nella documentazione dell'SDK Android.
  • [3.9/H-1-2] DEVE dichiarare il supporto dei profili gestiti tramite il flag di funzionalità android.software.managed_users, tranne quando il dispositivo è configurato in modo da segnalarsi come dispositivo con poca RAM o in modo da allocare lo spazio di archiviazione interno (non rimovibile) come spazio di archiviazione condiviso.

Implementazioni di dispositivi portatili:

  • [3.10/H-0-1] DEVE supportare i servizi di accessibilità di terze parti.
  • [3.10/H-SR] È FORTEMENTE CONSIGLIATO precaricare sul dispositivo servizi di accessibilità paragonabili o superiori a quelli di Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato), come forniti nel progetto open source TalkBack.
  • [3.11/H-0-1] DEVE supportare l'installazione di motori TTS di terze parti.
  • [3.11/H-SR] È FORTEMENTE CONSIGLIATO includere un motore TTS che supporti le lingue disponibili sul dispositivo.
  • [3.13/H-SR] È VIVAMENTE CONSIGLIATO includere un componente UI Impostazioni rapide.

Se le implementazioni di dispositivi portatili Android dichiarano il supporto di FEATURE_BLUETOOTH o FEATURE_WIFI:

  • [3.16/H-1-1] DEVE supportare la funzionalità di accoppiamento del dispositivo complementare.

Se la funzione di navigazione viene fornita come azione sullo schermo basata su gesti:

  • [7.2.3/H] La zona di riconoscimento dei gesti per la funzione Home NON DEVE superare i 32 dp di altezza dal bordo inferiore dello schermo.

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

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

2.2.4. Prestazioni e potenza

  • [8.1/H-0-1] Latenza dei frame coerente. La latenza dei frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più di 5 frame al secondo e DOVREBBE essere inferiore a 1 frame al secondo.
  • [8.1/H-0-2] Latenza dell'interfaccia utente. Le implementazioni del dispositivo DEVONO garantire un'esperienza utente a bassa latenza scorrendo un elenco di 10.000 voci di elenco come definito da Android Compatibility Test Suite (CTS) in meno di 36 secondi.
  • [8.1/H-0-3] Passaggio da un'app all'altra. Quando sono state avviate più applicazioni, il riavvio di un'applicazione già in esecuzione dopo l'avvio DEVE richiedere meno di 1 secondo.

Implementazioni di dispositivi portatili:

  • [8.2/H-0-1] DEVE garantire una velocità di scrittura sequenziale di almeno 5 MB/s.
  • [8.2/H-0-2] DEVE garantire una velocità di scrittura casuale di almeno 0,5 MB/s.
  • [8.2/H-0-3] DEVE garantire una velocità di lettura sequenziale di almeno 15 MB/s.
  • [8.2/H-0-4] DEVE garantire una velocità di lettura casuale di almeno 3,5 MB/s.

Se le implementazioni di dispositivi portatili includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP:

  • [8.3/H-1-1] DEVE fornire all'utente la possibilità di attivare e disattivare la funzionalità di risparmio energetico.
  • [8.3/H-1-2] DEVE fornire all'utente la possibilità di visualizzare tutte le app esenti dalle modalità di risparmio energetico Standby delle app e Sospensione.

Implementazioni di dispositivi portatili:

  • [8.4/H-0-1] DEVE fornire un profilo di alimentazione per componente che definisca il valore di consumo di corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto Android Open Source.
  • [8.4/H-0-2] DEVE segnalare tutti i valori di consumo energetico in milliampereora (mAh).
  • [8.4/H-0-3] DEVE segnalare il consumo energetico della CPU per ogni UID del processo. L'Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
  • [8.4/H-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando shell adb shell dumpsys batterystats allo sviluppatore dell'app.
  • [8.4/H] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo energetico del componente hardware a un'applicazione.

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

2.2.5. Modello di sicurezza

Implementazioni di dispositivi portatili:

  • [9.1/H-0-1] DEVE consentire alle app di terze parti di accedere alle statistiche di utilizzo tramite l'autorizzazione android.permission.PACKAGE_USAGE_STATS e fornire un meccanismo accessibile agli utenti per concedere o revocare l'accesso a queste app in risposta all'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Implementazioni di dispositivi portatili (* Non applicabile ai tablet):

  • [9.11/H-0-2]* DEVE eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
  • [9.11/H-0-3]* DEVONO essere implementati gli algoritmi di crittografia RSA, AES, ECDSA e HMAC e le funzioni hash MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto Android Open Source Project (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti di un isolamento basato su un hypervisor appropriato sono opzioni alternative.
  • [9.11/H-0-4]* DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto Android Open Source Project upstream fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
  • [9.11/H-0-5]* DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori di dispositivi. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, per ogni 100.000 unità potrebbe essere utilizzata una chiave diversa.

Tieni presente che se l'implementazione di un dispositivo è già stata lanciata su una versione precedente di Android, il dispositivo è esente dal requisito di disporre di un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione della chiave, a meno che non dichiari la funzionalità android.hardware.fingerprint, che richiede un keystore supportato da un ambiente di esecuzione isolato.

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

  • [9.11/H-1-1] DEVE consentire all'utente di scegliere il timeout di sospensione più breve, ovvero un tempo di transizione dallo stato sbloccato a quello bloccato, pari a 15 secondi o meno.
  • [9.11/H-1-2] DEVE fornire all'utente la possibilità di nascondere le notifiche e disattivare tutte le forme di autenticazione, ad eccezione dell'autenticazione principale descritta in 9.11.1 Schermata di blocco sicura. AOSP soddisfa il requisito come modalità di blocco.

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

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

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

  • [9.5/H-3-1] NON DEVE supportare i profili con limitazioni, ma DEVE essere in linea con l'implementazione AOSP dei controlli per consentire /disattivare l'accesso di altri utenti alle chiamate vocali e agli SMS.

2.2.6. Compatibilità di strumenti e opzioni per sviluppatori

Implementazioni di dispositivi portatili (* Non applicabile ai tablet):

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

Implementazioni di dispositivi portatili (* Non applicabile ai tablet):

2.3. Requisiti della TV

Un dispositivo Android Television si riferisce a un'implementazione di un dispositivo Android che è un'interfaccia di intrattenimento per la fruizione di contenuti multimediali digitali, film, giochi, app e/o TV in diretta per gli utenti seduti a circa tre metri di distanza (un'interfaccia utente "lean back" o "a 10 piedi").

Le implementazioni di dispositivi Android sono classificate come televisioni se soddisfano tutti i seguenti criteri:

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

I requisiti aggiuntivi nel resto di questa sezione sono specifici per le implementazioni di dispositivi Android Television.

2.3.1. Hardware

Implementazioni di dispositivi TV:

  • [7.2.2/T-0-1] DEVE supportare il D-pad.
  • [7.2.3/T-0-1] DEVE fornire le funzioni Home e Indietro.
  • [7.2.3/T-0-2] DEVE inviare sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano.
  • [7.2.6.1/T-0-1] DEVE includere il supporto dei controller di gioco e dichiarare il flag di funzionalità android.hardware.gamepad.
  • [7.2.7/T] DEVE fornire un telecomando da cui gli utenti possono accedere alla navigazione non touch e agli input dei tasti di navigazione principali.

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

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

Implementazioni di dispositivi TV:

  • [7.4.3/T-0-1] DEVE supportare Bluetooth e Bluetooth LE.
  • [7.6.1/T-0-1] DEVE avere almeno 4 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione (ovvero la partizione "/data").

Se le implementazioni dei dispositivi televisivi includono una porta USB che supporta la modalità host:

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

Se le implementazioni dei dispositivi TV sono a 32 bit:

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

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

Se le implementazioni dei dispositivi TV sono a 64 bit:

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

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

Tieni presente che la "memoria disponibile per il kernel e lo spazio utente" sopra indicata si riferisce allo spazio di memoria fornito in aggiunta a qualsiasi memoria già dedicata a componenti hardware come radio, video e così via che non sono sotto il controllo del kernel nelle implementazioni del dispositivo.

Implementazioni di dispositivi TV:

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

2.3.2. Multimediale

Le implementazioni dei dispositivi televisivi DEVONO supportare i seguenti formati di codifica e decodifica audio e renderli disponibili per le applicazioni di terze parti:

  • [5.1/T-0-1] Profilo MPEG-4 AAC (AAC LC)
  • [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
  • [5.1/T-0-3] AAC ELD (enhanced low delay AAC)

Le implementazioni dei dispositivi televisivi DEVONO supportare i seguenti formati di codifica video e renderli disponibili per le applicazioni di terze parti:

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

Implementazioni di dispositivi TV:

  • [5.2.2/T-SR] Sono FORTEMENTE CONSIGLIATI per supportare la codifica H.264 di video con risoluzione 720p e 1080p a 30 fotogrammi al secondo.

Le implementazioni dei dispositivi televisivi DEVONO supportare i seguenti formati di decodifica video e renderli disponibili per le applicazioni di terze parti:

Le implementazioni dei dispositivi televisivi DEVONO supportare la decodifica MPEG-2, come descritto nella sezione 5.3.1, a frame rate video e risoluzioni standard fino a:

  • [5.3.1/T-1-1] HD 1080p a 29,97 fotogrammi al secondo con Main Profile High Level.
  • [5.3.1/T-1-2] HD 1080i a 59,94 fotogrammi al secondo con Main Profile High Level. DEVE deinterlacciare il video MPEG-2 interlacciato e renderlo disponibile alle applicazioni di terze parti.

Le implementazioni dei dispositivi televisivi DEVONO supportare la decodifica H.264, come descritto nella sezione 5.3.4, a frame rate video e risoluzioni standard fino a:

  • [5.3.4/T-1-1] HD 1080p a 60 fotogrammi al secondo con profilo di base
  • [5.3.4/T-1-2] HD 1080p a 60 fotogrammi al secondo con profilo principale
  • [5.3.4/T-1-3] HD 1080p a 60 fotogrammi al secondo con High Profile Level 4.2

Le implementazioni di dispositivi televisivi con decoder hardware H.265 DEVONO supportare la decodifica H.265, come descritto nella sezione 5.3.5, a frame rate e risoluzioni video standard fino a:

  • [5.3.5/T-1-1] HD 1080p a 60 fotogrammi al secondo con Main Profile Level 4.1

Se le implementazioni di dispositivi televisivi con decoder hardware H.265 supportano la decodifica H.265 e il profilo di decodifica UHD:

  • [5.3.5/T-2-1] DEVE supportare il profilo di decodifica UHD a 60 fotogrammi al secondo con il profilo Main10 Level 5 Main Tier.

Le implementazioni dei dispositivi televisivi DEVONO supportare la decodifica VP8, come descritto nella sezione 5.3.6, a frame rate video e risoluzioni standard fino a:

  • [5.3.6/T-1-1] Profilo di decodifica HD 1080p a 60 fotogrammi al secondo

Le implementazioni di dispositivi televisivi con decoder hardware VP9 DEVONO supportare la decodifica VP9, come descritto nella sezione 5.3.7, a frame rate video e risoluzioni standard fino a:

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

Se le implementazioni di dispositivi televisivi con decoder hardware VP9 supportano la decodifica VP9 e il profilo di decodifica UHD:

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

Implementazioni di dispositivi TV:

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

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

  • [5.8/T-0-1] DEVE impostare la modalità di uscita HDMI per selezionare la risoluzione massima supportata con una frequenza di aggiornamento di 50 Hz o 60 Hz.
  • [5.8/T-SR] È VIVAMENTE CONSIGLIATO fornire un selettore della frequenza di aggiornamento HDMI configurabile dall'utente.
  • [5.8] DEVE impostare la frequenza di aggiornamento della modalità di uscita HDMI su 50 Hz o 60 Hz, a seconda della frequenza di aggiornamento video per la regione in cui viene venduto il dispositivo.

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

  • [5.8/T-1-1] MUST support HDCP 2.2.

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

  • [5.8/T-2-1] MUST support HDCP 1.4

2.3.3. Software

Implementazioni di dispositivi TV:

  • [3/T-0-1] DEVE dichiarare le funzionalità android.software.leanback e android.hardware.type.television.
  • [3.4.1/T-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.

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

  • [3.8.10/T-1-1] DEVE mostrare le notifiche nella schermata di blocco, incluso il modello di notifica multimediale.

Implementazioni di dispositivi TV:

  • [3.8.14/T-SR] Sono FORTEMENTE CONSIGLIATE per supportare la modalità multi-finestra Picture in picture (PIP).
  • [3.10/T-0-1] DEVE supportare i servizi di accessibilità di terze parti.
  • [3.10/T-SR] È VIVAMENTE CONSIGLIATO precaricare sul dispositivo servizi di accessibilità paragonabili o superiori a Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato) come forniti nel progetto open source TalkBack.

Se le implementazioni dei dispositivi TV segnalano la funzionalità android.hardware.audio.output,

  • [3.11/T-SR] È VIVAMENTE CONSIGLIATO includere un motore TTS che supporti le lingue disponibili sul dispositivo.
  • [3.11/T-1-1] DEVE supportare l'installazione di motori di sintesi vocale di terze parti.

Implementazioni di dispositivi TV:

  • [3.12/T-0-1] DEVE supportare TV Input Framework.

2.3.4. Prestazioni e potenza

  • [8.1/T-0-1] Latenza dei frame coerente. La latenza dei frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più di 5 frame al secondo e DOVREBBE essere inferiore a 1 frame al secondo.
  • [8.2/T-0-1] DEVE garantire una velocità di scrittura sequenziale di almeno 5 MB/s.
  • [8.2/T-0-2] DEVE garantire una velocità di scrittura casuale di almeno 0,5 MB/s.
  • [8.2/T-0-3] DEVE garantire una velocità di lettura sequenziale di almeno 15 MB/s.
  • [8.2/T-0-4] DEVE garantire una velocità di lettura casuale di almeno 3,5 MB/s.

Se le implementazioni dei dispositivi televisivi includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP:

  • [8.3/T-1-1] DEVE fornire all'utente la possibilità di attivare e disattivare la funzionalità di risparmio energetico.

Se le implementazioni dei dispositivi televisivi non hanno una batteria:

Se le implementazioni di dispositivi televisivi hanno una batteria:

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

Implementazioni di dispositivi TV:

  • [8.4/T-0-1] DEVE fornire un profilo di alimentazione per componente che definisca il valore di consumo di corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto Android Open Source.
  • [8.4/T-0-2] DEVE indicare tutti i valori di consumo energetico in milliampere ora (mAh).
  • [8.4/T-0-3] DEVE segnalare il consumo energetico della CPU per ogni UID del processo. L'Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
  • [8.4/T] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo energetico del componente hardware a un'applicazione.
  • [8.4/T-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando shell adb shell dumpsys batterystats allo sviluppatore dell'app.

2.3.5. Modello di sicurezza

Implementazioni di dispositivi TV:

  • [9.11/T-0-1] DEVE eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
  • [9.11/T-0-2] DEVE avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e delle funzioni hash MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto Android Open Source Project (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti di un isolamento basato su un hypervisor appropriato sono opzioni alternative.
  • [9.11/T-0-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e solo se riuscita, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto Android Open Source Project upstream fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
  • [9.11/T-0-4] DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori di dispositivi. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, per ogni 100.000 unità potrebbe essere utilizzata una chiave diversa.

Tieni presente che se l'implementazione di un dispositivo è già stata lanciata su una versione precedente di Android, il dispositivo è esente dal requisito di disporre di un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione della chiave, a meno che non dichiari la funzionalità android.hardware.fingerprint, che richiede un keystore supportato da un ambiente di esecuzione isolato.

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

  • [9.11/T-1-1] DEVE consentire all'utente di scegliere il timeout di sospensione per la transizione dallo stato sbloccato a quello bloccato, con un timeout minimo consentito fino a 15 secondi o meno.

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

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

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

  • [9.5/T-3-1] NON DEVE supportare i profili con limitazioni, ma DEVE essere in linea con l'implementazione AOSP dei controlli per consentire /disattivare l'accesso di altri utenti alle chiamate vocali e agli SMS.

2.3.6. Compatibilità di strumenti e opzioni per sviluppatori

Implementazioni di dispositivi TV:

2.4. Requisiti dell'orologio

Un dispositivo Android Watch si riferisce a un'implementazione di un dispositivo Android destinato a essere indossato sul corpo, ad esempio al polso.

Le implementazioni di dispositivi Android sono classificate come orologi se soddisfano tutti i seguenti criteri:

  • Avere uno schermo con una lunghezza diagonale fisica compresa tra 2,8 e 6,3 cm.
  • Disporre di un meccanismo da indossare sul corpo.

I requisiti aggiuntivi nel resto di questa sezione sono specifici per le implementazioni dei dispositivi Android Watch.

2.4.1. Hardware

Guarda le implementazioni dei dispositivi:

  • [7.1.1.1/W-0-1] DEVE avere uno schermo con dimensioni diagonali fisiche comprese tra 1,1 e 2,5 pollici.

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

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

  • [7.3.1/W-SR] È VIVAMENTE CONSIGLIATO includere un accelerometro a 3 assi.

Se le implementazioni dei dispositivi Watch includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag di funzionalità android.hardware.location.gps,

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

Se le implementazioni del dispositivo Watch includono un giroscopio a 3 assi:

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

Guarda le implementazioni dei dispositivi:

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

  • [7.6.1/W-0-1] DEVE avere almeno 1 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione (ovvero la partizione "/data").

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

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

  • [7.8.2/W] POTREBBE ma NON DOVREBBE avere un output audio.

2.4.2. Multimediale

Nessun requisito aggiuntivo.

2.4.3. Software

Guarda le implementazioni dei dispositivi:

  • [3/W-0-1] DEVE dichiarare la funzionalità android.hardware.type.watch.
  • [3/W-0-2] DEVE supportare uiMode = UI_MODE_TYPE_WATCH.

Guarda le implementazioni dei dispositivi:

  • [3.8.4/W-SR] È VIVAMENTE CONSIGLIATO di implementare un assistente sul dispositivo per gestire l'azione Assist.

Guarda le implementazioni del dispositivo che dichiarano il flag della funzionalità android.hardware.audio.output:

  • [3.10/W-1-1] DEVE supportare i servizi di accessibilità di terze parti.

  • [3.10/W-SR] È FORTEMENTE CONSIGLIATO precaricare sul dispositivo servizi di accessibilità paragonabili o superiori a quelli di Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato), come forniti nel progetto open source TalkBack.

  • [3.11/W-SR] Sono FORTEMENTE CONSIGLIATI per includere un motore di sintesi vocale che supporti le lingue disponibili sul dispositivo.

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

2.4.4. Prestazioni e potenza

Se le implementazioni dei dispositivi di orologi includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP:

  • [8.3/W-SR] È VIVAMENTE CONSIGLIATO fornire agli utenti la possibilità di visualizzare tutte le app esentate dalle modalità di risparmio energetico App Standby e Doze.
  • [8.3/W-SR] Sono FORTEMENTE CONSIGLIATI per consentire all'utente di attivare e disattivare la funzionalità di risparmio energetico.

Guarda le implementazioni dei dispositivi:

  • [8.4/W-0-1] DEVE fornire un profilo di consumo per componente che definisca il valore di consumo di corrente per ogni componente hardware e l'esaurimento approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto Android Open Source.
  • [8.4/W-0-2] DEVE segnalare tutti i valori di consumo energetico in milliampere ora (mAh).
  • [8.4/W-0-3] DEVE segnalare il consumo energetico della CPU per ogni UID del processo. L'Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
  • [8.4/W-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando shell adb shell dumpsys batterystats allo sviluppatore dell'app.
  • [8.4/W] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire l'utilizzo di energia del componente hardware a un'applicazione.

2.4.5. Modello di sicurezza

Se le implementazioni dei dispositivi Wearable includono più utenti e non dichiarano il flag di funzionalità android.hardware.telephony:

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

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

  • [9.5/W-2-1] NON DEVE supportare i profili con limitazioni, ma DEVE essere in linea con l'implementazione AOSP dei controlli per consentire /disattivare l'accesso di altri utenti alle chiamate vocali e agli SMS.

2.5. Requisiti per il settore automobilistico

L'implementazione di Android Automotive si riferisce a un'unità principale del veicolo che esegue Android come sistema operativo per parte o per l'intero sistema e/o per la funzionalità di infotainment.

Le implementazioni di dispositivi Android sono classificate come Automotive se dichiarano la funzionalità android.hardware.type.automotive o soddisfano tutti i seguenti criteri.

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

I requisiti aggiuntivi nel resto di questa sezione sono specifici per le implementazioni di dispositivi Android Automotive.

2.5.1. Hardware

Implementazioni di dispositivi per il settore automotive:

  • [7.1.1.1/A-0-1] DEVE avere uno schermo di almeno 6 pollici di dimensione diagonale fisica.

  • [7.1.1.1/A-0-2] DEVE avere un layout delle dimensioni dello schermo di almeno 750 dp x 480 dp.

  • [7.2.3/A-0-1] DEVE fornire la funzione Home e PUÒ fornire le funzioni Indietro e Recenti.

  • [7.2.3/A-0-2] DEVE inviare sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano.
  • [7.3/A-0-1] DEVE implementare e segnalare GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED e PARKING_BRAKE_ON.
  • [7.3/A-0-2] Il valore del flag NIGHT_MODE DEVE essere coerente con la modalità giorno/notte del cruscotto e DOVREBBE basarsi sull'input del sensore di luce ambientale. Il sensore di luce ambientale sottostante POTREBBE essere lo stesso del fotometro.
  • [7.3/A-0-3] DEVE fornire il campo di informazioni aggiuntive del sensore TYPE_SENSOR_PLACEMENT come parte di SensorAdditionalInfo per ogni sensore fornito.
  • [7.3/A-0-1] PUÒ stimare la posizione combinando GPS/GNSS con sensori aggiuntivi. Se la posizione è stimata, è VIVAMENTE CONSIGLIATO implementare e segnalare i tipi di sensore e/o gli ID proprietà veicolo corrispondenti utilizzati.
  • [7.3/A-0-2] La posizione richiesta tramite LocationManager#requestLocationUpdates() NON DEVE essere associata alla mappa.

Se le implementazioni di dispositivi per il settore automobilistico includono un accelerometro a 3 assi:

Se le implementazioni dei dispositivi per il settore automobilistico includono un giroscopio a 3 assi:

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

Implementazioni di dispositivi per il settore automotive:

  • [7.4.3/A-0-1] DEVE supportare il Bluetooth e DOVREBBE supportare Bluetooth LE.

  • [7.4.3/A-0-2] Le implementazioni di Android Automotive DEVONO supportare i seguenti profili Bluetooth:

    • Chiamate telefoniche tramite il profilo Hands-Free (HFP).
    • Riproduzione di contenuti multimediali tramite il profilo di distribuzione audio (A2DP).
    • Controllo della riproduzione multimediale tramite il profilo controllo remoto (AVRCP).
    • Condivisione dei contatti tramite il profilo di accesso alla rubrica (PBAP).

  • [7.4.3/A-SR] È VIVAMENTE CONSIGLIATO di supportare il profilo di accesso ai messaggi (MAP).

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

  • [7.4.5/A] PUÒ utilizzare la costante NetworkCapabilities#NET_CAPABILITY_OEM_PAID dell'API di sistema per le reti disponibili per le app di sistema.

Una videocamera con visuale esterna è una videocamera che riprende scene al di fuori dell'implementazione del dispositivo, come una dashcam.

Implementazioni di dispositivi per il settore automotive:

  • DEVE includere una o più videocamere con vista esterna.

Se le implementazioni di dispositivi per il settore automobilistico includono una videocamera con visuale esterna, per questa videocamera:

  • [7.5/A-1-1] NON devono avere telecamere con visuale esterna accessibili tramite le API Android Camera, a meno che non rispettino i requisiti di base della fotocamera.
  • [7.5/A-SR] È FORTEMENTE CONSIGLIATO di non ruotare o eseguire il mirroring orizzontale dell'anteprima della videocamera.
  • [7.5.5/A-SR] È VIVAMENTE CONSIGLIATO di orientare la videocamera in modo che la dimensione più lunga sia allineata all'orizzonte.
  • [7.5/A-SR] Sono FORTEMENTE CONSIGLIATE con una risoluzione di almeno 1,3 megapixel.
  • DEVE avere un hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
  • POTREBBE avere la messa a fuoco automatica hardware o software implementata nel driver della videocamera.

Implementazioni di dispositivi per il settore automotive:

  • [7.6.1/A-0-1] DEVE avere almeno 4 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione (ovvero la partizione "/data").

  • [7.6.1/A] DEVE formattare la partizione dei dati per offrire prestazioni e durata migliori sull'archiviazione flash, ad esempio utilizzando il file system f2fs.

Se le implementazioni di dispositivi per il settore automobilistico forniscono spazio di archiviazione esterno condiviso tramite una parte dello spazio di archiviazione interno non rimovibile:

  • [7.6.1/A-SR] Sono FORTEMENTE CONSIGLIATE per ridurre l'overhead di I/O sulle operazioni eseguite sullo spazio di archiviazione esterno, ad esempio utilizzando SDCardFS.

Se le implementazioni dei dispositivi per il settore automobilistico sono a 32 bit:

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

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

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

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

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

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

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

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

Se le implementazioni dei dispositivi per il settore automobilistico sono a 64 bit:

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

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

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

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

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

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

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

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

Tieni presente che la "memoria disponibile per il kernel e lo spazio utente" sopra indicata si riferisce allo spazio di memoria fornito in aggiunta a qualsiasi memoria già dedicata a componenti hardware come radio, video e così via che non sono sotto il controllo del kernel nelle implementazioni del dispositivo.

Implementazioni di dispositivi per il settore automotive:

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

Implementazioni di dispositivi per il settore automotive:

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

Implementazioni di dispositivi per il settore automotive:

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

2.5.2. Multimediale

Le implementazioni dei dispositivi per auto DEVONO supportare i seguenti formati di codifica e decodifica audio e renderli disponibili per le applicazioni di terze parti:

  • [5.1/A-0-1] Profilo MPEG-4 AAC (AAC LC)
  • [5.1/A-0-2] Profilo MPEG-4 HE AAC (AAC+)
  • [5.1/A-0-3] AAC ELD (enhanced low delay AAC)

Le implementazioni di dispositivi per auto DEVONO supportare i seguenti formati di codifica video e renderli disponibili per le applicazioni di terze parti:

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

Le implementazioni di dispositivi per auto DEVONO supportare i seguenti formati di decodifica video e renderli disponibili per le applicazioni di terze parti:

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

È VIVAMENTE CONSIGLIATO che le implementazioni dei dispositivi per il settore auto e motori supportino la seguente decodifica video:

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

2.5.3. Software

Implementazioni di dispositivi per il settore automotive:

Se le implementazioni dei dispositivi per auto includono un pulsante Push-to-talk:

  • [3.8.4/A-1-1] DEVE utilizzare una pressione breve del pulsante Push to Talk come interazione designata per avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService.

Implementazioni di dispositivi per il settore automotive:

  • [3.8.3.1/A-0-1] DEVE eseguire il rendering corretto delle risorse come descritto nella documentazione dell'SDK Notifications on Automotive OS.
  • [3.8.3.1/A-0-2] MUST display PLAY and MUTE for notification actions in the place of those provided through Notification.Builder.addAction()
  • [3.8.3.1/A] DOVREBBE limitare l'utilizzo di attività di gestione avanzate, come i controlli per canale di notifica. PUÒ utilizzare l'affordance della UI per applicazione per ridurre i controlli.

Implementazioni di dispositivi per il settore automotive:

Se le implementazioni dei dispositivi per il settore automobilistico includono un'app di avvio predefinita:

Implementazioni di dispositivi per il settore automotive:

2.5.4. Prestazioni e potenza

Implementazioni di dispositivi per il settore automotive:

  • [8.2/A-0-1] DEVE segnalare il numero di byte letti e scritti nell'archiviazione non volatile per ogni UID del processo, in modo che le statistiche siano disponibili per gli sviluppatori tramite l'API di sistema android.car.storagemonitoring.CarStorageMonitoringManager. Android Open Source Project soddisfa il requisito tramite il modulo kernel uid_sys_stats.
  • [8.3/A-1-3] DEVE attivare la modalità Garage almeno una volta prima che l'auto venga spenta.
  • [8.3/A-1-4] DEVE essere in modalità Garage per almeno 15 minuti, a meno che:
    • La batteria è scarica.
    • Nessun job inattivo è pianificato.
    • Il conducente esce dalla modalità Garage.
  • [8.4/A-0-1] DEVE fornire un profilo di consumo energetico per componente che definisca il valore di consumo di corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto Android Open Source.
  • [8.4/A-0-2] DEVE segnalare tutti i valori di consumo energetico in milliampere ora (mAh).
  • [8.4/A-0-3] DEVE segnalare il consumo energetico della CPU per ogni UID del processo. L'Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
  • [8.4/A] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo energetico del componente hardware a un'applicazione.
  • [8.4/A-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando shell adb shell dumpsys batterystats allo sviluppatore dell'app.

2.5.5. Modello di sicurezza

Se le implementazioni dei dispositivi per il settore automobilistico supportano più utenti:

Implementazioni di dispositivi per il settore automotive:

  • [9.11/A-0-1] DEVE eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
  • [9.11/A-0-2] DEVE avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e delle funzioni hash MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto Android Open Source Project (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti di un isolamento basato su un hypervisor appropriato sono opzioni alternative.
  • [9.11/A-0-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto Android Open Source Project upstream fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
  • [9.11/A-0-4] DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori di dispositivi. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, per ogni 100.000 unità potrebbe essere utilizzata una chiave diversa.

Tieni presente che se l'implementazione di un dispositivo è già stata lanciata su una versione precedente di Android, il dispositivo è esente dal requisito di disporre di un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione della chiave, a meno che non dichiari la funzionalità android.hardware.fingerprint, che richiede un keystore supportato da un ambiente di esecuzione isolato.

Se le implementazioni dei dispositivi per il settore automobilistico supportano una schermata di blocco sicura:

  • [9.11/A-1-1] DEVE consentire all'utente di scegliere il timeout di sospensione per la transizione dallo stato sbloccato a quello bloccato, con un timeout minimo consentito fino a 15 secondi o meno.

Implementazioni di dispositivi per il settore automotive:

  • [9.14/A-0-1] MUST gatekeep messages from Android framework vehicle subsystems, e.g., allowlisting permitted message types and message sources.
  • [9.14/A-0-2] DEVE proteggere dagli attacchi Denial of Service dal framework Android o da app di terze parti. In questo modo si evita che software dannosi inondino la rete del veicolo di traffico, il che potrebbe portare a un malfunzionamento dei sottosistemi del veicolo.

2.5.6. Compatibilità di strumenti e opzioni per sviluppatori

Implementazioni di dispositivi per il settore automotive:

2.6. Requisiti per tablet

Un tablet Android è un'implementazione di un dispositivo Android che soddisfa tutti i seguenti criteri:

  • Generalmente utilizzato tenendolo con entrambe le mani.
  • Non ha una configurazione a conchiglia o convertibile.
  • Qualsiasi implementazione di tastiera fisica utilizzata con il dispositivo DEVE connettersi tramite una connessione standard.
  • Ha una fonte di alimentazione che fornisce mobilità, ad esempio una batteria.
  • Ha una dimensione dello schermo diagonale fisica compresa tra 7 e 18 pollici.

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

2.6.1. Hardware

Dimensioni schermo

  • [7.1.1.1/Tab-0-1] DEVE avere uno schermo compreso tra 7 e 18 pollici.

Giroscopio

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

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

Memoria e spazio di archiviazione minimi (sezione 7.6.1)

Le densità dello schermo elencate per gli schermi piccoli/normali nei requisiti per i dispositivi portatili non sono applicabili ai tablet.

Modalità periferica USB (Sezione 7.7.1)

Se le implementazioni dei dispositivi tablet includono una porta USB che supporta la modalità periferica:

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

Modalità di realtà virtuale (sezione 7.9.1)

Virtual Reality High Performance (Sezione 7.9.2)

I requisiti di realtà virtuale non sono applicabili ai tablet.

2.6.2. Modello di sicurezza

Chiavi e credenziali (sezione 9.11)

Fai riferimento alla sezione [9.11].

Se le implementazioni dei dispositivi tablet includono più utenti e non dichiarano il flag di funzionalità android.hardware.telephony,

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

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

  • [9.5/T-2-1] NON DEVE supportare i profili con limitazioni, ma DEVE essere in linea con l'implementazione AOSP dei controlli per consentire /disattivare l'accesso di altri utenti alle chiamate vocali e agli SMS.

3. Software

3.1. Compatibilità delle API gestite

L'ambiente di esecuzione del bytecode Dalvik gestito è il veicolo principale per le applicazioni Android. L'interfaccia di programmazione di un'applicazione (API) Android è l'insieme di interfacce della piattaforma Android esposte alle applicazioni in esecuzione nell'ambiente di runtime gestito.

Implementazioni del dispositivo:

  • [C-0-1] DEVE fornire implementazioni complete, inclusi tutti i comportamenti documentati, di qualsiasi API documentata esposta dall'SDK Android o di qualsiasi API decorata con il marcatore "@SystemApi" nel codice sorgente Android upstream.

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

  • [C-0-3] NON DEVE omettere alcuna API gestita, alterare interfacce o firme API, discostarsi dal comportamento documentato o includere no-op, tranne nei casi specificamente consentiti da questa definizione di compatibilità.

  • [C-0-4] DEVE comunque mantenere le API presenti e comportarsi in modo ragionevole, anche quando vengono omesse alcune funzionalità hardware per le quali Android include API. Per i requisiti specifici per questo scenario, consulta la sezione 7.

  • [C-0-5] NON DEVE consentire ad app di terze parti di utilizzare interfacce non SDK, definite come metodi e campi nei pacchetti di linguaggio Java che si trovano nel boot classpath in AOSP e che non fanno parte dell'SDK pubblico. Sono incluse le API decorate con l'annotazione @hide, ma non con @SystemAPI, come descritto nei documenti SDK e nei membri delle classi privati e privati del pacchetto.

  • [C-0-6] MUST ship with each and every non-SDK interface on the same restricted lists as provided via the provisional list and denylist flags in prebuilts/runtime/appcompat/hiddenapi-flags.csv path for the appropriate API level branch in the AOSP.

    Tuttavia:

    • MAY, se un'API nascosta è assente o implementata in modo diverso nell'implementazione del dispositivo, sposta l'API nascosta nella lista nera o omettila da tutti gli elenchi con limitazioni.
    • MAGGIO: se un'API nascosta non esiste già in AOSP, aggiungila a uno degli elenchi con limitazioni.

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

3.1.1. Estensioni Android

Android include il supporto dell'estensione delle API gestite mantenendo la stessa versione del livello API.

  • [C-0-1] Le implementazioni dei dispositivi Android DEVONO precaricare l'implementazione AOSP sia della libreria condivisa ExtShared sia dei servizi ExtServices con versioni superiori o uguali alle versioni minime consentite per ogni livello API. Ad esempio, le implementazioni di dispositivi Android 7.0 che eseguono il livello API 24 DEVONO includere almeno la versione 1.

3.1.2. Libreria Android

A causa del ritiro del client HTTP Apache, le implementazioni del dispositivo:

  • [C-0-1] NON DEVE inserire la libreria org.apache.http.legacy nel bootclasspath.
  • [C-0-2] DEVE aggiungere la libreria org.apache.http.legacy al classpath dell'applicazione solo quando l'app soddisfa una delle seguenti condizioni:
    • Ha come target il livello API 28 o inferiore.
    • Dichiara nel manifest che ha bisogno della libreria impostando l'attributo android:name di <uses-library> su org.apache.http.legacy.

L'implementazione AOSP soddisfa questi requisiti.

3.2. Compatibilità API soft

Oltre alle API gestite della sezione 3.1, Android include anche un'API "soft" significativa solo in fase di runtime, sotto forma di intent, autorizzazioni e aspetti simili delle applicazioni Android che non possono essere applicati in fase di compilazione dell'applicazione.

3.2.1. Autorizzazioni

  • [C-0-1] Gli implementatori di dispositivi DEVONO supportare e applicare tutte le costanti di autorizzazione come documentato nella pagina di riferimento delle autorizzazioni. Tieni presente che la sezione 9 elenca requisiti aggiuntivi relativi al modello di sicurezza di Android.

3.2.2. Parametri di creazione

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

  • [C-0-1] Per fornire valori coerenti e significativi nelle implementazioni dei dispositivi, la tabella seguente include ulteriori limitazioni sui formati di questi valori a cui le implementazioni dei dispositivi DEVONO conformarsi.
Parametro Dettagli
VERSIONE.RELEASE La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE contenere uno dei valori stringa definiti in 10.
VERSION.SDK La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 10, questo campo DEVE avere il valore intero 10_INT.
VERSION.SDK_INT La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 10, questo campo DEVE avere il valore intero 10_INT.
VERSION.INCREMENTAL Un valore scelto dall'implementatore del dispositivo che indica la build specifica del sistema Android attualmente in esecuzione, in formato leggibile. Questo valore NON DEVE essere riutilizzato per build diverse rese disponibili agli utenti finali. Un utilizzo tipico di questo campo è indicare il numero di build o l'identificatore di modifica del controllo del codice sorgente utilizzato per generare la build. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit stampabile e corrispondere all'espressione regolare "^[^ :\/~]+$".
DA TAVOLO Un valore scelto dall'implementatore del dispositivo che identifica l'hardware interno specifico utilizzato dal dispositivo, in formato leggibile. Un possibile utilizzo di questo campo è indicare la revisione specifica della scheda che alimenta il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
BRAND Un valore che riflette il nome del brand associato al dispositivo noto agli utenti finali. DEVE essere in un formato leggibile e DOVREBBE rappresentare il produttore del dispositivo o il brand dell'azienda con cui viene commercializzato il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità dell'API nativa.
SUPPORTED_32_BIT_ABIS Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità dell'API nativa.
SUPPORTED_64_BIT_ABIS Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità dell'API nativa.
CPU_ABI Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità dell'API nativa.
CPU_ABI2 Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità dell'API nativa.
DISPOSITIVO Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice che identifica la configurazione delle funzionalità hardware e del design industriale del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Il nome del dispositivo NON DEVE cambiare durante il ciclo di vita del prodotto.
FINGERPRINT Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile. DEVE seguire questo modello:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Ad esempio:

acme/myproduct/
    mydevice:10/LMYXX/3359:userdebug/test-keys

L'impronta NON DEVE includere spazi vuoti. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit.

HARDWARE Il nome dell'hardware (dalla riga di comando del kernel o da /proc). DEVE essere ragionevolmente leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
HOST Una stringa che identifica in modo univoco l'host su cui è stata creata la build, in formato leggibile. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota ("").
ID Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in formato leggibile. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DOVREBBE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere tra le build software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
PRODUTTORE Il nome commerciale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota (""). Questo campo NON deve cambiare durante il ciclo di vita del prodotto.
MODELLO Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo noto all'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota (""). Questo campo NON deve cambiare durante il ciclo di vita del prodotto.
PRODOTTO Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice del prodotto (SKU) specifico che DEVE essere univoco all'interno dello stesso brand. DEVE essere leggibile, ma non è necessariamente destinato alla visualizzazione da parte degli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Il nome del prodotto NON DEVE cambiare durante il ciclo di vita del prodotto.
SERIAL DEVE restituire "UNKNOWN".
TAG Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che distinguono ulteriormente la build. I tag DEVONO essere codificabili come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+" e DEVONO avere uno dei valori corrispondenti alle tre configurazioni di firma tipiche della piattaforma Android: release-keys, dev-keys e test-keys.
DURATA Un valore che rappresenta il timestamp della build.
MACCHINA Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni tipiche di Android Runtime: user, userdebug o eng.
UTENTE Un nome o un ID utente dell'utente (o utente automatico) che ha generato la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota ("").
SECURITY_PATCH Un valore che indica il livello patch di sicurezza di una build. DEVE indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti nel Bollettino pubblico sulla sicurezza di Android designato. Deve essere nel formato [AAAA-MM-GG], corrispondente a una stringa definita documentata nel Bollettino pubblico sulla sicurezza di Android o nell'Android Security Advisory, ad esempio "2015-11-01".
BASE_OS Un valore che rappresenta il parametro FINGERPRINT della build che è altrimenti identica a questa build, ad eccezione delle patch fornite nel bollettino sulla sicurezza pubblica di Android. DEVE segnalare il valore corretto e, se tale build non esiste, segnalare una stringa vuota ("").
BOOTLOADER Un valore scelto dall'implementatore del dispositivo che identifica la versione specifica del bootloader interno utilizzata nel dispositivo, in formato leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
getRadioVersion() DEVE (essere o restituire) un valore scelto dall'implementatore del dispositivo che identifica la versione specifica della radio/del modem interno utilizzata nel dispositivo, in un formato leggibile. Se un dispositivo non ha alcuna radio/modem interno, DEVE restituire NULL. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-,]+$".
getSerial() DEVE (essere o restituire) un numero di serie hardware, che DEVE essere disponibile e univoco su tutti i dispositivi con lo stesso MODELLO e PRODUTTORE. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-,]+$".

3.2.3. Compatibilità degli intent

3.2.3.1. Intent applicazione principale

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

  • [C-0-1] Le implementazioni del dispositivo DEVONO precaricare uno o più componenti di applicazioni o servizi con un gestore di intent, per tutti i pattern di filtri per intent pubblici definiti dalle seguenti applicazioni Android di base in AOSP:

    • Orologio da scrivania
    • Browser
    • Calendar
    • Contatti
    • Galleria
    • GlobalSearch
    • Avvio app
    • Musica
    • Impostazioni
3.2.3.2. Risoluzione dell'intent

  • [C-0-1] Poiché Android è una piattaforma estensibile, le implementazioni dei dispositivi DEVONO consentire l'override di ogni pattern di intent a cui viene fatto riferimento nella sezione 3.2.3.1 , ad eccezione delle Impostazioni, da parte di applicazioni di terze parti. L'implementazione open source di Android upstream lo consente per impostazione predefinita.

  • [C-0-2] Gli implementatori di dispositivi NON DEVONO assegnare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema né impedire alle applicazioni di terze parti di eseguire il binding e assumere il controllo di questi pattern. Questo divieto include in particolare, a titolo esemplificativo, la disattivazione dell'interfaccia utente "Chooser", che consente all'utente di scegliere tra più applicazioni che gestiscono tutte lo stesso pattern di intent.

  • [C-0-3] Le implementazioni dei dispositivi DEVONO fornire un'interfaccia utente per consentire agli utenti di modificare l'attività predefinita per gli intent.

  • Tuttavia, le implementazioni del dispositivo POSSONO fornire attività predefinite per pattern URI specifici (ad es. http://play.google.com) quando l'attività predefinita fornisce un attributo più specifico per l'URI dei dati. Ad esempio, un pattern di filtro per intent che specifica l'URI dati "http://www.android.com" è più specifico del pattern di intent principale del browser per "http://".

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

  • [C-0-4] DEVE tentare di convalidare tutti i filtri per intent eseguendo i passaggi di convalida definiti nella specifica Digital Asset Links implementata da Package Manager nel progetto Android Open Source upstream.
  • [C-0-5] DEVE tentare la convalida dei filtri di intent durante l'installazione dell'applicazione e impostare tutti i filtri di intent URI convalidati correttamente come gestori di app predefiniti per i relativi URI.
  • PUÒ impostare filtri di intent URI specifici come gestori di app predefiniti per i propri URI, se vengono verificati correttamente, ma altri filtri URI candidati non superano la verifica. Se l'implementazione di un dispositivo lo fa, DEVE fornire all'utente override di pattern per URI appropriati nel menu delle impostazioni.
  • DEVE fornire all'utente controlli dei link dell'app per app in Impostazioni come segue:
    • [C-0-6] L'utente DEVE essere in grado di ignorare in modo olistico il comportamento predefinito dei link per app per un'app: sempre aperta, sempre richiesta o mai aperta, che DEVE essere applicato a tutti i filtri per intent URI candidati in egual misura.
    • [C-0-7] L'utente DEVE essere in grado di visualizzare un elenco dei filtri per intent URI candidati.
    • L'implementazione del dispositivo PUÒ fornire all'utente la possibilità di ignorare filtri per intent URI candidati specifici verificati correttamente, in base al filtro per intent.
    • [C-0-8] L'implementazione del dispositivo DEVE consentire agli utenti di visualizzare e ignorare filtri di intent URI candidati specifici se l'implementazione del dispositivo consente la verifica di alcuni filtri di intent URI candidati, mentre altri possono non riuscire.
3.2.3.3. Spazi dei nomi degli intent
  • [C-0-1] Le implementazioni dei dispositivi NON DEVONO includere componenti Android che rispettino nuovi pattern di intent o intent di trasmissione utilizzando un'AZIONE, una CATEGORIA o un'altra stringa chiave nello spazio dei nomi android. o com.android..
  • [C-0-2] Gli implementatori di dispositivi NON DEVONO includere componenti Android che rispettino nuovi intent o pattern di intent di trasmissione utilizzando una stringa ACTION, CATEGORY o un'altra stringa chiave in uno spazio di pacchetti appartenente a un'altra organizzazione.
  • [C-0-3] Gli implementatori di dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent utilizzati dalle app principali elencate nella sezione 3.2.3.1.
  • Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano spazi dei nomi chiaramente e ovviamente associati alla propria organizzazione. Questo divieto è analogo a quello specificato per le classi di linguaggio Java nella sezione 3.6.
3.2.3.4. Intent di trasmissione

Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent per notificare loro le modifiche all'ambiente hardware o software.

Implementazioni del dispositivo:

  • [C-0-1] DEVE trasmettere gli intent di trasmissione pubblica in risposta agli eventi di sistema appropriati, come descritto nella documentazione dell'SDK. Tieni presente che questo requisito non è in conflitto con la sezione 3.5, in quanto la limitazione per le applicazioni in background è descritta anche nella documentazione dell'SDK.
3.2.3.5. Impostazioni app predefinite

Android include impostazioni che offrono agli utenti un modo semplice per selezionare le applicazioni predefinite, ad esempio per la schermata Home o gli SMS.

Ove opportuno, le implementazioni del dispositivo DEVONO fornire un menu delle impostazioni simile ed essere compatibili con il pattern del filtro per intent e i metodi API descritti nella documentazione dell'SDK come indicato di seguito.

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

Se le implementazioni dei dispositivi segnalano android.hardware.telephony:

  • [C-2-1] DEVE fornire un menu delle impostazioni che richiami l'intent RoleManager.createRequestRoleIntent(String) con RoleManager.ROLE_SMS per mostrare una finestra di dialogo per cambiare l'applicazione SMS predefinita.

  • [C-2-2] DEVE rispettare l'intent android.telecom.action.CHANGE_DEFAULT_DIALER di mostrare una finestra di dialogo per consentire all'utente di modificare l'applicazione Telefono predefinita.

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

  • [C-2-3] DEVE rispettare l'intent android.telecom.action.CHANGE_PHONE_ACCOUNTS per fornire all'utente la possibilità di configurare ConnectionServices associato a PhoneAccounts, nonché un PhoneAccount predefinito che il fornitore di servizi di telecomunicazioni utilizzerà per effettuare chiamate in uscita. L'implementazione AOSP soddisfa questo requisito includendo un menu "Opzione Account chiamate" nel menu delle impostazioni "Chiamate".

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

  • [C-2-5] DEVE fornire all'utente la possibilità di scegliere un'app che detiene il ruolo android.app.role.CALL_REDIRECTION.

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

Se le implementazioni dei dispositivi supportano VoiceInteractionService e hanno installato più di un'applicazione che utilizza questa API contemporaneamente:

3.2.4. Attività su display secondari/multipli

Se le implementazioni dei dispositivi consentono l'avvio di attività Android normali su più di un display:

  • [C-1-1] DEVE impostare il flag funzionalità android.software.activities_on_secondary_displays.
  • [C-1-2] DEVE garantire la compatibilità dell'API in modo simile a un'attività in esecuzione sul display principale.
  • [C-1-3] DEVE visualizzare la nuova attività sullo stesso display dell'attività che l'ha avviata, quando la nuova attività viene avviata senza specificare un display di destinazione tramite l'API ActivityOptions.setLaunchDisplayId().
  • [C-1-4] DEVE distruggere tutte le attività quando viene rimosso un display con il flag Display.FLAG_PRIVATE.
  • [C-1-5] DEVE nascondere in modo sicuro i contenuti su tutte le schermate quando il dispositivo è bloccato con una schermata di blocco sicura, a meno che l'app non scelga di mostrare i contenuti sopra la schermata di blocco utilizzando l'API Activity#setShowWhenLocked().
  • DEVE avere android.content.res.Configuration corrispondente a quel display per essere visualizzata, funzionare correttamente e mantenere la compatibilità se un'attività viene avviata sul display secondario.

Se le implementazioni del dispositivo consentono l'avvio di attività Android normali su display secondari e un display secondario ha il flag android.view.Display.FLAG_PRIVATE:

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

3.3. Compatibilità delle API native

La compatibilità del codice nativo è difficile. Per questo motivo, gli implementatori di dispositivi:

  • [SR] VIVAMENTE CONSIGLIATO di utilizzare le implementazioni delle librerie elencate di seguito dal progetto open source Android upstream.

3.3.1. Application Binary Interfaces

Il bytecode Dalvik gestito può chiamare il codice nativo fornito nel file .apk dell'applicazione come file ELF .so compilato per l'architettura hardware del dispositivo appropriata. Poiché il codice nativo dipende molto dalla tecnologia del processore sottostante, Android definisce una serie di interfacce Application Binary Interface (ABI) nell'NDK Android.

Implementazioni del dispositivo:

  • [C-0-1] DEVE essere compatibile con una o più ABI definite e implementare la compatibilità con l'NDK Android.
  • [C-0-2] DEVE includere il supporto per il codice in esecuzione nell'ambiente gestito per chiamare il codice nativo, utilizzando la semantica standard di Java Native Interface (JNI).
  • [C-0-3] DEVE essere compatibile a livello di codice sorgente (ovvero compatibile con l'intestazione) e a livello binario (per l'ABI) con ogni libreria richiesta nell'elenco riportato di seguito.
  • [C-0-5] DEVE segnalare con precisione l'Application Binary Interface (ABI) nativa supportata dal dispositivo tramite i parametri android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, ognuno dei quali è un elenco di ABI separati da virgole e ordinati dalla più preferita alla meno preferita.

  • [C-0-6] DEVE segnalare, tramite i parametri sopra indicati, un sottoinsieme del seguente elenco di ABI e NON DEVE segnalare ABI non presenti nell'elenco.

    • armeabi
    • armeabi-v7a
    • arm64-v8a
    • x86
    • x86-64

    • [C-0-7] DEVE rendere disponibili alle app che includono codice nativo tutte le seguenti librerie, che forniscono API native:

    • libaaudio.so (supporto audio nativo AAudio)

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

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

  • [C-0-9] DEVE elencare le librerie non AOSP aggiuntive esposte direttamente alle app di terze parti in /vendor/etc/public.libraries.txt.
  • [C-0-10] NON DEVE esporre altre librerie native, implementate e fornite in AOSP come librerie di sistema, ad app di terze parti che hanno come target il livello API 24 o versioni successive, in quanto sono riservate.
  • [C-0-11] DEVE esportare tutti i simboli di funzione OpenGL ES 3.1 e Android Extension Pack, come definiti nell'NDK, tramite la libreria libGLESv3.so. Tieni presente che, sebbene tutti i simboli DEBBANO essere presenti, la sezione 7.1.4.1 descrive in modo più dettagliato i requisiti per quando è prevista l'implementazione completa di ciascuna funzione corrispondente.
  • [C-0-12] MUST export function symbols for the core Vulkan 1.0 function symbols, as well as the VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, and VK_KHR_get_physical_device_properties2 extensions through the libvulkan.so library. Tieni presente che, sebbene tutti i simboli DEBBANO essere presenti, la sezione 7.1.4.2 descrive in modo più dettagliato i requisiti per quando è prevista l'implementazione completa di ciascuna funzione corrispondente.
  • DEVE essere creato utilizzando il codice sorgente e i file di intestazione disponibili nel progetto open source Android upstream

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

3.3.2. Compatibilità del codice nativo ARM a 32 bit

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

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

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

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

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

  • [C-2-2] DEVE sempre mantenere disponibili le seguenti operazioni, anche nel caso in cui l'ABI sia implementata su un'architettura ARMv8, tramite il supporto della CPU nativa o l'emulazione software:

    • Istruzioni per SWP e SWPB.
    • Istruzione SETEND.
    • Operazioni di barriera CP15ISB, CP15DSB e CP15DMB.

  • [C-2-3] DEVE includere il supporto dell'estensione Advanced SIMD (nota anche come NEON).

3.4. Compatibilità web

3.4.1. Compatibilità di WebView

Se le implementazioni del dispositivo forniscono un'implementazione completa dell'API android.webkit.Webview:

  • [C-1-1] MUST report android.software.webview.
  • [C-1-2] DEVE utilizzare la build del progetto Chromium dal progetto open source Android upstream sul ramo Android 10 per l'implementazione dell'API android.webkit.WebView.

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

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • Il valore della stringa $(VERSION) DEVE essere uguale al valore di android.os.Build.VERSION.RELEASE.
    • La stringa $(MODEL) PUÒ essere vuota, ma se non lo è DEVE avere lo stesso valore di android.os.Build.MODEL.
    • "Build/$(BUILD)" PUÒ essere omesso, ma se è presente la stringa $(BUILD) DEVE essere uguale al valore di android.os.Build.ID.
    • Il valore della stringa $(CHROMIUM_VER) DEVE essere la versione di Chromium nel progetto open source Android upstream.
    • Le implementazioni dei dispositivi POSSONO omettere Mobile nella stringa dello user agent.

  • Il componente WebView DEVE includere il supporto per il maggior numero possibile di funzionalità HTML5 e, se supporta la funzionalità, DEVE essere conforme alla specifica HTML5.

  • [C-1-4] DEVE eseguire il rendering dei contenuti forniti o dei contenuti dell'URL remoto in un processo distinto dall'applicazione che crea l'istanza di WebView. In particolare, il processo di rendering separato DEVE avere privilegi inferiori, essere eseguito come ID utente separato, non avere accesso alla directory dei dati dell'app, non avere accesso diretto alla rete e avere accesso solo ai servizi di sistema minimi richiesti tramite Binder. L'implementazione AOSP di WebView soddisfa questo requisito.

Tieni presente che se le implementazioni del dispositivo sono a 32 bit o dichiarano il flag funzionalità android.hardware.ram.low, sono esenti da C-1-3.

3.4.2. Compatibilità del browser

Se le implementazioni dei dispositivi includono un'applicazione browser autonoma per la navigazione web generale:

  • [C-1-1] DEVE supportare ciascuna di queste API associate a HTML5:
  • [C-1-2] DEVE supportare l'API webstorage HTML5/W3C e DOVREBBE supportare l'API IndexedDB HTML5/W3C. Tieni presente che, poiché gli enti di standardizzazione dello sviluppo web stanno passando a IndexedDB rispetto a webstorage, è previsto che IndexedDB diventi un componente obbligatorio in una versione futura di Android.
  • POTREBBE spedire una stringa user agent personalizzata nell'applicazione Browser autonoma.
  • DEVE implementare il supporto per la maggior parte possibile di HTML5 nell'applicazione browser autonoma (basata sull'applicazione browser WebKit upstream o su una sostituzione di terze parti).

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

  • [C-2-1] DEVE comunque supportare i pattern di intent pubblici descritti nella sezione 3.2.3.1.

3.5. Compatibilità comportamentale delle API

Implementazioni del dispositivo:

  • [C-0-9] DEVE garantire che la compatibilità comportamentale dell'API venga applicata a tutte le app installate, a meno che non siano soggette a limitazioni come descritto nella Sezione 3.5.1.
  • [C-0-10] NON DEVE implementare l'approccio di allowlisting che garantisce la compatibilità comportamentale dell'API solo per le app selezionate dagli implementatori di dispositivi.

I comportamenti di ciascun tipo di API (gestita, soft, nativa e web) DEVONO essere coerenti con l'implementazione preferita del progetto Android Open Source upstream. Alcune aree specifiche di compatibilità sono:

  • [C-0-1] I dispositivi NON DEVONO modificare il comportamento o la semantica di un intent standard.
  • [C-0-2] I dispositivi NON DEVONO alterare il ciclo di vita o la semantica del ciclo di vita di un particolare tipo di componente di sistema (ad esempio Service, Activity, ContentProvider e così via).
  • [C-0-3] I dispositivi NON DEVONO modificare la semantica di un'autorizzazione standard.
  • I dispositivi NON DEVONO alterare le limitazioni imposte alle applicazioni in background. Più nello specifico, per le app in background:
    • [C-0-4] DEVE interrompere l'esecuzione dei callback registrati dall'app per ricevere gli output da GnssMeasurement e GnssNavigationMessage.
    • [C-0-5] DEVONO limitare la frequenza degli aggiornamenti forniti all'app tramite la classe API LocationManager o il metodo WifiManager.startScan().
    • [C-0-6] Se l'app ha come target il livello API 25 o versioni successive, NON DEVE consentire la registrazione di ricevitori di trasmissioni per le trasmissioni implicite di intent standard di Android nel manifest dell'app, a meno che l'intent di trasmissione non richieda un'autorizzazione "signature" o "signatureOrSystem" protectionLevel o si trovi nell'elenco delle esenzioni.
    • [C-0-7] Se l'app ha come target il livello API 25 o superiore, DEVE interrompere i servizi in background dell'app, come se l'app avesse chiamato il metodo stopSelf() dei servizi, a meno che l'app non sia inserita in un elenco consentito temporaneo per gestire un'attività visibile all'utente.
    • [C-0-8] Se l'app ha come target il livello API 25 o versioni successive, DEVE rilasciare i wakelock che detiene.
  • I dispositivi [C-0-9] DEVONO restituire i seguenti fornitori di sicurezza come primi sette valori dell'array dal metodo Security.getProviders(), nell'ordine indicato e con i nomi (restituiti da Provider.getName()) e le classi specificati, a meno che l'app non abbia modificato l'elenco tramite insertProviderAt() o removeProvider(). I dispositivi POSSONO restituire fornitori aggiuntivi dopo l'elenco specificato di fornitori riportato di seguito.
    1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider - sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

L'elenco riportato sopra non è esaustivo. La suite di test di compatibilità (CTS) verifica la compatibilità comportamentale di porzioni significative della piattaforma, ma non di tutte. È responsabilità dell'implementatore garantire la compatibilità comportamentale con l'Android Open Source Project. Per questo motivo, gli implementatori di dispositivi DEVONO utilizzare il codice sorgente disponibile tramite l'Android Open Source Project, ove possibile, anziché reimplementare parti significative del sistema.

3.5.1. Limitazione in background

Se le implementazioni dei dispositivi implementano le limitazioni delle app incluse in AOSP o le estendono,

  • [C-1-1] DEVE fornire un'interfaccia utente in cui l'utente possa visualizzare l'elenco delle app con limitazioni.
  • [C-1-2] DEVE fornire all'utente la possibilità di attivare / disattivare le limitazioni per ogni app.
  • [C-1-3] NON DEVE applicare automaticamente le limitazioni senza prove di un comportamento di integrità del sistema scadente, ma PUÒ applicare le limitazioni alle app al rilevamento di un comportamento di integrità del sistema scadente, come wakelock bloccati, servizi a esecuzione prolungata e altri criteri. I criteri POSSONO essere determinati dagli implementatori del dispositivo, ma DEVONO essere correlati all'impatto dell'app sull'integrità del sistema. Altri criteri non puramente correlati all'integrità del sistema, come la scarsa popolarità dell'app sul mercato, NON DEVONO essere utilizzati come criteri.
  • [C-1-4] NON DEVE applicare automaticamente le limitazioni delle app quando un utente le ha disattivate manualmente e PUÒ suggerire all'utente di applicarle.
  • [C-1-5] DEVE informare gli utenti se le limitazioni delle app vengono applicate automaticamente a un'app.
  • [C-1-6] DEVE restituire true per ActivityManager.isBackgroundRestricted() quando l'app con limitazioni chiama questa API.
  • [C-1-7] NON DEVE limitare l'app in primo piano principale utilizzata esplicitamente dall'utente.
  • [C-1-8] DEVONO sospendere le limitazioni di un'app che diventa l'applicazione in primo piano principale quando l'utente inizia esplicitamente a utilizzare l'app che era limitata.

3.6. API Namespaces

Android segue le convenzioni per lo spazio dei nomi di pacchetti e classi definite dal linguaggio di programmazione Java. Per garantire la compatibilità con le applicazioni di terze parti, gli implementatori di dispositivi NON DEVONO apportare modifiche vietate (vedi sotto) a questi spazi dei nomi dei pacchetti:

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

ovvero:

  • [C-0-1] NON DEVE modificare le API esposte pubblicamente sulla piattaforma Android modificando firme di metodi o classi oppure rimuovendo classi o campi di classi.
  • [C-0-2] NON DEVE aggiungere elementi esposti pubblicamente (ad esempio classi o interfacce, o campi o metodi a classi o interfacce esistenti) o API di test o di sistema alle API negli spazi dei nomi sopra indicati. Un "elemento esposto pubblicamente" è qualsiasi costrutto non decorato con il marcatore "@hide" utilizzato nel codice sorgente Android upstream.

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

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

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

  • [C-0-5] NON DEVE trovarsi in uno spazio dei nomi di proprietà di un'altra organizzazione o che fa riferimento a un'altra organizzazione. Ad esempio, gli implementatori di dispositivi NON DEVONO aggiungere API allo spazio dei nomi com.google.* o a uno simile: solo Google può farlo. Allo stesso modo, Google NON DEVE aggiungere API agli spazi dei nomi di altre società.
  • [C-0-6] DEVE essere incluso in una libreria condivisa Android in modo che solo le app che le utilizzano esplicitamente (tramite il meccanismo <uses-library>) siano interessate dall'aumento dell'utilizzo di memoria di queste API.

Se un implementatore di dispositivi propone di migliorare uno degli spazi dei nomi dei pacchetti sopra indicati (ad esempio aggiungendo nuove funzionalità utili a un'API esistente o aggiungendo una nuova API), DEVE visitare source.android.com e iniziare la procedura per contribuire con modifiche e codice, in base alle informazioni presenti sul sito.

Tieni presente che le limitazioni riportate sopra corrispondono alle convenzioni standard per la denominazione delle API nel linguaggio di programmazione Java; questa sezione ha semplicemente lo scopo di rafforzare queste convenzioni e renderle vincolanti mediante l'inclusione in questa definizione di compatibilità.

3.7. Compatibilità del runtime

Implementazioni del dispositivo:

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

  • [C-0-2] DEVE configurare i runtime Dalvik per allocare la memoria in conformità alla piattaforma Android upstream e come specificato nella tabella seguente. (Per le definizioni di dimensioni e densità dello schermo, consulta la sezione 7.1.1.)

  • DEVE utilizzare Android RunTime (ART), l'implementazione upstream di riferimento del formato eseguibile Dalvik e il sistema di gestione dei pacchetti dell'implementazione di riferimento.

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

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

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

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

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

Se le implementazioni dei dispositivi consentono alle applicazioni di terze parti di sostituire la schermata Home del dispositivo:

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

Se le implementazioni dei dispositivi includono un Avvio app predefinito che supporta il blocco delle scorciatoie in-app:

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

Se le implementazioni dei dispositivi implementano un launcher predefinito che fornisce un accesso rapido alle scorciatoie aggiuntive fornite da app di terze parti tramite l'API ShortcutManager, queste:

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

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

  • [C-5-1] DEVE rispettare il metodo API NotificationChannel.setShowBadge(). In altre parole, mostra un elemento visivo associato all'icona dell'app se il valore è impostato su true e non mostrare alcun schema di badge dell'icona dell'app quando tutti i canali di notifica dell'app hanno impostato il valore su false.
  • POTREBBE sostituire i badge delle icone delle app con il proprio schema di badge proprietario quando le applicazioni di terze parti indicano il supporto dello schema di badge proprietario tramite l'utilizzo di API proprietarie, ma DOVREBBE utilizzare le risorse e i valori forniti tramite le API dei badge di notifica descritte nell'SDK , ad esempio le API Notification.Builder.setNumber() e Notification.Builder.setBadgeIconType().

3.8.2. Widget

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

Se le implementazioni dei dispositivi supportano i widget delle app di terze parti:

  • [C-1-1] DEVE dichiarare il supporto per la funzionalità della piattaforma android.software.app_widgets.
  • [C-1-2] DEVE includere il supporto integrato per gli AppWidget ed esporre le funzionalità dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere gli AppWidget direttamente all'interno del Launcher.
  • [C-1-3] DEVE essere in grado di eseguire il rendering di widget di 4 x 4 nella dimensione della griglia standard. Per maggiori dettagli, consulta le linee guida per la progettazione dei widget delle app nella documentazione dell'SDK Android.
  • POTREBBE supportare i widget delle applicazioni nella schermata di blocco.

Se le implementazioni dei dispositivi supportano i widget delle app di terze parti e il blocco in-app delle scorciatoie:

3.8.3. Notifiche

Android include le API Notification e NotificationManager che consentono agli sviluppatori di app di terze parti di notificare agli utenti eventi importanti e attirare la loro attenzione utilizzando i componenti hardware (ad es. suono, vibrazione e luce) e le funzionalità software (ad es. riquadro delle notifiche, barra di sistema) del dispositivo.

3.8.3.1. Presentazione delle notifiche

Se le implementazioni dei dispositivi consentono alle app di terze parti di notificare agli utenti eventi importanti, queste:

  • [C-1-1] DEVE supportare le notifiche che utilizzano le funzionalità hardware, come descritto nella documentazione dell'SDK e nella misura possibile con l'hardware di implementazione del dispositivo. Ad esempio, se l'implementazione di un dispositivo include un vibratore, DEVE implementare correttamente le API di vibrazione. Se un'implementazione del dispositivo non dispone di hardware, le API corrispondenti DEVONO essere implementate come no-op. Questo comportamento è descritto in dettaglio nella sezione 7.
  • [C-1-2] DEVE eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) fornite nelle API o nella guida di stile delle icone della barra di stato/di sistema, anche se PUÒ fornire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'implementazione di riferimento di Android Open Source.
  • [C-1-3] DEVE rispettare e implementare correttamente i comportamenti descritti per le API per aggiornare, rimuovere e raggruppare le notifiche.
  • [C-1-4] DEVE fornire il comportamento completo dell'API NotificationChannel documentato nell'SDK.
  • [C-1-5] DEVE fornire un'opzione per bloccare e modificare la notifica di una determinata app di terze parti per ogni canale e livello di pacchetto dell'app.
  • [C-1-6] DEVE anche fornire un'interfaccia utente per visualizzare i canali di notifica eliminati.
  • [C-1-7] DEVE eseguire il rendering corretto di tutte le risorse (immagini, adesivi, icone e così via) fornite tramite Notification.MessagingStyle insieme al testo della notifica senza interazione aggiuntiva dell'utente. Ad esempio, DEVE mostrare tutte le risorse, incluse le icone fornite tramite android.app.Person in una conversazione di gruppo impostata tramite setGroupConversation.
  • [C-SR] Sono FORTEMENTE CONSIGLIATE per mostrare automaticamente una funzionalità utente per bloccare la notifica di una determinata app di terze parti per ogni canale e livello di pacchetto dell'app dopo che l'utente ha chiuso la notifica più volte.
  • DEVE supportare le notifiche avanzate.
  • DOVREBBE presentare alcune notifiche con priorità più elevata come notifiche in evidenza.
  • DEVE avere un'opzione per posticipare le notifiche.
  • MAY può gestire solo la visibilità e la tempistica delle notifiche di eventi importanti inviate agli utenti da app di terze parti per mitigare problemi di sicurezza come la distrazione del conducente.

Se le implementazioni dei dispositivi supportano le notifiche avanzate:

  • [C-2-1] DEVE utilizzare le risorse esatte fornite tramite la classe API Notification.Style e le relative sottoclassi per gli elementi delle risorse presentati.
  • DEVE presentare ogni elemento della risorsa (ad es. icona, titolo e testo del riepilogo) definito nella classe API Notification.Style e nelle relative sottoclassi.

Se le implementazioni dei dispositivi supportano le notifiche di avviso, queste:

  • [C-3-1] DEVE utilizzare la visualizzazione e le risorse delle notifiche heads-up come descritto nella classe API Notification.Builder quando vengono presentate le notifiche heads-up.
  • [C-3-2] DEVE mostrare le azioni fornite tramite Notification.Builder.addAction() insieme ai contenuti della notifica senza ulteriori interazioni dell'utente, come descritto nell'SDK.
3.8.3.2. Servizio listener di notifiche

Android include le API NotificationListenerService che consentono alle app (una volta attivate esplicitamente dall'utente) di ricevere una copia di tutte le notifiche man mano che vengono pubblicate o aggiornate.

Se le implementazioni del dispositivo segnalano il flag funzionalità android.hardware.ram.normal:

  • [C-1-1] DEVE aggiornare correttamente e tempestivamente le notifiche nella loro interezza a tutti i servizi di ascolto installati e attivati dall'utente, inclusi tutti i metadati allegati all'oggetto Notifica.
  • [C-1-2] DEVE rispettare la chiamata API snoozeNotification() e chiudere la notifica ed effettuare un callback dopo la durata del posticipo impostata nella chiamata API.

Se le implementazioni dei dispositivi prevedono una funzionalità utente per posticipare le notifiche:

  • [C-2-1] DEVE riflettere correttamente lo stato della notifica posticipata tramite le API standard come NotificationListenerService.getSnoozedNotifications().
  • [C-2-2] DEVE rendere disponibile questa funzionalità per posticipare le notifiche di ogni app di terze parti installata, a meno che non provengano da servizi persistenti/in primo piano.
3.8.3.3. DND (Do Not Disturb, Non disturbare)

Se le implementazioni dei dispositivi supportano la funzionalità Non disturbare:

  • [C-1-1] DEVE implementare un'attività che risponda all'intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, che per le implementazioni con UI_MODE_TYPE_NORMAL DEVE essere un'attività in cui l'utente può concedere o negare all'app l'accesso alle configurazioni delle norme DND.
  • [C-1-2] DEVE, quando l'implementazione del dispositivo ha fornito un mezzo per consentire all'utente di concedere o negare alle app di terze parti l'accesso alla configurazione delle norme DND, mostrare le regole DND automatiche create dalle applicazioni insieme alle regole create dall'utente e predefinite.
  • [C-1-3] DEVE rispettare i valori di suppressedVisualEffects passati insieme a NotificationManager.Policy e, se un'app ha impostato uno dei flag SUPPRESSED_EFFECT_SCREEN_OFF o SUPPRESSED_EFFECT_SCREEN_ON, DOVREBBE indicare all'utente che gli effetti visivi sono disattivati nel menu delle impostazioni Non disturbare.

Android include API che consentono agli sviluppatori di incorporare la ricerca nelle proprie applicazioni ed esporre i dati delle applicazioni nella ricerca globale del sistema. In generale, questa funzionalità è costituita da un'unica interfaccia utente a livello di sistema che consente agli utenti di inserire query, visualizza suggerimenti durante la digitazione e mostra i risultati. Le API Android consentono agli sviluppatori di riutilizzare questa interfaccia per fornire la ricerca all'interno delle proprie app e consentire agli sviluppatori di fornire risultati all'interfaccia utente di ricerca globale comune.

  • Le implementazioni dei dispositivi Android DEVONO includere la ricerca globale, un'unica interfaccia utente di ricerca condivisa a livello di sistema in grado di fornire suggerimenti in tempo reale in risposta all'input dell'utente.

Se le implementazioni dei dispositivi implementano l'interfaccia di ricerca globale:

  • [C-1-1] DEVE implementare le API che consentono alle applicazioni di terze parti di aggiungere suggerimenti alla casella di ricerca quando viene eseguita in modalità di ricerca globale.

Se non sono installate applicazioni di terze parti che utilizzano la ricerca globale:

  • Il comportamento predefinito DOVREBBE essere la visualizzazione dei risultati e dei suggerimenti del motore di ricerca web.

Android include anche le API Assist per consentire alle applicazioni di scegliere la quantità di informazioni del contesto attuale da condividere con l'assistente sul dispositivo.

Se le implementazioni dei dispositivi supportano l'azione Assist,

  • [C-2-1] DEVE indicare chiaramente all'utente finale quando il contesto viene condiviso, tramite:
    • Ogni volta che l'app di assistenza accede al contesto, viene visualizzata una luce bianca intorno ai bordi dello schermo che soddisfa o supera la durata e la luminosità dell'implementazione di Android Open Source Project.
    • Per l'app di assistenza preinstallata, fornire un'agevolazione per l'utente a meno di due navigazioni di distanza dal menu delle impostazioni dell'app di assistenza e di input vocale predefinito e condividere il contesto solo quando l'app di assistenza viene richiamata esplicitamente dall'utente tramite un comando vocale o l'input di un tasto di navigazione di assistenza.
  • [C-2-2] L'interazione designata per avviare l'app di assistenza, come descritto nella sezione 7.2.3, DEVE avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService o un'attività che gestisce l'intent ACTION_ASSIST.

3.8.5. Avvisi e notifiche di tipo toast

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

Se le implementazioni del dispositivo includono un'uscita video o uno schermo:

  • [C-1-1] DEVE fornire un'interfaccia utente per impedire a un'app di visualizzare finestre di avviso che utilizzano TYPE_APPLICATION_OVERLAY . L'implementazione AOSP soddisfa questo requisito disponendo di controlli nella barra delle notifiche.

  • [C-1-2] DEVE rispettare l'API Toast e mostrare i toast delle applicazioni agli utenti finali in modo ben visibile.

3.8.6. Temi

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

Android include una famiglia di temi "Holo" e "Material" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare l'aspetto del tema Holo definito dall'SDK Android.

Se le implementazioni del dispositivo includono un'uscita video o uno schermo:

  • [C-1-1] NON DEVE alterare nessuno degli attributi del tema Holo esposti alle applicazioni.
  • [C-1-2] DEVE supportare la famiglia di temi "Material" e NON DEVE alterare nessuno degli attributi del tema Material o delle relative risorse esposte alle applicazioni.

Android include anche una famiglia di temi "Predefinito del dispositivo" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare l'aspetto del tema del dispositivo come definito dall'implementatore del dispositivo.

Android supporta un tema variante con barre di sistema traslucide, che consente agli sviluppatori di applicazioni di riempire l'area dietro la barra di stato e di navigazione con i contenuti dell'app. Per garantire un'esperienza coerente per gli sviluppatori in questa configurazione, è importante che lo stile dell'icona della barra di stato venga mantenuto nelle diverse implementazioni dei dispositivi.

Se le implementazioni del dispositivo includono una barra di stato del sistema:

  • [C-2-1] DEVE utilizzare il bianco per le icone di stato del sistema (ad esempio intensità del segnale e livello della batteria) e per le notifiche emesse dal sistema, a meno che l'icona non indichi uno stato problematico o un'app non richieda una barra di stato chiara utilizzando il flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
  • [C-2-2] Le implementazioni dei dispositivi Android DEVONO cambiare il colore delle icone di stato del sistema in nero (per i dettagli, consulta R.style) quando un'app richiede una barra di stato chiara.

3.8.7. Sfondi animati

Android definisce un tipo di componente e l'API e il ciclo di vita corrispondenti che consentono alle applicazioni di esporre una o più "Live Wallpaper" all'utente finale. Gli sfondi animati sono animazioni, motivi o immagini simili con funzionalità di input limitate che vengono visualizzati come sfondo, dietro altre applicazioni.

L'hardware è considerato in grado di eseguire in modo affidabile gli sfondi animati se può eseguire tutti gli sfondi animati, senza limitazioni di funzionalità, a un frame rate ragionevole senza effetti negativi su altre applicazioni. Se le limitazioni dell'hardware causano arresti anomali, malfunzionamenti, consumo eccessivo di CPU o batteria o esecuzione a frequenze fotogrammi inaccettabilmente basse di sfondi e/o applicazioni, l'hardware è considerato incapace di eseguire sfondi animati. Ad esempio, alcuni sfondi animati potrebbero utilizzare un contesto OpenGL 2.0 o 3.x per il rendering dei contenuti. Lo sfondo animato non verrà eseguito in modo affidabile su hardware che non supporta più contesti OpenGL perché l'utilizzo di un contesto OpenGL da parte dello sfondo animato potrebbe entrare in conflitto con altre applicazioni che utilizzano anch'esse un contesto OpenGL.

  • Le implementazioni del dispositivo in grado di eseguire sfondi animati in modo affidabile come descritto sopra DEVONO implementare sfondi animati.

Se le implementazioni dei dispositivi implementano sfondi animati:

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

3.8.8. Passaggio da un'attività all'altra

Il codice sorgente Android upstream include la schermata Panoramica, un'interfaccia utente a livello di sistema per il cambio di attività e la visualizzazione di attività e task a cui si è acceduto di recente utilizzando un'immagine in miniatura dello stato grafico dell'applicazione nel momento in cui l'utente l'ha lasciata l'ultima volta.

Le implementazioni dei dispositivi, inclusa la chiave di navigazione della funzione Recenti, come descritto nella sezione 7.2.3, POSSONO alterare l'interfaccia.

Se le implementazioni dei dispositivi, inclusa la chiave di navigazione della funzione Recenti, come descritto nella sezione 7.2.3, modificano l'interfaccia:

  • [C-1-1] DEVE supportare almeno fino a 7 attività visualizzate.
  • DOVREBBE mostrare almeno il titolo di 4 attività alla volta.
  • [C-1-2] DEVE implementare il comportamento di blocco schermo e fornire all'utente un menu delle impostazioni per attivare/disattivare la funzionalità.
  • DOVREBBE mostrare il colore di evidenziazione, l'icona e il titolo della schermata in Recenti.
  • DEVE mostrare un indicatore di chiusura ("x"), ma PUÒ ritardare questa operazione finché l'utente non interagisce con le schermate.
  • DEVE implementare una scorciatoia per passare facilmente all'attività precedente.
  • DEVE attivare l'azione di cambio rapido tra le due app utilizzate più di recente quando il tasto funzione Recenti viene toccato due volte.
  • DEVE attivare la modalità multi-finestra a schermo diviso, se supportata, quando viene premuto a lungo il tasto delle funzioni Recenti.
  • POTREBBE mostrare i contenuti recenti affiliati come un gruppo che si sposta insieme.
  • [SR] È FORTEMENTE CONSIGLIATO di utilizzare l'interfaccia utente Android upstream (o un'interfaccia simile basata su miniature) per la schermata Panoramica.

3.8.9. Input Management

Android include il supporto per la gestione dell'input e per gli editor di metodi di input di terze parti.

Se le implementazioni dei dispositivi consentono agli utenti di utilizzare metodi di immissione di terze parti sul dispositivo:

  • [C-1-1] DEVE dichiarare la funzionalità della piattaforma android.software.input_methods e supportare le API IME come definito nella documentazione dell'SDK Android.
  • [C-1-2] DEVE fornire un meccanismo accessibile all'utente per aggiungere e configurare metodi di immissione di terze parti in risposta all'intent android.settings.INPUT_METHOD_SETTINGS.

Se le implementazioni del dispositivo dichiarano il flag di funzionalità android.software.autofill, queste:

3.8.10. Controllo dei contenuti multimediali nella schermata di blocco

L'API Remote Control Client è ritirata da Android 5.0 a favore del modello di notifica multimediale che consente alle applicazioni multimediali di integrarsi con i controlli di riproduzione visualizzati nella schermata di blocco.

3.8.11. Salvaschermo (precedentemente Sogni)

Android include il supporto per i salvaschermo interattivi, in precedenza chiamati Dreams. I salvaschermo consentono agli utenti di interagire con le applicazioni quando un dispositivo collegato a una fonte di alimentazione è inattivo o agganciato a una base di ricarica. I dispositivi Android Watch POSSONO implementare i salvaschermo, ma altri tipi di implementazione del dispositivo DEVONO includere il supporto per i salvaschermo e fornire un'opzione di impostazione per consentire agli utenti di configurare i salvaschermo in risposta all'intent android.settings.DREAM_SETTINGS.

3.8.12. Posizione

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

3.8.13. Unicode e carattere

Android include il supporto per i caratteri emoji definiti in Unicode 10.0.

Se le implementazioni del dispositivo includono un'uscita video o uno schermo:

  • [C-1-1] DEVE essere in grado di eseguire il rendering di questi caratteri emoji in un glifo a colori.
  • [C-1-2] MUST include support for:
    • Carattere Roboto 2 con diversi pesi: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light per le lingue disponibili sul dispositivo.
    • Copertura completa di Unicode 7.0 per i caratteri latini, greci e cirillici, inclusi gli intervalli latini estesi A, B, C e D e tutti i glifi nel blocco dei simboli di valuta di Unicode 7.0.
  • DEVE supportare le emoji con tonalità della pelle e delle diverse famiglie come specificato nel Unicode Technical Report #51.

Se le implementazioni dei dispositivi includono un IME:

  • DEVE fornire all'utente un metodo di input per questi caratteri emoji.

Android include il supporto per il rendering dei caratteri del Myanmar. Il Myanmar ha diversi caratteri non conformi a Unicode, comunemente noti come "Zawgyi", per il rendering delle lingue del paese.

Se le implementazioni dei dispositivi includono il supporto del birmano: 

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. Multi-finestra

Se le implementazioni dei dispositivi sono in grado di visualizzare più attività contemporaneamente:

  • [C-1-1] DEVE implementare queste modalità multi-finestra in conformità con i comportamenti e le API delle applicazioni descritti nella documentazione sul supporto della modalità multi-finestra dell'SDK Android e soddisfare i seguenti requisiti:
  • [C-1-2] DEVE rispettare android:resizeableActivity impostato da un'app nel file AndroidManifest.xml come descritto in questo SDK.
  • [C-1-3] NON DEVE offrire la modalità Split Screen o Freeform se l'altezza dello schermo è inferiore a 440 dp e la larghezza dello schermo è inferiore a 440 dp.
  • [C-1-4] Le dimensioni di un'attività NON DEVONO essere ridotte a meno di 220 dp nelle modalità multi-finestra diverse da Picture in picture.
  • Le implementazioni del dispositivo con dimensioni dello schermo xlarge DEVONO supportare la modalità Freeform.

Se le implementazioni dei dispositivi supportano una o più modalità multi-finestra e la modalità schermo diviso:

  • [C-2-1] DEVE precaricare un launcher ridimensionabile come predefinito.
  • [C-2-2] DEVE ritagliare l'attività agganciata di una finestra multipla in modalità split-screen, ma DOVREBBE mostrare alcuni contenuti se l'app Avvio app è la finestra attiva.
  • [C-2-3] DEVE rispettare i valori dichiarati di AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight dell'applicazione di avvio di terze parti e non sostituirli durante la visualizzazione di alcuni contenuti dell'attività agganciata.

Se le implementazioni dei dispositivi supportano la modalità multi-finestra e la modalità multi-finestra Picture in picture:

  • [C-3-1] DEVE avviare le attività in modalità multi-finestra Picture in picture quando l'app: * Ha come target il livello API 26 o versioni successive e dichiara android:supportsPictureInPicture * Ha come target il livello API 25 o versioni precedenti e dichiara sia android:resizeableActivity sia android:supportsPictureInPicture.
  • [C-3-2] DEVE esporre le azioni nella SystemUI come specificato dall'attività PIP corrente tramite l'API setActions().
  • [C-3-3] DEVE supportare proporzioni maggiori o uguali a 1:2,39 e minori o uguali a 2,39:1, come specificato dall'attività PIP tramite l'API setAspectRatio().
  • [C-3-4] DEVE utilizzare KeyEvent.KEYCODE_WINDOW per controllare la finestra PIP; se la modalità PIP non è implementata, il tasto DEVE essere disponibile per l'attività in primo piano.
  • [C-3-5] DEVE fornire un'interfaccia utente per bloccare la visualizzazione di un'app in modalità PIP. L'implementazione AOSP soddisfa questo requisito disponendo di controlli nella barra delle notifiche.
  • [C-3-6] DEVE allocare una larghezza e un'altezza minime di 108 dp per la finestra PIP e una larghezza minima di 240 dp e un'altezza di 135 dp per la finestra PIP quando Configuration.uiMode è configurato come UI_MODE_TYPE_TELEVISION.

3.8.15. Ritaglio display

Android supporta un ritaglio del display come descritto nel documento SDK. L'API DisplayCutout definisce un'area sul bordo del display che non è funzionale per la visualizzazione dei contenuti.

Se le implementazioni del dispositivo includono uno o più fori sul display:

  • [C-1-1] DEVE avere solo intagli sul bordo o sui bordi corti del dispositivo. Al contrario, se le proporzioni del dispositivo sono 1.0 (1:1), NON devono avere ritagli.
  • [C-1-2] NON DEVE avere più di un ritaglio per bordo.
  • [C-1-3] DEVE rispettare i flag di ritaglio del display impostati dall'app tramite l'API WindowManager.LayoutParams come descritto nell'SDK.
  • [C-1-4] DEVE segnalare i valori corretti per tutte le metriche di ritaglio definite nell'API DisplayCutout.

3.9. Amministrazione dispositivo

Android include funzionalità che consentono alle applicazioni attente alla sicurezza di eseguire funzioni di amministrazione dei dispositivi a livello di sistema, ad esempio l'applicazione di criteri per le password o l'esecuzione della cancellazione da remoto, tramite l'API Android Device Administration.

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

  • [C-1-1] DEVE dichiarare android.software.device_admin.
  • [C-1-2] DEVE supportare il provisioning del proprietario del dispositivo come descritto nella sezione 3.9.1 e nella sezione 3.9.1.1.

3.9.1 Provisioning dispositivo

3.9.1.1 Provisioning del proprietario del dispositivo

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

  • [C-1-1] DEVE supportare la registrazione di un client Device Policy (DPC) come app proprietario del dispositivo, come descritto di seguito:
  • [C-1-2] DEVE richiedere un'azione affermativa durante la procedura di provisioning per acconsentire all'impostazione dell'app come proprietario del dispositivo. Il consenso può essere ottenuto tramite l'azione dell'utente o con mezzi programmatici durante il provisioning, ma NON deve essere codificato o impedire l'utilizzo di altre app proprietarie del dispositivo.

Se le implementazioni del dispositivo dichiarano android.software.device_admin, ma includono anche una soluzione di gestione proprietaria del proprietario del dispositivo e forniscono un meccanismo per promuovere un'applicazione configurata nella loro soluzione come "equivalente del proprietario del dispositivo" al "proprietario del dispositivo" standard riconosciuto dalle API DevicePolicyManager standard di Android:

  • [C-2-1] DEVE disporre di una procedura per verificare che l'app specifica promossa appartenga a una soluzione di gestione dei dispositivi aziendali legittima e che sia già stata configurata nella soluzione proprietaria per disporre di diritti equivalenti a quelli di un "Proprietario del dispositivo".
  • [C-2-2] DEVE mostrare la stessa informativa sul consenso del proprietario del dispositivo AOSP del flusso avviato da android.app.action.PROVISION_MANAGED_DEVICE prima di registrare l'applicazione DPC come "Proprietario del dispositivo".
  • POTREBBE avere dati utente sul dispositivo prima di registrare l'applicazione DPC come "Proprietario del dispositivo".
3.9.1.2 Provisioning dei profili gestiti

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

  • [C-1-1] DEVE implementare le API che consentono a un'applicazione controller dei criteri dei dispositivi (DPC) di diventare il proprietario di un nuovo profilo gestito.

  • [C-1-2] La procedura di provisioning del profilo gestito (il flusso avviato da android.app.action.PROVISION_MANAGED_PROFILE) deve essere in linea con l'implementazione AOSP.

  • [C-1-3] DEVE fornire le seguenti funzionalità per l'utente all'interno delle Impostazioni per indicare all'utente quando una particolare funzione di sistema è stata disattivata dal controller delle norme del dispositivo (DPC):

    • Un'icona coerente o un altro elemento di interazione utente (ad esempio l'icona delle informazioni AOSP upstream) per indicare quando una determinata impostazione è limitata da un amministratore dispositivo.
    • Un breve messaggio di spiegazione, fornito dall'amministratore del dispositivo tramite setShortSupportMessage.
    • L'icona dell'applicazione DPC.

3.9.2 Supporto dei profili gestiti

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

  • [C-1-1] DEVE supportare i profili gestiti tramite le API android.app.admin.DevicePolicyManager.
  • [C-1-2] DEVE consentire la creazione di un solo profilo gestito.
  • [C-1-3] DEVE utilizzare un badge icona (simile al badge di lavoro upstream AOSP) per rappresentare le applicazioni e i widget gestiti e altri elementi dell'interfaccia utente con badge come Recenti e Notifiche.
  • [C-1-4] DEVE mostrare un'icona di notifica (simile al badge di lavoro upstream AOSP) per indicare quando l'utente si trova all'interno di un'applicazione del profilo gestito.
  • [C-1-5] DEVE mostrare un messaggio di notifica che indica che l'utente si trova nel profilo gestito quando il dispositivo si riattiva (ACTION_USER_PRESENT) e l'applicazione in primo piano si trova all'interno del profilo gestito.
  • [C-1-6] Se esiste un profilo gestito, DEVE mostrare un elemento visivo nell'Intent "Chooser" per consentire all'utente di inoltrare l'intent dal profilo gestito all'utente principale o viceversa, se abilitato dal controller dei criteri del dispositivo.
  • [C-1-7] Se esiste un profilo gestito, DEVONO essere esposte le seguenti funzionalità per l'utente sia per l'utente principale sia per il profilo gestito:
    • Contabilità separata per l'utilizzo di batteria, posizione, dati mobili e spazio di archiviazione per l'utente principale e il profilo gestito.
    • Gestione indipendente delle applicazioni VPN installate nell'utente principale o nel profilo gestito.
    • Gestione indipendente delle applicazioni installate nell'utente principale o nel profilo gestito.
    • Gestione indipendente degli account all'interno dell'utente principale o del profilo gestito.
  • [C-1-8] DEVE garantire che le applicazioni preinstallate di composizione, contatti e messaggistica possano cercare e consultare le informazioni del chiamante dal profilo gestito (se esistente) insieme a quelle del profilo principale, se il controller delle norme del dispositivo lo consente.
  • [C-1-9] DEVE garantire di soddisfare tutti i requisiti di sicurezza applicabili a un dispositivo con più utenti abilitati (vedi sezione 9.5), anche se il profilo gestito non viene conteggiato come un altro utente oltre all'utente principale.
  • [C-1-10] DEVE supportare la possibilità di specificare una schermata di blocco separata che soddisfi i seguenti requisiti per concedere l'accesso alle app in esecuzione in un profilo gestito.
    • Le implementazioni del dispositivo DEVONO rispettare l'intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrare un'interfaccia per configurare una credenziale della schermata di blocco separata per il profilo gestito.
    • Le credenziali della schermata di blocco del profilo gestito DEVONO utilizzare gli stessi meccanismi di gestione e archiviazione delle credenziali del profilo genitore, come documentato nel sito del progetto Android Open Source.
    • I criteri per le password del DPC DEVONO essere applicati solo alle credenziali della schermata di blocco del profilo gestito, a meno che non venga chiamata l'istanza DevicePolicyManager restituita da getParentProfileInstance.
  • Quando i contatti del profilo gestito vengono visualizzati nel registro chiamate preinstallato, nella UI durante la chiamata e nelle notifiche di chiamate in corso e senza risposta, le app di contatti e messaggistica DEVONO essere contrassegnate con lo stesso badge utilizzato per indicare le applicazioni del profilo gestito.

3.9.3 Supporto degli utenti gestiti

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

  • [C-1-1] DEVE fornire un'opzione per disconnettersi dall'utente corrente e tornare all'utente principale in una sessione multiutente quando isLogoutEnabled restituisce true. L'utente deve poter accedere all'assistente dalla schermata di blocco senza sbloccare il dispositivo.

3.10. Accessibilità

Android fornisce un livello di accessibilità che aiuta gli utenti con disabilità a navigare più facilmente sui propri dispositivi. Inoltre, Android fornisce API della piattaforma che consentono alle implementazioni dei servizi di accessibilità di ricevere callback per eventi utente e di sistema e generare meccanismi di feedback alternativi, come sintesi vocale, feedback aptico e navigazione con trackball/D-pad.

Se le implementazioni dei dispositivi supportano servizi di accessibilità di terze parti:

  • [C-1-1] DEVE fornire un'implementazione del framework di accessibilità Android come descritto nella documentazione dell'SDK delle API Accessibility.
  • [C-1-2] DEVE generare eventi di accessibilità e fornire il AccessibilityEvent appropriato a tutte le implementazioni AccessibilityService registrate, come documentato nell'SDK.
  • [C-1-3] DEVE rispettare l'intent android.settings.ACCESSIBILITY_SETTINGS di fornire un meccanismo accessibile all'utente per attivare e disattivare i servizi di accessibilità di terze parti insieme ai servizi di accessibilità preinstallati.
  • [C-1-4] DEVE aggiungere un pulsante nella barra di navigazione del sistema che consenta all'utente di controllare il servizio di accessibilità quando i servizi di accessibilità attivati dichiarano AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Tieni presente che per le implementazioni del dispositivo senza barra di navigazione di sistema, questo requisito non è applicabile, ma le implementazioni del dispositivo DEVONO fornire un'agevolazione per l'utente per controllare questi servizi di accessibilità.

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

  • [C-2-1] DEVE implementare questi servizi di accessibilità preinstallati come app compatibili con l'avvio diretto quando l'archiviazione dei dati è criptata con la crittografia basata su file (FBE).
  • DEVE fornire un meccanismo nel flusso di configurazione predefinito per consentire agli utenti di attivare i servizi di accessibilità pertinenti, nonché opzioni per regolare le dimensioni del carattere, le dimensioni di visualizzazione e i gesti di ingrandimento.

3.11. Sintesi vocale

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

Se le implementazioni del dispositivo segnalano la funzionalità android.hardware.audio.output,

Se le implementazioni dei dispositivi supportano l'installazione di motori TTS di terze parti:

  • [C-2-1] DEVE fornire all'utente la possibilità di selezionare un motore TTS da utilizzare a livello di sistema.

3.12. Framework per l'ingresso TV

L'Android Television Input Framework (TIF) semplifica la distribuzione di contenuti live ai dispositivi Android TV. TIF fornisce un'API standard per creare moduli di input che controllano i dispositivi Android Television.

Se le implementazioni dei dispositivi supportano TIF:

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

3.13. Impostazioni rapide

Android fornisce un componente UI Impostazioni rapide che consente di accedere rapidamente alle azioni utilizzate di frequente o necessarie con urgenza.

Se le implementazioni dei dispositivi includono un componente dell'interfaccia utente delle Impostazioni rapide, questo:

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

3.14. UI media

Se le implementazioni del dispositivo includono applicazioni non attivate tramite comandi vocali (le App) che interagiscono con applicazioni di terze parti tramite MediaBrowser o MediaSession, le App:

  • [C-1-2] DEVE mostrare chiaramente le icone ottenute tramite getIconBitmap() o getIconUri() e i titoli ottenuti tramite getTitle(), come descritto in MediaDescription. Potrebbe abbreviare i titoli per rispettare le normative di sicurezza (ad es. distrazione del conducente).

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

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

  • [C-1-5] DEVE considerare il doppio tocco di KEYCODE_HEADSETHOOK o KEYCODE_MEDIA_PLAY_PAUSE come KEYCODE_MEDIA_NEXT per MediaSession.Callback#onMediaButtonEvent.

3.15. App istantanee

Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti:

  • [C-0-1] Alle app istantanee DEVONO essere concesse solo autorizzazioni con android:protectionLevel impostato su "instant".
  • [C-0-2] Le app istantanee NON DEVONO interagire con le app installate tramite intent impliciti, a meno che non si verifichi una delle seguenti condizioni:
    • Il filtro del pattern di intent del componente è esposto e ha CATEGORY_BROWSABLE
    • L'azione è una delle seguenti: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • Il target è esposto in modo esplicito con android:visibleToInstantApps
  • [C-0-3] Le app istantanee NON DEVONO interagire esplicitamente con le app installate, a meno che il componente non sia esposto tramite android:visibleToInstantApps.
  • [C-0-4] Le app installate NON DEVONO visualizzare i dettagli sulle app istantanee sul dispositivo, a meno che l'app istantanea non si connetta esplicitamente all'applicazione installata.
  • Le implementazioni dei dispositivi DEVONO fornire le seguenti funzionalità per l'interazione con le app istantanee. AOSP soddisfa i requisiti con l'interfaccia utente di sistema, le Impostazioni e il Launcher predefiniti. Implementazioni del dispositivo:
    • [C-0-5] DEVE fornire un'interfaccia utente per visualizzare ed eliminare le app istantanee memorizzate nella cache locale per ogni singolo pacchetto dell'app.
    • [C-0-6] DEVE fornire una notifica utente persistente che può essere compressa mentre un'app istantanea è in esecuzione in primo piano. Questa notifica per l'utente DEVE includere l'informazione che le app istantanee non richiedono l'installazione e fornire un'opzione che indirizzi l'utente alla schermata delle informazioni sull'applicazione nelle Impostazioni. Per le app istantanee avviate tramite intent web, come definito dall'utilizzo di un intent con l'azione impostata su Intent.ACTION_VIEW e con uno schema "http" o "https", un'ulteriore funzionalità per l'utente DOVREBBE consentirgli di non avviare l'app istantanea e di avviare il link associato con il browser web configurato, se un browser è disponibile sul dispositivo.
    • [C-0-7] DEVE consentire l'accesso alle app istantanee dalla funzione Recenti se questa è disponibile sul dispositivo.

3.16. Accoppiamento del dispositivo complementare

Android include il supporto per l'accoppiamento dei dispositivi complementari per gestire in modo più efficace l'associazione con i dispositivi complementari e fornisce l'API CompanionDeviceManager per consentire alle app di accedere a questa funzionalità.

Se le implementazioni dei dispositivi supportano la funzionalità di accoppiamento del dispositivo complementare:

  • [C-1-1] DEVE dichiarare il flag funzionalità FEATURE_COMPANION_DEVICE_SETUP .
  • [C-1-2] DEVE garantire che le API nel pacchetto android.companion siano completamente implementate.
  • [C-1-3] DEVE fornire all'utente la possibilità di selezionare/confermare la presenza e il funzionamento di un dispositivo complementare.

3.17. App pesanti

Se le implementazioni del dispositivo dichiarano la funzionalità FEATURE_CANT_SAVE_STATE, allora:

  • [C-1-1] DEVE avere una sola app installata che specifica cantSaveState in esecuzione nel sistema alla volta. Se l'utente esce da un'app senza chiuderla esplicitamente (ad esempio premendo il tasto Home mentre lascia un'attività attiva nel sistema, anziché premere Indietro senza altre attività attive nel sistema), le implementazioni del dispositivo DEVONO dare la priorità a questa app nella RAM, come fanno per altre cose che devono rimanere in esecuzione, ad esempio i servizi in primo piano. Mentre un'app di questo tipo è in background, il sistema può comunque applicare funzionalità di gestione dell'alimentazione, come la limitazione dell'accesso alla CPU e alla rete.
  • [C-1-2] DEVE fornire un'interfaccia utente per scegliere l'app che non parteciperà al normale meccanismo di salvataggio/ripristino dello stato una volta che l'utente avvia una seconda app dichiarata con l'attributo cantSaveState.
  • [C-1-3] NON DEVE applicare altre modifiche alle norme alle app che specificano cantSaveState, ad esempio la modifica delle prestazioni della CPU o della priorità di pianificazione.

Se le implementazioni del dispositivo non dichiarano la funzionalità FEATURE_CANT_SAVE_STATE, allora:

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

4. Compatibilità con la creazione di pacchetti di applicazioni

Implementazioni dei dispositivi:

  • [C-0-1] DEVE essere in grado di installare ed eseguire file ".apk" Android generati dallo strumento "aapt" incluso nell'SDK Android ufficiale.
  • Poiché il requisito precedente potrebbe essere difficile da soddisfare, è CONSIGLIATO che le implementazioni dei dispositivi utilizzino il sistema di gestione dei pacchetti dell'implementazione di riferimento AOSP.

Implementazioni del dispositivo:

  • [C-0-2] DEVE supportare la verifica dei file ".apk" utilizzando lo schema di firma dell'APK v3 , lo schema di firma dell'APK v2 e la firma JAR.
  • [C-0-3] NON DEVE estendere i formati .apk, Android Manifest, bytecode Dalvik o bytecode RenderScript in modo tale da impedire l'installazione e l'esecuzione corretta di questi file su altri dispositivi compatibili.

  • [C-0-4] NON DEVE consentire ad app diverse dall'attuale "programma di installazione registrato" per il pacchetto di disinstallare l'app automaticamente senza alcuna conferma dell'utente, come documentato nell'SDK per l'autorizzazione DELETE_PACKAGE. Le uniche eccezioni sono l'app di verifica dei pacchetti di sistema che gestisce l'intent PACKAGE_NEEDS_VERIFICATION e l'app di gestione dello spazio di archiviazione che gestisce l'intent ACTION_MANAGE_STORAGE.

  • [C-0-5] DEVE avere un'attività che gestisce l'intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.

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

    • DEVE dichiarare l'autorizzazione REQUEST_INSTALL_PACKAGES o avere il valore di android:targetSdkVersion impostato su 24 o inferiore.
    • L'utente DEVE aver concesso l'autorizzazione per installare app da fonti sconosciute.

  • DEVE fornire un'interfaccia utente per concedere/revocare l'autorizzazione a installare app da origini sconosciute per applicazione, ma PUÒ scegliere di implementarla come no-op e restituire RESULT_CANCELED per startActivityForResult(), se l'implementazione del dispositivo non vuole consentire agli utenti di avere questa scelta. Tuttavia, anche in questi casi, DEVONO indicare all'utente il motivo per cui non viene presentata questa scelta.

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

  • DEVE fornire un'opzione all'utente per scegliere di disinstallare o avviare un'applicazione nella finestra di dialogo di avviso.

5. Compatibilità multimediale

Implementazioni del dispositivo:

  • [C-0-1] DEVE supportare i formati multimediali, i codificatori, i decodificatori, i tipi di file e i formati contenitore definiti nella sezione 5.1 per ogni codec dichiarato da MediaCodecList.
  • [C-0-2] DEVE dichiarare e segnalare il supporto dei codificatori e decodificatori disponibili per le applicazioni di terze parti tramite MediaCodecList.
  • [C-0-3] DEVE essere in grado di decodificare correttamente e rendere disponibili alle app di terze parti tutti i formati che può codificare. Sono inclusi tutti i bitstream generati dai relativi codificatori e i profili riportati nel relativo CamcorderProfile.

Implementazioni del dispositivo:

  • SHOULD aim for minimum codec latency, in others words, they
    • NON DEVE consumare e archiviare i buffer di input e restituirli solo una volta elaborati.
    • NON DEVE conservare i buffer decodificati per un periodo di tempo superiore a quello specificato dallo standard (ad es. SPS).
    • NON DEVE conservare i buffer codificati più a lungo di quanto richiesto dalla struttura GOP.

Tutti i codec elencati nella sezione seguente sono forniti come implementazioni software nell'implementazione Android preferita di Android Open Source Project.

Tieni presente che né Google né l'Open Handset Alliance dichiarano che questi codec siano esenti da brevetti di terze parti. Coloro che intendono utilizzare questo codice sorgente in prodotti hardware o software sono informati che le implementazioni di questo codice, incluso in software open source o shareware, potrebbero richiedere licenze di brevetto dai titolari dei brevetti pertinenti.

5.1. Codec multimediali

5.1.1. Codifica audio

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

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

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

Tutti i codificatori audio DEVONO supportare:

5.1.2. Decodifica audio

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

Se le implementazioni del dispositivo dichiarano il supporto della funzionalità android.hardware.audio.output, DEVONO supportare la decodifica dei seguenti formati audio:

  • [C-1-1] Profilo MPEG-4 AAC (AAC LC)
  • [C-1-2] Profilo MPEG-4 HE AAC (AAC+)
  • [C-1-3] Profilo MPEG-4 HE AACv2 (AAC+ avanzato)
  • [C-1-4] AAC ELD (enhanced low delay AAC)
  • [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, che include USAC Baseline Profile e ISO/IEC 23003-4 Dynamic Range Control Profile)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE, inclusi formati audio ad alta risoluzione fino a 24 bit, frequenza di campionamento di 192 kHz e 8 canali. Tieni presente che questo requisito riguarda solo la decodifica e che un dispositivo può eseguire il downsampling e il downmix durante la fase di riproduzione.
  • [C-1-10] Opus

Se le implementazioni dei dispositivi supportano la decodifica dei buffer di input AAC di stream multicanale (ovvero più di due canali) in PCM tramite il decodificatore audio AAC predefinito nell'API android.media.MediaCodec, deve essere supportato quanto segue:

  • [C-2-1] La decodifica DEVE essere eseguita senza downmix (ad es. uno stream AAC 5.0 DEVE essere decodificato in cinque canali PCM, uno stream AAC 5.1 DEVE essere decodificato in sei canali PCM).
  • [C-2-2] I metadati dell'intervallo dinamico DEVONO essere definiti in "Dynamic Range Control (DRC)" (Controllo dell'intervallo dinamico) nella norma ISO/IEC 14496-3 e le chiavi DRC android.media.MediaFormat per configurare i comportamenti correlati all'intervallo dinamico del decodificatore audio. Le chiavi DRC AAC sono state introdotte nell'API 21 e sono: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_ENCODED_TARGET_LEVEL.
  • [SR] È VIVAMENTE CONSIGLIATO che i requisiti C-2-1 e C-2-2 sopra indicati siano soddisfatti da tutti i decoder audio AAC.

Durante la decodifica dell'audio USAC, MPEG-D (ISO/IEC 23003-4):

  • [C-3-1] I metadati relativi al volume e al DRC DEVONO essere interpretati e applicati in conformità al profilo di controllo della gamma dinamica MPEG-D DRC di livello 1.
  • [C-3-2] Il decoder DEVE comportarsi in base alla configurazione impostata con i seguenti tasti android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_DRC_EFFECT_TYPE.

Decoder dei profili MPEG-4 AAC, HE AAC e HE AACv2:

  • MAY supporta il controllo del volume e della gamma dinamica utilizzando il profilo di controllo della gamma dinamica ISO/IEC 23003-4.

Se ISO/IEC 23003-4 è supportato e se sia i metadati ISO/IEC 23003-4 sia quelli ISO/IEC 14496-3 sono presenti in un bitstream decodificato:

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

Tutti i decoder audio DEVONO supportare l'output di:

5.1.3. Dettagli sui codec audio

Formato/Codec Dettagli Tipi di file/formati contenitore da supportare
Profilo MPEG-4 AAC
(AAC LC) 		Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 8 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC non elaborato ADTS (.aac, ADIF non supportato)
  • MPEG-TS (.ts, non ricercabile, solo decodifica)
  • Matroska (.mkv, solo decodifica)
Profilo MPEG-4 HE AAC (AAC+) Supporto di contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
Profilo MPEG-4 HE AACv2
(AAC+ avanzato) 		Supporto di contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
AAC ELD (AAC a basso ritardo avanzato) Supporto per contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
USAC Supporto di contenuti mono/stereo con frequenze di campionamento standard da 7,35 a 48 kHz. MPEG-4 (.mp4, .m4a)
AMR-NB Da 4,75 a 12,2 kbps campionati a 8 kHz 3GPP (.3gp)
AMR-WB 9 velocità da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz, come definito in AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec 3GPP (.3gp)
FLAC Per il codificatore e il decodificatore: devono essere supportate almeno le modalità Mono e Stereo. Devono essere supportate frequenze di campionamento fino a 192 kHz; devono essere supportate risoluzioni a 16 e 24 bit. La gestione dei dati audio FLAC a 24 bit DEVE essere disponibile con la configurazione audio in virgola mobile.
  • FLAC (.flac)
  • MPEG-4 (.mp4, .m4a, solo decodifica)
  • Matroska (.mkv, solo decodifica)
MP3 Bitrate costante (CBR) o variabile (VBR) mono/stereo 8-320 Kbps
  • MP3 (.mp3)
  • MPEG-4 (.mp4, .m4a, solo decodifica)
  • Matroska (.mkv, solo decodifica)
MIDI MIDI di tipo 0 e 1. DLS versione 1 e 2. XMF e Mobile XMF. Supporto dei formati di suoneria RTTTL/RTX, OTA e iMelody
  • Tipo 0 e 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, solo decodifica)
  • Matroska (.mkv)
  • Webm (.webm)
PCM/WAVE Il codec PCM DEVE supportare PCM lineare a 16 bit e virgola mobile a 16 bit. L'estrattore WAVE DEVE supportare PCM lineare a 16 bit, 24 bit, 32 bit e virgola mobile a 32 bit (frequenze fino al limite dell'hardware). Le frequenze di campionamento DEVONO essere supportate da 8 kHz a 192 kHz. WAVE (.wav)
Opus
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, solo decodifica)
  • Matroska (.mkv)
  • Webm (.webm)

5.1.4. Codifica dell'immagine

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

Le implementazioni dei dispositivi DEVONO supportare la codifica della seguente codifica delle immagini:

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

Se le implementazioni dei dispositivi supportano la codifica HEIC tramite android.media.MediaCodec per il tipo di media MIMETYPE_IMAGE_ANDROID_HEIC:

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

5.1.5. Decodifica dell'immagine

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

Le implementazioni dei dispositivi DEVONO supportare la decodifica della seguente codifica delle immagini:

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Raw
  • [C-0-7] HEIF (HEIC)

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

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

5.1.6. Dettagli sui codec immagine

Formato/Codec Dettagli Tipi di file/formati contenitore supportati
JPEG Base+progressiva 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)

Encoder e decoder di immagini esposti tramite l'API MediaCodec

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

  • [SR] VIVAMENTE CONSIGLIATO di supportare il formato di colore RGB888 per la modalità Surface di input.

  • [C-1-3] DEVE supportare almeno uno dei formati di colore YUV420 8:8:8 planare o semiplanare: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). È FORTEMENTE CONSIGLIATO supportarli entrambi.

5.1.7. Codec video

  • Per una qualità accettabile dei servizi di streaming video sul web e di videoconferenza, le implementazioni dei dispositivi DEVONO utilizzare un codec VP8 hardware che soddisfi i requisiti.

Se le implementazioni del dispositivo includono un codificatore o decodificatore video:

  • [C-1-1] I codec video DEVONO supportare dimensioni di bytebuffer di output e input che contengano il frame compresso e non compresso più grande possibile, come stabilito dallo standard e dalla configurazione, ma senza allocare risorse in eccesso.

  • [C-1-2] I codificatori e decodificatori video DEVONO supportare i formati di colore flessibili YUV420 8:8:8 (COLOR_FormatYUV420Flexible) tramite CodecCapabilities.

  • [C-1-3] I codificatori e decodificatori video DEVONO supportare almeno uno dei formati di colore YUV420 8:8:8 planare o semiplanare: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). È FORTEMENTE CONSIGLIATO supportarli entrambi.

  • [SR] È VIVAMENTE CONSIGLIATO che i codificatori e decodificatori video supportino almeno uno dei formati di colore YUV420 8:8:8 planare o semiplanare ottimizzati per l'hardware (YV12, NV12, NV21 o formato equivalente ottimizzato per il fornitore).

  • [C-1-5] I decoder video che supportano un formato ad alta profondità di bit (9 o più bit per canale) DEVONO supportare l'output di un formato equivalente a 8 bit se richiesto dall'applicazione. Ciò DEVE essere rispecchiato dal supporto di un formato colore YUV420 8:8:8 tramite android.media.MediaCodecInfo.

Se le implementazioni dei dispositivi pubblicizzano il supporto del profilo HDR tramite Display.HdrCapabilities:

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

Se le implementazioni dei dispositivi pubblicizzano il supporto dell'aggiornamento intra-frame tramite FEATURE_IntraRefresh nella classe MediaCodecInfo.CodecCapabilities:

  • [C-3-1] DEVE supportare i periodi di aggiornamento nell'intervallo di 10-60 fotogrammi e funzionare con una precisione del 20% del periodo di aggiornamento configurato.

A meno che l'applicazione non specifichi diversamente utilizzando la chiave di formato KEY_COLOR_FORMAT, le implementazioni del decodificatore video:

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

5.1.8. Elenco dei codec video

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

5.1.9. Sicurezza dei codec multimediali

Le implementazioni dei dispositivi DEVONO garantire la conformità alle funzionalità di sicurezza dei codec multimediali, come descritto di seguito.

Android include il supporto per OMX, un'API di accelerazione multimediale cross-platform, nonché Codec 2.0, un'API di accelerazione multimediale a basso overhead.

Se le implementazioni dei dispositivi supportano i contenuti multimediali:

  • [C-1-1] DEVE fornire supporto per i codec multimediali tramite le API OMX o Codec 2.0 (o entrambe) come in Android Open Source Project e non disattivare o aggirare le protezioni di sicurezza. Ciò non significa che ogni codec DEVE utilizzare l'API OMX o Codec 2.0, ma solo che il supporto di almeno una di queste API DEVE essere disponibile e che il supporto delle API disponibili DEVE includere le protezioni di sicurezza presenti.
  • [C-SR] Are STRONGLY RECOMMENDED to include support for Codec 2.0 API.

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

  • [C-2-1] DEVE includere il codec software OMX corrispondente dell'Android Open Source Project (se disponibile) per ogni formato e tipo di media (codificatore o decodificatore) supportato dal dispositivo.
  • [C-2-2] Codec con nomi che iniziano con "OMX.google." DEVE basarsi sul codice sorgente di Android Open Source Project.
  • [C-SR] È VIVAMENTE CONSIGLIATO che i codec software OMX vengano eseguiti in un processo di codec che non ha accesso a driver hardware diversi dai mapper di memoria.

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

  • [C-3-1] DEVE includere il codec software Codec 2.0 corrispondente dal progetto Android Open Source (se disponibile) per ogni formato e tipo di media (codificatore o decodificatore) supportato dal dispositivo.
  • [C-3-2] DEVE ospitare i codec software Codec 2.0 nel processo di codec software come fornito in Android Open Source Project per consentire di concedere l'accesso ai codec software in modo più specifico.
  • [C-3-3] Codec con nomi che iniziano con "c2.android." DEVE basarsi sul codice sorgente di Android Open Source Project.

5.1.10. Caratterizzazione del codec multimediale

Se le implementazioni dei dispositivi supportano i codec multimediali:

  • [C-1-1] DEVE restituire i valori corretti della caratterizzazione del codec multimediale tramite l'API MediaCodecInfo.

In particolare:

  • [C-1-2] Codec con nomi che iniziano con "OMX." DEVE utilizzare le API OMX e avere nomi conformi alle linee guida per la denominazione OMX IL.
  • [C-1-3] Codec con nomi che iniziano con "c2." DEVE utilizzare l'API Codec 2.0 e avere nomi conformi alle linee guida per la denominazione di Codec 2.0 per Android.
  • [C-1-4] Codec con nomi che iniziano con "OMX.google." o "c2.android." NON DEVE essere caratterizzato come fornitore o come accelerato dall'hardware.
  • [C-1-5] I codec eseguiti in un processo codec (fornitore o sistema) che hanno accesso a driver hardware diversi da allocatori e mapper di memoria NON DEVONO essere caratterizzati come solo software.
  • [C-1-6] I codec non presenti in Android Open Source Project o non basati sul codice sorgente di questo progetto DEVONO essere caratterizzati come fornitori.
  • [C-1-7] I codec che utilizzano l'accelerazione hardware DEVONO essere caratterizzati come accelerati dall'hardware.
  • [C-1-8] I nomi dei codec NON DEVONO essere fuorvianti. Ad esempio, i codec denominati "decoder" DEVONO supportare la decodifica, mentre quelli denominati "encoder" DEVONO supportare la codifica. I codec con nomi contenenti formati multimediali DEVONO supportare questi formati.

Se le implementazioni del dispositivo supportano i codec video:

  • [C-2-1] Tutti i codec video DEVONO pubblicare i dati relativi al frame rate raggiungibile per le seguenti dimensioni, se supportate dal codec:
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p UHD
Risoluzione video
  • 176 x 144 px (H263, MPEG2, MPEG4)
  • 352 x 288 px (codificatore 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)
  • 1408 x 1152 px (H263)
  • 1280 x 720 px (altro)
1920 x 1080 px (diverso da MPEG4) 3840 x 2160 px (HEVC, VP9)
  • [C-2-2] I codec video caratterizzati come accelerati dall'hardware DEVONO pubblicare informazioni sui punti di rendimento. Devono elencare tutti i punti di rendimento standard supportati (elencati nell'API PerformancePoint), a meno che non siano coperti da un altro punto di rendimento standard supportato.
  • Inoltre, DEVONO pubblicare punti di prestazioni estesi se supportano prestazioni video sostenute diverse da quelle standard elencate.

5.2. Codifica video

Se le implementazioni dei dispositivi supportano un codificatore video e lo rendono disponibile ad app di terze parti:

  • NON DEVE superare il 15% del bitrate tra gli intervalli intraframe (I-frame) in due finestre scorrevoli.
  • NON DEVE superare il 100% del bitrate in una finestra mobile di 1 secondo.

Se le implementazioni del dispositivo includono un display integrato con una lunghezza diagonale di almeno 6,35 cm o includono una porta di uscita video o dichiarano il supporto di una videocamera tramite il flag di funzionalità android.hardware.camera.any,

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

Se le implementazioni dei dispositivi supportano uno qualsiasi dei codificatori video H.264, VP8, VP9 o HEVC e lo rendono disponibile ad applicazioni di terze parti:

  • [C-2-1] DEVE supportare bitrate configurabili in modo dinamico.
  • DEVE supportare frequenze fotogrammi variabili, in cui il codificatore video DEVE determinare la durata istantanea del fotogramma in base ai timestamp dei buffer di input e allocare il bucket di bit in base a questa durata del fotogramma.

Se le implementazioni dei dispositivi supportano il codificatore video MPEG-4 SP e lo rendono disponibile per le app di terze parti:

  • DEVE supportare bit rate configurabili dinamicamente per il codificatore supportato.

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

  • [C-4-1] tutti i codificatori video e immagini con accelerazione hardware DEVONO supportare la codifica dei frame delle videocamere hardware.
  • DEVE supportare la codifica dei frame dalle videocamere hardware tramite tutti i codificatori video o di immagini.

5.2.1. H.263

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

  • [C-1-1] DEVE supportare il profilo di base di livello 45.
  • DEVE supportare bit rate configurabili dinamicamente per il codificatore supportato.

5.2.2. H.264

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

  • [C-1-1] DEVE supportare il profilo di base di livello 3. Tuttavia, il supporto di ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) e RS (Redundant Slices) è FACOLTATIVO. Inoltre, per mantenere la compatibilità con altri dispositivi Android, è CONSIGLIATO che ASO, FMO e RS non vengano utilizzati per il profilo di base dai codificatori.
  • [C-1-2] DEVE supportare i profili di codifica video SD (definizione standard) nella tabella seguente.
  • DEVE supportare il profilo principale di livello 4.
  • DEVE supportare i profili di codifica video HD (alta definizione) come indicato nella tabella seguente.

Se le implementazioni dei dispositivi segnalano il supporto della codifica H.264 per i video con risoluzione 720p o 1080p tramite le API multimediali,

  • [C-2-1] DEVE supportare i profili di codifica nella tabella seguente.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p
Risoluzione video 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
Frequenza fotogrammi video 20 f/s 30 fps 30 fps 30 fps
Velocità in bit video 384 kbps 2 Mbps 4 Mbps 10 Mbps

5.2.3. VP8

Se le implementazioni dei dispositivi supportano il codec VP8:

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

Se le implementazioni dei dispositivi segnalano il supporto della codifica VP8 per i video con risoluzione 720p o 1080p tramite le API Media,

  • [C-2-1] DEVE supportare i profili di codifica nella tabella seguente.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p
Risoluzione video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Frequenza fotogrammi video 30 fps 30 fps 30 fps 30 fps
Velocità in bit video 800 kbps 2 Mbps 4 Mbps 10 Mbps

5.2.4. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

  • [C-1-2] DEVE supportare il profilo 0 livello 3.
  • [C-1-1] DEVE supportare la scrittura di file Matroska WebM.
  • [C-1-3] DEVE generare dati CodecPrivate.
  • DEVE supportare i profili di decodifica HD indicati nella tabella seguente.
  • [SR] sono FORTEMENTE CONSIGLIATI per supportare i profili di decodifica HD, come indicato nella tabella seguente, se è presente un codificatore hardware.
SD HD 720p HD 1080p UHD
Risoluzione video 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
Frequenza fotogrammi video 30 fps 30 fps 30 fps 30 fps
Velocità in bit video 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

Se le implementazioni dei dispositivi dichiarano di supportare il profilo 2 o il profilo 3 tramite le API Media:

  • Il supporto del formato a 12 bit è FACOLTATIVO.

5.2.5. H.265

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

  • [C-1-1] DEVE supportare il livello 3 del profilo principale.
  • DEVE supportare i profili di codifica HD come indicato nella tabella seguente.
  • [SR] sono FORTEMENTE CONSIGLIATI per supportare i profili di codifica HD, come indicato nella tabella seguente, se è presente un codificatore hardware.
SD HD 720p HD 1080p UHD
Risoluzione video 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
Frequenza fotogrammi video 30 fps 30 fps 30 fps 30 fps
Velocità in bit video 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.3. Decodifica video

Se le implementazioni dei dispositivi supportano i codec VP8, VP9, H.264 o H.265:

  • [C-1-1] DEVE supportare il cambio dinamico della risoluzione video e del frame rate tramite le API Android standard all'interno dello stesso stream per tutti i codec VP8, VP9, H.264 e H.265 in tempo reale e fino alla risoluzione massima supportata da ciascun codec sul dispositivo.

5.3.1. MPEG-2

Se le implementazioni dei dispositivi supportano i decoder MPEG-2:

  • [C-1-1] DEVE supportare il profilo principale di alto livello.

5.3.2. H.263

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

  • [C-1-1] DEVE supportare il profilo di base di livello 30 e 45.

5.3.3. MPEG-4

Se le implementazioni del dispositivo con decoder MPEG-4:

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

5.3.4. H.264

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

  • [C-1-1] DEVE supportare il profilo principale di livello 3.1 e il profilo di base. Il supporto di ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) e RS (Redundant Slices) è FACOLTATIVO.
  • [C-1-2] DEVE essere in grado di decodificare i video con i profili SD (Standard Definition) elencati nella tabella seguente e codificati con il profilo di base e il profilo principale di livello 3.1 (incluso 720p30).
  • DEVE essere in grado di decodificare i video con i profili HD (alta definizione) come indicato nella tabella seguente.

Se l'altezza segnalata dal metodo Display.getSupportedModes() è uguale o maggiore della risoluzione video, le implementazioni del dispositivo:

  • [C-2-1] DEVE supportare i profili di decodifica video HD 720p nella tabella seguente.
  • [C-2-2] DEVE supportare i profili di decodifica video HD 1080p nella tabella seguente.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p
Risoluzione video 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
Frequenza fotogrammi video 30 fps 30 fps 60 FPS 30 fps (60 fpsTelevisione)
Velocità in bit video 800 kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5. H.265 (HEVC)

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

  • [C-1-1] DEVE supportare il profilo principale, livello 3, livello principale e i profili di decodifica video SD come indicato nella tabella seguente.
  • DEVE supportare i profili di decodifica HD indicati nella tabella seguente.
  • [C-1-2] DEVE supportare i profili di decodifica HD indicati nella tabella seguente se è presente un decoder hardware.

Se l'altezza segnalata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione del video:

  • [C-2-1] Le implementazioni dei dispositivi DEVONO supportare almeno una delle decodifiche H.265 o VP9 dei profili 720, 1080 e UHD.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p UHD
Risoluzione video 352 x 288 px 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
Frequenza fotogrammi video 30 fps 30 fps 30 fps 30/60 fps (60 fpsTelevisione con decodifica hardware H.265) 60 FPS
Velocità in bit video 600 kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

Se le implementazioni dei dispositivi dichiarano di supportare un profilo HDR (HEVCProfileMain10HDR10, HEVCProfileMain10HDR10Plus) tramite le API Media:

  • [C-3-1] Le implementazioni dei dispositivi DEVONO accettare i metadati HDR richiesti (MediaFormat#KEY_HDR_STATIC_INFO per tutti i profili HDR) dall'applicazione utilizzando l'API MediaCodec, nonché supportare l'estrazione dei metadati HDR richiesti (MediaFormat#KEY_HDR_STATIC_INFO per tutti i profili HDR, nonché MediaFormat#KEY_HDR10_PLUS_INFO per i profili HDR10+) dal bitstream e/o dal contenitore come definito dalle specifiche pertinenti. Devono inoltre supportare l'output dei metadati HDR richiesti (MediaFormat#KEY_HDR_STATIC_INFO per tutti i profili HDR) dal bitstream e/o dal contenitore come definito dalle specifiche pertinenti.

  • [C-SR] È VIVAMENTE CONSIGLIATO che le implementazioni dei dispositivi supportino l'output dei metadati MediaFormat#KEY_HDR10_PLUS_INFO per i profili HDR10+ tramite MediaCodec#getOutputFormat(int).

  • [C-3-2] Le implementazioni del dispositivo DEVONO visualizzare correttamente i contenuti HDR per il profilo HEVCProfileMain10HDR10 sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

  • [C-SR] È VIVAMENTE CONSIGLIATO implementare i dispositivi per visualizzare correttamente i contenuti HDR per il profilo HEVCProfileMain10HDR10Plus sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

5.3.6. VP8

Se le implementazioni dei dispositivi supportano il codec VP8:

  • [C-1-1] DEVE supportare i profili di decodifica SD nella tabella seguente.
  • DEVE utilizzare un codec VP8 hardware che soddisfi i requisiti.
  • DEVE supportare i profili di decodifica HD nella tabella seguente.

Se l'altezza segnalata dal metodo Display.getSupportedModes() è uguale o maggiore della risoluzione video:

  • [C-2-1] Le implementazioni dei dispositivi DEVONO supportare i profili 720p nella tabella seguente.
  • [C-2-2] Le implementazioni dei dispositivi DEVONO supportare i profili 1080p nella tabella seguente.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p
Risoluzione video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Frequenza fotogrammi video 30 fps 30 fps 30 fps (60 fpsTelevisione) 30 (60 fpsTelevisione)
Velocità in bit video 800 kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

  • [C-1-1] DEVE supportare i profili di decodifica video SD indicati nella tabella seguente.
  • DEVE supportare i profili di decodifica HD indicati nella tabella seguente.

Se le implementazioni del dispositivo supportano il codec VP9 e un decoder hardware:

  • [C-2-1] DEVE supportare i profili di decodifica HD indicati nella tabella seguente.

Se l'altezza segnalata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione del video:

  • [C-3-1] Le implementazioni dei dispositivi DEVONO supportare almeno una delle decodifiche VP9 o H.265 dei profili 720, 1080 e UHD.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p UHD
Risoluzione video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
Frequenza fotogrammi video 30 fps 30 fps 30 fps 30 fps (60 fpsTV con decodifica hardware VP9) 60 FPS
Velocità in bit video 600 kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

Se le implementazioni dei dispositivi dichiarano di supportare VP9Profile2 o VP9Profile3 tramite le API multimediali 'CodecProfileLevel':

  • Il supporto del formato a 12 bit è FACOLTATIVO.

Se le implementazioni dei dispositivi dichiarano di supportare un profilo HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) tramite le API Media:

  • [C-4-1] Le implementazioni dei dispositivi DEVONO accettare i metadati HDR richiesti (MediaFormat#KEY_HDR_STATIC_INFO per tutti i profili HDR, nonché il parametro MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO per i profili HDR10Plus) dall'applicazione utilizzando l'API MediaCodec, nonché supportare l'estrazione dei metadati HDR richiesti (MediaFormat#KEY_HDR_STATIC_INFO per tutti i profili HDR, nonché MediaFormat#KEY_HDR10_PLUS_INFO per i profili HDR10Plus) dal bitstream e/o dal contenitore come definito dalle specifiche pertinenti. Devono inoltre supportare l'output dei metadati HDR richiesti (MediaFormat#KEY_HDR_STATIC_INFO per tutti i profili HDR) dal bitstream e/o dal contenitore come definito dalle specifiche pertinenti.

  • [C-4-2] Le implementazioni del dispositivo DEVONO visualizzare correttamente i contenuti HDR per i profili VP9Profile2HDR e VP9Profile3HDR sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

  • [C-SR] È FORTEMENTE CONSIGLIATO che le implementazioni dei dispositivi supportino l'output dei metadati MediaFormat#KEY_HDR10_PLUS_INFO per i profili HDR10Plus tramite MediaCodec#getOutputFormat(int).

  • [C-SR] È FORTEMENTE CONSIGLIATO che le implementazioni dei dispositivi visualizzino correttamente i contenuti HDR per i profili VP9Profile2HDR10Plus e VP9Profile3HDR10Plus sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

5.3.8. Dolby Vision

Se le implementazioni dei dispositivi dichiarano il supporto del decodificatore Dolby Vision tramite HDR_TYPE_DOLBY_VISION:

  • [C-1-1] DEVE fornire un estrattore compatibile con Dolby Vision.
  • [C-1-2] DEVE visualizzare correttamente i contenuti Dolby Vision sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).
  • [C-1-3] DEVE impostare l'indice della traccia dei livelli base compatibili con le versioni precedenti (se presenti) in modo che corrisponda all'indice della traccia del livello Dolby Vision combinato.

5.3.9. AV1

Se le implementazioni dei dispositivi supportano il codec AV1:

  • [C-1-1] DEVE supportare il profilo 0, inclusi i contenuti a 10 bit.

5.4. Registrazione audio

Sebbene alcuni dei requisiti descritti in questa sezione siano elencati come SHOULD a partire da Android 4.3, è previsto che la definizione di compatibilità per le versioni future li modifichi in MUST. È VIVAMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti elencati come SHOULD, altrimenti non potranno ottenere la compatibilità con Android quando verranno aggiornati alla versione futura.

5.4.1. Acquisizione audio grezzo e informazioni sul microfono

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

  • [C-1-1] DEVE consentire l'acquisizione di contenuti audio non elaborati con le seguenti caratteristiche:

    • Formato: PCM lineare, 16 bit
    • Frequenze di campionamento: 8000, 11025, 16000, 44100, 48000 Hz
    • Canali: mono

  • DEVE consentire l'acquisizione di contenuti audio non elaborati con le seguenti caratteristiche:

    • Formato: PCM lineare, 16 bit e 24 bit
    • Frequenze di campionamento: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
    • Canali: tanti canali quanti sono i microfoni sul dispositivo

  • [C-1-2] DEVE acquisire a frequenze di campionamento superiori senza upsampling.

  • [C-1-3] DEVE includere un filtro anti-aliasing appropriato quando le frequenze di campionamento indicate sopra vengono acquisite con il downsampling.

  • DEVE consentire l'acquisizione di contenuti audio grezzi con qualità radio AM e DVD, il che significa che devono avere le seguenti caratteristiche:

    • Formato: PCM lineare, 16 bit
    • Frequenze di campionamento: 22050, 48000 Hz
    • Canali: stereo

  • [C-1-4] DEVE rispettare l'API MicrophoneInfo e compilare correttamente le informazioni per i microfoni disponibili sul dispositivo accessibili alle applicazioni di terze parti tramite l'API AudioManager.getMicrophones() e i microfoni attualmente attivi accessibili alle applicazioni di terze parti tramite le API AudioRecord.getActiveMicrophones() e MediaRecorder.getActiveMicrophones(). Se le implementazioni del dispositivo consentono la radio AM e l'acquisizione di contenuti audio grezzi di qualità DVD:

  • [C-2-1] DEVE acquisire senza upsampling a qualsiasi rapporto superiore a 16000:22050 o 44100:48000.

  • [C-2-2] DEVE includere un filtro anti-aliasing appropriato per qualsiasi upsampling o downsampling.

5.4.2. Acquisizione per il riconoscimento vocale

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

  • [C-1-1] DEVE acquisire la sorgente audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION a una delle frequenze di campionamento, 44100 e 48000.
  • [C-1-2] DEVE, per impostazione predefinita, disattivare qualsiasi elaborazione audio di riduzione del rumore durante la registrazione di uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
  • [C-1-3] DEVE, per impostazione predefinita, disattivare qualsiasi controllo automatico del guadagno durante la registrazione di un flusso audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
  • DEVE registrare il flusso audio del riconoscimento vocale con caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte: in particolare, ±3 dB, da 100 Hz a 4000 Hz.
  • DEVE registrare il flusso audio del riconoscimento vocale con una sensibilità di input impostata in modo che una sorgente con un livello di potenza sonora (SPL) di 90 dB a 1000 Hz produca un valore RMS di 2500 per campioni a 16 bit.
  • DEVE registrare il flusso audio del riconoscimento vocale in modo che i livelli di ampiezza PCM traccino linearmente le variazioni del livello di pressione sonora di ingresso in un intervallo di almeno 30 dB da -18 dB a +12 dB rispetto a 90 dB SPL sul microfono.
  • DEVE registrare il flusso audio del riconoscimento vocale con distorsione armonica totale (THD) inferiore all'1% per 1 kHz a un livello di ingresso di 90 dB SPL al microfono.

Se le implementazioni dei dispositivi dichiarano android.hardware.microphone e tecnologie di soppressione (riduzione) del rumore ottimizzate per il riconoscimento vocale:

  • [C-2-1] DEVE consentire il controllo di questo effetto audio con l'API android.media.audiofx.NoiseSuppressor.
  • [C-2-2] DEVE identificare in modo univoco ogni implementazione della tecnologia di soppressione del rumore tramite il campo AudioEffect.Descriptor.uuid.

5.4.3. Acquisizione per il reindirizzamento della riproduzione

La classe android.media.MediaRecorder.AudioSource include la sorgente audio REMOTE_SUBMIX.

Se le implementazioni del dispositivo dichiarano sia android.hardware.audio.output sia android.hardware.microphone:

  • [C-1-1] DEVE implementare correttamente la sorgente audio REMOTE_SUBMIX in modo che quando un'applicazione utilizza l'API android.media.AudioRecord per registrare da questa sorgente audio, acquisisca un mix di tutti i flussi audio, ad eccezione di quanto segue:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.4.4. Acoustic Echo Canceler

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

  • DEVE implementare una tecnologia di cancellazione dell'eco acustico (AEC) ottimizzata per la comunicazione vocale e applicata al percorso di acquisizione quando si acquisisce utilizzando AudioSource.VOICE_COMMUNICATION

Se le implementazioni del dispositivo forniscono un Acoustic Echo Canceler che viene inserito nel percorso audio di acquisizione quando è selezionato AudioSource.VOICE_COMMUNICATION, queste:

5.4.5. Acquisizione simultanea

Se le implementazioni del dispositivo dichiarano android.hardware.microphone,DEVONO implementare l'acquisizione simultanea come descritto in questo documento . Nello specifico:

  • [C-1-1] DEVE consentire l'accesso simultaneo al microfono da parte di un servizio di accessibilità che acquisisce con AudioSource.VOICE_RECOGNITION e di almeno un'applicazione che acquisisce con qualsiasi AudioSource.
  • [C-1-2] DEVE consentire l'accesso simultaneo al microfono da parte di un'applicazione preinstallata che detiene un ruolo di assistente e di almeno un'applicazione che acquisisce con qualsiasi AudioSource, ad eccezione di AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER.
  • [C-1-3] DEVE disattivare l'acquisizione audio per qualsiasi altra applicazione, ad eccezione di un servizio di accessibilità, mentre un'applicazione acquisisce con AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER. Tuttavia, quando un'app acquisisce tramite AudioSource.VOICE_COMMUNICATION, un'altra app può acquisire la chiamata vocale se è un'app privilegiata (preinstallata) con l'autorizzazione CAPTURE_AUDIO_OUTPUT.
  • [C-1-4] Se due o più applicazioni acquisiscono contemporaneamente e nessuna delle due ha un'interfaccia utente in primo piano, quella che ha avviato l'acquisizione più di recente riceve l'audio.

5.4.6. Livelli di guadagno del microfono

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

  • DEVE mostrare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte nella gamma di frequenza media: in particolare ±3 dB da 100 Hz a 4000 Hz per ogni microfono utilizzato per registrare la sorgente audio del riconoscimento vocale.
  • DEVE impostare la sensibilità dell'input audio in modo che una sorgente di tono sinusoidale a 1000 Hz riprodotta a un livello di pressione sonora (SPL) di 90 dB produca una risposta con RMS di 2500 per campioni a 16 bit (o -22,35 dB a fondo scala per campioni in virgola mobile/a doppia precisione) per ogni microfono utilizzato per registrare la sorgente audio di riconoscimento vocale.
  • [C-SR] sono FORTEMENTE CONSIGLIATI per mostrare livelli di ampiezza nella gamma di basse frequenze: in particolare da ±20 dB da 5 Hz a 100 Hz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio del riconoscimento vocale.
  • [C-SR] è VIVAMENTE CONSIGLIATO di mostrare livelli di ampiezza nella gamma di alte frequenze: in particolare da ±30 dB da 4000 Hz a 22 kHz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio del riconoscimento vocale.

5.5. Riproduzione audio

Android include il supporto per consentire alle app di riprodurre l'audio tramite la periferica di uscita audio come definito nella sezione 7.8.2.

5.5.1. Riproduzione audio grezzo

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

  • [C-1-1] DEVE consentire la riproduzione di contenuti audio non elaborati con le seguenti caratteristiche:

    • Formati sorgente: PCM lineare, 16 bit, 8 bit, virgola mobile
    • Canali: mono, stereo, configurazioni multicanale valide con un massimo di 8 canali
    • Frequenze di campionamento (in Hz):
      • 8000, 11025, 16000, 22050, 32000, 44100, 48000 nelle configurazioni dei canali elencate sopra
      • 96000 in mono e stereo

  • DOVREBBE consentire la riproduzione di contenuti audio non elaborati con le seguenti caratteristiche:

    • Frequenze di campionamento: 24000

5.5.2. Effetti audio

Android fornisce un'API per gli effetti audio per le implementazioni dei dispositivi.

Se le implementazioni del dispositivo dichiarano la funzionalità android.hardware.audio.output:

  • [C-1-1] DEVE supportare le implementazioni EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controllabili tramite le sottoclassi AudioEffect Equalizer e LoudnessEnhancer.
  • [C-1-2] DEVE supportare l'implementazione dell'API Visualizer, controllabile tramite la classe Visualizer.
  • [C-1-3] DEVE supportare l'implementazione di EFFECT_TYPE_DYNAMICS_PROCESSING controllabile tramite la sottoclasse AudioEffect DynamicsProcessing.
  • DEVE supportare le implementazioni EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controllabili tramite le sottoclassi AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.
  • [C-SR] Sono VIVAMENTE CONSIGLIATI per supportare gli effetti in virgola mobile e multicanale.

5.5.3. Volume di uscita audio

Implementazioni di dispositivi per il settore automotive:

  • DOVREBBE consentire la regolazione separata del volume audio per ogni flusso audio utilizzando il tipo di contenuto o l'utilizzo definito da AudioAttributes e l'utilizzo dell'audio dell'auto come definito pubblicamente in android.car.CarAudioManager.

5.6. Latenza audio

La latenza audio è il ritardo di tempo che si verifica quando un segnale audio passa attraverso un sistema. Molte classi di applicazioni si basano su latenze brevi per ottenere effetti sonori in tempo reale.

Ai fini di questa sezione, utilizza le seguenti definizioni:

  • latenza di output. L'intervallo tra il momento in cui un'applicazione scrive un frame di dati codificati in PCM e il momento in cui il suono corrispondente viene presentato all'ambiente in un trasduttore on-device o il segnale esce dal dispositivo tramite una porta e può essere osservato esternamente.
  • Latenza di output a freddo. La latenza di output per il primo frame, quando il sistema di output audio è rimasto inattivo e spento prima della richiesta.
  • latenza di output continua. La latenza di output per i frame successivi, dopo che il dispositivo riproduce l'audio.
  • Latenza input. L'intervallo tra il momento in cui un suono viene presentato dall'ambiente al dispositivo in un trasduttore on-device o il momento in cui un segnale entra nel dispositivo tramite una porta e il momento in cui un'applicazione legge il frame corrispondente di dati codificati in PCM.
  • input perso. La parte iniziale di un segnale di input inutilizzabile o non disponibile.
  • Latenza di input a freddo. La somma del tempo di input perso e della latenza di input per il primo frame, quando il sistema di input audio è stato inattivo e spento prima della richiesta.
  • latenza input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.
  • cold output jitter. La variabilità tra misurazioni separate dei valori di latenza di output a freddo.
  • jitter di input a freddo. La variabilità tra misurazioni separate dei valori di latenza di input a freddo.
  • latenza di andata e ritorno continua. La somma della latenza di input continua, della latenza di output continua e di un periodo di buffer. Il periodo di buffer consente all'app di elaborare il segnale e di attenuare la differenza di fase tra i flussi di input e output.
  • API OpenSL ES PCM buffer queue. Il set di API OpenSL ES correlate a PCM all'interno di Android NDK.
  • API audio nativa AAudio. Il set di API AAudio all'interno di Android NDK.
  • timestamp. Una coppia costituita da una posizione relativa del frame all'interno di un flusso e dall'ora stimata in cui il frame entra o esce dalla pipeline di elaborazione audio sull'endpoint associato. Vedi anche AudioTimestamp.
  • glitch. Un'interruzione temporanea o un valore di esempio errato nel segnale audio, in genere causato da un buffer underrun per l'output, da un buffer overrun per l'input o da qualsiasi altra fonte di rumore digitale o analogico.

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

  • [C-1-1] Il timestamp di output restituito da AudioTrack.getTimestamp e AAudioStream_getTimestamp è preciso con un margine di errore di +/- 2 ms.
  • [C-1-2] Latenza di output a freddo pari o inferiore a 500 millisecondi.

Se le implementazioni del dispositivo dichiarano android.hardware.audio.output, è FORTEMENTE CONSIGLIATO che soddisfino o superino i seguenti requisiti:

  • [C-SR] Latenza di output a freddo pari o inferiore a 100 millisecondi. È VIVAMENTE CONSIGLIATO che i dispositivi esistenti e nuovi che eseguono questa versione di Android soddisfino questi requisiti ora. In una versione futura della piattaforma nel 2021, la latenza di output a freddo di 200 ms o inferiore sarà un requisito OBBLIGATORIO.
  • [C-SR] Latenza di uscita continua di 45 millisecondi o meno.
  • [C-SR] Ridurre al minimo il jitter dell'output freddo.
  • [C-SR] Il timestamp di output restituito da AudioTrack.getTimestamp e AAudioStream_getTimestamp è preciso con un margine di errore di +/- 1 ms.

Se le implementazioni dei dispositivi soddisfano i requisiti sopra indicati, dopo la calibrazione iniziale, quando si utilizzano sia la coda del buffer PCM OpenSL ES sia le API audio native AAudio, per la latenza di output continua e la latenza di output a freddo su almeno un dispositivo di output audio supportato, sono:

Se le implementazioni dei dispositivi non soddisfano i requisiti per l'audio a bassa latenza tramite la coda del buffer PCM OpenSL ES e le API audio native AAudio:

  • [C-2-1] NON DEVE segnalare il supporto dell'audio a bassa latenza.

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

  • [C-3-1] Limita l'errore nei timestamp di input, restituiti da AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 2 ms. Per "errore" si intende la deviazione dal valore corretto.
  • [C-3-2] Latenza di input a freddo pari o inferiore a 500 millisecondi.

Se le implementazioni dei dispositivi includono android.hardware.microphone, è VIVAMENTE CONSIGLIATO che soddisfino questi requisiti audio di input:

  • [C-SR] Latenza di input a freddo pari o inferiore a 100 millisecondi. È VIVAMENTE CONSIGLIATO che i dispositivi esistenti e nuovi che eseguono questa versione di Android soddisfino questi requisiti ora. In una futura release della piattaforma nel 2021, la latenza di input a freddo di 200 ms o inferiore sarà un requisito OBBLIGATORIO.
  • [C-SR] Latenza di input continua di 30 millisecondi o meno.
  • [C-SR] Latenza nel tempo di round trip continua pari o inferiore a 50 millisecondi.
  • [C-SR] Minimizza il jitter dell'input freddo.
  • [C-SR] Limita l'errore nei timestamp di input, restituiti da AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 1 ms.

5.7. Protocolli di rete

Le implementazioni del dispositivo DEVONO supportare i protocolli di rete multimediale per la riproduzione audio e video, come specificato nella documentazione dell'SDK Android.

Se le implementazioni dei dispositivi includono un decoder audio o video:

  • [C-1-1] DEVE supportare tutti i codec e i formati contenitore richiesti nella sezione 5.1 tramite HTTP(S).

  • [C-1-2] DEVE supportare i formati dei segmenti multimediali mostrati nella tabella Formati dei segmenti multimediali di seguito tramite il protocollo bozza HTTP Live Streaming, versione 7.

  • [C-1-3] DEVE supportare il seguente profilo audio/video RTP e i codec correlati nella tabella RTSP riportata di seguito. Per le eccezioni, consulta le note a piè di pagina della tabella nella sezione 5.1.

Formati dei segmenti multimediali

Formati dei segmenti Riferimento/i Supporto codec obbligatorio
Stream di trasporto MPEG-2 ISO 13818 Codec video:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Per informazioni dettagliate su H264 AVC, MPEG2-4 SP
e MPEG-2,vedi la sezione 5.1.3.

Codec audio:

  • AAC
Per informazioni dettagliate su AAC e sulle relative varianti, consulta la sezione 5.1.1.
AAC con framing ADTS e tag ID3 ISO 13818-7 Per informazioni dettagliate su AAC e sulle relative varianti, consulta la sezione 5.1.1.
WebVTT WebVTT

RTSP (RTP, SDP)

Nome del profilo Riferimento/i Supporto codec obbligatorio
H264 AVC RFC 6184 Per informazioni dettagliate su H264 AVC, consulta la sezione 5.1.3.
MP4A-LATM RFC 6416 Per informazioni dettagliate su AAC e sulle relative varianti, consulta la sezione 5.1.1.
H263-1998 RFC 3551
RFC 4629
RFC 2190 		Per informazioni dettagliate su H263, consulta la sezione 5.1.3.
H263-2000 RFC 4629 Per informazioni dettagliate su H263, consulta la sezione 5.1.3.
AMR RFC 4867 Per informazioni dettagliate su AMR-NB, consulta la sezione 5.1.1.
AMR-WB RFC 4867 Per informazioni dettagliate su AMR-WB, consulta la sezione 5.1.1.
MP4V-ES RFC 6416 Per informazioni dettagliate su MPEG-4 SP, consulta la sezione 5.1.3.
mpeg4-generic RFC 3640 Per informazioni dettagliate su AAC e sulle relative varianti, consulta la sezione 5.1.1.
MP2T RFC 2250 Per i dettagli, vedi Flusso di trasporto MPEG-2 in HTTP Live Streaming.

5.8. Secure Media

Se le implementazioni dei dispositivi supportano l'uscita video sicura e sono in grado di supportare le superfici sicure:

  • [C-1-1] DEVE dichiarare il supporto di Display.FLAG_SECURE.

Se le implementazioni del dispositivo dichiarano il supporto di Display.FLAG_SECURE e supportano il protocollo di visualizzazione wireless:

  • [C-2-1] DEVE proteggere il collegamento con un meccanismo crittograficamente sicuro come HDCP 2.x o versioni successive per i display collegati tramite protocolli wireless come Miracast.

Se le implementazioni dei dispositivi dichiarano il supporto di Display.FLAG_SECURE e supportano un display esterno cablato:

  • [C-3-1] DEVE supportare HDCP 1.2 o versioni successive per tutti i display esterni collegati tramite una porta cablata accessibile all'utente.

5.9. Musical Instrument Digital Interface (MIDI)

Se le implementazioni dei dispositivi segnalano il supporto della funzionalità android.software.midi tramite la classe android.content.pm.PackageManager:

  • [C-1-1] DEVE supportare MIDI su tutti i trasporti hardware compatibili con MIDI per i quali fornisce connettività generica non MIDI, dove questi trasporti sono:

  • [C-1-2] DEVE supportare il trasporto software MIDI tra app (dispositivi MIDI virtuali)

  • [C-1-3] DEVE includere libamidi.so (supporto MIDI nativo)

5.10. Audio professionale

Se le implementazioni dei dispositivi segnalano il supporto della funzionalità android.hardware.audio.pro tramite la classe android.content.pm.PackageManager,

  • [C-1-1] DEVE segnalare il supporto per la funzionalità android.hardware.audio.low_latency.
  • [C-1-2] DEVE avere una latenza audio di andata e ritorno continua, come definita nella sezione 5.6 Latenza audio, pari o inferiore a 20 millisecondi e DOVREBBE essere pari o inferiore a 10 millisecondi su almeno un percorso supportato.
  • [C-1-3] DEVE includere una o più porte USB che supportano la modalità host USB e la modalità periferica USB.
  • [C-1-4] DEVE segnalare il supporto della funzionalità android.software.midi.
  • [C-1-5] DEVE soddisfare i requisiti di latenza e audio USB utilizzando sia l'API di coda del buffer PCM OpenSL ES sia almeno un percorso dell'API AAudio native audio.
  • [SR] È VIVAMENTE CONSIGLIATO di soddisfare i requisiti di latenza e audio USB utilizzando l'API AAudio native audio anziché il percorso MMAP.
  • [C-1-6] DEVE avere una latenza di output freddo pari o inferiore a 200 millisecondi.
  • [C-1-7] DEVE avere una latenza di input a freddo pari o inferiore a 200 millisecondi.
  • [SR] Sono FORTEMENTE CONSIGLIATI per fornire un livello costante di prestazioni della CPU mentre l'audio è attivo e il carico della CPU varia. Questo test DOVREBBE essere eseguito utilizzando la versione dell'app per Android di SynthMark con l'ID commit 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. SynthMark utilizza un sintetizzatore software in esecuzione su un framework audio simulato che misura le prestazioni del sistema. L'app SynthMark deve essere eseguita utilizzando l'opzione "Test automatico" e ottenere i seguenti risultati:
    • voicemark.90 >= 32 voci
    • latencymark.fixed.little <= 15 msec
    • latencymark.dynamic.little <= 50 msec

Per una spiegazione dei benchmark, consulta la documentazione di SynthMark.

  • DEVE ridurre al minimo l'imprecisione e la deriva dell'orologio audio rispetto all'ora standard.
  • DOVREBBE ridurre al minimo la deriva dell'orologio audio rispetto alla CPU CLOCK_MONOTONIC quando entrambi sono attivi.
  • DEVE ridurre al minimo la latenza audio sui trasduttori del dispositivo.
  • DEVE ridurre al minimo la latenza audio tramite l'audio digitale USB.
  • DEVE documentare le misurazioni della latenza audio su tutti i percorsi.
  • DEVE ridurre al minimo il jitter nei tempi di inserimento del callback di completamento del buffer audio, in quanto ciò influisce sulla percentuale utilizzabile della larghezza di banda della CPU completa da parte del callback.
  • DOVREBBE fornire zero problemi audio durante il normale utilizzo alla latenza segnalata.
  • DEVE fornire una differenza di latenza tra i canali pari a zero.
  • DEVE ridurre al minimo la latenza media MIDI su tutti i trasporti.
  • DEVE ridurre al minimo la variabilità della latenza MIDI sotto carico (jitter) su tutti i trasporti.
  • DEVE fornire timestamp MIDI accurati su tutti i trasporti.
  • DOVREBBE ridurre al minimo il rumore del segnale audio sui trasduttori del dispositivo, incluso il periodo immediatamente successivo all'avvio a freddo.
  • DEVE fornire una differenza di clock audio pari a zero tra i lati di input e output degli endpoint corrispondenti, quando entrambi sono attivi. Esempi di endpoint corrispondenti includono il microfono e l'altoparlante sul dispositivo o l'input e l'output del jack audio.
  • DEVE gestire i callback di completamento del buffer audio per i lati di input e output degli endpoint corrispondenti sullo stesso thread quando entrambi sono attivi e inserire il callback di output immediatamente dopo il ritorno dal callback di input. Se non è possibile gestire i callback nello stesso thread, inserisci il callback di output subito dopo aver inserito il callback di input per consentire all'applicazione di avere una tempistica coerente dei lati di input e output.
  • DEVE ridurre al minimo la differenza di fase tra il buffering audio HAL per i lati di input e output degli endpoint corrispondenti.
  • SHOULD minimize touch latency.
  • DOVREBBE ridurre al minimo la variabilità della latenza del tocco sotto carico (jitter).
  • DOVREBBE avere una latenza dall'input tocco all'output audio inferiore o uguale a 40 ms.

Se le implementazioni dei dispositivi soddisfano tutti i requisiti sopra indicati:

Se le implementazioni dei dispositivi includono un jack audio da 3, 5 mm a 4 conduttori:

Se le implementazioni dei dispositivi omettono un jack audio da 3, 5 mm a 4 conduttori e includono una o più porte USB che supportano la modalità host USB:

  • [C-3-1] DEVE implementare la classe audio USB.
  • [C-3-2] DEVE avere una latenza audio di andata e ritorno continua di 20 millisecondi o meno sulla porta in modalità host USB utilizzando la classe audio USB.
  • La latenza audio continua di andata e ritorno DOVREBBE essere pari o inferiore a 10 millisecondi sulla porta della modalità host USB utilizzando la classe audio USB.
  • [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare I/O simultanei fino a 8 canali per direzione, frequenza di campionamento di 96 kHz e profondità di 24 o 32 bit, se utilizzati con periferiche audio USB che supportano anche questi requisiti.

Se le implementazioni dei dispositivi includono una porta HDMI:

  • DEVE supportare l'output in stereo e otto canali a 20 bit o 24 bit di profondità e 192 kHz senza perdita di profondità di bit o ricampionamento, in almeno una configurazione.

5.11. Acquisizione per Non elaborato

Android include il supporto per la registrazione dell'audio non elaborato tramite la sorgente audio android.media.MediaRecorder.AudioSource.UNPROCESSED. In OpenSL ES, è possibile accedervi con il preset di registrazione SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Se le implementazioni dei dispositivi intendono supportare l'origine audio non elaborata e renderla disponibile per le app di terze parti:

  • [C-1-1] DEVE segnalare il supporto tramite la proprietà android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

  • [C-1-2] DEVE presentare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte nella gamma di frequenza media: in particolare ±10 dB da 100 Hz a 7000 Hz per ogni microfono utilizzato per registrare la sorgente audio non elaborata.

  • [C-1-3] DEVE mostrare livelli di ampiezza nella gamma di basse frequenze: in particolare da ±20 dB da 5 Hz a 100 Hz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio non elaborata.

  • [C-1-4] DEVE mostrare livelli di ampiezza nella gamma di alte frequenze: in particolare da ±30 dB da 7000 Hz a 22 kHz rispetto alla gamma di medie frequenze per ogni microfono utilizzato per registrare la sorgente audio non elaborata.

  • [C-1-5] DEVE impostare la sensibilità dell'ingresso audio in modo che una sorgente di tono sinusoidale a 1000 Hz riprodotta a un livello di pressione sonora (SPL) di 94 dB produca una risposta con RMS di 520 per campioni a 16 bit (o -36 dB Full Scale per campioni in virgola mobile/a doppia precisione) per ogni microfono utilizzato per registrare la sorgente audio non elaborata.

  • [C-1-6] DEVE avere un rapporto segnale/rumore (SNR) pari o superiore a 60 dB per ogni microfono utilizzato per registrare la sorgente audio non elaborata. mentre il rapporto segnale/rumore viene misurato come la differenza tra 94 dB SPL e il livello SPL equivalente del rumore proprio, ponderato A.

  • [C-1-7] DEVE avere una distorsione armonica totale (THD) inferiore all'1% per 1 kHz a un livello di ingresso SPL di 90 dB per ogni microfono utilizzato per registrare la sorgente audio non elaborata.

  • NON deve avere altre elaborazioni del segnale (ad es. controllo automatico del guadagno, filtro passa alto o cancellazione dell'eco) nel percorso, ad eccezione di un moltiplicatore di livello per portare il livello all'intervallo desiderato. In altre parole:

  • [C-1-8] Se nell'architettura è presente un'elaborazione del segnale per qualsiasi motivo, questa DEVE essere disattivata e introdurre un ritardo o una latenza aggiuntivi pari a zero nel percorso del segnale.
  • [C-1-9] Il moltiplicatore di livello, sebbene sia consentito nel percorso, NON DEVE introdurre ritardi o latenza nel percorso del segnale.

Tutte le misurazioni SPL vengono effettuate direttamente accanto al microfono in fase di test. Per le configurazioni con più microfoni, questi requisiti si applicano a ciascun microfono.

Se le implementazioni del dispositivo dichiarano android.hardware.microphone, ma non supportano la sorgente audio non elaborata:

  • [C-2-1] DEVE restituire null per il metodo API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), per indicare correttamente la mancanza di supporto.
  • [SR] sono ancora FORTEMENTE CONSIGLIATI per soddisfare il maggior numero possibile di requisiti per il percorso del segnale della sorgente di registrazione non elaborata.

6. Compatibilità di strumenti e opzioni per sviluppatori

6.1. Strumenti per sviluppatori

Implementazioni del dispositivo:

  • [C-0-1] DEVE supportare gli strumenti per sviluppatori Android forniti nell'SDK Android.

  • Android Debug Bridge (ADB)

    • [C-0-2] DEVE supportare adb come documentato nell'SDK Android e i comandi della shell forniti in AOSP, che possono essere utilizzati dagli sviluppatori di app, inclusi dumpsys cmd stats
    • [C-SR] Sono VIVAMENTE CONSIGLIATI per supportare il comando shell cmd testharness.
    • [C-0-3] NON DEVE alterare il formato o i contenuti degli eventi di sistema del dispositivo (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrati tramite il comando dumpsys.
    • [C-0-10] DEVE registrare, senza omissioni, e rendere i seguenti eventi accessibili e disponibili per il comando shell cmd stats e la classe API di sistema StatsManager.
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] Il daemon ADB lato dispositivo DEVE essere inattivo per impostazione predefinita e DEVE esistere un meccanismo accessibile all'utente per attivare Android Debug Bridge.
    • [C-0-5] DEVE supportare adb sicuro. Android include il supporto per adb sicuro. adb sicuro consente adb su host autenticati noti.

    • [C-0-6] DEVE fornire un meccanismo che consenta la connessione di adb da una macchina host. Ad esempio:

      • Le implementazioni dei dispositivi senza una porta USB che supporti la modalità periferica DEVONO implementare adb tramite rete locale (ad esempio Ethernet o Wi-Fi).
      • DEVONO fornire driver per Windows 7, 9 e 10, consentendo agli sviluppatori di connettersi al dispositivo utilizzando il protocollo ADB.

  • Dalvik Debug Monitor Service (DDMS)

    • [C-0-7] DEVE supportare tutte le funzionalità di ddms come documentato nell'SDK Android. Poiché ddms utilizza adb, il supporto di ddms DEVE essere inattivo per impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato Android Debug Bridge, come sopra.
  • Scimmia
    • [C-0-8] DEVE includere il framework Monkey e renderlo disponibile per l'utilizzo da parte delle applicazioni.
  • SysTrace
    • [C-0-9] DEVE supportare lo strumento systrace come documentato nell'SDK Android. Systrace DEVE essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivarlo.

  • Perfetto

    • [C-SR] Are STRONGLY RECOMMENDED to expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.
    • [C-SR] È VIVAMENTE CONSIGLIATO che il binario perfetto accetti come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
    • [C-SR] È VIVAMENTE CONSIGLIATO di scrivere il binario perfetto come output di una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
    • [C-SR] È FORTEMENTE CONSIGLIATO fornire, tramite il binario perfetto, almeno le origini dati descritte nella documentazione di perfetto.

  • Modalità test harness

    Se le implementazioni dei dispositivi supportano il comando shell cmd testharness ed eseguono cmd testharness enable:

Se le implementazioni dei dispositivi segnalano il supporto di Vulkan 1.0 o versioni successive tramite i flag delle funzionalità android.hardware.vulkan.version:

  • [C-1-1] DEVE fornire una funzionalità che consenta allo sviluppatore di app di attivare/disattivare i livelli di debug della GPU.
  • [C-1-2] DEVE, quando i livelli di debug della GPU sono attivati, enumerare i livelli nelle librerie fornite da strumenti esterni (ovvero non parte del pacchetto della piattaforma o dell'applicazione) trovati nella directory di base delle applicazioni sottoponibili a debug per supportare i metodi API vkEnumerateInstanceLayerProperties() e vkCreateInstance().

6.2. Opzioni sviluppatore

Android include il supporto per consentire agli sviluppatori di configurare le impostazioni relative allo sviluppo di applicazioni.

Le implementazioni dei dispositivi DEVONO fornire un'esperienza coerente per le Opzioni sviluppatore:

  • [C-0-1] DEVE rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo di applicazioni. L'implementazione Android upstream nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avviare le opzioni sviluppatore dopo aver premuto sette (7) volte la voce di menu Impostazioni > Informazioni dispositivo > Numero build.
  • [C-0-2] MUST hide Developer Options by default.
  • [C-0-3] DEVE fornire un meccanismo chiaro che non dia un trattamento preferenziale a un'app di terze parti rispetto a un'altra per attivare le opzioni sviluppatore. DEVE fornire un documento o un sito web visibile pubblicamente che descriva come attivare le opzioni sviluppatore. Questo documento o sito web DEVE essere collegabile dai documenti dell'SDK Android.
  • DOVREBBE mostrare una notifica visiva continua all'utente quando le opzioni sviluppatore sono attive e la sicurezza dell'utente è a rischio.
  • POTREBBE limitare temporaneamente l'accesso al menu Opzioni sviluppatore nascondendolo o disattivandolo visivamente, per evitare distrazioni negli scenari in cui la sicurezza dell'utente è un problema.

7. Compatibilità hardware

Se un dispositivo include un particolare componente hardware con un'API corrispondente per sviluppatori di terze parti:

  • [C-0-1] L'implementazione del dispositivo DEVE implementare questa API come descritto nella documentazione dell'SDK Android.

Se un'API nell'SDK interagisce con un componente hardware dichiarato facoltativo e l'implementazione del dispositivo non possiede quel componente:

  • [C-0-2] Devono comunque essere presentate le definizioni complete delle classi (come documentato dall'SDK) per le API dei componenti.
  • [C-0-3] I comportamenti dell'API DEVONO essere implementati come no-op in modo ragionevole.
  • [C-0-4] I metodi API DEVONO restituire valori null laddove consentito dalla documentazione dell'SDK.
  • [C-0-5] I metodi API DEVONO restituire implementazioni no-op di classi in cui i valori null non sono consentiti dalla documentazione dell'SDK.
  • [C-0-6] I metodi API NON DEVONO generare eccezioni non documentate dalla documentazione dell'SDK.
  • [C-0-7] Le implementazioni dei dispositivi DEVONO segnalare in modo coerente informazioni accurate sulla configurazione hardware tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) nella classe android.content.pm.PackageManager per la stessa impronta di build.

Un esempio tipico di scenario in cui si applicano questi requisiti è l'API Telephony: anche sui dispositivi non telefonici, queste API DEVONO essere implementate come no-op ragionevoli.

7.1. Display e grafica

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 una varietà di configurazioni hardware. Sui display compatibili con Android su 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 questa sezione.

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

  • dimensione diagonale fisica. La distanza in pollici tra due angoli opposti della parte illuminata del display.
  • punti per pollice (dpi). Il numero di pixel compresi in un intervallo lineare orizzontale o verticale di 2,54 cm. Se sono elencati i valori DPI, sia il DPI orizzontale che quello verticale DEVONO rientrare nell'intervallo.
  • proporzioni. Il rapporto tra i pixel della dimensione più lunga e quelli della dimensione più corta dello schermo. Ad esempio, un display di 480 x 854 pixel avrebbe un rapporto di 854/480 = 1,779, ovvero circa "16:9".
  • pixel indipendenti dalla densità (dp). L'unità di pixel virtuale normalizzata a uno schermo da 160 dpi, calcolata come: pixel = dp * (densità/160).

7.1.1. Configurazione dello schermo

7.1.1.1. Dimensioni e forma dello schermo

Il framework UI di Android supporta una serie di dimensioni del layout dello schermo logico diverse e consente alle applicazioni di eseguire query sulle dimensioni del layout dello schermo della configurazione corrente tramite Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK e Configuration.smallestScreenWidthDp.

Implementazioni del dispositivo:

  • [C-0-1] DEVE segnalare le dimensioni corrette del layout per Configuration.screenLayout come definito nella documentazione dell'SDK Android. Nello specifico, le implementazioni dei dispositivi DEVONO segnalare le dimensioni dello schermo in pixel indipendenti dalla densità (dp) logici corretti come indicato di seguito:

    • I dispositivi con Configuration.uiMode impostato su un valore diverso da UI_MODE_TYPE_WATCH e che segnalano una dimensione small per Configuration.screenLayout DEVONO avere almeno 426 dp x 320 dp.
    • I dispositivi che segnalano una dimensione normal per Configuration.screenLayout DEVONO avere almeno 480 dp x 320 dp.
    • I dispositivi che segnalano una dimensione large per Configuration.screenLayout DEVONO avere almeno 640 dp x 480 dp.
    • I dispositivi che segnalano una dimensione xlarge per Configuration.screenLayout DEVONO avere almeno 960 dp x 720 dp.

  • [C-0-2] DEVE rispettare correttamente il supporto dichiarato dalle applicazioni per le dimensioni dello schermo tramite l'attributo <supports-screens> nel file AndroidManifest.xml, come descritto nella documentazione dell'SDK Android.

  • POTREBBE avere uno o più display compatibili con Android con angoli arrotondati.

Se le implementazioni dei dispositivi supportano UI_MODE_TYPE_NORMAL e includono i display compatibili con Android con angoli arrotondati:

  • [C-1-1] DEVE garantire che il raggio degli angoli arrotondati sia inferiore o uguale a 38 dp.
  • DEVE includere la possibilità per l'utente di passare alla modalità di visualizzazione con gli angoli rettangolari.
7.1.1.2. Proporzioni dello schermo

Sebbene non vi siano restrizioni per le proporzioni del display fisico per i display compatibili con Android, le proporzioni del display logico in cui vengono visualizzate le app di terze parti, che possono essere derivate dai valori di altezza e larghezza riportati tramite le API view.Display e le API Configuration, DEVONO soddisfare i seguenti requisiti:

  • [C-0-1] Le implementazioni del dispositivo con Configuration.uiMode impostato su UI_MODE_TYPE_NORMAL DEVONO avere un valore delle proporzioni inferiore o uguale a 1,86 (circa 16:9), a meno che l'app non soddisfi una delle seguenti condizioni:

    • L'app ha dichiarato di supportare un rapporto di formato dello schermo più ampio tramite il valore dei metadati android.max_aspect.
    • L'app dichiara di essere ridimensionabile tramite l'attributo android:resizeableActivity.
    • L'app ha come target il livello API 24 o versioni successive e non dichiara un android:maxAspectRatio che limiterebbe le proporzioni consentite.

  • [C-0-2] Le implementazioni del dispositivo con Configuration.uiMode impostato su UI_MODE_TYPE_NORMAL DEVONO avere un valore del formato uguale o maggiore di 1,3333 (4:3), a meno che l'app non possa essere allargata soddisfacendo una delle seguenti condizioni:

  • [C-0-3] Le implementazioni del dispositivo con Configuration.uiMode impostato su UI_MODE_TYPE_WATCH DEVONO avere un valore delle proporzioni impostato su 1,0 (1:1).

7.1.1.3. Densità schermo

Il framework UI di Android definisce un insieme di densità logiche standard per aiutare gli sviluppatori di applicazioni a scegliere come target le risorse delle applicazioni.

Se è presente un'opzione per modificare le dimensioni del display del dispositivo:

  • [C-1-1] Le dimensioni del display NON DEVONO essere scalate a un valore superiore a 1,5 volte la densità nativa o produrre una dimensione minima effettiva dello schermo inferiore a 320 dp (equivalente al qualificatore di risorse sw320dp), a seconda di quale delle due condizioni si verifica per prima.
  • [C-1-2] La dimensione del display NON DEVE essere ridotta a una scala inferiore a 0,85 volte la densità nativa.
  • Per garantire una buona usabilità e dimensioni dei caratteri coerenti, è CONSIGLIATO fornire il seguente ridimensionamento delle opzioni di visualizzazione nativa (rispettando i limiti specificati sopra)
  • Piccola: 0,85x
  • Predefinito: 1x (scala di visualizzazione nativa)
  • Large: 1,15x
  • Più grande: 1,3x
  • Più grande 1,45x

7.1.2. Metriche display

Se le implementazioni dei dispositivi includono i display compatibili con Android o l'output video sugli schermi dei display compatibili con Android,

  • [C-1-1] DEVE segnalare i valori corretti per tutte le metriche di visualizzazione compatibili con Android definite nell'API android.util.DisplayMetrics.

Se le implementazioni del dispositivo non includono uno schermo o un'uscita video incorporati:

  • [C-2-1] DEVE segnalare i valori corretti del display compatibile con Android come definito nell'API android.util.DisplayMetrics per view.Display predefinito emulato.

7.1.3. Orientamento schermo

Implementazioni del dispositivo:

  • [C-0-1] DEVE indicare le orientazioni dello schermo supportate (android.hardware.screen.portrait e/o android.hardware.screen.landscape) e DEVE indicare almeno un'orientazione supportata. Ad esempio, un dispositivo con uno schermo orizzontale a orientamento fisso, come una televisione o un laptop, DEVE segnalare solo android.hardware.screen.landscape.
  • [C-0-2] DEVE segnalare il valore corretto per l'orientamento attuale del dispositivo, ogni volta che viene eseguita una query tramite le API android.content.res.Configuration.orientation, android.view.Display.getOrientation() o altre.

Se le implementazioni dei dispositivi supportano entrambi gli orientamenti dello schermo:

  • [C-1-1] DEVE supportare l'orientamento dinamico delle applicazioni in verticale o orizzontale. ovvero il dispositivo DEVE rispettare la richiesta dell'applicazione di un orientamento dello schermo specifico.
  • [C-1-2] NON DEVE modificare le dimensioni o la densità dello schermo segnalate quando cambia l'orientamento.
  • PUÒ selezionare l'orientamento verticale o orizzontale come predefinito.

7.1.4. Accelerazione grafica 2D e 3D

7.1.4.1 OpenGL ES

Implementazioni del dispositivo:

  • [C-0-1] DEVE identificare correttamente le versioni OpenGL ES supportate (1.1, 2.0, 3.0, 3.1, 3.2) tramite le API gestite (ad esempio tramite il metodo GLES10.getString()) e le API native.
  • [C-0-2] DEVE includere il supporto per tutte le API gestite e native corrispondenti per ogni versione di OpenGL ES che è stata identificata come supportata.

Se le implementazioni del dispositivo includono un'uscita video o uno schermo:

  • [C-1-1] DEVE supportare OpenGL ES 1.1 e 2.0, come descritto e dettagliato nella documentazione dell'SDK Android.
  • [C-SR] Are STRONGLY RECOMMENDED to support OpenGL ES 3.1.
  • DEVE supportare OpenGL ES 3.2.

Se le implementazioni dei dispositivi supportano una delle versioni di OpenGL ES:

  • [C-2-1] DEVE segnalare tramite le API gestite OpenGL ES e le API native qualsiasi altra estensione OpenGL ES che ha implementato e, viceversa, NON DEVE segnalare stringhe di estensione che non supporta.
  • [C-2-2] DEVE supportare le estensioni EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable e EGL_ANDROID_GLES_layers.
  • [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare le estensioni EGL_KHR_partial_update e OES_EGL_image_external.
  • DEVE segnalare con precisione tramite il metodo getString() qualsiasi formato di compressione delle texture supportato, che in genere è specifico del fornitore.

Se le implementazioni dei dispositivi dichiarano il supporto di OpenGL ES 3.0, 3.1 o 3.2:

  • [C-3-1] MUST export the corresponding function symbols for these version in addition to the OpenGL ES 2.0 function symbols in the libGLESv2.so library.
  • [SR] Sono FORTEMENTE CONSIGLIATI per supportare l'estensione OES_EGL_image_external_essl3.

Se le implementazioni dei dispositivi supportano OpenGL ES 3.2:

  • [C-4-1] DEVE supportare l'intero pacchetto di estensioni Android OpenGL ES.

Se le implementazioni dei dispositivi supportano l'Android Extension Pack di OpenGL ES nella sua interezza:

  • [C-5-1] DEVE identificare il supporto tramite il flag di funzionalità android.hardware.opengles.aep.

Se le implementazioni dei dispositivi espongono il supporto per l'estensione EGL_KHR_mutable_render_buffer:

  • [C-6-1] DEVE supportare anche l'estensione EGL_ANDROID_front_buffer_auto_refresh.
7.1.4.2 Vulkan

Android include il supporto di Vulkan, un'API multipiattaforma a basso overhead per grafica 3D ad alte prestazioni.

Se le implementazioni dei dispositivi supportano OpenGL ES 3.1:

  • [SR] È FORTEMENTE CONSIGLIATO includere il supporto per Vulkan 1.1.

Se le implementazioni del dispositivo includono un'uscita video o uno schermo:

  • DOVREBBE includere il supporto di Vulkan 1.1.

Se le implementazioni dei dispositivi includono il supporto di Vulkan 1.0:

  • [C-1-1] DEVE segnalare il valore intero corretto con i flag di funzionalità android.hardware.vulkan.level e android.hardware.vulkan.version.
  • [C-1-2] DEVE enumerare almeno un VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] DEVE implementare completamente le API Vulkan 1.0 per ogni VkPhysicalDevice enumerato.
  • [C-1-4] DEVE enumerare i livelli contenuti nelle librerie native denominate libVkLayer*.so nella directory delle librerie native del pacchetto dell'applicazione tramite le API native Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties() .
  • [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.
  • [C-1-6] DEVE segnalare tutte le stringhe di estensione che supporta tramite le API native Vulkan e, viceversa, NON DEVE segnalare le stringhe di estensione che non supporta correttamente.
  • [C-1-7] DEVE supportare le estensioni VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain e VK_KHR_incremental_present.
  • [C-SR] È VIVAMENTE CONSIGLIATO di supportare le estensioni VK_KHR_driver_properties e VK_GOOGLE_display_timing.

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

  • [C-2-1] NON DEVE dichiarare nessuno dei flag funzionalità Vulkan (ad es. android.hardware.vulkan.level, android.hardware.vulkan.version).
  • [C-2-2] NON DEVE enumerare alcun VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices().

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

  • [C-3-1] DEVE esporre il supporto per i tipi di semaforo e handle esterni SYNC_FD e per l'estensione VK_ANDROID_external_memory_android_hardware_buffer.
7.1.4.3 RenderScript
  • [C-0-1] Le implementazioni del dispositivo DEVONO supportare Android RenderScript, come descritto nella documentazione dell'SDK Android.
7.1.4.4 Accelerazione grafica 2D

Android include un meccanismo che consente alle applicazioni di dichiarare di voler attivare l'accelerazione hardware per la grafica 2D a livello di applicazione, attività, finestra o visualizzazione tramite l'utilizzo di un tag manifest android:hardwareAccelerated o chiamate API dirette.

Implementazioni del dispositivo:

  • [C-0-1] DEVE abilitare l'accelerazione hardware per impostazione predefinita e DEVE disabilitarla se lo sviluppatore lo richiede impostando android:hardwareAccelerated="false” o disabilitando l'accelerazione hardware direttamente tramite le API Android View.
  • [C-0-2] DEVE mostrare un comportamento coerente con la documentazione dell'SDK Android sull'accelerazione hardware.

Android include un oggetto TextureView che consente agli sviluppatori di integrare direttamente le texture OpenGL ES con accelerazione hardware come target di rendering in una gerarchia dell'interfaccia utente.

Implementazioni del dispositivo:

  • [C-0-3] DEVE supportare l'API TextureView e DEVE mostrare un comportamento coerente con l'implementazione Android upstream.
7.1.4.5 Display ad ampia gamma

Se le implementazioni dei dispositivi dichiarano il supporto per i display ad ampia gamma tramite Configuration.isScreenWideColorGamut():

  • [C-1-1] DEVE avere un display con colori calibrati.
  • [C-1-2] DEVE avere un display la cui gamma copre interamente la gamma di colori sRGB nello spazio CIE 1931 xyY.
  • [C-1-3] DEVE avere un display la cui gamma ha un'area di almeno il 90% di DCI-P3 nello spazio CIE 1931 xyY.
  • [C-1-4] DEVE supportare OpenGL ES 3.1 o 3.2 e segnalarlo correttamente.
  • [C-1-5] DEVE pubblicizzare il supporto delle estensioni EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear e EGL_EXT_gl_colorspace_display_p3_passthrough.
  • [C-SR] Sono VIVAMENTE CONSIGLIATI per supportare GL_EXT_sRGB.

Al contrario, se le implementazioni dei dispositivi non supportano i display ad ampia gamma,

  • [C-2-1] DOVREBBE coprire il 100% o più di sRGB nello spazio CIE 1931 xyY, anche se la gamma di colori dello schermo non è definita.

7.1.5. Modalità di compatibilità con le applicazioni legacy

Android specifica una "modalità di compatibilità" in cui il framework funziona in una modalità di dimensioni dello schermo "normale" equivalente (larghezza 320 dp) a vantaggio delle applicazioni legacy non sviluppate per le versioni precedenti di Android che precedono l'indipendenza dalle dimensioni dello schermo.

7.1.6. Tecnologia dello schermo

La piattaforma Android include API che consentono alle applicazioni di eseguire il rendering di grafiche avanzate su un display compatibile con Android. I dispositivi DEVONO supportare tutte queste API come definito dall'SDK Android, a meno che non sia specificamente consentito in questo documento.

Tutti i display compatibili con Android di un'implementazione del dispositivo:

  • [C-0-1] MUST be capable of rendering 16-bit color graphics.
  • DEVE supportare display in grado di visualizzare grafica a 24 bit.
  • [C-0-2] DEVE essere in grado di eseguire il rendering delle animazioni.
  • [C-0-3] DEVE avere proporzioni pixel (PAR) comprese tra 0,9 e 1,15. ovvero le proporzioni pixel DEVONO essere quasi quadrate (1.0) con una tolleranza del 10-15%.

7.1.7. Display secondari

Android include il supporto per display secondari compatibili con Android per attivare le funzionalità di condivisione dei contenuti multimediali e le API per sviluppatori per accedere ai display esterni.

Se le implementazioni dei dispositivi supportano un display esterno tramite una connessione cablata, wireless o un'ulteriore connessione display incorporata:

  • [C-1-1] DEVE implementare il servizio di sistema e l'API DisplayManager come descritto nella documentazione dell'SDK Android.

7.2. Dispositivi di immissione

Implementazioni del dispositivo:

7.2.1. Tastiera

Se le implementazioni dei dispositivi includono il supporto per applicazioni Input Method Editor (IME) di terze parti:

Implementazioni del dispositivo: * [C-0-1] NON DEVE includere una tastiera hardware che non corrisponda a uno dei formati specificati in android.content.res.Configuration.keyboard (QWERTY o 12 tasti). * SHOULD include additional soft keyboard implementations. * POTREBBE includere una tastiera hardware.

7.2.2. Navigazione non touch

Android include il supporto per il D-pad, la trackball e la rotella come meccanismi per la navigazione non touch.

Implementazioni del dispositivo:

Se le implementazioni dei dispositivi non prevedono navigazioni non touch:

  • [C-1-1] DEVE fornire un meccanismo di interfaccia utente alternativo ragionevole per la selezione e la modifica del testo, compatibile con i motori di gestione dell'input. L'implementazione open source di Android upstream include un meccanismo di selezione adatto all'uso con dispositivi che non dispongono di input di navigazione non touch.

7.2.3. Tasti di navigazione

Le funzioni Home, Recenti e Indietro, in genere fornite tramite un'interazione con un pulsante fisico dedicato o una parte distinta del touchscreen, sono essenziali per il paradigma di navigazione di Android e, pertanto, per le implementazioni dei dispositivi:

  • [C-0-1] DEVE fornire un'interfaccia utente per avviare le applicazioni installate che hanno un'attività con <intent-filter> impostato con ACTION=MAIN e CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER per le implementazioni di dispositivi televisivi. La funzione Casa DOVREBBE essere il meccanismo per questa funzionalità utente.
  • DOVREBBE fornire pulsanti per le funzioni Recenti e Indietro.

Se vengono fornite le funzioni Home, Recenti o Indietro:

  • [C-1-1] DEVE essere accessibile con una singola azione (ad es. tocco, doppio clic o gesto) quando una qualsiasi di queste azioni è accessibile.
  • [C-1-2] DEVE fornire un'indicazione chiara di quale singola azione attiverebbe ogni funzione. Un'indicazione di questo tipo può essere un'icona visibile impressa sul pulsante, un'icona software nella parte della barra di navigazione dello schermo o una procedura guidata passo passo durante la configurazione iniziale.

Implementazioni del dispositivo:

  • [SR] are STRONGLY RECOMMENDED to not provide the input mechanism for the Menu function as it is deprecated in favor of action bar since Android 4.0.

Se le implementazioni del dispositivo forniscono la funzione Menu, queste:

  • [C-2-1] DEVE mostrare il pulsante di overflow delle azioni ogni volta che il popup del menu di overflow delle azioni non è vuoto e la barra delle azioni è visibile.
  • [C-2-2] NON DEVE modificare la posizione del popup di overflow delle azioni visualizzato selezionando il pulsante di overflow nella barra delle azioni, ma PUÒ eseguire il rendering del popup di overflow delle azioni in una posizione modificata sullo schermo quando viene visualizzato selezionando la funzione Menu.

Se le implementazioni del dispositivo non forniscono la funzione Menu, per la compatibilità con le versioni precedenti: * [C-SR] È FORTEMENTE CONSIGLIATO rendere disponibile la funzione Menu alle applicazioni quando targetSdkVersion è inferiore a 10, tramite un pulsante fisico, un tasto software o gesti. Questa funzione di menu DOVREBBE essere accessibile, a meno che non sia nascosta insieme ad altre funzioni di navigazione.

Se le implementazioni del dispositivo forniscono la funzione Assist, queste:

  • [C-4-1] DEVE rendere accessibile la funzione Assistenza con una singola azione (ad es. tocco, doppio clic o gesto) quando sono accessibili altri tasti di navigazione.
  • [SR] VIVAMENTE CONSIGLIATO di utilizzare la pressione prolungata sulla funzione HOME come interazione designata.

Se le implementazioni dei dispositivi utilizzano una parte distinta dello schermo per visualizzare i tasti di navigazione:

  • [C-5-1] I tasti di navigazione DEVONO utilizzare una parte distinta dello schermo, non disponibile per le applicazioni, e NON DEVONO oscurare o interferire in altro modo con la parte dello schermo disponibile per le applicazioni.
  • [C-5-2] DEVE rendere disponibile una parte del display alle applicazioni che soddisfano i requisiti definiti nella sezione 7.1.1.
  • [C-5-3] DEVE rispettare i flag impostati dall'app tramite il metodo API View.setSystemUiVisibility(), in modo che questa parte distinta dello schermo (ovvero la barra di navigazione) sia nascosta correttamente come documentato nell'SDK.

Se la funzione di navigazione viene fornita come azione sullo schermo basata su gesti:

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets() DEVE essere utilizzato solo per segnalare l'area di riconoscimento del gesto Home.
  • [C-6-2] I gesti che iniziano all'interno di un rettangolo di esclusione fornito dall'applicazione in primo piano tramite View#setSystemGestureExclusionRects(), ma al di fuori di WindowInsets#getMandatorySystemGestureInsets(), NON DEVONO essere intercettati per la funzione di navigazione, a condizione che il rettangolo di esclusione sia consentito entro il limite massimo di esclusione specificato nella documentazione di View#setSystemGestureExclusionRects().
  • [C-6-3] DEVE inviare all'app in primo piano un evento MotionEvent.ACTION_CANCEL una volta che i tocchi iniziano a essere intercettati per un gesto di sistema, se all'app in primo piano è stato precedentemente inviato un evento MotionEvent.ACTION_DOWN.
  • [C-6-4] DEVE fornire un'interfaccia utente per passare a una navigazione sullo schermo basata su pulsanti (ad esempio, nelle Impostazioni).
  • DEVE fornire la funzione Home scorrendo verso l'alto dal bordo inferiore dell'orientamento corrente dello schermo.
  • DEVE fornire la funzionalità Recenti con uno scorrimento verso l'alto e una pressione prolungata prima del rilascio, dalla stessa area del gesto Home.
  • I gesti che iniziano all'interno di WindowInsets#getMandatorySystemGestureInsets() NON DEVONO essere interessati dai rettangoli di esclusione forniti dall'applicazione in primo piano tramite View#setSystemGestureExclusionRects().

Se una funzione di navigazione viene fornita da qualsiasi punto dei bordi sinistro e destro dell'orientamento attuale dello schermo:

  • [C-7-1] La funzione di navigazione DEVE essere Indietro e fornita come scorrimento dai bordi sinistro e destro dell'orientamento attuale dello schermo.
  • [C-7-2] Se vengono forniti pannelli di sistema personalizzati scorrevoli sui bordi sinistro o destro, DEVONO essere posizionati nel terzo superiore dello schermo con un'indicazione visiva chiara e persistente che il trascinamento verso l'interno richiama i pannelli sopra menzionati e quindi non Indietro. Un pannello di sistema PUÒ essere configurato da un utente in modo che si trovi sotto il primo terzo del bordo o dei bordi dello schermo, ma NON DEVE utilizzare più di un terzo del bordo o dei bordi.
  • [C-7-3] Quando l'app in primo piano ha impostato i flag View.SYSTEM_UI_FLAG_IMMERSIVE o View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, lo scorrimento dai bordi DEVE comportarsi come implementato in AOSP, documentato nell'SDK.
  • [C-7-4] Quando l'app in primo piano ha impostato i flag View.SYSTEM_UI_FLAG_IMMERSIVE o View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, i pannelli di sistema personalizzati scorrevoli DEVONO essere nascosti finché l'utente non visualizza le barre di sistema (ovvero la barra di navigazione e la barra di stato) come implementato in AOSP.

7.2.4. Input touchscreen

Android include il supporto per una serie di sistemi di input del puntatore, come touchscreen, touchpad e dispositivi di input touch simulato. Le implementazioni di dispositivi basati su touchscreen sono associate a un display in modo che l'utente abbia l'impressione di manipolare direttamente gli elementi sullo schermo. Poiché l'utente tocca direttamente lo schermo, il sistema non richiede ulteriori ausili per indicare gli oggetti manipolati.

Implementazioni del dispositivo:

  • DEVE avere un sistema di input del puntatore di qualche tipo (simile al mouse o al tocco).
  • DEVE supportare puntatori tracciati in modo completamente indipendente.

Se le implementazioni dei dispositivi includono un touchscreen (single-touch o superiore):

  • [C-1-1] DEVE segnalare TOUCHSCREEN_FINGER per il campo API Configuration.touchscreen.
  • [C-1-2] DEVE segnalare i flag delle funzionalità android.hardware.touchscreen e android.hardware.faketouch.

Se le implementazioni dei dispositivi includono un touchscreen in grado di tracciare più di un tocco,

  • [C-2-1] DEVE segnalare i flag delle funzionalità appropriati android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand corrispondenti al tipo di touchscreen specifico sul dispositivo.

Se le implementazioni del dispositivo non includono un touchscreen (e si basano solo su un dispositivo di puntamento) e soddisfano i requisiti di tocco simulato nella sezione 7.2.5,

  • [C-3-1] NON deve segnalare alcun flag di funzionalità che inizia con android.hardware.touchscreen e DEVE segnalare solo android.hardware.faketouch.

7.2.5. Input tocco simulato

L'interfaccia touch simulata fornisce un sistema di input utente che approssima un sottoinsieme delle funzionalità del touchscreen. Ad esempio, un mouse o un telecomando che controlla un cursore sullo schermo simula il tocco, ma richiede all'utente di puntare o mettere a fuoco e poi fare clic. Numerosi dispositivi di input come mouse, trackpad, mouse aereo basato su giroscopio, giroscopio, joystick e trackpad multi-touch possono supportare interazioni touch simulate. Android include la funzionalità costante android.hardware.faketouch, che corrisponde a un dispositivo di input non touch (basato su puntatore) ad alta fedeltà, come un mouse o un trackpad, in grado di emulare adeguatamente l'input basato sul tocco (incluso il supporto di base dei gesti) e indica che il dispositivo supporta un sottoinsieme emulato della funzionalità touchscreen.

Se le implementazioni del dispositivo non includono un touchscreen, ma includono un altro sistema di input del puntatore che vogliono rendere disponibile:

  • DEVE dichiarare il supporto del flag funzionalità android.hardware.faketouch.

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.faketouch:

  • [C-1-1] DEVE segnalare le posizioni X e Y assolute dello schermo della posizione del puntatore e visualizzare un puntatore visivo sullo schermo.
  • [C-1-2] DEVE segnalare l'evento tocco con il codice azione che specifica la modifica dello stato che si verifica quando il puntatore si sposta verso il basso o verso l'alto sullo schermo.
  • [C-1-3] DEVE supportare il puntatore verso il basso e verso l'alto su un oggetto sullo schermo, il che consente agli utenti di emulare il tocco di un oggetto sullo schermo.
  • [C-1-4] DEVE supportare il puntatore verso il basso, il puntatore verso l'alto, il puntatore verso il basso e poi verso l'alto nello stesso punto di un oggetto sullo schermo entro una soglia di tempo, il che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo.
  • [C-1-5] DEVE supportare il puntatore verso il basso su un punto arbitrario dello schermo, il movimento del puntatore verso un altro punto arbitrario dello schermo, seguito da un puntatore verso l'alto, che consente agli utenti di emulare un trascinamento con il tocco.
  • [C-1-6] DEVE supportare il puntatore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in una posizione diversa sullo schermo e poi il puntatore verso l'alto sullo schermo, il che consente agli utenti di lanciare un oggetto sullo schermo.
  • [C-1-7] DEVE segnalare TOUCHSCREEN_NOTOUCH per il campo API Configuration.touchscreen.

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.faketouch.multitouch.distinct:

  • [C-2-1] DEVE dichiarare il supporto di android.hardware.faketouch.
  • [C-2-2] DEVE supportare il monitoraggio distinto di due o più input del puntatore indipendenti.

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.faketouch.multitouch.jazzhand:

  • [C-3-1] DEVE dichiarare il supporto di android.hardware.faketouch.
  • [C-3-2] DEVE supportare il tracciamento distinto di 5 (tracciamento di una mano di dita) o più input del puntatore in modo completamente indipendente.

7.2.6. Supporto del controller di gioco

7.2.6.1. Mappature dei pulsanti

Se le implementazioni del dispositivo dichiarano il flag di funzionalità android.hardware.gamepad:

  • [C-1-1] DEVE avere un controller integrato o essere spedito con un controller separato nella confezione, che fornisca i mezzi per inserire tutti gli eventi elencati nelle tabelle seguenti.
  • [C-1-2] DEVE essere in grado di mappare gli eventi HID alle costanti view.InputEvent Android associate elencate nelle tabelle seguenti. L'implementazione Android upstream include l'implementazione per i controller di gioco che soddisfa questo requisito.
Pulsante Utilizzo HID2 Pulsante Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-pad su1
D-pad giù1 		0x01 0x00393 AXIS_HAT_Y4
D-pad - Sinistra1
D-pad - Destra1 		0x01 0x00393 AXIS_HAT_X4
Pulsante dorsale sinistro1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Pulsante dorsale destro1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clic della levetta sinistra1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clic dello stick destro1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Home1 0x0c 0x0223 KEYCODE_HOME (3)
Indietro1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 Gli utilizzi HID sopra indicati DEVONO essere dichiarati all'interno di una CA del gamepad (0x01 0x0005).

3 Questo utilizzo DEVE avere un minimo logico di 0, un massimo logico di 7, un minimo fisico di 0, un massimo fisico di 315, unità in gradi e una dimensione del report di 4. Il valore logico è definito come la rotazione in senso orario rispetto all'asse verticale. Ad esempio, un valore logico pari a 0 non rappresenta alcuna rotazione e indica la pressione del tasto Su, mentre un valore logico pari a 1 rappresenta una rotazione di 45 gradi e la pressione dei tasti Su e Sinistra.

4 MotionEvent

Controlli analogici1 Utilizzo HID Pulsante Android
Grilletto sinistro 0x02 0x00C5 AXIS_LTRIGGER
Grilletto destro 0x02 0x00C4 AXIS_RTRIGGER
Joystick sinistro 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
Joystick destro 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. Telecomando

Per i requisiti specifici del dispositivo, consulta la sezione 2.3.1.

7.3. Sensori

Se le implementazioni dei dispositivi includono un particolare tipo di sensore con un'API corrispondente per sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android e nella documentazione Android Open Source sui sensori.

Implementazioni del dispositivo:

  • [C-0-1] DEVE segnalare con precisione la presenza o l'assenza di sensori in base alla classe android.content.pm.PackageManager.
  • [C-0-2] DEVE restituire un elenco accurato dei sensori supportati tramite SensorManager.getSensorList() e metodi simili.
  • [C-0-3] DEVE comportarsi in modo ragionevole per tutte le altre API dei sensori (ad esempio, restituendo true o false a seconda dei casi quando le applicazioni tentano di registrare i listener, non chiamando i listener dei sensori quando i sensori corrispondenti non sono presenti e così via).

Se le implementazioni dei dispositivi includono un particolare tipo di sensore con un'API corrispondente per sviluppatori di terze parti:

  • [C-1-1] DEVE segnalare tutte le misurazioni dei sensori utilizzando i valori pertinenti del Sistema internazionale di unità di misura (metrico) per ogni tipo di sensore, come definito nella documentazione dell'SDK Android.
  • [C-1-2] DEVE segnalare i dati dei sensori con una latenza massima di 100 millisecondi + 2 * sample_time nel caso di un flusso di sensori con una latenza massima richiesta di 0 ms quando il processore dell'applicazione è attivo. Questo ritardo non include eventuali ritardi di filtraggio.
  • [C-1-3] DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time dall'attivazione del sensore. È accettabile che questo campione abbia una precisione pari a 0.

  • [SR] SHOULD report the event time in nanoseconds as defined in the Android SDK documentation, representing the time the event happened and synchronized with the SystemClock.elapsedRealtimeNano() clock. È VIVAMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti, in modo da poter eseguire l'upgrade alle future versioni della piattaforma in cui questo potrebbe diventare un componente OBBLIGATORIO. L'errore di sincronizzazione DOVREBBE essere inferiore a 100 millisecondi.

  • [C-1-4] Per qualsiasi API indicata dalla documentazione dell'SDK Android come sensore continuo, le implementazioni del dispositivo DEVONO fornire continuamente campioni di dati periodici che DOVREBBERO avere un jitter inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori timestamp segnalati tra eventi consecutivi.

  • [C-1-5] DEVE garantire che il flusso di eventi del sensore NON impedisca alla CPU del dispositivo di entrare in stato di sospensione o di riattivarsi da uno stato di sospensione.

  • Quando vengono attivati più sensori, il consumo energetico NON DEVE superare la somma del consumo energetico segnalato di ogni singolo sensore.

L'elenco riportato sopra non è esaustivo. Il comportamento documentato dell'SDK Android e delle documentazioni open source di Android sui sensori deve essere considerato autorevole.

Alcuni tipi di sensori sono compositi, il che significa che possono essere derivati dai dati forniti da uno o più altri sensori. Alcuni esempi sono il sensore di orientamento e il sensore di accelerazione lineare.

Implementazioni del dispositivo:

  • DOVREBBE implementare questi tipi di sensori, quando includono i sensori fisici prerequisiti descritti in Tipi di sensori.

Se le implementazioni dei dispositivi includono un sensore composito:

  • [C-2-1] DEVE implementare il sensore come descritto nella documentazione Android Open Source sui sensori compositi.

7.3.1. Accelerometro

Implementazioni del dispositivo:

  • [C-SR] È VIVAMENTE CONSIGLIATO includere un accelerometro a 3 assi.

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

  • [C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
  • [C-1-2] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER.
  • [C-1-3] DEVE rispettare il sistema di coordinate dei sensori Android come descritto nelle API Android.
  • [C-1-4] DEVE essere in grado di misurare dalla caduta libera fino a quattro volte la gravità(4 g) o più su qualsiasi asse.
  • [C-1-5] DEVE avere una risoluzione di almeno 12 bit.
  • [C-1-6] DEVE avere una deviazione standard non superiore a 0,05 m/s^, dove la deviazione standard DEVE essere calcolata per asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più rapida.
  • [SR] are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
  • [SR] are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. È FORTEMENTE CONSIGLIATO che i dispositivi Android soddisfino questo requisito, in modo che possano essere aggiornati alla futura release della piattaforma in cui questo potrebbe diventare OBBLIGATORIO.
  • DEVE implementare i sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento SDK Android.
  • DEVE segnalare eventi fino ad almeno 200 Hz.
  • DOVREBBE avere una risoluzione di almeno 16 bit.
  • DEVE essere calibrato durante l'uso se le caratteristiche cambiano nel corso del ciclo di vita e compensato e conservare i parametri di compensazione tra i riavvii del dispositivo.
  • DEVE essere compensato in base alla temperatura.

Se le implementazioni del dispositivo includono un accelerometro a 3 assi e uno qualsiasi dei sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER:

  • [C-2-1] La somma del loro consumo energetico DEVE sempre essere inferiore a 4 mW.
  • DOVREBBE essere inferiore a 2 mW e 0,5 mW quando il dispositivo si trova in una condizione dinamica o statica.

Se le implementazioni dei dispositivi includono un accelerometro a 3 assi e un sensore giroscopio a 3 assi:

  • [C-3-1] DEVE implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • [C-SR] È FORTEMENTE CONSIGLIATO implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

Se le implementazioni dei dispositivi includono un accelerometro a 3 assi, un sensore giroscopio a 3 assi e un sensore magnetometro:

  • [C-4-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

7.3.2. Magnetometro

Implementazioni del dispositivo:

  • [C-SR] È VIVAMENTE CONSIGLIATO includere un magnetometro a 3 assi (bussola).

Se le implementazioni del dispositivo includono un magnetometro a 3 assi:

  • [C-1-1] DEVE implementare il sensore TYPE_MAGNETIC_FIELD.
  • [C-1-2] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 10 Hz e DOVREBBE segnalare eventi fino ad almeno 50 Hz.
  • [C-1-3] DEVE rispettare il sistema di coordinate dei sensori Android come descritto nelle API Android.
  • [C-1-4] DEVE essere in grado di misurare tra -900 µT e +900 µT su ogni asse prima di saturarsi.
  • [C-1-5] DEVE avere un valore di compensazione del ferro duro inferiore a 700 µT e DOVREBBE avere un valore inferiore a 200 µT posizionando il magnetometro lontano da campi magnetici dinamici (indotti dalla corrente) e statici (indotti dal magnete).
  • [C-1-6] DEVE avere una risoluzione uguale o superiore a 0,6 µT.
  • [C-1-7] DEVE supportare la calibrazione e la compensazione online della distorsione di ferro duro e conservare i parametri di compensazione tra i riavvii del dispositivo.
  • [C-1-8] DEVE essere applicata la compensazione del ferro dolce. La calibrazione può essere eseguita durante l'uso o la produzione del dispositivo.
  • [C-1-9] DEVE avere una deviazione standard, calcolata per asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più rapida, non superiore a 1,5 µT; DOVREBBE avere una deviazione standard non superiore a 0,5 µT.
  • DEVE implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] È VIVAMENTE CONSIGLIATO implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED sui dispositivi Android nuovi ed esistenti.

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi, un sensore accelerometro e un sensore giroscopio a 3 assi:

  • [C-2-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

Se le implementazioni del dispositivo includono un magnetometro a 3 assi e un accelerometro:

  • POTREBBE implementare il sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi, un accelerometro e un sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR:

  • [C-3-1] DEVE consumare meno di 10 mW.
  • DOVREBBE consumare meno di 3 mW quando il sensore è registrato per la modalità batch a 10 Hz.

7.3.3. GPS

Implementazioni del dispositivo:

  • [C-SR] È VIVAMENTE CONSIGLIATO includere un ricevitore GPS/GNSS.

Se le implementazioni del dispositivo includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag di funzionalità android.hardware.location.gps,

  • [C-1-1] DEVE supportare gli output di posizione a una velocità di almeno 1 Hz quando richiesto tramite LocationManager#requestLocationUpdate.
  • [C-1-2] DEVE essere in grado di determinare la posizione in condizioni di cielo aperto (segnali forti, multipath trascurabile, HDOP < 2) entro 10 secondi (tempo di acquisizione rapido), quando è connesso a una connessione a internet con velocità dati pari o superiore a 0,5 Mbps. Questo requisito viene in genere soddisfatto utilizzando una qualche forma di tecnica GPS/GNSS assistita o predittiva per ridurre al minimo il tempo di acquisizione del segnale GPS/GNSS (i dati di assistenza includono l'ora di riferimento, la posizione di riferimento e l'effemeride/l'orologio del satellite).
    • [C-1-6] Dopo aver eseguito il calcolo della posizione, le implementazioni del dispositivo DEVONO determinare la posizione, in cielo aperto, entro 5 secondi, quando le richieste di posizione vengono riavviate, fino a un'ora dopo il calcolo iniziale della posizione, anche quando la richiesta successiva viene effettuata senza una connessione dati e/o dopo un ciclo di accensione.

  • In condizioni di cielo aperto dopo aver determinato la posizione, da fermo o in movimento con un'accelerazione inferiore a 1 metro al secondo quadrato:

    • [C-1-3] DEVE essere in grado di determinare la posizione entro 20 metri e la velocità entro 0,5 metri al secondo almeno il 95% delle volte.
    • [C-1-4] DEVE tracciare e segnalare simultaneamente tramite GnssStatus.Callback almeno 8 satelliti di una costellazione.
    • DEVE essere in grado di monitorare simultaneamente almeno 24 satelliti di più costellazioni (ad es. GPS + almeno una tra Glonass, Beidou, Galileo).
    • [C-SR] È FORTEMENTE CONSIGLIATO di continuare a fornire normali output di posizione GPS/GNSS tramite le API del fornitore di servizi di localizzazione GNSS durante una chiamata di emergenza.
    • [C-SR] È FORTEMENTE CONSIGLIATO segnalare le misurazioni GNSS di tutte le costellazioni monitorate (come riportato nei messaggi GnssStatus), ad eccezione di SBAS.
    • [C-SR] È FORTEMENTE CONSIGLIATO segnalare AGC e frequenza di misurazione GNSS.
    • [C-SR] È VIVAMENTE CONSIGLIATO di segnalare tutte le stime di precisione (inclusi orientamento, velocità e verticale) nell'ambito di ogni posizione GPS/GNSS.
    • [C-SR] È VIVAMENTE CONSIGLIATO segnalare le misurazioni GNSS non appena vengono trovate, anche se una posizione calcolata dal GPS/GNSS non è ancora stata segnalata.
    • [C-SR] È FORTEMENTE CONSIGLIATO segnalare le pseudodistanze e le velocità di pseudodistanza GNSS che, in condizioni di cielo aperto dopo aver determinato la posizione, da fermo o in movimento con un'accelerazione inferiore a 0, 2 metri al secondo quadrato, sono sufficienti per calcolare la posizione entro 20 metri e la velocità entro 0, 2 metri al secondo, almeno il 95% delle volte.

7.3.4. Giroscopio

Implementazioni del dispositivo:

  • [C-SR] È FORTEMENTE CONSIGLIATO includere un sensore giroscopio, a meno che non sia incluso anche un accelerometro a 3 assi.

Se le implementazioni del dispositivo includono un giroscopio a 3 assi:

  • [C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
  • [C-1-2] DEVE implementare il sensore TYPE_GYROSCOPE ed è FORTEMENTE CONSIGLIATO di implementare anche il sensore TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-4] DEVE avere una risoluzione di almeno 12 bit e DOVREBBE avere una risoluzione di almeno 16 bit.
  • [C-1-5] DEVE essere compensato in temperatura.
  • [C-1-6] DEVE essere calibrato e compensato durante l'uso e conservare i parametri di compensazione tra i riavvii del dispositivo.
  • [C-1-7] DEVE avere una varianza non superiore a 1e-7 rad^2 / s^2 per Hz (varianza per Hz o rad^2 / s). La varianza può variare in base alla frequenza di campionamento, ma DEVE essere vincolata da questo valore. In altre parole, se misuri la varianza del giroscopio a una frequenza di campionamento di 1 Hz, NON DEVE essere superiore a 1e-7 rad^2/s^2.
  • [SR] Si CONSIGLIA VIVAMENTE che l'errore di calibrazione sia inferiore a 0,01 rad/s quando il dispositivo è fermo a temperatura ambiente.
  • DEVE segnalare eventi fino ad almeno 200 Hz.

Se le implementazioni dei dispositivi includono un giroscopio a 3 assi, un sensore accelerometro e un sensore magnetometro:

  • [C-2-1] DEVE implementare un sensore composito TYPE_ROTATION_VECTOR.

Se le implementazioni dei dispositivi includono un accelerometro a 3 assi e un sensore giroscopio a 3 assi:

  • [C-3-1] DEVE implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • [C-SR] È FORTEMENTE CONSIGLIATO implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometro

Implementazioni del dispositivo:

  • [C-SR] È VIVAMENTE CONSIGLIATO includere un barometro (sensore di pressione atmosferica).

Se le implementazioni del dispositivo includono un barometro:

  • [C-1-1] DEVE implementare e segnalare il sensore TYPE_PRESSURE.
  • [C-1-2] DEVE essere in grado di fornire eventi a una frequenza di 5 Hz o superiore.
  • [C-1-3] DEVE essere compensato in base alla temperatura.
  • [SR] VIVAMENTE CONSIGLIATO per poter segnalare misurazioni della pressione nell'intervallo da 300 hPa a 1100 hPa.
  • DOVREBBE avere una precisione assoluta di 1 hPa.
  • DOVREBBE avere una precisione relativa di 0,12 hPa in un intervallo di 20 hPa (equivalente a una precisione di circa 1 m in una variazione di circa 200 m a livello del mare).

7.3.6. Termometro

Implementazioni del dispositivo:

  • POTREBBE includere un termometro ambiente (sensore di temperatura).
  • PUÒ ma NON DEVE includere un sensore di temperatura della CPU.

Se le implementazioni dei dispositivi includono un termometro ambientale (sensore di temperatura):

  • [C-1-1] DEVE essere definito come SENSOR_TYPE_AMBIENT_TEMPERATURE e DEVE misurare la temperatura ambiente (stanza/abitacolo del veicolo) da cui l'utente interagisce con il dispositivo in gradi Celsius.
  • [C-1-2] MUST be defined as SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] DEVE misurare la temperatura della CPU del dispositivo.
  • [C-1-4] NON DEVE misurare altre temperature.

Tieni presente che il tipo di sensore SENSOR_TYPE_TEMPERATURE è stato ritirato in Android 4.0.

7.3.7. Fotometro

  • Le implementazioni del dispositivo POSSONO includere un fotometro (sensore di luce ambientale).

7.3.8. Sensore di prossimità

  • Le implementazioni del dispositivo POSSONO includere un sensore di prossimità.

Se le implementazioni dei dispositivi includono un sensore di prossimità:

  • [C-1-1] DEVE misurare la prossimità di un oggetto nella stessa direzione dello schermo. ovvero il sensore di prossimità DEVE essere orientato in modo da rilevare gli oggetti vicini allo schermo, in quanto lo scopo principale di questo tipo di sensore è rilevare un telefono in uso da parte dell'utente. Se le implementazioni del dispositivo includono un sensore di prossimità con un altro orientamento, NON deve essere accessibile tramite questa API.
  • [C-1-2] DEVE avere una precisione di almeno 1 bit.

7.3.9. Sensori ad alta fedeltà

Se le implementazioni dei dispositivi includono un insieme di sensori di qualità superiore, come definito in questa sezione, e li rendono disponibili alle app di terze parti:

  • [C-1-1] DEVE identificare la funzionalità tramite il flag funzionalità android.hardware.sensor.hifi_sensors.

Se le implementazioni dei dispositivi dichiarano android.hardware.sensor.hifi_sensors:

  • [C-2-1] DEVE avere un sensore TYPE_ACCELEROMETER che:

    • DEVE avere un intervallo di misurazione compreso tra almeno -8 g e +8 g, DOVREBBE avere un intervallo di misurazione compreso tra almeno -16 g e +16 g.
    • DEVE avere una risoluzione di misurazione di almeno 2048 LSB/g.
    • DEVE avere una frequenza di misurazione minima di 12,5 Hz o inferiore.
    • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DOVREBBE supportare SensorDirectChannel RATE_VERY_FAST.
    • DEVE avere un rumore di misurazione non superiore a 400 μg/√Hz.
    • DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore.
    • DEVE avere un consumo energetico di batching non superiore a 3 mW.
    • [C-SR] È FORTEMENTE CONSIGLIATO avere una larghezza di banda di misurazione di 3 dB di almeno l'80% della frequenza di Nyquist e uno spettro di rumore bianco all'interno di questa larghezza di banda.
    • DEVE avere una passeggiata casuale di accelerazione inferiore a 30 μg √Hz testata a temperatura ambiente.
    • DOVREBBE avere una variazione della distorsione rispetto alla temperatura di ≤ +/- 1 mg/°C.
    • DEVE avere una non linearità della retta di miglior adattamento ≤ 0,5% e una variazione della sensibilità rispetto alla temperatura ≤ 0,03%/°C.
    • DOVREBBE avere una sensibilità all'asse trasversale < 2,5 % e una variazione della sensibilità all'asse trasversale < 0,2% nell'intervallo di temperatura di funzionamento del dispositivo.

  • [C-2-2] DEVE avere un TYPE_ACCELEROMETER_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_ACCELEROMETER.

  • [C-2-3] DEVE avere un sensore TYPE_GYROSCOPE che:

    • DEVE avere un intervallo di misurazione compreso tra almeno -1000 e +1000 dps.
    • DEVE avere una risoluzione di misurazione di almeno 16 LSB/dps.
    • DEVE avere una frequenza di misurazione minima di 12,5 Hz o inferiore.
    • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DOVREBBE supportare SensorDirectChannel RATE_VERY_FAST.
    • DEVE avere un rumore di misurazione non superiore a 0,014°/s/√Hz.
    • [C-SR] È FORTEMENTE CONSIGLIATO avere una larghezza di banda di misurazione di 3 dB di almeno l'80% della frequenza di Nyquist e uno spettro di rumore bianco all'interno di questa larghezza di banda.
    • DEVE avere una passeggiata casuale della velocità inferiore a 0,001 °/s √Hz testata a temperatura ambiente.
    • DOVREBBE avere una variazione di polarizzazione rispetto alla temperatura ≤ +/- 0,05 °/ s / °C.
    • DOVREBBE avere una variazione di sensibilità rispetto alla temperatura ≤ 0,02% / °C.
    • DOVREBBE avere una non linearità della linea di miglior adattamento ≤ 0,2%.
    • DEVE avere una densità di rumore ≤ 0,007 °/s/√Hz.
    • DEVE avere un errore di calibrazione inferiore a 0,002 rad/s nell'intervallo di temperatura 10 ~ 40 °C quando il dispositivo è fermo.
    • DEVE avere una sensibilità all'accelerazione inferiore a 0,1 °/s/g.
    • DEVE avere una sensibilità cross-axis < 4,0 % e una variazione della sensibilità cross-axis < 0,3% nell'intervallo di temperatura di funzionamento del dispositivo.

  • [C-2-4] DEVE avere un TYPE_GYROSCOPE_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GYROSCOPE.

  • [C-2-5] DEVE avere un sensore TYPE_GEOMAGNETIC_FIELD che:

    • DEVE avere un intervallo di misurazione compreso tra almeno -900 e +900 μT.
    • DEVE avere una risoluzione di misurazione di almeno 5 LSB/uT.
    • DEVE avere una frequenza di misurazione minima di 5 Hz o inferiore.
    • DEVE avere una frequenza di misurazione massima di 50 Hz o superiore.
    • DEVE avere un rumore di misurazione non superiore a 0,5 μT.

  • [C-2-6] DEVE avere un TYPE_MAGNETIC_FIELD_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GEOMAGNETIC_FIELD e, in aggiunta:

    • DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 600 eventi del sensore.
    • [C-SR] È VIVAMENTE CONSIGLIATO avere uno spettro di rumore bianco da 1 Hz ad almeno 10 Hz quando la frequenza di report è pari o superiore a 50 Hz.

  • [C-2-7] DEVE avere un sensore TYPE_PRESSURE che:

    • DEVE avere un intervallo di misurazione compreso tra almeno 300 e 1100 hPa.
    • DEVE avere una risoluzione di misurazione di almeno 80 LSB/hPa.
    • DEVE avere una frequenza di misurazione minima di 1 Hz o inferiore.
    • DEVE avere una frequenza di misurazione massima di 10 Hz o superiore.
    • DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz.
    • DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
    • DEVE avere un consumo energetico di batching non superiore a 2 mW.
  • [C-2-8] DEVE avere un sensore TYPE_GAME_ROTATION_VECTOR.
  • [C-2-9] DEVE avere un sensore TYPE_SIGNIFICANT_MOTION che:
    • DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
  • [C-2-10] DEVE avere un sensore TYPE_STEP_DETECTOR che:
    • DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 100 eventi del sensore.
    • DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
    • DEVE avere un consumo energetico di batching non superiore a 4 mW.
  • [C-2-11] DEVE avere un sensore TYPE_STEP_COUNTER che:
    • DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
  • [C-2-12] DEVE avere un sensore TILT_DETECTOR che:
    • DEVE avere un consumo energetico non superiore a 0,5 mW quando il dispositivo è statico e a 1,5 mW quando è in movimento.
  • [C-2-13] Il timestamp dell'evento fisico riportato da accelerometro, giroscopio e magnetometro DEVE essere compreso entro 2, 5 millisecondi l'uno dall'altro. Il timestamp dell'evento fisico riportato dall'accelerometro e dal giroscopio DEVE essere entro 0,25 millisecondi l'uno dall'altro.
  • [C-2-14] MUST have Gyroscope sensor event timestamps on the same time base as the camera subsystem and within 1 milliseconds of error.
  • [C-2-15] DEVE fornire campioni alle applicazioni entro 5 millisecondi dal momento in cui i dati sono disponibili per l'applicazione su uno qualsiasi dei sensori fisici sopra indicati.
  • [C-2-16] NON DEVE avere un consumo energetico superiore a 0,5 mW quando il dispositivo è statico e a 2,0 mW quando il dispositivo è in movimento quando è abilitata una qualsiasi combinazione dei seguenti sensori:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] POTREBBE avere un sensore TYPE_PROXIMITY, ma se presente DEVE avere una capacità di buffer minima di 100 eventi del sensore.

Tieni presente che tutti i requisiti di consumo energetico in questa sezione non includono il consumo energetico del processore dell'applicazione. È inclusa la potenza assorbita dall'intera catena di sensori: il sensore, qualsiasi circuito di supporto, qualsiasi sistema di elaborazione dei sensori dedicato e così via.

Se le implementazioni dei dispositivi includono il supporto diretto dei sensori:

  • [C-3-1] DEVE dichiarare correttamente il supporto dei tipi di canali diretti e del livello di frequenza dei report diretti tramite le API isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
  • [C-3-2] DEVE supportare almeno uno dei due tipi di canali diretti del sensore per tutti i sensori che dichiarano il supporto del canale diretto del sensore.
  • DEVE supportare la generazione di report sugli eventi tramite il canale diretto del sensore per il sensore principale (variante non di riattivazione) dei seguenti tipi:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensori biometrici

Per ulteriori informazioni sulla misurazione della sicurezza dello sblocco biometrico, consulta la documentazione sulla misurazione della sicurezza biometrica.

Se le implementazioni del dispositivo includono una schermata di blocco sicura:

  • DEVE includere un sensore biometrico

I sensori biometrici possono essere classificati come Forti, Deboli o Comodi in base ai tassi di accettazione di spoofing e impostori e alla sicurezza della pipeline biometrica. Questa classificazione determina le funzionalità che il sensore biometrico deve interfacciare con la piattaforma e con le applicazioni di terze parti. I sensori sono classificati come Convenienza per impostazione predefinita e devono soddisfare requisiti aggiuntivi, come descritto di seguito, se vogliono essere classificati come Debole o Forte. Le biometrie Debole e Forte ottengono funzionalità aggiuntive, come descritto di seguito.

Per rendere disponibile un sensore biometrico ad applicazioni di terze parti, implementazioni di dispositivi:

  • [C-0-1] DEVE soddisfare i requisiti per la biometria forte o debole, come definito in questo documento.

Per consentire l'accesso alle chiavi del keystore alle applicazioni di terze parti, implementazioni del dispositivo:

  • [C-0-2] DEVE soddisfare i requisiti per Forte definiti in questo documento.

Inoltre:

  • [C-0-3] DEVE essere abbinato a un'azione di conferma esplicita (ad es. la pressione di un pulsante) se la biometria forte è passiva (ad es. viso o iride in cui non esiste un segnale esplicito dell'intenzione dell'utente).
    • [C-SR] L'azione di conferma per la biometria passiva è FORTEMENTE CONSIGLIATA per essere protetta in modo che una compromissione del sistema operativo o del kernel non possa falsificarla. Ad esempio, ciò significa che l'azione di conferma basata su un pulsante fisico viene indirizzata tramite un pin di input/output (GPIO) generico solo di input di un elemento sicuro (SE) che non può essere azionato in altro modo se non premendo un pulsante fisico.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Convenienza, devono:

  • [C-1-1] DEVE avere un tasso di falsa accettazione inferiore allo 0,002%.
  • [C-1-2] DEVE comunicare che questa modalità potrebbe essere meno sicura di un PIN, una sequenza o una password efficaci ed elencare chiaramente i rischi della sua attivazione, se i tassi di accettazione di spoofing e impersonificazione sono superiori al 7%.
  • [C-1-3] MUST rate limit attempts for at least 30 seconds after five false trials for biometric verification - where a false trial is one with an adequate capture quality (BIOMETRIC_ACQUIRED_GOOD) that does not match an enrolled biometric.
  • [C-1-4] DEVE impedire l'aggiunta di nuove biometriche senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare le credenziali del dispositivo esistenti o di aggiungerne di nuove (PIN/sequenza/password) protette da TEE. L'implementazione di Android Open Source Project fornisce il meccanismo nel framework per farlo.
  • [C-1-5] DEVE rimuovere completamente tutti i dati biometrici identificabili di un utente quando il suo account viene rimosso (anche tramite un ripristino dei dati di fabbrica).
  • [C-1-6] DEVE rispettare il flag individuale per quella biometria (ad es. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE o DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
  • [C-1-7] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) una volta ogni 24 ore o meno per i nuovi dispositivi con Android 10 e una volta ogni 72 ore o meno per i dispositivi che eseguono l'upgrade da una versione precedente di Android.

  • [C-1-8] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) dopo uno dei seguenti eventi:

    • Un periodo di timeout di inattività di 4 ore OPPURE
    • 3 tentativi di autenticazione biometrica non riusciti.
    • Il periodo di timeout di inattività e il conteggio dei tentativi di autenticazione non riusciti vengono reimpostati dopo qualsiasi conferma riuscita delle credenziali del dispositivo.

    L'upgrade dei dispositivi da una versione precedente di Android può essere esentato dal punto C-1-8.

  • [C-SR] Sono FORTEMENTE CONSIGLIATI per avere un tasso di falsi rifiuti inferiore al 10%, misurato sul dispositivo.

  • [C-SR] È VIVAMENTE CONSIGLIATO che abbiano una latenza inferiore a 1 secondo, misurata dal momento in cui viene rilevata la biometria fino allo sblocco dello schermo, per ogni biometria registrata.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Debole:

  • [C-2-1] DEVE soddisfare tutti i requisiti per la Convenienza sopra indicati, ad eccezione di [C-1-2].
  • [C-2-2] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 20%.
  • [C-2-3] DEVE avere un'implementazione di keystore basata su hardware ed eseguire la corrispondenza biometrica in un ambiente di esecuzione isolato al di fuori dello spazio utente o del kernel Android, ad esempio il Trusted Execution Environment (TEE), o su un chip con un canale sicuro per l'ambiente di esecuzione isolato.
  • [C-2-4] DEVE avere tutti i dati identificabili criptati e autenticati crittograficamente 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 Android Open Source.
  • [C-2-5] Per la biometria basata sulla videocamera, durante l'autenticazione o la registrazione biometrica:
    • DEVE utilizzare la videocamera in una modalità che impedisca la lettura o l'alterazione dei frame della videocamera al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro per l'ambiente di esecuzione isolato.
    • Per le soluzioni RGB a singola videocamera, i frame della videocamera 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-6] NON DEVE consentire alle applicazioni di terze parti di distinguere tra le singole registrazioni biometriche.
  • [C-2-7] NON DEVE consentire l'accesso non criptato a dati biometrici identificabili o a qualsiasi dato da essi derivato (ad esempio incorporamenti) al processore dell'applicazione al di fuori del contesto del TEE.

  • [C-2-8] DEVE disporre di una pipeline di elaborazione sicura in modo che la compromissione di un sistema operativo o di un kernel non possa consentire l'inserimento diretto di dati per l'autenticazione fraudolenta come utente.

    Se le implementazioni dei dispositivi sono già state lanciate su una versione precedente di Android e non possono soddisfare il requisito C-2-8 tramite un aggiornamento del software di sistema, POTREBBERO essere esentate dal requisito.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come Efficace:

  • [C-3-1] DEVE soddisfare tutti i requisiti di Debole sopra indicati. L'upgrade dei dispositivi da una versione precedente di Android non è esente dal punto C-2-7.
  • [C-3-2] DEVE avere un tasso di accettazione di spoofing e impersonificazione non superiore al 7%.
  • [C-3-3] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) una volta ogni 72 ore o meno.

7.3.12. Sensore di postura

Implementazioni del dispositivo:

  • POTREBBE supportare il sensore di postura con 6 gradi di libertà.

Se le implementazioni dei dispositivi supportano il sensore di postura con 6 gradi di libertà:

  • [C-1-1] DEVE implementare e segnalare il sensore TYPE_POSE_6DOF.
  • [C-1-2] DEVE essere più preciso del solo vettore di rotazione.

7.4. Connettività dei dati

7.4.1. Telefonia

Il termine "telefonia" utilizzato dalle API Android e in questo documento si riferisce in modo specifico all'hardware correlato all'effettuazione di chiamate vocali e all'invio di messaggi SMS tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano o meno essere a commutazione di pacchetto, ai fini di Android sono considerate indipendenti da qualsiasi connettività dati che possa essere implementata utilizzando la stessa rete. In altre parole, le funzionalità e le API "telefonia" di Android si riferiscono specificamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni di dispositivi che non possono effettuare chiamate o inviare/ricevere SMS non sono considerate dispositivi di telefonia, indipendentemente dal fatto che utilizzino una rete cellulare per la connettività dati.

  • Android PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. ovvero Android è compatibile con dispositivi diversi dagli smartphone.

Se le implementazioni dei dispositivi includono la telefonia GSM o CDMA:

  • [C-1-1] DEVE dichiarare il flag funzionalità android.hardware.telephony e altri flag funzionalità secondari in base alla tecnologia.
  • [C-1-2] DEVE implementare il supporto completo per l'API per quella tecnologia.

Se le implementazioni dei dispositivi non includono hardware di telefonia:

  • [C-2-1] MUST implement the full APIs as no-ops.

Se le implementazioni dei dispositivi supportano eUICC o eSIM/SIM integrate e includono un meccanismo proprietario per rendere disponibile la funzionalità eSIM per gli sviluppatori di terze parti:

7.4.1.1. Compatibilità con il blocco dei numeri

Se le implementazioni dei dispositivi segnalano android.hardware.telephony feature, significa che:

  • [C-1-1] DEVE includere il supporto per il blocco dei numeri
  • [C-1-2] DEVE implementare completamente BlockedNumberContract e l'API corrispondente come descritto nella documentazione dell'SDK.
  • [C-1-3] DEVE bloccare tutte le chiamate e i messaggi provenienti da un numero di telefono in "BlockedNumberProvider" senza alcuna interazione con le app. L'unica eccezione si verifica quando il blocco dei numeri viene temporaneamente rimosso, come descritto nella documentazione dell'SDK.
  • [C-1-4] NON DEVE scrivere al provider del registro chiamate della piattaforma per una chiamata bloccata.
  • [C-1-5] NON DEVE scrivere al fornitore di telefonia per un messaggio bloccato.
  • [C-1-6] DEVE implementare un'interfaccia utente di gestione dei numeri bloccati, che viene aperta con l'intent restituito dal metodo TelecomManager.createManageBlockedNumbersIntent().
  • [C-1-7] NON DEVE consentire agli utenti secondari di visualizzare o modificare i numeri bloccati sul dispositivo, in quanto la piattaforma Android presuppone che l'utente principale abbia il controllo completo dei servizi di telefonia, una singola istanza, sul dispositivo. Tutta l'interfaccia utente relativa al blocco DEVE essere nascosta agli utenti secondari e l'elenco bloccati DEVE comunque essere rispettato.
  • DOVREBBE eseguire la migrazione dei numeri bloccati nel provider quando un dispositivo viene aggiornato ad Android 7.0.
7.4.1.2. API Telecom

Se le implementazioni dei dispositivi segnalano android.hardware.telephony:

  • [C-1-1] DEVE supportare le API ConnectionService descritte nell'SDK.
  • [C-1-2] DEVE mostrare una nuova chiamata in arrivo e fornire all'utente la possibilità di accettarla o rifiutarla quando è impegnato in una chiamata in corso effettuata da un'app di terze parti che non supporta la funzionalità di attesa specificata tramite CAPABILITY_SUPPORT_HOLD.
  • [C-1-3] DEVE avere un'applicazione che implementa InCallService.

  • [C-SR] È FORTEMENTE CONSIGLIATO notificare all'utente che rispondere a una chiamata in arrivo interromperà una chiamata in corso.

    L'implementazione AOSP soddisfa questi requisiti tramite una notifica heads-up che indica all'utente che se risponde a una chiamata in arrivo, l'altra chiamata verrà interrotta.

  • [C-SR] È FORTEMENTE CONSIGLIATO precaricare l'app Telefono predefinita che mostra una voce del registro chiamate e il nome di un'app di terze parti nel registro chiamate quando l'app di terze parti imposta il tasto degli extra EXTRA_LOG_SELF_MANAGED_CALLS nel suo PhoneAccount su true.

  • [C-SR] Sono FORTEMENTE CONSIGLIATI per gestire gli eventi KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK delle cuffie audio per le API android.telecom come indicato di seguito:
    • Chiama Connection.onDisconnect() quando viene rilevata una pressione breve dell'evento chiave durante una chiamata in corso.
    • Chiama Connection.onAnswer() quando viene rilevata una pressione breve dell'evento chiave durante una chiamata in arrivo.
    • Chiama Connection.onReject() quando viene rilevata una pressione prolungata dell'evento chiave durante una chiamata in arrivo.
    • Attiva/disattiva lo stato di disattivazione dell'audio di CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementazioni del dispositivo:

  • DEVE includere il supporto per una o più forme di 802.11.

Se le implementazioni del dispositivo includono il supporto di 802.11 ed espongono la funzionalità a un'applicazione di terze parti:

  • [C-1-1] DEVE implementare l'API Android corrispondente.
  • [C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.wifi.
  • [C-1-3] DEVE implementare l'API multicast come descritto nella documentazione dell'SDK.
  • [C-1-4] DEVE supportare il DNS multicast (mDNS) e NON DEVE filtrare i pacchetti mDNS (224.0.0.251) in qualsiasi momento del funzionamento, tra cui:
    • Anche quando lo schermo non è in stato attivo.
    • Per le implementazioni di dispositivi Android Television, anche in modalità di alimentazione in standby.
  • [C-1-5] NON DEVE considerare la chiamata al metodo API WifiManager.enableNetwork() come indicazione sufficiente per cambiare l'Network attualmente attivo, utilizzato per impostazione predefinita per il traffico dell'applicazione e restituito dai metodi API ConnectivityManager come getActiveNetwork e registerDefaultNetworkCallback. In altre parole, POSSONO disattivare l'accesso a internet fornito da qualsiasi altro operatore di rete (ad es. dati mobili) solo se verificano correttamente che la rete Wi-Fi fornisce l'accesso a internet.
  • [C-1-6] Sono FORTEMENTE CONSIGLIATI di, quando viene chiamato il metodo API ConnectivityManager.reportNetworkConnectivity(), rivalutare l'accesso a internet su Network e, una volta che la valutazione determina che l'attuale Network non fornisce più l'accesso a internet, passare a qualsiasi altra rete disponibile (ad es. dati mobili) che fornisca l'accesso a internet.
  • [C-SR] È VIVAMENTE CONSIGLIATO di randomizzare l'indirizzo MAC di origine e il numero di sequenza dei frame di richiesta di probe, una volta all'inizio di ogni scansione, mentre la STA è disconnessa.
    • Ogni gruppo di frame di richiesta di probe che comprende una scansione DEVE utilizzare un indirizzo MAC coerente (NON DEVE randomizzare l'indirizzo MAC a metà scansione).
    • Il numero di sequenza della richiesta di probe DEVE essere iterato normalmente (in sequenza) tra le richieste di probe in una scansione.
    • Il numero di sequenza della richiesta di probe DEVE essere randomizzato tra l'ultima richiesta di probe di una scansione e la prima richiesta di probe della scansione successiva.
  • [C-SR] Sono FORTEMENTE CONSIGLIATI, mentre STA è disconnessa, per consentire solo i seguenti elementi nei frame delle richieste di sondaggio:
    • Set di parametri SSID (0)
    • Set di parametri DS (3)

Se le implementazioni dei dispositivi includono il supporto della modalità di risparmio energetico Wi-Fi come definita nello standard IEEE 802.11,

  • [C-3-1] DEVE disattivare la modalità di risparmio energetico del Wi-Fi ogni volta che un'app acquisisce il blocco WIFI_MODE_FULL_HIGH_PERF o WIFI_MODE_FULL_LOW_LATENCY tramite le API WifiManager.createWifiLock() e WifiManager.WifiLock.acquire() e il blocco è attivo.
  • [C-3-2] La latenza media di round trip tra il dispositivo e un punto di accesso mentre il dispositivo è in modalità di blocco Wi-Fi a bassa latenza (WIFI_MODE_FULL_LOW_LATENCY) DEVE essere inferiore alla latenza durante la modalità di blocco Wi-Fi ad alte prestazioni (WIFI_MODE_FULL_HIGH_PERF).
  • [C-SR] Sono FORTEMENTE CONSIGLIATI per ridurre al minimo la latenza di andata e ritorno del Wi-Fi ogni volta che viene acquisita e ha effetto una serratura a bassa latenza (WIFI_MODE_FULL_LOW_LATENCY).

Se le implementazioni dei dispositivi supportano il Wi-Fi e lo utilizzano per la scansione della posizione:

7.4.2.1. Wi-Fi Direct

Implementazioni del dispositivo:

  • DEVE includere il supporto per Wi-Fi Direct (Wi-Fi peer-to-peer).

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Direct:

  • [C-1-1] DEVE implementare l'API Android corrispondente come descritto nella documentazione dell'SDK.
  • [C-1-2] DEVE segnalare la funzionalità hardware android.hardware.wifi.direct.
  • [C-1-3] DEVE supportare il normale funzionamento del Wi-Fi.
  • [C-1-4] DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Direct.

Implementazioni del dispositivo:

Se le implementazioni dei dispositivi includono il supporto di TDLS e TDLS è abilitato dall'API WiFiManager,

  • [C-1-1] DEVE dichiarare il supporto di TDLS tramite WifiManager.isTdlsSupported.
  • DEVE utilizzare i TDLS solo quando è possibile E vantaggioso.
  • DOVREBBE utilizzare alcune euristiche e NON utilizzare TDLS quando le sue prestazioni potrebbero essere peggiori rispetto a quelle del punto di accesso Wi-Fi.
7.4.2.3. Wi-Fi Aware

Implementazioni del dispositivo:

Se le implementazioni del dispositivo includono il supporto di Wi-Fi Aware ed espongono la funzionalità ad app di terze parti, allora:

  • [C-1-1] DEVE implementare le API WifiAwareManager come descritto nella documentazione dell'SDK.
  • [C-1-2] DEVE dichiarare il flag funzionalità android.hardware.wifi.aware.
  • [C-1-3] DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Aware.
  • [C-1-4] DEVE randomizzare l'indirizzo dell'interfaccia di gestione Wi-Fi Aware a intervalli non superiori a 30 minuti e ogni volta che Wi-Fi Aware è abilitato.

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Aware e della posizione Wi-Fi, come descritto nella sezione 7.4.2.5, ed espongono queste funzionalità ad app di terze parti, allora:

7.4.2.4. Wi-Fi Passpoint

Implementazioni del dispositivo:

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Passpoint:

  • [C-1-1] DEVE implementare le API WifiManager relative a Passpoint come descritto nella documentazione dell'SDK.
  • [C-1-2] DEVE supportare lo standard IEEE 802.11u, in particolare per quanto riguarda l'individuazione e la selezione della rete, ad esempio il servizio di pubblicità generica (GAS) e il protocollo di query della rete di accesso (ANQP).

Al contrario, se le implementazioni dei dispositivi non includono il supporto di Wi-Fi Passpoint:

  • [C-2-1] L'implementazione delle API WifiManager correlate a Passpoint DEVE generare un UnsupportedOperationException.
7.4.2.5. Posizione Wi-Fi (tempo di round trip - RTT del Wi-Fi)

Implementazioni del dispositivo:

Se le implementazioni del dispositivo includono il supporto della posizione Wi-Fi ed espongono la funzionalità ad app di terze parti, allora:

  • [C-1-1] DEVE implementare le API WifiRttManager come descritto nella documentazione dell'SDK.
  • [C-1-2] DEVE dichiarare il flag funzionalità android.hardware.wifi.rtt.
  • [C-1-3] DEVE randomizzare l'indirizzo MAC di origine per ogni burst RTT eseguito mentre l'interfaccia Wi-Fi su cui viene eseguito l'RTT non è associata a un punto di accesso.
7.4.2.6. Offload keepalive Wi-Fi

Implementazioni del dispositivo:

  • DEVE includere il supporto per l'offload di Wi-Fi keepalive.

Se le implementazioni del dispositivo includono il supporto per l'offload di Wi-Fi Keepalive ed espongono la funzionalità ad app di terze parti:

  • [C-1-1] DEVE supportare l'API SocketKeepAlive.

  • [C-1-2] DEVE supportare almeno tre slot keepalive simultanei su Wi-Fi e almeno uno slot keepalive su rete mobile.

Se le implementazioni dei dispositivi non includono il supporto per l'offload di Wi-Fi Keepalive,

7.4.2.7. Wi-Fi Easy Connect (protocollo di provisioning dei dispositivi)

Implementazioni del dispositivo:

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Easy Connect ed espongono la funzionalità ad app di terze parti:

7.4.3. Bluetooth

Se le implementazioni del dispositivo supportano il profilo audio Bluetooth:

  • DOVREBBE supportare i codec audio avanzati e i codec audio Bluetooth (ad es. LDAC).

Se le implementazioni dei dispositivi supportano HFP, A2DP e AVRCP:

  • DEVE supportare almeno 5 dispositivi connessi in totale.

Se le implementazioni del dispositivo dichiarano la funzionalità android.hardware.vr.high_performance:

  • [C-1-1] DEVE supportare Bluetooth 4.2 e l'estensione della lunghezza dei dati Bluetooth LE.

Android include il supporto per Bluetooth e Bluetooth Low Energy.

Se le implementazioni dei dispositivi includono il supporto di Bluetooth e Bluetooth Low Energy:

  • [C-2-1] DEVE dichiarare le funzionalità della piattaforma pertinenti (android.hardware.bluetooth e android.hardware.bluetooth_le rispettivamente) e implementare le API della piattaforma.
  • DEVE implementare profili Bluetooth pertinenti come A2DP, AVRCP, OBEX, HFP e così via, a seconda del dispositivo.

Se le implementazioni dei dispositivi includono il supporto di Bluetooth Low Energy:

  • [C-3-1] DEVE dichiarare la funzionalità hardware android.hardware.bluetooth_le.
  • [C-3-2] DEVE attivare le API Bluetooth basate su GATT (generic attribute profile) come descritto nella documentazione dell'SDK e in android.bluetooth.
  • [C-3-3] DEVE segnalare il valore corretto per BluetoothAdapter.isOffloadedFilteringSupported() per indicare se è implementata la logica di filtraggio per le classi API ScanFilter.
  • [C-3-4] DEVE segnalare il valore corretto per BluetoothAdapter.isMultipleAdvertisementSupported() per indicare se la pubblicità a basso consumo energetico è supportata.
  • DEVE supportare l'offload della logica di filtraggio al chipset Bluetooth durante l'implementazione dell'API ScanFilter.
  • DEVE supportare l'offload della scansione batch al chipset Bluetooth.

  • DEVE supportare più pubblicità con almeno 4 slot.

  • [SR] È VIVAMENTE CONSIGLIATO di implementare un timeout dell'indirizzo privato risolvibile (RPA) non superiore a 15 minuti e di ruotare l'indirizzo al timeout per proteggere la privacy dell'utente.

Se le implementazioni dei dispositivi supportano Bluetooth LE e lo utilizzano per la scansione della posizione:

  • [C-4-1] DEVE fornire un'interfaccia utente per attivare/disattivare la lettura del valore tramite l'API di sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se le implementazioni dei dispositivi includono il supporto per Bluetooth LE e il profilo per apparecchi acustici, come descritto in Supporto audio per apparecchi acustici tramite Bluetooth LE, queste:

7.4.4. Near Field Communication

Implementazioni del dispositivo:

  • DEVE includere un ricetrasmettitore e l'hardware correlato per la tecnologia Near Field Communication (NFC).
  • [C-0-1] DEVE implementare le API android.nfc.NdefMessage e android.nfc.NdefRecord anche se non includono il supporto NFC o dichiarano la funzionalità android.hardware.nfc, in quanto le classi rappresentano un formato di rappresentazione dei dati indipendente dal protocollo.

Se le implementazioni del dispositivo includono hardware NFC e prevedono di renderlo disponibile per app di terze parti:

  • [C-1-1] DEVE segnalare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature().
  • DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC:
  • [C-1-2] DEVE essere in grado di fungere da lettore/scrittore NFC Forum (come definito dalla specifica tecnica NFCForum-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Tipi di tag NFC Forum 1, 2, 3, 4, 5 (definiti da NFC Forum)

  • [SR] VIVAMENTE CONSIGLIATO di essere in grado di leggere e scrivere messaggi NDEF e dati non elaborati tramite i seguenti standard NFC. Tieni presente che, sebbene gli standard NFC siano indicati come FORTEMENTE CONSIGLIATI, la definizione di compatibilità per una versione futura prevede di modificarli in OBBLIGATORI. Questi standard sono facoltativi in questa versione, ma saranno obbligatori nelle versioni future. È FORTEMENTE CONSIGLIATO ai dispositivi esistenti e nuovi che eseguono questa versione di Android di soddisfare questi requisiti ora, in modo da poter eseguire l'upgrade alle versioni future della piattaforma.

  • [C-1-13] DEVE eseguire il polling di tutte le tecnologie supportate in modalità di rilevamento NFC.

  • DEVE essere in modalità di rilevamento NFC mentre il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.
  • DEVE essere in grado di leggere il codice a barre e l'URL (se codificato) dei prodotti Thinfilm NFC Barcode.

Tieni presente che i link disponibili pubblicamente non sono disponibili per le specifiche JIS, ISO e NFC Forum citate sopra.

Android include il supporto per la modalità Host Card Emulation (HCE) NFC.

Se le implementazioni dei dispositivi includono un chipset del controller NFC in grado di supportare HCE (per NfcA e/o NfcB) e il routing dell'ID applicazione (AID),:

  • [C-2-1] DEVE segnalare la costante della funzionalità android.hardware.nfc.hce.
  • [C-2-2] DEVE supportare le API NFC HCE come definite nell'SDK Android.

Se le implementazioni dei dispositivi includono un chipset del controller NFC in grado di supportare HCE per NfcF e implementano la funzionalità per applicazioni di terze parti:

  • [C-3-1] DEVE segnalare la costante della funzionalità android.hardware.nfc.hcef.
  • [C-3-2] DEVE implementare le API di emulazione della scheda NfcF come definite nell'SDK Android.

Se le implementazioni dei dispositivi includono il supporto NFC generale come descritto in questa sezione e supportano le tecnologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF su MIFARE Classic) nel ruolo di lettore/scrittore:

  • [C-4-1] DEVE implementare le API Android corrispondenti come documentato dall'SDK Android.
  • [C-4-2] DEVE segnalare la funzionalità com.nxp.mifare dal metodo android.content.pm.PackageManager.hasSystemFeature(). Tieni presente che questa non è una funzionalità Android standard e pertanto non viene visualizzata come costante nella classe android.content.pm.PackageManager.

7.4.5. Capacità di rete minima

Implementazioni del dispositivo:

  • [C-0-1] DEVE includere il supporto di una o più forme di networking dei dati. Nello specifico, le implementazioni dei dispositivi DEVONO includere il supporto di almeno uno standard di dati in grado di raggiungere una velocità di 200 Kbit/sec o superiore. Esempi di tecnologie che soddisfano questo requisito includono EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
  • DOVREBBE includere anche il supporto di almeno uno standard comune per i dati wireless, ad esempio 802.11 (Wi-Fi), quando uno standard di rete fisico (ad esempio Ethernet) è la connessione dati principale.
  • PUÒ implementare più di una forma di connettività dei dati.
  • [C-0-2] DEVE includere uno stack di rete IPv6 e supportare la comunicazione IPv6 utilizzando le API gestite, come java.net.Socket e java.net.URLConnection, nonché le API native, come i socket AF_INET6.
  • [C-0-3] DEVE abilitare IPv6 per impostazione predefinita.
  • DEVE garantire che la comunicazione IPv6 sia affidabile quanto IPv4, ad esempio:
    • [C-0-4] DEVE mantenere la connettività IPv6 in modalità Doze.
    • [C-0-5] La limitazione della velocità NON DEVE causare la perdita della connettività IPv6 sul dispositivo su qualsiasi rete compatibile con IPv6 che utilizzi durate RA di almeno 180 secondi.
  • [C-0-6] DEVE fornire alle applicazioni di terze parti connettività IPv6 diretta alla rete quando è connesso a una rete IPv6, senza alcuna forma di traduzione di indirizzi o porte a livello locale sul dispositivo. Sia le API gestite, come Socket#getLocalAddress o Socket#getLocalPort, sia le API NDK, come getsockname() o IPV6_PKTINFO, DEVONO restituire l'indirizzo IP e la porta effettivamente utilizzati per inviare e ricevere pacchetti sulla rete.

Il livello di supporto IPv6 richiesto dipende dal tipo di rete, come mostrato nei seguenti requisiti.

Se le implementazioni dei dispositivi supportano il Wi-Fi:

  • [C-1-1] DEVE supportare il funzionamento a doppio stack e solo IPv6 su Wi-Fi.

Se le implementazioni dei dispositivi supportano Ethernet:

  • [C-2-1] DEVE supportare il funzionamento dual-stack su Ethernet.

Se le implementazioni dei dispositivi supportano i dati cellulari:

  • DEVE supportare il funzionamento IPv6 (solo IPv6 e possibilmente dual-stack) sulla rete cellulare.

Se le implementazioni dei dispositivi supportano più di un tipo di rete (ad es. Wi-Fi e dati mobili):

  • [C-3-1] DEVE soddisfare contemporaneamente i requisiti di cui sopra su ogni rete quando il dispositivo è connesso contemporaneamente a più di un tipo di rete.

7.4.6. Impostazioni sincronizzazione

Implementazioni del dispositivo:

  • [C-0-1] DEVE avere l'impostazione di sincronizzazione automatica principale attiva per impostazione predefinita in modo che il metodo getMasterSyncAutomatically() restituisca "true".

7.4.7. Risparmio dati

Se le implementazioni dei dispositivi includono una connessione a consumo, sono:

  • [SR] VIVAMENTE CONSIGLIATO di fornire la modalità Risparmio dati.

Se le implementazioni del dispositivo forniscono la modalità Risparmio dati:

Se le implementazioni del dispositivo non forniscono la modalità Risparmio dati:

  • [C-2-1] DEVE restituire il valore RESTRICT_BACKGROUND_STATUS_DISABLED per ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] MUST NOT broadcast ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • [C-2-3] DEVE avere un'attività che gestisce l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ma PUÒ implementarlo come no-op.

7.4.8. Secure Element

Se le implementazioni dei dispositivi supportano Open Mobile API in grado di proteggere gli elementi sicuri e renderli disponibili per le app di terze parti:

7.5. Fotocamere

Se le implementazioni dei dispositivi includono almeno una videocamera:

  • [C-1-1] DEVE dichiarare il flag funzionalità android.hardware.camera.any.
  • [C-1-2] DEVE essere possibile per un'applicazione allocare simultaneamente 3 bitmap RGBA_8888 di dimensioni pari a quelle delle immagini prodotte dal sensore della fotocamera con la risoluzione più alta sul dispositivo, mentre la fotocamera è aperta per lo scopo di anteprima di base e acquisizione di foto.
  • [C-1-3] DEVE garantire che l'applicazione fotocamera preinstallata predefinita che gestisce gli intent MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE o MediaStore.ACTION_VIDEO_CAPTURE sia responsabile della rimozione della posizione dell'utente nei metadati dell'immagine prima di inviarla all'applicazione ricevente quando quest'ultima non dispone di ACCESS_FINE_LOCATION.

7.5.1. Fotocamera posteriore

Una fotocamera posteriore è una fotocamera che si trova sul lato del dispositivo opposto al display, ovvero riprende le scene sul lato opposto del dispositivo, come una fotocamera tradizionale.

Implementazioni del dispositivo:

  • DEVE includere una fotocamera posteriore.

Se le implementazioni dei dispositivi includono almeno una videocamera posteriore:

  • [C-1-1] DEVE segnalare il flag funzionalità android.hardware.camera e android.hardware.camera.any.
  • [C-1-2] DEVE avere una risoluzione di almeno 2 megapixel.
  • DEVE avere l'autofocus hardware o software implementato nel driver della fotocamera (trasparente per il software applicativo).
  • POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
  • POTREBBE includere un flash.

Se la fotocamera include un flash:

  • [C-2-1] la lampada flash NON DEVE essere accesa mentre è stata registrata un'istanza android.hardware.Camera.PreviewCallback su una superficie di anteprima della videocamera, a meno che l'applicazione non abbia attivato esplicitamente il flash attivando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON di un oggetto Camera.Parameters. Tieni presente che questo vincolo non si applica all'applicazione fotocamera di sistema integrata nel dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

Una fotocamera frontale è una fotocamera posizionata sullo stesso lato del dispositivo del display, ovvero una fotocamera in genere utilizzata per riprendere l'utente, ad esempio per le videoconferenze e applicazioni simili.

Implementazioni del dispositivo:

  • POTREBBE includere una fotocamera anteriore.

Se le implementazioni dei dispositivi includono almeno una videocamera frontale:

  • [C-1-1] DEVE segnalare il flag funzionalità android.hardware.camera.any e android.hardware.camera.front.
  • [C-1-2] DEVE avere una risoluzione di almeno VGA (640x480 pixel).
  • [C-1-3] NON DEVE utilizzare una fotocamera frontale come predefinita per l'API Camera e NON DEVE configurare l'API in modo che tratti una fotocamera frontale come fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
  • [C-1-4] L'anteprima della videocamera DEVE essere specchiata orizzontalmente rispetto all'orientamento specificato dall'applicazione quando l'applicazione corrente ha richiesto esplicitamente la rotazione del display della videocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation(). Al contrario, l'anteprima DEVE essere specchiata lungo l'asse orizzontale predefinito del dispositivo quando l'applicazione corrente non richiede esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation().
  • [C-1-5] NON DEVE eseguire il mirroring dell'immagine statica o dei flussi video acquisiti finali restituiti ai callback dell'applicazione o salvati nello spazio di archiviazione multimediale.
  • [C-1-6] DEVE rispecchiare l'immagine visualizzata dalla postview nello stesso modo del flusso di immagini di anteprima della videocamera.
  • POSSONO includere funzionalità (come messa a fuoco automatica, flash e così via) disponibili per le fotocamere posteriori, come descritto nella sezione 7.5.1.

Se le implementazioni del dispositivo possono essere ruotate dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente):

  • [C-2-1] L'anteprima della videocamera DEVE essere specchiata orizzontalmente rispetto all'orientamento attuale del dispositivo.

7.5.3. Videocamera esterna

Implementazioni del dispositivo:

  • POTREBBE includere il supporto di una videocamera esterna che non è necessariamente sempre connessa.

Se le implementazioni dei dispositivi includono il supporto di una videocamera esterna:

  • [C-1-1] DEVE dichiarare il flag della funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any.
  • [C-1-2] DEVE supportare USB Video Class (UVC 1.0 o versioni successive) se la videocamera esterna si connette tramite la porta host USB.
  • [C-1-3] DEVE superare i test CTS della videocamera con un dispositivo videocamera esterno fisico collegato. I dettagli dei test CTS della videocamera sono disponibili all'indirizzo source.android.com.
  • DEVE supportare compressioni video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ad es. stream di immagini grezzi o compressi in modo indipendente).
  • POTREBBE supportare più videocamere.
  • POTREBBE supportare la codifica video basata sulla videocamera.

Se la codifica video basata sulla videocamera è supportata:

  • [C-2-1] L'implementazione del dispositivo DEVE poter accedere a uno stream simultaneo non codificato / MJPEG (risoluzione QVGA o superiore).

7.5.4. Comportamento dell'API Camera

Android include due pacchetti API per accedere alla fotocamera. L'API android.hardware.camera2 più recente espone il controllo della fotocamera di livello inferiore all'app, inclusi flussi di streaming/scatto a raffica efficienti senza copia e controlli per frame di esposizione, guadagno, guadagni del bilanciamento del bianco, conversione del colore, riduzione del rumore, nitidezza e altro ancora.

Il pacchetto API precedente, android.hardware.Camera, è contrassegnato come ritirato in Android 5.0, ma DOVREBBE essere ancora disponibile per l'utilizzo da parte delle app. Le implementazioni dei dispositivi Android DEVONO garantire il supporto continuo dell'API come descritto in questa sezione e nell'SDK Android.

Tutte le funzionalità comuni tra la classe android.hardware.Camera deprecata e il pacchetto android.hardware.camera2 più recente DEVONO avere prestazioni e qualità equivalenti in entrambe le API. Ad esempio, con impostazioni equivalenti, la velocità e l'accuratezza dell'autofocus DEVONO essere identiche e la qualità delle immagini acquisite DEVE essere la stessa. Le funzionalità che dipendono dalle diverse semantiche delle due API non devono avere velocità o qualità corrispondenti, ma DEVONO corrispondere il più possibile.

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API correlate alla fotocamera, per tutte le fotocamere disponibili. Implementazioni del dispositivo:

  • [C-0-1] DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione quando un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] DEVE inoltre essere nel formato di codifica NV21 quando un'applicazione registra un'istanza android.hardware.Camera.PreviewCallback e il sistema chiama il metodo onPreviewFrame() e il formato di anteprima è YCbCr_420_SP, i dati nel byte[] passati a onPreviewFrame(). ovvero NV21 DEVE essere il valore predefinito.
  • [C-0-3] DEVE supportare il formato YV12 (indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia per le fotocamere anteriori che per quelle posteriori per android.hardware.Camera. Il codificatore video hardware e la videocamera possono utilizzare qualsiasi formato pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione in YV12.
  • [C-0-4] DEVE supportare i formati android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG come output tramite l'API android.media.ImageReader per i dispositivi android.hardware.camera2 che pubblicizzano la funzionalità REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities.
  • [C-0-5] DEVE comunque implementare l'API Camera completa inclusa nella documentazione dell'SDK Android, indipendentemente dal fatto che il dispositivo includa la messa a fuoco automatica hardware o altre funzionalità. Ad esempio, le videocamere che non hanno la messa a fuoco automatica DEVONO comunque chiamare le istanze android.hardware.Camera.AutoFocusCallback registrate (anche se non è pertinente per una videocamera senza messa a fuoco automatica). Tieni presente che questo vale per le fotocamere frontali; ad esempio, anche se la maggior parte delle fotocamere frontali non supporta la messa a fuoco automatica, i callback API DEVONO comunque essere "falsificati" come descritto.
  • [C-0-6] DEVE riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters e nella classe android.hardware.camera2.CaptureRequest. Al contrario, le implementazioni del dispositivo NON DEVONO rispettare o riconoscere le costanti stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. ovvero le implementazioni dei dispositivi DEVONO supportare tutti i parametri standard della fotocamera se l'hardware lo consente e NON DEVONO supportare tipi di parametri della fotocamera personalizzati. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini utilizzando tecniche di imaging High Dynamic Range (HDR) DEVONO supportare il parametro della videocamera Camera.SCENE_MODE_HDR.
  • [C-0-7] DEVE segnalare il livello di supporto appropriato con la proprietà android.info.supportedHardwareLevel come descritto nell'SDK Android e segnalare i flag delle funzionalità del framework appropriati.
  • [C-0-8] DEVE anche dichiarare le funzionalità della singola videocamera android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag delle funzionalità appropriati; DEVE definire il flag della funzionalità se uno qualsiasi dei dispositivi videocamera collegati la supporta.
  • [C-0-9] DEVE trasmettere l'intent Camera.ACTION_NEW_PICTURE ogni volta che la fotocamera scatta una nuova foto e la voce della foto è stata aggiunta all'archivio multimediale.
  • [C-0-10] DEVE trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e la voce dell'immagine è stata aggiunta all'archivio multimediale.
  • [C-0-11] TUTTE le videocamere accessibili tramite l'API android.hardware.Camera ritirata DEVONO essere accessibili anche tramite l'API android.hardware.camera2.
  • [C-SR] Per i dispositivi con più videocamere RGB rivolte nella stessa direzione, è VIVAMENTE CONSIGLIATO supportare un dispositivo videocamera logico che elenca la funzionalità CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, costituita da tutte le videocamere RGB rivolte in quella direzione come sottodispositivi fisici.

Se le implementazioni dei dispositivi forniscono un'API fotocamera proprietaria ad app di terze parti:

7.5.5. Orientamento della videocamera

Se le implementazioni del dispositivo hanno una fotocamera anteriore o posteriore, queste fotocamere:

  • [C-1-1] DEVE essere orientata in modo che la dimensione lunga della videocamera sia allineata alla dimensione lunga dello schermo. ovvero, quando il dispositivo è tenuto in orientamento orizzontale, le videocamere DEVONO acquisire immagini in orientamento orizzontale. Ciò vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica sia ai dispositivi con orientamento orizzontale principale sia a quelli con orientamento verticale principale.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

Implementazioni del dispositivo:

  • [C-0-1] DEVE includere un gestore dei download che le applicazioni POSSONO utilizzare per scaricare file di dati e DEVONO essere in grado di scaricare singoli file di almeno 100 MB nella posizione "cache" predefinita.

7.6.2. Spazio di archiviazione condiviso dell'applicazione

Implementazioni del dispositivo:

  • [C-0-1] DEVE offrire uno spazio di archiviazione da condividere tra le applicazioni, spesso chiamato anche "spazio di archiviazione esterno condiviso", "spazio di archiviazione condiviso dell'applicazione" o dal percorso Linux "/sdcard" su cui è montato.
  • [C-0-2] DEVE essere configurato con l'archiviazione condivisa montata per impostazione predefinita, ovvero "pronta all'uso", indipendentemente dal fatto che l'archiviazione sia implementata su un componente di archiviazione interno o su un supporto di archiviazione rimovibile (ad es. slot per schede Secure Digital).
  • [C-0-3] DEVE montare lo spazio di archiviazione condiviso dell'applicazione direttamente sul percorso Linux sdcard o includere un link simbolico Linux da sdcard al punto di montaggio effettivo.
  • [C-0-4] DEVE applicare l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE a questo spazio di archiviazione condiviso come documentato nell'SDK.
  • [C-0-5] DEVE attivare lo storage isolato per impostazione predefinita per tutte le app che hanno come target il livello API 29 o versioni successive, tranne nelle seguenti situazioni:
    • quando l'app è stata installata prima dell'upgrade del dispositivo al livello API 29, indipendentemente dall'API di destinazione dell'app.
    • quando l'app ha richiesto android:requestLegacyExternalStorage="true" nel manifest.
    • quando all'app viene concessa l'autorizzazione android.permission.WRITE_MEDIA_STORAGE.
  • [C-0-6] DEVE garantire che le app con spazio di archiviazione isolato attivato non abbiano accesso diretto al file system ai file al di fuori delle directory specifiche dell'applicazione, come restituito dai metodi API Context, ad esempio i metodi Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs() e Context.getObbDirs().
  • [C-0-7] DEVE oscurare i metadati di posizione, come i tag EXIF GPS, memorizzati nei file multimediali quando questi file vengono consultati tramite MediaStore, tranne quando l'app chiamante dispone dell'autorizzazione ACCESS_MEDIA_LOCATION.

Le implementazioni dei dispositivi POSSONO soddisfare i requisiti precedenti utilizzando uno dei seguenti metodi:

  • Memoria rimovibile accessibile all'utente, ad esempio uno slot per schede Secure Digital (SD).
  • Una parte della memoria interna (non rimovibile) come implementata in Android Open Source Project (AOSP).

Se le implementazioni dei dispositivi utilizzano supporti di archiviazione rimovibili per soddisfare i requisiti di cui sopra:

  • [C-1-1] DEVE implementare un avviso nell'interfaccia utente sotto forma di toast o popup che avvisa l'utente quando non è inserito alcun supporto di archiviazione nello slot.
  • [C-1-2] DEVE includere un supporto di archiviazione formattato FAT (ad es. scheda SD) o mostrare sulla confezione e su altro materiale disponibile al momento dell'acquisto che il supporto di archiviazione deve essere acquistato separatamente.

Se le implementazioni dei dispositivi utilizzano una parte dello spazio di archiviazione non rimovibile per soddisfare i requisiti di cui sopra:

  • DEVE utilizzare l'implementazione AOSP dello spazio di archiviazione condiviso interno dell'applicazione.
  • POTREBBE condividere lo spazio di archiviazione con i dati privati dell'applicazione.

Se le implementazioni del dispositivo includono più percorsi di archiviazione condivisa (ad esempio uno slot per scheda SD e una memoria interna condivisa):

  • [C-2-1] DEVE consentire la scrittura nella memoria esterna secondaria solo alle applicazioni Android preinstallate e privilegiate con l'autorizzazione WRITE_MEDIA_STORAGE, tranne quando si scrive nelle directory specifiche del pacchetto o all'interno di URI restituito dall'intent ACTION_OPEN_DOCUMENT_TREE.
  • [C-2-2] DEVE richiedere che l'accesso diretto associato all'autorizzazione android.permission.WRITE_MEDIA_STORAGE venga concesso solo alle app visibili all'utente quando viene concessa anche l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE.
  • [SR] È VIVAMENTE CONSIGLIATO che le applicazioni Android preinstallate e con privilegi utilizzino API pubbliche come MediaStore per interagire con i dispositivi di archiviazione, anziché fare affidamento sull'accesso diretto concesso da android.permission.WRITE_MEDIA_STORAGE.

Se le implementazioni dei dispositivi hanno una porta USB con supporto della modalità periferica USB:

  • [C-3-1] DEVE fornire un meccanismo per accedere ai dati nell'archivio condiviso dell'applicazione da un computer host.
  • DEVE esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione dei contenuti multimediali di Android e android.provider.MediaStore.
  • PUÒ utilizzare l'archiviazione di massa USB, ma DEVE utilizzare il protocollo di trasferimento multimediale per soddisfare questo requisito.

Se le implementazioni dei dispositivi hanno una porta USB con modalità periferica USB e supportano il protocollo di trasferimento multimediale,

  • DEVE essere compatibile con l'host MTP Android di riferimento, Android File Transfer.
  • DEVE segnalare una classe di dispositivo USB pari a 0x00.
  • DEVE segnalare il nome dell'interfaccia USB "MTP".

7.6.3. Spazio di archiviazione utilizzabile

Se il dispositivo è mobile per natura, a differenza della televisione, le implementazioni del dispositivo sono:

  • [SR] È VIVAMENTE CONSIGLIATO di implementare l'archiviazione adattabile in una posizione stabile a lungo termine, poiché la disconnessione accidentale può causare la perdita/il danneggiamento dei dati.

Se la porta del dispositivo di archiviazione rimovibile si trova in una posizione stabile a lungo termine, ad esempio all'interno del vano batteria o di un'altra copertura protettiva, le implementazioni del dispositivo sono:

7.7. USB

Se le implementazioni del dispositivo hanno una porta USB:

  • DEVE supportare la modalità periferica USB e la modalità host USB.

7.7.1. Modalità periferica USB

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità periferica:

  • [C-1-1] La porta DEVE essere collegabile a un host USB con una porta USB standard di tipo A o di tipo C.
  • [C-1-2] DEVE segnalare il valore corretto di iSerialNumber nel descrittore del dispositivo standard USB tramite android.os.Build.SERIAL.
  • [C-1-3] DEVE rilevare caricabatterie da 1,5 A e 3 A in base allo standard di resistenza Type-C e DEVE rilevare le modifiche alla pubblicità se supportano USB Type-C.
  • [SR] La porta DEVE utilizzare il fattore di forma USB micro-B, micro-AB o Type-C. È VIVAMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti, in modo da poter eseguire l'upgrade alle versioni future della piattaforma.
  • [SR] La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o attivare la rotazione dello schermo software per tutte le app (inclusa la schermata Home), in modo che il display venga visualizzato correttamente quando il dispositivo è orientato con la porta in basso. È VIVAMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti in modo da poter eseguire l'upgrade alle versioni future della piattaforma.
  • [SR] DOVREBBE implementare il supporto per assorbire una corrente di 1,5 A durante il segnale acustico HS e il traffico come specificato nella specifica di ricarica della batteria USB, revisione 1.2. È VIVAMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti, in modo da poter eseguire l'upgrade alle versioni future della piattaforma.
  • [SR] È VIVAMENTE CONSIGLIATO di non supportare metodi di ricarica proprietari che modificano la tensione Vbus oltre i livelli predefiniti o alterano i ruoli di sink/source, in quanto ciò potrebbe causare problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard di alimentazione USB. Sebbene sia indicato come "FORTEMENTE CONSIGLIATO", nelle future versioni di Android potremmo RICHIEDERE che tutti i dispositivi di tipo C supportino la piena interoperabilità con i caricabatterie standard di tipo C.
  • [SR] VIVAMENTE CONSIGLIATO per supportare Power Delivery per lo scambio di ruoli di dati e alimentazione quando supportano USB Type-C e la modalità host USB.
  • DOVREBBE supportare Power Delivery per la ricarica ad alta tensione e le modalità alternative come l'uscita video.
  • DEVE implementare l'API e la specifica Android Open Accessory (AOA) come documentato nella documentazione dell'SDK Android.

Se le implementazioni dei dispositivi includono una porta USB e implementano la specifica AOA:

  • [C-2-1] DEVE dichiarare il supporto per la funzionalità hardware android.hardware.usb.accessory.
  • [C-2-2] La classe di archiviazione di massa USB DEVE includere la stringa "android" alla fine della stringa iInterface della descrizione dell'interfaccia dell'archiviazione di massa USB

7.7.2. Modalità host USB

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host:

  • [C-1-1] DEVE implementare l'API host USB di Android come documentato nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host.
  • [C-1-2] DEVE implementare il supporto per connettere periferiche USB standard, ovvero DEVE:
    • Avere una porta di tipo C sul dispositivo o essere fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB Type-C standard (dispositivo USB Type-C).
    • Disporre di una porta di tipo A sul dispositivo o essere fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB standard di tipo A.
    • Avere una porta micro-AB sul dispositivo, che DOVREBBE essere fornita con un cavo di adattamento a una porta Type-A standard.
  • [C-1-3] NON DEVE essere spedito con un adattatore che converte le porte USB di tipo A o micro-AB in una porta (presa) di tipo C.
  • [C-SR] È FORTEMENTE CONSIGLIATO di implementare la classe audio USB come documentato nella documentazione dell'SDK Android.
  • DEVE supportare la ricarica del dispositivo periferico USB collegato in modalità host; pubblicizzare una corrente di alimentazione di almeno 1,5 A come specificato nella sezione Termination Parameters (Parametri di terminazione) della specifica del cavo e del connettore USB Type-C, revisione 1.2 per i connettori USB Type-C o utilizzare l'intervallo di corrente di uscita della porta di ricarica downstream (CDP) come specificato nelle specifiche di ricarica della batteria USB, revisione 1.2 per i connettori Micro-AB.
  • DEVE implementare e supportare gli standard USB Type-C.

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e la classe audio USB:

  • [C-2-1] DEVE supportare la classe USB HID.
  • [C-2-2] DEVE supportare il rilevamento e la mappatura dei seguenti campi di dati HID specificati nelle tabelle di utilizzo HID USB e nella richiesta di utilizzo dei comandi vocali alle costanti KeyEvent come indicato di seguito:
    • Pagina di utilizzo (0xC) ID utilizzo (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Pagina di utilizzo (0xC) ID utilizzo (0x0E9): KEYCODE_VOLUME_UP
    • Pagina di utilizzo (0xC) ID utilizzo (0x0EA): KEYCODE_VOLUME_DOWN
    • Pagina di utilizzo (0xC) ID utilizzo (0x0CF): KEYCODE_VOICE_ASSIST

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e Storage Access Framework (SAF),

  • [C-3-1] DEVE riconoscere tutti i dispositivi MTP (Media Transfer Protocol) connessi da remoto e rendere accessibili i relativi contenuti tramite gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT.

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e USB Type-C:

  • [C-4-1] DEVE implementare la funzionalità Dual Role Port come definita dalla specifica USB Type-C (sezione 4.5.1.3.3).
  • [SR] VIVAMENTE CONSIGLIATO per supportare DisplayPort, DOVREBBE supportare velocità di trasferimento dati USB SuperSpeed ed è VIVAMENTE CONSIGLIATO per supportare Power Delivery per lo scambio di ruoli di dati e alimentazione.
  • [SR] VIVAMENTE CONSIGLIATO di NON supportare la modalità accessorio adattatore audio come descritto nell'appendice A della specifica del cavo e del connettore USB Type-C Revisione 1.2.
  • DEVE implementare il modello Try.* più appropriato per il fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DEVE implementare il modello Try.SNK.

7.8. Audio

7.8.1. Microfono

Se le implementazioni del dispositivo includono un microfono:

  • [C-1-1] DEVE segnalare la costante della funzionalità android.hardware.microphone.
  • [C-1-2] DEVE soddisfare i requisiti di registrazione audio riportati nella sezione 5.4.
  • [C-1-3] DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
  • [SR] Sono FORTEMENTE CONSIGLIATI per supportare la registrazione di suoni quasi impercettibili come descritto nella sezione 7.8.3.

Se le implementazioni del dispositivo omettono un microfono:

  • [C-2-1] NON DEVE segnalare la costante della funzionalità android.hardware.microphone.
  • [C-2-2] DEVE implementare l'API di registrazione audio almeno come no-ops, come indicato nella sezione 7.

7.8.2. Uscita audio

Se le implementazioni dei dispositivi includono un altoparlante o una porta di output audio/multimediale per una periferica di output audio come un jack audio da 3,5 mm a 4 conduttori o una porta in modalità host USB che utilizza la classe audio USB, queste:

  • [C-1-1] DEVE segnalare la costante della funzionalità android.hardware.audio.output.
  • [C-1-2] DEVE soddisfare i requisiti di riproduzione audio riportati nella sezione 5.5.
  • [C-1-3] DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
  • [SR] VIVAMENTE CONSIGLIATO per supportare la riproduzione di suoni quasi ultrasonici, come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono un altoparlante o una porta di uscita audio:

  • [C-2-1] NON DEVE segnalare la funzionalità android.hardware.audio.output.
  • [C-2-2] DEVE implementare almeno le API correlate all'output audio come no-op.

Ai fini di questa sezione, una "porta di uscita" è un'interfaccia fisica come un jack audio da 3, 5 mm, HDMI o una porta in modalità host USB con classe audio USB. Il supporto dell'output audio tramite protocolli basati su radio come Bluetooth, Wi-Fi o rete cellulare non è considerato un "output port".

7.8.2.1. Porte audio analogiche

Per essere compatibili con le cuffie e altri accessori audio che utilizzano la spina audio da 3, 5 mm nell'ecosistema Android, se le implementazioni dei dispositivi includono una o più porte audio analogiche:

  • [C-SR] È FORTEMENTE CONSIGLIATO includere almeno una delle porte audio come jack audio da 3,5 mm a 4 conduttori.

Se le implementazioni dei dispositivi hanno un jack audio da 3, 5 mm a 4 conduttori:

  • [C-1-1] DEVE supportare la riproduzione audio su cuffie stereo e cuffie stereo con microfono.
  • [C-1-2] DEVE supportare i connettori audio TRRS con l'ordine dei pin CTIA.
  • [C-1-3] DEVE supportare il rilevamento e la mappatura dei codici chiave per i seguenti tre intervalli di impedenza equivalente tra il microfono e i conduttori di terra sul connettore audio:
    • 70 ohm o meno: KEYCODE_HEADSETHOOK
    • 210-290 ohm: KEYCODE_VOLUME_UP
    • 360-680 ohm: KEYCODE_VOLUME_DOWN
  • [C-1-4] DEVE attivare ACTION_HEADSET_PLUG all'inserimento di una spina, ma solo dopo che tutti i contatti della spina toccano i segmenti pertinenti del jack.
  • [C-1-5] DEVE essere in grado di pilotare almeno 150 mV ± 10% della tensione di uscita su un'impedenza dell'altoparlante di 32 ohm.
  • [C-1-6] DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V e 2,9 V.
  • [C-1-7] DEVE rilevare e mappare il codice tasto per il seguente intervallo di impedenza equivalente tra il microfono e i conduttori di terra sul jack audio:
    • 110-180 ohm: KEYCODE_VOICE_ASSIST
  • [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare i jack audio con l'ordine dei pin OMTP.
  • [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare la registrazione audio da cuffie stereo con microfono.

Se le implementazioni dei dispositivi hanno un jack audio da 3, 5 mm a 4 conduttori e supportano un microfono e trasmettono android.intent.action.HEADSET_PLUG con il valore aggiuntivo del microfono impostato su 1, allora:

  • [C-2-1] DEVE supportare il rilevamento del microfono sull'accessorio audio collegato.
7.8.2.2. Porte audio digitali

Per essere compatibili con le cuffie e altri accessori audio che utilizzano connettori USB-C e implementano (classe audio USB) nell'ecosistema Android come definito nella specifica delle cuffie USB per Android.

Per i requisiti specifici del dispositivo, consulta la sezione 2.2.1.

7.8.3. Quasi ultrasuoni

L'audio quasi ultrasonico è la banda da 18,5 kHz a 20 kHz.

Implementazioni del dispositivo:

  • DEVE segnalare correttamente il supporto della funzionalità audio a ultrasuoni tramite l'API AudioManager.getProperty nel seguente modo:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND è "true", le sorgenti audio VOICE_RECOGNITION e UNPROCESSED DEVONO soddisfare i seguenti requisiti:

  • [C-1-1] La risposta di potenza media del microfono nella banda da 18,5 kHz a 20 kHz NON DEVE essere inferiore di più di 15 dB rispetto alla risposta a 2 kHz.
  • [C-1-2] Il rapporto segnale/rumore non ponderato del microfono nell'intervallo da 18,5 kHz a 20 kHz per un tono a 19 kHz a -26 dBFS NON DEVE essere inferiore a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND è "true":

  • [C-2-1] La risposta media dell'altoparlante a 18,5 kHz - 20 kHz NON DEVE essere inferiore a 40 dB rispetto alla risposta a 2 kHz.

7.8.4. Integrità del segnale

Implementazioni del dispositivo:

  • DEVE fornire un percorso del segnale audio privo di problemi sia per i flussi di input che di output sui dispositivi portatili, come definito da zero problemi misurati durante un test di un minuto per percorso. Esegui il test utilizzando "Automated Glitch Test" di [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester).

Il test richiede un dongle di loopback audio, utilizzato direttamente in un jack da 3,5 mm e/o in combinazione con un adattatore da USB-C a 3,5 mm. Tutte le porte di uscita audio DEVONO essere testate.

OboeTester attualmente supporta i percorsi AAudio, pertanto le seguenti combinazioni DEVONO essere testate per rilevare problemi utilizzando AAudio:

Modalità Prestazioni Condivisione Frequenza di campionamento in uscita In Chans Out Chans
LOW_LATENCY ESCLUSIVO NON SPECIFICATO 1 2
LOW_LATENCY ESCLUSIVO NON SPECIFICATO 2 1
LOW_LATENCY CONDIVISO NON SPECIFICATO 1 2
LOW_LATENCY CONDIVISO NON SPECIFICATO 2 1
NESSUNO CONDIVISO 48000 1 2
NESSUNO CONDIVISO 48000 2 1
NESSUNO CONDIVISO 44100 1 2
NESSUNO CONDIVISO 44100 2 1
NESSUNO CONDIVISO 16000 1 2
NESSUNO CONDIVISO 16000 2 1

Un flusso affidabile DEVE soddisfare i seguenti criteri per il rapporto segnale/rumore (SNR) e la distorsione armonica totale (THD) per una sinusoide a 2000 Hz.

Trasduttore THD SNR
altoparlante integrato principale, misurato utilizzando un microfono di riferimento esterno < 3,0% >= 50 dB
microfono integrato principale, misurato utilizzando un altoparlante di riferimento esterno < 3,0% >= 50 dB
Jack analogici da 3,5 mm integrati, testati utilizzando l'adattatore loopback < 1% >= 60 dB
Adattatori USB forniti con lo smartphone, testati utilizzando l'adattatore loopback < 1,0% >= 60 dB

7.9. Realtà virtuale

Android include API e funzionalità per creare applicazioni di "realtà virtuale" (VR), tra cui esperienze VR mobile di alta qualità. Le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

7.9.1. Modalità Realtà virtuale

Android include il supporto della modalità VR, una funzionalità che gestisce il rendering stereoscopico delle notifiche e disattiva i componenti dell'interfaccia utente del sistema monoculare mentre un'applicazione VR è in primo piano.

7.9.2. Modalità Realtà virtuale - Alte prestazioni

Se le implementazioni dei dispositivi supportano la modalità VR:

  • [C-1-1] DEVE avere almeno 2 core fisici.
  • [C-1-2] DEVE dichiarare la funzionalità android.hardware.vr.high_performance.
  • [C-1-3] DEVE supportare la modalità di prestazioni sostenute.
  • [C-1-4] DEVE supportare OpenGL ES 3.2.
  • [C-1-5] MUST support android.hardware.vulkan.level 0.
  • DEVE supportare android.hardware.vulkan.level 1 o versioni successive.
  • [C-1-6] DEVE implementare EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace ed esporre le estensioni nell'elenco delle estensioni EGL disponibili.
  • [C-1-8] DEVE implementare GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
  • [C-SR] È FORTEMENTE CONSIGLIATO implementare GL_EXT_external_buffer, GL_EXT_EGL_image_array ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
  • [C-SR] Are STRONGLY RECOMMENDED to support Vulkan 1.1.
  • [C-SR] È VIVAMENTE CONSIGLIATO di implementare VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image ed esporlo nell'elenco delle estensioni Vulkan disponibili.
  • [C-SR] È FORTEMENTE CONSIGLIATO esporre almeno una famiglia di code Vulkan in cui flags contenga sia VK_QUEUE_GRAPHICS_BIT sia VK_QUEUE_COMPUTE_BIT e queueCount sia almeno 2.
  • [C-1-7] La GPU e il display DEVONO essere in grado di sincronizzare l'accesso al buffer frontale condiviso in modo che il rendering alternato per occhio dei contenuti VR a 60 fps con due contesti di rendering venga visualizzato senza artefatti di tearing visibili.
  • [C-1-9] DEVE implementare il supporto dei flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT come descritto nell'NDK.
  • [C-1-10] DEVE implementare il supporto per AHardwareBuffer con qualsiasi combinazione dei flag di utilizzo AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT per almeno i seguenti formati: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
  • [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare l'allocazione di AHardwareBuffer con più di un livello e flag e formati specificati in C-1-10.
  • [C-1-11] DEVE supportare la decodifica H.264 almeno a 3840 x 2160 a 30 fps, compressa a una media di 40 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps - 10 Mbps o 2 istanze di 1920 x 1080 a 60 fps - 20 Mbps).
  • [C-1-12] DEVE supportare HEVC e VP9, DEVE essere in grado di decodificare almeno 1920 x 1080 a 30 fps compresso a una media di 10 Mbps e DOVREBBE essere in grado di decodificare 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps-5 Mbps).
  • [C-1-13] DEVE supportare l'API HardwarePropertiesManager.getDeviceTemperatures e restituire valori accurati per la temperatura cutanea.
  • [C-1-14] DEVE avere uno schermo integrato e la sua risoluzione DEVE essere almeno 1920 x 1080.
  • [C-SR] Sono FORTEMENTE CONSIGLIATI per una risoluzione dello schermo di almeno 2560 x 1440.
  • [C-1-15] Il display DEVE aggiornarsi almeno a 60 Hz in modalità VR.
  • [C-1-17] Il display DEVE supportare una modalità a bassa persistenza con una persistenza ≤ 5 millisecondi, dove la persistenza è definita come il tempo per cui un pixel emette luce.
  • [C-1-18] DEVE supportare Bluetooth 4.2 e l'estensione della lunghezza dei dati Bluetooth LE sezione 7.4.3.
  • [C-1-19] DEVE supportare e segnalare correttamente il tipo di canale diretto per tutti i seguenti tipi di sensori predefiniti:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare il tipo di canale diretto TYPE_HARDWARE_BUFFER per tutti i tipi di canali diretti elencati sopra.
  • [C-1-21] DEVE soddisfare i requisiti relativi a giroscopio, accelerometro e magnetometro per android.hardware.hifi_sensors, come specificato nella sezione 7.3.9.
  • [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare la funzionalità android.hardware.sensor.hifi_sensors.
  • [C-1-22] DEVE avere una latenza end-to-end dal movimento al fotone non superiore a 28 millisecondi.
  • [C-SR] È VIVAMENTE CONSIGLIATO che la latenza end-to-end dal movimento al fotone non superi i 20 millisecondi.
  • [C-1-23] DEVE avere un rapporto del primo fotogramma, ovvero il rapporto tra la luminosità dei pixel del primo fotogramma dopo una transizione dal nero al bianco e la luminosità dei pixel bianchi in stato stazionario, di almeno l'85%.
  • [C-SR] È FORTEMENTE CONSIGLIATO che abbiano un rapporto tra il primo frame e il totale di almeno il 90%.
  • PUÒ fornire un core esclusivo all'applicazione in primo piano e PUÒ supportare l'API Process.getExclusiveCores per restituire il numero di core della CPU esclusivi per l'applicazione in primo piano principale.

Se il core esclusivo è supportato, il core:

  • [C-2-1] NON DEVE consentire l'esecuzione di altri processi dello spazio utente (ad eccezione dei driver del dispositivo utilizzati dall'applicazione), ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

8. Prestazioni e potenza

Alcuni criteri minimi di prestazioni e potenza sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di base che gli sviluppatori avrebbero durante lo sviluppo di un'app.

8.1. Coerenza dell'esperienza utente

È possibile fornire un'interfaccia utente fluida all'utente finale se sono presenti determinati requisiti minimi per garantire una frequenza dei fotogrammi e tempi di risposta coerenti per applicazioni e giochi. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POSSONO avere requisiti misurabili per la latenza dell'interfaccia utente e il cambio di attività, come descritto nella sezione 2.

8.2. Prestazioni di accesso I/O di file

Fornire una base di riferimento comune per prestazioni di accesso ai file coerenti nell'archivio privato dei dati dell'applicazione (partizione /data) consente agli sviluppatori di app di impostare un'aspettativa adeguata che aiuti la progettazione del software. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POSSONO avere determinati requisiti descritti nella sezione 2 per le seguenti operazioni di lettura e scrittura:

  • Prestazioni di scrittura sequenziale. Misurato scrivendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
  • Prestazioni di scrittura casuale. Misurato scrivendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.
  • Prestazioni di lettura sequenziale. Misurato leggendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
  • Rendimento di lettura casuale. Misurato leggendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.

8.3. Modalità di risparmio energetico

Se le implementazioni dei dispositivi includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP:

  • [C-1-1] NON DEVE discostarsi dall'implementazione AOSP per gli algoritmi di attivazione, manutenzione e riattivazione e per l'utilizzo delle impostazioni di sistema globali delle modalità di risparmio energetico App Standby e Doze.
  • [C-1-2] NON DEVE discostarsi dall'implementazione AOSP per l'utilizzo delle impostazioni globali per gestire la limitazione di job, sveglie e rete per le app in ogni bucket per la funzionalità App in standby.
  • [C-1-3] NON DEVE discostarsi dall'implementazione AOSP per il numero di bucket di standby delle app utilizzati per lo standby delle app.
  • [C-1-4] DEVE implementare App Standby Buckets e Doze come descritto in Power Management.
  • [C-1-5] DEVE restituire true per PowerManager.isPowerSaveMode() quando il dispositivo è in modalità di risparmio energetico.
  • [C-SR] Sono FORTEMENTE CONSIGLIATI per fornire all'utente la possibilità di attivare e disattivare la funzionalità di risparmio energetico.
  • [C-SR] È VIVAMENTE CONSIGLIATO di fornire agli utenti la possibilità di visualizzare tutte le app esentate dalle modalità di risparmio energetico App Standby e Doze.

Oltre alle modalità di risparmio energetico, le implementazioni dei dispositivi Android POSSONO implementare uno o tutti e quattro gli stati di alimentazione in sospensione definiti da Advanced Configuration and Power Interface (ACPI).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S4 come definiti da ACPI:

  • [C-1-1] DEVE entrare in questo stato solo dopo che l'utente ha intrapreso un'azione esplicita per mettere il dispositivo in uno stato inattivo (ad es. chiudendo un coperchio che fa parte fisicamente del dispositivo o spegnendo un veicolo o una televisione) e prima che l'utente riattivi il dispositivo (ad es. aprendo il coperchio o riaccendendo il veicolo o la televisione).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S3 come definiti da ACPI:

  • [C-2-1] DEVE soddisfare il requisito C-1-1 sopra indicato OPPURE DEVE entrare nello stato S3 solo quando le applicazioni di terze parti non necessitano delle risorse di sistema (ad es. schermo, CPU).

    Al contrario, DEVE uscire dallo stato S3 quando le applicazioni di terze parti hanno bisogno delle risorse di sistema, come descritto in questo SDK.

    Ad esempio, mentre le applicazioni di terze parti richiedono di mantenere lo schermo acceso tramite FLAG_KEEP_SCREEN_ON o di mantenere la CPU in esecuzione tramite PARTIAL_WAKE_LOCK, il dispositivo NON DEVE entrare nello stato S3 a meno che, come descritto in C-1-1, l'utente non abbia intrapreso un'azione esplicita per mettere il dispositivo in uno stato inattivo. Al contrario, quando viene attivata un'attività implementata da app di terze parti tramite JobScheduler o quando Firebase Cloud Messaging viene distribuito ad app di terze parti, il dispositivo DEVE uscire dallo stato S3, a meno che l'utente non lo abbia messo in stato di inattività. Questi non sono esempi esaustivi e AOSP implementa numerosi indicatori di riattivazione che attivano la riattivazione da questo stato.

8.4. Contabilizzazione del consumo energetico

Una contabilizzazione e un reporting più accurati del consumo energetico forniscono allo sviluppatore dell'app sia gli incentivi che gli strumenti per ottimizzare il modello di utilizzo dell'energia dell'applicazione.

Implementazioni del dispositivo:

  • [SR] È VIVAMENTE CONSIGLIATO fornire un profilo di alimentazione per componente che definisca il valore di consumo di corrente per ogni componente hardware e l'esaurimento approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto Android Open Source.
  • [SR] VIVAMENTE CONSIGLIATO di segnalare tutti i valori di consumo energetico in milliampere ora (mAh).
  • [SR] VIVAMENTE CONSIGLIATO di segnalare il consumo energetico della CPU per ogni UID del processo. L'Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
  • [SR] VIVAMENTE CONSIGLIATO di rendere disponibile questo consumo energetico tramite il comando shell adb shell dumpsys batterystats allo sviluppatore dell'app.
  • DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo energetico del componente hardware a un'applicazione.

8.5. Prestazioni costanti

Le prestazioni possono variare notevolmente per le app a esecuzione prolungata ad alte prestazioni, a causa delle altre app in esecuzione in background o della limitazione della CPU dovuta ai limiti di temperatura. Android include interfacce programmatiche in modo che, quando il dispositivo è in grado di farlo, l'applicazione in primo piano principale possa richiedere al sistema di ottimizzare l'allocazione delle risorse per gestire queste fluttuazioni.

Implementazioni del dispositivo:

Se le implementazioni dei dispositivi segnalano il supporto della modalità Prestazioni sostenute:

  • [C-1-1] DEVE fornire all'applicazione in primo piano principale un livello di prestazioni costante per almeno 30 minuti, quando l'app lo richiede.
  • [C-1-2] DEVE rispettare l'API Window.setSustainedPerformanceMode() e altre API correlate.

Se le implementazioni dei dispositivi includono due o più core della CPU:

  • DEVE fornire almeno un core esclusivo che può essere riservato dall'app in primo piano.

Se le implementazioni dei dispositivi supportano la prenotazione di un core esclusivo per l'applicazione in primo piano principale:

  • [C-2-1] DEVE segnalare tramite il metodo API Process.getExclusiveCores() i numeri ID dei core esclusivi che possono essere riservati dall'applicazione in primo piano principale.
  • [C-2-2] NON DEVE consentire l'esecuzione di processi nello spazio utente, ad eccezione dei driver del dispositivo utilizzati dall'applicazione, sui core esclusivi, ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

Se le implementazioni del dispositivo non supportano un core esclusivo:

9. Compatibilità del modello di sicurezza

Implementazioni del dispositivo:

  • [C-0-1] DEVE implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento su sicurezza e autorizzazioni nelle API nella documentazione per sviluppatori Android.

  • [C-0-2] DEVE supportare l'installazione di applicazioni autofirmate senza richiedere autorizzazioni/certificati aggiuntivi da terze parti/autorità. Nello specifico, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle seguenti sottosezioni.

9.1. Autorizzazioni

Implementazioni del dispositivo:

  • [C-0-1] DEVE supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android. Nello specifico, DEVONO applicare ogni autorizzazione definita come descritto nella documentazione dell'SDK; nessuna autorizzazione può essere omessa, modificata o ignorata.

  • POSSONO aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe ID autorizzazione non si trovino nello spazio dei nomi android.\*.

  • [C-0-2] Le autorizzazioni con un protectionLevel di PROTECTION_FLAG_PRIVILEGED DEVONO essere concesse solo alle app preinstallate nei percorsi privilegiati dell'immagine di sistema e nel sottoinsieme delle autorizzazioni esplicitamente consentite per ogni app. L'implementazione AOSP soddisfa questo requisito leggendo e rispettando le autorizzazioni consentite per ogni app dai file nel percorso etc/permissions/ e utilizzando il percorso system/priv-app come percorso privilegiato.

Le autorizzazioni con un livello di protezione pericoloso sono autorizzazioni di runtime. Le applicazioni con targetSdkVersion > 22 le richiedono al runtime.

Implementazioni del dispositivo:

  • [C-0-3] DEVE mostrare un'interfaccia dedicata in cui l'utente possa decidere se concedere le autorizzazioni di runtime richieste e fornire un'interfaccia per gestire le autorizzazioni di runtime.
  • [C-0-4] DEVE avere una e una sola implementazione di entrambe le interfacce utente.
  • [C-0-5] NON DEVE concedere autorizzazioni di runtime alle app preinstallate, a meno che:
    • Il consenso dell'utente può essere ottenuto prima che l'applicazione lo utilizzi.
    • Le autorizzazioni di runtime sono associate a un pattern di intent per il quale l'applicazione preinstallata è impostata come gestore predefinito.
  • [C-0-6] DEVE concedere l'autorizzazione android.permission.RECOVER_KEYSTORE solo alle app di sistema che registrano un agente di recupero adeguatamente protetto. Un agente di recupero protetto correttamente è definito come un agente software sul dispositivo che si sincronizza con uno spazio di archiviazione remoto esterno al dispositivo, dotato di hardware sicuro con protezione equivalente o superiore a quella descritta nel servizio Google Cloud Key Vault per impedire attacchi brute-force al fattore di conoscenza della schermata di blocco.

Implementazioni del dispositivo:

  • [C-0-7] DEVE rispettare le proprietà dell'autorizzazione di accesso alla posizione di Android quando un'app richiede i dati sulla posizione o sull'attività fisica tramite l'API Android standard o un meccanismo proprietario. Questi dati includono, a titolo esemplificativo:

    • Posizione del dispositivo (ad es. latitudine e longitudine).
    • Informazioni che possono essere utilizzate per determinare o stimare la posizione del dispositivo (ad es. SSID, BSSID, ID cella, scansioni Bluetooth o posizione della rete a cui è connesso il dispositivo).
    • Attività fisica dell'utente o classificazione dell'attività fisica.

Più nello specifico, le implementazioni dei dispositivi:

  • [C-0-8] DEVE ottenere il consenso dell'utente per consentire a un'app di accedere ai dati di posizione o di attività fisica.
  • [C-0-9] DEVE concedere un'autorizzazione di runtime SOLO all'app che dispone di un'autorizzazione sufficiente come descritto nell'SDK. Ad esempio, TelephonyManager#getServiceState richiede android.permission.ACCESS_FINE_LOCATION).

Le autorizzazioni possono essere contrassegnate come limitate, modificandone il comportamento.

  • [C-0-10] Le autorizzazioni contrassegnate dal flag hardRestricted NON DEVONO essere concesse a un'app, a meno che:

    • Un file APK dell'app si trova nella partizione di sistema.
    • L'utente assegna a un'app un ruolo associato alle autorizzazioni hardRestricted.
    • Il programma di installazione concede hardRestricted a un'app.
    • A un'app viene concesso hardRestricted in una versione precedente di Android.

  • [C-0-11] Le app che dispongono di un'autorizzazione softRestricted DEVONO ottenere solo un accesso limitato e NON DEVONO ottenere l'accesso completo finché non vengono aggiunte a una lista consentita come descritto nell'SDK, in cui l'accesso completo e limitato è definito per ogni autorizzazione softRestricted (ad esempio, WRITE_EXTERNAL_STORAGE e READ_EXTERNAL_STORAGE).

Se le implementazioni dei dispositivi includono un'app preinstallata o vogliono consentire alle app di terze parti di accedere alle statistiche di utilizzo:

  • [SR] è FORTEMENTE CONSIGLIATO fornire un meccanismo accessibile agli utenti per concedere o revocare l'accesso alle statistiche sull'utilizzo in risposta all'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS per le app che dichiarano l'autorizzazione android.permission.PACKAGE_USAGE_STATS.

Se le implementazioni dei dispositivi intendono impedire a qualsiasi app, incluse quelle preinstallate, di accedere alle statistiche di utilizzo:

  • [C-1-1] DEVE comunque avere un'attività che gestisce il pattern di intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, ma DEVE implementarlo come no-op, ovvero avere un comportamento equivalente a quando l'accesso all'utente viene negato.

9.2. UID e isolamento dei processi

Implementazioni del dispositivo:

  • [C-0-1] DEVE supportare il modello di sandbox delle applicazioni Android, in cui ogni applicazione viene eseguita come UID in stile Unix univoco e in un processo separato.
  • [C-0-2] DEVE supportare l'esecuzione di più applicazioni con lo stesso ID utente Linux, a condizione che le applicazioni siano firmate e create correttamente, come definito nel riferimento a sicurezza e autorizzazioni.

9.3. Autorizzazioni del file system

Implementazioni del dispositivo:

9.4. Ambienti di esecuzione alternativi

Le implementazioni dei dispositivi DEVONO mantenere la coerenza del modello di sicurezza e autorizzazioni di Android, anche se includono ambienti di runtime che eseguono applicazioni utilizzando software o tecnologie diversi dal formato eseguibile Dalvik o dal codice nativo. In altre parole:

  • [C-0-1] Gli ambienti di runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella sezione 9.

  • [C-0-2] Non DEVE essere concesso l'accesso a runtime alternativi alle risorse protette da autorizzazioni non richieste nel file AndroidManifest.xml del runtime tramite il meccanismo <uses-permission>.

  • [C-0-3] I runtime alternativi NON DEVONO consentire alle applicazioni di utilizzare funzionalità protette da autorizzazioni Android limitate alle applicazioni di sistema.

  • [C-0-4] I runtime alternativi DEVONO rispettare il modello di sandbox di Android e le applicazioni installate che utilizzano un runtime alternativo NON DEVONO riutilizzare la sandbox di altre app installate sul dispositivo, se non tramite i meccanismi standard di Android di ID utente condiviso e certificato di firma.

  • [C-0-5] Gli ambienti di runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso ai sandbox corrispondenti ad altre applicazioni per Android.

  • [C-0-6] I runtime alternativi NON DEVONO essere avviati con, ricevere o concedere ad altre applicazioni privilegi di superutente (root) o di qualsiasi altro ID utente.

  • [C-0-7] Quando i file .apk di runtime alternativi sono inclusi nell'immagine di sistema delle implementazioni del dispositivo, DEVONO essere firmati con una chiave diversa da quella utilizzata per firmare altre applicazioni incluse nelle implementazioni del dispositivo.

  • [C-0-8] Durante l'installazione delle applicazioni, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione.

  • [C-0-9] Quando un'applicazione deve utilizzare una risorsa del dispositivo per la quale esiste un'autorizzazione Android corrispondente (ad esempio fotocamera, GPS e così via), l'ambiente di runtime alternativo DEVE informare l'utente che l'applicazione potrà accedere a quella risorsa.

  • [C-0-10] Quando l'ambiente di runtime non registra le funzionalità dell'applicazione in questo modo, DEVE elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che utilizza quel runtime.

  • I runtime alternativi DEVONO installare le app tramite PackageManager in sandbox Android separate (ID utente Linux e così via).

  • Runtime alternativi POSSONO fornire una singola sandbox Android condivisa da tutte le applicazioni che utilizzano il runtime alternativo.

9.5. Supporto multiutente

Android include il supporto multiutente e fornisce il supporto per l'isolamento completo degli utenti.

  • Le implementazioni dei dispositivi POSSONO, ma NON DEVONO, attivare il multiutente se utilizzano supporti rimovibili per l'archiviazione esterna principale.

Se le implementazioni dei dispositivi includono più utenti:

  • [C-1-1] DEVE soddisfare i seguenti requisiti relativi al supporto multiutente.
  • [C-1-2] DEVE implementare, per ogni utente, un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento su sicurezza e autorizzazioni nelle API.
  • [C-1-3] DEVE avere directory di archiviazione delle applicazioni condivise separate e isolate (ovvero /sdcard) per ogni istanza utente.
  • [C-1-4] DEVE garantire che le applicazioni di proprietà di un determinato utente e in esecuzione per suo conto non possano elencare, leggere o scrivere nei file di proprietà di qualsiasi altro utente, anche se i dati di entrambi gli utenti sono archiviati nello stesso volume o file system.
  • [C-1-5] DEVE criptare i contenuti della scheda SD quando è abilitato l'utilizzo multiutente utilizzando una chiave memorizzata solo su supporti non rimovibili accessibili solo al sistema se le implementazioni del dispositivo utilizzano supporti rimovibili per le API di archiviazione esterna. Poiché in questo modo i contenuti multimediali non saranno leggibili da un PC host, le implementazioni dei dispositivi dovranno passare a MTP o a un sistema simile per fornire ai PC host l'accesso ai dati dell'utente corrente.

9.6. Avviso SMS premium

Android include il supporto per avvisare gli utenti di eventuali messaggi SMS premium in uscita. Gli SMS premium sono messaggi di testo inviati a un servizio registrato presso un operatore che potrebbe comportare un addebito per l'utente.

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.telephony:

  • [C-1-1] DEVE avvisare gli utenti prima di inviare un messaggio SMS a numeri identificati da espressioni regolari definite nel file /data/misc/sms/codes.xml del dispositivo. Il progetto Android Open Source upstream fornisce un'implementazione che soddisfa questo requisito.

9.7. Funzionalità per la sicurezza

Le implementazioni dei dispositivi DEVONO garantire la conformità alle funzionalità di sicurezza sia nel kernel sia nella piattaforma, come descritto di seguito.

La sandbox Android include funzionalità che utilizzano il sistema di controllo dell'accesso obbligatorio (MAC) Security-Enhanced Linux (SELinux), il sandboxing seccomp e altre funzionalità di sicurezza nel kernel Linux. Implementazioni del dispositivo:

  • [C-0-1] DEVE mantenere la compatibilità con le applicazioni esistenti, anche quando SELinux o altre funzionalità di sicurezza sono implementate al di sotto del framework Android.
  • [C-0-2] NON DEVE avere un'interfaccia utente visibile quando viene rilevata e bloccata correttamente una violazione della sicurezza dalla funzionalità di sicurezza implementata sotto il framework Android, ma PUÒ avere un'interfaccia utente visibile quando si verifica una violazione della sicurezza non bloccata che comporta un exploit riuscito.
  • [C-0-3] NON DEVE rendere configurabili per l'utente o lo sviluppatore di app SELinux o qualsiasi altra funzionalità di sicurezza implementata al di sotto del framework Android.
  • [C-0-4] NON DEVE consentire a un'applicazione che può influire su un'altra applicazione tramite un'API (ad esempio un'API di amministrazione del dispositivo) di configurare un criterio che interrompe la compatibilità.
  • [C-0-5] DEVE dividere il framework multimediale in più processi in modo da poter concedere l'accesso in modo più specifico per ogni processo, come descritto nel sito Android Open Source Project.
  • [C-0-6] DEVE implementare un meccanismo di sandboxing delle applicazioni del kernel che consenta il filtraggio delle chiamate di sistema utilizzando un criterio configurabile da programmi multithread. L'Android Open Source Project upstream soddisfa questo requisito attivando seccomp-BPF con la sincronizzazione dei gruppi di thread (TSYNC), come descritto nella sezione Configurazione del kernel di source.android.com.

Le funzionalità di integrità e autoprotezione del kernel sono parte integrante della sicurezza di Android. Implementazioni del dispositivo:

  • [C-0-7] DEVE implementare meccanismi di protezione dal buffer overflow dello stack del kernel. Esempi di questi meccanismi sono CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
  • [C-0-8] DEVE implementare protezioni rigorose della memoria del kernel in cui il codice eseguibile è di sola lettura, i dati di sola lettura non sono eseguibili e non sono scrivibili e i dati scrivibili non sono eseguibili (ad es. CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] DEVE implementare il controllo dei limiti delle dimensioni degli oggetti statici e dinamici delle copie tra lo spazio utente e lo spazio kernel (ad es. CONFIG_HARDENED_USERCOPY) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
  • [C-0-10] NON DEVE eseguire la memoria dello spazio utente durante l'esecuzione in modalità kernel (ad es. PXN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
  • [C-0-11] NON DEVE leggere o scrivere nella memoria dello spazio utente nel kernel al di fuori delle normali API di accesso usercopy (ad es. PAN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
  • [C-0-12] DEVE implementare l'isolamento della tabella delle pagine del kernel se l'hardware è vulnerabile a CVE-2017-5754 su tutti i dispositivi originariamente forniti con il livello API 28 o versioni successive (ad es. CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0).
  • [C-0-13] DEVE implementare la protezione della predizione dei rami se l'hardware è vulnerabile a CVE-2017-5715 su tutti i dispositivi originariamente forniti con il livello API 28 o versioni successive (ad es. CONFIG_HARDEN_BRANCH_PREDICTOR).
  • [SR] VIVAMENTE CONSIGLIATO di mantenere i dati del kernel scritti solo durante l'inizializzazione contrassegnati come di sola lettura dopo l'inizializzazione (ad es. __ro_after_init).

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

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

  • [C-SR] È FORTEMENTE CONSIGLIATO di non disattivare Control-Flow Integrity (CFI), Shadow Call Stack (SCS) o Integer Overflow Sanitization (IntSan) sui componenti su cui è attivato.
  • [C-SR] È VIVAMENTE CONSIGLIATO di attivare CFI, SCS e IntSan per eventuali componenti userspace aggiuntivi sensibili alla sicurezza, come spiegato in CFI e IntSan.

Se le implementazioni dei dispositivi utilizzano un kernel Linux:

  • [C-1-1] DEVE implementare SELinux.
  • [C-1-2] DEVE impostare SELinux sulla modalità di applicazione globale.
  • [C-1-3] DEVE configurare tutti i domini in modalità di applicazione. Non sono consentiti domini in modalità permissiva, inclusi i domini specifici di un dispositivo/fornitore.
  • [C-1-4] NON DEVE modificare, omettere o sostituire le regole neverallow presenti nella cartella system/sepolicy fornita nel progetto Android Open Source Project (AOSP) upstream e il criterio DEVE essere compilato con tutte le regole neverallow presenti, sia per i domini SELinux AOSP sia per i domini specifici del dispositivo/fornitore.
  • [C-1-5] DEVONO eseguire applicazioni di terze parti che hanno come target il livello API 28 o superiore in sandbox SELinux per applicazione con limitazioni SELinux per app nella directory dei dati privati di ogni applicazione.
  • DEVE conservare il criterio SELinux predefinito fornito nella cartella system/sepolicy del progetto Android Open Source e aggiungere solo ulteriori elementi a questo criterio per la propria configurazione specifica del dispositivo.

Se le implementazioni dei dispositivi sono già state lanciate su una versione precedente di Android e non soddisfano i requisiti [C-1-1] e [C-1-5] tramite un aggiornamento del software di sistema, POSSONO essere esentate da questi requisiti.

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

  • [C-2-1] DEVE utilizzare un sistema di controllo dell'accesso obbligatorio equivalente a SELinux.

Android include diverse funzionalità di difesa in profondità che sono parte integrante della sicurezza del dispositivo.

9.8. Privacy

9.8.1. Cronologia di utilizzo

Android memorizza la cronologia delle scelte dell'utente e la gestisce tramite UsageStatsManager.

Implementazioni del dispositivo:

  • [C-0-1] DEVE mantenere un periodo di conservazione ragionevole di questa cronologia utente.
  • [SR] È VIVAMENTE CONSIGLIATO di mantenere il periodo di conservazione di 14 giorni configurato per impostazione predefinita nell'implementazione AOSP.

Android archivia gli eventi di sistema utilizzando gli identificatori StatsLog e gestisce la cronologia tramite l'API di sistema StatsManager e IncidentManager.

Implementazioni del dispositivo:

  • [C-0-2] DEVE includere solo i campi contrassegnati con DEST_AUTOMATIC nel report sull'incidente creato dalla classe API di sistema IncidentManager.
  • [C-0-3] NON DEVE utilizzare gli identificatori di eventi di sistema per registrare eventi diversi da quelli descritti nei documenti dell'SDK StatsLog. Se vengono registrati eventi di sistema aggiuntivi, questi POTREBBERO utilizzare un identificatore atomo diverso nell'intervallo compreso tra 100.000 e 200.000.

9.8.2. Registrazione in corso…

Implementazioni del dispositivo:

  • [C-0-1] NON DEVE precaricare o distribuire componenti software pronti all'uso che inviano informazioni private dell'utente (ad es. sequenze di tasti, testo visualizzato sullo schermo, report di bug) dal dispositivo senza il consenso dell'utente o notifiche chiare e continue.

  • [C-0-2] DEVE mostrare e ottenere il consenso esplicito dell'utente che includa sostanzialmente lo stesso messaggio di AOSP ogni volta che la trasmissione o la registrazione dello schermo è attivata tramite MediaProjection o API proprietarie. NON DEVE fornire agli utenti la possibilità di disattivare la visualizzazione futura del consenso dell'utente.

  • [C-0-3] DEVE mostrare una notifica continua all'utente mentre la trasmissione o la registrazione dello schermo è attiva. AOSP soddisfa questo requisito mostrando un'icona di notifica in corso nella barra di stato.

Se le implementazioni del dispositivo includono funzionalità nel sistema che acquisiscono i contenuti visualizzati sullo schermo e/o registrano il flusso audio riprodotto sul dispositivo in modo diverso dall'API di sistema ContentCaptureService o con altri mezzi proprietari descritti nella Sezione 9.8.6 Acquisizione dei contenuti, queste:

  • [C-1-1] DEVE mostrare una notifica continua all'utente ogni volta che questa funzionalità è attiva e sta acquisendo/registrando.

Se le implementazioni del dispositivo includono un componente abilitato out-of-box, in grado di registrare l'audio ambientale e/o registrare l'audio riprodotto sul dispositivo per dedurre informazioni utili sul contesto dell'utente,

  • [C-2-1] NON DEVE memorizzare in modo permanente nella memoria del dispositivo o trasmettere al di fuori del dispositivo l'audio grezzo registrato o qualsiasi formato che possa essere riconvertito nell'audio originale o in una copia quasi esatta, se non con il consenso esplicito dell'utente.

9.8.3. Connettività

Se le implementazioni dei dispositivi hanno una porta USB con supporto della modalità periferica USB:

  • [C-1-1] DEVE presentare un'interfaccia utente che chieda il consenso dell'utente prima di consentire l'accesso ai contenuti dello spazio di archiviazione condiviso tramite la porta USB.

9.8.4. Traffico di rete

Implementazioni del dispositivo:

  • [C-0-1] DEVE preinstallare gli stessi certificati radice per l'archivio delle autorità di certificazione (CA) attendibili dal sistema come fornito nel progetto open source Android upstream.
  • [C-0-2] MUST ship with an empty user root CA store.
  • [C-0-3] DEVE mostrare un avviso all'utente che indica che il traffico di rete potrebbe essere monitorato quando viene aggiunta una CA radice utente.

Se il traffico del dispositivo viene indirizzato tramite una VPN, le implementazioni del dispositivo:

  • [C-1-1] DEVE mostrare all'utente un avviso che indica:
    • Il traffico di rete potrebbe essere monitorato.
    • Il traffico di rete viene instradato tramite l'applicazione VPN specifica che fornisce la VPN.

Se le implementazioni dei dispositivi hanno un meccanismo, attivato per impostazione predefinita, che indirizza il traffico di dati di rete tramite un server proxy o un gateway VPN (ad esempio, il precaricamento di un servizio VPN con android.permission.CONTROL_VPN concesso), allora:

  • [C-2-1] DEVE chiedere il consenso dell'utente prima di attivare questo meccanismo, a meno che la VPN non sia attivata dal controller delle norme relative ai dispositivi tramite DevicePolicyManager.setAlwaysOnVpnPackage() , nel qual caso l'utente non deve fornire un consenso separato, ma DEVE solo ricevere una notifica.

Se le implementazioni del dispositivo implementano una funzionalità utente per attivare/disattivare la funzione "VPN sempre attiva" di un'app VPN di terze parti:

  • [C-3-1] DEVE disattivare questa funzionalità per le app che non supportano il servizio VPN sempre attiva nel file AndroidManifest.xml impostando l'attributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON su false.

9.8.5. Identificatori dei dispositivi

Implementazioni del dispositivo:

  • [C-0-1] DEVE impedire l'accesso al numero di serie del dispositivo e, se applicabile, all'IMEI/MEID, al numero di serie della SIM e all'International Mobile Subscriber Identity (IMSI) da un'app, a meno che non soddisfi uno dei seguenti requisiti:
    • è un'app operatore firmata e verificata dai produttori di dispositivi.
    • è stata concessa l'autorizzazione READ_PRIVILEGED_PHONE_STATE.
    • dispone dei privilegi dell'operatore definiti in UICC Carrier Privileges.
    • è un proprietario del dispositivo o del profilo a cui è stata concessa l'autorizzazione READ_PHONE_STATE.
    • (Solo per il numero di serie della SIM/ICCID) ha il requisito delle normative locali che l'app rilevi le modifiche all'identità dell'abbonato.

9.8.6. Acquisizione dei contenuti

Android, tramite l'API di sistema ContentCaptureService o con altri mezzi proprietari, supporta un meccanismo per le implementazioni dei dispositivi per acquisire le seguenti interazioni tra le applicazioni e l'utente.

  • Testo e grafica visualizzati sullo schermo, inclusi, a titolo esemplificativo, notifiche e dati di assistenza tramite l'API AssistStructure.
  • Dati multimediali, come audio o video, registrati o riprodotti dal dispositivo.
  • Eventi di input (ad es. tasti, mouse, gesti, voce, video e accessibilità).
  • Qualsiasi altro evento fornito da un'applicazione al sistema tramite l'API Content Capture o un'API proprietaria con funzionalità simili.

Se le implementazioni dei dispositivi acquisiscono i dati sopra indicati:

  • [C-1-1] DEVE criptare tutti questi dati quando vengono memorizzati nel dispositivo. Questa crittografia PUÒ essere eseguita utilizzando la crittografia basata su file di Android o uno qualsiasi dei cifrari elencati come versione API 26+ descritti in Cipher SDK.
  • [C-1-2] NON DEVE eseguire il backup di dati non elaborati o criptati utilizzando i metodi di backup di Android o altri metodi di backup.
  • [C-1-3] DEVE inviare tutti questi dati e il log del dispositivo solo utilizzando un meccanismo che tutela la privacy. Il meccanismo che tutela la privacy è definito come "quello che consente solo l'analisi aggregata e impedisce la corrispondenza degli eventi registrati o dei risultati derivati con i singoli utenti", per impedire che i dati per utente siano ispezionabili (ad es. implementati utilizzando una tecnologia di privacy differenziale come RAPPOR).
  • [C-1-4] NON DEVE associare questi dati a un'identità utente (ad esempio Account) sul dispositivo, tranne con il consenso esplicito dell'utente ogni volta che i dati vengono associati.
  • [C-1-5] NON DEVE condividere questi dati con altre app, se non con il consenso esplicito dell'utente ogni volta che vengono condivisi.
  • [C-1-6] DEVE fornire all'utente la possibilità di cancellare i dati raccolti dal ContentCaptureService o dai mezzi proprietari se i dati sono memorizzati in qualsiasi forma sul dispositivo.

Se le implementazioni dei dispositivi includono un servizio che implementa l'API di sistema ContentCaptureService o qualsiasi servizio proprietario che acquisisce i dati come descritto sopra:

  • [C-2-1] NON DEVE consentire agli utenti di sostituire il servizio di acquisizione dei contenuti con un'applicazione o un servizio installabile dall'utente e DEVE consentire solo al servizio preinstallato di acquisire tali dati.
  • [C-2-2] NON DEVE consentire ad app diverse dal meccanismo di servizio di acquisizione dei contenuti preinstallato di acquisire tali dati.
  • [C-2-3] DEVE fornire all'utente la possibilità di disattivare il servizio di acquisizione dei contenuti.
  • [C-2-4] NON DEVE omettere la possibilità per l'utente di gestire le autorizzazioni Android detenute dal servizio di acquisizione dei contenuti e seguire il modello di autorizzazioni Android descritto nella Sezione 9.1. Autorizzazione.

  • [C-SR] È FORTEMENTE CONSIGLIATO mantenere separati i componenti del servizio di acquisizione dei contenuti, ad esempio non collegare il servizio o condividere gli ID processo, da altri componenti del sistema, ad eccezione di:

    • Telefonia, Contatti, UI di sistema e contenuti multimediali

9.8.7. Accesso agli appunti

Implementazioni del dispositivo:

  • [C-0-1] NON DEVE restituire dati troncati negli appunti (ad es. tramite l'API ClipboardManager) a meno che l'app non sia l'IME predefinito o l'app attualmente selezionata.

9.8.8. Posizione

Implementazioni del dispositivo:

  • [C-0-1] NON DEVE attivare/disattivare l'impostazione di geolocalizzazione del dispositivo e le impostazioni di scansione Wi-Fi/Bluetooth senza il consenso esplicito dell'utente o l'avvio da parte dell'utente.
  • [C-0-2] DEVE fornire all'utente la possibilità di accedere alle informazioni relative alla posizione, incluse le richieste di posizione recenti, le autorizzazioni a livello di app e l'utilizzo della scansione Wi-Fi/Bluetooth per determinare la posizione.
  • [C-0-3] DEVE garantire che l'applicazione che utilizza l'API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] sia una sessione di emergenza avviata dall'utente (ad es. chiamata al 911 o invio di un messaggio al 911).
  • [C-0-4] DEVE preservare la capacità dell'API Emergency Location Bypass di bypassare le impostazioni di localizzazione del dispositivo senza modificarle.
  • [C-0-5] DEVE pianificare una notifica che ricordi all'utente che un'app in background ha avuto accesso alla sua posizione utilizzando l'autorizzazione [ACCESS_BACKGROUND_LOCATION].

9.9. Crittografia dell'archiviazione dei dati

Tutti i dispositivi DEVONO soddisfare i requisiti della sezione 9.9.1. I dispositivi lanciati con un livello API precedente a quello di questo documento sono esenti dai requisiti delle sezioni 9.9.2 e 9.9.3; devono invece soddisfare i requisiti della sezione 9.9 del documento Android Compatibility Definition corrispondente al livello API con cui è stato lanciato il dispositivo.

9.9.1. Avvio diretto

Implementazioni del dispositivo:

  • [C-0-1] DEVE implementare le API della modalità Avvio diretto anche se non supportano la crittografia dell'archiviazione.

  • [C-0-2] Gli intent ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED DEVONO comunque essere trasmessi per segnalare alle applicazioni compatibili con l'avvio diretto che le posizioni di archiviazione con crittografia del dispositivo (DE) e crittografia delle credenziali (CE) sono disponibili per l'utente.

9.9.2. Requisiti di crittografia

Implementazioni del dispositivo:

  • [C-0-1] DEVE criptare i dati privati dell'applicazione (partizione /data), nonché la partizione di archiviazione condivisa dell'applicazione (partizione /sdcard) se è una parte permanente e non rimovibile del dispositivo.
  • [C-0-2] DEVE abilitare la crittografia dell'archiviazione dei dati per impostazione predefinita al momento del completamento della configurazione iniziale da parte dell'utente.
  • [C-0-3] DEVE soddisfare il requisito di crittografia dell'archiviazione dei dati sopra indicato implementando la crittografia basata su file (FBE).

9.9.3. Crittografia basata su file

Dispositivi criptati:

  • [C-1-1] DEVE avviarsi senza richiedere le credenziali all'utente e consentire alle app compatibili con l'avvio diretto di accedere allo spazio di archiviazione con crittografia del dispositivo (DE) dopo la trasmissione del messaggio ACTION_LOCKED_BOOT_COMPLETED.
  • [C-1-2] DEVE consentire l'accesso allo spazio di archiviazione con crittografia delle credenziali (CE) solo dopo che l'utente ha sbloccato il dispositivo fornendo le proprie credenziali (ad es. passcode, PIN, sequenza o impronta) e viene trasmesso il messaggio ACTION_USER_UNLOCKED.
  • [C-1-3] NON DEVE offrire alcun metodo per sbloccare lo spazio di archiviazione protetto da CE senza le credenziali fornite dall'utente o una chiave di deposito registrata.
  • [C-1-4] DEVE utilizzare l'avvio verificato e assicurarsi che le chiavi DE siano legate crittograficamente alla radice di attendibilità hardware del dispositivo.
  • [C-1-5] DEVE criptare i contenuti dei file utilizzando AES-256-XTS o Adiantum. AES-256-XTS si riferisce all'Advanced Encryption Standard con una lunghezza della chiave di cifratura di 256 bit, utilizzato in modalità XTS; la lunghezza completa della chiave è di 512 bit. Adiantum si riferisce ad Adiantum-XChaCha12-AES, come specificato all'indirizzo https://github.com/google/adiantum.
  • [C-1-6] I nomi dei file DEVONO essere criptati utilizzando AES-256-CBC-CTS o Adiantum.

  • [C-1-12] DEVE utilizzare AES-256-XTS per i contenuti dei file e AES-256-CBC-CTS per i nomi dei file (anziché Adiantum) se il dispositivo dispone di istruzioni Advanced Encryption Standard (AES). Le istruzioni AES sono le estensioni di crittografia ARMv8 sui dispositivi basati su ARM o AES-NI sui dispositivi basati su x86. Se il dispositivo non dispone di istruzioni AES, POTREBBE utilizzare Adiantum.

  • Le chiavi che proteggono le aree di archiviazione CE e DE:

  • [C-1-7] DEVE essere associato in modo crittografico a un keystore basato su hardware.

  • [C-1-8] Le chiavi CE DEVONO essere associate alle credenziali della schermata di blocco di un utente.
  • [C-1-9] Le chiavi CE DEVONO essere associate a un passcode predefinito quando l'utente non ha specificato le credenziali della schermata di blocco.
  • [C-1-10] DEVE essere univoca e distinta, in altre parole la chiave CE o DE di un utente non corrisponde a quella di un altro utente.
  • [C-1-11] DEVE utilizzare le cifrature, le lunghezze delle chiavi e le modalità supportate obbligatoriamente.

  • [C-SR] È VIVAMENTE CONSIGLIATO criptare i metadati del file system, come dimensioni, proprietà, modalità e attributi estesi (xattr), con una chiave crittograficamente associata alla radice di attendibilità hardware del dispositivo.

  • DEVONO rendere le app essenziali preinstallate (ad es. Sveglia, Telefono, Messenger) compatibili con l'avvio diretto.

Il progetto Android Open Source upstream fornisce un'implementazione preferita di questa funzionalità basata sulla funzionalità di crittografia "fscrypt" del kernel Linux.

9.10. Integrità del dispositivo

I seguenti requisiti garantiscono la trasparenza dello stato dell'integrità del dispositivo. Implementazioni del dispositivo:

  • [C-0-1] DEVE segnalare correttamente tramite il metodo dell'API di sistema PersistentDataBlockManager.getFlashLockState() se lo stato del bootloader consente il flashing dell'immagine di sistema. Lo stato FLASH_LOCK_UNKNOWN è riservato alle implementazioni dei dispositivi che eseguono l'upgrade da una versione precedente di Android in cui questo nuovo metodo API di sistema non esisteva.

  • [C-0-2] DEVE supportare l'Avvio verificato per l'integrità del dispositivo.

Se le implementazioni dei dispositivi sono già state lanciate senza supportare l'Avvio verificato su una versione precedente di Android e non è possibile aggiungere il supporto per questa funzionalità con un aggiornamento del software di sistema, POTREBBERO essere esentate dal requisito.

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

  • [C-1-1] DEVE dichiarare il flag funzionalità della piattaforma android.software.verified_boot.
  • [C-1-2] DEVE eseguire la verifica a ogni sequenza di avvio.
  • [C-1-3] DEVE avviare la verifica da una chiave hardware immutabile che è la radice di attendibilità e arrivare fino alla partizione di sistema.
  • [C-1-4] DEVE implementare ogni fase di verifica per controllare l'integrità e l'autenticità di tutti i byte nella fase successiva prima di eseguire il codice nella fase successiva.
  • [C-1-5] DEVE utilizzare algoritmi di verifica efficaci quanto le attuali raccomandazioni del NIST per gli algoritmi di hashing (SHA-256) e le dimensioni delle chiavi pubbliche (RSA-2048).
  • [C-1-6] NON DEVE consentire il completamento dell'avvio quando la verifica del sistema non va a buon fine, a meno che l'utente non acconsenta a tentare comunque l'avvio, nel qual caso i dati di eventuali blocchi di archiviazione non verificati NON DEVONO essere utilizzati.
  • [C-1-7] NON DEVE consentire la modifica delle partizioni verificate sul dispositivo, a meno che l'utente non abbia sbloccato esplicitamente il bootloader.
  • [C-SR] Se nel dispositivo sono presenti più chip discreti (ad es. radio, processore di immagini specializzato), è VIVAMENTE CONSIGLIATO verificare ogni fase del processo di avvio di ciascun chip.
  • [C-1-8] DEVE utilizzare l'archiviazione antimanomissione: per memorizzare se il bootloader è sbloccato. L'archiviazione a prova di manomissione indica che il bootloader può rilevare se l'archiviazione è stata manomessa dall'interno di Android.
  • [C-1-9] DEVE richiedere all'utente, durante l'utilizzo del dispositivo, una conferma fisica prima di consentire il passaggio dalla modalità bootloader bloccato alla modalità bootloader sbloccato.
  • [C-1-10] DEVE implementare la protezione dal rollback per le partizioni utilizzate da Android (ad es. partizioni di avvio e di sistema) e utilizzare l'archiviazione antimanomissione per memorizzare i metadati utilizzati per determinare la versione minima consentita del sistema operativo.
  • [C-SR] È VIVAMENTE CONSIGLIATO verificare tutti i file APK delle app con privilegi con una catena di attendibilità basata su partizioni protette da Avvio verificato.
  • [C-SR] È FORTEMENTE CONSIGLIATO verificare gli artefatti eseguibili caricati da un'app con privilegi al di fuori del file APK (ad esempio codice caricato dinamicamente o codice compilato) prima di eseguirli o FORTEMENTE CONSIGLIATO di non eseguirli affatto.
  • DEVE implementare la protezione dal rollback per qualsiasi componente con firmware persistente (ad es. modem, fotocamera) e DEVE utilizzare un archivio a prova di manomissione per archiviare i metadati utilizzati per determinare la versione minima consentita.

Se le implementazioni dei dispositivi sono già state lanciate senza supportare C-1-8 fino a C-1-10 su una versione precedente di Android e non è possibile aggiungere il supporto per questi requisiti con un aggiornamento del software di sistema, POTREBBERO essere esentate dai requisiti.

Il progetto Android Open Source a monte fornisce un'implementazione preferita di questa funzionalità nel repository external/avb/, che può essere integrata nel bootloader utilizzato per caricare Android.

Implementazioni del dispositivo:

Se le implementazioni dei dispositivi supportano l'API Android Protected Confirmation:

  • [C-3-1] DEVE segnalare true per l'API ConfirmationPrompt.isSupported().

  • [C-3-2] DEVE garantire che il codice in esecuzione nel sistema operativo Android, incluso il kernel, dannoso o meno, non possa generare una risposta positiva senza l'interazione dell'utente.

  • [C-3-3] DEVE garantire che l'utente abbia potuto esaminare e approvare il messaggio richiesto anche nel caso in cui il sistema operativo Android, incluso il suo kernel, sia compromesso.

9.11. Chiavi e credenziali

Il sistema Android Keystore consente agli sviluppatori di app di archiviare le chiavi di crittografia in un contenitore e di utilizzarle nelle operazioni di crittografia tramite l'API KeyChain o l'API Keystore. Implementazioni del dispositivo:

  • [C-0-1] DEVE consentire l'importazione o la generazione di almeno 8192 chiavi.
  • [C-0-2] L'autenticazione della schermata di blocco DEVE limitare la frequenza dei tentativi e DEVE avere un algoritmo di backoff esponenziale. Oltre 150 tentativi non riusciti, il ritardo DEVE essere di almeno 24 ore per tentativo.
  • Non deve limitare il numero di chiavi che possono essere generate

Quando l'implementazione del dispositivo supporta una schermata di blocco sicura:

  • [C-1-1] DEVE eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
  • [C-1-2] DEVE avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e delle funzioni hash MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto Android Open Source Project (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti di un isolamento basato su un hypervisor appropriato sono opzioni alternative.
  • [C-1-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e solo se riuscita, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto Android Open Source Project upstream fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
  • [C-1-4] DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori di dispositivi. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, per ogni 100.000 unità potrebbe essere utilizzata una chiave diversa.

Tieni presente che se l'implementazione di un dispositivo è già stata lanciata su una versione precedente di Android, il dispositivo è esente dal requisito di disporre di un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione della chiave, a meno che non dichiari la funzionalità android.hardware.fingerprint, che richiede un keystore supportato da un ambiente di esecuzione isolato.

  • [C-1-5] DEVE consentire all'utente di scegliere il timeout di sospensione per la transizione dallo stato sbloccato a quello bloccato, con un timeout minimo consentito fino a 15 secondi.

9.11.1. Schermata di blocco sicura e autenticazione

L'implementazione di AOSP segue un modello di autenticazione a più livelli in cui l'autenticazione primaria basata su un fattore di conoscenza può essere supportata da una biometria secondaria efficace o da modalità terziarie più deboli.

Implementazioni del dispositivo:

  • [C-SR] È VIVAMENTE CONSIGLIATO di impostare solo uno dei seguenti metodi come metodo di autenticazione principale:
    • Un PIN numerico
    • Una password alfanumerica
    • Un pattern di scorrimento su una griglia di esattamente 3x3 punti

Tieni presente che i metodi di autenticazione sopra indicati sono indicati in questo documento come metodi di autenticazione principali consigliati.

Se le implementazioni dei dispositivi aggiungono o modificano i metodi di autenticazione principali consigliati e utilizzano un nuovo metodo di autenticazione come modo sicuro per bloccare lo schermo, il nuovo metodo di autenticazione:

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco se basati su un segreto noto e utilizzano un nuovo metodo di autenticazione da trattare come un modo sicuro per bloccare lo schermo:

  • [C-3-1] L'entropia della lunghezza minima consentita degli input DEVE essere maggiore di 10 bit.
  • [C-3-2] L'entropia massima di tutti gli input possibili DEVE essere maggiore di 18 bit.
  • [C-3-3] Il nuovo metodo di autenticazione NON DEVE sostituire nessuno dei metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) implementati e forniti in AOSP.
  • [C-3-4] Il nuovo metodo di autenticazione DEVE essere disattivato quando l'applicazione DPC (controller criteri dispositivi) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_SOMETHING.
  • [C-3-5] I nuovi metodi di autenticazione DEVONO ripristinare i metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) una volta ogni 72 ore o meno OPPURE comunicare chiaramente all'utente che alcuni dati non verranno sottoposti a backup per preservare la privacy dei dati.

Se le implementazioni dei dispositivi aggiungono o modificano i metodi di autenticazione principali consigliati per sbloccare la schermata di blocco e utilizzano un nuovo metodo di autenticazione basato sulla biometria da trattare come un modo sicuro per bloccare lo schermo, il nuovo metodo:

  • [C-4-1] DEVE soddisfare tutti i requisiti descritti nella sezione 7.3.10 per Convenienza.
  • [C-4-2] DEVE disporre di un meccanismo di fallback per utilizzare uno dei metodi di autenticazione principali consigliati basati su un segreto noto.
  • [C-4-3] DEVE essere disattivato e consentire solo l'autenticazione principale consigliata per sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio della funzionalità Keyguard chiamando il metodo DevicePolicyManager.setKeyguardDisabledFeatures(), con uno qualsiasi dei flag biometrici associati (ad es. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE o KEYGUARD_DISABLE_IRIS).

Se i metodi di autenticazione biometrica non soddisfano i requisiti per l'autenticazione forte descritti nella sezione 7.3.10:

  • [C-5-1] I metodi DEVONO essere disattivati se l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-5-2] All'utente DEVE essere richiesta l'autenticazione principale consigliata (ad es. PIN, sequenza, password) dopo un periodo di timeout di inattività di 4 ore. Il periodo di timeout di inattività viene reimpostato dopo qualsiasi conferma riuscita delle credenziali del dispositivo.
  • [C-5-3] I metodi NON DEVONO essere trattati come una schermata di blocco sicura e DEVONO soddisfare i requisiti che iniziano con C-8 nella sezione seguente.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco e un nuovo metodo di autenticazione si basa su un token fisico o sulla posizione:

  • [C-6-1] DEVE disporre di un meccanismo di fallback per utilizzare uno dei metodi di autenticazione principali consigliati, basato su un segreto noto e soddisfare i requisiti per essere considerato una schermata di blocco sicura.
  • [C-6-2] Il nuovo metodo DEVE essere disattivato e deve consentire solo a uno dei metodi di autenticazione principale consigliati di sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio con il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED.
  • [C-6-3] All'utente DEVE essere richiesta una delle modalità di autenticazione primaria consigliate (ad es. PIN, sequenza, password) almeno una volta ogni 4 ore o meno.
  • [C-6-4] Il nuovo metodo NON DEVE essere trattato come una schermata di blocco sicura e DEVE rispettare i vincoli elencati in C-8 di seguito.

Se le implementazioni del dispositivo hanno una schermata di blocco sicura e includono uno o più trust agent, che implementano l'API di sistema TrustAgentService,

  • [C-7-1] DEVE essere presente un'indicazione chiara nel menu delle impostazioni e nella schermata di blocco quando il blocco del dispositivo viene posticipato o può essere mantenuto sbloccato da uno o più trust agent. Ad esempio, AOSP soddisfa questo requisito mostrando una descrizione testuale per le impostazioni "Blocco automatico" e "Tasto di accensione blocca istantaneamente" nel menu delle impostazioni e un'icona distinguibile nella schermata di blocco.
  • [C-7-2] DEVE rispettare e implementare completamente tutte le API Trust Agent nella classe DevicePolicyManager, ad esempio la costante KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-7-3] NON DEVE implementare completamente la funzione TrustAgentService.addEscrowToken() su un dispositivo utilizzato come dispositivo personale principale (ad es. dispositivo portatile), ma PUÒ implementare completamente la funzione su implementazioni di dispositivi che vengono in genere condivisi (ad es. Android TV o dispositivo per auto).
  • [C-7-4] DEVE criptare tutti i token memorizzati aggiunti da TrustAgentService.addEscrowToken().
  • [C-7-5] NON DEVE archiviare la chiave di crittografia o il token di escrow sullo stesso dispositivo in cui viene utilizzata la chiave. Ad esempio, è consentito a una chiave memorizzata su uno smartphone sbloccare un account utente su una TV.
  • [C-7-6] DEVE informare l'utente delle implicazioni per la sicurezza prima di attivare il token di deposito per decriptare l'archiviazione dei dati.
  • [C-7-7] DEVE disporre di un meccanismo di fallback per utilizzare uno dei metodi di autenticazione principali consigliati.
  • [C-7-8] All'utente DEVE essere richiesta l'autenticazione primaria consigliata (ad es.PIN, sequenza, password) almeno una volta ogni 72 ore o meno, a meno che non sia in discussione la sicurezza dell'utente (ad es. distrazione del conducente).
  • [C-7-9] All'utente DEVE essere richiesta l'autenticazione primaria consigliata (ad es. PIN, sequenza, password) dopo un periodo di inattività di 4 ore, a meno che non sia in discussione la sicurezza dell'utente (ad es. distrazione del conducente). Il periodo di timeout di inattività viene reimpostato dopo qualsiasi conferma riuscita delle credenziali del dispositivo.
  • [C-7-10] NON DEVE essere trattato come una schermata di blocco sicura e DEVE rispettare i vincoli elencati in C-8 di seguito.
  • [C-7-11] NON DEVE consentire a Trust Agents sui dispositivi personali principali (ad es.portatili) di sbloccare il dispositivo e può utilizzarli solo per mantenere un dispositivo già sbloccato nello stato sbloccato per un massimo di 4 ore. L'implementazione predefinita di TrustManagerService in AOSP soddisfa questo requisito.
  • [C-7-12] DEVE utilizzare un canale di comunicazione con protezione criptata (ad es.UKEY2) per trasferire il token di deposito dal dispositivo di archiviazione al dispositivo di destinazione.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco che non è una schermata di blocco sicura come descritto sopra e utilizzano un nuovo metodo di autenticazione per sbloccare il keyguard:

  • [C-8-1] Il nuovo metodo DEVE essere disattivato quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED.
  • [C-8-2] NON DEVONO reimpostare i timer di scadenza della password impostati da DevicePolicyManager.setPasswordExpirationTimeout().
  • [C-8-3] NON DEVONO esporre un'API per l'utilizzo da parte di app di terze parti per modificare lo stato della serratura.

9.11.2. StrongBox

Il sistema Android Keystore consente agli sviluppatori di app di archiviare le chiavi di crittografia in un processore sicuro dedicato, nonché nell'ambiente di esecuzione isolato descritto in precedenza. Un processore sicuro dedicato di questo tipo è chiamato "StrongBox". I requisiti da C-1-3 a C-1-11 di seguito definiscono i requisiti che un dispositivo DEVE soddisfare per essere qualificato come StrongBox.

Implementazioni del dispositivo con un processore sicuro dedicato:

  • [C-SR] Sono VIVAMENTE CONSIGLIATI per supportare StrongBox. StrongBox diventerà probabilmente un requisito in una versione futura.

Se le implementazioni dei dispositivi supportano StrongBox:

  • [C-1-1] MUST declare FEATURE_STRONGBOX_KEYSTORE.

  • [C-1-2] DEVE fornire un hardware sicuro dedicato utilizzato per il keystore e l'autenticazione utente sicura. L'hardware sicuro dedicato può essere utilizzato anche per altri scopi.

  • [C-1-3] DEVE avere una CPU discreta che non condivida cache, DRAM, coprocessori o altre risorse di base con il processore dell'applicazione (AP).

  • [C-1-4] DEVE garantire che qualsiasi periferica condivisa con l'AP non possa alterare in alcun modo l'elaborazione di StrongBox né ottenere informazioni da StrongBox. Il fornitore di servizi potrebbe disattivare o bloccare l'accesso a StrongBox.

  • [C-1-5] DEVE avere un orologio interno con una precisione ragionevole (+/-10%) immune alla manipolazione da parte dell'AP.

  • [C-1-6] DEVE disporre di un generatore di numeri casuali che produca un output distribuito in modo uniforme e imprevedibile.

  • [C-1-7] DEVE essere a prova di manomissione, inclusa la resistenza alla penetrazione fisica e ai malfunzionamenti.

  • [C-1-8] MUST have side-channel resistance, including resistance against leaking information via power, timing, electromagnetic radiation, and thermal radiation side channels.

  • [C-1-9] DEVE disporre di un archivio sicuro che garantisca la riservatezza, l'integrità, l'autenticità, la coerenza e l'aggiornamento dei contenuti. L'archivio NON deve essere leggibile o modificabile, ad eccezione di quanto consentito dalle API StrongBox.

  • Per convalidare la conformità ai requisiti [C-1-3] - [C-1-9], le implementazioni del dispositivo:

    • [C-1-10] DEVE includere l'hardware certificato in base al profilo di protezione IC sicuro BSI-CC-PP-0084-2014 o valutato da un laboratorio di test accreditato a livello nazionale che incorpora la valutazione della vulnerabilità con potenziale di attacco elevato in base ai Common Criteria Application of Attack Potential to Smartcards.
    • [C-1-11] DEVE includere il firmware valutato da un laboratorio di test accreditato a livello nazionale che incorpora la valutazione della vulnerabilità con elevato potenziale di attacco in base ai Common Criteria Application of Attack Potential to Smartcards.
    • [C-SR] Sono FORTEMENTE CONSIGLIATI per includere l'hardware valutato utilizzando un Security Target, un livello di garanzia della valutazione (EAL) 5, aumentato da AVA_VAN.5. La certificazione EAL 5 diventerà probabilmente un requisito in una versione futura.

  • [C-SR] sono FORTEMENTE CONSIGLIATI per fornire resistenza agli attacchi interni (IAR), il che significa che un insider con accesso alle chiavi di firma del firmware non può produrre firmware che causino la perdita di segreti da parte di StrongBox, che aggirino i requisiti di sicurezza funzionali o che consentano in altro modo l'accesso a dati utente sensibili. Il modo consigliato per implementare IAR è consentire gli aggiornamenti firmware solo quando la password dell'utente principale viene fornita tramite IAuthSecret HAL.

9.12. Eliminazione dei dati

Tutte le implementazioni dei dispositivi:

  • [C-0-1] DEVE fornire agli utenti un meccanismo per eseguire un "Ripristino dei dati di fabbrica".
  • [C-0-2] DEVE eliminare tutti i dati nel file system userdata.
  • [C-0-3] DEVE eliminare i dati in modo da soddisfare gli standard di settore pertinenti, ad esempio NIST SP800-88.
  • [C-0-4] DEVE attivare la procedura di "Ripristino dei dati di fabbrica" di cui sopra quando l'API DevicePolicyManager.wipeData() viene chiamata dall'app controller dei criteri dei dispositivi dell'utente principale.
  • PUÒ fornire un'opzione di cancellazione rapida dei dati che esegue solo un'eliminazione logica dei dati.

9.13. Modalità di avvio sicuro

Android offre la modalità provvisoria, che consente agli utenti di avviare il dispositivo in una modalità in cui è consentita l'esecuzione solo delle app di sistema preinstallate e tutte le app di terze parti sono disattivate. Questa modalità, nota come "modalità di avvio sicuro", consente all'utente di disinstallare app di terze parti potenzialmente dannose.

Le implementazioni del dispositivo sono:

  • [SR] CONSIGLIAMO VIVAMENTE di implementare la modalità provvisoria.

Se le implementazioni dei dispositivi implementano la modalità di avvio protetto:

  • [C-1-1] DEVE fornire all'utente un'opzione per accedere alla modalità provvisoria in modo non interrompibile da app di terze parti installate sul dispositivo, tranne quando l'app di terze parti è un controller delle norme relative ai dispositivi e ha impostato il flag UserManager.DISALLOW_SAFE_BOOT su true.

  • [C-1-2] DEVE fornire all'utente la possibilità di disinstallare qualsiasi app di terze parti in modalità provvisoria.

  • DEVE fornire all'utente un'opzione per accedere alla modalità di avvio sicuro dal menu di avvio utilizzando un flusso di lavoro diverso da quello di un avvio normale.

9.14. Isolamento del sistema del veicolo

I dispositivi Android Automotive devono scambiare dati con i sottosistemi critici del veicolo utilizzando l'HAL del veicolo per inviare e ricevere messaggi tramite le reti del veicolo, come il bus CAN.

Lo scambio di dati può essere protetto implementando funzionalità di sicurezza al di sotto dei livelli del framework Android per impedire interazioni dannose o involontarie con questi sottosistemi.

9.15. Piani di abbonamento

"Piani di abbonamento" si riferisce ai dettagli del piano di fatturazione forniti da un operatore di telefonia mobile tramite SubscriptionManager.setSubscriptionPlans().

Tutte le implementazioni dei dispositivi:

  • [C-0-1] DEVE restituire i piani di abbonamento solo all'app dell'operatore di telefonia mobile che li ha forniti originariamente.
  • [C-0-2] NON DEVE eseguire il backup o caricare da remoto i piani di abbonamento.
  • [C-0-3] DEVE consentire solo override, ad esempio SubscriptionManager.setSubscriptionOverrideCongested(), dall'app dell'operatore di telefonia mobile che attualmente fornisce piani in abbonamento validi.

10. Test di compatibilità del software

Le implementazioni dei dispositivi DEVONO superare tutti i test descritti in questa sezione. Tuttavia, tieni presente che nessun pacchetto di test software è completamente esaustivo. Per questo motivo, è VIVAMENTE CONSIGLIATO agli implementatori di dispositivi di apportare il minor numero possibile di modifiche all'implementazione di riferimento e preferita di Android disponibile nell'Android Open Source Project. In questo modo, ridurrai al minimo il rischio di introdurre bug che creano incompatibilità che richiedono rielaborazioni e potenziali aggiornamenti del dispositivo.

10.1. Compatibility Test Suite (CTS)

Implementazioni del dispositivo:

  • [C-0-1] DEVE superare la suite di test di compatibilità Android (CTS) disponibile nell'Android Open Source Project, utilizzando il software di spedizione finale sul dispositivo.

  • [C-0-2] DEVE garantire la compatibilità in caso di ambiguità nel CTS e per qualsiasi reimplementazione di parti del codice sorgente di riferimento.

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi software, il CTS potrebbe contenere bug. La CTS avrà una versione indipendente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni della CTS per Android 10.

Implementazioni del dispositivo:

  • [C-0-3] DEVE superare l'ultima versione di CTS disponibile al momento del completamento del software del dispositivo.

  • DEVE utilizzare l'implementazione di riferimento nell'albero Android Open Source il più possibile.

10.2. Strumento di verifica CTS

CTS Verifier è incluso in Compatibility Test Suite e deve essere eseguito da un operatore umano per testare funzionalità che non possono essere testate da un sistema automatizzato, come il corretto funzionamento di una fotocamera e dei sensori.

Implementazioni del dispositivo:

  • [C-0-1] DEVE eseguire correttamente tutti i casi applicabili nel programma di verifica CTS.

CTS Verifier include test per molti tipi di hardware, tra cui alcuni hardware opzionali.

Implementazioni del dispositivo:

  • [C-0-2] DEVE superare tutti i test per l'hardware in suo possesso; ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente lo scenario di test dell'accelerometro in CTS Verifier.

Gli scenari di test per le funzionalità indicate come facoltative in questo Compatibility Definition Document POSSONO essere ignorati o omessi.

  • [C-0-2] Ogni dispositivo e ogni build DEVE eseguire correttamente CTS Verifier, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori di dispositivi eseguano esplicitamente CTS Verifier su build che differiscono solo in modo banale. Nello specifico, le implementazioni del dispositivo che differiscono da un'implementazione che ha superato il CTS Verifier solo per l'insieme di impostazioni internazionali, branding e così via INCLUDONO il test CTS Verifier.

11. Software aggiornabile

  • [C-0-1] Le implementazioni del dispositivo DEVONO includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire upgrade "live", ovvero potrebbe essere necessario riavviare il dispositivo. Può essere utilizzato qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, uno qualsiasi dei seguenti approcci soddisferà questo requisito:

    • Download "over-the-air (OTA)" con aggiornamento offline tramite riavvio.
    • Aggiornamenti "in tethering" tramite USB da un PC host.
    • Aggiornamenti "offline" tramite riavvio e aggiornamento da un file su un dispositivo di archiviazione rimovibile.

  • [C-0-2] Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. ovvero il meccanismo di aggiornamento DEVE preservare i dati privati dell'applicazione e i dati condivisi dell'applicazione. Tieni presente che il software Android upstream include un meccanismo di aggiornamento che soddisfa questo requisito.

  • [C-0-3] L'intero aggiornamento DEVE essere firmato e il meccanismo di aggiornamento sul dispositivo DEVE verificare l'aggiornamento e la firma rispetto a una chiave pubblica memorizzata sul dispositivo.

  • [C-SR] Il meccanismo di firma è FORTEMENTE CONSIGLIATO per eseguire l'hashing dell'aggiornamento con SHA-256 e convalidare l'hash rispetto alla chiave pubblica utilizzando ECDSA NIST P-256.

Se le implementazioni del dispositivo includono il supporto di una connessione dati senza limiti, ad esempio 802.11 o il profilo PAN (Personal Area Network) Bluetooth, allora:

  • [C-1-1] DEVE supportare i download OTA con aggiornamento offline tramite riavvio.

Per le implementazioni dei dispositivi che vengono lanciate con Android 6.0 e versioni successive, il meccanismo di aggiornamento DEVE supportare la verifica che l'immagine di sistema sia identica al risultato previsto dopo un aggiornamento OTA. L'implementazione OTA basata su blocchi nel progetto Android Open Source, aggiunta a partire da Android 5.1, soddisfa questo requisito.

Inoltre, le implementazioni dei dispositivi DEVONO supportare gli aggiornamenti di sistema A/B. AOSP implementa questa funzionalità utilizzando l'HAL di controllo dell'avvio.

Se viene rilevato un errore nell'implementazione di un dispositivo dopo il suo rilascio, ma entro la sua ragionevole durata del prodotto, che viene determinata in consultazione con il team di compatibilità Android per influire sulla compatibilità delle applicazioni di terze parti, allora:

  • [C-2-1] L'implementatore del dispositivo DEVE correggere l'errore tramite un aggiornamento software disponibile che può essere applicato secondo il meccanismo appena descritto.

Android include funzionalità che consentono all'app Proprietario del dispositivo (se presente) di controllare l'installazione degli aggiornamenti di sistema. Se il sottosistema di aggiornamento di sistema per i dispositivi segnala android.software.device_admin, significa che:

12. Log delle modifiche del documento

Per un riepilogo delle modifiche alla definizione di compatibilità in questa release:

Per un riepilogo delle modifiche alle sezioni individuali:

  1. Introduzione
  2. Tipi di dispositivi
  3. Software
  4. Packaging dell'applicazione
  5. Contenuti multimediali
  6. Strumenti e opzioni per sviluppatori
  7. Compatibilità hardware
  8. Prestazioni e potenza
  9. Modello di sicurezza
  10. Test di compatibilità del software
  11. Software aggiornabile
  12. Log delle modifiche del documento
  13. Contattaci

12.1. Suggerimenti per la visualizzazione del log delle modifiche

Le modifiche sono contrassegnate come segue:

  • CDD
    Modifiche sostanziali ai requisiti di compatibilità.

  • Documenti
    Modifiche estetiche o relative alla build.

Per una visualizzazione ottimale, aggiungi i parametri URL pretty=full e no-merges agli URL del log delle modifiche.

13. Contattaci

Puoi partecipare al forum sulla compatibilità di Android e chiedere chiarimenti o segnalare eventuali problemi che ritieni non siano trattati nel documento.