Definizione di compatibilità con Android 11

1. Introduzione

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

L'uso di "DEVE", "NON DEVE", "OBBLIGATORIO", "DEVE", "NON DEVE", "DEVE", "NON DEVE", "CONSIGLIATO", "PUÒ" e "FACOLTATIVO" è conforme allo standard IETF definito nella RFC2119.

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

Per essere considerati compatibili con Android 11, le implementazioni dei dispositivi DEVONO soddisfare i requisiti presentati in questa definizione di compatibilità, inclusi eventuali documenti incorporati tramite riferimento.

Se questa definizione o i test software descritti nella sezione 10 non sono chiari, 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 sia quella preferita di Android. È FORTEMENTE CONSIGLIATO agli implementatori di dispositivi di basare le proprie implementazioni il più possibile sul codice sorgente "upstream" disponibile nell'Android Open Source Project. Sebbene alcuni componenti possano essere teoricamente sostituiti con implementazioni alternative, è FORTEMENTE CONSIGLIATO di non seguire questa pratica, in quanto superare i test software diventerà notevolmente più difficile. È responsabilità dell'implementatore garantire la piena compatibilità comportamentale con l'implementazione standard di Android, inclusi e oltre i test di compatibilità. Infine, tieni presente che alcune sostituzioni e modifiche dei componenti sono vietate esplicitamente da questo documento.

Molte delle risorse a cui si fa riferimento in questo documento derivano direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni riportate nella documentazione dell'SDK. In tutti i casi in cui questa definizione di compatibilità o la suite di test di compatibilità non è in linea con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Eventuali dettagli tecnici forniti nelle risorse collegate in questo documento sono considerati 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 che si applicano 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, a questi requisiti viene fatto riferimento come "Requisiti principali".

1.1.2. ID requisito

L'ID requisito viene assegnato per i requisiti MUST.

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

Ogni ID è definito come segue:

  • ID tipo di dispositivo (scopri di più in 2. Tipi di dispositivi)
    • C: Core (requisiti applicati a qualsiasi implementazione di dispositivi Android)
    • H: dispositivo palmare Android
    • T: dispositivo Android TV
    • A: Implementazione di Android Automotive
    • W: Implementazione di Android Watch
    • Scheda: implementazione del tablet Android
  • ID condizione
    • Quando il requisito è incondizionato, questo ID viene impostato su 0.
    • Quando il requisito è condizionale, viene assegnato 1 per la 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 aumenta 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 dispositivi

Sebbene il progetto open source Android fornisca uno stack software che può essere utilizzato per una serie 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é requisiti e consigli aggiuntivi applicabili a ciascun tipo di dispositivo.

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 del dispositivo

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

2.2. Requisiti del dispositivo portatile

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

Le implementazioni dei dispositivi Android sono classificate come dispositivi mobili se soddisfano tutti i seguenti criteri:

  • Avere una fonte di alimentazione che offra mobilità, ad esempio una batteria.
  • Avere una dimensione dello schermo fisico diagonale compresa tra 8,4 cm (o 6,3 cm per i dispositivi lanciati con un livello API precedente ad Android 11) e 20 cm.

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

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

2.2.1. Hardware

Implementazioni dei dispositivi portatili:

  • [7.1.1.1/H-0-1] DEVE avere almeno un display compatibile con Android che soddisfi tutti i requisiti descritti in questo documento.
  • [7.1.1.3/H-SR] È FORTEMENTE CONSIGLIATO fornire agli utenti un'opzione per modificare le dimensioni del display (densità dello schermo).

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

  • [7.1.1.1/H-1-1]* È OBBLIGATORIO che lo schermo logico reso disponibile per le applicazioni di terze parti sia di almeno 5,1 cm sui lati corti e di 6,9 cm sui lati lunghi. I dispositivi lanciati con un livello API precedente a quello di questo documento sono esenti da questo requisito.

Se le implementazioni dei dispositivi portatili non supportano la rotazione dello schermo software, devono:

  • [7.1.1.1/H-2-1]* È OBBLIGATORIO che lo schermo logico reso disponibile per le applicazioni di terze parti sia di almeno 6,9 cm sui lati corti. I dispositivi lanciati con un livello API precedente a quello di questo documento sono esenti da questo requisito.

Se le implementazioni dei dispositivi mobili dichiarano di supportare i display HDR tramite Configuration.isScreenHdr():

  • [7.1.4.5/H-1-1] È OBBLIGATORIO 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 dei dispositivi portatili:

  • [7.1.4.6/H-0-1] DEVE indicare se il dispositivo supporta la funzionalità di profilazione della GPU tramite una proprietà di sistema graphics.gpu.profiler.support.

Se le implementazioni dei dispositivi palmari dichiarano il supporto tramite una proprietà di sistema graphics.gpu.profiler.support:

Implementazioni dei dispositivi portatili:

  • [7.1.5/H-0-1] DEVE includere il supporto della modalità di compatibilità delle applicazioni precedenti come implementata dal codice open source Android upstream. In altre parole, le implementazioni dei dispositivi NON DEVONO modificare gli attivatori o le soglie a cui viene attivata la modalità di compatibilità e NON DEVONO modificare 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 App recenti su almeno uno dei display compatibili con Android.
  • [7.2.3/H-0-2] DEVE inviare all'applicazione in primo piano sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK). Questi eventi NON DEVONO essere utilizzati dal sistema e POSSONO essere attivati dall'esterno 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] È FORTEMENTE CONSIGLIATO di avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService, o un'attività che gestisce ACTION_ASSIST con 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 dei dispositivi palmari includono un accelerometro a 3 assi, devono:

  • [7.3.1/H-1-1] DEVE essere in grado di registrare 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 registrare le misurazioni GNSS non appena vengono rilevate, anche se una posizione calcolata da GPS/GNSS non è ancora stata registrata.
  • [7.3.3/H-2-2] DEVE segnalare le pseudoraggi e le velocità di pseudoraggi GNSS che, in condizioni di cielo aperto dopo aver determinato la posizione, mentre sono fermi o si muovono 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 dei dispositivi palmari includono un giroscopio a 3 assi, devono:

  • [7.3.4/H-3-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 100 Hz.
  • [7.3.4/H-3-2] DEVE essere in grado di misurare le variazioni 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 dei 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 di Bluetooth e Bluetooth LE.

Se le implementazioni dei dispositivi palmari includono una connessione con misuratore, devono:

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

Se le implementazioni dei dispositivi palmari includono un dispositivo fotocamera logico che elenca le funzionalità utilizzando CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA:

  • [7.5.4/H-1-1] PER IMPEDIRE che le immagini siano sfocate, il campo visivo (FOV) DEVE essere impostato su "Normale" per impostazione predefinita e DEVE essere compreso tra 50 e 90 gradi.

Implementazioni dei 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 è disponibile meno di 1 GB di memoria per il kernel e lo spazio utente.

Se le implementazioni dei dispositivi palmari dichiarano il supporto di un'ABI solo 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 di 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 palmari 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 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 di 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 dei dispositivi palmari includono meno o uguale a 1 GB di memoria disponibile per il kernel e lo spazio utente, devono:

  • [7.6.1/H-9-1] È OBBLIGATORIO 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 dei dispositivi palmari 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 dei dispositivi portatili:

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

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

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

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

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

Implementazioni dei dispositivi portatili:

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

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

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

Se le implementazioni dei 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 software dei codici HID:
Funzione Mappature Contesto Comportamento
A Pagina di utilizzo HID: 0x0C
Utilizzo HID: 0x0CD
Chiave del kernel: KEY_PLAYPAUSE
Chiave Android: KEYCODE_MEDIA_PLAY_PAUSE 		Riproduzione di contenuti multimediali Input: pressione breve
Output: riproduzione o messa in pausa
Input: pressione prolungata
Output: Avvia comando vocale
Invia: android.speech.action.VOICE_SEARCH_HANDS_FREE se il dispositivo è bloccato o lo schermo è spento. Invia android.speech.RecognizerIntent.ACTION_WEB_SEARCH in caso contrario
Chiamata in arrivo Input: pressione breve
Output: accetta chiamata
Input: pressione prolungata
Output: Rifiuta chiamata
Chiamata in corso Input: pressione breve
Output: termina chiamata
Input: pressione prolungata
Output: disattiva o riattiva il 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 prolungata
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 prolungata
Output: riduce il volume del sistema o delle cuffie
D Pagina di utilizzo HID: 0x0C
Utilizzo HID: 0x0CF
Chiave del 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 al momento dell'inserimento del connettore, ma solo dopo che le interfacce audio e gli endpoint USB sono stati enumerati correttamente per identificare il tipo di terminale connesso.

Quando vengono rilevati i tipi di terminali audio USB 0x0302:

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

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

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

Quando l'API AudioManager.getDevices() viene chiamata 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 il ruolo 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 del collegamento 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.

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

L'attuatore a risonanza lineare (LRA) è un sistema a molla a massa singola con una frequenza di risonanza dominante in cui la massa si traduce nella direzione del movimento desiderato.

Se le implementazioni dei dispositivi portatili includono almeno un attuatore a risonanza lineare, devono:

  • [7.10/H]* DOVREBBE spostare l'attuatore aptico sull'asse X con orientamento verticale.

Se le implementazioni dei dispositivi portatili dispongono di un attuatore aptico che è un attuatore a risonanza lineare (LRA) sull'asse X, devono:

  • [7.10/H-SR]* È FORTEMENTE CONSIGLIATO che la frequenza di risonanza dell'LRA sull'asse X sia inferiore a 200 Hz.

Se le implementazioni dei dispositivi portatili seguono la mappatura delle costanti aptica, queste:

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 (AAC a basso ritardo migliorato)

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 dei 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 che fornisca all'utente la possibilità di accedere ai dati del provider di documenti utilizzando l'API DocumentsProvider.
  • [3.2.3.1/H-0-2]* DEVE precaricare una o più applicazioni o componenti di servizio con un gestore degli intent per tutti i pattern di filtro degli intent pubblici definiti dai seguenti intent di applicazione elencati qui.
  • [3.2.3.1/H-SR] È FORTEMENTE CONSIGLIATO di precaricare un'applicazione email che possa gestire gli intent ACTION_SENDTO o ACTION_SEND o ACTION_SEND_MULTIPLE per inviare un'email.
  • [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 di browser autonoma per la navigazione web degli utenti generici.
  • [3.8.1/H-SR] È FORTEMENTE CONSIGLIATO implementare un Avvio app predefinito che supporti il bloccaggio in-app di scorciatoie, widget e widgetFeatures.
  • [3.8.1/H-SR] È FORTEMENTE CONSIGLIATO implementare un Avvio app predefinito che fornisca un accesso rapido alle scorciatoie aggiuntive fornite dalle app di terze parti tramite l'API ShortcutManager.
  • [3.8.1/H-SR] È MOLTO 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] DEVE supportare le notifiche avanzate.
  • [3.8.3/H-0-3] DEVE supportare le notifiche in primo piano.
  • [3.8.3/H-0-4] DEVE includere una tendina delle notifiche, che consenta all'utente di controllare direttamente (ad es. rispondere, posticipare, ignorare, bloccare) le notifiche tramite elementi di usabilità come i pulsanti di azione o il pannello di controllo come 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 ulteriore interazione dell'utente.
  • [3.8.3/H-SR] È FORTEMENTE CONSIGLIATO mostrare tutte le opzioni fornite tramite RemoteInput.Builder setChoices() nell'area notifiche quando l'utente espande tutte le notifiche nell'area notifiche.
  • [3.8.3.1/H-SR] È MOLTO CONSIGLIATO mostrare le azioni per le quali Notification.Action.Builder.setContextual è impostato su true in linea con le risposte visualizzate da Notification.Remoteinput.Builder.setChoices.
  • [3.8.4/H-SR] È FORTEMENTE CONSIGLIATO implementare un assistente sul dispositivo per gestire l'azione di assistenza.

Se le implementazioni dei dispositivi palmari supportano l'azione di assistenza, devono:

  • [3.8.4/H-SR] È FORTEMENTE 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 mobili supportano conversation notifications e le raggruppano in una sezione separata dalle notifiche di avviso e silenziose non di conversazione, devono:

  • [3.8.4/H-1-1]* DEVE mostrare le notifiche delle conversazioni prima di quelle non relative alle conversazioni, ad eccezione delle notifiche dei servizi in primo piano in esecuzione e delle notifiche importance:high.

Se le implementazioni dei dispositivi Android portatili supportano una schermata di blocco, devono:

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

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

  • [3.9/H-1-1] DEVE implementare l'intera gamma di criteri di amministrazione del dispositivo definiti nella documentazione dell'SDK Android.
  • [3.9/H-1-2] DEVE dichiarare il supporto dei profili gestiti tramite il flag della 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.

Se le implementazioni dei dispositivi mobili includono il supporto delle API ControlsProviderService e Control e consentono alle applicazioni di terze parti di pubblicare controlli dei dispositivi, devono:

  • [3.8.16/H-1-1] È OBBLIGATORIO dichiarare il flag funzionalità android.software.controls e impostarlo su true.
  • [3.8.16/H-1-2] DEVE fornire all'utente la possibilità di aggiungere, modificare, selezionare e utilizzare i controlli del dispositivo preferiti dall'utente tra quelli registrati dalle applicazioni di terze parti tramite le API ControlsProviderService e Control.
  • [3.8.16/H-1-3] DEVE fornire l'accesso a questa funzionalità per l'utente entro tre interazioni da un Avvio app predefinito.
  • [3.8.16/H-1-4] In questa funzionalità per l'utente DEVONO essere visualizzati con precisione il nome e l'icona di ogni app di terze parti che fornisce controlli tramite l'API ControlsProviderService, nonché eventuali campi specificati forniti dalle API Control.

Al contrario, se le implementazioni dei dispositivi palmari non implementano questi controlli:

Implementazioni dei dispositivi portatili:

  • [3.10/H-0-1] DEVE supportare i servizi di accessibilità di terze parti.
  • [3.10/H-SR] È FORTEMENTE CONSIGLIATO di precaricare sul dispositivo servizi di accessibilità paragonabili o superiori alle funzionalità di Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato) come indicato nell'Android Open Source Project.
  • [3.11/H-0-1] DEVE supportare l'installazione di motori TTS di terze parti.
  • [3.11/H-SR] È MOLTO CONSIGLIATO includere un motore TTS che supporti le lingue disponibili sul dispositivo.
  • [3.13/H-SR] È FORTEMENTE CONSIGLIATO includere un componente dell'interfaccia utente delle Impostazioni rapide.

Se le implementazioni dei 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 essere più alta di 32 dp dal fondo dello schermo.

Se le implementazioni dei dispositivi palmari 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 ciascun lato. L'area dei gesti DEVE avere una larghezza di 24 dp per impostazione predefinita.

2.2.4. Prestazioni e potenza

  • [8.1/H-0-1] Latenza dei fotogrammi costante. La latenza dei fotogrammi incoerente o un ritardo nel rendering dei fotogrammi NON DEVONO verificarsi più di 5 volte al secondo e DEVONO essere inferiori a 1 fotogramma al secondo.
  • [8.1/H-0-2] Latenza dell'interfaccia utente. Le implementazioni dei dispositivi DEVONO garantire un'esperienza utente a bassa latenza scorrendo un elenco di 10.000 voci come definito dal Compatibility Test Suite (CTS) di Android in meno di 36 secondi.
  • [8.1/H-0-3] Passaggio da un'attività all'altra. Quando sono state avviate più applicazioni, il riavvio di un'applicazione già in esecuzione DOVESSE richiedere meno di 1 secondo.

Implementazioni dei dispositivi portatili:

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

Se le implementazioni dei 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] È OBBLIGATORIO 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 App Standby e Sospensione.

Implementazioni dei dispositivi portatili:

  • [8.4/H-0-1] È NECESSARIO fornire un profilo di alimentazione per componente che definisce il valore di consumo corrente per ciascun componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
  • [8.4/H-0-2] DEVE riportare tutti i valori di consumo di energia in milliampere ora (mAh).
  • [8.4/H-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID del processo. 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 di energia tramite il comando a shell adb shell dumpsys batterystats per lo sviluppatore dell'app.
  • [8,4/H] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.

Se le implementazioni dei dispositivi portatili includono uno schermo o un'uscita video, devono:

2.2.5. Modello di sicurezza

Implementazioni dei 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]* È NECESSARIO eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
  • [9.11/H-0-3]* DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni hash di famiglie 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 sopra. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA. Il progetto Android Open Source (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura sottoposta a revisione da parte di terze parti di un'isolamento basato su hypervisor adeguato sono opzioni alternative.
  • [9.11/H-0-4]* DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo se l'autenticazione va a buon fine, consentire l'utilizzo delle chiavi legate 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 open source Android upstream fornisce l'HAL (Hardware Abstraction Layer) Gatekeeper 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 dei 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, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione delle chiavi, 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 mobili 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, di massimo 15 secondi.
  • [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 dei dispositivi mobili includono più utenti e non dichiarano il flag della funzionalità android.hardware.telephony:

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

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

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

2.2.6. Compatibilità di Strumenti per sviluppatori e Opzioni 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):

  • Perfetto
    • [6.1/H-0-2]* DEVE esporre un file binario /system/bin/perfetto all'utente della shell la cui cmdline sia conforme alla documentazione di perfetto.
    • [6.1/H-0-3]* Il file binario di perfetto DEVE accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
    • [6.1/H-0-4]* Il file binario di perfetto DEVE scrivere come output una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
    • [6.1/H-0-5]* DEVE fornire, tramite il file binario perfetto, almeno le origini dati descritte nella documentazione di perfetto.
    • [6.1/H-0-6]* Il daemon di tracciamento di perfetto DEVE essere abilitato per impostazione predefinita (proprietà di sistema persist.traced.enable).

2.2.7 Classe di rendimento dei contenuti multimediali su dispositivi mobili

Consulta la sezione 7.11 per la definizione della classe di rendimento dei media.

2.2.7.1. Contenuti multimediali

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.R per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, allora:

  • [5.1/H-1-1] DEVE pubblicizzare il numero massimo di sessioni di decodifica video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-2] DEVE supportare 6 istanze di sessioni di decodifica video hardware (AVC o HEVC) in qualsiasi combinazione di codec in esecuzione contemporaneamente a una risoluzione di 720p a 30 fps.
  • [5.1/H-1-3] DEVE pubblicizzare il numero massimo di sessioni di codifica video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-4] DEVE supportare 6 istanze di sessioni di codifica video hardware (AVC o HEVC) in qualsiasi combinazione di codec in esecuzione contemporaneamente a una risoluzione di 720p a 30 fps.
  • [5.1/H-1-5] DEVE pubblicizzare il numero massimo di sessioni di codifica e decodifica video hardware che possono essere eseguite contemporaneamente in qualsiasi combinazione di codec tramite i metodi CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-6] DEVE supportare 6 istanze di decodifica video hardware e sessioni di codifica video hardware (AVC o HEVC) in qualsiasi combinazione di codec in esecuzione contemporaneamente a una risoluzione di 720p a 30 fps.
  • [5.1/H-1-7] DEVE avere una latenza di inizializzazione del codec pari o inferiore a 65 ms per una sessione di codifica video a 1080p o inferiore per tutti gli encoder video hardware (diversi dal codec Dolby Vision) in caso di carico. Per carico si intende una sessione di transcodifica solo video da 1080p a 720p concorrente che utilizza codec video hardware insieme all'inizializzazione della registrazione audio-video a 1080p.
  • [5.1/H-1-8] DEVE avere una latenza di inizializzazione del codec pari o inferiore a 50 ms per una sessione di codifica audio con una velocità in bit pari o inferiore a 128 Kbps per tutti gli codificatori audio quando sotto carico.Per carico si intende una sessione di transcodifica simultanea solo video da 1080p a 720p che utilizza codec video hardware insieme all'inizializzazione della registrazione audio-video a 1080p.
  • [5.3/H-1-1] NON DEVE perdere più di 1 frame in 10 secondi (ovvero meno dello 0,333% di perdita di frame) per una sessione video a 1080p a 30 fps sotto carico. Per carico si intende una sessione di transcodifica simultanea da 1080p a 720p solo video che utilizza codec video hardware, nonché una riproduzione audio AAC a 128 Kbps.
  • [5.3/H-1-2] NON DEVE perdere più di 1 frame in 10 secondi durante una modifica della risoluzione video in una sessione video a 30 fps sotto carico. Per carico si intende una sessione di transcodifica solo video da 1080p a 720p simultanea che utilizza codec video hardware, nonché una riproduzione audio AAC a 128 Kbps.
  • [5.6/H-1-1] DEVE avere una latenza tap-to-tone inferiore a 100 millisecondi utilizzando il test tap-to-tone di OboeTester o il test tap-to-tone di CTS Verifier.
2.2.7.2. Fotocamera

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.R per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, allora:

  • [7.5/H-1-1] DEVE avere una fotocamera posteriore principale con una risoluzione di almeno 12 megapixel che supporti l'acquisizione video a 4K a 30 fps. La fotocamera posteriore principale è la fotocamera posteriore con l'ID più basso.
  • [7.5/H-1-2] DEVE avere una fotocamera anteriore principale con una risoluzione di almeno 4 megapixel che supporti l'acquisizione video a 1080p a 30 fps. La fotocamera anteriore principale è la fotocamera anteriore con l'ID più basso.
  • [7.5/H-1-3] DEVE supportare la proprietà android.info.supportedHardwareLevel come COMPLETA o superiore per la fotocamera principale posteriore e LIMITATA o superiore per la fotocamera principale anteriore.
  • [7.5/H-1-4] DEVE supportare CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME per entrambe le fotocamere principali.
  • [7.5/H-1-5] DEVE avere una latenza di acquisizione JPEG della fotocamera2 inferiore a 1000 ms per la risoluzione di 1080p, misurata dal test di prestazioni della fotocamera CTS in condizioni di illuminazione ITS (3000 K) per entrambe le fotocamere principali.
  • [7.5/H-1-6] È NECESSARIO che la latenza di avvio di camera2 (apertura della fotocamera al primo frame di anteprima) sia inferiore a 600 ms, misurata dal test di prestazioni della fotocamera CTS in condizioni di illuminazione ITS (3000 K) per entrambe le fotocamere principali.
2.2.7.3. Hardware

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.R per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, allora:

  • [7.1.1.1/H-1-1] DEVE avere una risoluzione dello schermo di almeno 1080p.
  • [7.1.1.3/H-1-1] DEVE avere una densità dello schermo di almeno 400 dpi.
  • [7.6.1/H-1-1] DEVE avere almeno 6 GB di memoria fisica.
2.2.7.4. Prestazioni

Se le implementazioni dei dispositivi palmari restituiscono android.os.Build.VERSION_CODES.R per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, allora:

  • [8.2/H-1-1] DEVE garantire un rendimento di scrittura sequenziale di almeno 100 MB/s.
  • [8.2/H-1-2] DEVE garantire un rendimento di scrittura casuale di almeno 10 MB/s.
  • [8.2/H-1-3] DEVE garantire un rendimento di lettura sequenziale di almeno 200 MB/s.
  • [8.2/H-1-4] DEVE garantire un rendimento di lettura casuale di almeno 25 MB/s.

2.3. Requisiti della TV

Un dispositivo Android TV si riferisce a un'implementazione di un dispositivo Android che è un'interfaccia di intrattenimento per l'utilizzo 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 "10-foot").

Le implementazioni dei dispositivi Android sono classificate come TV 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 diagonale maggiore di 61 cm 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 dei dispositivi Android TV.

2.3.1. Hardware

Implementazioni dei 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 all'applicazione in primo piano sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK).
  • [7.2.6.1/T-0-1] DEVE includere il supporto per i controller di gioco e dichiarare il flag della funzionalità android.hardware.gamepad.
  • [7.2.7/T] È necessario fornire un telecomando da cui gli utenti possono accedere agli input di navigazione non tocco e alle principali tasti di navigazione.

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

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

Implementazioni dei 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 TV includono una porta USB che supporta la modalità host, devono:

  • [7.5.3/T-1-1] DEVE includere il supporto di 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 vengono utilizzate una delle seguenti densità:

    • 400 dpi o superiore su schermi piccoli/normali
    • xhdpi o superiore su schermi di grandi dimensioni
    • tvdpi o superiore su schermi extra large

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 di grandi dimensioni
    • tvdpi o superiore su schermi extra large

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 dei 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 TV 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] Profilo MPEG-4 HE AAC (AAC+)
  • [5.1/T-0-3] AAC ELD (AAC a basso ritardo migliorato)

Le implementazioni dei dispositivi TV 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 dei dispositivi TV:

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

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

Le implementazioni dei dispositivi TV DEVONO supportare la decodifica MPEG-2, come descritto nella Sezione 5.3.1, a frequenze frame video standard e risoluzioni 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 frame al secondo con Main Profile High Level. DEBBONO deinterlacciare il video MPEG-2 interlacciato e renderlo disponibile per le applicazioni di terze parti.

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

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

Le implementazioni di dispositivi TV con decodificatori hardware H.265 DEVONO supportare la decodifica H.265, come descritto nella Sezione 5.3.5, a frequenze frame video standard e risoluzioni fino a:

  • [5.3.5/T-1-1] 1080p HD a 60 frame al secondo con profilo principale di livello 4.1

Se le implementazioni dei dispositivi TV con decodificatori 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 di livello 5 del livello principale

Le implementazioni dei dispositivi TV DEVONO supportare la decodifica VP8, come descritto nella Sezione 5.3.6, a frequenze fotogrammi e risoluzioni video standard fino a:

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

Le implementazioni di dispositivi TV con decodificatori hardware VP9 DEVONO supportare la decodifica VP9, come descritto nella Sezione 5.3.7, a frequenze frame video e risoluzioni standard fino a:

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

Se le implementazioni dei dispositivi TV con decodificatori 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à colore di 8 bit).
  • [5.3.7/T-2-1] È FORTEMENTE CONSIGLIATO supportare il profilo di decodifica UHD a 60 frame al secondo con il profilo 2 (profondità colore di 10 bit).

Implementazioni dei dispositivi TV:

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

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

  • [5.8/T-0-1] È OBBLIGATORIO impostare la modalità di uscita HDMI in modo da selezionare la risoluzione massima che può essere supportata con una frequenza di aggiornamento di 50 Hz o 60 Hz.
  • [5.8/T-SR] È FORTEMENTE 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 TV non hanno un display integrato, ma supportano un display esterno collegato tramite HDMI, devono:

  • [5.8/T-1-1] DEVE supportare HDCP 2.2.

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

  • [5.8/T-2-1] DEVE supportare HDCP 1.4

2.3.3. Software

Implementazioni dei dispositivi TV:

  • [3/T-0-1] È OBBLIGATORIO dichiarare le funzionalità android.software.leanback e android.hardware.type.television.
  • [3.2.3.1/T-0-1] DEVE precaricare una o più applicazioni o componenti di servizio con un gestore degli intent per tutti i pattern di filtro degli intent pubblici definiti dai seguenti intent di applicazione elencati qui.
  • [3.4.1/T-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.

Se le implementazioni dei dispositivi Android TV supportano una schermata di blocco,devono:

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

Implementazioni dei dispositivi TV:

  • [3.8.14/T-SR] È FORTEMENTE CONSIGLIATO supportare la modalità Picture in picture (PIP) in multi-finestra.
  • [3.10/T-0-1] DEVE supportare i servizi di accessibilità di terze parti.
  • [3.10/T-SR] È FORTEMENTE CONSIGLIATO di precaricare sul dispositivo servizi di accessibilità paragonabili o superiori alle funzionalità di Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato) come indicato nell'Android Open Source Project.

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

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

Implementazioni dei 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 costante. La latenza dei fotogrammi incoerente o un ritardo nel rendering dei fotogrammi NON DEVONO verificarsi più di 5 volte al secondo e DEVONO essere inferiori a 1 fotogramma al secondo.
  • [8.2/T-0-1] DEVE garantire prestazioni di scrittura sequenziale di almeno 5 MB/s.
  • [8.2/T-0-2] DEVE garantire un rendimento di scrittura casuale di almeno 0,5 MB/s.
  • [8.2/T-0-3] DEVE garantire un rendimento di lettura sequenziale di almeno 15 MB/s.
  • [8.2/T-0-4] DEVE garantire prestazioni di lettura casuale di almeno 3,5 MB/s.

Se le implementazioni dei dispositivi TV 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 TV non hanno una batteria:

Se le implementazioni dei dispositivi TV dispongono di una batteria:

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

Implementazioni dei dispositivi TV:

  • [8.4/T-0-1] DEVE fornire un profilo di alimentazione per componente che definisce il valore di consumo corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
  • [8.4/T-0-2] È OBBLIGATORIO segnalare tutti i valori di consumo di energia in milliampere ora (mAh).
  • [8.4/T-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID del processo. 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 di energia del componente hardware a un'applicazione.
  • [8.4/T-0-4] DEVE rendere disponibile questo consumo di energia tramite il comando a shell adb shell dumpsys batterystats per lo sviluppatore dell'app.

2.3.5. Modello di sicurezza

Implementazioni dei dispositivi TV:

  • [9.11/T-0-1] È NECESSARIO eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
  • [9.11/T-0-2] DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni hash di famiglie 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 sopra. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA. Il progetto Android Open Source (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura sottoposta a revisione da parte di terze parti di un'isolamento basato su hypervisor adeguato sono opzioni alternative.
  • [9.11/T-0-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo se l'autenticazione va a buon fine, deve consentire l'utilizzo delle chiavi legate 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 open source Android upstream fornisce l'HAL (Hardware Abstraction Layer) Gatekeeper 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 dei 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, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione delle chiavi, 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 TV 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 TV includono più utenti e non dichiarano il flag della funzionalità android.hardware.telephony:

  • [9.5/T-2-1] DEVE supportare i profili con limitazioni, una funzionalità che consente ai proprietari di dispositivi di gestire utenti aggiuntivi e le relative funzionalità sul dispositivo. Con i profili con limitazioni, i proprietari di dispositivi possono configurare rapidamente ambienti separati in cui altri utenti possono lavorare, 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 della funzionalità android.hardware.telephony:

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

2.3.6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori

Implementazioni dei dispositivi TV:

2.4. Requisiti dell'orologio

Un dispositivo Android Watch si riferisce a un'implementazione di un dispositivo Android progettata per essere indossata sul corpo, ad esempio sul polso.

Le implementazioni dei dispositivi Android sono classificate come smartwatch se soddisfano tutti i seguenti criteri:

  • Avere uno schermo con una lunghezza diagonale fisica compresa tra 28 e 64 mm.
  • Avere un meccanismo che consenta di indossarlo sul corpo.

I requisiti aggiuntivi riportati 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 2,8 e 6,35 cm.

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

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

Se le implementazioni dei dispositivi indossabili 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 rilevate, anche se una posizione calcolata da GPS/GNSS non è ancora stata segnalata.
  • [7.3.3/W-1-2] DEVE segnalare pseudorange e rate di pseudorange GNSS che, in condizioni di cielo aperto dopo aver determinato la posizione, mentre è fermo o si muove 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 dei dispositivi indossabili includono un giroscopio a 3 assi, devono:

  • [7.3.4/W-2-1] DEVE essere in grado di misurare le variazioni 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 disponibili per il kernel e lo spazio utente.

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

  • [7.8.2/W] POTREBBE avere un'uscita audio.

2.4.2. Multimediale

Nessun altro requisito.

2.4.3. Software

Guarda le implementazioni dei dispositivi:

  • [3/W-0-1] È OBBLIGATORIO dichiarare la funzionalità android.hardware.type.watch.
  • [3/W-0-2] DEVE supportare uiMode = UI_MODE_TYPE_WATCH.
  • [3.2.3.1/W-0-1] È NECESSARIO precaricare una o più applicazioni o componenti di servizio con un gestore degli intent per tutti i pattern di filtro degli intent pubblici definiti dai seguenti intent di applicazione elencati qui.

Guarda le implementazioni dei dispositivi:

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

Guarda le implementazioni dei dispositivi 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 di precaricare sul dispositivo servizi di accessibilità paragonabili o superiori alle funzionalità di Switch Access e TalkBack (per le lingue supportate dal motore di sintesi vocale preinstallato) come indicato nell'Android Open Source Project.

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

  • [3.11/W-SR] È MOLTO CONSIGLIATO includere un motore TTS che supporti le lingue disponibili sul dispositivo.

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

2.4.4. Prestazioni e potenza

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

  • [8.3/W-SR] È FORTEMENTE CONSIGLIATO fornire all'utente la possibilità di visualizzare tutte le app esenti dalle modalità di risparmio energetico App Standby e Sospensione.
  • [8.3/W-SR] È FORTEMENTE CONSIGLIATO fornire all'utente la possibilità di attivare e disattivare la funzionalità di risparmio energetico.

Guarda le implementazioni dei dispositivi:

  • [8.4/W-0-1] È NECESSARIO fornire un profilo di alimentazione per componente che definisce il valore di consumo corrente per ciascun componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
  • [8.4/W-0-2] È OBBLIGATORIO segnalare tutti i valori di consumo di energia in milliampere ora (mAh).
  • [8.4/W-0-3] È OBBLIGATORIO segnalare il consumo di energia della CPU per ogni UID del processo. 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 di energia tramite il comando di shell adb shell dumpsys batterystats per lo sviluppatore dell'app.
  • [8,4/W] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.

2.4.5. Modello di sicurezza

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

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

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

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

2.5. Requisiti per il settore auto e motori

L'implementazione di Android Automotive si riferisce a un'unità principale del veicolo con Android come sistema operativo per parte o per tutte le funzionalità del sistema e/o di infotainment.

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

  • Sono integrati in un veicolo auto e motori o possono essere collegati a un veicolo.
  • 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 dei dispositivi Android Automotive.

2.5.1. Hardware

Implementazioni di dispositivi per auto e motori:

  • [7.1.1.1/A-0-1] DEVE avere uno schermo con dimensioni fisiche diagonali di almeno 15 cm.

  • [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 all'applicazione in primo piano sia l'evento di pressione normale che quello di pressione prolungata della funzione Indietro (KEYCODE_BACK).
  • [7.3/A-0-1] È OBBLIGATORIO 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 della dashboard e DOVREBBE essere basato sull'input del sensore di luce ambientale. Il sensore di luce ambientale sottostante POTREBBE essere lo stesso di Fotometro.
  • [7.3/A-0-3] È OBBLIGATORIO fornire il campo delle informazioni aggiuntive del sensore TYPE_SENSOR_PLACEMENT all'interno di SensorAdditionalInfo per ogni sensore fornito.
  • [7.3/A-0-1] PUO' calcolare la posizione tramite triangolazione combinando il GPS/GNSS con sensori aggiuntivi. Se la posizione è basata sulla stima, è MOLTO CONSIGLIATO implementare e registrare i tipi di sensore e/o gli ID proprietà del veicolo corrispondenti utilizzati.
  • [7.3/A-0-2] La posizione richiesta tramite LocationManager#requestLocationUpdates() NON DEVE essere associata alla mappa.

Se le implementazioni dei dispositivi per auto e motori includono un accelerometro a 3 assi:

Se le implementazioni dei dispositivi per auto e motori includono un giroscopio a 3 assi:

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

Se le implementazioni dei dispositivi per auto e motori includono un ricevitore GPS/GNSS, ma non la connettività dati basata su rete mobile, devono:

  • [7.3.3/A-3-1] DEVE determinare la posizione la prima volta che il ricevitore GPS/GNSS viene acceso o dopo più di 4 giorni entro 60 secondi.
  • [7.3.3/A-3-2] DEVE soddisfare i criteri relativi al tempo di risposta iniziale descritti in 7.3.3/C-1-2 e 7.3.3/C-1-6 per tutte le altre richieste di posizione (ovvero le richieste che non sono la prima volta o dopo più di 4 giorni). Il requisito 7.3.3/C-1-2 viene generalmente soddisfatto nei veicoli senza connettività dati basata su rete mobile, utilizzando le previsioni dell'orbita GNSS calcolate sul ricevitore o utilizzando l'ultima posizione nota del veicolo insieme alla possibilità di eseguire la navigazione stimata per almeno 60 secondi con una precisione della posizione che soddisfa il requisito 7.3.3/C-1-3 o una combinazione di entrambi.

Implementazioni di dispositivi per auto e motori:

  • [7.4.3/A-0-1] DEVE supportare il Bluetooth e DOVREBBE supportare il Bluetooth LE.
  • [7.4.3/A-0-2] Le implementazioni di Android Automotive DEVONO supportare i seguenti profili Bluetooth:
    • Chiamate su rete mobile tramite il profilo Hands-Free (HFP).
    • Riproduzione di contenuti multimediali tramite il profilo Audio Distribution (A2DP).
    • Controllo della riproduzione dei contenuti multimediali tramite il profilo di controllo remoto (AVRCP).
    • Condivisione dei contatti tramite il profilo Phonebook Access (PBAP).

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

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

  • [7.4.5/A] PUO' utilizzare la costante NetworkCapabilities#NET_CAPABILITY_OEM_PAID dell'API di sistema per le emittenti che devono essere disponibili per le app di sistema.

Una videocamera per esterni è una videocamera che acquisisce immagini di scene esterne all'implementazione del dispositivo, ad esempio una dashcam.

Implementazioni di dispositivi per auto e motori:

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

Se le implementazioni dei dispositivi per auto e motori includono una videocamera per la visuale esterna, per questa videocamera:

  • [7.5/A-1-1] NON DEVONO avere fotocamere esterne 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 specchiare orizzontalmente l'anteprima della videocamera.
  • [7.5.5/A-SR] È FORTEMENTE CONSIGLIATO di orientarle in modo che la dimensione più lunga della videocamera sia allineata all'orizzonte.
  • [7.5/A-SR] È FORTEMENTE CONSIGLIATO avere una risoluzione di almeno 1,3 megapixel.
  • DEVE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
  • DEVE supportare il framework di sincronizzazione Android.
  • POTREBBE avere l'autofocus hardware o l'autofocus software implementato nel driver della fotocamera.

Implementazioni di dispositivi per auto e motori:

  • [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 sullo spazio di archiviazione flash, ad esempio utilizzando il file system f2fs.

Se le implementazioni dei dispositivi Automotive forniscono spazio di archiviazione esterno condiviso tramite una parte dello spazio di archiviazione interno non rimovibile:

  • [7.6.1/A-SR] È FORTEMENTE CONSIGLIATO di ridurre l'overhead I/O delle operazioni eseguite sulla memoria esterna, ad esempio utilizzando SDCardFS.

Se le implementazioni dei dispositivi Automotive 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 vengono utilizzate una delle seguenti densità:

    • 280 dpi o meno su schermi piccoli/normali
    • ldpi o inferiore su schermi extra large
    • 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 extra large

  • [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 di grandi dimensioni
    • tvdpi o superiore su schermi extra large

  • [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 di grandi dimensioni
    • xhdpi o superiore su schermi extra large

Se le implementazioni dei dispositivi per auto e motori 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 extra large
    • 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 extra large

  • [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 di grandi dimensioni
    • tvdpi o superiore su schermi extra large

  • [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 di grandi dimensioni
    • xhdpi o superiore su schermi extra large

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 auto e motori:

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

Implementazioni di dispositivi per auto e motori:

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

Implementazioni di dispositivi per auto e motori:

  • [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 e motori 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 (AAC a basso ritardo migliorato)

Le implementazioni dei dispositivi per auto e motori 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 dei dispositivi per auto e motori 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

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

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

2.5.3. Software

Implementazioni di dispositivi per auto e motori:

  • [3/A-0-1] DEVE dichiarare la funzionalità android.hardware.type.automotive.

  • [3/A-0-2] DEVE supportare uiMode = UI_MODE_TYPE_CAR.

  • [3/A-0-3] DEVE supportare tutte le API pubbliche nello spazio dei nomi android.car.*.

Se le implementazioni dei dispositivi per auto e motori forniscono un'API proprietaria che utilizza android.car.CarPropertyManager con android.car.VehiclePropertyIds:

  • [3/A-1-1] NON DEVE assegnare privilegi speciali all'utilizzo di queste proprietà da parte dell'applicazione di sistema o impedire alle applicazioni di terze parti di utilizzarle.
  • [3/A-1-2] NON DEVE replicare una proprietà del veicolo già esistente nell'SDK.

Implementazioni di dispositivi per auto e motori:

  • [3.2.1/A-0-1] DEVE supportare e applicare tutte le costanti di autorizzazione come documentato nella pagina di riferimento delle autorizzazioni per i veicoli.

  • [3.2.3.1/A-0-1] DEVE precaricare una o più applicazioni o componenti di servizio con un gestore degli intent per tutti i pattern di filtro degli intent pubblici definiti dai seguenti intent di applicazione elencati qui.

  • [3.4.1/A-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.

  • [3.8.3/A-0-1] DEVE mostrare notifiche che utilizzano l'API Notification.CarExtender quando richiesto da applicazioni di terze parti.

  • [3.8.4/A-SR] È vivamente consigliato implementare un assistente sul dispositivo per gestire l'azione di assistenza.

Se le implementazioni dei dispositivi per auto includono un pulsante push-to-talk, devono:

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

Implementazioni di dispositivi per auto e motori:

  • [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] DEVE mostrare PLAY e MUTE per le azioni di notifica al posto di quelle fornite tramite Notification.Builder.addAction()
  • [3.8.3.1/A] DOVREBBE limitare l'uso di attività di gestione avanzate come i controlli per canale di notifica. PUO' utilizzare l'affordance utente per applicazione per ridurre i controlli.

Implementazioni di dispositivi per auto e motori:

Se le implementazioni dei dispositivi Automotive includono un'app Avvio app predefinita:

Implementazioni di dispositivi per auto e motori:

  • [3.8/A] PUÒ limitare le richieste di applicazione per passare a una modalità a schermo intero come descritto in immersive documentation.
  • [3.8/A] PUÒ mantenere sempre visibili la barra di stato e la barra di navigazione.
  • [3.8/A] PUO' limitare le richieste di applicazione per modificare i colori dietro gli elementi dell'interfaccia utente di sistema, per garantire che questi elementi siano sempre chiaramente visibili.

2.5.4. Prestazioni e potenza

Implementazioni di dispositivi per auto e motori:

  • [8.2/A-0-1] DEVE segnalare il numero di byte letti e scritti nella memoria non volatile per l'UID di ogni 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 del kernel uid_sys_stats.
  • [8.3/A-1-3] DEVE supportare la modalità Garage.
  • [8.3/A] DOVREBBE essere in modalità Garage per almeno 15 minuti dopo ogni viaggio, a meno che:
    • La batteria è scarica.
    • Non sono pianificati job inattivi.
    • Il conducente esce dalla modalità Garage.
  • [8.4/A-0-1] DEVE fornire un profilo di alimentazione per componente che definisce il valore di consumo corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
  • [8.4/A-0-2] È obbligatorio segnalare tutti i valori di consumo di energia in milliampere ora (mAh).
  • [8.4/A-0-3] È OBBLIGATORIO segnalare il consumo di energia della CPU per ogni UID del processo. 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 di energia del componente hardware a un'applicazione.
  • [8.4/A-0-4] DEVE rendere disponibile questo consumo di energia tramite il comando di shell adb shell dumpsys batterystats per lo sviluppatore dell'app.

2.5.5. Modello di sicurezza

Se le implementazioni dei dispositivi per auto e motori supportano più utenti:

Implementazioni di dispositivi per auto e motori:

  • [9.11/A-0-1] È NECESSARIO eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
  • [9.11/A-0-2] DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni hash di famiglie 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 sopra. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA. Il progetto Android Open Source (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura sottoposta a revisione da parte di terze parti di un'isolamento basato su hypervisor adeguato sono opzioni alternative.
  • [9.11/A-0-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo se l'autenticazione va a buon fine, deve consentire l'utilizzo delle chiavi legate 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 open source Android upstream fornisce l'HAL (Hardware Abstraction Layer) Gatekeeper 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 dei 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, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione delle chiavi, a meno che non dichiari la funzionalità android.hardware.fingerprint che richiede un keystore supportato da un ambiente di esecuzione isolato.

Implementazioni di dispositivi per auto e motori:

  • [9.14/A-0-1] DEVE controllare i messaggi provenienti dai sottosistemi del veicolo del framework Android, ad esempio aggiungendo tipi di messaggi e origini dei messaggi consentiti a una lista consentita.
  • [9.14/A-0-2] È obbligatorio il monitoraggio per rilevare gli attacchi di denial of service dal framework Android o da app di terze parti. In questo modo, si evita che il software dannoso inondi la rete del veicolo con traffico, causando il malfunzionamento dei sottosistemi del veicolo.

2.5.6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori

Implementazioni di dispositivi per auto e motori:

2.6. Requisiti del tablet

Un dispositivo tablet Android si riferisce a un'implementazione di un dispositivo Android che in genere soddisfa tutti i seguenti criteri:

  • Da tenere con entrambe le mani.
  • Non ha una configurazione a conchiglia o convertibile.
  • Le implementazioni di tastiere fisiche utilizzate con il dispositivo si connettono tramite una connessione standard (ad es. USB, Bluetooth).
  • Ha una fonte di alimentazione che offre mobilità, ad esempio una batteria.
  • Ha una dimensione dello schermo in diagonale fisica compresa tra 18 e 45 cm.

Le implementazioni dei tablet hanno requisiti simili a quelli dei dispositivi palmari. Le eccezioni sono indicate da un asterisco nella sezione in questione e 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 18 e 45 cm.

Giroscopio

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

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

Memoria e spazio di archiviazione minimi (sezione 7.6.1)

Le densità dello schermo elencate per 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, devono:

  • [7.7.1/scheda] PUO' implementare l'API Android Open Accessory (AOA).

Modalità Realtà virtuale (sezione 7.9.1)

Realtà virtuale ad alte prestazioni (sezione 7.9.2)

I requisiti per la 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 della funzionalità android.hardware.telephony:

  • [9.5/T-1-1] DEVE supportare i profili con limitazioni, una funzionalità che consente ai proprietari di dispositivi di gestire utenti aggiuntivi e le relative funzionalità sul dispositivo. Con i profili con limitazioni, i proprietari di dispositivi possono configurare rapidamente ambienti separati in cui altri utenti possono lavorare, 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 della funzionalità android.hardware.telephony:

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

2.6.2. Software

  • [3.2.3.1/Tab-0-1] DEVE precaricare una o più applicazioni o componenti di servizio con un gestore degli intent per tutti i pattern di filtro degli intent pubblici definiti dai seguenti intent di applicazione elencati qui.

3. Software

3.1. Compatibilità con le API gestite

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

Implementazioni dei dispositivi:

  • [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 l'indicatore "@SystemApi" nel codice sorgente di Android upstream.

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

  • [C-0-3] NON DEVE omettere API gestite, modificare interfacce o firme dell'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 alcune funzionalità hardware per le quali Android include API vengono omesse. Consulta la sezione 7 per i requisiti specifici di questo scenario.

  • [C-0-5] NON DEVE consentire alle app di terze parti di utilizzare interfacce non SDK, definite come metodi e campi nei pacchetti di linguaggi Java presenti nel percorso di classe di avvio 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 nella documentazione dell'SDK e i membri di classe privati e privati del pacchetto.

  • [C-0-6] DEVE essere fornito con ogni interfaccia non SDK negli stessi elenchi con limitazioni forniti tramite i flag provvisori e della lista negativa nel percorso prebuilts/runtime/appcompat/hiddenapi-flags.csv per il ramo del livello API appropriato in AOSP.

  • [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 presenti in AOSP.

    Tuttavia:

    • Può essere che, se un'API nascosta non è presente o è implementata in modo diverso nell'implementazione del dispositivo, l'API nascosta venga spostata nella lista negativa o omessa da tutti gli elenchi con limitazioni (ovvero grigio chiaro, grigio scuro e nero).
    • Può, se un'API nascosta non esiste già in AOSP, aggiungere l'API nascosta a uno degli elenchi con limitazioni (grigio chiaro, grigio scuro, nero).

3.1.1. Estensioni Android

Android supporta l'estensione dell'interfaccia API gestita di un determinato livello API aggiornando la versione dell'estensione per quel livello API. L'API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) restituisce la versione dell'estensione del apiLevel fornito, se sono presenti estensioni per quel livello API.

Implementazioni dei dispositivi Android:

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

  • [C-0-2] DEVE restituire solo il numero di versione dell'estensione valido definito dall'AOSP.

  • [C-0-3] DEVE supportare tutte le API definite dalle versioni dell'estensione restituite da android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) nello stesso modo in cui sono supportate le altre API gestite, seguendo i requisiti della sezione 3.1.

3.1.2. Libreria Android

A causa del ritiro del client HTTP Apache, le implementazioni dei dispositivi:

  • [C-0-1] NON DEVE inserire la libreria org.apache.http.legacy nel bootclasspath.
  • [C-0-2] È NECESSARIO aggiungere la libreria org.apache.http.legacy al percorso di classe dell'applicazione solo quando l'app soddisfa una delle seguenti condizioni:
    • Hanno come target il livello API 28 o versioni precedenti.
    • Dichiara nel manifest di aver 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 di runtime, sotto forma di intent, autorizzazioni e aspetti simili delle applicazioni Android che non possono essere applicati al momento della compilazione dell'applicazione.

3.2.1. Autorizzazioni

  • [C-0-1] Gli implementatori dei 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 compilazione

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 per tutte le implementazioni dei dispositivi, la tabella seguente include ulteriori limitazioni relative ai formati di questi valori a cui le implementazioni dei dispositivi DEVONO essere conformi.
Parametro Dettagli
VERSION.RELEASE La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE avere uno dei valori di stringa definiti in 11.
VERSION.SDK La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 11, questo campo DEVE avere il valore intero 11_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 11, questo campo DEVE avere il valore intero 11_INT.
VERSION.INCREMENTAL Un valore scelto dall'implementatore del dispositivo che designa 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 della 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, come noto agli utenti finali. DEVE essere in un formato leggibile e DEVE 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 dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
SUPPORTED_32_BIT_ABIS Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
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à con le API native.
CPU_ABI Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
CPU_ABI2 Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
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 il 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 la vita utile del prodotto.
FINGERPRINT Una stringa che identifica in modo univoco questa build. DOVREBBE essere ragionevolmente leggibile da una persona. DEVE seguire questo modello:

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

Ad esempio:

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

L'impronta NON DEVE includere caratteri di spazio vuoto. 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). DOVREBBE essere ragionevolmente leggibile da una persona. 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 eseguita la compilazione, in formato leggibile. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
ID Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una versione specifica, in un formato leggibile da una persona. Questo campo può essere uguale ad android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere 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 La ragione sociale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto 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 per il fatto 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 specifico (SKU) 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.
SERIALE DEVE restituire "UNKNOWN".
TAG Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che distingue 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 della piattaforma Android: release-keys, dev-keys e test-keys.
DURATA Un valore che rappresenta il timestamp della compilazione.
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 di runtime Android tipiche: user, userdebug o eng.
UTENTE Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
VERSION.SECURITY_PATCH Un valore che indica il livello della patch di sicurezza di una build. DEBBA 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] e corrispondere a una stringa definita documentata nel Bollettino pubblico sulla sicurezza di Android o nell'Avviso sulla sicurezza di Android, ad esempio "2015-11-01".
VERSION.BASE_OS Un valore che rappresenta il parametro FINGERPRINT della build, che è altrimenti identico a questa build, ad eccezione delle patch fornite nel bollettino Android Public Security. DEVE riportare il valore corretto e, se una build di questo tipo non esiste, deve riportare 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 interna utilizzata nel dispositivo, in formato leggibile. Se un dispositivo non ha radio/modem interni, 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à con gli intent

3.2.3.1. Intent comuni per le applicazioni

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

Implementazioni dei dispositivi:

  • [C-SR] È FORTEMENTE CONSIGLIATO di precaricare una o più applicazioni o componenti di servizio con un gestore degli intent per tutti i pattern di filtro degli intent pubblici definiti dai seguenti intent di applicazione elencati qui e fornire il completamento, ovvero soddisfare le aspettative degli sviluppatori per questi intent di applicazione comuni come descritto nell'SDK.

Consulta la Sezione 2 per gli intent di applicazione obbligatori per ciascun tipo di dispositivo.

3.2.3.2. Risoluzione dell'intent

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

  • [C-0-2] Gli implementatori dei dispositivi NON DEVONO assegnare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema o impedire alle applicazioni di terze parti di associarsi a questi pattern e assumerne il controllo. Questo divieto include, in particolare, 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 che consenta agli utenti di modificare l'attività predefinita per gli intent.

  • Tuttavia, le implementazioni dei dispositivi 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 dati. Ad esempio, un pattern del 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 per consentire 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 filtro intent di un'app, le implementazioni dei dispositivi:

  • [C-0-4] DEVE tentare di convalidare tutti i filtri per intent eseguendo i passaggi di convalida definiti nella specifica Digital Asset Links, come implementato dal gestore pacchetti nel progetto open source Android 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.
  • PUO' 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 un'implementazione del dispositivo esegue questa operazione, DEVE fornire all'utente le sostituzioni dei pattern per URI appropriate nel menu delle impostazioni.
  • DEVE fornire all'utente i controlli dei link dell'app per app nelle Impostazioni come segue:
    • [C-0-6] L'utente DEVE essere in grado di sostituire in modo olistico il comportamento predefinito dei link alle app in modo che un'app sia: sempre aperta, sempre chiedi o mai aperta, che deve essere applicato allo stesso modo a tutti i filtri di intent URI candidati.
    • [C-0-7] L'utente DEVE essere in grado di visualizzare un elenco dei filtri di intent URI candidati.
    • L'implementazione del dispositivo PUÒ fornire all'utente la possibilità di ignorare filtri di intent URI candidati specifici che sono stati verificati correttamente, in base al filtro di intent.
    • [C-0-8] L'implementazione del dispositivo DEVE fornire agli utenti la possibilità di visualizzare e sostituire filtri di intent URI candidati specifici se l'implementazione del dispositivo consente a alcuni filtri di intent URI candidati di superare la verifica, mentre altri possono non riuscirci.
3.2.3.3. Spazi dei nomi degli intent
  • [C-0-1] Le implementazioni dei dispositivi NON DEVONO includere componenti Android che supportano 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 supportano nuovi pattern di intent o intent di trasmissione utilizzando un'azione, una CATEGORY o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione.
  • [C-0-3] Gli implementatori dei dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent elencati nella sezione 3.2.3.1.
  • Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano spazi dei nomi chiaramente e inequivocabilmente associati alla propria organizzazione. Questo divieto è analogo a quello specificato per i corsi di lingua 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 al fine di essere avvisate delle modifiche nell'ambiente hardware o software.

Implementazioni dei dispositivi:

  • [C-0-1] DEVE trasmettere gli intent di trasmissione pubblica elencati qui in risposta a eventi di sistema appropriati, come descritto nella documentazione dell'SDK. Tieni presente che questo requisito non è in conflitto con la sezione 3.5, poiché la limitazione per le applicazioni in background è descritta anche nella documentazione dell'SDK. Inoltre, alcuni intent di trasmissione sono condizionati dal supporto hardware. Se il dispositivo supporta l'hardware necessario, DEVE trasmettere gli intent e fornire il comportamento in linea con la documentazione dell'SDK.
3.2.3.5. Intent di applicazione condizionali

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 dei dispositivi DEVONO fornire un menu delle impostazioni simile ed essere compatibili con il pattern del filtro 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:

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

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

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

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

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

  • [C-6-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 dei criteri di modalità Non disturbare.

Se le implementazioni del dispositivo consentono agli utenti di utilizzare metodi di immissione di terze parti sul dispositivo, questi:

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

  • [C-8-1] DEVE rispettare l'intento di android.settings.ACCESSIBILITY_SETTINGS di fornire un meccanismo accessibile agli utenti per attivare e disattivare i servizi di accessibilità di terze parti insieme a quelli preinstallati.

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Easy Connect e mettono a disposizione la funzionalità per le app di terze parti, devono:

Se le implementazioni del dispositivo forniscono la modalità di risparmio dati: * [C-10-1] DEVONO fornire un'interfaccia utente nelle impostazioni che gestisce l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, consentendo agli utenti di aggiungere applicazioni alla lista consentita o rimuoverle.

Se le implementazioni dei dispositivi non forniscono la modalità Risparmio dati, devono:

Se le implementazioni dei dispositivi dichiarano il supporto della videocamera tramite android.hardware.camera.any:

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

Se le implementazioni del dispositivo dichiarano il flag della funzionalità android.software.autofill:

Se le implementazioni dei dispositivi includono un'app preinstallata o vogliono consentire alle app di terze parti di accedere alle statistiche di utilizzo, devono:

  • [C-SR] È FORTEMENTE CONSIGLIATO fornire un meccanismo accessibile agli utenti per concedere o revocare l'accesso alle statistiche di 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 non vogliono consentire ad alcuna app, incluse quelle preinstallate, di accedere alle statistiche di utilizzo, devono:

  • [C-15-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 quello che si verifica quando l'utente viene rifiutato per l'accesso.

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

  • [C-SR] È vivamente consigliato rispettare gli intent android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA e android.speech.tts.engine.GET_SAMPLE_TEXT e avere un'attività per fornire l'adempimento di questi intent come descritto nell'SDK qui.

Android include il supporto per i salvaschermo interattivi, precedentemente noti come Sogni. I salvaschermo consentono agli utenti di interagire con le applicazioni quando un dispositivo collegato a una fonte di alimentazione è inattivo o agganciato alla base di ricarica. Implementazioni del dispositivo:

  • DOVREBBE includere il supporto dei salvaschermo e fornire un'opzione di impostazioni per consentire agli utenti di configurare i salvaschermo in risposta all'intent android.settings.DREAM_SETTINGS.

3.2.4. Attività su display secondari/multipli

Se le implementazioni dei dispositivi consentono di avviare normali attività Android su più di un display, devono:

  • [C-1-1] È NECESSARIO impostare il flag funzionalità android.software.activities_on_secondary_displays.
  • [C-1-2] DEVE garantire la compatibilità con le API simile a quella di un'attività in esecuzione sul display principale.
  • [C-1-3] DEVE mostrare la nuova attività sulla stessa visualizzazione dell'attività che l'ha lanciata, quando la nuova attività viene lanciata senza specificare una visualizzazione target 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 decida di essere visualizzata sopra la schermata di blocco utilizzando l'API Activity#setShowWhenLocked().
  • DEVE avere android.content.res.Configuration che corrisponde a quel display per essere visualizzato, funzionare correttamente e mantenere la compatibilità se un'attività viene avviata sul display secondario.

Se le implementazioni del dispositivo consentono di avviare normali attività Android sui 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. Chiunque può avviare un'app su un display con il flag android.view.Display.FLAG_PUBLIC.

3.3. Compatibilità con le API native

La compatibilità con il codice nativo è complessa. Per questo motivo, gli implementatori di dispositivi sono:

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

3.3.1. Application Binary Interface

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 è altamente dipendente dalla tecnologia del processore sottostante, Android definisce una serie di interfacce a livello di codice macchina (ABI) nell'Android NDK.

Implementazioni dei dispositivi:

  • [C-0-1] DEVE essere compatibile con una o più ABI Android NDK definite.
  • [C-0-2] DEVE includere il supporto 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 con il codice sorgente (ovvero con gli header) e con il codice binario (per l'ABI) di ogni libreria richiesta nell'elenco 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, ciascuno un elenco di ABI separati da virgola ordinati dal più preferito al meno preferito.

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

  • [C-0-7] DEVE rendere disponibili per le 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 è dichiarata come descritto nella Sezione 5.9)
    • libandroid.so (supporto delle attività native di Android)
    • libc (libreria C)
    • libcamera2ndk.so
    • libdl (linker dinamico)
    • libEGL.so (gestione delle superfici OpenGL native)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (logging Android)
    • libmediandk.so (supporto delle API multimediali 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] È OBBLIGATORIO 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] È OBBLIGATORIO esportare tutti i simboli delle funzioni OpenGL ES 3.1 e del pacchetto di estensioni Android, come definiti in NDK, tramite la libreria libGLESv3.so. Tieni presente che, anche se tutti i simboli DEVONO essere presenti, la sezione 7.1.4.1 descrive in modo più dettagliato i requisiti per l'implementazione completa di ogni funzione corrispondente.
  • [C-0-12] È OBBLIGATORIO esportare i simboli delle funzioni per i simboli delle funzioni di base di Vulkan 1.0, nonché le estensioni VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 tramite la libreria libvulkan.so. Tieni presente che, anche se tutti i simboli DEVONO essere presenti, la sezione 7.1.4.2 descrive in modo più dettagliato i requisiti per l'implementazione completa di ogni funzione corrispondente.
  • DEVE essere compilato 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 di ABI aggiuntive.

3.3.2. Compatibilità con il 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 segnalarne il supporto, in quanto armeabi-v7a è solo per la compatibilità con le versioni precedenti delle app.armeabi

Se le implementazioni del dispositivo 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 altri ABI.

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

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

    • Istruzioni per SWP e SWPB.
    • Istruzione SETEND.
    • Operazioni di barriere 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à con WebView

Se le implementazioni dei dispositivi forniscono un'implementazione completa dell'API android.webkit.Webview:

  • [C-1-1] È obbligatorio segnalare android.software.webview.
  • [C-1-2] È OBBLIGATORIO utilizzare la build del progetto Chromium dal progetto open source Android upstream sul ramo Android 11 per l'implementazione dell'API android.webkit.WebView.

  • [C-1-3] La stringa dello user agent segnalata da WebView DEVE avere il seguente formato:

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, come Gecko) Versione/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 è vuota 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 del maggior numero possibile di funzionalità HTML5 e, se supporta la funzionalità, DEVE essere conforme alla specifica HTML5.

  • [C-1-3] DEVE eseguire il rendering dei contenuti forniti o dei contenuti dell'URL remoto in un processo distinto dall'applicazione che esegue l'istanza di WebView. Nello specifico, il processo del renderer separato DEVE avere un privilegio inferiore, 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 di WebView in AOSP soddisfa questo requisito.

Tieni presente che se le implementazioni dei dispositivi sono a 32 bit o dichiarano il flag della 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, devono:

  • [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 per lo sviluppo web stanno adottando IndexedDB al posto di webstorage, IndexedDB dovrebbe diventare un componente obbligatorio in una versione futura di Android.
  • PUÒ includere una stringa user agent personalizzata nell'applicazione Browser autonoma.
  • DOVREBBE implementare il supporto per il maggior numero possibile di funzionalità di HTML5 nell'applicazione Browser autonoma (in base all'applicazione Browser WebKit a monte o a un sostituto di terze parti).

Tuttavia, se le implementazioni dei dispositivi non includono un'applicazione browser autonoma, queste:

  • [C-2-1] DEVE comunque supportare i pattern di intenti pubblici come descritto nella sezione 3.2.3.1.

3.5. Compatibilità comportamentale dell'API

Implementazioni dei dispositivi:

  • [C-0-9] DEVE garantire che la compatibilità comportamentale dell'API venga applicata a tutte le app installate, a meno che non siano limitate come descritto nella Sezione 3.5.1.
  • [C-0-10] NON DEVE implementare l'approccio della lista consentita che garantisce la compatibilità del comportamento dell'API solo per le app selezionate dagli implementatori del dispositivo.

I comportamenti di ciascuno dei tipi di API (gestite, soft, native e web) devono essere coerenti con l'implementazione preferita del progetto Android Open Source a monte. Ecco alcune aree specifiche di compatibilità:

  • [C-0-1] I dispositivi NON DEVONO modificare il comportamento o la semantica di uno scopo standard.
  • [C-0-2] I dispositivi NON DEVONO alterare il ciclo di vita o la semantica del ciclo di vita di un determinato 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 modificare le limitazioni applicate alle applicazioni in background. Più nello specifico, per le app in background:
    • [C-0-4] DEVONO 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 broadcast receiver per le emissioni implicite degli intent Android standard nel file manifest dell'app, a meno che l'intent di trasmissione non richieda un'autorizzazione "signature" o "signatureOrSystem" protectionLevel o non sia presente nell'elenco delle esenzioni.
    • [C-0-7] Se l'app ha come target il livello API 25 o versioni successive, DEVE interrompere i servizi in background dell'app, proprio come se l'app avesse chiamato il metodo stopSelf() dei servizi, a meno che l'app non sia inserita in una lista consentita temporanea 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 detenuti dall'app.
  • [C-0-9] I dispositivi DEVONO restituire i seguenti fornitori di sicurezza come primi sette valori dell'array del metodo Security.getProviders(), nell'ordine specificato e con i nomi e le classi specificati (come restituiti da Provider.getName()), a meno che l'app non abbia modificato l'elenco tramite insertProviderAt() o removeProvider(). I dispositivi POSSONO restituire fornitori aggiuntivi dopo l'elenco di fornitori specificato 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 Compatibility Test Suite (CTS) testa parti significative della piattaforma per verificarne la compatibilità comportamentale, ma non tutte. È responsabilità dell'implementatore garantire la compatibilità del comportamento con il progetto open source Android. Per questo motivo, gli implementatori di dispositivi DOVREBBERO utilizzare il codice sorgente disponibile tramite l'Android Open Source Project, ove possibile, anziché implementare nuovamente parti significative del sistema.

3.5.1. Limitazione delle applicazioni

Se le implementazioni dei dispositivi implementano un meccanismo proprietario per limitare le app e questo meccanismo è più restrittivo del bucket di app in standby rare, devono:

  • [C-1-1] DEVE fornire all'utente la possibilità di 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 restrizioni senza prove di un comportamento di salute del sistema scadente, ma PUÒ applicare le restrizioni alle app al rilevamento di un comportamento di salute del sistema scadente, come wakelock bloccati, servizi a lungo termine 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 strettamente 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 per le 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. Queste informazioni DEVONO essere fornite entro 24 ore dall'applicazione delle limitazioni.
  • [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] È OBBLIGATORIO sospendere le limitazioni su un'app che diventa l'applicazione in primo piano quando l'utente inizia a utilizzare esplicitamente l'app che era soggetta a limitazioni.

3.6. Spazi dei nomi API

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

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

In altre parole:

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

Gli implementatori dei dispositivi POSSONO modificare l'implementazione sottostante delle API, ma queste 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 dei 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 al namespace com.google.* o a uno simile: solo Google può farlo. Analogamente, Google NON DEVE aggiungere API ai namespace di altre aziende.
  • [C-0-6] DEVE essere pacchettizzato 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 del pacchetto sopra indicati (ad esempio aggiungendo nuove funzionalità utili a un'API esistente o aggiungendo una nuova API), l'implementatore DEVE visitare il sito source.android.com e iniziare la procedura per apportare modifiche e codice, in base alle informazioni riportate sul sito.

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

3.7. Compatibilità con il runtime

Implementazioni dei dispositivi:

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

  • [C-0-2] È NECESSARIO configurare i runtime Dalvik per allocare la memoria in conformità con la piattaforma Android upstream e come specificato dalla tabella seguente. (consulta la sezione 7.1.1 per le definizioni delle dimensioni e della densità dello schermo).

  • DEBBA 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 di fuzz 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 POTREBBERO allocare più memoria per applicazione.

Layout dello 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 (400dpi) 56MB
420 dpi (420dpi) 64MB
480 dpi (xxhdpi) 88MB
560 dpi (560dpi) 112MB
640 dpi (xxxhdpi) 154MB
piccolo/normale 120 dpi (ldpi) 32MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi) 48MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 80MB
360 dpi (360dpi)
400 dpi (400dpi) 96MB
420 dpi (420dpi) 112MB
480 dpi (xxhdpi) 128MB
560 dpi (560dpi) 192MB
640 dpi (xxxhdpi) 256MB
grande 120 dpi (ldpi) 32MB
140 dpi (140dpi) 48MB
160 dpi (mdpi)
180 dpi (180dpi) 80MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 96MB
320 dpi (xhdpi) 128MB
360 dpi (360dpi) 160MB
400 dpi (400dpi) 192MB
420 dpi (420dpi) 228MB
480 dpi (xxhdpi) 256MB
560 dpi (560dpi) 384MB
640 dpi (xxxhdpi) 512MB
xlarge 120 dpi (ldpi) 48MB
140 dpi (140dpi) 80MB
160 dpi (mdpi)
180 dpi (180dpi) 96MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 144MB
320 dpi (xhdpi) 192MB
360 dpi (360dpi) 240MB
400 dpi (400dpi) 288MB
420 dpi (420dpi) 336MB
480 dpi (xxhdpi) 384MB
560 dpi (560dpi) 576MB
640 dpi (xxxhdpi) 768MB

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

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

Se le implementazioni del dispositivo consentono ad applicazioni di terze parti di sostituire la schermata Home del dispositivo, queste:

  • [C-1-1] È OBBLIGATORIO 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 del dispositivo includono un Avvio app predefinito che supporta il bloccaggio delle scorciatoie in-app, devono:

Al contrario, se le implementazioni dei dispositivi non supportano il bloccaggio delle scorciatoie all'interno dell'app:

Se le implementazioni del dispositivo implementano un Avvio app predefinito che fornisce un accesso rapido alle scorciatoie aggiuntive fornite dalle app di terze parti tramite l'API ShortcutManager, devono:

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

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

  • [C-5-1] DEVE rispettare il metodo dell'API NotificationChannel.setShowBadge(). In altre parole, mostra un'affordance visiva associata all'icona dell'app se il valore è impostato su true e non mostrare alcun schema di badge per l'icona dell'app quando tutti i canali di notifica dell'app hanno impostato il valore su true.false
  • PUÒ 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 DEVE utilizzare le risorse e i valori forniti tramite le API dei badge di notifica descritte nell'SDK , come le API Notification.Builder.setNumber() e Notification.Builder.setBadgeIconType().

3.8.2. Widget

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

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

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

Se le implementazioni dei dispositivi supportano i widget di app di terze parti e il fissaggio delle scorciatoie all'interno dell'app, devono:

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. suoni, vibrazioni e luce) e le funzionalità software (ad es. barra 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 inviare notifiche agli utenti su eventi importanti, queste:

  • [C-1-1] DEVE supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK, e, nella misura del 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 l'implementazione di un dispositivo non dispone di hardware, le API corrispondenti DEVONO essere implementate come no-op. Questo comportamento è descritto in maggiore dettaglio nella sezione 7.
  • [C-1-2] DEVE eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) previste nelle API o nella guida allo stile delle icone della barra di stato/sistema, anche se PUÒ offrire 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 all'utente la possibilità di bloccare e modificare la notifica di una determinata app di terze parti per ogni livello di canale e pacchetto di app.
  • [C-1-6] DEVE anche fornire un'affordance all'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 ulteriore interazione 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] È FORTEMENTE CONSIGLIATO mostrare automaticamente un'opzione per consentire all'utente di bloccare la notifica di una determinata app di terze parti per ogni canale e livello del pacchetto di app dopo che l'utente ha ignorato la notifica più volte.
  • DOVREBBE supportare le notifiche avanzate.
  • DOVREBBE presentare alcune notifiche con priorità più elevata come notifiche in evidenza.
  • DOVREBBE avere un'affordance per consentire all'utente di posticipare le notifiche.
  • POTREBBE gestire solo la visibilità e la tempistica in cui le app di terze parti possono inviare notifiche agli utenti di eventi importanti per ridurre i problemi di sicurezza, come la distrazione del conducente.

Android 11 introduce il supporto per le notifiche di conversazione, ovvero notifiche che utilizzano MessagingStyle e forniscono un ID scorciatoia Persone pubblicato.

Implementazioni dei dispositivi:

  • [C-SR] È MOLTO CONSIGLIATO raggruppare e visualizzare conversation notifications prima delle notifiche non di conversazione, ad eccezione delle notifiche dei servizi in primo piano in esecuzione e delle notifiche importance:high.

Se le implementazioni dei dispositivi supportano conversation notifications e l'app fornisce i dati richiesti per bubbles:

  • [C-SR] È MOLTO CONSIGLIATO mostrare questa conversazione come una bolla. L'implementazione AOSP soddisfa questi requisiti con la UI di sistema, le Impostazioni e Avvio predefiniti.

Se le implementazioni dei dispositivi supportano le notifiche avanzate:

  • [C-2-1] DEVI utilizzare le risorse esatte come fornite tramite la classe API Notification.Style e i relativi sottoclassi per gli elementi della risorsa presentati.
  • DEVE presentare tutti gli elementi della risorsa (ad es. icona, titolo e testo di riepilogo) definiti nella classe API Notification.Style e nei relativi sottoclassi.

Se le implementazioni dei dispositivi supportano le notifiche in primo piano:

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

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

Implementazioni dei dispositivi:

  • [C-0-1] DEVE aggiornare correttamente e tempestivamente le notifiche nella loro interezza in tutti i servizi di ascolto installati e abilitati dall'utente, inclusi tutti i metadati associati all'oggetto Notification.
  • [C-0-2] DEVE rispettare la chiamata all'API snoozeNotification(), ignorare la notifica ed eseguire un callback dopo la durata del posticipo impostata nella chiamata all'API.

Se le implementazioni del dispositivo offrono all'utente la possibilità di posticipare le notifiche, devono:

  • [C-1-1] DEVE riflettere correttamente lo stato della notifica posticipata tramite le API standard come NotificationListenerService.getSnoozedNotifications().
  • [C-1-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 (Non disturbare)

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

  • [C-1-1] DEVE, quando l'implementazione del dispositivo ha fornito all'utente un mezzo per concedere o negare alle app di terze parti l'accesso alla configurazione delle norme della modalità Non disturbare, mostrare le regole automatiche della modalità Non disturbare create dalle applicazioni insieme alle regole predefinite e create dall'utente.
  • [C-1-3] DEVE rispettare i valori suppressedVisualEffects trasmessi tramite NotificationManager.Policy e, se un'app ha impostato uno dei flag SUPPRESSED_EFFECT_SCREEN_OFF o SUPPRESSED_EFFECT_SCREEN_ON, DEVE indicare all'utente che gli effetti visivi sono soppressi nel menu delle impostazioni della modalità Non disturbare.

Android include API che consentono agli sviluppatori di incorporare la ricerca nelle loro applicazioni ed esporre i dati delle applicazioni nella ricerca di sistema globale. In generale, questa funzionalità consiste in un'unica interfaccia utente a livello di sistema che consente agli utenti di inserire query, visualizzare suggerimenti man mano che digitano e visualizzare i risultati. Le API Android consentono agli sviluppatori di riutilizzare questa interfaccia per fornire la ricerca all'interno delle proprie app e di fornire risultati all'interfaccia utente della ricerca globale comune.

  • Le implementazioni dei dispositivi Android DEVONO includere la ricerca globale, un'interfaccia utente di ricerca singola, condivisa e 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 di risultati e suggerimenti del motore di ricerca web.

Android include anche le API Assist per consentire alle applicazioni di scegliere quante informazioni del contesto corrente devono essere condivise con l'assistente sul dispositivo.

Se le implementazioni dei dispositivi supportano l'azione di assistenza, devono:

  • [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 del progetto open source Android.
    • Per l'app di assistenza preinstallata, fornire all'utente un'affordance a meno di due navigazioni dal menu delle impostazioni dell'app di assistenza e dell'input vocale predefinito e condividere il contesto solo quando l'app di assistenza viene invocata esplicitamente dall'utente tramite una hotword o l'input della chiave di navigazione dell'assistente.
  • [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 popup

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 l'API di tipo di finestra TYPE_APPLICATION_OVERLAY per visualizzare finestre di avviso come overlay su altre app.

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

  • [C-1-1] DEVE fornire all'utente la possibilità di bloccare la visualizzazione di finestre di avviso che utilizzano TYPE_APPLICATION_OVERLAY . L'implementazione AOSP soddisfa questo requisito grazie ai controlli nella barra delle notifiche.

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

3.8.6. Temi

Android fornisce i "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 il look and feel del tema Holo come definito dall'SDK Android.

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

  • [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 le relative risorse esposte alle applicazioni.
  • [C-1-3] È obbligatorio impostare la famiglia di caratteri "sans-serif" su Roboto versione 2.x per le lingue supportate da Roboto oppure fornire all'utente la possibilità di modificare il carattere utilizzato per la famiglia di caratteri "sans-serif" su Roboto versione 2.x per le lingue supportate da Roboto.

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 con barre di sistema traslucide, che consente agli sviluppatori di applicazioni di riempire l'area dietro la barra di stato e di navigazione con i contenuti delle app. Per consentire un'esperienza utente coerente in questa configurazione, è importante che lo stile dell'icona della barra di stato venga mantenuto nelle diverse implementazioni del dispositivo.

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

  • [C-2-1] È obbligatorio utilizzare il bianco per le icone di stato del sistema (ad esempio l'intensità del segnale e il livello della batteria) e le notifiche emesse dal sistema, a meno che l'icona non indichi uno stato problematico o un'app richieda una barra di stato chiara utilizzando il flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
  • [C-2-2] Le implementazioni dei dispositivi Android DEVONO impostare il colore delle icone di stato di sistema su nero (per maggiori dettagli, fai riferimento a 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 uno o più "Sfondi animati" all'utente finale. Gli sfondi animati sono animazioni, motivi o immagini simili con funzionalità di input limitate che vengono visualizzate 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 alla funzionalità, a una frequenza fotogrammi ragionevole senza effetti negativi su altre applicazioni. Se le limitazioni dell'hardware causano arresti anomali di sfondi e/o applicazioni, malfunzionamenti, consumo eccessivo di CPU o batteria o l'esecuzione a frequenze fotogrammi inaccettabilmente basse, l'hardware è considerato incapace di eseguire sfondi animati. Ad esempio, alcuni sfondi animati potrebbero utilizzare un contesto OpenGL 2.0 o 3.x per eseguire il rendering dei contenuti. La funzionalità Sfondo animato non funziona in modo affidabile su hardware che non supporta più contesti OpenGL perché l'utilizzo di un contesto OpenGL da parte della funzionalità Sfondo animato potrebbe entrare in conflitto con altre applicazioni che utilizzano anche un contesto OpenGL.

  • Le implementazioni dei dispositivi in grado di eseguire sfondi animati in modo affidabile come descritto sopra DOVREBBERO implementare gli sfondi animati.

Se le implementazioni dei dispositivi implementano sfondi animati:

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

3.8.8. Cambio attività

Il codice sorgente di Android upstream include la schermata di panoramica, un'interfaccia utente a livello di sistema per il passaggio da un'attività all'altra e la visualizzazione delle attività e delle attività a cui è stato eseguito l'accesso di recente utilizzando un'immagine in miniatura dello stato grafico dell'applicazione al momento in cui l'utente ha chiuso l'applicazione per l'ultima volta.

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

Se le implementazioni del dispositivo, inclusa la chiave di navigazione della funzione Recenti descritta nella sezione 7.2.3, modificano l'interfaccia:

  • [C-1-1] DEVE supportare almeno 7 attività visualizzate.
  • DEVE mostrare almeno il titolo di 4 attività alla volta.
  • [C-1-2] DEVE implementare il comportamento di blocco dello 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 tra le app recenti.
  • DOVREBBE mostrare un'affordance di chiusura ("x"), ma PUÒ ritardare questa azione finché l'utente non interagisce con le schermate.
  • DOVREBBE implementare una scorciatoia per passare facilmente all'attività precedente.
  • DOVREBBE attivare l'azione di passaggio rapido tra le due app utilizzate più di recente, quando il tasto funzione Recenti viene toccato due volte.
  • DOVREBBE attivare la modalità multifinestra con schermo diviso, se supportata, quando la chiave delle funzioni recenti viene premuta a lungo.
  • POTREBBE mostrare i contenuti recenti affiliati come un gruppo che si sposta insieme.
  • [SR] È FORTEMENTE CONSIGLIATO di utilizzare l'interfaccia utente Android a monte (o un'interfaccia basata su miniature simile) per la schermata Panoramica.

3.8.9. Gestione dell'input

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

Se le implementazioni del dispositivo consentono agli utenti di utilizzare metodi di immissione di terze parti sul dispositivo, questi:

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

3.8.10. Controllo dei contenuti multimediali nella schermata di blocco

L'API Remote Control Client è deprecata in 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 (in precedenza Sogni)

Consulta la sezione 3.2.3.5 per le impostazioni di intent per configurare gli screensaver.

3.8.12. Posizione

Se le implementazioni dei dispositivi 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 dei caratteri emoji definiti in Unicode 10.0.

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

  • [C-1-1] DEVE essere in grado di visualizzare questi caratteri emoji in un glifo a colori.
  • [C-1-2] DEVE includere il supporto per:
    • Carattere Roboto 2 con diversi spessori: 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 latino, greco e cirillico, inclusi gli intervalli latini estesi A, B, C e D e tutti i glifi nel blocco dei simboli di valuta di Unicode 7.0.
  • DOVREBBE supportare la tonalità della pelle e le diverse emoji di famiglia come specificato nel report tecnico Unicode n. 51.

Se le implementazioni del dispositivo includono un IME, devono:

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

Android include il supporto per il rendering dei caratteri birmani. In Myanmar esistono diversi caratteri non conformi allo standard Unicode, comunemente noti come "Zawgyi", per il rendering delle lingue birmane.

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 hanno la capacità di mostrare più attività contemporaneamente:

  • [C-1-1] DEVE implementare queste modalità multi-finestra in conformità con i comportamenti e le API dell'applicazione descritti nella documentazione di 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à schermo diviso o a forma libera 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 dei dispositivi con dimensioni dello schermo xlarge DEVONO supportare la modalità a forma libera.

Se le implementazioni del dispositivo supportano le modalità multi-finestra e la modalità schermo diviso:

  • [C-2-1] È obbligatorio precaricare un Avvio app redimensionabile come predefinito.
  • [C-2-2] DEVE ritagliare l'attività agganciata di una finestra multipla a schermo diviso, ma DEVE mostrare alcuni contenuti, se l'app Avvio app è la finestra attiva.
  • [C-2-3] DEVE rispettare i valori AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight dichiarati dell'applicazione di avvio di terze parti e non deve sostituirli durante la visualizzazione di alcuni contenuti dell'attività agganciata.

Se le implementazioni dei dispositivi supportano una o più modalità multi-finestra e la modalità multi-finestra Picture in picture, devono:

  • [C-3-1] DEVE avviare le attività in modalità finestra multipla 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 UI di sistema 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, la chiave DEVE essere disponibile per l'attività in primo piano.
  • [C-3-5] DEVE fornire all'utente la possibilità di bloccare la visualizzazione di un'app in modalità PIP; l'implementazione AOSP soddisfa questo requisito grazie ai controlli nella barra delle notifiche.

  • [C-3-6] È OBBLIGATORIO allocare la seguente larghezza e altezza minime per la finestra PIP quando un'applicazione non dichiara alcun valore per AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight:

    • I dispositivi con Configuration.uiMode impostato su un valore diverso da UI_MODE_TYPE_TELEVISION DEVONO allocare una larghezza e un'altezza minime di 108 dp.
    • I dispositivi con Configuration.uiMode impostato su UI_MODE_TYPE_TELEVISION DEVONO allocare una larghezza minima di 240 dp e un'altezza minima di 135 dp.

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 potrebbe non essere funzionale per un'applicazione a causa di un ritaglio del display o di un display curvo sui bordi.

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

  • [C-1-5] NON DEVONO essere presenti ritagli se le proporzioni del dispositivo sono 1,0 (1:1).
  • [C-1-2] NON DEVE avere più di un ritaglio per bordo.
  • [C-1-3] DEVE rispettare i flag di ritaglio del display impostati dall'app tramite l'API WindowManager.LayoutParams come descritto nell'SDK.
  • [C-1-4] DEVE riportare valori corretti per tutte le metriche di ritaglio definite nell'API DisplayCutout.

3.8.16. Controllo dei dispositivi

Android include le API ControlsProviderService e Control per consentire alle applicazioni di terze parti di pubblicare controlli dei dispositivi per fornire agli utenti informazioni rapide sullo stato e sulle azioni.

Per i requisiti specifici del dispositivo, consulta la sezione 2_2_3.

3.9. Amministrazione dispositivo

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

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

  • [C-1-1] È OBBLIGATORIO 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 del dispositivo

3.9.1.1 Provisioning del proprietario del dispositivo

Se le implementazioni del dispositivo dichiarano android.software.device_admin:

  • [C-1-1] DEVE supportare la registrazione di un client Device Policy (DPC) come app di proprietà del dispositivo come descritto di seguito:
  • [C-1-2] DEVE richiedere un intervento dell'utente prima o durante la procedura di provisioning per acconsentire all'impostazione dell'app come proprietario del dispositivo. Il consenso può essere dato dall'utente o tramite alcuni mezzi programmatici, ma l'informativa appropriata (a cui si fa riferimento in AOSP) DEVE essere mostrata prima dell'avvio del provisioning del proprietario del dispositivo. Inoltre, il meccanismo di consenso del proprietario del dispositivo programmatico utilizzato (dalle aziende) per il provisioning del proprietario del dispositivo NON DEVE interferire con l'esperienza Out-Of-Box per l'utilizzo non aziendale.
  • [C-1-3] NON DEVE codificare il consenso o impedire l'utilizzo di altre app di proprietà del dispositivo.

Se le implementazioni dei dispositivi 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, devono:

  • [C-2-1] È OBBLIGATORIO 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à configurata nella soluzione proprietaria per avere i diritti equivalenti a quelli di un "proprietario del dispositivo".
  • [C-2-2] DEVE mostrare la stessa informativa per il 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 della registrazione dell'applicazione DPC come "Proprietario dispositivo".
3.9.1.2 Provisioning dei profili gestiti

Se le implementazioni del dispositivo dichiarano android.software.managed_users:

  • [C-1-1] DEVE implementare le API che consentono a un'applicazione Device Policy Controller (DPC) di diventare il proprietario di un nuovo profilo gestito.

  • [C-1-2] L'esperienza degli utenti durante 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 nelle Impostazioni per indicare all'utente quando una determinata funzione di sistema è stata disattivata dal Device Policy Controller (DPC):

    • Un'icona coerente o un'altra funzionalità per l'utente (ad esempio l'icona delle informazioni AOSP a monte) per indicare quando una determinata impostazione è limitata da un amministratore dispositivo.
    • Un breve messaggio esplicativo, fornito dall'amministratore dispositivo tramite setShortSupportMessage.
    • L'icona dell'applicazione DPC.

3.9.2 Assistenza per i profili gestiti

Se le implementazioni del dispositivo 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] È OBBLIGATORIO utilizzare un badge icona (simile al badge di lavoro in 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 essere visualizzata un'icona di notifica (simile al badge di lavoro in upstream AOSP) per indicare quando l'utente si trova in un'applicazione del profilo gestito.
  • [C-1-5] DEVE mostrare una notifica che indica che l'utente è nel profilo gestito se e quando il dispositivo si riattiva (ACTION_USER_PRESENT) e l'applicazione in primo piano si trova nel profilo gestito.
  • [C-1-6] Se esiste un profilo gestito, DEVE essere mostrata un'affordance visiva nel "selettore" di intent 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, DEVE esporre le seguenti funzionalità per l'utente principale e per il profilo gestito:
    • Contabilità separata per batteria, posizione, dati mobili e utilizzo dello 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 di telefonia, contatti e messaggistica preinstallate possano cercare e recuperare le informazioni sull'autore della chiamata dal profilo gestito (se esistente) insieme a quelle del profilo principale, se il Controller dei criteri del dispositivo lo consente.
  • [C-1-9] DEVE garantire che soddisfi 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.

Se le implementazioni del dispositivo dichiarano android.software.managed_users e android.software.secure_lock_screen:

  • [C-2-1] DEVE supportare la possibilità di specificare una schermata di blocco separata che soddisfi i seguenti requisiti per concedere l'accesso alle app in esecuzione solo 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 archiviazione e gestione delle credenziali del profilo principale, come documentato sul sito del progetto open source Android.
    • I criteri delle password del DPC DEVONO essere applicati solo alle credenziali della schermata di blocco del profilo gestito, a meno che non vengano richiamati nell'istanza DevicePolicyManager restituita da getParentProfileInstance.
  • Quando i contatti del profilo gestito vengono visualizzati nel registro chiamate preinstallato, nell'interfaccia utente durante la chiamata, nelle notifiche di chiamate in corso e perse, nelle app di contatti e messaggistica, DEVONO essere contrassegnati con lo stesso badge utilizzato per indicare le applicazioni del profilo gestito.

3.9.3 Assistenza per gli utenti gestiti

Se le implementazioni del dispositivo dichiarano android.software.managed_users:

  • [C-1-1] È OBBLIGATORIO fornire un'affordance utente per uscire dall'utente corrente e tornare all'utente principale nella sessione con più utenti quando isLogoutEnabled restituisce true. L'affordance utente DEVE essere accessibile 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 nei loro dispositivi. Inoltre, Android fornisce API di piattaforma che consentono alle implementazioni dei servizi di accessibilità di ricevere callback per eventi utente e di sistema e di generare meccanismi di feedback alternativi, come la sintesi vocale, il feedback aptico e la 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à di Android come descritto nella documentazione dell'SDK delle API di accessibilità.
  • [C-1-2] DEVE generare eventi di accessibilità e inviare il AccessibilityEvent appropriato a tutte le implementazioni di AccessibilityService registrate, come documentato nell'SDK.
  • [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à abilitati dichiarano AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Tieni presente che per le implementazioni dei dispositivi senza barra di navigazione di sistema, questo requisito non è applicabile, ma le implementazioni dei dispositivi DOVREBBERO fornire all'utente un'affordance 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 Direct Boot Aware quando l'archiviazione dei dati è criptata con la crittografia basata su file (FBE).
  • DOVREBBE fornire un meccanismo nel flusso di configurazione out-of-box per consentire agli utenti di attivare i servizi di accessibilità pertinenti, nonché opzioni per regolare le dimensioni dei caratteri, le dimensioni del display 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 di questi servizi.

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. TV Input Framework

Android Television Input Framework (TIF) semplifica l'importazione di contenuti dal vivo sui dispositivi Android TV. TIF fornisce un'API standard per creare moduli di input che controllano i dispositivi Android TV.

Se le implementazioni del dispositivo supportano TIF:

  • [C-1-1] È OBBLIGATORIO 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 basati su TIF di terze parti possa essere installata e utilizzata sul dispositivo.

3.13. Impostazioni rapide

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

Se le implementazioni del dispositivo includono un componente dell'interfaccia utente delle Impostazioni rapide e supportano le Impostazioni rapide di terze parti:

  • [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 da 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 forniti dal sistema.

3.14. UI multimediale

Se le implementazioni del dispositivo includono applicazioni non attive 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. I titoli possono essere abbreviati 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 i contenuti forniti da questa applicazione di terze parti.

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

  • [C-1-5] È OBBLIGATORIO 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 le 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 sia vera una delle seguenti condizioni:
    • Il filtro pattern intent del componente è esposto e ha CATEGORY_BROWSABLE
    • L'azione è una di ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • Il target è esposto esplicitamente 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 vedere i dettagli delle app istantanee sul dispositivo, a meno che l'app istantanea non si connetta esplicitamente all'applicazione installata.

Se le implementazioni dei dispositivi supportano le app istantanee:

  • [C-1-1] DEVE fornire le seguenti funzionalità per l'interazione con le app istantanee. AOSP soddisfa i requisiti con la UI di sistema, le Impostazioni e Avvio predefinite.
  • [C-1-2] DEVE fornire all'utente la possibilità di visualizzare ed eliminare le app istantanee memorizzate nella cache locale per ogni singolo pacchetto dell'app.
  • [C-1-3] DEVE fornire una notifica utente persistente che può essere compressa mentre un'app istantanea è in esecuzione in primo piano. Questa notifica all'utente DEVE includere il fatto che le app istantanee non richiedono l'installazione e fornire un'affordance 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 azione impostata su Intent.ACTION_VIEW e con uno schema di "http" o "https", un'ulteriore funzionalità per l'utente DEVE consentire all'utente di non avviare l'app istantanea e di avviare il link associato con il browser web configurato, se un browser è disponibile sul dispositivo.
  • [C-1-4] DEVE consentire l'accesso alle app istantanee in esecuzione dalla funzione Recenti se questa è disponibile sul dispositivo.
  • [C-1-5] DEVE precaricare uno o più componenti di servizi o applicazioni con un gestore degli intent per gli intent elencati nell'SDK qui e renderli visibili per le app istantanee.

3.16. Accoppiamento 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 secondario:

  • [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità FEATURE_COMPANION_DEVICE_SETUP .
  • [C-1-2] DEVI assicurarti che le API nel pacchetto android.companion siano completamente implementate.
  • [C-1-3] DEVE fornire all'utente le funzionalità necessarie per selezionare/confermare che un dispositivo complementare è presente e operativo.

3.17. App pesanti

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

  • [C-1-1] È necessario che nel sistema sia installata una sola app che specifichi cantSaveState alla volta. Se l'utente esce da un'app di questo tipo senza uscirne esplicitamente (ad esempio premendo Home mentre esce da un'attività attiva del sistema, anziché premere Indietro quando non sono presenti attività attive nel sistema), le implementazioni del dispositivo DEVONO dare la priorità a quell'app nella RAM, come per altre cose che dovrebbero rimanere in esecuzione, come i servizi in primo piano. Quando un'app di questo tipo è in background, il sistema può comunque applicare funzionalità di gestione dell'alimentazione, ad esempio limitare l'accesso alla CPU e alla rete.
  • [C-1-2] DEVE fornire un'affordance dell'interfaccia utente per scegliere l'app che non parteciperà al normale meccanismo di salvataggio/ripristino dello stato quando l'utente avvia una seconda app dichiarata con l'attributo cantSaveState.
  • [C-1-3] NON DEVONO essere applicate altre modifiche alle norme alle app che specificano cantSaveState, ad esempio la modifica del rendimento 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.

3.18. Contatti

Android include API Contacts Provider per consentire alle applicazioni di gestire i dati di contatto memorizzati sul dispositivo. I dati di contatto inseriti direttamente nel dispositivo vengono in genere sincronizzati con un servizio web, ma POTREBBERO anche essere memorizzati solo localmente sul dispositivo. I contatti memorizzati solo sul dispositivo sono chiamati contatti locali.

I RawContacts sono "associati a" o "memorizzati in" un Account quando le colonne ACCOUNT_NAME e ACCOUNT_TYPE per i contatti non elaborati corrispondono ai campi Account.name e Account.type dell'account.

Account locale predefinito: un account per i contatti non elaborati memorizzati solo sul dispositivo e non associati a un account in AccountManager, che vengono creati con valori null per le colonne ACCOUNT_NAME e ACCOUNT_TYPE.

Account locale personalizzato: un account per i contatti non elaborati memorizzati solo sul dispositivo e non associati a un account in AccountManager, che vengono creati con almeno un valore non nullo per le colonne ACCOUNT_NAME e ACCOUNT_TYPE.

Implementazioni dei dispositivi:

  • [C-SR] È FORTEMENTE CONSIGLIATO di non creare account locali personalizzati.

Se le implementazioni dei dispositivi utilizzano un account locale personalizzato:

  • [C-1-1] L'attributo ACCOUNT_NAME dell'account locale personalizzato DEVE essere restituito da ContactsContract.RawContacts.getLocalAccountName
  • [C-1-2] L'attributo ACCOUNT_TYPE dell'account locale personalizzato DEVE essere restituito da ContactsContract.RawContacts.getLocalAccountType
  • [C-1-3] I contatti non elaborati inseriti da applicazioni di terze parti con l'account locale predefinito (ovvero impostando valori null per ACCOUNT_NAME e ACCOUNT_TYPE) DEVONO essere inseriti nell'account locale personalizzato.
  • [C-1-4] I contatti non elaborati inseriti nell'account locale personalizzato NON devono essere rimossi quando vengono aggiunti o rimossi account.
  • [C-1-5] Le operazioni di eliminazione eseguite sull'account locale personalizzato DEVONO comportare l'eliminazione immediata dei contatti non elaborati (come se il parametro CALLER_IS_SYNCADAPTER fosse impostato su true), anche se il parametro CALLER\_IS\_SYNCADAPTER è impostato su false o non è specificato.

4. Compatibilità con il pacchettizzazione delle applicazioni

Implementazioni dei dispositivi:

  • [C-0-1] DEVE essere in grado di installare ed eseguire file ".apk" Android come generati dallo strumento "aapt" incluso nell'SDK Android ufficiale.
  • Poiché il requisito sopra indicato può essere impegnativo, per le implementazioni dei dispositivi è CONSIGLIATO utilizzare il sistema di gestione dei pacchetti dell'implementazione di riferimento AOSP.

Implementazioni dei dispositivi:

  • [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 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 "installatore registrato" del pacchetto di disinstallare l'app in modo silenzioso senza alcuna conferma dell'utente, come documentato nell'SDK per l'autorizzazione DELETE_PACKAGE. Le uniche eccezioni sono l'app di verifica del pacchetto 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 di applicazioni da origini sconosciute, a meno che l'app che richiede l'installazione non soddisfi tutti i seguenti requisiti:

    • DEVE dichiarare l'autorizzazione REQUEST_INSTALL_PACKAGES o avere android:targetSdkVersion impostato su 24 o meno.
    • È OBBLIGATORIO che l'utente abbia concesso l'autorizzazione per installare app da origini sconosciute.

  • DOVREBBE fornire all'utente la possibilità di concedere/revocare l'autorizzazione per installare app da origini sconosciute per ogni applicazione, ma PUÒ scegliere di implementare questa operazione come no-op e restituire RESULT_CANCELED per startActivityForResult(), se l'implementazione del dispositivo non vuole consentire agli utenti di fare questa scelta. Tuttavia, anche in questi casi, DOVREBBE 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.

  • DOVREBBE fornire all'utente la possibilità di scegliere se disinstallare o avviare un'applicazione nella finestra di dialogo di avviso.

  • [C-0-8] È OBBLIGATORIO implementare il supporto per il file system incrementale come descritto qui.

  • [C-0-9] DEVE supportare la verifica dei file APK utilizzando lo schema di firma dell'APK v4.

  • Se le implementazioni dei dispositivi sono già state lanciate su una versione precedente di Android e non possono soddisfare i requisiti [C-0-8] e [C-0-9] tramite un aggiornamento del software di sistema, POTREBBERO essere esenti da questi requisiti.

5. Compatibilità multimediale

Implementazioni dei dispositivi:

  • [C-0-1] DEVE supportare i formati multimediali, gli encoder, i decodificatori, i tipi di file e i formati dei contenitori definiti nella sezione 5.1 per ogni codec dichiarato da MediaCodecList.
  • [C-0-2] DEVE dichiarare e segnalare il supporto degli encoder e dei decodificatori disponibili per le applicazioni di terze parti tramite MediaCodecList.
  • [C-0-3] DEVE essere in grado di decodificare correttamente e mettere a disposizione delle app di terze parti tutti i formati che può codificare. Sono inclusi tutti i bitstream generati dai suoi codificatori e i profili registrati nel suo CamcorderProfile.

Implementazioni dei dispositivi:

  • DEVONO mirare a una latenza minima del codec, in altre parole, devono
    • NON DEVE consumare e memorizzare i buffer di input e restituire i buffer di input solo dopo l'elaborazione.
    • NON DEVE conservare i buffer decodificati per più tempo di quanto 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 di seguito sono forniti come implementazioni software nell'implementazione Android preferita del progetto open source Android.

Tieni presente che né Google né l'Open Handset Alliance dichiarano che questi codec sono esenti da brevetti di terze parti. Gli utenti 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 da parte dei 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 dei dispositivi 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+ migliorato)
  • [C-1-4] AAC ELD (AAC a basso ritardo migliorato)
  • [C-1-11] xHE-AAC (profilo HE AAC esteso ISO/IEC 23003-3, che include il profilo di riferimento USAC e il profilo di controllo della gamma dinamica ISO/IEC 23003-4)
  • [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 è autorizzato a eseguire il downsampling e il downmix durante la fase di riproduzione.
  • [C-1-10] Opus

Se le implementazioni del dispositivo supportano la decodifica dei buffer di input AAC degli 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 downmixing (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 relativi all'intervallo dinamico DEVONO essere come definiti in "Controllo dell'intervallo dinamico (DRC)" in ISO/IEC 14496-3 e le chiavi DRC android.media.MediaFormat per configurare i comportamenti relativi 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] È FORTEMENTE CONSIGLIATO che i requisiti C-2-1 e C-2-2 sopra indicati siano soddisfatti da tutti i decodificatori audio AAC.

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

  • [C-3-1] I metadati di DRC e livello di volume DEVONO essere interpretati e applicati in base al profilo di controllo dinamico del livello DRC MPEG-D 1.
  • [C-3-2] Il decodificatore DEVE comportarsi in base alla configurazione impostata con le seguenti chiavi android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_DRC_EFFECT_TYPE.

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

  • POTREBBE supportare il controllo dell'intensità e del range dinamico utilizzando il profilo di controllo del range dinamico ISO/IEC 23003-4.

Se lo standard ISO/IEC 23003-4 è supportato e se in un flusso di bit decodificato sono presenti sia i metadati ISO/IEC 23003-4 sia quelli ISO/IEC 14496-3:

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

Tutti i decodificatori 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)
  • ADTS raw AAC (.aac, ADIF non supportato)
  • MPEG-TS (.ts, non cercabile, solo decodifica)
  • Matroska (.mkv, solo decodifica)
Profilo MPEG-4 HE AAC (AAC+) Supporto per 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 per 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 bassa latenza migliorata) Supporto per contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
USAC Supporto per 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 frequenze 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 Sia per l'encoder che per il decodificatore: DEVONO essere supportate almeno le modalità Mono e Stereo. È OBBLIGATORIO supportare frequenze di campionamento fino a 192 kHz e risoluzioni a 16 e 24 bit. La gestione dei dati audio FLAC a 24 bit DEVE essere disponibile con la configurazione audio a virgola mobile.
  • FLAC (.flac)
  • MPEG-4 (.mp4, .m4a, solo decodifica)
  • Matroska (.mkv, solo decodifica)
MP3 Mono/stereo 8-320 Kbps costante (CBR) o con velocità in bit variabile (VBR)
  • MP3 (.mp3)
  • MPEG-4 (.mp4, .m4a, solo decodifica)
  • Matroska (.mkv, solo decodifica)
MIDI Tipo MIDI 0 e 1. Versioni 1 e 2 di DLS. XMF e Mobile XMF. Supporto per i formati delle sveglie RTTTL/RTX, OTA e iMelody
  • Tipo 0 e 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • 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 a virgola mobile a 16 bit. L'estrattore WAVE deve supportare PCM lineare a 16 bit, 24 bit e 32 bit e float 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 Decodifica: supporto per contenuti mono, stereo, 5.0 e 5.1 con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz.
Codifica: supporto per contenuti mono e stereo con frequenze di campionamento di 8000, 12000, 16000, 24000 e 48000 Hz.
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, solo decodifica)
  • Matroska (.mkv)
  • WebM (.webm)

5.1.4. Codifica delle immagini

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

Le implementazioni dei dispositivi DEVONO supportare la codifica delle seguenti 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 del codificatore 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 di 512 x 512 px.

5.1.5. Decodifica delle immagini

Per ulteriori dettagli, consulta la sezione 5.1.6. Dettagli 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] Non elaborato

Se le implementazioni dei dispositivi supportano la decodifica video HEVC: * [C-1-1] DEVONO supportare la decodifica delle immagini HEIF (HEIC).

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

  • [C-2-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 delle immagini

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)

Codificatori e decodificatori di immagini esposti tramite l'API MediaCodec

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

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

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

5.1.7. Codec video

  • Per una qualità accettabile dei servizi di streaming video 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 decodificatore o un codificatore video:

  • [C-1-1] I codec video DEVONO supportare dimensioni dei buffer di byte di output e di input che supportino il frame compresso e non compresso più grande possibile, come stabilito dallo standard e dalla configurazione, ma che non prevedano un'allocazione eccessiva.

  • [C-1-2] Gli encoder e i decodificatori video DEVONO supportare i formati di colore flessibili YUV420 8:8:8 (COLOR_FormatYUV420Flexible) fino a CodecCapabilities.

  • [C-1-3] Gli encoder e i decodificatori video DEVONO supportare almeno un formato di colore YUV420 8:8:8 planare o semiplanare: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). È FORTEMENTE CONSIGLIATO supportare entrambi.

  • [SR] È FORTEMENTE CONSIGLIATO che gli encoder e i decodificatori video supportino almeno un formato di colore YUV420 8:8:8 planare o semiplanare ottimizzato per l'hardware (YV12, NV12, NV21 o un formato ottimizzato dal fornitore equivalente).

  • [C-1-5] I decodificatori video che supportano un formato con una profondità di bit elevata (più di 9 bit per canale) DEVONO supportare l'output di un formato equivalente a 8 bit, se richiesto dall'applicazione. Questo DEVE essere supportato da un formato di 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 interno tramite FEATURE_IntraRefresh nella classe MediaCodecInfo.CodecCapabilities:

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

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

  • [C-4-1] DEVE essere impostato come predefinito il formato di colore ottimizzato per il display hardware se configurato utilizzando l'output Surface.
  • [C-4-2] DEVE essere impostato come predefinito un formato di colore YUV420 8:8:8 ottimizzato per la lettura della CPU se configurato per non utilizzare l'uscita 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 cercabile)
  • Matroska (.mkv, solo decodifica)
H.265 HEVC Per informazioni dettagliate, consulta la sezione 5.3
  • MPEG-4 (.mp4)
  • Matroska (.mkv, solo decodifica)
MPEG-2 Profilo principale
  • MPEG2-TS (.ts, non cercabile)
  • 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 informazioni dettagliate, 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 multipiattaforma, nonché per 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 il supporto per i codec multimediali tramite le API OMX o Codec 2.0 (o entrambe) come nel progetto open source Android e non deve disattivare o aggirare le protezioni di sicurezza. Nello specifico, 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] È FORTEMENTE CONSIGLIATO includere il supporto per l'API Codec 2.0.

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

  • [C-2-1] DEVE includere il codec software OMX corrispondente del progetto open source Android (se disponibile) per ogni formato e tipo di contenuti multimediali (codificatore o decodificatore) supportato dal dispositivo.
  • [C-2-2] Codec con nomi che iniziano con "OMX.google." DEVONO essere basati sul codice sorgente del progetto open source Android.
  • [C-SR] È FORTEMENTE CONSIGLIATO che i codec software OMX vengano eseguiti in un processo di codec che non abbia accesso a driver hardware diversi dai mappatori della memoria.

Se le implementazioni del dispositivo supportano l'API Codec 2.0:

  • [C-3-1] DEVE includere il codec software Codec 2.0 corrispondente del progetto open source Android (se disponibile) per ogni formato e tipo di contenuti multimediali (codificatore o decodificatore) supportato dal dispositivo.
  • [C-3-2] È NECESSARIO includere i codec software Codec 2.0 nel processo dei codec software come indicato nel progetto open source Android per consentire di concedere l'accesso ai codec software in modo più limitato.
  • [C-3-3] Codec con nomi che iniziano con "c2.android." DEVONO essere basati sul codice sorgente del progetto open source Android.

5.1.10. Caratterizzazione dei codec multimediali

Se le implementazioni dei dispositivi supportano i codec multimediali:

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

In particolare:

  • [C-1-2] Codec con nomi che iniziano con "OMX". DEVONO utilizzare le API OMX e avere nomi conformi alle linee guida per i nomi OMX IL.
  • [C-1-3] Codec con nomi che iniziano con "c2". DEVONO 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 con accelerazione hardware.
  • [C-1-5] I codec in esecuzione in un processo di codec (del fornitore o di sistema) che hanno accesso a driver hardware diversi da allocatori e mappatori di memoria NON DEVONO essere caratterizzati come solo software.
  • [C-1-6] I codec non presenti nell'Android Open Source Project o non basati sul codice sorgente di quel progetto DEVONO essere identificati come di proprietà del fornitore.
  • [C-1-7] I codec che utilizzano l'accelerazione hardware DEVONO essere caratterizzati come con accelerazione hardware.
  • [C-1-8] I nomi dei codec NON DEVONO ingannare. 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 sulla frequenza frame 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 con accelerazione 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 rendimento estesi se supportano un rendimento video duraturo diverso da uno di quelli standard elencati.

5.2. Codifica video

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

  • NON deve superare, in due finestre scorrevoli, il 15% della velocità in bit tra gli intervalli intraframe (I-frame).
  • NON deve superare il 100% della velocità in bit in un intervallo mobile di 1 secondo.

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

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

Se le implementazioni dei dispositivi supportano uno degli encoder video H.264, VP8, VP9 o HEVC e lo rendono disponibile per le applicazioni di terze parti, devono:

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

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

  • DEVE supportare le velocità in bit configurabili dinamicamente per il codificatore supportato.

Se le implementazioni del dispositivo forniscono codificatori video o di 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 di immagini con accelerazione hardware DEVONO supportare la codifica dei frame dalle videocamere hardware.
  • DOVREBBE 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 le app di terze parti, devono:

  • [C-1-1] DEVE supportare il livello 45 del profilo di baseline.
  • DEVE supportare le velocità in bit 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 riferimento 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 gli encoder non utilizzino ASO, FMO e RS per il profilo di riferimento.
  • [C-1-2] DEVE supportare i profili di codifica video SD (definizione standard) riportati 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 riportati 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.
  • DOVREBBE fornire un codec VP8 hardware che soddisfi i requisiti di codifica hardware RTC del progetto WebM, per garantire una qualità accettabile dei servizi di streaming video web e di videoconferenza.

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

  • [C-2-1] DEVE supportare i profili di codifica riportati 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 di livello 3.
  • [C-1-1] DEVE supportare la scrittura di file Matroska WebM.
  • [C-1-3] DEVE generare dati CodecPrivate.
  • DOVREBBE supportare i profili di decodifica HD come indicato nella tabella seguente.
  • [SR] È MOLTO CONSIGLIATO 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 profilo principale di livello 3.
  • DOVREBBE supportare i profili di codifica HD come indicato nella tabella seguente.
  • [SR] È MOLTO CONSIGLIATO 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 passaggio dinamico della risoluzione video e della frequenza frame 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 decodificatori 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 decodificatori H.263:

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

5.3.3. MPEG-4

Se le implementazioni dei dispositivi con decodificatori 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 decodificatori H.264:

  • [C-1-1] DEVE supportare il profilo principale di livello 3.1 e il profilo di baseline. 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 (definizione standard) 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 indicata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, le implementazioni del dispositivo:

  • [C-2-1] DEVE supportare i profili di decodifica video HD 720p riportati nella tabella seguente.
  • [C-2-2] DEVE supportare i profili di decodifica video HD 1080p riportati 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 f/s (60 f/sTelevisore)
Velocità in bit video 800 kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5. H.265 (HEVC)

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

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

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

  • [C-2-1] Le implementazioni dei dispositivi DEVONO supportare almeno una decodifica 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 fpsTelevisore 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 tramite le API Media:

  • [C-3-1] Le implementazioni dei dispositivi DEVONO accettare i metadati HDR richiesti dall'applicazione, nonché supportare l'estrazione e l'output dei metadati HDR richiesti dal flusso di bit e/o dal contenitore.
  • [C-3-2] Le implementazioni dei dispositivi DEVONO mostrare correttamente i contenuti HDR 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 riportati nella tabella seguente.
  • DEBBA utilizzare un codec VP8 hardware che soddisfi i requisiti.
  • DEVE supportare i profili di decodifica HD riportati nella tabella seguente.

Se l'altezza indicata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, allora:

  • [C-2-1] Le implementazioni dei dispositivi DEVONO supportare i profili 720p indicati nella tabella seguente.
  • [C-2-2] Le implementazioni dei dispositivi DEVONO supportare i profili 1080p indicati 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 f/s (60 f/sTelevisore) 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 come indicato nella tabella seguente.
  • DOVREBBE supportare i profili di decodifica HD come indicato nella tabella seguente.

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

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

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

  • [C-3-1] Le implementazioni dei dispositivi DEVONO supportare almeno una decodifica 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 fpsTelevisore con decodifica hardware VP9) 60 FPS
Velocità in bit video 600 kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

Se le implementazioni del dispositivo dichiarano di supportare VP9Profile2 o VP9Profile3 tramite le API multimediali 'CodecProfileLevel':

  • Il supporto del formato a 12 bit è FACOLTATIVO.

Se le implementazioni del dispositivo dichiarano di supportare un profilo HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) tramite le API multimediali:

  • [C-4-1] Le implementazioni dei dispositivi DEVONO accettare i metadati HDR richiesti (KEY_HDR_STATIC_INFO per tutti i profili HDR, nonché 'KEY_HDR10_PLUS_INFO' per i profili HDR10 Plus) dall'applicazione. Inoltre, DEVONO supportare l'estrazione e l'output dei metadati HDR richiesti dal flusso di dati e/o dal contenitore.
  • [C-4-2] Le implementazioni dei dispositivi DEVONO mostrare correttamente i contenuti HDR sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

5.3.8. Dolby Vision

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

  • [C-1-1] È OBBLIGATORIO fornire un'apposita app per l'estrazione di file compatibile con Dolby Vision.
  • [C-1-2] DEVE mostrare correttamente i contenuti Dolby Vision sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).
  • [C-1-3] È NECESSARIO impostare l'indice traccia dei livelli base compatibili con le versioni precedenti (se presenti) in modo che corrisponda a quello 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 DOVREBBE fin da Android 4.3, è previsto che la definizione di compatibilità per le versioni future li modifichi in DEVE. Per i dispositivi Android esistenti e nuovi è FORTEMENTE CONSIGLIATO soddisfare questi requisiti indicati come DOVREBBE, altrimenti non potranno raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

5.4.1. Acquisizione di audio non compresso e informazioni sul microfono

Se le implementazioni del dispositivo 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 e 24 bit
    • Frequenze di campionamento: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
    • Canali: il numero di canali corrisponde al numero di microfoni sul dispositivo

  • [C-1-2] È OBBLIGATORIO 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 sottocampionamento.

  • DEVE consentire l'acquisizione di contenuti audio non elaborati con qualità DVD e radio AM, 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 relative ai microfoni disponibili sul dispositivo accessibili alle applicazioni di terze parti tramite l'API AudioManager.getMicrophones() e ai microfoni attualmente attivi accessibili alle applicazioni di terze parti tramite le API AudioRecord.getActiveMicrophones() e MediaRecorder.getActiveMicrophones(). Se le implementazioni dei dispositivi consentono l'acquisizione di contenuti audio non elaborati con qualità DVD e radio AM, devono:

  • [C-2-1] È NECESSARIO 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. Acquisisci per il riconoscimento vocale

Se le implementazioni del dispositivo dichiarano android.hardware.microphone:

  • [C-1-1] È NECESSARIO acquisire l'origine audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION a una delle frequenze di campionamento 44100 e 48000.
  • [C-1-2] PER IMPOSTAZIONE PREDEFINITA, deve disattivare qualsiasi elaborazione audio di riduzione del rumore durante la registrazione di uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
  • [C-1-3] PER IMPOSTAZIONE PREDEFINITA, deve essere disattivato qualsiasi controllo automatico del guadagno durante la registrazione di uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
  • DEBBA registrare lo stream audio di riconoscimento vocale con caratteristiche di ampiezza approssimativamente piatte rispetto alla frequenza: in particolare, ±3 dB, da 100 Hz a 4000 Hz.
  • DEBBA registrare lo stream audio di riconoscimento vocale con la sensibilità di input impostata in modo che una sorgente con un livello di potenza sonora (SPL) di 90 dB a 1000 Hz generi un RMS di 2500 per i campioni a 16 bit.
  • DEVE registrare lo stream audio di riconoscimento vocale in modo che i livelli di ampiezza PCM seguano in modo lineare le variazioni di SPL in ingresso in un intervallo di almeno 30 dB da -18 dB a +12 dB rispetto a 90 dB SPL al microfono.
  • DEVE registrare lo stream audio di riconoscimento vocale con una 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 tecnologie android.hardware.microphone e di soppressione (riduzione) del rumore ottimizzate per il riconoscimento vocale, devono:

  • [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. Acquisisci per il reindirizzamento della riproduzione

La classe android.media.MediaRecorder.AudioSource include l'origine audio REMOTE_SUBMIX.

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

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

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

5.4.4. Cancellazione dell'eco acustica

Se le implementazioni del dispositivo dichiarano android.hardware.microphone:

  • DOVREBBE implementare una tecnologia di cancellazione dell'eco acustica (AEC) ottimizzata per la comunicazione vocale e applicata al percorso di acquisizione durante l'acquisizione utilizzando AudioSource.VOICE_COMMUNICATION

Se le implementazioni del dispositivo forniscono un annullamento dell'eco acustico che viene inserito nel percorso audio di acquisizione quando è selezionato AudioSource.VOICE_COMMUNICATION, devono:

5.4.5. Acquisizione simultanea

Se le implementazioni dei dispositivi dichiarano android.hardware.microphone,DEVONO implementare la cattura 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 ha il ruolo di assistente e di almeno un'applicazione di acquisizione 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 autorizzazione CAPTURE_AUDIO_OUTPUT.
  • [C-1-4] Se due o più applicazioni acquisiscono contemporaneamente e se nessuna delle app ha un'interfaccia utente in alto, quella che ha iniziato l'acquisizione più di recente riceve l'audio.

5.4.6. Livelli di guadagno del microfono

Se le implementazioni del dispositivo dichiarano android.hardware.microphone:

  • DEVE presentare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte nell'intervallo di frequenza medio: in particolare ±3 dB da 100 Hz a 4000 Hz per ogni microfono utilizzato per registrare l'origine audio del riconoscimento vocale.
  • DEBBA impostare la sensibilità di ingresso audio in modo che un'origine di suoni sinusoidali a 1000 Hz riprodotta a un livello di pressione sonora (SPL) di 90 dB generi una risposta con RMS di 2500 per campioni a 16 bit (o -22,35 dB Full Scale per campioni a virgola mobile/doppia precisione) per ogni microfono utilizzato per registrare l'origine audio del riconoscimento vocale.
  • [C-SR] È MOLTO CONSIGLIABILE che mostrino livelli di ampiezza nell'intervallo di frequenza basso: in particolare da ±20 dB da 5 Hz a 100 Hz rispetto all'intervallo di frequenza medio per ogni microfono utilizzato per registrare l'origine audio del riconoscimento vocale.
  • [C-SR] sono FORTEMENTE CONSIGLIATI per presentare livelli di ampiezza nell'intervallo di frequenza alto: in particolare da ±30 dB da 4000 Hz a 22 KHz rispetto all'intervallo di frequenza medio per ogni microfono utilizzato per registrare l'origine 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 non elaborata

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

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

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

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

    • Frequenze di campionamento: 24000, 48000

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 di 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 di visualizzazione, controllabile tramite la classe Visualizer.
  • [C-1-3] DEVE supportare l'implementazione di EFFECT_TYPE_DYNAMICS_PROCESSING controllabile tramite la sottoclasse AudioEffect DynamicsProcessing.
  • DOVREBBE 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 FORTEMENTE CONSIGLIATI per supportare gli effetti in virgola mobile e multicanale.

5.5.3. Volume uscita audio

Implementazioni di dispositivi per auto e motori:

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

5.6. Latenza audio

La latenza audio è il ritardo temporale 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 in uscita. 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 uscita per il primo frame, quando il sistema di uscita audio è inattivo e spento prima della richiesta.
  • Latenza di output continua. La latenza di uscita per i frame successivi, dopo che il dispositivo ha iniziato a riprodurre l'audio.
  • Latenza di input. L'intervallo tra il momento in cui un suono viene presentato dall'ambiente al dispositivo su un trasduttore on-device o il segnale entra nel dispositivo tramite una porta e il momento in cui un'applicazione legge il frame corrispondente dei dati codificati in PCM.
  • Ha perso l'input. La parte iniziale di un segnale di input inutilizzabile o non disponibile.
  • Latenza di input a freddo. La somma del tempo di inserimento perso e della latenza di inserimento per il primo frame, quando il sistema di inserimento audio è inattivo e spento prima della richiesta.
  • Latenza di input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.
  • Jitter in uscita a freddo. La variabilità tra misurazioni separate dei valori di latenza dell'output a freddo.
  • Jitter di input a freddo. La variabilità tra misurazioni separate dei valori di latenza di input a freddo.
  • latenza di viaggio avanti e indietro continua. La somma della latenza di input continua più la latenza di output continua più un periodo di buffer. Il periodo di buffer consente all'app di elaborare il segnale e di attenuare la differenza di fase tra gli stream di input e di output.
  • API OpenSL ES PCM buffer queue. L'insieme di API OpenSL ES correlate a PCM in Android NDK.
  • API audio nativa AAudio. L'insieme di API AAudio in Android NDK.
  • Timestamp. Una coppia composta da una posizione relativa del frame all'interno di uno stream e dall'ora stimata in cui il frame entra o esce dalla pipeline di elaborazione audio nell'endpoint associato. Vedi anche AudioTimestamp.
  • glitch. Un'interruzione temporanea o un valore del campione errato nel segnale audio, in genere causato da un underrun del buffer per l'output, da un overflow del buffer 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'accuratezza di +/- 2 ms.
  • [C-1-2] Latenza di uscita a freddo pari o inferiore a 500 millisecondi.

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

  • [C-SR] Latenza in uscita a freddo pari o inferiore a 100 millisecondi. È MOLTO FORTEMENTE CONSIGLIATO che i dispositivi esistenti e nuovi che eseguono questa versione di Android soddisfino subito questi requisiti. In una futura release della piattaforma nel 2021, la latenza di output a freddo non dovrà superare i 200 ms.
  • [C-SR] Latenza di uscita continua di massimo 45 millisecondi.
  • [C-SR] Riduci al minimo il jitter dell'output a freddo.
  • [C-SR] Il timestamp di output restituito da AudioTrack.getTimestamp e AAudioStream_getTimestamp è preciso al massimo +/- 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 uscita continua e la latenza di uscita a freddo su almeno un dispositivo di uscita audio supportato, i valori 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, non sono supportate le seguenti funzionalità:

  • [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 per l'audio di input:

  • [C-3-1] Limita l'errore nei timestamp di input, restituito 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, è MOLTO CONSIGLIATO soddisfare i seguenti requisiti per l'input audio:

  • [C-SR] Latenza di input a freddo pari o inferiore a 100 millisecondi. È MOLTO FORTEMENTE CONSIGLIATO che i dispositivi esistenti e nuovi che eseguono questa versione di Android soddisfino subito questi requisiti. In una futura release della piattaforma nel 2021, la latenza di input a freddo non dovrà superare i 200 ms.
  • [C-SR] Latenza di input continua pari o inferiore a 30 millisecondi.
  • [C-SR] Latenza nel tempo di round trip continua pari o inferiore a 50 millisecondi.
  • [C-SR] Riduci al minimo il jitter dell'input a 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 dei dispositivi DEVONO supportare i protocolli di rete multimediale per la riproduzione di contenuti audio e video, come specificato nella documentazione dell'SDK Android.

Se le implementazioni dei dispositivi includono un decodificatore audio o video, devono:

  • [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 indicati nella tabella dei formati dei segmenti multimediali di seguito tramite il protocollo HTTP Live Streaming nella versione 7.

  • [C-1-3] DEVE supportare il seguente profilo audio video RTP e i codec correlati nella tabella RTSP 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 Riferimenti Supporto dei codec obbligatori
Stream di trasporto MPEG-2 ISO 13818 Codec video:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Consulta la sezione 5.1.3 per informazioni dettagliate su H264 AVC, MPEG2-4 SP
e MPEG-2.

Codec audio:

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

RTSP (RTP, SDP)

Nome del profilo Riferimenti Supporto dei codec obbligatori
H264 AVC RFC 6184 Per informazioni dettagliate su H264 AVC, consulta la sezione 5.1.3
MP4A-LATM RFC 6416 Per informazioni dettagliate sull'AAC e sulle sue 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 sull'AAC e sulle sue varianti, consulta la sezione 5.1.1.
MP2T RFC 2250 Per maggiori dettagli, consulta Flusso di trasporto MPEG-2 in HTTP Live Streaming

5.8. Contenuti multimediali sicuri

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

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

Se le implementazioni dei dispositivi dichiarano il supporto di Display.FLAG_SECURE e supportano il protocollo di visualizzazione wireless, devono:

  • [C-2-1] È NECESSARIO 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 lo schermo esterno con cavo, devono:

  • [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 il MIDI su tutti i trasporti hardware compatibili con MIDI per i quali forniscono connettività generica non MIDI, dove questi trasporti sono:

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

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

  • DOVREBBE supportare il MIDI in modalità periferica USB, sezione 7.7

5.10. Audio professionale

Se le implementazioni del dispositivo segnalano il supporto della funzionalità android.hardware.audio.pro tramite la classe android.content.pm.PackageManager:

  • [C-1-1] DEVE segnalare il supporto della funzionalità android.hardware.audio.low_latency.
  • [C-1-2] DEVE avere una latenza audio continua nel tempo di round trip, come definito nella sezione 5.6 Latenza audio, DEVE essere pari o inferiore a 20 millisecondi e DEVE 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 le latenze e i requisiti audio USB utilizzando sia l'API coda del buffer PCM OpenSL ES sia almeno un percorso dell'API audio nativo AAudio.
  • [SR] È FORTEMENTE CONSIGLIATO soddisfare i requisiti di latenza e audio USB utilizzando l'API audio nativo AAudio tramite il percorso MMAP.
  • [C-1-6] DEVE avere una latenza di output a freddo di massimo 200 millisecondi.
  • [C-1-7] DEVE avere una latenza di input a freddo di massimo 200 millisecondi.
  • [SR] Sono FORTEMENTE CONSIGLIATI per fornire un livello coerente di prestazioni della CPU quando l'audio è attivo e il carico della CPU varia. Questo deve essere testato utilizzando la versione dell'app per Android dell'ID commit di SynthMark 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 deve 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.

  • DOVREBBE ridurre al minimo l'inaccuratezza e lo scostamento dell'orologio audio rispetto all'ora standard.
  • DOVREBBE ridurre al minimo lo scostamento dell'orologio audio rispetto alla CPU CLOCK_MONOTONIC quando entrambe sono attive.
  • DEVE ridurre al minimo la latenza audio sui trasduttori sul dispositivo.
  • DEVE ridurre al minimo la latenza audio tramite l'audio digitale USB.
  • DOVREBBE documentare le misurazioni della latenza audio su tutti i percorsi.
  • DOVREBBE ridurre al minimo il jitter nei tempi di inserimento del callback di completamento del buffer audio, in quanto influisce sulla percentuale utilizzabile della larghezza di banda completa della CPU dal callback.
  • NON DEVE presentare glitch audio durante l'uso normale con la latenza indicata.
  • DOVREBBE fornire una differenza di latenza intercanale pari a zero.
  • DOVREBBE ridurre al minimo la latenza media MIDI su tutti i trasporti.
  • DOVREBBE ridurre al minimo la variabilità della latenza MIDI sotto carico (jitter) su tutti i trasporti.
  • DOVREBBE fornire timestamp MIDI accurati su tutti i trasporti.
  • DOVREBBE ridurre al minimo il rumore del segnale audio sui trasduttori sul 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 di output degli endpoint corrispondenti, quando entrambi sono attivi. Alcuni esempi di endpoint corrispondenti sono il microfono e lo speaker sul dispositivo oppure l'ingresso e l'uscita del jack audio.
  • DEVE gestire i callback di completamento del buffer audio per i lati di input e di output degli endpoint corrispondenti nello stesso thread quando entrambi sono attivi e deve inserire il callback di output immediatamente dopo il ritorno dal callback di input. In alternativa, se non è possibile gestire i callback nello stesso thread, inserisci il callback di output poco dopo aver inserito il callback di input per consentire all'applicazione di avere una temporizzazione 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 di output degli endpoint corrispondenti.
  • DEVE ridurre al minimo la latenza del tocco.
  • DOVREBBE ridurre al minimo la variabilità della latenza tocco sotto carico (jitter).
  • DEVE avere una latenza dall'input tocco all'uscita 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, devono:

  • [C-2-1] La latenza audio continua nel tempo di andata e ritorno deve essere pari o inferiore a 20 millisecondi sul percorso del jack audio.
  • [SR] È FORTEMENTE CONSIGLIATO di rispettare la sezione Specifiche del jack per dispositivi mobili della Specifica per cuffie audio con cavo (v1.1).
  • La latenza audio continua nel tempo di round trip DEVE essere pari o inferiore a 10 millisecondi lungo il percorso del jack audio.

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] È NECESSARIO implementare la classe audio USB.
  • [C-3-2] DEVE avere una latenza audio continua nel tempo di round trip pari o inferiore a 20 ms sulla porta in modalità host USB utilizzando la classe audio USB.
  • La latenza audio in tempo di round trip continuo DEVE essere pari o inferiore a 10 millisecondi sulla porta in modalità host USB utilizzando la classe audio USB.
  • [C-SR] È FORTEMENTE CONSIGLIATO supportare I/O simultanee fino a 8 canali in ogni direzione, frequenza di campionamento di 96 kHz e profondità di 24 o 32 bit, se utilizzate con periferiche audio USB che supportano anche questi requisiti.

Se le implementazioni dei dispositivi includono una porta HDMI, devono:

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

5.11. Acquisisci per non elaborato

Android include il supporto per la registrazione di 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 hanno l'intenzione di supportare l'origine audio non elaborata e renderla disponibile per le app di terze parti:

  • [C-1-1] È OBBLIGATORIO 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 nell'intervallo di frequenza medio: in particolare ±10 dB da 100 Hz a 7000 Hz per ogni microfono utilizzato per registrare l'origine audio non elaborata.

  • [C-1-3] DEVE presentare livelli di ampiezza nell'intervallo di frequenza basso: in particolare da ±20 dB da 5 Hz a 100 Hz rispetto all'intervallo di frequenza medio per ogni microfono utilizzato per registrare l'origine audio non elaborata.

  • [C-1-4] DEVE presentare livelli di ampiezza nell'intervallo di frequenza alto: in particolare da ±30 dB da 7000 Hz a 22 KHz rispetto all'intervallo di frequenza medio per ogni microfono utilizzato per registrare l'origine audio non elaborata.

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

  • [C-1-6] DEVE avere un rapporto segnale/rumore (SNR) di almeno 60 dB per ogni microfono utilizzato per registrare l'origine audio non elaborata. (mentre il rapporto SNR viene misurato come differenza tra 94 dB SPL e 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 di 90 dB SPL su ogni microfono utilizzato per registrare l'origine audio non elaborata.

  • NON deve essere presente nel percorso alcun altro trattamento del segnale (ad es. controllo automatico del guadagno, filtro passa alto o cancellazione dell'eco) oltre a un moltiplicatore di livello per portare il livello nell'intervallo desiderato. In altre parole:

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

Tutte le misurazioni SPL vengono effettuate direttamente accanto al microfono in prova. Per più configurazioni del microfono, questi requisiti si applicano a ogni 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 dell'API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), per indicare correttamente la mancanza di supporto.
  • [SR] sono comunque FORTEMENTE CONSIGLIATI per soddisfare il maggior numero possibile di requisiti per il percorso del segnale per l'origine di registrazione non elaborata.

6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori

6.1. Strumenti per sviluppatori

Implementazioni dei dispositivi:

  • [C-0-1] DEVE supportare gli Android Developer Tools forniti nell'SDK Android.

  • Android Debug Bridge (ADB)

    • [C-0-2] DEVE supportare adb come descritto nell'SDK Android e i comandi shell forniti in AOSP, che possono essere utilizzati dagli sviluppatori di app, tra cui dumpsys cmd stats
    • [C-0-11] DEVE supportare il comando shell cmd testharness. L'upgrade delle implementazioni dei dispositivi da una versione precedente di Android senza un blocco di dati persistenti POTREBBE essere esente da C-0-11.
    • [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 accessibili e disponibili i seguenti eventi al comando shell cmd stats e alla classe dell'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] È NECESSARIO che il daemon adb lato dispositivo sia inattivo per impostazione predefinita e DEVE essere presente 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 attiva adb su host autenticati noti.
    • [C-0-6] DEVE fornire un meccanismo che consenta la connessione di adb da una macchina host. Nello specifico:

    Se le implementazioni dei dispositivi senza porta USB supportano la modalità periferica:

    • [C-3-1] È OBBLIGATORIO implementare adb tramite una rete locale (ad esempio Ethernet o Wi-Fi).
    • [C-3-2] DEVE fornire i driver per Windows 7, 8 e 10, consentendo agli sviluppatori di connettersi al dispositivo utilizzando il protocollo adb.

    Se le implementazioni dei dispositivi supportano le connessioni adb a una macchina host tramite Wi-Fi, devono:

    • [C-4-1] Il metodo AdbManager#isAdbWifiSupported() DEVE restituire true.

    Se le implementazioni dei dispositivi supportano le connessioni adb a una macchina host tramite Wi-Fi e includono almeno una videocamera:

    • [C-5-1] Il metodo AdbManager#isAdbWifiQrSupported() DEVE restituire true.

  • Dalvik Debug Monitor Service (ddms)

    • [C-0-7] DEVE supportare tutte le funzionalità ddms come documentato nell'SDK Android. Poiché ddms utilizza adb, il supporto di ddms DOVREBBE 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 descritto nell'SDK Android. Systrace deve essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivarlo.
  • Perfetto
    • [C-SR] È FORTEMENTE CONSIGLIATO esporre all'utente della shell un file binario /system/bin/perfetto la cui cmdline sia conforme alla documentazione di perfetto.
    • [C-SR] È FORTEMENTE CONSIGLIATO che il file binario perfetto accetti come input una configurazione protobuf conforme allo schema definito nella documentazione di perfetto.
    • [C-SR] È FORTEMENTE CONSIGLIATO che il file binario perfetto scriva come output una traccia protobuf conforme allo schema definito nella documentazione di perfetto.
    • [C-SR] È FORTEMENTE CONSIGLIATO di fornire, tramite il file binario perfetto, almeno le origini dati descritte nella documentazione di perfetto.
  • Low Memory Killer
    • [C-0-10] DEVE scrivere un atomo LMK_KILL_OCCURRED_FIELD_NUMBER nel log di statsd quando un'app viene interrotta dal Low Memory Killer.
  • 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 di funzionalità android.hardware.vulkan.version:

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

6.2. Opzioni sviluppatore

Android include il supporto per la configurazione delle impostazioni relative allo sviluppo delle applicazioni da parte degli sviluppatori.

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

  • [C-0-1] DEVE rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo delle applicazioni. L'implementazione di Android a monte nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avviare le Opzioni sviluppatore dopo aver premuto sette (7) volte l'elemento di menu Impostazioni > Informazioni sul dispositivo > Numero build.
  • [C-0-2] DEVE nascondere le Opzioni sviluppatore per impostazione predefinita.
  • [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. DEVI fornire un documento o un sito web pubblicamente visibile che descriva come attivare le Opzioni sviluppatore. Questo documento o sito web DEVE essere collegabile dai documenti dell'SDK Android.
  • DOVREBBE avere una notifica visiva continua per l'utente quando le Opzioni sviluppatore sono attive e la sicurezza dell'utente è in discussione.
  • POTREBBE limitare temporaneamente l'accesso al menu Opzioni sviluppatore nascondendolo o disattivandolo visivamente per evitare distrazioni in scenari in cui la sicurezza dell'utente è in discussione.

7. Compatibilità hardware

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

  • [C-0-1] L'implementazione del dispositivo DEVE implementare l'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 dispone di questo componente:

  • [C-0-2] È comunque necessario presentare definizioni di classi complete (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 dell'API DEVONO restituire valori null se consentito dalla documentazione dell'SDK.
  • [C-0-5] I metodi API DEVONO restituire implementazioni no-op delle classi in cui i valori null non sono consentiti dalla documentazione dell'SDK.
  • [C-0-6] I metodi dell'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) della classe android.content.pm.PackageManager per la stessa impronta di build.

Un esempio tipico di uno scenario in cui si applicano questi requisiti è l'API di telefonia: anche su dispositivi diversi dagli smartphone, queste API devono essere implementate come no-op ragionevoli.

7.1. Display e grafica

Android include funzionalità che regolano automaticamente gli asset dell'applicazione e i layout dell'interfaccia utente in base al dispositivo per garantire il corretto funzionamento delle applicazioni di terze parti su una varietà di configurazioni hardware. Sui display compatibili con Android su cui possono essere eseguite tutte le applicazioni compatibili con Android di terze parti, 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:

  • Dimensioni diagonali fisiche. La distanza in pollici tra due angoli opposti della parte illuminata del display.
  • Punti per pollice (DPI). Il numero di pixel inclusi in un intervallo lineare orizzontale o verticale di 2,54 cm. Se sono elencati i valori dpi, sia quelli orizzontali che quelli verticali 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 corrisponde a 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 segue: pixel = dps * (densità/160).

7.1.1. Configurazione schermo

7.1.1.1. Dimensioni e forma dello schermo

Il framework UI di Android supporta una serie di dimensioni diverse del layout dello schermo logico 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 dei dispositivi:

  • [C-0-1] DEVE riportare 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 logiche in pixel indipendenti dalla densità (dp) corrette 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 di 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> in 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 uno o più display compatibili con Android con angoli arrotondati, devono:

  • [C-1-1] DEVI assicurarti che sia soddisfatto almeno uno dei seguenti requisiti:
  • Il raggio degli angoli arrotondati è inferiore o uguale a 38 dp.

  • Quando una casella di 15 dp per 15 dp è ancorata a ogni angolo della visualizzazione logica, almeno un pixel di ogni casella è visibile sullo schermo.

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

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

Se le implementazioni del dispositivo includono uno o più display compatibili con Android pieghevoli o un perno di chiusura tra più pannelli del display e se il perno o la piega attraversano una finestra dell'applicazione a schermo intero, i dispositivi:

  • [C-3-1] DEVE segnalare all'applicazione la posizione, i limiti e lo stato della cerniera o della piega tramite estensioni o API sidecar.

Per informazioni dettagliate sull'implementazione corretta delle API sidecar o di estensione, consulta la documentazione pubblica di Window Manager Jetpack.

7.1.1.2. Proporzioni dello schermo

Sebbene non siano previste limitazioni 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 ricavate dai valori di altezza e larghezza registrati tramite le API view.Display e le API Configuration, DEVONO soddisfare i seguenti requisiti:

  • [C-0-1] Le implementazioni dei dispositivi con Configuration.uiMode impostato su UI_MODE_TYPE_NORMAL DEVONO avere un valore di 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 formato dello schermo più grande 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 limiti le proporzioni consentite.

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

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

7.1.1.3. Densità schermo

Il framework dell'interfaccia utente di Android definisce un insieme di densità logiche standard per aiutare gli sviluppatori di applicazioni a scegliere come target le risorse dell'applicazione.

  • [C-0-1] Per impostazione predefinita, le implementazioni del dispositivo DEVONO segnalare una sola delle densità del framework Android elencate in DisplayMetrics tramite l'API DENSITY_DEVICE_STABLE e questo valore NON DEVE cambiare in nessun momento; tuttavia, il dispositivo PUÒ segnalare una densità arbitraria diversa in base alle modifiche alla configurazione del display apportate dall'utente (ad esempio le dimensioni del display) impostate dopo l'avvio iniziale.

  • Le implementazioni del dispositivo DEVONO definire la densità del framework Android standard più vicina numericamente alla densità fisica dello schermo, a meno che questa densità logica non riduca le dimensioni dello schermo registrate al di sotto del minimo supportato. Se la densità del framework Android standard più vicina numericamente alla densità fisica genera dimensioni dello schermo inferiori alle dimensioni dello schermo compatibile più piccole supportate (larghezza di 320 dp), le implementazioni del dispositivo DEVONO segnalare la densità del framework Android standard successiva più bassa.

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

  • [C-1-1] Le dimensioni del display NON DEVONO essere scalate per un valore superiore a 1,5 volte la densità nativa o produrre una dimensione dello schermo minima effettiva inferiore a 320 dp (equivalente al qualificatore della risorsa sw320dp), a seconda del caso.
  • [C-1-2] Le dimensioni del display NON DEVONO essere scalate a un valore inferiore a 0,85 volte la densità nativa.
  • Per garantire una buona usabilità e dimensioni dei caratteri coerenti, è CONSIGLIATO fornire la seguente scalabilità delle opzioni di visualizzazione nativa (nel rispetto dei limiti specificati sopra):
  • Piccola: 0,85x
  • Valore predefinito: 1x (scala di visualizzazione nativa)
  • Grande: 1,15x
  • Più grande: 1,3 volte
  • Più grande 1,45x

7.1.2. Metriche relative alla visualizzazione

Se le implementazioni dei dispositivi includono i display o l'uscita video compatibili con Android, devono:

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

Se le implementazioni dei dispositivi non includono uno schermo incorporato o un'uscita video, devono:

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

7.1.3. Orientamento schermo

Implementazioni dei dispositivi:

  • [C-0-1] DEVE indicare gli orientamenti dello schermo supportati (android.hardware.screen.portrait e/o android.hardware.screen.landscape) e DEVE indicare almeno un orientamento supportato. Ad esempio, un dispositivo con uno schermo orizzontale con orientamento fisso, come una TV o un laptop, DOVREBBE segnalare solo android.hardware.screen.landscape.
  • [C-0-2] DEVE riportare il valore corretto per l'orientamento corrente del dispositivo, ogni volta che viene eseguito una query tramite android.content.res.Configuration.orientation, android.view.Display.getOrientation() o altre API.

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

  • [C-1-1] DEVE supportare l'orientamento dinamico da parte delle applicazioni per l'orientamento dello schermo verticale o orizzontale. In altre parole, 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 registrate quando si cambia l'orientamento.
  • PUO' selezionare l'orientamento verticale o orizzontale come predefinito.

7.1.4. Accelerazione grafica 2D e 3D

7.1.4.1 OpenGL ES

Implementazioni dei dispositivi:

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

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

  • [C-1-1] DEVE supportare sia OpenGL ES 1.1 che 2.0, come descritto e dettagliato nella documentazione dell'SDK Android.
  • [C-SR] È MOLTO CONSIGLIATO supportare OpenGL ES 3.1.
  • DOVREBBE supportare OpenGL ES 3.2.

Se le implementazioni del dispositivo supportano una delle versioni OpenGL ES, devono:

  • [C-2-1] DEVE segnalare tramite le API OpenGL ES gestite e le API native tutte le altre estensioni OpenGL ES che ha implementato e, al contrario, NON DEVE segnalare le 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] È MOLTO CONSIGLIATO 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 del dispositivo dichiarano il supporto di OpenGL ES 3.0, 3.1 o 3.2:

  • [C-3-1] È NECESSARIO esportare i simboli di funzione corrispondenti per queste versioni, oltre ai simboli di funzione OpenGL ES 2.0, nella libreria libGLESv2.so.
  • [SR] Sono FORTEMENTE CONSIGLIATI per supportare l'estensione OES_EGL_image_external_essl3.

Se le implementazioni del dispositivo supportano OpenGL ES 3.2:

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

Se le implementazioni del dispositivo supportano l'Android Extension Pack OpenGL ES nella sua interezza, devono:

  • [C-5-1] È NECESSARIO identificare il supporto tramite il flag della 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 la grafica 3D ad alte prestazioni.

Se le implementazioni del dispositivo supportano OpenGL ES 3.1:

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

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

  • DOVREBBE includere il supporto di Vulkan 1.1.

I test Vulkan dEQP sono suddivisi in una serie di elenchi di test, ciascuno con una data/versione associata. Si trovano nella struttura del codice sorgente di Android in external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Un dispositivo che supporta Vulkan a un livello autodichiarato indica che può superare i test dEQP in tutti gli elenchi di test a partire da questo livello e precedenti.

Se le implementazioni del dispositivo includono il supporto di Vulkan 1.0 o versioni successive:

  • [C-1-1] DEVE riportare il valore intero corretto con i flag di funzionalità android.hardware.vulkan.level e android.hardware.vulkan.version.
  • [C-1-2] DEVE elencare almeno un VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] DEVE implementare completamente le API Vulkan 1.0 per ogni VkPhysicalDevice elencato.
  • [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 di Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties() .
  • [C-1-5] NON DEVE enumerare i livelli forniti dalle librerie esterne al pacchetto dell'applicazione o fornire altri modi per tracciare o intercettare l'API Vulkan, a meno che l'attributo android:debuggable dell'applicazione non sia impostato su true.
  • [C-1-6] DEVE segnalare tutte le stringhe di estensione supportate tramite le API native di Vulkan e, al contrario, NON DEVE segnalare le stringhe di estensione non supportate correttamente.
  • [C-1-7] DEVE supportare le estensioni VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain e VK_KHR_incremental_present.
  • [C-1-8] DEVE segnalare la versione massima dei test Vulkan dEQP supportata tramite il flag di funzionalità android.software.vulkan.deqp.level.
  • [C-1-9] DEVE supportare almeno la versione 132317953 (dal 1° marzo 2019) come indicato nel flag della funzionalità android.software.vulkan.deqp.level.
  • [C-1-10] DEVE superare tutti i test Vulkan dEQP negli elenchi di test tra la versione 132317953 e la versione specificata nel flag della funzionalità android.software.vulkan.deqp.level.
  • [C-SR] È FORTEMENTE CONSIGLIATO 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 elencare alcun VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices().

Se le implementazioni del dispositivo includono il supporto di Vulkan 1.1 e dichiarano uno dei flag di funzionalità Vulkan, devono:

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

Android include un meccanismo per consentire 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 di chiamate API dirette.

Implementazioni dei dispositivi:

  • [C-0-1] DEVE attivare l'accelerazione hardware per impostazione predefinita e DEVE disattivarla se lo sviluppatore lo richiede impostando android:hardwareAccelerated="false" o disattivando l'accelerazione hardware direttamente tramite le API View di Android.
  • [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 dei dispositivi:

  • [C-0-3] DEVE supportare l'API TextureView e DEVE avere un comportamento coerente con l'implementazione Android a monte.
7.1.4.5 Display con gamma di colori ampliata

Se le implementazioni dei dispositivi dichiarano il supporto dei display a gamma estesa tramite Configuration.isScreenWideColorGamut():

  • [C-1-1] DEVE avere un display calibrato a colori.
  • [C-1-2] DEVE avere un display la cui gamma copra interamente la gamma di colori sRGB nello spazio xyY CIE 1931.
  • [C-1-3] DEVE avere un display la cui gamma ha un'area di almeno il 90% di DCI-P3 nello spazio xyY CIE 1931.
  • [C-1-4] DEVE supportare OpenGL ES 3.1 o 3.2 e segnalarlo correttamente.
  • [C-1-5] È OBBLIGATORIO pubblicizzare il supporto per le 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] È MOLTO CONSIGLIATO supportare GL_EXT_sRGB.

Al contrario, se le implementazioni dei dispositivi non supportano i display a gamma estesa:

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

7.1.5. Modalità di compatibilità delle applicazioni precedenti

Android specifica una "modalità di compatibilità" in cui il framework opera in una modalità equivalente a dimensioni dello schermo "normali" (larghezza di 320 dp) a vantaggio delle applicazioni precedenti 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 grafica avanzata su un display compatibile con Android. I dispositivi DEVONO supportare tutte queste API come definite 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] DEVE essere in grado di eseguire il rendering di grafica a colori a 16 bit.
  • DEVE supportare i display in grado di gestire la grafica a colori a 24 bit.
  • [C-0-2] DEVE essere in grado di eseguire il rendering delle animazioni.
  • [C-0-3] DEVE avere un formato pixel (PAR) compreso tra 0,9 e 1,15. In altre parole, 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 i 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 con cavo, wireless o un display aggiuntivo integrato, devono:

  • [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 dei dispositivi:

7.2.1. Tastiera

Se le implementazioni dei dispositivi includono il supporto di applicazioni Input Method Editor (IME) di terze parti, devono:

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). * DEVE includere implementazioni aggiuntive della tastiera virtuale. * POTREBBE includere una tastiera hardware.

7.2.2. Navigazione non tocco

Android include il supporto per il d-pad, la trackball e il mouse come meccanismi per la navigazione non tocco.

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi non dispongono di navigazione non tocco, presentano i seguenti problemi:

  • [C-1-1] DEVE fornire un meccanismo di interfaccia utente alternativo ragionevole per la selezione e la modifica del testo, compatibile con gli Input Management Engine. 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, di conseguenza, per le implementazioni dei dispositivi:

  • [C-0-1] DEVE fornire all'utente la possibilità di avviare le applicazioni installate che hanno un'attività con <intent-filter> impostato su ACTION=MAIN e CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER per le implementazioni dei dispositivi TV. La funzione Home DOVREBBE essere il meccanismo per questa funzionalità per l'utente.
  • DOVREBBE fornire pulsanti per le funzioni Recenti e Indietro.

Se sono fornite le funzioni Home, Recenti o Indietro:

  • [C-1-1] DEVONO essere accessibili con una singola azione (ad es. tocco, doppio clic o gesto) quando sono accessibili.
  • [C-1-2] DEVE fornire un'indicazione chiara della singola azione che attiverà ogni funzione. Alcuni esempi di queste indicazioni sono l'inserimento di un'icona visibile sul pulsante, la visualizzazione di un'icona del software nella parte della barra di navigazione dello schermo o la guida dell'utente attraverso un flusso di dimostrazione passo passo durante l'esperienza di configurazione out-of-box.

Implementazioni dei dispositivi:

  • [SR] È FORTEMENTE CONSIGLIATO di non fornire il meccanismo di immissione per la funzione Menu, in quanto è stata ritirata a favore dell'app bar da Android 4.0.

Se le implementazioni del dispositivo forniscono la funzione Menu, devono:

  • [C-2-1] DEVE mostrare il pulsante di overflow delle azioni ogni volta che il menu popup 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Ò visualizzare il popup di overflow delle azioni in una posizione modificata sullo schermo quando viene visualizzato selezionando la funzione Menu.

Se le implementazioni dei dispositivi non forniscono la funzione Menu, per la compatibilità con le versioni precedenti:

  • [C-3-1] DEVE rendere disponibile la funzione Menu per le applicazioni quando targetSdkVersion è inferiore a 10, tramite un pulsante fisico, una chiave software o gesti. Questa funzione Menu deve essere accessibile, a meno che non sia nascosta insieme ad altre funzioni di navigazione.

Se le implementazioni dei dispositivi forniscono la funzione di assistenza:

  • [C-4-1] È OBBLIGATORIO rendere accessibile la funzione di assistenza con una singola azione (ad es. tocco, doppio clic o gesto) quando sono accessibili altri tasti di navigazione.
  • [SR] È FORTEMENTE CONSIGLIATO di utilizzare la pressione prolungata sulla funzione HOME come interazione designata.

Se le implementazioni del dispositivo 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 coprire o interferire in altro modo con la parte dello schermo disponibile per le applicazioni.
  • [C-5-2] DEVE rendere disponibile una parte del display per le applicazioni che soddisfano i requisiti definiti nella sezione 7.1.1.
  • [C-5-3] DEVE rispettare i flag impostati dall'app tramite il metodo dell'API View.setSystemUiVisibility(), in modo che questa parte distinta della schermata (ovvero la barra di navigazione) venga nascosta correttamente come descritto 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 dei gesti della casa.
  • [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 di esclusione massimo specificato nella documentazione di View#setSystemGestureExclusionRects().
  • [C-6-3] DEVE inviare all'app in primo piano un evento MotionEvent.ACTION_CANCEL quando i tocchi iniziano a essere intercettati per un gesto di sistema, se all'app in primo piano è stato inviato in precedenza un evento MotionEvent.ACTION_DOWN.
  • [C-6-4] DEVE fornire all'utente la possibilità di passare a una navigazione sullo schermo basata su pulsanti (ad esempio nelle Impostazioni).
  • DOVREBBE fornire la funzione Home con uno scorrimento verso l'alto dal bordo inferiore dell'orientamento corrente dello schermo.
  • DOVREBBE 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 un punto qualsiasi dei bordi sinistro e destro dell'orientamento corrente dello schermo:

  • [C-7-1] La funzione di navigazione DEVE essere Indietro e deve essere fornita come scorrimento dai bordi sinistro e destro dell'orientamento corrente dello schermo.
  • [C-7-2] Se sono disponibili pannelli di sistema scorrevoli personalizzati sui bordi sinistro o destro, questi DEVONO essere posizionati nel terzo superiore dello schermo con un'indicazione visiva chiara e persistente che indichi che lo scorrimento verso l'interno attiverà i pannelli sopra menzionati e quindi non Indietro. Un riquadro di sistema PUÒ essere configurato da un utente in modo da apparire sotto il terzo superiore dei bordi dello schermo, ma NON DEVE occupare più di 1/3 dei bordi.
  • [C-7-3] Quando nell'app in primo piano sono impostati i flag View.SYSTEM_UI_FLAG_IMMERSIVE o View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, lo scorrimento dai bordi DEVE comportarsi come implementato in AOSP, come documentato nell'SDK.
  • [C-7-4] Quando nell'app in primo piano sono impostati i flag View.SYSTEM_UI_FLAG_IMMERSIVE o View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, i riquadri di sistema scorrevoli personalizzati DEVONO essere nascosti finché l'utente non inserisce 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 di una serie di sistemi di input del cursore, come touchscreen, touchpad e dispositivi di input touch simulati. Le implementazioni dei 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 funzionalità aggiuntive per indicare gli oggetti manipolati.

Implementazioni dei dispositivi:

  • DEVE avere un sistema di input del cursore di qualche tipo (simile al mouse o tocco).
  • DOVREBBE supportare gli indicatori monitorati in modo completamente indipendente.

Se le implementazioni del dispositivo includono un touchscreen (monotocco o superiore) su un display principale compatibile con Android, devono:

  • [C-1-1] È OBBLIGATORIO segnalare TOUCHSCREEN_FINGER per il campo dell'API Configuration.touchscreen.
  • [C-1-2] DEVI segnalare i flag di funzionalità android.hardware.touchscreen e android.hardware.faketouch.

Se le implementazioni del dispositivo includono un touchscreen che può rilevare più di un tocco su un display principale compatibile con Android, devono:

  • [C-2-1] DEVE segnalare i flag di 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 dei dispositivi si basano su un dispositivo di input esterno come mouse o trackball (ovvero non toccano direttamente lo schermo) per l'input su un display principale compatibile con Android e soddisfano i requisiti di tocco falso descritti nella sezione 7.2.5, devono:

  • [C-3-1] NON DEVE segnalare alcun flag di funzionalità che inizi con android.hardware.touchscreen.
  • [C-3-2] DEVE essere riportato solo android.hardware.faketouch.
  • [C-3-3] È OBBLIGATORIO segnalare TOUCHSCREEN_NOTOUCH per il campo dell'API Configuration.touchscreen.

7.2.5. Input tocco simulato

L'interfaccia touch simulata fornisce un sistema di input utente che approssima un sottoinsieme di funzionalità del touchscreen. Ad esempio, un mouse o un telecomando che gestisce un cursore sullo schermo si avvicina al tocco, ma richiede all'utente di prima puntare o mettere a fuoco e poi fare clic. Numerosi dispositivi di input come mouse, trackpad, mouse aereo basato su giroscopio, cursore a giroscopio, joystick e trackpad multi-touch possono supportare interazioni touch false. Android include la costante di funzionalità android.hardware.faketouch, che corrisponde a un dispositivo di input non touch (basato su cursore) ad alta fedeltà, come un mouse o un trackpad, che può emulare adeguatamente l'input touch (incluso il supporto di gesti di base) e indica che il dispositivo supporta un sottoinsieme emulato delle funzionalità del touchscreen.

Se le implementazioni dei dispositivi non includono un touchscreen, ma includono un altro sistema di input del cursore che vogliono rendere disponibile:

  • DOVREBBE dichiarare il supporto per il flag di funzionalità android.hardware.faketouch.

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.faketouch:

  • [C-1-1] DEVE segnalare le posizioni sullo schermo X e Y assolute della posizione del cursore e mostrare un cursore visivo sullo schermo.
  • [C-1-2] È OBBLIGATORIO registrare l'evento tocco con il codice azione che specifica la modifica dello stato che si verifica quando il cursore si sposta verso il basso o verso l'alto sullo schermo.
  • [C-1-3] DEVE supportare il movimento del cursore 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 cursore verso il basso, il cursore verso l'alto, il cursore verso il basso e poi il cursore verso l'alto nello stesso punto su 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 cursore verso il basso in un punto arbitrario dello schermo, il cursore si sposta in un altro punto arbitrario dello schermo, seguito da un cursore verso l'alto, che consente agli utenti di emulare un trascinamento con tocco.
  • [C-1-6] DEVE supportare il cursore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in un'altra posizione sullo schermo e poi il cursore verso l'alto sullo schermo, in modo da consentire agli utenti di lanciare un oggetto sullo schermo.

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.faketouch.multitouch.distinct:

  • [C-2-1] È OBBLIGATORIO dichiarare il supporto di android.hardware.faketouch.
  • [C-2-2] DEVE supportare il monitoraggio distinto di due o più input del cursore indipendenti.

Se le implementazioni del dispositivo dichiarano il supporto di android.hardware.faketouch.multitouch.jazzhand:

  • [C-3-1] È OBBLIGATORIO dichiarare il supporto di android.hardware.faketouch.
  • [C-3-2] DEVE supportare il rilevamento distinto di 5 (monitoraggio di una mano di dita) o più input del cursore in modo completamente indipendente.

7.2.6. Supporto del controller di gioco

7.2.6.1. Mappature dei pulsanti

Implementazioni dei dispositivi:

  • [C-1-1] DEVE essere in grado di mappare gli eventi HID alle costanti InputEvent corrispondenti, come elencato nelle tabelle seguenti. L'implementazione Android a monte soddisfa questo requisito.

Se le implementazioni dei dispositivi includono un controller o vengono fornite con un controller separato nella confezione che consenta di inserire tutti gli eventi elencati nelle tabelle seguenti, devono:

  • [C-2-1] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.gamepad
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)
Pulsante direzionale su1
Pulsante direzionale giù1 		0x01 0x00393 AXIS_HAT_Y4
D-pad sinistra1
D-pad destra1 		0x01 0x00393 AXIS_HAT_X4
Pulsante del tasto sinistro1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Pulsante del tasto funzione destro1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clic con la levetta sinistra1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clic con il tasto destro della levetta1 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 per gamepad (0x01 0x0005).

3 Questo utilizzo deve avere un valore minimo logico di 0, un valore massimo logico di 7, un valore minimo fisico di 0, un valore massimo fisico di 315, unità in gradi e una dimensione del report di 4. Il valore logico è definito come la rotazione in senso orario dall'asse verticale; ad esempio, un valore logico pari a 0 indica che non è presente alcuna rotazione e che è stato premuto il tasto Su, mentre un valore logico pari a 1 indica una rotazione di 45 gradi e che sono stati premuti sia il tasto Su sia il tasto Sinistra.

4 MotionEvent

Controlli analogici1 Utilizzo HID Pulsante Android
Triangolo sinistro 0x02 0x00C5 AXIS_LTRIGGER
Trigger 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 dei dispositivi, consulta la sezione 2.3.1.

7.3. Sensori

Se le implementazioni del dispositivo includono un determinato tipo di sensore con un'API corrispondente per gli 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 dei dispositivi:

  • [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 di sensori (ad esempio, restituendo true o false a seconda dei casi quando le applicazioni tentano di registrare gli ascoltatori, non chiamando gli ascoltatori dei sensori quando i sensori corrispondenti non sono presenti e così via).

Se le implementazioni del dispositivo includono un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti, devono:

  • [C-1-1] È NECESSARIO segnalare tutte le misurazioni del sensore 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 del sensore con una latenza massima di 100 millisecondi + 2 * sample_time per il caso di uno stream del sensore con una latenza massima richiesta di 0 ms quando l'elaborazione dell'applicazione è attiva. Questo ritardo non include i ritardi dovuti ai filtri.
  • [C-1-3] DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time dall'attivazione del sensore. Per questo campione è accettabile una precisione pari a 0.
  • [C-1-4] Affinché qualsiasi API indicata dalla documentazione dell'SDK Android sia un sensore continuo, le implementazioni del dispositivo DEVONO fornire continuamente campioni di dati periodici che DEVONO avere un jitter inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori timestamp registrati tra eventi consecutivi.
  • [C-1-5] DEVE garantire che lo stream di eventi del sensore NON DEVE impedire alla CPU del dispositivo di entrare in uno stato di sospensione o di riattivarsi da uno stato di sospensione.
  • [C-1-6] DEVE registrare l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta l'ora in cui si è verificato l'evento e sincronizzata con l'orologio SystemClock.elapsedRealtimeNano().
  • [C-SR] È FORTEMENTE CONSIGLIATO avere un errore di sincronizzazione del timestamp inferiore a 100 millisecondi e DOVREBBE avere un errore di sincronizzazione del timestamp inferiore a 1 millisecondo.
  • Quando sono attivati più sensori, il consumo di energia NON DEVE superare la somma del consumo di energia registrato dal singolo sensore.

L'elenco riportato sopra non è esaustivo; il comportamento documentato dell'SDK Android e della documentazione Android Open Source sui sensori deve essere considerato autorevole.

Se le implementazioni del dispositivo includono un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti, devono:

  • [C-1-6] È NECESSARIO impostare una risoluzione diversa da zero per tutti i sensori e segnalare il valore tramite il metodo dell'API Sensor.getResolution().

Alcuni tipi di sensori sono composti, il che significa che possono essere ricavati dai dati forniti da uno o più altri sensori. Alcuni esempi sono il sensore di orientamento e il sensore di accelerazione lineare.

Implementazioni dei dispositivi:

  • DEVE implementare questi tipi di sensori, se includono i sensori fisici prerequisiti descritti in tipi di sensori.

Se le implementazioni del dispositivo includono un sensore composito:

  • [C-2-1] È NECESSARIO implementare il sensore come descritto nella documentazione Android Open Source sui sensori compositi.

Se le implementazioni dei dispositivi includono un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti e il sensore registra un solo valore, le implementazioni dei dispositivi:

  • [C-3-1] È NECESSARIO impostare la risoluzione su 1 per il sensore e segnalare il valore tramite il metodo API Sensor.getResolution().

Se le implementazioni del dispositivo includono un determinato tipo di sensore che supporta SensorAdditionalInfo#TYPE_VEC3_CALIBRATION e il sensore è esposto a sviluppatori di terze parti, questi:

  • [C-4-1] NON DEVE includere parametri di calibrazione fissi determinati in fabbrica nei dati forniti.

Se le implementazioni del dispositivo includono una combinazione di accelerometro a 3 assi, un sensore giroscopio a 3 assi o un sensore magnetometrico, sono:

  • [C-SR] È FORTEMENTE CONSIGLIATO assicurarsi che l'accelerometro, il giroscopio e il magnetometro abbiano una posizione relativa fissa, in modo che, se il dispositivo è trasformabile (ad es. pieghevole), gli assi del sensore rimangano allineati e coerenti con il sistema di coordinate del sensore in tutti i possibili stati di trasformazione del dispositivo.

7.3.1. Accelerometro

Implementazioni dei dispositivi:

  • [C-SR] È FORTEMENTE CONSIGLIATO includere un accelerometro a 3 assi.

Se le implementazioni del dispositivo includono un accelerometro a 3 assi, devono:

  • [C-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 50 Hz.
  • [C-1-2] È NECESSARIO implementare e segnalare il sensore TYPE_ACCELEROMETER.
  • [C-1-3] DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nelle API Android.
  • [C-1-4] DEVE essere in grado di misurare da 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 in base all'asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più elevata.
  • [SR] sono FORTEMENTE CONSIGLIATI per implementare il sensore composito TYPE_SIGNIFICANT_MOTION.
  • [SR] È MOLTO CONSIGLIATO implementare e segnalare il sensore TYPE_ACCELEROMETER_UNCALIBRATED. È FORTEMENTE CONSIGLIATO che i dispositivi Android soddisfino questo requisito per poter eseguire l'upgrade alla futura release della piattaforma, quando 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 dell'SDK Android.
  • DEVE registrare eventi fino ad almeno 200 Hz.
  • DEVE avere una risoluzione di almeno 16 bit.
  • DEVE essere calibrato durante l'uso se le caratteristiche cambiano nel ciclo di vita e vengono compensate e deve 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 sono implementati uno dei sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER:

  • [C-2-1] La somma del loro consumo di energia DEVE essere sempre inferiore a 4 mW.
  • DEVONO essere inferiori a 2 mW e 0,5 mW quando il dispositivo è in una condizione dinamica o statica.

Se le implementazioni del dispositivo includono un accelerometro a tre assi e un sensore giroscopio a tre assi, devono:

  • [C-3-1] È NECESSARIO implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • [C-SR] È FORTEMENTE CONSIGLIATO di implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

Se le implementazioni del dispositivo includono un accelerometro a 3 assi, un sensore giroscopio a 3 assi e un sensore magnetometro:

  • [C-4-1] È NECESSARIO implementare un sensore composito TYPE_ROTATION_VECTOR.

7.3.2. Magnetometro

Implementazioni dei dispositivi:

  • [C-SR] È MOLTO CONSIGLIATO includere un magnetometro a 3 assi (bussola).

Se le implementazioni del dispositivo includono un magnetometro a tre assi, devono:

  • [C-1-1] È OBBLIGATORIO implementare il sensore TYPE_MAGNETIC_FIELD.
  • [C-1-2] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 10 Hz e DOVREBBE registrare eventi fino ad almeno 50 Hz.
  • [C-1-3] DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nelle API Android.
  • [C-1-4] DEVE essere in grado di misurare tra -900 µT e +900 µT su ciascun asse prima della saturazione.
  • [C-1-5] DEVE avere un valore di offset 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 del bias hardware e conservare i parametri di compensazione tra i riavvii del dispositivo.
  • [C-1-8] È OBBLIGATORIO applicare la compensazione del ferro dolce. La calibrazione può essere eseguita durante l'uso o durante la produzione del dispositivo.
  • [C-1-9] DEVE avere una deviazione standard, calcolata in base all'asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più elevata, non superiore a 1,5 µT; DEVE avere una deviazione standard non superiore a 0,5 µT.
  • [C-SR] È MOLTO CONSIGLIATO implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Se le implementazioni del dispositivo includono un magnetometro a 3 assi, un sensore di accelerazione e un sensore giroscopio a 3 assi:

  • [C-2-1] È NECESSARIO implementare un sensore composito TYPE_ROTATION_VECTOR.

Se le implementazioni del dispositivo includono un magnetometro a 3 assi, un accelerometro:

  • PUO' implementare il sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Se le implementazioni del dispositivo includono un magnetometro a 3 assi, un accelerometro e un sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR, devono:

  • [C-3-1] DEVE consumare meno di 10 mW.
  • DEVE consumare meno di 3 mW quando il sensore è registrato per la modalità batch a 10 Hz.

7.3.3. GPS

Implementazioni dei dispositivi:

  • [C-SR] È MOLTO CONSIGLIATO includere un ricevitore GPS/GNSS.

Se le implementazioni dei dispositivi 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 le uscite di posizione a una frequenza di almeno 1 Hz quando richieste 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 prima correzione rapido), quando è connesso a una connessione a internet con velocità di trasferimento dati di almeno 0,5 Mbps. Questo requisito viene solitamente soddisfatto mediante l'utilizzo di una qualche forma di tecnica GPS/GNSS assistita o prevista per ridurre al minimo il tempo di accoppiamento GPS/GNSS (i dati di assistenza includono ora di riferimento, posizione di riferimento ed effemeride/orologio satellitare).
    • [C-1-6] Dopo aver eseguito questo calcolo della posizione, le implementazioni del dispositivo DEVONO determinare la posizione, in cielo aperto, entro 5 secondi, quando le richieste di geolocalizzazione 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 alimentazione.

  • In condizioni di cielo aperto dopo aver determinato la posizione, a veicolo 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 monitorare e segnalare contemporaneamente tramite GnssStatus.Callback almeno 8 satelliti di una costellazione.
    • DOVREBBE essere in grado di rilevare contemporaneamente almeno 24 satelliti di più costellazioni (ad es. GPS + almeno uno di Glonass, Beidou, Galileo).
    • [C-SR] È FORTEMENTE CONSIGLIATO continuare a fornire normali output di posizione GPS/GNSS tramite le API GNSS Location Provider durante una chiamata di emergenza.
    • [C-SR] È MOLTO CONSIGLIATO segnalare le misurazioni GNSS di tutte le costellazioni monitorate (come riportato nei messaggi GnssStatus), ad eccezione di SBAS.
    • [C-SR] È MOLTO CONSIGLIATO segnalare l'AGC e la frequenza della misurazione GNSS.
    • [C-SR] È FORTEMENTE CONSIGLIATO segnalare tutte le stime di accuratezza (incluse direzione, velocità e verticale) come parte di ogni posizione GPS/GNSS.
    • [C-SR] È FORTEMENTE CONSIGLIATO segnalare le misurazioni GNSS non appena vengono rilevate, anche se una posizione calcolata da GPS/GNSS non è ancora stata segnalata.
    • [C-SR] È FORTEMENTE CONSIGLIATO segnalare le pseudoraggi e le velocità di pseudoraggi GNSS che, in condizioni di cielo aperto dopo aver determinato la posizione, mentre sono fermi o si muovono 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 dei dispositivi:

  • [C-SR] È MOLTO CONSIGLIATO includere un sensore giroscopico.

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

  • [C-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 50 Hz.
  • [C-1-2] È OBBLIGATORIO implementare il sensore TYPE_GYROSCOPE ed È FORTEMENTE CONSIGLIATO 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 base alla temperatura.
  • [C-1-6] DEVE essere calibrato e compensato durante l'uso e deve 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 con la 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] È FORTEMENTE CONSIGLIATO che l'errore di calibrazione sia inferiore a 0,01 rad/s quando il dispositivo è fermo a temperatura ambiente.
  • DEVE registrare eventi fino ad almeno 200 Hz.

Se le implementazioni del dispositivo includono un giroscopio a 3 assi, un sensore di accelerometro e un sensore di magnetometro:

  • [C-2-1] È NECESSARIO implementare un sensore composito TYPE_ROTATION_VECTOR.

Se le implementazioni del dispositivo includono un accelerometro a tre assi e un sensore giroscopio a tre assi, devono:

  • [C-3-1] È NECESSARIO implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • [C-SR] È FORTEMENTE CONSIGLIATO di implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometro

Implementazioni dei dispositivi:

  • [C-SR] È MOLTO CONSIGLIATO includere un barometro (sensore di pressione dell'aria ambiente).

Se le implementazioni del dispositivo includono un barometro:

  • [C-1-1] È NECESSARIO implementare e segnalare il sensore TYPE_PRESSURE.
  • [C-1-2] DEVE essere in grado di inviare eventi a una frequenza di almeno 5 Hz.
  • [C-1-3] DEVE essere compensato in base alla temperatura.
  • [SR] FORTEMENTE CONSIGLIATO per poter registrare misurazioni della pressione nell'intervallo da 300 hPa a 1100 hPa.
  • DEVE avere una precisione assoluta di 1 hPa.
  • DEVE avere una precisione relativa di 0,12 hPa su un intervallo di 20 hPa (equivalente a una precisione di circa 1 m su una variazione di circa 200 m a livello del mare).

7.3.6. Termometro

Se le implementazioni del dispositivo includono un termometro ambiente (sensore di temperatura), devono:

  • [C-1-1] DEVE definire SENSOR_TYPE_AMBIENT_TEMPERATURE per il sensore di temperatura ambiente e il sensore DEVE misurare la temperatura ambiente (della stanza/della cabina del veicolo) da dove l'utente interagisce con il dispositivo in gradi Celsius.

Se le implementazioni dei dispositivi includono un sensore di temperatura che misura una temperatura diversa da quella ambiente, ad esempio la temperatura della CPU, devono:

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 del dispositivo includono un sensore di prossimità:

  • [C-1-1] DEVE misurare la prossimità di un oggetto nella stessa direzione dello schermo. In altre parole, il sensore di prossimità DEVE essere orientato in modo da rilevare gli oggetti vicini allo schermo, poiché lo scopo principale di questo tipo di sensore è rilevare uno smartphone in uso dall'utente. Se le implementazioni del dispositivo includono un sensore di prossimità con qualsiasi 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 per le app di terze parti, devono:

  • [C-1-1] DEVE identificare la funzionalità tramite il flag funzionalità android.hardware.sensor.hifi_sensors.

Se le implementazioni del dispositivo 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 ed è FORTEMENTE CONSIGLIATO 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 pari o inferiore a 12,5 Hz.
    • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DEVE supportare il canale SensorDirectChannel RATE_VERY_FAST.
    • DEVE avere un rumore di misurazione non superiore a 400 μg/√Hz.
    • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore.
    • DEVE avere un consumo energetico per il raggruppamento non superiore a 3 mW.
    • [C-SR] È FORTEMENTE CONSIGLIATO di 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 dell'accelerazione inferiore a 30 μg √Hz testata a temperatura ambiente.
    • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 1 mg/°C.
    • DEVE avere una non linearità della linea di adattamento ottimale pari o inferiore allo 0,5% e una variazione di sensibilità rispetto alla temperatura pari o inferiore allo 0,03%/°C.
    • DEVE avere una sensibilità sull'asse trasversale inferiore al 2,5 % e una variazione della sensibilità sull'asse trasversale inferiore allo 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 pari o inferiore a 12,5 Hz.
    • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DEVE supportare il canale SensorDirectChannel RATE_VERY_FAST.
    • DEVE avere un rumore di misurazione non superiore a 0,014°/s/√Hz.
    • [C-SR] È FORTEMENTE CONSIGLIATO di 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 deriva casuale della frequenza inferiore a 0,001 °/s √Hz testata a temperatura ambiente.
    • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 0,05 °/ s / °C.
    • DOVREBBE avere una variazione di sensibilità rispetto alla temperatura di ≤ 0,02% / °C.
    • DEVE avere una non linearità della linea di miglior adattamento pari o inferiore allo 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 compreso tra 10 e 40 °C quando il dispositivo è fermo.
    • DEVE avere una sensibilità g inferiore a 0,1°/s/g.
    • DEVE avere una sensibilità trasversale inferiore al 4,0 % e una variazione di sensibilità trasversale inferiore allo 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 pari o inferiore a 5 Hz.
    • DEVE avere una frequenza di misurazione massima di almeno 50 Hz.
    • DEVE avere un rumore di misurazione non superiore a 0,5 uT.

  • [C-2-6] DEVE avere un TYPE_MAGNETIC_FIELD_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GEOMAGNETIC_FIELD e, inoltre:

    • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 600 eventi del sensore.
    • [C-SR] È FORTEMENTE CONSIGLIATO avere uno spettro di rumore bianco da 1 Hz ad almeno 10 Hz quando la frequenza di generazione dei 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 pari o inferiore a 1 Hz.
    • DEVE avere una frequenza di misurazione massima di almeno 10 Hz.
    • DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz.
    • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
    • DEVE avere un consumo energetico per l'aggregazione 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 di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
  • [C-2-10] DEVE avere un sensore TYPE_STEP_DETECTOR che:
    • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 100 eventi del sensore.
    • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
    • DEVE avere un consumo energetico per il raggruppamento non superiore a 4 mW.
  • [C-2-11] DEVE avere un sensore TYPE_STEP_COUNTER che:
    • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
  • [C-2-12] DEVE avere un sensore TILT_DETECTOR che:
    • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
  • [C-2-13] Il timestamp dello stesso evento fisico registrato dall'accelerometro, dal giroscopio e dal magnetometro DEVE essere compreso tra 2, 5 millisecondi. Il timestamp dello stesso evento fisico registrato dall'accelerometro e dal giroscopio DEVE essere compreso in un intervallo di 0,25 millisecondi.
  • [C-2-14] DEVE avere i timestamp degli eventi del sensore giroscopico sulla stessa base di tempo del sottosistema della videocamera e con un errore massimo di 1 millisecondo.
  • [C-2-15] DEVE inviare i campioni alle applicazioni entro 5 millisecondi dal momento in cui i dati sono disponibili su uno dei sensori fisici sopra indicati per l'applicazione.
  • [C-2-16] NON DEVE avere un consumo di energia superiore a 0,5 mW quando il dispositivo è fermo e 2,0 mW quando il dispositivo è in movimento quando è attiva qualsiasi combinazione dei seguenti sensori:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] PUO' 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 dell'unità di elaborazione applicazioni. Sono incluse le potenze assorbite dall'intera catena del sensore: il sensore, eventuali circuiti di supporto, qualsiasi sistema di elaborazione del sensore dedicato e così via.

Se le implementazioni dei dispositivi includono il supporto diretto dei sensori, devono:

  • [C-3-1] È NECESSARIO 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.
  • DOVREBBE supportare i report sugli eventi tramite il canale diretto del sensore per il sensore principale (variante non sveglia) 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 relativa alla 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 di classe 3 (in precedenza Elevata), di classe 2 (in precedenza Debole) o di classe 1 (in precedenza Comodità) in base ai tassi di accettazione di spoofing e di attacco di impostori e alla sicurezza della pipeline biometrica. Questa classificazione determina le funzionalità del sensore biometrico per interfacciarsi con la piattaforma e con le applicazioni di terze parti. Per impostazione predefinita, i sensori sono classificati come Classe 1 e devono soddisfare requisiti aggiuntivi, come descritto di seguito, per essere classificati come Classe 2 o Classe 3. Sia i dati biometrici di classe 2 che quelli di classe 3 dispongono di funzionalità aggiuntive, come descritto di seguito.

Se le implementazioni del dispositivo rendono disponibile un sensore biometrico per le applicazioni di terze parti tramite android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, devono:

  • [C-4-1] DEVE soddisfare i requisiti per la biometria di classe 3 o classe 2 come definito in questo documento.
  • [C-4-2] DEVE riconoscere e rispettare ogni nome parametro definito come costante nella classe Authenticators e in qualsiasi combinazione. Al contrario, NON DEVE rispettare o riconoscere costanti intere passate ai metodi canAuthenticate(int) e setAllowedAuthenticators(int) diverse da quelle documentate come costanti pubbliche in Authenticators e qualsiasi combinazione di queste.
  • [C-4-3] È OBBLIGATORIO implementare l'azione ACTION_BIOMETRIC_ENROLL sui dispositivi con dati biometrici di classe 3 o classe 2. Questa azione DEVE presentare solo i punti di contatto per la registrazione per la biometria di classe 3 o classe 2.

Se le implementazioni dei dispositivi supportano la biometria passiva:

  • [C-5-1] PER IMPOSTAZIONE PREDEFINITA deve richiedere un passaggio di conferma aggiuntivo (ad es. la pressione di un pulsante).
  • [C-SR] È FORTEMENTE CONSIGLIATO avere un'impostazione che consenta agli utenti di ignorare la preferenza dell'applicazione e di richiedere sempre il passaggio di conferma.
  • [C-SR] È FORTEMENTE CONSIGLIATO di proteggere l'azione di conferma in modo che non possa essere falsificata da una compromissione del sistema operativo o del kernel. Ad esempio, significa che l'azione di conferma basata su un pulsante fisico viene inoltrata tramite un pin GPIO (input/output general purpose) di sola entrata di un elemento sicuro (SE) che non può essere azionato in nessun altro modo se non premendo un pulsante fisico.
  • [C-5-2] DEVE inoltre implementare un flusso di autenticazione implicita (senza passaggio di conferma) corrispondente a setConfirmationRequired(boolean), che le applicazioni possono impostare per l'utilizzo per i flussi di accesso.

Se le implementazioni dei dispositivi dispongono di più sensori biometrici:

  • [C-SR] È FORTEMENTE CONSIGLIATO di richiedere la conferma di una sola biometria per autenticazione (ad es. se sul dispositivo sono disponibili sia i sensori di impronte digitali che quelli del volto, onAuthenticationSucceeded deve essere inviato dopo la conferma di uno di questi).

Affinché le implementazioni dei dispositivi consentano l'accesso alle chiavi del keystore ad applicazioni di terze parti, devono:

  • [C-6-1] DEVE soddisfare i requisiti per la classe 3 come definiti in questa sezione di seguito.
  • [C-6-2] DEVE presentare solo dati biometrici di classe 3 quando l'autenticazione richiede BIOMETRIC_STRONG o l'autenticazione viene invocata con un CryptoObject.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come di classe 1 (in precedenza Comodità), devono:

  • [C-1-1] DEVE avere un tasso di accettazione errato inferiore allo 0,002%.
  • [C-1-2] È OBBLIGATORIO indicare che questa modalità potrebbe essere meno sicura di una sequenza, una password o un PIN efficaci ed elencare chiaramente i rischi della sua attivazione, se i tassi di accettazione di spoofing e furto d'identità sono superiori al 7%, come misurato dai protocolli di test di biometria di Android.
  • [C-1-3] DEVE applicare un limite di frequenza dei tentativi per almeno 30 secondi dopo cinque tentativi falsi per la verifica biometrica, dove un tentativo falso è un tentativo con una qualità di acquisizione adeguata (BIOMETRIC_ACQUIRED_GOOD) che non corrisponde a un dato biometrico registrato.
  • [C-1-4] DEVE impedire l'aggiunta di nuove informazioni biometriche senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare le credenziali esistenti o di aggiungerne di nuove (PIN/pattern/password) protette dal TEE. L'implementazione del progetto open source Android fornisce il meccanismo necessario nel framework.
  • [C-1-5] DEVE rimuovere completamente tutti i dati biometrici identificabili di un utente quando l'account dell'utente viene rimosso (anche tramite un ripristino dei dati di fabbrica).
  • [C-1-6] DEVE rispettare il singolo flag per il dato biometrico (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 lanciati con Android 10, 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 una delle seguenti condizioni:

    • un periodo di timeout di inattività di 4 ore OPPURE
    • 3 tentativi di autenticazione biometrica non riusciti.
    • Il periodo di timeout inattivo e il conteggio delle autenticazioni non riuscite vengono reimpostati dopo ogni conferma delle credenziali del dispositivo.

    L'upgrade dei dispositivi da una versione precedente di Android può essere esentato da C-1-8. * [C-SR] È FORTEMENTE CONSIGLIATO di utilizzare la logica del framework fornita dal progetto open source Android per applicare i vincoli specificati in [C-1-7] e [C-1-8] per i nuovi dispositivi. * [C-SR] È FORTEMENTE CONSIGLIATO di avere un tasso di rifiuto falso inferiore al 10%, misurato sul dispositivo. * [C-SR] È FORTEMENTE CONSIGLIATO di avere una latenza inferiore a 1 secondo, misurata dal momento in cui viene rilevato il dato biometrico fino allo sblocco dello schermo, per ogni dato biometrico registrato.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come di classe 2 (in precedenza debole), devono:

  • [C-2-1] DEVE soddisfare tutti i requisiti per la classe 1 sopra indicati.
  • [C-2-2] DEVE avere un tasso di accettazione di spoofing e furto d'identità non superiore al 20%, misurato in base ai protocolli di test di biometria Android.
  • [C-2-3] DEVE eseguire la corrispondenza biometrica in un ambiente di esecuzione isolato al di fuori dello spazio utente o del kernel di Android, ad esempio in un 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 tramite crittografia in modo che non possano essere acquisiti, letti o alterati al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro per l'ambiente di esecuzione isolato, come documentato nelle linee guida per l'implementazione sul sito del progetto open source Android.
  • [C-2-5] Per i dati biometrici basati sulla videocamera, durante l'autenticazione o la registrazione basata sulla biometria:
    • DEVE operare la fotocamera in una modalità che impedisca la lettura o la modifica dei frame della fotocamera al di fuori dell'ambiente di esecuzione isolato o un chip con un canale sicuro per l'ambiente di esecuzione isolato.
    • Per le soluzioni RGB con una sola videocamera, i frame della videocamera POSSONO essere leggibili all'esterno dell'ambiente di esecuzione isolato per supportare operazioni come l'anteprima per la registrazione, ma NON DEVONO essere alterabili.
  • [C-2-6] NON DEVE consentire ad applicazioni di terze parti di distinguere tra singole registrazioni biometriche.
  • [C-2-7] NON DEVE consentire l'accesso non criptato a dati biometrici identificabili o a dati derivati (ad esempio embedding) all'App Processor al di fuori del contesto del TEE.

  • [C-2-8] DEVE avere una pipeline di elaborazione sicura in modo che una compromissione del sistema operativo o del kernel non possa consentire l'iniezione diretta di dati per autenticarsi falsamente 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 esenti dal requisito.

  • [C-SR] È FORTEMENTE CONSIGLIATO includere il rilevamento della presenza per tutte le modalità biometriche e il rilevamento dell'attenzione per la biometria facciale.

Se le implementazioni dei dispositivi vogliono trattare un sensore biometrico come di classe 3 (in precedenza Efficace), devono:

  • [C-3-1] DEVE soddisfare tutti i requisiti della classe 2 sopra indicati, ad eccezione di [C-1-7] e [C-1-8]. I dispositivi sottoposti ad upgrade da una versione precedente di Android non sono esenti da C-2-7.
  • [C-3-2] DEVE avere un'implementazione del keystore basata su hardware.
  • [C-3-3] DEVE avere un tasso di accettazione di spoofing e furto d'identità non superiore al 7%, misurato in base ai protocolli di test di biometria Android.
  • [C-3-4] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) una volta ogni massimo 72 ore.

7.3.12. Sensore di posizione

Implementazioni dei dispositivi:

  • PUO' supportare il sensore di posa con 6 gradi di libertà.

Se le implementazioni del dispositivo supportano il sensore di posizione con 6 gradi di libertà, devono:

  • [C-1-1] È NECESSARIO implementare e segnalare il sensore TYPE_POSE_6DOF.
  • [C-1-2] DEVE essere più preciso del solo vettore di rotazione.

7.3.13. Sensore dell'angolo della cerniera

Se le implementazioni del dispositivo supportano un sensore dell'angolo della cerniera:

7.4. Connettività dei dati

7.4.1. Telefonia

Per "Telefonia", come utilizzato dalle API Android e in questo documento, si intende in modo specifico l'hardware relativo all'invio di chiamate vocali e di messaggi SMS tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano o meno essere con commutazione di pacchetti, ai fini di Android sono considerate indipendenti da qualsiasi connettività dati che possa essere implementata utilizzando la stessa rete. In altre parole, le API e la funzionalità "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 messaggi 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. In altre parole, Android è compatibile con dispositivi diversi dagli smartphone.

Se le implementazioni dei dispositivi includono la telefonia GSM o CDMA, devono:

  • [C-1-1] DEVE dichiarare il flag funzionalità android.hardware.telephony e altri flag delle sottofunzionalità in base alla tecnologia.
  • [C-1-2] DEVE implementare il supporto completo dell'API per la tecnologia in questione.

Se le implementazioni dei dispositivi non includono hardware di telefonia, devono:

  • [C-2-1] È OBBLIGATORIO implementare le API complete come no-op.

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, devono:

7.4.1.1. Compatibilità con il blocco dei numeri

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

  • [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 da un numero di telefono in "BlockedNumberProvider" senza alcuna interazione con le app. L'unica eccezione è quando il blocco dei numeri viene rimosso temporaneamente, 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 per la 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 per gli utenti secondari e l'elenco bloccato DEVE essere rispettato.
  • DOVREBBE eseguire la migrazione dei numeri bloccati nel fornitore 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 accettare o rifiutare la chiamata in arrivo quando l'utente è in una chiamata in corso effettuata da un'app di terze parti che non supporta la funzionalità di messa in attesa specificata tramite CAPABILITY_SUPPORT_HOLD.
  • [C-1-3] DEVE avere un'applicazione che implementi InCallService.

  • [C-SR] È MOLTO CONSIGLIATO informare l'utente che la risposta a una chiamata in arrivo interromperà una chiamata in corso.

    L'implementazione AOSP soddisfa questi requisiti tramite una notifica in primo piano che indica all'utente che la risposta a una chiamata in arrivo causerà l'interruzione dell'altra chiamata.

  • [C-SR] È FORTEMENTE CONSIGLIATO di precaricare l'app Telefono predefinita che mostra una voce del registro chiamate e il nome di un'app di terze parti nel suo registro chiamate quando l'app di terze parti imposta la chiave extra EXTRA_LOG_SELF_MANAGED_CALLS su PhoneAccount su true.

  • [C-SR] È FORTEMENTE CONSIGLIATO gestire gli eventi KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK dell'auricolare audio per le API android.telecom come indicato di seguito:
    • Chiama Connection.onDisconnect() quando viene rilevata una breve pressione dell'evento chiave durante una chiamata in corso.
    • Chiama Connection.onAnswer() quando viene rilevata una breve pressione 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 del CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementazioni dei dispositivi:

  • DEVE includere il supporto di una o più forme di 802.11.

Se le implementazioni dei dispositivi includono il supporto per 802.11 e mettono a disposizione la funzionalità a un'applicazione di terze parti, devono:

  • [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 di funzionamento, inclusi:
    • Anche quando lo schermo non è attivo.
    • Per le implementazioni dei dispositivi Android TV, anche in stato di alimentazione in standby.
  • [C-1-5] NON DEVE trattare la chiamata al metodo dell'API WifiManager.enableNetwork() come un'indicazione sufficiente per cambiare il Network attualmente attivo, che viene utilizzato per impostazione predefinita per il traffico delle applicazioni e restituito dai metodi dell'API ConnectivityManager come getActiveNetwork e registerDefaultNetworkCallback. In altre parole, possono disattivare l'accesso a internet fornito da qualsiasi altro provider di rete (ad es. dati mobili) solo se verificano correttamente che la rete Wi-Fi fornisce l'accesso a internet.
  • [C-1-6] È FORTEMENTE CONSIGLIATO, quando viene chiamato il metodo dell'API ConnectivityManager.reportNetworkConnectivity(), di rivalutare l'accesso a internet su Network e, una volta che la valutazione ha stabilito che l'attuale Network non fornisce più accesso a internet, passare a qualsiasi altra rete disponibile (ad es. dati mobili) che fornisca accesso a internet.
  • [C-SR] È MOLTO CONSIGLIATO randomizzare l'indirizzo MAC di origine e il numero di sequenza dei frame di richiesta di prova, una volta all'inizio di ogni scansione, mentre lo STA è disconnesso.
    • Ogni gruppo di frame di richiesta di prova che compone una scansione deve utilizzare un indirizzo MAC coerente (NON DEVE essere randomizzato a metà scansione).
    • Il numero di sequenza della richiesta di probe deve essere eseguito normalmente (in sequenza) tra le richieste di probe in una scansione.
    • Il numero di sequenza della richiesta di probe deve essere casuale tra l'ultima richiesta di probe di una scansione e la prima richiesta di probe della scansione successiva.
  • [C-SR] È MOLTO CONSIGLIATO, mentre lo STA è disconnesso, consentire solo i seguenti elementi nei frame di richiesta di esplorazione:
    • Set di parametri SSID (0)
    • DS Parameter Set (3)

Se le implementazioni dei dispositivi includono il supporto della modalità di risparmio energetico Wi-Fi come definita nello standard IEEE 802.11, devono:

  • [C-3-1] È OBBLIGATORIO 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 nel tempo di andata e ritorno tra il dispositivo e un punto di accesso quando il dispositivo è in modalità di blocco Wi-Fi a bassa latenza (WIFI_MODE_FULL_LOW_LATENCY) DEVE essere inferiore alla latenza durante una modalità di blocco Wi-Fi ad alte prestazioni (WIFI_MODE_FULL_HIGH_PERF).
  • [C-SR] È MOLTO CONSIGLIATO ridurre al minimo la latenza di andata e ritorno del Wi-Fi ogni volta che viene acquisito e applicato un blocco a bassa latenza (WIFI_MODE_FULL_LOW_LATENCY).

Se le implementazioni dei dispositivi supportano il Wi-Fi e lo utilizzano per la ricerca della posizione, devono:

7.4.2.1. Wi-Fi Direct

Implementazioni dei dispositivi:

  • DEVE includere il supporto di 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 dei dispositivi:

Se le implementazioni dei dispositivi includono il supporto di TDLS e TDLS è abilitato dall'API WiFiManager, i dispositivi:

  • [C-1-1] È OBBLIGATORIO dichiarare il supporto di TDLS tramite WifiManager.isTdlsSupported.
  • DEVI utilizzare TDLS solo quando è possibile E utile.
  • DOVREBBE avere qualche euristica e NON utilizzare TDLS quando il rendimento potrebbe essere peggiore rispetto al passaggio tramite il punto di accesso Wi-Fi.
7.4.2.3. Wi-Fi Aware

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Aware e mettono a disposizione la funzionalità per le app di terze parti, devono:

  • [C-1-1] DEVE implementare le API WifiAwareManager come descritto nella documentazione dell'SDK.
  • [C-1-2] È OBBLIGATORIO 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, a meno che non sia in corso un'operazione di misurazione Aware o non sia attivo un percorso dati Aware (la randomizzazione non è prevista finché il percorso dati è attivo).

Se le implementazioni del dispositivo includono il supporto di Wi-Fi Aware e Posizione Wi-Fi come descritto nella Sezione 7.4.2.5 ed espongono queste funzionalità ad app di terze parti, devono:

7.4.2.4. Wi-Fi Passpoint

Se le implementazioni dei dispositivi includono il supporto per 802.11 (Wi-Fi), devono:

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Passpoint:

  • [C-1-2] DEVE implementare le API WifiManager relative a Passpoint come descritto nella documentazione dell'SDK.
  • [C-1-3] DEVE supportare lo standard IEEE 802.11u, in particolare per quanto riguarda la rilevamento e la selezione della rete, come il servizio Generic Advertisement Service (GAS) e il protocollo Access Network Query Protocol (ANQP).

Al contrario, se le implementazioni dei dispositivi non includono il supporto di Wi-Fi Passpoint:

  • [C-2-1] L'implementazione delle API WifiManager relative a Passpoint DEVE generare un UnsupportedOperationException.
7.4.2.5. Posizione Wi-Fi (tempo di round trip Wi-Fi - RTT)

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi includono il supporto della posizione Wi-Fi e mettono a disposizione la funzionalità per le app di terze parti, devono:

  • [C-1-1] DEVE implementare le API WifiRttManager come descritto nella documentazione dell'SDK.
  • [C-1-2] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.wifi.rtt.
  • [C-1-3] DEVE randomizzare l'indirizzo MAC di origine per ogni burst RTT che viene 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 dei dispositivi:

  • DEVE includere il supporto per l'offload del keepalive Wi-Fi.

Se le implementazioni del dispositivo includono il supporto per l'offload del keepalive Wi-Fi ed espongono la funzionalità ad app di terze parti, devono:

  • [C-1-1] DEVE supportare l'API SocketKeepAlive.

  • [C-1-2] DEVE supportare almeno tre slot keepalive simultanei tramite Wi-Fi e almeno un slot keepalive tramite rete mobile.

Se le implementazioni dei dispositivi non includono il supporto per l'offload del keepalive Wi-Fi, i dispositivi:

7.4.2.7. Wi-Fi Easy Connect (Device Provisioning Protocol)

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Easy Connect e mettono a disposizione la funzionalità per le app di terze parti, devono:

7.4.3. Bluetooth

Se le implementazioni dei dispositivi supportano il profilo Bluetooth Audio:

  • DOVREBBE supportare codec audio avanzati e 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 (rispettivamente android.hardware.bluetooth e android.hardware.bluetooth_le) 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 (BLE), devono:

  • [C-3-1] È OBBLIGATORIO dichiarare la funzionalità hardware android.hardware.bluetooth_le.
  • [C-3-2] È NECESSARIO attivare le API Bluetooth basate su GATT (Generic Attribute Profile) come descritto nella documentazione dell'SDK e in android.bluetooth.
  • [C-3-3] DEVE riportare il valore corretto per BluetoothAdapter.isOffloadedFilteringSupported() per indicare se la logica di filtro per le classi dell'API ScanFilter è implementata.
  • [C-3-4] È OBBLIGATORIO indicare il valore corretto per BluetoothAdapter.isMultipleAdvertisementSupported() per indicare se la pubblicità a basso consumo energetico è supportata.
  • [C-3-5] È OBBLIGATORIO implementare un timeout per l'indirizzo privato risolvibile (RPA) non superiore a 15 minuti e ruotare l'indirizzo al timeout per proteggere la privacy dell'utente quando il dispositivo utilizza attivamente il BLE per la scansione o la pubblicità. Per evitare attacchi di temporizzazione, gli intervalli di timeout DEVONO essere randomizzati anche tra 5 e 15 minuti.
  • DOVREBBE supportare lo sgravio della logica di filtro sul chipset Bluetooth durante l'implementazione dell'API ScanFilter.
  • DOVREBBE supportare lo sgravio della scansione collettiva sul chipset Bluetooth.
  • DEVE supportare più annunci con almeno 4 slot.

Se le implementazioni dei dispositivi supportano il Bluetooth LE e lo utilizzano per la scansione della posizione, devono:

  • [C-4-1] DEVE fornire un'affordance utente per attivare/disattivare il valore letto tramite l'API di sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se le implementazioni dei dispositivi includono il supporto di Bluetooth LE e del profilo per apparecchi acustici, come descritto in Supporto audio per apparecchi acustici tramite Bluetooth LE, devono:

7.4.4. Near Field Communication

Implementazioni dei dispositivi:

  • DOVREBBE includere un transceiver e 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 per NFC o dichiarano la funzionalità android.hardware.nfc poiché le classi rappresentano un formato di rappresentazione dei dati indipendente dal protocollo.

Se le implementazioni dei dispositivi includono hardware NFC e prevedono di renderlo disponibile per le app di terze parti, devono:

  • [C-1-1] DEVE segnalare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature().
  • DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC:
  • [C-1-2] DEVE essere in grado di agire come lettore/scrittore NFC Forum (come definito dalla specifica tecnica NFC Forum 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 dal NFC Forum)

  • [SR] È MOLTO CONSIGLIATO che sia in grado di leggere e scrivere messaggi NDEF, nonché dati non elaborati, tramite i seguenti standard NFC. Tieni presente che, sebbene gli standard NFC siano indicati come FORTEMENTE CONSIGLIATI, è previsto che la definizione di compatibilità per una versione futura li modifichi in OBBLIGATORI. Questi standard sono facoltativi in questa versione, ma saranno obbligatori nelle versioni future. Consigliamo vivamente ai dispositivi esistenti e nuovi che eseguono questa versione di Android di soddisfare subito questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.

  • [C-1-13] DEVE eseguire la ricerca di tutte le tecnologie supportate in modalità di rilevamento NFC.

  • DOVREBBE essere in modalità di rilevamento NFC quando il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.
  • DOVREBBE 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à NFC Host Card Emulation (HCE).

Se le implementazioni dei dispositivi includono un chipset del controller NFC in grado di supportare HCE (per NfcA e/o NfcB) e supportano il routing dell'ID applicazione (AID), devono:

  • [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, devono:

  • [C-3-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.nfc.hcef.
  • [C-3-2] DEVE implementare le API di emulazione di carte 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, devono:

  • [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à standard di Android e, pertanto, non viene visualizzata come costante nella classe android.content.pm.PackageManager.

7.4.5. Protocolli e API di rete

7.4.5.1. Capacità di rete minima

Implementazioni dei dispositivi:

  • [C-0-1] DEVE includere il supporto di una o più forme di reti di dati. Nello specifico, le implementazioni dei dispositivi DEVONO includere il supporto di almeno uno standard di dati in grado di supportare una velocità di 200 Kbit/sec o superiore. Alcuni esempi di tecnologie che soddisfano questo requisito sono EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
  • DEVE includere anche il supporto di almeno uno standard di dati wireless comune, come 802.11 (Wi-Fi), quando uno standard di rete fisica (come Ethernet) è la connessione dati principale.
  • PUO' implementare più di una forma di connettività dei dati.
7.4.5.2. IPv6

Implementazioni dei dispositivi:

  • [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 le socket AF_INET6.
  • [C-0-3] DEVE attivare IPv6 per impostazione predefinita.
  • DEVE garantire che la comunicazione IPv6 sia affidabile quanto quella IPv4, ad esempio:
    • [C-0-4] DEVE mantenere la connettività IPv6 in modalità sospensione.
    • [C-0-5] Il limite di velocità NON DEVE causare la perdita della connettività IPv6 del dispositivo su qualsiasi rete IPv6 conforme che utilizza durate RA di almeno 180 secondi.
  • [C-0-6] DEVE fornire alle applicazioni di terze parti una connettività IPv6 diretta alla rete quando è connesso a una rete IPv6, senza alcuna forma di traduzione di indirizzi o porte localmente 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 e sono visibili come IP e porta di origine per i server internet (web).

Il livello di supporto IPv6 richiesto dipende dal tipo di rete, come indicato 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 a doppio stack e solo IPv6 su Ethernet.

Se le implementazioni dei dispositivi supportano la rete dati, devono:

  • [C-3-1] DEVE supportare il funzionamento IPv6 (solo IPv6 e possibilmente a doppio stack) su rete mobile.

Se le implementazioni dei dispositivi supportano più di un tipo di rete (ad es. Wi-Fi e dati mobili), devono:

  • [C-4-1] DEVE soddisfare contemporaneamente i requisiti sopra indicati su ogni rete quando il dispositivo è connesso contemporaneamente a più di un tipo di rete.
7.4.5.3. Captive portal

Un captive portal è una rete che richiede l'accesso per ottenere l'accesso a internet.

Se le implementazioni dei dispositivi forniscono un'implementazione completa del android.webkit.Webview API:

  • [C-1-1] DEVE fornire un'applicazione del portale captive per gestire l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN e visualizzare la pagina di accesso al portale captive inviando l'intent in chiamata all'API di sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle).
  • [C-1-2] DEVE eseguire il rilevamento dei captive portal e supportare l'accesso tramite l'applicazione captive portal quando il dispositivo è connesso a qualsiasi tipo di rete, inclusa la rete mobile/cellulare, Wi-Fi, Ethernet o Bluetooth.
  • [C-1-3] DEVE supportare l'accesso ai portali captive utilizzando il DNS in testo normale quando il dispositivo è configurato per utilizzare la modalità DNS privato rigorosa.
  • [C-1-4] È OBBLIGATORIO utilizzare il DNS criptato come da documentazione dell'SDK per android.net.LinkProperties.getPrivateDnsServerName e android.net.LinkProperties.isPrivateDnsActive per tutto il traffico di rete che non comunica esplicitamente con il captive portal.
  • [C-1-5] DEVE garantire che, mentre l'utente accede a un captive portal, la rete predefinita utilizzata dalle applicazioni (come restituita da ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback e utilizzata per impostazione predefinita dalle API di rete Java come java.net.Socket e dalle API native come connect()) sia qualsiasi altra rete disponibile che fornisca accesso a internet, se disponibile.

7.4.6. Impostazioni sincronizzazione

Implementazioni dei dispositivi:

  • [C-0-1] L'impostazione di sincronizzazione automatica principale DEVE essere 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 con misuratore, sono:

  • [SR] MOLTO CONSIGLIATO fornire la modalità Risparmio dati.

Se le implementazioni dei dispositivi forniscono la modalità Risparmio dati:

  • [C-1-1] DEVE supportare tutte le API della classe ConnectivityManager come descritto nella documentazione dell'SDK

Se le implementazioni dei dispositivi non forniscono la modalità Risparmio dati, devono:

7.4.8. Secure Element

Se le implementazioni dei dispositivi supportano elementi sicuri compatibili con l'API Open Mobile e li rendono disponibili per le app di terze parti, devono:

7.5. Fotocamere

Se le implementazioni dei dispositivi includono almeno una videocamera:

  • [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.camera.any.
  • [C-1-2] DEVE essere possibile per un'applicazione allocare contemporaneamente tre bitmap RGBA_8888 uguali alle dimensioni delle immagini prodotte dal sensore della fotocamera con la risoluzione più alta sul dispositivo, mentre la fotocamera è aperta a scopo di anteprima di base e acquisizione di foto.
  • [C-1-3] DEVE assicurarsi che l'applicazione della 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 inviarli all'applicazione di destinazione quando quest'ultima non dispone di ACCESS_FINE_LOCATION.

7.5.1. Fotocamera posteriore

Una fotocamera posteriore è una fotocamera situata sul lato del dispositivo opposto al display, ovvero acquisisce le immagini delle scene sul lato opposto del dispositivo, come una fotocamera tradizionale.

Implementazioni dei dispositivi:

  • DOVREBBE includere una fotocamera posteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera posteriore, devono:

  • [C-1-1] È OBBLIGATORIO segnalare i flag delle 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 l'autofocus software implementato nel driver della fotocamera (trasparente al software dell'applicazione).
  • POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
  • PUO' includere un flash.

Se la fotocamera include un flash:

  • [C-2-1] la spia del flash NON DEVE essere accesa quando è stata registrata un'istanza di android.hardware.Camera.PreviewCallback su una superficie di anteprima della fotocamera, 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 della fotocamera di sistema integrata del dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

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

Implementazioni dei dispositivi:

  • PUO' includere una fotocamera anteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera anteriore, devono:

  • [C-1-1] È OBBLIGATORIO segnalare i flag delle funzionalità android.hardware.camera.any e android.hardware.camera.front.
  • [C-1-2] DEVE avere una risoluzione di almeno VGA (640 x 480 pixel).
  • [C-1-3] NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Camera e NON DEVE configurare l'API in modo da trattare una fotocamera anteriore come fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
  • [C-1-4] L'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto all'orientamento specificato dall'applicazione quando l'applicazione corrente ha richiesto esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation(). Al contrario, l'anteprima DEVE essere speculare rispetto all'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 rispecchiare gli stream video o di fermo immagine acquisiti finali restituiti ai callback dell'applicazione o sottoposti a commit nello spazio di archiviazione multimediale.
  • [C-1-6] L'immagine visualizzata dalla visualizzazione post DEVE essere speculare rispetto a quella dello stream di immagini dell'anteprima della fotocamera.
  • PUO' 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 dei dispositivi possono essere ruotate dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente):

  • [C-2-1] L'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto all'orientamento corrente del dispositivo.

7.5.3. Videocamera esterna

Implementazioni dei dispositivi:

  • POTREBBE includere il supporto di una videocamera esterna non necessariamente sempre connessa.

Se le implementazioni dei dispositivi includono il supporto di una videocamera esterna:

  • [C-1-1] È OBBLIGATORIO dichiarare i flag delle funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any.
  • [C-1-2] DEVE supportare la classe video USB (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 di videocamera esterna fisica collegato. I dettagli dei test CTS della videocamera sono disponibili all'indirizzo source.android.com.
  • DOVREBBE supportare compressioni video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ad es. stream di immagini non compressi o compressi in modo indipendente).
  • POTREBBE supportare più videocamere.
  • POTREBBE supportare la codifica video basata sulla fotocamera.

Se la codifica video basata sulla videocamera è supportata:

  • [C-2-1] È OBBLIGATORIO che l'implementazione del dispositivo sia accessibile a uno stream non codificato / MJPEG simultaneo (risoluzione QVGA o superiore).

7.5.4. Comportamento dell'API Camera

Android include due pacchetti API per accedere alla fotocamera. La più recente API android.hardware.camera2 espone all'app il controllo della fotocamera a livello inferiore, inclusi flussi di scatti/streaming efficienti a copia zero e controlli per fotogramma di esposizione, guadagno, guadagni del bilanciamento del bianco, conversione del colore, riduzione del rumore, affinamento e altro ancora.

Il pacchetto API precedente,android.hardware.Camera, è contrassegnato come deprecato in Android 5.0, ma dovrebbe essere ancora disponibile per le 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 deprecata android.hardware.Camera e il pacchetto più recente android.hardware.camera2 DEVONO avere prestazioni e qualità equivalenti in entrambe le API. Ad esempio, con impostazioni equivalenti, la velocità e la precisione dell'autofocus devono essere identiche e la qualità delle immagini acquisite deve essere la stessa. Le funzionalità che dipendono dalla semantica diversa delle due API non devono necessariamente avere la stessa velocità o qualità, ma DEVONO corrispondere il più possibile.

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

  • [C-0-1] È OBBLIGATORIO 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 essere inoltre 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 in byte[] passati a onPreviewFrame(). In altre parole, NV21 DEVE essere il valore predefinito.
  • [C-0-3] DEVE supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia per le fotocamere anteriori che posteriori per android.hardware.Camera. Il codificatore video hardware e la videocamera possono utilizzare qualsiasi formato di 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 l'autofocus hardware o altre funzionalità. Ad esempio, le fotocamere prive di messa a fuoco automatica DEVONO comunque chiamare le eventuali istanze android.hardware.Camera.AutoFocusCallback registrate (anche se questo non ha alcuna rilevanza per una fotocamera senza messa a fuoco automatica). Tieni presente che questo vale per le fotocamere anteriori; ad esempio, anche se la maggior parte delle fotocamere anteriori non supporta l'autofocus, i callback dell'API devono comunque essere "falsi" 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 dei dispositivi NON DEVONO rispettare o riconoscere costanti di stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. In altre parole, le implementazioni dei dispositivi DEVONO supportare tutti i parametri Camera standard, se l'hardware lo consente, e NON DEVONO supportare i tipi di parametri Camera personalizzati. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini utilizzando tecniche di imaging HDR (High Dynamic Range) DEVONO supportare il parametro della fotocamera 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 singole funzionalità della videocamera di android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag di funzionalità appropriati; DEVE definire il flag di funzionalità se uno dei dispositivi videocamera collegati supporta la funzionalità.
  • [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 al media store.
  • [C-0-10] DEVE trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e la voce della foto è stata aggiunta al media store.
  • [C-0-11] È OBBLIGATORIO che tutte le videocamere siano accessibili tramite l'API deprecata android.hardware.Camera e anche tramite l'API android.hardware.camera2.
  • [C-0-12] È OBBLIGATORIO assicurarsi che l'aspetto del viso NON venga alterato, inclusa, a titolo esemplificativo, la geometria del viso, la tonalità della pelle del viso o la levigatezza della pelle del viso per qualsiasi API android.hardware.camera2 o android.hardware.Camera.
  • [C-SR] Per i dispositivi con più videocamere RGB rivolte nella stessa direzione, è FORTEMENTE 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 di fotocamera proprietaria alle app di terze parti:

7.5.5. Orientamento della fotocamera

Se le implementazioni del dispositivo dispongono di 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. In altre parole, quando il dispositivo è tenuto in orizzontale, le fotocamere DEVONO acquisire le immagini in orizzontale. Questo vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica ai dispositivi con orientamento principale orizzontale e verticale.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

Implementazioni dei dispositivi:

  • [C-0-1] DEVE includere un gestore dei download che le applicazioni POSSONO utilizzare per scaricare file di dati e DEVE essere in grado di scaricare singoli file di dimensioni di almeno 100 MB nella posizione predefinita "cache".

7.6.2. Spazio di archiviazione condiviso dell'applicazione

Implementazioni dei dispositivi:

  • [C-0-1] DEVE offrire spazio di archiviazione da condividere con le applicazioni, spesso indicato anche come "spazio di archiviazione esterno condiviso", "spazio di archiviazione condiviso per le applicazioni" o dal percorso Linux "/sdcard" su cui è montato.
  • [C-0-2] DEVE essere configurato con lo spazio di archiviazione condiviso montato per impostazione predefinita, in altre parole "out of the box", indipendentemente dal fatto che lo spazio di archiviazione sia implementato su un componente di archiviazione interno o su un supporto di archiviazione rimovibile (ad es. slot per schede Secure Digital).
  • [C-0-3] È NECESSARIO 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] È OBBLIGATORIO attivare lo spazio di archiviazione limitato per impostazione predefinita per tutte le app che hanno come target il livello API 29 o versioni successive, tranne nella seguente situazione:
    • Quando l'app ha richiesto android:requestLegacyExternalStorage="true" nel file manifest.
  • [C-0-5] È OBBLIGATORIO oscurare i metadati sulla posizione, ad esempio i tag EXIF GPS, memorizzati nei file multimediali quando si accede a questi file tramite MediaStore, tranne quando l'app chiamante dispone dell'autorizzazione ACCESS_MEDIA_LOCATION.

Le implementazioni dei dispositivi POSSONO soddisfare i requisiti sopra indicati utilizzando una delle seguenti opzioni:

  • Spazio di archiviazione rimovibile accessibile all'utente, ad esempio uno slot per schede Secure Digital (SD).
  • Una parte della memoria interna (non rimovibile) implementata nell'Android Open Source Project (AOSP).

Se le implementazioni dei dispositivi utilizzano lo spazio di archiviazione rimovibile per soddisfare i requisiti sopra indicati:

  • [C-1-1] DEVE implementare un'interfaccia utente popup o di tipo toast che avvisi l'utente quando non è presente alcun supporto di archiviazione inserito nello slot.
  • [C-1-2] DEVE includere un supporto di archiviazione con formato FAT (ad es. una scheda SD) o indicare 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 sopra indicati:

  • DOVREBBE utilizzare l'implementazione AOSP dello spazio di archiviazione condiviso dell'applicazione interna.
  • POTREBBE condividere lo spazio di archiviazione con i dati privati dell'applicazione.

Se le implementazioni dei dispositivi dispongono di una porta USB con supporto della modalità periferica USB, devono:

  • [C-3-1] DEVE fornire un meccanismo per accedere ai dati nello spazio di archiviazione condiviso dell'applicazione da un computer host.
  • DOVREBBE esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione multimediale di Android e android.provider.MediaStore.
  • PUO' utilizzare la memoria di massa USB, ma DEVE utilizzare il protocollo Media Transfer per soddisfare questo requisito.

Se le implementazioni dei dispositivi dispongono di una porta USB con modalità periferica USB e supportano il protocollo Media Transfer, devono:

  • DEVE essere compatibile con l'host MTP Android di riferimento, Android File Transfer.
  • DOVREBBE segnalare una classe di dispositivo USB pari a 0x00.
  • DOVREBBE riportare il nome dell'interfaccia USB "MTP".

7.6.3. Spazio di archiviazione utilizzabile

Se il dispositivo è di natura mobile, a differenza della TV, le implementazioni del dispositivo sono:

  • [RP] È FORTEMENTE CONSIGLIATO di implementare lo spazio di archiviazione adottabile in una posizione stabile a lungo termine, poiché la disconnessione accidentale può causare la perdita/corruzione 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 dei dispositivi dispongono di una porta USB:

  • DOVREBBE supportare la modalità periferica USB e la modalità host USB.

7.7.1. Modalità periferica USB

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità periferica:

  • [C-1-1] La porta DEVE essere connettibile a un host USB con una porta USB standard di tipo A o C.
  • [C-1-2] DEVE riportare il valore corretto di iSerialNumber nel descrittore del dispositivo standard USB tramite android.os.Build.SERIAL.
  • [C-1-3] DEVE rilevare i caricabatterie da 1,5 A e 3 A in base allo standard del resistore di tipo C e DEVE rilevare le modifiche nell'annuncio se supportano USB di tipo C.
  • [SR] La porta DEVE utilizzare il fattore di forma USB micro-B, micro-AB o Type-C. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release 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. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
  • [SR] DOVREBBE implementare il supporto per assorbire una corrente di 1,5 A durante il traffico e il chirp HS come specificato nella specifica di ricarica della batteria USB, revisione 1.2. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
  • [SR] È FORTEMENTE CONSIGLIATO di non supportare metodi di ricarica proprietari che modificano la tensione Vbus oltre i livelli predefiniti o alterano i ruoli di sink/sorgente, in quanto potrebbero verificarsi problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard di Power Delivery USB. Sebbene sia indicato come "FORTEMENTE CONSIGLIATO", nelle versioni future di Android potremmo RICHIEDERE a tutti i dispositivi Type-C di supportare la piena interoperabilità con i caricabatterie Type-C standard.
  • [SR] È FORTEMENTE CONSIGLIATO supportare Power Delivery per lo scambio di ruoli di alimentazione e dati 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 la visualizzazione.
  • DEVE implementare l'API e la specifica Android Open Accessory (AOA) come descritto nella documentazione dell'SDK Android.

Se le implementazioni dei dispositivi includono una porta USB e implementano la specifica AOA, devono:

  • [C-2-1] DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.accessory.
  • [C-2-2] La classe di archiviazione di massa USB DEVE includere la stringa "android" 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, devono:

  • [C-1-1] DEVE implementare l'API host USB Android come documentato nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host.
  • [C-1-2] DEVONO implementare il supporto per il collegamento di periferiche USB standard, in altre parole DEVONO:
    • Avere una porta di tipo C sul dispositivo o essere dotato di cavi che adattano una porta proprietaria sul dispositivo a una porta USB Type-C standard (dispositivo USB Type-C).
    • Avere un connettore di tipo A sul dispositivo o essere fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB di tipo A standard.
    • Avere una porta micro-AB sul dispositivo, che DOVREBBE essere fornita con un cavo adattabile a una porta di tipo A standard.
  • [C-1-3] NON deve essere fornito con un adattatore che converte da porte USB di tipo A o micro-AB a una porta di tipo C (presa).
  • [C-SR] È FORTEMENTE CONSIGLIATO implementare la classe audio USB come descritto nella documentazione dell'SDK Android.
  • DEVE supportare la ricarica del dispositivo periferico USB collegato in modalità host; deve pubblicizzare una corrente di alimentazione di almeno 1,5 A come specificato nella sezione Parametri di terminazione della USB Type-C Cable and Connector Specification Revision 1.2 per i connettori USB Type-C o utilizzare l'intervallo di corrente di uscita della porta di ricarica a valle(CDP) come specificato nelle USB Battery Charging specifications, revision 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, devono:

  • [C-2-1] DEVE supportare la classe HID USB.
  • [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), devono:

  • [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à della porta con doppio ruolo come definita dalla specifica USB Type-C (sezione 4.5.1.3.3).
  • [SR] È MOLTO CONSIGLIATO supportare DisplayPort, DOVREBBE supportare le velocità di trasferimento dati USB SuperSpeed ed È MOLTO CONSIGLIATO supportare Power Delivery per lo scambio di ruoli di alimentazione e dati.
  • [RP] È FORTEMENTE CONSIGLIATO di NON supportare la modalità accessorio dell'adattatore audio come descritto nell'appendice A della Revisione 1.2 della specifica del cavo e del connettore USB Type-C.
  • DOVREBBE implementare il modello Try.* più appropriato per il fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DOVREBBE implementare il modello Try.SNK.

7.8. Audio

7.8.1. Microfono

Se le implementazioni dei dispositivi includono un microfono:

  • [C-1-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.microphone.
  • [C-1-2] DEVE soddisfare i requisiti di registrazione audio descritti nella sezione 5.4.
  • [C-1-3] DEVE soddisfare i requisiti di latenza audio descritti nella sezione 5.6.
  • [SR] È MOLTO CONSIGLIATO supportare la registrazione in modalità quasi ultrasuoni 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] È OBBLIGATORIO implementare l'API di registrazione audio almeno come no-op, come indicato nella sezione 7.

7.8.2. Uscita audio

Se le implementazioni del dispositivo includono uno speaker o una porta di uscita audio/multimediale per una periferica di uscita audio, ad esempio un jack audio da 3,5 mm a 4 conduttori o una porta in modalità host USB che utilizza la classe audio USB, devono:

  • [C-1-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.audio.output.
  • [C-1-2] DEVE soddisfare i requisiti di riproduzione audio descritti nella sezione 5.5.
  • [C-1-3] DEVE soddisfare i requisiti di latenza audio descritti nella sezione 5.6.
  • [SR] È MOLTO CONSIGLIATO supportare la riproduzione a frequenza quasi ultrasonica come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono uno speaker o una porta di uscita audio, devono:

  • [C-2-1] NON DEVE segnalare la funzionalità android.hardware.audio.output.
  • [C-2-2] È NECESSARIO implementare le API relative all'output audio almeno come no-op.

Ai fini di questa sezione, una "porta di uscita" è un'interfaccia fisica, ad esempio un jack audio da 3,5 mm, HDMI o una porta in modalità host USB con classe audio USB. Il supporto dell'uscita audio tramite protocolli basati su radio, come Bluetooth, Wi-Fi o rete mobile, non è considerato come "porta di uscita".

7.8.2.1. Porte audio analogiche

Per essere compatibili con le cuffie e altri accessori audio che utilizzano il jack audio da 3,5 mm nell'ecosistema Android, se le implementazioni dei dispositivi includono una o più porte audio analogiche, devono:

  • [C-SR] È FORTEMENTE CONSIGLIATO includere almeno una delle porte audio con un jack audio da 3,5 mm a 4 conduttori.

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

  • [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 ai codici a tasti per i seguenti tre intervalli di impedenza equivalente tra i conduttori del microfono e della 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 quando viene inserito il connettore, ma solo dopo che tutti i contatti del connettore toccano i relativi segmenti sul jack.
  • [C-1-5] DEVE essere in grado di alimentare almeno 150 mV ± 10% di tensione di uscita su un'impedenza dello speaker 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 al codice a chiave il seguente intervallo di impedenza equivalente tra i conduttori del microfono e della messa a terra sul connettore audio:
    • 110-180 ohm: KEYCODE_VOICE_ASSIST
  • [C-SR] È FORTEMENTE CONSIGLIATO supportare i connettori audio con l'ordine di pinout OMTP.
  • [C-SR] È MOLTO CONSIGLIATO 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 extra del microfono impostato su 1, devono:

  • [C-2-1] DEVE supportare il rilevamento del microfono sull'accessorio audio collegato.
7.8.2.2. Porte audio digitali

Per essere compatibile con le cuffie e altri accessori audio che utilizzano connettori USB-C e implementano la classe audio USB nell'ecosistema Android, come definito nella specifica delle cuffie USB Android.

Per i requisiti specifici dei dispositivi, consulta la sezione 2.2.1.

7.8.3. Near-Ultrasound

L'audio quasi a ultrasuoni è la banda da 18,5 kHz a 20 kHz.

Implementazioni dei dispositivi:

  • DEVE segnalare correttamente il supporto della funzionalità audio a frequenza quasi ultrasonica tramite l'API AudioManager.getProperty come segue:

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 superiore a 15 dB al di sotto della risposta a 2 kHz.
  • [C-1-2] Il rapporto segnale/rumore non pesato del microfono in un intervallo di frequenza compreso tra 18,5 kHz e 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 nella gamma di frequenza 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 dei dispositivi: * DEVONO fornire un percorso del segnale audio senza glitch sia per gli stream di input che per quelli di output sui dispositivi portatili, come definito da zero glitch misurati durante un test di un minuto per percorso. Esegui il test utilizzando il "test automatico dei glitch" di [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester).

Il test richiede un dongle loopback audio, da utilizzare direttamente in un jack da 3,5 mm e/o in combinazione con un adattatore da USB-C a 3,5 mm. È NECESSARIO testare tutte le porte di uscita audio.

OboeTester attualmente supporta i percorsi AAudio, pertanto le seguenti combinazioni DOVREBBERO essere testate per verificare la presenza di glitch utilizzando AAudio:

Modalità Perf Condivisione Frequenza di campionamento in uscita In canali 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

Uno stream 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 uno speaker di riferimento esterno < 3,0% >= 50 dB
Jack da 3,5 mm analogici integrati, testati utilizzando l'adattatore di loopback < 1% >= 60 dB
Adattatori USB forniti in dotazione 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), incluse 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 di sistema monoculare quando un'applicazione VR ha l'attenzione dell'utente.

7.9.2. Modalità realtà virtuale - Prestazioni elevate

Se le implementazioni dei dispositivi supportano la modalità VR:

  • [C-1-1] DEVE avere almeno 2 core fisici.
  • [C-1-2] È OBBLIGATORIO dichiarare la funzionalità android.hardware.vr.high_performance.
  • [C-1-3] DEVE supportare la modalità di prestazioni sostenute.
  • [C-1-4] È FORTEMENTE CONSIGLIATO supportare OpenGL ES 3.2.
  • [C-1-5] DEVE supportare android.hardware.vulkan.level 0.
  • DEVE supportare android.hardware.vulkan.level 1 o versioni successive.
  • [C-1-6] È OBBLIGATORIO implementare EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace ed esporre le estensioni nell'elenco delle estensioni EGL disponibili.
  • [C-1-8] DEVE implementare GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
  • [C-SR] È FORTEMENTE CONSIGLIATO implementare GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
  • [C-SR] È MOLTO CONSIGLIATO supportare Vulkan 1.1.
  • [C-SR] È FORTEMENTE CONSIGLIATO implementare VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image e esporli 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 che 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 anteriore condiviso in modo che il rendering con l'occhio alternato 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 per i 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 i AHardwareBuffer con qualsiasi combinazione di 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ù livelli e flag e formati specificati in C-1-10.
  • [C-1-11] DEVE supportare la decodifica H.264 di almeno 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 compressi 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 di almeno 1920 x 1080.
  • [C-SR] È FORTEMENTE CONSIGLIATO avere una risoluzione del display di almeno 2560 x 1440.
  • [C-1-15] Il display DEVE aggiornarsi ad almeno 60 Hz in modalità VR.
  • [C-1-17] Il display DEVE supportare una modalità a bassa persistenza con una persistenza massima di 5 millisecondi, dove persistenza viene definita come il periodo di 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] È MOLTO CONSIGLIATO supportare il tipo di canale diretto TYPE_HARDWARE_BUFFER per tutti i tipi di canale diretto 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 del movimento al fotone non superiore a 28 millisecondi.
  • [C-SR] È FORTEMENTE CONSIGLIATO di avere una latenza end-to-end del movimento al fotone non superiore a 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 stabile, di almeno l'85%.
  • [C-SR] È FORTEMENTE CONSIGLIATO avere un rapporto del primo frame di almeno il 90%.
  • PUO' fornire un core esclusivo all'applicazione in primo piano e PUO' supportare l'API Process.getExclusiveCores per restituire i numeri dei core della CPU esclusivi dell'applicazione in primo piano principale.

Se il core esclusivo è supportato, il core:

  • [C-2-1] NON DEVE consentire l'esecuzione di altri processi nello spazio utente (tranne i driver di dispositivo utilizzati dall'applicazione), ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

7.10. Tecnologia aptica

Per i requisiti specifici dei dispositivi, consulta la sezione 2.2.1.

7.11. Classe di rendimento dei media

La classe di prestazioni multimediali dell'implementazione del dispositivo può essere ottenuta dall'API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. I requisiti per la classe di rendimento dei contenuti multimediali sono definiti per ogni versione di Android a partire da R (versione 30). Il valore speciale 0 indica che il dispositivo non appartiene a una classe di prestazioni media.

Se le implementazioni del dispositivo restituiscono un valore diverso da zero per android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, devono:

  • [C-1-1] DEVE restituire almeno un valore pari a android.os.Build.VERSION_CODES.R.

  • [C-1-2] DEVE essere un'implementazione di un dispositivo portatile.

  • [C-1-3] DEVE soddisfare tutti i requisiti per la "Classe di rendimento dei contenuti multimediali" descritti nella sezione 2.2.7.

Per i requisiti specifici del dispositivo, consulta la sezione 2.2.7.

8. Prestazioni e potenza

Alcuni criteri minimi di prestazioni e potenza sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di riferimento che gli sviluppatori dovrebbero fare durante lo sviluppo di un'app.

8.1. Coerenza dell'esperienza utente

È possibile fornire all'utente finale un'interfaccia utente fluida se sono presenti determinati requisiti minimi per garantire una frequenza frame e tempi di risposta coerenti per applicazioni e giochi. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POTREBBERO avere requisiti misurabili per la latenza dell'interfaccia utente e il passaggio da un'attività all'altra, come descritto nella sezione 2.

8.2. Prestazioni di accesso I/O file

Fornire una linea di base comune per un rendimento coerente dell'accesso ai file nell'archiviazione dei dati privati dell'applicazione (partizione /data) consente agli sviluppatori di app di impostare un'aspettativa adeguata che possa essere utile per il design del software. Le implementazioni dei dispositivi, a seconda del tipo, POTREBBERO 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.
  • Rendimento delle scritture casuali. Misurato scrivendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.
  • Rendimento di lettura sequenziale. Misurato leggendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
  • Rendimento della 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 del dispositivo includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo incluse in AOSP (ad es. App Standby Bucket, Sospensione) o estendono le funzionalità che non applicano restrizioni più severe rispetto al bucket Rare App Standby, devono:

  • [C-1-1] NON DEVE discostarsi dall'implementazione di AOSP per gli algoritmi di attivazione, manutenzione e risveglio e per l'utilizzo delle impostazioni di sistema globali delle modalità di risparmio energetico App Standby e Sospensione.
  • [C-1-2] NON DEVE discostarsi dall'implementazione AOSP per l'utilizzo delle impostazioni globali per gestire il throttling di job, sveglie e rete per le app in ogni bucket per la modalità in attesa delle app.
  • [C-1-3] NON DEVE discostarsi dall'implementazione AOSP per il numero di bucket di app in standby utilizzati per questa funzionalità.
  • [C-1-4] È NECESSARIO implementare i bucket di app in standby e la modalità Sospensione come descritto in Gestione dell'alimentazione.
  • [C-1-5] DEVE restituire true per PowerManager.isPowerSaveMode() quando il dispositivo è in modalità di risparmio energetico.
  • [C-SR] È FORTEMENTE CONSIGLIATO fornire all'utente la possibilità di attivare e disattivare la funzionalità di risparmio energetico.
  • [C-SR] È FORTEMENTE CONSIGLIATO fornire all'utente la possibilità di visualizzare tutte le app esenti dalle modalità di risparmio energetico App Standby e Sospensione.

Se le implementazioni del dispositivo estendono le funzionalità di gestione dell'alimentazione incluse in AOSP e questa estensione applica restrizioni più stringenti rispetto al bucket Rare App Standby, consulta la sezione 3.5.1.

Oltre alle modalità di risparmio energetico, le implementazioni dei dispositivi Android POSSONO implementare uno o tutti e quattro gli stati di alimentazione in sospensione come definiti dall'Advanced Configuration and Power Interface (ACPI).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S4 come definiti dall'ACPI, devono:

  • [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 TV) e prima che l'utente riattivi il dispositivo (ad es. aprendo il coperchio o riaccendendo il veicolo o la TV).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S3 come definiti dall'ACPI, devono:

  • [C-2-1] DEVE soddisfare C-1-1 sopra indicato OPPURE DEVE entrare nello stato S3 solo quando le applicazioni di terze parti non richiedono le risorse di sistema (ad es. lo schermo, la CPU).

    Al contrario, DEVE uscire dallo stato S3 quando le applicazioni di terze parti richiedono le 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 in esecuzione la CPU 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 inviato ad app di terze parti, il dispositivo DEVE uscire dallo stato S3, a meno che l'utente non lo abbia messo in uno stato di inattività. Questi non sono esempi esaustivi e AOSP implementa indicatori di risveglio estesi che attivano un risveglio da questo stato.

8.4. Contabilità del consumo energetico

Una contabilità e una generazione di report più accurati sul consumo di energia forniscono allo sviluppatore di app gli incentivi e gli strumenti per ottimizzare il pattern di utilizzo dell'energia dell'applicazione.

Implementazioni dei dispositivi:

  • [SR] È FORTEMENTE CONSIGLIATO fornire un profilo di alimentazione per componente che definisca il valore di consumo corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
  • [SR] È FORTEMENTE CONSIGLIATO segnalare tutti i valori di consumo di energia in milliampere ora (mAh).
  • [RP] È FORTEMENTE CONSIGLIATO segnalare il consumo energetico della CPU per UID di ogni processo. Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
  • [SR] VIVAMENTE CONSIGLIATO di rendere disponibile questo consumo di energia tramite il comando shell adb shell dumpsys batterystats per lo sviluppatore dell'app.
  • DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.

8.5. Prestazioni costanti

Le prestazioni possono variare notevolmente per le app ad alte prestazioni a lungo termine, a causa delle altre app in esecuzione in background o del throttling della CPU a causa dei limiti di temperatura. Android include interfacce programmatiche in modo che, se il dispositivo è compatibile, l'applicazione in primo piano più importante possa richiedere al sistema di ottimizzare l'allocazione delle risorse per gestire queste fluttuazioni.

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi segnalano il supporto della modalità di prestazioni sostenute:

  • [C-1-1] DEVE fornire all'applicazione in primo piano 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, devono:

  • DEVE fornire almeno un core esclusivo che può essere riservato dall'applicazione in primo piano principale.

Se le implementazioni del dispositivo supportano la prenotazione di un core esclusivo per l'applicazione in primo piano principale, devono:

  • [C-2-1] DEVE segnalare tramite il metodo dell'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 di dispositivo utilizzati dall'applicazione, sui core esclusivi, ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

Se le implementazioni dei dispositivi non supportano un core esclusivo:

9. Compatibilità del modello di sicurezza

Implementazioni dei dispositivi:

  • [C-0-1] DEVE implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API della documentazione per sviluppatori Android.

  • [C-0-2] DEVE supportare l'installazione di applicazioni con firma autografata senza richiedere autorizzazioni/certificati aggiuntivi da parte di terze parti/autorità. In particolare, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle sottosezioni seguenti.

9.1. Autorizzazioni

Implementazioni dei dispositivi:

  • [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, alterata o ignorata.

  • PUO' aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe ID autorizzazione non siano nello spazio dei nomi android.\*.

  • [C-0-2] Le autorizzazioni con un valore protectionLevel pari a PROTECTION_FLAG_PRIVILEGED DEVONO essere concesse solo alle app preinstallate nei percorsi privilegiati dell'immagine di sistema e all'interno del sottoinsieme di 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 in fase di esecuzione.

Implementazioni dei dispositivi:

  • [C-0-3] DEVE mostrare un'interfaccia dedicata che consenta all'utente di decidere se concedere le autorizzazioni di runtime richieste e fornire un'interfaccia per la gestione delle autorizzazioni di runtime.
  • [C-0-4] DEVE avere 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] È NECESSARIO concedere l'autorizzazione android.permission.RECOVER_KEYSTORE solo alle app di sistema che registrano un agente di recupero protetto correttamente. Un agente di recupero protetto correttamente è definito come un agente software on-device che si sincronizza con uno spazio di archiviazione remoto off-device, dotato di hardware sicuro con protezione equivalente o superiore a quella descritta nel servizio Google Cloud Key Vault per impedire attacchi di forza bruta al fattore di conoscenza della schermata di blocco.

Implementazioni dei dispositivi:

  • [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 o posizione della rete a cui è connesso il dispositivo).
    • Attività fisica dell'utente o classificazione dell'attività fisica.

Nello specifico, le implementazioni dei dispositivi:

  • [C-0-8] È OBBLIGATORIO ottenere il consenso dell'utente per consentire a un'app di accedere ai dati sulla posizione o sull'attività fisica.
  • [C-0-9] DEVE concedere un'autorizzazione di runtime SOLO all'app che detiene 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 con il 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 il hardRestricted a un'app.
    • A un'app viene concesso il hardRestricted su una versione precedente di Android.

  • [C-0-11] Le app che detengono un'autorizzazione softRestricted DEVONO ottenere solo accesso limitato e NON DEVONO ottenere accesso completo finché non vengono inserite nella lista consentita come descritto nell'SDK, dove l'accesso completo e limitato è definito per ogni autorizzazione softRestricted (ad esempio READ_EXTERNAL_STORAGE).

Se le implementazioni del dispositivo forniscono all'utente la possibilità di scegliere quali app possono disegnare sopra altre app con un'attività che gestisce l'intent ACTION_MANAGE_OVERLAY_PERMISSION, devono:

  • [C-2-1] DEVI assicurarti che tutte le attività con filtri di intent per l'intent ACTION_MANAGE_OVERLAY_PERMISSION abbiano la stessa schermata dell'interfaccia utente, indipendentemente dall'app di lancio o dalle informazioni fornite.

9.2. Isolamento UID e dei processi

Implementazioni dei dispositivi:

  • [C-0-1] DEVE supportare il modello di sandbox delle applicazioni Android, in cui ogni applicazione viene eseguita come UID 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 nella documentazione di riferimento su sicurezza e autorizzazioni.

9.3. Autorizzazioni del file system

Implementazioni dei dispositivi:

9.4. Ambienti di esecuzione alternativi

Le implementazioni dei dispositivi DEVONO mantenere la coerenza del modello di sicurezza e delle autorizzazioni di Android, anche se includono ambienti di runtime che eseguono applicazioni utilizzando un altro software o una tecnologia diversa dal formato eseguibile Dalvik o dal codice nativo. In altre parole:

  • [C-0-1] I runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella sezione 9.

  • [C-0-2] Ai runtime alternativi NON DEVE essere concesso l'accesso 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 dalle 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 qualsiasi altra app installata sul dispositivo, tranne tramite i meccanismi standard di Android per ID utente e certificato di firma condivisi.

  • [C-0-5] I runtime alternativi NON DEVONO essere avviati con le sandbox corrispondenti ad altre applicazioni Android, né devono concedere o ricevere l'accesso alle sandbox.

  • [C-0-6] I runtime alternativi NON DEVONO essere avviati con, essere concessi o concedere ad altre applicazioni privilegi del superutente (root) o di qualsiasi altro ID utente.

  • [C-0-7] Quando i file .apk dei 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), il 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, l'ambiente di runtime DEVE elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che lo utilizza.

  • I runtime alternativi DOVREBBERO installare le app tramite PackageManager in sandbox Android separate (ID utente Linux e così via).

  • I runtime alternativi POSSONO fornire una singola sandbox Android condivisa da tutte le applicazioni che li utilizzano.

9.5. Supporto di più utenti

Android include il supporto di più utenti e l'isolamento completo degli utenti.

  • Le implementazioni dei dispositivi POSSONO, ma NON DEVONO, attivare il multiutente se utilizzano supporti rimovibili per lo spazio di archiviazione esterno principale.

Se le implementazioni dei dispositivi includono più utenti, queste:

  • [C-1-1] DEVE soddisfare i seguenti requisiti relativi al supporto multiutente.
  • [C-1-2] DEVE, per ogni utente, implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API.
  • [C-1-3] DEVE avere directory di spazio di archiviazione delle applicazioni condivise (ovvero /sdcard) separate e isolate 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 altri utenti, 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 il multiutente è attivato utilizzando una chiave memorizzata solo su un supporto non rimovibile accessibile solo al sistema se le implementazioni del dispositivo utilizzano supporti rimovibili per le API di archiviazione esterna. Poiché i contenuti multimediali non saranno più 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 qualsiasi messaggio SMS premium in uscita. Gli SMS premium sono messaggi inviati a un servizio registrato presso un operatore che potrebbero 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 ai numeri identificati dalle espressioni regolari definite nel file /data/misc/sms/codes.xml nel dispositivo. L'Android Open Source Project 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 di 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 dei dispositivi:

  • [C-0-1] DEVE mantenere la compatibilità con le applicazioni esistenti, anche quando SELinux o altre funzionalità di sicurezza sono implementate sotto il framework Android.
  • [C-0-2] NON DEVE avere un'interfaccia utente visibile quando viene rilevata una violazione della sicurezza e bloccata correttamente 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 si traduce in uno sfruttamento riuscito.
  • [C-0-3] NON DEVE consentire all'utente o allo sviluppatore di app di configurare SELinux o qualsiasi altra funzionalità di sicurezza implementata sotto il 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 violi la compatibilità.
  • [C-0-5] È OBBLIGATORIO suddividere il framework multimediale in più processi in modo da poter concedere l'accesso in modo più specifico per ogni processo, come descritto nel sito del progetto open source Android.
  • [C-0-6] È NECESSARIO implementare un meccanismo di sandboxing delle applicazioni del kernel che consenta di filtrare le chiamate di sistema utilizzando un criterio configurabile da programmi multithread. Il progetto Android Open Source upstream soddisfa questo requisito attivando seccomp-BPF con la sincronizzazione del gruppo 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 dei dispositivi:

  • [C-0-7] DEVE implementare meccanismi di protezione da overflow del buffer dello stack del kernel. Esempi di questi meccanismi sono CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
  • [C-0-8] È OBBLIGATORIO 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] È OBBLIGATORIO implementare il controllo dei limiti di dimensione degli oggetti statici e dinamici delle copie tra spazio utente e 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 la 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] È OBBLIGATORIO 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] È OBBLIGATORIO implementare il rafforzamento della previsione delle ramificazioni se l'hardware è vulnerabile alla vulnerabilità CVE-2017-5715 su tutti i dispositivi originariamente forniti con il livello API 28 o versioni successive (ad es. CONFIG_HARDEN_BRANCH_PREDICTOR).
  • [SR] È FORTEMENTE CONSIGLIATO 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] È FORTEMENTE CONSIGLIATO di randomizzare il layout del codice e della memoria del kernel ed evitare esposizioni che potrebbero compromettere 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] È FORTEMENTE 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 l'integrità del flusso di controllo (CFI), lo stack di chiamate shadow (SCS) o la convalida degli overflow di interi (IntSan) nei componenti in cui sono abilitati.
  • [C-SR] È FORTEMENTE CONSIGLIATO di attivare CFI, SCS e IntSan per eventuali componenti aggiuntivi dello spazio utente sensibili alla sicurezza, come spiegato in CFI e IntSan.
  • [C-SR] È FORTEMENTE CONSIGLIATO abilitare l'inizializzazione dello stack nel kernel per impedire l'utilizzo di variabili locali non inizializzate (CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO). Inoltre, le implementazioni del dispositivo NON DEVONO assumere il valore utilizzato dal compilatore per inizializzare le variabili locali.
  • [C-SR] È FORTEMENTE CONSIGLIATO abilitare l'inizializzazione dell'heap nel kernel per impedire l'utilizzo di allocazioni dell'heap non inizializzate (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) e NON DEVONO assumere il valore utilizzato dal kernel per inizializzare queste allocazioni.

Se le implementazioni dei dispositivi utilizzano un kernel Linux:

  • [C-1-1] È NECESSARIO implementare SELinux.
  • [C-1-2] È NECESSARIO impostare SELinux sulla modalità di applicazione globale.
  • [C-1-3] È NECESSARIO 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 nell'Android Open Source Project (AOSP) in upstream e il criterio DEVE compilare con tutte le regole neverallow presenti, sia per i domini SELinux AOSP sia per i domini specifici del dispositivo/del fornitore.
  • [C-1-5] È NECESSARIO eseguire applicazioni di terze parti che hanno come target il livello API 28 o versioni successive in sandbox SELinux per applicazione con limitazioni SELinux per app nella directory dei dati privati di ogni applicazione.
  • DOVREBBE mantenere il criterio SELinux predefinito fornito nella cartella system/sepolicy del progetto open source Android upstream e aggiungere ulteriori elementi a questo criterio solo per la propria configurazione specifica del dispositivo.

Se le implementazioni dei dispositivi sono già state lanciate su una versione precedente di Android e non possono soddisfare i requisiti [C-1-1] e [C-1-5] tramite un aggiornamento del software di sistema, POTREBBERO essere esenti da questi requisiti.

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

  • [C-2-1] È NECESSARIO utilizzare un sistema di controllo degli accessi obbligatorio equivalente a SELinux.

Android contiene più funzionalità di difesa in profondità che sono parte integrante della sicurezza del dispositivo.

9.8. Privacy

9.8.1. Cronologia utilizzo

Android archivia la cronologia delle scelte dell'utente e la gestisce tramite UsageStatsManager.

Implementazioni dei dispositivi:

  • [C-0-1] DEVE mantenere un periodo di conservazione ragionevole di questa cronologia utente.
  • [SR] È FORTEMENTE CONSIGLIATO di mantenere il periodo di conservazione di 14 giorni come configurato per impostazione predefinita nell'implementazione AOSP.

Android memorizza gli eventi di sistema utilizzando gli identificatori StatsLog e gestisce questa cronologia tramite le API di sistema StatsManager e IncidentManager.

Implementazioni dei dispositivi:

  • [C-0-2] È obbligatorio includere solo i campi contrassegnati con DEST_AUTOMATIC nel report sugli incidenti creato dalla classe dell'API di sistema IncidentManager.
  • [C-0-3] NON devi utilizzare gli identificatori di eventi di sistema per registrare eventi diversi da quelli descritti nella documentazione dell'SDK StatsLog. Se vengono registrati altri eventi di sistema, POTREBBE essere utilizzato un identificatore di atomi diverso nell'intervallo compreso tra 100.000 e 200.000.

9.8.2. Registrazione in corso…

Implementazioni dei dispositivi:

  • [C-0-1] NON DEVE precaricare o distribuire componenti software out-of-box che inviano le informazioni private dell'utente (ad es. sequenze di tasti, testo visualizzato sullo schermo, report di bug) dal dispositivo senza il consenso dell'utente o senza mostrare notifiche chiare.
  • [C-0-2] DEVE mostrare e ottenere il consenso esplicito dell'utente per consentire di acquisire qualsiasi informazione sensibile visualizzata sullo schermo dell'utente ogni volta che la trasmissione o la registrazione dello schermo è attivata tramite MediaProjection o API proprietarie. NON DEVE fornire agli utenti un'opzione per disattivare la futura visualizzazione del consenso dell'utente.
  • [C-0-3] DEVE essere presente una notifica continua all'utente mentre la trasmissione o la registrazione dello schermo sono attive. AOSP soddisfa questo requisito mostrando un'icona di notifica in corso nella barra di stato.

Se le implementazioni del dispositivo includono nel sistema funzionalità che acquisiscono i contenuti visualizzati sullo schermo e/o registrano lo stream audio riprodotto sul dispositivo in modo diverso dall'API di sistema ContentCaptureService o da altri mezzi proprietari descritti nella Sezione 9.8.6 Acquisizione di contenuti, devono:

  • [C-1-1] DEVE essere presente una notifica continua all'utente ogni volta che questa funzionalità è attiva e acquisisce/registra attivamente.

Se le implementazioni dei dispositivi includono un componente abilitato out-of-the-box, in grado di registrare l'audio ambientale e/o l'audio riprodotto sul dispositivo per dedurre informazioni utili sul contesto dell'utente, devono:

  • [C-2-1] NON DEVE memorizzare nello spazio di archiviazione on-device permanente o trasmettere dal dispositivo l'audio non elaborato registrato o qualsiasi formato che possa essere convertito nuovamente nell'audio originale o in una copia quasi esatta, tranne con il consenso esplicito dell'utente.

9.8.3. Connettività

Se le implementazioni dei dispositivi dispongono di una porta USB con supporto della modalità periferica USB, devono:

  • [C-1-1] DEVE presentare un'interfaccia utente che richieda 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 dei dispositivi:

  • [C-0-1] DEVE preinstallare gli stessi certificati radice per l'archivio delle autorità di certificazione (CA) attendibili di sistema forniti nel progetto open source Android upstream.
  • [C-0-2] DEVE essere fornito con un magazzino CA radice utente vuoto.
  • [C-0-3] DEVE mostrare un avviso all'utente che indica che il traffico di rete potrebbe essere monitorato quando viene aggiunta una CA principale dell'utente.

Se il traffico del dispositivo viene instradato tramite una VPN, le implementazioni del dispositivo:

  • [C-1-1] DEVE mostrare un avviso all'utente 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 dispongono di un meccanismo, abilitato per impostazione predefinita, che instrada 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), devono:

  • [C-2-1] DEVE chiedere il consenso dell'utente prima di attivare il meccanismo, a meno che la VPN non sia attivata dal Device Policy Controller tramite DevicePolicyManager.setAlwaysOnVpnPackage() , nel qual caso l'utente non deve fornire un consenso separato, ma DEVE solo essere informato.

Se le implementazioni del dispositivo implementano un'affordance utente per attivare/disattivare la funzionalità "VPN sempre attiva" di un'app VPN di terze parti, devono:

  • [C-3-1] È OBBLIGATORIO disattivare questa funzionalità per gli utenti per le app che non supportano il servizio VPN sempre attivo nel file AndroidManifest.xml impostando l'attributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON su false.

9.8.5. Identificatori dei dispositivi

Implementazioni dei dispositivi:

  • [C-0-1] DEVE impedire l'accesso al numero di serie del dispositivo e, se applicabile, all'IMEI/MEID, al numero di serie della SIM e all'IMSI (International Mobile Subscriber Identity) da un'app, a meno che non soddisfi uno dei seguenti requisiti:
    • è un'app dell'operatore firmata e verificata dai produttori di dispositivi.
    • è stata concessa l'autorizzazione READ_PRIVILEGED_PHONE_STATE.
    • Ha i privilegi dell'operatore come definito in Privilegi dell'operatore UICC.
    • è un proprietario del dispositivo o del profilo a cui è stata concessa l'autorizzazione READ_PHONE_STATE.
    • (Solo per numero di serie della SIM/ICCID) è previsto dal regolamento locale che l'app rilevi le modifiche all'identità dell'abbonato.

9.8.6. Acquisizione dei contenuti

Android, tramite l'API System ContentCaptureService o altri mezzi proprietari, supporta un meccanismo per le implementazioni dei dispositivi per acquisire le seguenti interazioni tra le applicazioni e l'utente.

  • Testo e immagini visualizzati sullo schermo, inclusi, a titolo esemplificativo, notifiche e dati di assistenza tramite l'API AssistStructure.
  • Dati multimediali, ad esempio audio o video, registrati o riprodotti dal dispositivo.
  • Eventi di input (ad es. tasti, mouse, gesti, voce, video e accessibilità).
  • Eventuali altri eventi forniti da un'applicazione al sistema tramite l'API Content Capture o un'API proprietaria con funzionalità simili.
  • Qualsiasi testo o altro dato inviato tramite TextClassifier API a System TextClassifier, ovvero al servizio di sistema per comprendere il significato del testo, nonché per generare azioni successive previste in base al testo.

Se le implementazioni dei dispositivi acquisiscono i dati sopra indicati, queste:

  • [C-1-1] DEVE criptare tutti questi dati quando vengono archiviati nel dispositivo. Questa crittografia PUÒ essere eseguita utilizzando la crittografia basata su file di Android o uno dei cifrari elencati come API versione 26 e successive descritti nell'SDK Cipher.
  • [C-1-2] NON DEVE eseguire il backup dei dati non elaborati o criptati utilizzando i metodi di backup di Android o altri metodi di backup.
  • [C-1-3] DEVE inviare solo tutti questi dati e il log del dispositivo utilizzando un meccanismo che garantisca la tutela della privacy. Il meccanismo di tutela della privacy è definito come "quelli che consentono solo l'analisi aggregata e impediscono la corrispondenza di eventi registrati o risultati derivati ai singoli utenti", per impedire l'introspezione dei dati per utente (ad es. implementati utilizzando una tecnologia di privacy differenziale come RAPPOR).
  • [C-1-4] NON DEVE associare questi dati a qualsiasi 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, tranne che 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 da ContentCaptureService o dai mezzi proprietari se i dati sono archiviati in qualsiasi forma sul dispositivo.

Se le implementazioni dei dispositivi includono un servizio che implementa l'API System ContentCaptureService o qualsiasi servizio proprietario che acquisisce i dati come descritto sopra, devono:

  • [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 questi dati.
  • [C-2-2] NON DEVE consentire ad altre app, oltre al meccanismo del servizio di acquisizione dei contenuti preinstallato, di acquisire questi dati.
  • [C-2-3] DEVE fornire all'utente la possibilità di disattivare il servizio di acquisizione dei contenuti.
  • [C-2-4] NON DEVE omettere l'affordance dell'utente per 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 di mantenere separati i componenti del servizio di acquisizione dei contenuti, ad esempio non associare il servizio o condividere gli ID processo, da altri componenti di sistema, ad eccezione di quanto segue:

    • Telefonia, Contatti, Interfaccia utente di sistema e contenuti multimediali

9.8.7. Accesso agli appunti

Implementazioni dei dispositivi:

  • [C-0-1] NON DEVE restituire dati ritagliati nella clipboard (ad es. tramite l'API ClipboardManager), a meno che l'app non sia l'IME predefinito o l'app attualmente attiva.

9.8.8. Posizione

Implementazioni dei dispositivi:

  • [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'attivazione da parte dell'utente.
  • [C-0-2] DEVE fornire all'utente la possibilità di accedere alle informazioni relative alla posizione, tra cui richieste di accesso alla posizione recenti, autorizzazioni a livello di app e utilizzo della scansione Wi-Fi/Bluetooth per determinare la posizione.
  • [C-0-3] DEVE garantire che l'applicazione che utilizza l'API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] sia una sessione di emergenza avviata dall'utente (ad es. chiamare il 112 o inviare un messaggio al 112). Tuttavia, per i veicoli, un veicolo PUÒ avviare una sessione di emergenza senza interazione attiva dell'utente nel caso in cui venga rilevato un incidente (ad es. per soddisfare i requisiti di eCall).
  • [C-0-4] È NECESSARIO preservare la capacità dell'API Emergency Location Bypass di aggirare le impostazioni di geolocalizzazione 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.8.9. App installate

Per impostazione predefinita, le app per Android che hanno come target il livello API 30 o versioni successive non possono vedere i dettagli delle altre app installate (vedi Visibilità del pacchetto nella documentazione dell'SDK Android).

Implementazioni dei dispositivi:

  • [C-0-1] NON DEVE esporre a qualsiasi app che ha come target il livello API 30 o versioni successive i dettagli di qualsiasi altra app installata, a meno che l'app non sia già in grado di vedere i dettagli dell'altra app installata tramite le API gestite. Sono inclusi, a titolo esemplificativo, i dettagli esposti da eventuali API personalizzate aggiunte dall'implementatore del dispositivo o accessibili tramite il file system.

9.8.10. Segnalazione di bug relativi alla connettività

Se le implementazioni dei dispositivi generano segnalazioni di bug utilizzando l'API System BUGREPORT_MODE_TELEPHONY con BugreportManager:

  • [C-1-1] DEVE ottenere il consenso dell'utente ogni volta che viene chiamata l'API di sistema BUGREPORT_MODE_TELEPHONY per generare un report e NON DEVE chiedere all'utente di acconsentire a tutte le richieste future dell'applicazione.
  • [C-1-2] DEVE mostrare e ottenere il consenso esplicito dell'utente quando i report iniziano a essere generati e NON DEVE restituire il report generato all'app richiedente senza il consenso esplicito dell'utente.
  • [C-1-3] DEVE generare i report richiesti contenenti almeno le seguenti informazioni:
    • Dump di TelephonyDebugService
    • Dump di TelephonyRegistry
    • Dump di WifiService
    • Dump di ConnectivityService
    • Un dump dell'istanza CarrierService del pacchetto chiamante (se associato)
    • Buffer dei log del segnale radio
  • [C-1-4] NON DEVE includere quanto segue nei report generati:
    • Qualsiasi tipo di informazione non correlata al debug della connettività.
    • Qualsiasi tipo di log del traffico delle applicazioni installate dall'utente o profili dettagliati di applicazioni/pacchetti installati dall'utente (gli UID sono consentiti, i nomi dei pacchetti no).
  • POTREBBE includere informazioni aggiuntive non associate a nessuna identità utente. (ad es. log del fornitore).

Se le implementazioni dei dispositivi includono informazioni aggiuntive (ad es.log del fornitore) nella segnalazione di bug e queste informazioni hanno un impatto sulla privacy/sicurezza/batteria/spazio di archiviazione/memoria:

  • [C-SR] È VIVAMENTE CONSIGLIATO di impostare l'impostazione di uno sviluppatore su disattivata per impostazione predefinita. AOSP soddisfa questo requisito fornendo l'opzione Enable verbose vendor logging nelle impostazioni per sviluppatori per includere log aggiuntivi del fornitore specifici del dispositivo nelle segnalazioni di bug.

9.8.11. Condivisione di blob di dati

Android, tramite BlobStoreManager, consente alle app di contribuire con blob di dati al sistema da condividere con un insieme selezionato di app.

Se le implementazioni dei dispositivi supportano i blob di dati condivisi come descritto nella documentazione dell'SDK:

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 su cui è stato lanciato il dispositivo.

9.9.1. Avvio diretto

Implementazioni dei dispositivi:

  • [C-0-1] DEVE implementare le API della modalità di avvio diretto anche se non supportano la crittografia dello spazio di archiviazione.

  • [C-0-2] Gli intent ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED DEVONO comunque essere trasmessi per segnalare alle applicazioni compatibili con il Boot diretto che le posizioni di archiviazione con crittografia del dispositivo (DE) e con crittografia delle credenziali (CE) sono disponibili per l'utente.

9.9.2. Requisiti di crittografia

Implementazioni dei dispositivi:

  • [C-0-1] DEVE criptare i dati privati dell'applicazione (partizione /data) e la partizione dello spazio di archiviazione condiviso dell'applicazione (partizione /sdcard) se si tratta di una parte permanente e non rimovibile del dispositivo.
  • [C-0-2] DEVE attivare la crittografia dello spazio di archiviazione dei dati per impostazione predefinita quando l'utente ha completato l'esperienza di configurazione fuori dalla scatola.

  • [C-0-3] DEVE soddisfare il requisito di crittografia dell'archiviazione dei dati riportato sopra implementando uno dei seguenti due metodi di crittografia:

9.9.3. Metodi di crittografia

Se le implementazioni dei dispositivi sono criptate:

  • [C-1-1] DEVE avviarsi senza richiedere all'utente le credenziali e consentire alle app compatibili con il riavvio diretto di accedere allo spazio di archiviazione criptato del dispositivo dopo l'invio 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 il messaggio ACTION_USER_UNLOCKED viene trasmesso.
  • [C-1-13] NON DEVE offrire alcun metodo per sbloccare lo spazio di archiviazione protetto CE senza le credenziali fornite dall'utente, una chiave escrow registrata o un'implementazione del ripristino al riavvio che soddisfi i requisiti della sezione 9.9.4.
  • [C-1-4] DEVE utilizzare l'Avvio verificato.

9.9.3.1. Crittografia basata su file con crittografia dei metadati

Se le implementazioni dei dispositivi utilizzano la crittografia basata su file con crittografia dei metadati:

  • [C-1-5] È NECESSARIO criptare i contenuti dei file e i metadati del file system utilizzando AES-256-XTS o Adiantum. AES-256-XTS si riferisce all'Advanced Encryption Standard con una lunghezza della chiave di crittografia di 256 bit, operata in modalità XTS; la lunghezza completa della chiave è di 512 bit. Per Adiantum si intende Adiantum-XChaCha12-AES, come specificato all'indirizzo https://github.com/google/adiantum. I metadati del file system sono dati quali dimensioni dei file, proprietà, modalità e attributi estesi (xattr).
  • [C-1-6] È NECESSARIO criptare i nomi dei file utilizzando AES-256-CBC-CTS o Adiantum.
  • [C-1-12] Se il dispositivo dispone di istruzioni Advanced Encryption Standard (AES) (ad esempio le estensioni di crittografia ARMv8 sui dispositivi basati su ARM o AES-NI sui dispositivi basati su x86), è OBBLIGATORIO utilizzare le opzioni basate su AES riportate sopra per la crittografia del nome file, dei contenuti del file e dei metadati del file system, non Adiantum.
  • [C-1-13] È OBBLIGATORIO utilizzare una funzione di derivazione delle chiavi crittograficamente sicura e irreversibile (ad es. HKDF-SHA512) per ricavare le eventuali sottochiavi necessarie (ad es. chiavi per file) dalle chiavi CE e DE. "Molto sicura e non reversibile dal punto di vista della crittografia" significa che la funzione di derivazione della chiave ha un livello di sicurezza di almeno 256 bit e si comporta come una famiglia di funzioni pseudocasuali sui suoi input.

  • [C-1-14] NON DEVE utilizzare le stesse chiavi o sottochiavi di crittografia basata su file (FBE) per scopi crittografici diversi (ad es. sia per la crittografia che per la derivazione delle chiavi o per due diversi algoritmi di crittografia).

  • Le chiavi che proteggono le aree di archiviazione CE e DE e i metadati del file system:

  • [C-1-7] DEVE essere associato in modo crittografico a un Keystore basato su hardware. Questo keystore DEVE essere associato all'Avvio verificato e all'hardware root of trust del dispositivo.

  • [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 univoco e distinto, in altre parole nessuna chiave CE o DE di un utente corrisponde a quella di un altro utente.

  • [C-1-11] DEVE utilizzare le modalità, le lunghezze delle chiavi e le cifre supportate obbligatoriamente.

  • DOVREBBE rendere le app essenziali preinstallate (ad es. Sveglia, Telefono, Messenger) compatibili con il riavvio diretto.

Il progetto Android Open Source upstream fornisce un'implementazione preferita della crittografia basata su file in base alla funzionalità di crittografia "fscrypt" del kernel Linux e della crittografia dei metadati in base alla funzionalità "dm-default-key" del kernel Linux.

9.9.3.2. Crittografia a livello di blocco per utente

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

  • [C-1-1] DEVE essere attivato il supporto multiutente come descritto nella sezione 9.5.
  • [C-1-2] DEVE fornire partizioni per utente, utilizzando partizioni non formattate o volumi logici.
  • [C-1-3] DEBBONO essere utilizzate chiavi di crittografia univoche e distinte per utente per la crittografia dei dispositivi di blocco sottostanti.

  • [C-1-4] È NECESSARIO utilizzare AES-256-XTS per la crittografia a livello di blocco delle partizioni utente.

  • Le chiavi che proteggono i dispositivi criptati a livello di blocco per utente:

  • [C-1-5] DEVE essere vincolato in modo crittografico a un Keystore basato su hardware. Questo keystore DEVE essere associato all'Avvio verificato e all'hardware root of trust del dispositivo.

  • [C-1-6] DEVE essere associato alle credenziali della schermata di blocco dell'utente corrispondente.

La crittografia a livello di blocco per utente può essere implementata utilizzando la funzionalità "dm-crypt" del kernel Linux sulle partizioni per utente.

9.9.4. Riprendi al riavvio

La funzionalità Riprendi dopo il riavvio consente di sbloccare lo spazio di archiviazione CE di tutte le app, incluse quelle che non supportano ancora il riavvio diretto, dopo un riavvio avviato da un aggiornamento OTA. Questa funzionalità consente agli utenti di ricevere notifiche dalle app installate dopo il riavvio.

Un'implementazione della funzionalità Riprendi al riavvio deve continuare a garantire che, quando un dispositivo finisce nelle mani di un malintenzionato, sia estremamente difficile per quest'ultimo recuperare i dati criptati con crittografia lato client dell'utente, anche se il dispositivo è acceso, lo spazio di archiviazione lato client è sbloccato e l'utente ha sbloccato il dispositivo dopo aver ricevuto un aggiornamento OTA. Per la resistenza agli attacchi di tipo insider, supponiamo inoltre che l'utente malintenzionato ottenga l'accesso alle chiavi di firma crittografiche di trasmissione.

Nello specifico:

  • [C-0-1] Lo spazio di archiviazione CE NON DEVE essere leggibile nemmeno per l'utente malintenzionato che ha il dispositivo fisicamente e dispone quindi di queste funzionalità e limitazioni:

    • Può utilizzare la chiave di firma di qualsiasi fornitore o azienda per firmare messaggi arbitrari.
    • Può causare la ricezione di un aggiornamento OTA da parte del dispositivo.
    • Può modificare il funzionamento di qualsiasi hardware (AP, flash e così via), tranne che come descritto di seguito, ma questa modifica comporta un ritardo di almeno un'ora e un ciclo di alimentazione che distrugge i contenuti della RAM.
    • Non è possibile modificare il funzionamento dell'hardware a prova di manomissione (ad es. Titan M).
    • Impossibile leggere la RAM del dispositivo in tempo reale.
    • Non può ottenere le credenziali dell'utente (PIN, sequenza, password) o causarne l'inserimento.

A titolo esemplificativo, un'implementazione di un dispositivo che implementa e rispetta tutte le descrizioni riportate qui sarà conforme a [C-0-1].

9.10. Integrità del dispositivo

I seguenti requisiti garantiscono la trasparenza dello stato dell'integrità del dispositivo. Implementazioni dei dispositivi:

  • [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 non esisteva questo nuovo metodo dell'API di sistema.

  • [C-0-2] DEVE supportare l'Avvio verificato per l'integrità del dispositivo.

Se le implementazioni dei dispositivi sono già state lanciate senza supportare Avvio verificato su una versione precedente di Android e non è possibile aggiungere il supporto di questa funzionalità con un aggiornamento del software di sistema, POTREBBERO essere esenti 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] È OBBLIGATORIO dichiarare il flag funzionalità della piattaforma android.software.verified_boot.
  • [C-1-2] È NECESSARIO eseguire la verifica a ogni sequenza di avvio.
  • [C-1-3] È NECESSARIO avviare la verifica da una chiave hardware immutabile che è la radice della 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] È NECESSARIO utilizzare algoritmi di verifica altrettanto efficaci dei consigli attuali 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 accetti di 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 il dispositivo contiene più chip distinti (ad es. radio, processore di immagini specializzato), è MOLTO CONSIGLIATO verificare ogni fase del processo di avvio di ciascuno di questi chip all'avvio.
  • [C-1-8] È NECESSARIO utilizzare uno spazio di archiviazione con dispositivo antimanomissione per memorizzare se il bootloader è sbloccato. Lo spazio di archiviazione con rilevamento di manomissione indica che il bootloader può rilevare se lo spazio di archiviazione è stato manomesso dall'interno di Android.
  • [C-1-9] DEVE richiedere all'utente, durante l'utilizzo del dispositivo, una conferma fisica prima di consentire la transizione dalla modalità di blocco del bootloader alla modalità di sblocco del bootloader.
  • [C-1-10] DEVE implementare la protezione del rollback per le partizioni utilizzate da Android (ad es. partizioni di avvio e di sistema) e utilizzare uno spazio di archiviazione con rilevamento di manomissione per memorizzare i metadati utilizzati per determinare la versione minima del sistema operativo consentita.
  • [C-SR] È FORTEMENTE 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 elementi eseguibili caricati da un'app privilegiata dall'esterno 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 del rollback per qualsiasi componente con firmware persistente (ad es. modem, videocamera) e DEVE utilizzare lo spazio di archiviazione con rilevamento 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, i dispositivi POTREBBERO essere esentati dai requisiti.

Il progetto Android Open Source fornisce un'implementazione preferita di questa funzionalità nel repository external/avb/, che può essere integrata nel bootloader utilizzato per il caricamento di Android.

Implementazioni dei dispositivi:

  • [C-0-3] DEVE supportare la verifica tramite crittografia dei contenuti del file rispetto a una chiave attendibile senza leggere l'intero file.
  • [C-0-4] NON DEVE consentire il buon esito delle richieste di lettura su un file protetto quando i contenuti letti non vengono verificati rispetto a una chiave attendibile.

Se le implementazioni dei dispositivi sono già state lanciate senza la possibilità di verificare i contenuti dei file rispetto a una chiave attendibile su una versione precedente di Android e non è possibile aggiungere il supporto di questa funzionalità con un aggiornamento del software di sistema, POTREBBERO essere esenti dal requisito. Il progetto Android Open Source upstream fornisce un'implementazione preferita di questa funzionalità basata sulla funzionalità fs-verity del kernel Linux.

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi supportano l'API Android Protected Confirmation, devono:

  • [C-3-1] È OBBLIGATORIO 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 sia stato in grado di esaminare e approvare il messaggio richiesto anche nel caso in cui il sistema operativo Android, incluso il 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 dei dispositivi:

  • [C-0-1] DEVE consentire l'importazione o la generazione di almeno 8192 chiavi.
  • [C-0-2] L'autenticazione nella 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] È NECESSARIO eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
  • [C-1-2] DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni hash di famiglie 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 sopra. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA. Il progetto Android Open Source (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura sottoposta a revisione da parte di terze parti di un'isolamento basato su hypervisor adeguato sono opzioni alternative.
  • [C-1-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo se l'autenticazione va a buon fine, deve consentire l'utilizzo delle chiavi legate 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 open source Android upstream fornisce l'HAL (Hardware Abstraction Layer) Gatekeeper 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 dei 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, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.

Tieni presente che se un'implementazione del dispositivo è già stata lanciata su una versione precedente di Android, questo dispositivo è esente dall'obbligo di avere un keystore supportato da un ambiente di esecuzione isolato e di supportare l'attestazione delle chiavi, 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 della modalità Sospensione per la transizione dallo stato sbloccato a quello bloccato, con un timeout minimo consentito fino a 15 secondi. I dispositivi per auto, che bloccano lo schermo ogni volta che l'unità principale viene spenta o l'utente cambia, POTREBBERO NON avere la configurazione del timeout di sospensione.

9.11.1. Schermata di blocco e autenticazione sicure

L'implementazione di AOSP segue un modello di autenticazione a più livelli in cui un'autenticazione principale basata su knowledge-factory può essere supportata da un'autenticazione biometrica secondaria efficace o da modalità terziarie meno efficaci.

Implementazioni dei dispositivi:

  • [C-SR] È FORTEMENTE CONSIGLIATO impostare solo uno dei seguenti come metodo di autenticazione principale:
    • Un PIN numerico
    • Una password alfanumerica
    • Un pattern di scorrimento su una griglia di esattamente 3 x 3 punti

Tieni presente che i metodi di autenticazione sopra indicati sono indicati come metodi di autenticazione principali consigliati in questo documento.

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 si basano su una chiave segreta nota 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 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_SOMETHING.
  • [C-3-5] I nuovi metodi di autenticazione DEVONO ricorrere ai metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) una volta ogni 72 ore o meno OPPURE indicare chiaramente all'utente che non verrà eseguito il backup di alcuni dati per preservare la privacy dei suoi 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 la classe 1 (in precedenza Convenience).
  • [C-4-2] DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principale consigliati basati su una chiave segreta nota.
  • [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à di protezione con PIN chiamando il metodo DevicePolicyManager.setKeyguardDisabledFeatures() con uno 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 la classe 3 (in precedenza Resistente) come descritto 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) come descritto in [C-1-7] e [C-1-8] nella sezione 7.3.10.
  • [C-5-3] I metodi NON DEVONO essere considerati come una schermata di blocco sicura e DEVONO soddisfare i requisiti che iniziano con C-8 in questa sezione di seguito.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco e un nuovo metodo di autenticazione si basa su un token fisico o sulla posizione:

  • [C-6-1] Devono disporre di un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principale consigliati basati su una chiave segreta nota e soddisfare i requisiti per essere considerati 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 la schermata quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio con il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o con il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED.
  • [C-6-3] All'utente DEVE essere richiesto uno dei metodi di autenticazione principale consigliati (ad es. PIN, sequenza, password) almeno una volta ogni 4 ore.
  • [C-6-4] Il nuovo metodo NON DEVE essere considerato una schermata di blocco sicura e DEVE rispettare le limitazioni elencate in C-8 di seguito.

Se le implementazioni dei dispositivi dispongono di una schermata di blocco sicura e includono uno o più agenti di attendibilità 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 è differito o può essere sbloccato dagli agenti di attendibilità. Ad esempio, AOSP soddisfa questo requisito mostrando una descrizione del testo per le impostazioni "Blocca automaticamente" e "Il tasto di accensione blocca immediatamente" nel menu delle impostazioni e un'icona distinguibile nella schermata di blocco.
  • [C-7-2] DEVE rispettare e implementare completamente tutte le API di agenti di attendibilità 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. palmare), ma PUÒ implementare completamente la funzione sulle implementazioni dei dispositivi che in genere vengono condivisi (ad es. Android TV o dispositivo per auto e motori).
  • [C-7-4] DEVE criptare tutti i token archiviati aggiunti da TrustAgentService.addEscrowToken().
  • [C-7-5] NON DEVE memorizzare la chiave di crittografia o il token escrow sullo stesso dispositivo in cui viene utilizzata la chiave. Ad esempio, è consentito che una chiave memorizzata su uno smartphone sblocchi un account utente su una TV. Per i dispositivi Automotive, non è consentito memorizzare il token escrow in nessuna parte del veicolo.
  • [C-7-6] È OBBLIGATORIO informare l'utente sulle implicazioni per la sicurezza prima di attivare il token escrow per decriptare lo spazio di archiviazione dei dati.
  • [C-7-7] DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principale consigliati.
  • [C-7-8] All'utente DEVE essere richiesto uno dei metodi di autenticazione principale consigliati (ad es.PIN, sequenza, password) almeno una volta ogni 72 ore, a meno che non sia in discussione la sicurezza dell'utente (ad es. distrazione del conducente).
  • [C-7-9] All'utente DEVE essere richiesta una verifica per uno dei metodi di autenticazione principale consigliati (ad es.PIN, sequenza, password) come descritto in [C-1-7] e [C-1-8] nella sezione 7.3.10, a meno che non sia in discussione la sicurezza dell'utente (ad es. distrazione del conducente).
  • [C-7-10] NON DEVE essere trattata come una schermata di blocco sicura e DEVE rispettare le limitazioni elencate in C-8 di seguito.
  • [C-7-11] NON DEVE consentire a TrustAgent sui dispositivi personali principali (ad es.palmari) di sbloccare il dispositivo e può utilizzarli solo per mantenere un dispositivo già sbloccato in stato sbloccato per un massimo di 4 ore. L'implementazione predefinita di TrustManagerService in AOSP soddisfa questo requisito.
  • [C-7-12] È NECESSARIO utilizzare un canale di comunicazione con protezione criptata (ad es.UKEY2) per trasmettere il token di escrow 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 la schermata di guardia:

  • [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 da utilizzare 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 sopra. Questo tipo di processore sicuro dedicato è chiamato "StrongBox". I requisiti C-1-3 fino a C-1-11 riportati di seguito definiscono i requisiti che un dispositivo deve soddisfare per essere considerato una cassetta di sicurezza.

Implementazioni di dispositivi con un processore sicuro dedicato:

  • [C-SR] È MOLTO CONSIGLIATO supportare StrongBox. StrongBox diventerà probabilmente un requisito in una release futura.

Se le implementazioni dei dispositivi supportano StrongBox:

  • [C-1-1] È OBBLIGATORIO dichiarare FEATURE_STRONGBOX_KEYSTORE.

  • [C-1-2] È NECESSARIO fornire hardware sicuro dedicato utilizzato per eseguire il backup del keystore e per proteggere l'autenticazione utente. L'hardware sicuro dedicato può essere utilizzato anche per altri scopi.

  • [C-1-3] DEVE avere una CPU discreta che non condivide cache, DRAM, coprocessori o altre risorse di base con l'AP (Application Processor).

  • [C-1-4] DEVE garantire che le periferiche condivise con l'AP non possano alterare in alcun modo l'elaborazione di StrongBox o ottenere informazioni da StrongBox. L'AP POTREBBE disattivare o bloccare l'accesso a StrongBox.

  • [C-1-5] DEVE avere un orologio interno con una precisione ragionevole (+-10%) che sia immune alle manipolazioni da parte dell'AP.

  • [C-1-6] DEVE avere un generatore di numeri casuali veri che produca un output distribuito in modo uniforme e imprevedibile.

  • [C-1-7] DEVE essere resistente alle manomissioni, inclusa la penetrazione fisica e i glitch.

  • [C-1-8] DEVE avere resistenza ai canali laterali, inclusa la resistenza alla fuga di informazioni tramite canali laterali di alimentazione, temporizzazione, radiazioni elettromagnetiche e radiazioni termiche.

  • [C-1-9] DEVE avere uno spazio di archiviazione sicuro che garantisca la riservatezza, l'integrità, l'autenticità, la coerenza e l'aggiornamento dei contenuti. Lo spazio di archiviazione NON DEVE essere leggibile o modificabile, tranne nei casi consentiti dalle API StrongBox.

  • Per convalidare la conformità ai punti [C-1-3] fino a [C-1-9], le implementazioni dei dispositivi:

    • [C-1-10] DEVE includere l'hardware certificato in base al profilo di protezione delle smart card sicure BSI-CC-PP-0084-2014 o valutato da un laboratorio di test accreditato a livello nazionale che includa 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 includa la valutazione della vulnerabilità con potenziale di attacco elevato in base ai Common Criteria Application of Attack Potential to Smartcards.
    • [C-SR] È FORTEMENTE CONSIGLIATO includere l'hardware valutato utilizzando un target di sicurezza, Evaluation Assurance Level (EAL) 5, aumentato da AVA_VAN.5. La certificazione EAL 5 diventerà probabilmente un requisito in una release futura.

  • [C-SR] sono FORTEMENTE CONSIGLIATI per garantire la resistenza agli attacchi di tipo insider (IAR), il che significa che un insider con accesso alle chiavi di firma del firmware non può produrre firmware che causino la fuga di segreti da StrongBox, aggirino i requisiti di sicurezza funzionali o consentano in altro modo l'accesso a dati utente sensibili. Il modo consigliato per implementare l'IAR è consentire gli aggiornamenti del firmware solo quando la password dell'utente principale viene fornita tramite l'HAL IAuthSecret.

9.11.3. Credenziali di identità

Il sistema di credenziali di identità viene definito e realizzato implementando tutte le API nel pacchetto android.security.identity.*. Queste API consentono agli sviluppatori di app di archiviare e recuperare i documenti di identità degli utenti. Implementazioni dei dispositivi:

  • [C-SR] È MOLTO CONSIGLIATO implementare il Sistema di credenziali di identità.

Se le implementazioni dei dispositivi implementano il Sistema di credenziali di identità:

  • [C-0-1] DEVE restituire un valore non nullo per il metodo IdentityCredentialStore#getInstance().

  • [C-0-2] È OBBLIGATORIO implementare il Sistema di credenziali di identità (ad es. le API android.security.identity.*) con codice che comunica con un'applicazione attendibile in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e sopra. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA.

  • [C-0-3] Le operazioni di crittografia necessarie per implementare il Sistema di credenziali di identità (ad es. le API android.security.identity.*) DEVONO essere eseguite interamente nell'applicazione attendibile e il materiale della chiave privata NON DEVE mai uscire dall'ambiente di esecuzione isolato, a meno che non sia specificamente richiesto da API di livello superiore (ad es. il metodo createEphemeralKeyPair()).

  • [C-0-4] L'applicazione attendibile DEVE essere implementata in modo che le sue proprietà di sicurezza non siano interessate (ad es. i dati delle credenziali non vengono rilasciati a meno che non siano soddisfatte le condizioni di controllo dell'accesso, non è possibile produrre MAC per dati arbitrari) anche se Android non funziona correttamente o è compromesso.

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] È NECESSARIO eliminare tutti i dati nel file system userdata.
  • [C-0-3] DEVE eliminare i dati in modo da soddisfare gli standard di settore pertinenti, come NIST SP800-88.
  • [C-0-4] DEVE attivare la procedura di "Ripristino dei dati di fabbrica" riportata sopra quando l'API DevicePolicyManager.wipeData() viene chiamata dall'app Device Policy Controller dell'utente principale.
  • POTREBBE fornire un'opzione di eliminazione rapida dei dati che esegue solo un'eliminazione logica dei dati.

9.13. Modalità Avvio sicuro

Android fornisce la modalità Avvio sicuro, che consente agli utenti di avviarsi 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 dei dispositivi sono:

  • [SR] MOLTO CONSIGLIATO di implementare la modalità Avvio protetto.

Se le implementazioni dei dispositivi implementano la modalità di avvio sicuro, devono:

  • [C-1-1] DEVE fornire all'utente un'opzione per avviare la modalità provvisoria in modo che non possa essere interrotta dalle app di terze parti installate sul dispositivo, tranne quando l'app di terze parti è un controller Device Policy 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.

  • DOVREBBE 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 normale avvio.

9.14. Isolamento del sistema di veicoli a motore

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 reso sicuro implementando funzionalità di sicurezza sotto i livelli del framework Android per impedire l'interazione dannosa o involontaria con questi sottosistemi.

9.15. Piani di abbonamento

Per "Piani di abbonamento" si intendono i dettagli del piano del rapporto 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 in origine.
  • [C-0-2] NON DEVE eseguire il backup o caricare i piani di abbonamento da remoto.
  • [C-0-3] DEVE consentire le sostituzioni, ad esempio SubscriptionManager.setSubscriptionOverrideCongested(), solo dall'app dell'operatore di telefonia mobile che al momento fornisce piani di abbonamento validi.

9.16. Migrazione dei dati delle applicazioni

Se le implementazioni dei dispositivi includono la possibilità di eseguire la migrazione dei dati da un dispositivo a un altro e non limitano i dati dell'applicazione che vengono copiati a quelli configurati dallo sviluppatore dell'applicazione nel file manifest tramite l'attributo android:fullBackupContent, devono:

  • [C-1-1] NON DEVE avviare trasferimenti di dati delle applicazioni da dispositivi su cui l'utente non ha impostato un'autenticazione principale come descritto in 9.11.1 Schermata di blocco e autenticazione sicure.
  • [C-1-2] DEVE confermare in modo sicuro l'autenticazione principale sul dispositivo di origine e confermare con l'utente l'intenzione di copiare i dati sul dispositivo di origine prima che vengano trasferiti.
  • [C-1-3] È NECESSARIO utilizzare l'attestazione della chiave di sicurezza per assicurarsi che sia il dispositivo di origine sia il dispositivo di destinazione nella migrazione da dispositivo a dispositivo siano dispositivi Android legittimi e abbiano un bootloader bloccato.
  • [C-1-4] È NECESSARIO eseguire la migrazione dei dati dell'applicazione solo alla stessa applicazione sul dispositivo di destinazione, con lo stesso nome del pacchetto E lo stesso certificato di firma.
  • [C-1-5] NEL MENU Impostazioni DEVE essere indicata la migrazione dei dati del dispositivo di origine tramite una migrazione dei dati da dispositivo a dispositivo. Un utente NON DEVE essere in grado di rimuovere questa indicazione.

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, agli implementatori dei dispositivi è FORTEMENTE CONSIGLIATO 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 dei dispositivi:

  • [C-0-1] DEVE superare la Compatibility Test Suite (CTS) di Android 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 eventuali reimplementazioni 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 verrà numerata indipendentemente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni della CTS per Android 11.

Implementazioni dei dispositivi:

  • [C-0-3] DEVE superare la versione CTS più recente disponibile al momento del completamento del software del dispositivo.

  • DOVREBBE utilizzare l'implementazione di riferimento nella struttura Android Open Source il più possibile.

10.2. CTS Verifier

CTS Verifier è incluso nella Compatibility Test Suite e deve essere eseguito da un operatore umano per testare le funzionalità che non possono essere testate da un sistema automatico, ad esempio il corretto funzionamento di una fotocamera e dei sensori.

Implementazioni dei dispositivi:

  • [C-0-1] DEVE eseguire correttamente tutti i casi applicabili nel verificatore CTS.

CTS Verifier include test per molti tipi di hardware, incluso hardware facoltativo.

Implementazioni dei dispositivi:

  • [C-0-2] DEVE superare tutti i test per l'hardware di cui dispone; ad esempio, se un dispositivo dispone di un accelerometro, DEVE eseguire correttamente lo scenario di test Accelerometer in CTS Verifier.

Gli scenari di test per le funzionalità indicate come facoltative da questo documento di definizione della compatibilità POSSONO essere saltati o omessi.

  • [C-0-2] Ogni dispositivo e ogni build DEVONO eseguire correttamente lo strumento di verifica CTS, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori dei dispositivi eseguano esplicitamente CTS Verifier su build che differiscono solo in modo banale. In particolare, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato CTS Verifier solo per l'insieme di lingue, branding e così via inclusi POSSONO omettere il test CTS Verifier.

11. Software aggiornabile

  • [C-0-1] Le implementazioni dei dispositivi DEVONO includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire upgrade "in tempo reale", ovvero POTREBBE essere necessario riavviare il dispositivo. È possibile utilizzare qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, qualsiasi dei seguenti approcci soddisfa questo requisito:

    • I download "over-the-air (OTA)" con aggiornamento offline tramite riavvio.
    • Aggiornamenti "in tethering" tramite USB da un PC host.
    • Aggiornamenti "offline" tramite un riavvio e un aggiornamento da un file su una memoria rimovibile.

  • [C-0-2] Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. In altre parole, il meccanismo di aggiornamento DEVE preservare i dati privati e 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 in base a una chiave pubblica memorizzata sul dispositivo.

  • [C-SR] È FORTEMENTE CONSIGLIATO che il meccanismo di firma esegui l'hash dell'aggiornamento con SHA-256 e convalidi l'hash rispetto alla chiave pubblica utilizzando ECDSA NIST P-256.

Se le implementazioni del dispositivo includono il supporto di una connessione dati non misurata, ad esempio il profilo 802.11 o PAN (Personal Area Network) Bluetooth, devono:

  • [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 DOVREBBE supportare la verifica che l'immagine di sistema sia identica al risultato previsto dopo un aggiornamento OTA. L'implementazione OTA basata su blocchi nell'Android Open Source Project upstream, aggiunta 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 del boot.

Se viene rilevato un errore nell'implementazione di un dispositivo dopo il rilascio, ma entro il periodo di tempo ragionevole del prodotto, che viene stabilito in consultazione con il team di compatibilità di Android, che influisce sulla compatibilità delle applicazioni di terze parti:

  • [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 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, questi:

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 relative alle persone:

  1. Introduzione
  2. Tipi di dispositivi
  3. Software
  4. Confezione 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 della documentazione
  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 compilazione.

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 Android Compatibility e chiedere chiarimenti o segnalare eventuali problemi che ritieni non coperti dal documento.