Definizione di compatibilità con Android 10

1. Introduzione

Questo documento elenca i requisiti che devono essere soddisfatti per rendere i dispositivi compatibili con Android 10.

L'utilizzo di "DEVE", "NON DEVE", "OBBLIGATORIO", "SHALL", "NON CONSENTITO", "DOVREBRE", "NON DOVREBBE", "CONSIGLIATO", "MAGGIO" e "FACOLTATIVO" è conforme allo standard IETF definito nel documento RFC2119.

Nell'ambito di questo documento, per "implementatore del dispositivo" o "implementatore" si intende una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 10. Per "implementazione del dispositivo" o "implementazione" si intende la soluzione hardware/software così sviluppata.

Per essere considerate compatibili con Android 10, le implementazioni dei dispositivi DEVONO soddisfare i requisiti indicati nella presente definizione di compatibilità, compresi gli eventuali documenti incorporati tramite riferimento.

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

Per questo motivo, l'Android Open Source Project è sia il riferimento sia l'implementazione preferita di Android. Gli utenti che implementano i dispositivi sono VIVAMENTE CONSIGLIATI di basare le loro implementazioni il più possibile sul codice sorgente "upstream" disponibile nell'Android Open Source Project. Anche se alcuni componenti possono ipoteticamente essere sostituiti con implementazioni alternative, è VIVAMENTE CONSIGLIATO di non seguire questa prassi, in quanto il superamento dei test del software diventerà molto più difficile. È responsabilità dell'implementatore di garantire la piena compatibilità comportamentale con l'implementazione standard di Android, inclusa e oltre il Compatibility Test Suite. Infine, tieni presente che determinate sostituzioni e modifiche dei componenti sono espressamente vietate dal presente documento.

Molte delle risorse collegate in questo documento derivano direttamente o indirettamente dall'SDK Android e saranno identiche dal punto di vista funzionale alle informazioni contenute nella documentazione dell'SDK. Nei casi in cui la presente Definizione di compatibilità o il Test Suite di compatibilità non concordi con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevoli. Eventuali dettagli tecnici forniti nelle risorse collegate in questo documento sono considerati parte integrante della presente Definizione di compatibilità.

1.1 Struttura dei documenti

1.1.1. Requisiti per tipo di dispositivo

La Sezione 2 contiene tutti i requisiti che si applicano a un tipo di dispositivo specifico. Ogni sottosezione della Sezione 2 è dedicata a un tipo di dispositivo specifico.

Tutti gli altri requisiti, che valgono universalmente per le implementazioni dei dispositivi Android, sono elencati nelle sezioni successive alla Sezione 2. Nel presente documento, questi requisiti sono indicati come "Requisiti principali".

1.1.2. ID requisito

L'ID requisito è assegnato per i requisiti MUST.

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

Ogni ID è definito come di seguito:

  • ID tipo di dispositivo (per saperne di più, vedi 2. Tipi di dispositivi)
    • C: Core (requisiti che si applicano a tutte le implementazioni dei dispositivi Android)
    • H: Dispositivo portatile Android
    • T: Dispositivo Android TV
    • A: Implementazione di Android Automotive
    • W: Implementazione di Android Watch
    • Scheda: implementazione su tablet Android
  • ID condizione
    • Se il requisito è incondizionato, questo ID è impostato su 0.
    • Quando il requisito è condizionale, per la prima condizione viene assegnato 1 e il numero aumenta di 1 nella stessa sezione e nello stesso tipo di dispositivo.
  • ID requisito
    • Questo ID parte da 1 e aumenta di 1 nella stessa sezione e nella 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 l'Android Open Source Project fornisca uno stack di software utilizzabile per diversi tipi di dispositivi e fattori di forma, ci sono alcuni tipi di dispositivi che hanno un ecosistema di distribuzione delle applicazioni relativamente migliore consolidato.

In questa sezione vengono descritti questi tipi di dispositivi, nonché requisiti e consigli aggiuntivi applicabili a ciascun tipo.

Tutte le implementazioni su dispositivi Android che non rientrano in nessuno dei tipi di dispositivi descritti DEVONO comunque soddisfare tutti i requisiti riportati nelle altre sezioni della presente Definizione di compatibilità.

2.1 Configurazioni dei dispositivi

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 per gli smartphone

Un dispositivo portatile Android fa riferimento a un'implementazione su un dispositivo Android che viene solitamente utilizzato tenendolo in mano, ad esempio un lettore mp3, uno smartphone o un tablet.

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

  • Disporre di una fonte di alimentazione che garantisca la mobilità, ad esempio una batteria.
  • Lo schermo deve avere una diagonale fisica compresa tra 2,5 e 8 pollici.

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

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

2.2.1. Hardware

Implementazioni di dispositivi portatili:

  • [7.1.1.1/H-0-1] DEVE avere almeno un display compatibile con Android con diagonale fisica di almeno 2,5 pollici e ogni display compatibile con Android DEVE soddisfare tutti i requisiti descritti in questo documento.
  • [7.1.1.3/H-SR] È VIVAMENTE CONSIGLIATO di offrire agli utenti un'invito a modificare le dimensioni di visualizzazione (densità dello schermo).

Se le implementazioni dei dispositivi portatili rivendicano il supporto dei display High Dynamic Range tramite Configuration.isScreenHdr() , questi:

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

Implementazioni di dispositivi portatili:

  • [7.1.5/H-0-1] DEVE includere il supporto per la modalità di compatibilità delle applicazioni precedenti, così come implementata dal codice open source di Android upstream. In altre parole, le implementazioni dei dispositivi NON DEVONO alterare gli attivatori o le soglie ai quali viene attivata la modalità di compatibilità e NON DEVONO alterare il comportamento della modalità stessa.
  • [7.2.1/H-0-1] DEVE includere il supporto per le applicazioni IME (Input Method Editor) di terze parti.
  • [7.2.3/H-0-3] DEVE offrire la funzione Home su tutti i display compatibili con Android che hanno la schermata Home.
  • [7.2.3/H-0-4] DEVE fornire la funzione Indietro su tutti i display compatibili con Android e la funzione Recenti su almeno uno dei display compatibili con Android.
  • [7.2.3/H-0-2] DEVE inviare sia l'evento di pressione prolungata sia normale della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano. Questi eventi NON DEVONO essere consumati dal sistema e POSSONO essere attivati dall'esterno del dispositivo Android (ad esempio, una tastiera hardware esterna collegata al dispositivo Android).
  • [7.2.4/H-0-1] DEVE supportare l'input del touchscreen.
  • [7.2.4/H-SR] È VIVAMENTE CONSIGLIATO di avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService o un'attività che gestisce ACTION_ASSIST alla 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] È VIVAMENTE CONSIGLIATO di includere un accelerometro a 3 assi.

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

  • [7.3.1/H-1-1] DEVE essere in grado di segnalare eventi con una 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 della funzionalità android.hardware.location.gps, queste:

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

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

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

Implementazioni di dispositivi portatili che possono effettuare chiamate vocali e indicare qualsiasi valore diverso da PHONE_TYPE_NONE in getPhoneType:

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

Implementazioni di dispositivi portatili:

  • [7.3.11/H-SR] È CONSIGLIATO di supportare un sensore di posizione con 6 gradi di libertà.
  • [7.4.3/H] DOVREBBE includere il supporto per Bluetooth e Bluetooth LE.

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

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

Se le implementazioni dei dispositivi portatili includono una fotocamera logica che elenca le funzionalità utilizzando CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA:

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

Implementazioni di dispositivi portatili:

  • [7.6.1/H-0-1] DEVONO disporre di almeno 4 GB di spazio di archiviazione permanente per i dati privati dell'applicazione (ovvero partizione "/data").
  • [7.6.1/H-0-2] DEVE restituire "true" per ActivityManager.isLowRamDevice() se è disponibile meno di 1 GB di memoria per il kernel e lo spazio utente.

Se le implementazioni dei dispositivi portatili dichiarano il supporto soltanto di un'ABI a 32 bit:

  • [7.6.1/H-1-1] La memoria disponibile per il kernel e lo spazio utente 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 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 esempio, QWXGA).

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

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

  • [7.6.1/H-6-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere di almeno 944 MB se il display predefinito utilizza risoluzioni 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 esempio, QWXGA).

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

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

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

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

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

Implementazioni di dispositivi portatili:

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

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

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

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

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

Implementazioni di dispositivi portatili:

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

Se le implementazioni dei dispositivi portatili sono in grado di soddisfare tutti i requisiti di prestazioni per il supporto della modalità VR e includono il relativo supporto, queste:

  • [7.9.1/H-1-1] DEVE dichiarare il flag della funzionalità android.hardware.vr.high_performance.
  • [7.9.1/H-1-2] DEVE includere un'applicazione che implementa android.service.vr.VrListenerService che possa 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, queste:

  • [7.8.2.2/H-1-1] DEVE fornire la seguente mappatura software dei codici HID:
Funzione Mappature Il contesto Comportamento
R Pagina di utilizzo dell'HID: 0x0C
Utilizzo dell'HID: 0x0CD
Chiave del kernel: KEY_PLAYPAUSE
Chiave Android: KEYCODE_MEDIA_PLAY_PAUSE 		Riproduzione di contenuti multimediali Ingresso: pressione breve
Uscita: consente di riprodurre o mettere 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 Ingresso: pressione breve
Output: consente di accettare la chiamata
Ingresso: pressione prolungata.
Output: rifiuta la chiamata.
Chiamata in corso Ingresso: pressione breve
Uscita: termina la chiamata
Ingresso: pressione prolungata.
Output: disattiva o riattiva l'audio del microfono.
MLD Pagina di utilizzo HID: 0x0C
Utilizzo HID: 0x0E9
Chiave kernel: KEY_VOLUMEUP
Chiave Android: VOLUME_UP 		Riproduzione di contenuti multimediali, Chiamata in corso Ingresso: pressione breve o lunga
Uscita: consente di aumentare il volume del sistema o delle cuffie
C Pagina di utilizzo HID: 0x0C
Utilizzo HID: 0x0EA
Chiave kernel: KEY_VOLUMEDOWN
Chiave Android: VOLUME_DOWN 		Riproduzione di contenuti multimediali, Chiamata in corso Ingresso: pressione breve o lunga.
Uscita: consente di abbassare il volume del sistema o delle cuffie
D Pagina di utilizzo dell'HID: 0x0C
Utilizzo dell'HID: 0x0CF
Chiave del kernel: KEY_VOICECOMMAND
Chiave Android: KEYCODE_VOICE_ASSIST 		Tutti. Può essere attivato in qualsiasi istanza. Ingresso: pressione breve o lunga.
Output: avvia il comando vocale
  • [7.8.2.2/H-1-2] DEVE attivare ACTION_HEADSET_PLUG su un inserto, ma solo dopo che le interfacce audio e gli endpoint USB sono stati elencati correttamente per identificare il tipo di terminale collegato.

Quando vengono rilevati i terminali audio USB di tipo 0x0302, questi:

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

Quando vengono rilevati i terminali audio USB di tipo 0x0402, questi:

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

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

  • [7.8.2.2/H-4-1] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e il ruolo isSink() se il campo 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 Tipo di terminale audio USB è 0x0402.

  • [7.8.2.2/H-4-3] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_HEADSET e role isSource() se il campo 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 Tipo di terminale audio USB è 0x603.

  • [7.8.2.2/H-4-5] DEVE elencare un dispositivo di tipo AudioDeviceInfo.TYPE_USB_DEVICE e role isSource() se il campo 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 Tipo di terminale audio USB è 0x400.

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

  • [7.8.2.2/H-SR] Sono VIVAMENTE CONSIGLIATE al collegamento di una periferica audio USB-C per eseguire l'enumerazione dei descrittori USB, identificare i tipi di terminali e trasmettere l'intent ACTION_HEADSET_PLUG in meno di 1000 millisecondi.

2.2.2. Multimediale

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

  • [5.1/H-0-1] AMR-NB
  • [5.1/H-0-2] AMR-WB
  • [5.1/H-0-3] Profilo AAC MPEG-4 (AAC LC)
  • [5.1/H-0-4] Profilo MPEG-4 HE AAC (AAC+)
  • [5.1/H-0-5] AAC ELD (AAC a basso ritardo migliorato)

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

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

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

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

2.2.3. streaming

Implementazioni di dispositivi portatili:

  • [3.2.3.1/H-0-1] DEVE avere un'applicazione che gestisca gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE e ACTION_CREATE_DOCUMENT come descritto nei documenti dell'SDK e fornisca all'utente l'affetto per accedere ai dati del fornitore del documento utilizzando l'API DocumentsProvider.
  • [3.4.1/H-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.
  • [3.4.2/H-0-1] DEVE includere un'applicazione browser autonoma per la navigazione generale degli utenti sul web.
  • [3.8.1/H-SR] È VIVAMENTE CONSIGLIATO di implementare un'Avvio app predefinito che supporti il blocco in-app di scorciatoie, widget e funzionalità dei widget.
  • [3.8.1/H-SR] È VIVAMENTE CONSIGLIATO di implementare un'Avvio app predefinito che consenta di accedere rapidamente alle scorciatoie aggiuntive fornite da app di terze parti tramite l'API ShortcutManager.
  • [3.8.1/H-SR] È VIVAMENTE CONSIGLIATO di includere un'app Avvio app predefinita che mostra i badge per le icone delle app.
  • [3.8.2/H-SR] È VIVAMENTE CONSIGLIATO 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 evidenza.
  • [3.8.3/H-0-4] DEVE includere un'area notifiche che fornisca all'utente la possibilità di controllare direttamente (ad es. rispondere, posticipare, ignorare, bloccare) le notifiche tramite l'invito dell'utente, come i pulsanti di azione o il pannello di controllo, come implementato nell'AOSP.
  • [3.8.3/H-0-5] DEVE visualizzare le scelte fornite tramite RemoteInput.Builder setChoices() nell'area notifiche.
  • [3.8.3/H-SR] È VIVAMENTE CONSIGLIATO di visualizzare la prima scelta fornita tramite RemoteInput.Builder setChoices() nell'area notifiche senza ulteriori interazioni da parte dell'utente.
  • [3.8.3/H-SR] È VIVAMENTE CONSIGLIATO di visualizzare 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] È VIVAMENTE CONSIGLIATO di visualizzare 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] È VIVAMENTE CONSIGLIATO di implementare un assistente sul dispositivo per gestire l'azione di assistenza.

Se le implementazioni dei dispositivi portatili supportano l'azione Assist, queste:

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

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

  • [3.8.10/H-1-1] DEVE visualizzare le notifiche della schermata di blocco, incluso il modello di notifica dei contenuti multimediali.

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

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

Implementazioni di dispositivi portatili:

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

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 DEVE essere non superiore a 32 dp di altezza dalla parte inferiore dello schermo.

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

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

2.2.4. Prestazioni e potenza

  • [8.1/H-0-1] Latenza fotogrammi coerente. Una latenza di frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più di 5 frame al secondo e DEVE essere inferiore a 1 frame al secondo.
  • [8.1/H-0-2] Latenza dell'interfaccia utente. Le implementazioni dei dispositivi DEVONO garantire un'esperienza utente a bassa latenza scorrendo un elenco di 10.000 voci, come definito dalla suite per il test di compatibilità Android (CTS, Android Compatibility Test Suite, CTS) in meno di 36 secondi.
  • [8.1/H-0-3] Cambio di attività. Quando sono state lanciate più applicazioni, il riavvio di un'applicazione già in esecuzione dopo l'avvio DEVE richiedere meno di un secondo.

Implementazioni di 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 prestazioni 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 dei dispositivi incluse in AOSP o estendere le funzionalità incluse in AOSP, questi:

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

Implementazioni di dispositivi portatili:

  • [8.4/H-0-1] DEVE fornire un profilo di alimentazione per componente che definisca il valore del 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 indicare tutti i valori del consumo energetico in milliampere-ora (mAh).
  • [8.4/H-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID di ciascun processo. Il progetto open source Android soddisfa il requisito tramite l'implementazione del modulo kernel uid_cputime.
  • [8.4/H-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando della shell adb shell dumpsys batterystats allo sviluppatore dell'app.
  • [8.4/H] DEVE essere attribuita al componente hardware stesso se non è possibile attribuire l'utilizzo dell'energia del componente hardware a un'applicazione.

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

2.2.5. Modello di sicurezza

Implementazioni di dispositivi portatili:

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

Implementazioni di dispositivi portatili (* Non applicabile per i tablet):

  • [9.11/H-0-2]* DEVE eseguire il backup dell'implementazione dell'archivio chiavi con un ambiente di esecuzione isolato.
  • [9.11/H-0-3]* DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni di hash della famiglia MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema dell'archivio chiavi Android in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, compresa la DMA. L'upstream Android Open Source Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura esaminata da terze parti di un corretto isolamento basato su hypervisor sono opzioni alternative.
  • [9.11/H-0-4]* DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere archiviate in un modo che consenta solo all'ambiente di esecuzione isolato di eseguire l'autenticazione. L'upstream Android Open Source Project fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
  • [9.11/H-0-5]* DEVE supportare l'attestazione della chiave in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita su hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise tra un numero sufficiente di dispositivi da evitare che vengano utilizzate come identificatori del dispositivo. 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, POTREBBE essere utilizzata una chiave diversa per ogni 100.000 unità.

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

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

  • [9.11/H-1-1] DEVE consentire all'utente di scegliere il timeout di sospensione più breve, ovvero un tempo di transizione dallo stato sbloccato allo stato di blocco, della durata massima di 15 secondi.
  • [9.11/H-1-2] DEVE fornire l'invito all'utente per nascondere le notifiche e disattivare tutte le forme di autenticazione, ad eccezione dell'autenticazione principale descritta nella sezione 9.11.1 Schermata di blocco sicura. L'AOSP soddisfa il requisito come modalità di blocco.

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

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

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

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

2.2.6. Compatibilità degli strumenti e delle opzioni per sviluppatori

Implementazioni di dispositivi portatili (* Non applicabile per i tablet):

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

Implementazioni di dispositivi portatili (* Non applicabile per i tablet):

2.3. Requisiti per la televisione

Un dispositivo Android Television si riferisce a un'implementazione di dispositivi Android, ovvero un'interfaccia di intrattenimento che consente di utilizzare media digitali, film, giochi, app e/o TV in diretta per utenti seduti a circa 3 metri di distanza ("interfaccia utente di 3 metri di distanza").

Le implementazioni sui dispositivi Android sono classificate come televisori 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 incorporato con una lunghezza diagonale superiore a 24 pollici OPPURE includere una porta di uscita video, ad esempio VGA, HDMI, DisplayPort o una porta wireless per il display.

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

2.3.1. Hardware

Implementazioni di dispositivi televisivi:

  • [7.2.2/T-0-1] DEVE supportare D-pad.
  • [7.2.3/T-0-1] DEVE fornire le funzioni Home e Indietro.
  • [7.2.3/T-0-2] DEVE inviare sia l'evento di pressione prolungata sia normale della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano.
  • [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] DEVE fornire un telecomando da cui gli utenti possano accedere agli input della navigazione non touch e dei tasti di navigazione principali.

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

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

Implementazioni di dispositivi televisivi:

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

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

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

Se le implementazioni sui dispositivi TV sono a 32 bit:

  • [7.6.1/T-1-1] La memoria disponibile per il kernel e lo spazio utente 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 molto grandi

Se le implementazioni sui dispositivi TV sono a 64 bit:

  • [7.6.1/T-2-1] La memoria disponibile per il kernel e lo spazio utente 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 molto grandi

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

Implementazioni di dispositivi televisivi:

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

2.3.2. Multimediale

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

  • [5.1/T-0-1] Profilo AAC MPEG-4 (AAC LC)
  • [5.1/T-0-2] Profilo MPEG-4 HE AAC (AAC+)
  • [5.1/T-0-3] AAC ELD (AAC a basso ritardo migliorato)

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

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

Implementazioni di dispositivi televisivi:

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

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

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

  • [5.3.1/T-1-1] HD 1080p a 29,97 frame al secondo con profilo principale di alto livello.
  • [5.3.1/T-1-2] HD 1080i a 59,94 frame al secondo con profilo principale di alto livello. DEVONO deinterlacciare il video MPEG-2 e renderlo disponibile ad applicazioni di terze parti.

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

  • [5.3.4/T-1-1] HD 1080p a 60 frame al secondo con profilo di riferimento
  • [5.3.4/T-1-2] HD 1080p a 60 frame al secondo con profilo principale
  • [5.3.4/T-1-3] HD 1080p a 60 frame al secondo con profilo alto livello 4.2

Le implementazioni di dispositivi televisivi con decodificatori hardware H.265 DEVONO supportare la decodifica H.265, come descritto nella Sezione 5.3.5, a frequenze fotogrammi e risoluzioni standard per i video fino a un massimo di:

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

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

  • [5.3.5/T-2-1] DEVE supportare il profilo di decodifica UHD a 60 frame al secondo con il profilo di livello principale Main10 Livello 5.

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

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

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

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

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

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

Implementazioni di dispositivi televisivi:

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

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

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

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

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

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

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

2.3.3. streaming

Implementazioni di dispositivi televisivi:

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

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

  • [3.8.10/T-1-1] DEVE visualizzare le notifiche della schermata di blocco, incluso il modello di notifica dei contenuti multimediali.

Implementazioni di dispositivi televisivi:

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

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

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

Implementazioni di dispositivi televisivi:

  • [3.12/T-0-1] DEVE supportare il framework di input TV.

2.3.4. Prestazioni e potenza

  • [8.1/T-0-1] Latenza fotogrammi coerente. Una latenza di frame incoerente o un ritardo nel rendering dei frame NON DEVE verificarsi più di 5 frame al secondo e DEVE essere inferiore a 1 frame 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 prestazioni di scrittura casuale di almeno 0,5 MB/s.
  • [8.2/T-0-3] DEVE garantire prestazioni 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 televisivi includono funzioni per migliorare la gestione dell'alimentazione dei dispositivi incluse in AOSP o estendere le funzioni incluse in AOSP, questi:

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

Se le implementazioni dei dispositivi televisivi non hanno una batteria:

Se le implementazioni dei dispositivi televisivi:

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

Implementazioni di dispositivi televisivi:

  • [8.4/T-0-1] DEVE fornire un profilo di alimentazione per componente che definisca il valore del 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/T-0-2] DEVE indicare tutti i valori del consumo energetico in milliampere-ora (mAh).
  • [8.4/T-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID di ciascun processo. Il progetto open source Android soddisfa il requisito tramite l'implementazione del modulo kernel uid_cputime.
  • [8.4/T] DEVE essere attribuita al componente hardware stesso se non è possibile attribuire l'utilizzo dell'energia del componente hardware a un'applicazione.
  • [8.4/T-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando della shell adb shell dumpsys batterystats allo sviluppatore dell'app.

2.3.5. Modello di sicurezza

Implementazioni di dispositivi televisivi:

  • [9.11/T-0-1] DEVE eseguire il backup dell'implementazione dell'archivio chiavi con un ambiente di esecuzione isolato.
  • [9.11/T-0-2] DEVE avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni di hash della famiglia MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema dell'archivio chiavi Android in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, compresa la DMA. L'upstream Android Open Source Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura esaminata da terze parti di un corretto isolamento basato su hypervisor sono opzioni alternative.
  • [9.11/T-0-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere archiviate in un modo che consenta solo all'ambiente di esecuzione isolato di eseguire l'autenticazione. L'upstream Android Open Source Project fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
  • [9.11/T-0-4] DEVE supportare l'attestazione della chiave in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita su hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise tra un numero sufficiente di dispositivi da evitare che vengano utilizzate come identificatori del dispositivo. 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, POTREBBE essere utilizzata una chiave diversa per ogni 100.000 unità.

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

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

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

Se le implementazioni dei dispositivi televisivi includono più utenti e non viene dichiarato il flag funzionalità android.hardware.telephony, questi:

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

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

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

2.3.6. Compatibilità degli strumenti e delle opzioni per sviluppatori

Implementazioni di dispositivi televisivi:

2.4. Requisiti dell'orologio

Un dispositivo Android Watch si riferisce all'implementazione di un dispositivo Android da indossare a corpo, magari al polso.

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

  • Avere uno schermo con la lunghezza diagonale fisica nell'intervallo da 1,1 a 2,5 pollici.
  • Disporre di un meccanismo da indossare sul corpo.

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

2.4.1. Hardware

Implementazioni dell'orologio:

  • [7.1.1.1/W-0-1] DEVE avere uno schermo con diagonale fisica nell'intervallo da 1,1 a 2,5 pollici.

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

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

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

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

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

Se le implementazioni dello smartwatch includono un giroscopio a 3 assi:

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

Implementazioni dell'orologio:

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

  • [7.6.1/W-0-1] DEVE avere almeno 1 GB di spazio di archiviazione permanente disponibile per i dati privati dell'applicazione (ovvero 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] MAGGIO, ma NON DEVE avere un'uscita audio.

2.4.2. Multimediale

Nessun altro requisito.

2.4.3. streaming

Implementazioni dell'orologio:

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

Implementazioni dell'orologio:

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

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

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

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

  • [3.11/W-SR] È VIVAMENTE CONSIGLIATO di includere un motore di sintesi vocale che supporti le lingue disponibili sul dispositivo.

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

2.4.4. Prestazioni e potenza

Se le implementazioni dei dispositivi Watch includono funzionalità per migliorare la gestione dell'alimentazione del dispositivo incluse in AOSP o estendere le funzionalità incluse in AOSP, questi:

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

Implementazioni dell'orologio:

  • [8.4/W-0-1] DEVE fornire un profilo di alimentazione per componente che definisca il valore del consumo attuale 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] DEVE indicare tutti i valori del consumo energetico in milliampere-ora (mAh).
  • [8.4/W-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID di ciascun processo. Il progetto open source Android soddisfa il requisito tramite l'implementazione del modulo kernel uid_cputime.
  • [8.4/W-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando della shell adb shell dumpsys batterystats allo sviluppatore dell'app.
  • [8.4/W] DEVE essere attribuita al componente hardware stesso se non è possibile attribuire l'utilizzo dell'energia del componente hardware a un'applicazione.

2.4.5. Modello di sicurezza

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

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

Se le implementazioni sui dispositivi Watch includono più utenti e dichiarano il flag funzionalità android.hardware.telephony, questi:

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

2.5. Requisiti per il settore automobilistico

L'implementazione di Android Automotive si riferisce a un'unità principale del veicolo su cui è in esecuzione Android come sistema operativo per l'intero sistema e/o la funzionalità di infotainment o per intero.

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

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

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

2.5.1. Hardware

Implementazioni di dispositivi nel settore auto e motori:

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

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

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

  • [7.2.3/A-0-2] DEVE inviare sia l'evento di pressione prolungata sia normale della funzione Indietro (KEYCODE_BACK) all'applicazione in primo piano.
  • [7.3/A-0-1] DEVE implementare e segnalare GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED e PARKING_BRAKE_ON.
  • [7.3/A-0-2] Il valore del flag NIGHT_MODE DEVE essere coerente con la modalità giorno/notte della dashboard e DEVE essere basato sull'input del sensore di luce ambientale. Il sensore di luce ambientale sottostante POTREBBE essere lo stesso del Fotometro.
  • [7.3/A-0-3] DEVE fornire un campo informativo aggiuntivo sul sensore TYPE_SENSOR_PLACEMENT come parte delle informazioni aggiuntive sul sensore per ogni sensore fornito.
  • [7.3/A-0-1] POTREBBE considerare la posizione fondendo GPS/GNSS con sensori aggiuntivi. Se la Località non è considerata definitiva, è VIVAMENTE CONSIGLIATO di implementare e segnalare i tipi di sensori e/o gli ID proprietà veicolo corrispondenti utilizzati.
  • [7.3/A-0-2] La Località richiesta tramite LocationManager#requestLocationUpdates() NON DEVE corrispondere alla mappa.

Se le implementazioni dei dispositivi Auto e motori includono un accelerometro a 3 assi, questi:

Se le implementazioni dei dispositivi Auto e motori includono un giroscopio a 3 assi, questi:

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

Implementazioni di dispositivi nel settore auto e motori:

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

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

    • Chiamate con Profilo in vivavoce (HFP).
    • Riproduzione di contenuti multimediali tramite Audio Distribution Profile (A2DP).
    • Controllo della riproduzione di contenuti multimediali tramite Remote Control Profile (AVRCP).
    • Condivisione dei contatti tramite il Phone Book Access Profile (PBAP).

  • [7.4.3/A-SR] È VIVAMENTE CONSIGLIATO per il supporto del Message Access Profile (MAP).

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

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

Una videocamera per esterni è una videocamera che riproduce scene al di fuori dell'implementazione del dispositivo, ad esempio una dashcam.

Implementazioni di dispositivi nel settore auto e motori:

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

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

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

Implementazioni di dispositivi nel settore auto e motori:

  • [7.6.1/A-0-1] DEVONO disporre di almeno 4 GB di spazio di archiviazione permanente per i dati privati dell'applicazione (ovvero partizione "/data").

  • [7.6.1/A] DEVE formattare la partizione dei dati per offrire prestazioni e longevità migliori sullo spazio di archiviazione flash, ad esempio utilizzando un file system f2fs.

Se le implementazioni dei dispositivi Automotive forniscono una memoria esterna condivisa tramite una parte della memoria interna non rimovibile,

  • [7.6.1/A-SR] È VIVAMENTE CONSIGLIATO per ridurre l'overhead I/O sulle 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 viene utilizzata una delle seguenti densità:

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

  • [7.6.1/A-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 grandi
    • mdpi o superiore su schermi molto grandi

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

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

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

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

Se le implementazioni dei dispositivi Automotive sono a 64 bit:

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

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

  • [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 grandi
    • mdpi o superiore su schermi molto grandi

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

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

  • [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 molto grandi

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

Implementazioni di dispositivi nel settore auto e motori:

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

Implementazioni di dispositivi nel settore auto e motori:

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

Implementazioni di dispositivi nel settore auto e motori:

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

2.5.2. Multimediale

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

  • [5.1/A-0-1] Profilo AAC MPEG-4 (AAC LC)
  • [5.1/A-0-2] Profilo MPEG-4 HE AAC (AAC+)
  • [5.1/A-0-3] AAC ELD (AAC a basso ritardo migliorato)

Le implementazioni dei dispositivi automobilistici DEVONO supportare i seguenti formati di codifica video e renderli disponibili ad applicazioni di terze parti:

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

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

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

Le implementazioni dei dispositivi per auto e motori sono VIVAMENTE CONSIGLIATE per supportare la seguente decodifica video:

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

2.5.3. streaming

Implementazioni di dispositivi nel settore auto e motori:

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

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

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

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

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

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

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

Se le implementazioni dei dispositivi Auto e motori includono un pulsante Premi per parlare:

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

Implementazioni di dispositivi nel settore auto e motori:

  • [3.8.3.1/A-0-1] DEVE eseguire il rendering delle risorse correttamente come descritto nella documentazione dell'SDK Notifications on Automotive OS.
  • [3.8.3.1/A-0-2] DEVE visualizzare le opzioni RIPRODUCI e DISATTIVARE AUDIO per le azioni di notifica al posto di quelle fornite tramite Notification.Builder.addAction()
  • [3.8.3.1/A] DEVONO limitare l'uso di attività di gestione avanzate, come i controlli dei canali di notifica. POTREBBE utilizzare l'autorizzazione UI per applicazione per ridurre i controlli.

Implementazioni di dispositivi nel settore auto e motori:

Se le implementazioni dei dispositivi Auto e motori includono un'app Avvio app predefinita, queste:

Implementazioni di dispositivi nel settore auto e motori:

2.5.4. Prestazioni e potenza

Implementazioni di dispositivi nel settore auto e motori:

  • [8.2/A-0-1] DEVE segnalare il numero di byte letti e scritti nello spazio di archiviazione permanente per l'UID di ciascun processo, in modo che le statistiche siano disponibili per gli sviluppatori tramite l'API di sistema android.car.storagemonitoring.CarStorageMonitoringManager. Il progetto open source Android soddisfa i requisiti tramite il modulo kernel uid_sys_stats.
  • [8.3/A-1-3] DEVE attivare la modalità garage almeno una volta prima di spegnere l'auto.
  • [8.3/A-1-4] DEVE essere in modalità garage per almeno 15 minuti a meno che:
    • La batteria è scarica.
    • Nessun job inattivo pianificato.
    • Il conducente esce dalla modalità Garage.
  • [8.4/A-0-1] DEVE fornire un profilo alimentazione per componente che definisca il valore del 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/A-0-2] DEVE indicare tutti i valori del consumo energetico in milliampere-ora (mAh).
  • [8.4/A-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID di ciascun processo. Il progetto open source Android soddisfa il requisito tramite l'implementazione del modulo kernel uid_cputime.
  • [8.4/A] DEVE essere attribuita al componente hardware stesso se non è possibile attribuire l'utilizzo dell'energia del componente hardware a un'applicazione.
  • [8.4/A-0-4] DEVE rendere disponibile questo consumo energetico tramite il comando della shell adb shell dumpsys batterystats allo sviluppatore dell'app.

2.5.5. Modello di sicurezza

Se le implementazioni dei dispositivi Auto e motori supportano più utenti, questi:

Implementazioni di dispositivi nel settore auto e motori:

  • [9.11/A-0-1] DEVE eseguire il backup dell'implementazione dell'archivio chiavi con un ambiente di esecuzione isolato.
  • [9.11/A-0-2] DEVE avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni di hash della famiglia MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema dell'archivio chiavi Android in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e su versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, compresa la DMA. L'upstream Android Open Source Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura esaminata da terze parti di un corretto isolamento basato su hypervisor sono opzioni alternative.
  • [9.11/A-0-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere archiviate in un modo che consenta solo all'ambiente di esecuzione isolato di eseguire l'autenticazione. L'upstream Android Open Source Project fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
  • [9.11/A-0-4] DEVE supportare l'attestazione della chiave in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita su hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise tra un numero sufficiente di dispositivi da evitare che vengano utilizzate come identificatori del dispositivo. 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, POTREBBE essere utilizzata una chiave diversa per ogni 100.000 unità.

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

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

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

Implementazioni di dispositivi nel settore auto e motori:

  • [9.14/A-0-1] DEVONO limitare i messaggi provenienti dai sottosistemi dei veicoli del framework Android, ad esempio inserendo nella lista consentita i tipi di messaggi e le origini dei messaggi consentiti.
  • [9.14/A-0-2] DEVE essere il watchdog dagli attacchi denial of service da parte del framework Android o di app di terze parti. Questo protegge da software dannoso che inonda di traffico la rete veicolare, causando il malfunzionamento dei sottosistemi del veicolo.

2.5.6. Compatibilità degli strumenti e delle opzioni per sviluppatori

Implementazioni di dispositivi nel settore auto e motori:

2.6. Requisiti per i tablet

Un dispositivo tablet Android fa riferimento a un'implementazione del dispositivo Android che soddisfa tutti i seguenti criteri:

  • In genere si usa tenendo entrambe le mani.
  • Non ha una configurazione clamshell o convertibile.
  • Qualsiasi implementazione della tastiera fisica utilizzata con il dispositivo DEVE connettersi tramite una connessione standard.
  • Ha una fonte di alimentazione che garantisce la mobilità, ad esempio una batteria.
  • Ha una dimensione dello schermo diagonale fisica compresa tra 7 e 18 pollici.

Le implementazioni dei tablet hanno requisiti simili a quelli delle implementazioni sui dispositivi portatili. Le eccezioni sono indicate con un asterisco (*) e sono indicate come riferimento in questa sezione.

2.6.1. Hardware

Dimensioni schermo

  • [7.1.1.1/Tab-0-1] DEVE avere uno schermo nell'intervallo da 7 a 18 pollici.

Giroscopio

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

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

Memoria e spazio di archiviazione minimi (Sezione 7.6.1)

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

Modalità periferica USB (Sezione 7.7.1)

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

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

Modalità di realtà virtuale (Sezione 7.9.1)

Prestazioni elevate di realtà virtuale (Sezione 7.9.2)

I requisiti di realtà virtuale non si applicano ai tablet.

2.6.2. Modello di sicurezza

Chiavi e credenziali (Sezione 9.11)

Consulta la Sezione [9.11].

Se le implementazioni dei dispositivi tablet includono più utenti e non viene dichiarato il flag funzionalità android.hardware.telephony, questi:

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

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

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

3. streaming

3.1. Compatibilità delle API gestite

L'ambiente di esecuzione bytecode Dalvik gestito è il veicolo principale per le app per Android. L'API (Application Programming Interface) di Android è un 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 per Android o di qualsiasi API decorata con l'indicatore "@SystemApi" nel codice sorgente 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, alterare le interfacce o le firme delle API, deviare dal comportamento documentato o includere nessuna operazione, salvo laddove specificamente consentito dalla presente Definizione di compatibilità.

  • [C-0-4] DEVE mantenere comunque le API e comportarsi in modo ragionevole, anche se alcune funzionalità hardware per cui Android include API sono omesse. Consulta la sezione 7 per i requisiti specifici relativi a questo scenario.

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

  • [C-0-6] DEVE essere fornita con ogni interfaccia non SDK negli stessi elenchi limitati forniti tramite l'elenco provvisorio e i flag della lista bloccata nel percorso prebuilts/runtime/appcompat/hiddenapi-flags.csv per il ramo del livello API appropriato nell'AOSP.

    Tuttavia:

    • MAGGIO, se un'API nascosta non è presente o implementata in modo diverso nell'implementazione del dispositivo, spostala nella lista bloccata o omettila da tutti gli elenchi con restrizioni.
    • MAGGIO, se nell'AOSP non esiste già un'API nascosta, aggiungila a uno degli elenchi con restrizioni.

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

3.1.1. Estensioni Android

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

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

3.1.2. Raccolta Android

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

  • [C-0-1] NON DEVE inserire la libreria org.apache.http.legacy nel percorso bootclass.
  • [C-0-2] DEVE aggiungere la libreria org.apache.http.legacy al classpath dell'applicazione solo se l'app soddisfa una delle seguenti condizioni:
    • Ha come target il livello API 28 o un livello inferiore.
    • Dichiara nel file manifest che ha bisogno della libreria impostando 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 per il runtime, sotto forma di, ad esempio, intent, autorizzazioni e aspetti simili delle app per Android che non possono essere applicati al momento della compilazione dell'applicazione.

3.2.1. Autorizzazioni

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

3.2.2. Parametri build

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 riportata di seguito include limitazioni aggiuntive sui formati di questi valori a cui le implementazioni dei dispositivi DEVONO essere conformi.
Parametro Dettagli
VERSIONE.LANCIO La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE avere uno dei valori di stringa definiti nella sezione 10.
VERSIONE.SDK La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 10, questo campo DEVE avere il valore intero 10_INT.
VERSION.SDK_INT La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 10, questo campo DEVE avere il valore intero 10_INT.
VERSIONE.INCREMENTALE 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 diverse build rese disponibili agli utenti finali. Un utilizzo tipico di questo campo è quello di 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 in formato 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. Questo campo può essere utilizzato per 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 e che è noto agli utenti finali. DEVONO essere in formato leggibile e DEVONO rappresentare il produttore del dispositivo o il brand aziendale con cui il dispositivo viene commercializzato. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
SUPPORTO_ABIS Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle API native.
SUPPORTO_32_BIT_ABIS Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle API native.
SUPPORTATO_64_BIT_ABIS Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle API native.
CPU_ABI Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità delle 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à delle 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 di questo dispositivo NON DEVE cambiare per tutta la durata del prodotto.
IMPRONTA Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile. DEVE seguire questo modello:

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

Ecco alcuni esempi:

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

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

HARDWARE Il nome dell'hardware (dalla riga di comando del kernel o da /proc). DEVE essere ragionevolmente leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
PRESENTATORE Una stringa che identifica in modo univoco l'host su cui è stata basata la build, in formato leggibile. Non esistono requisiti sul formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere null o la stringa vuota ("").
ID Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in formato leggibile. Questo campo può essere uguale ad android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere tra build del software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
PRODUTTORE Il nome commerciale del produttore di apparecchiature originali (OEM) del prodotto. Non esistono requisiti relativi al formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere nullo o con la stringa vuota (""). Questo campo NON DEVE cambiare per tutta la durata del prodotto.
MODELLO Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo noto all'utente finale. DEVE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non esistono requisiti relativi al formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere nullo o con la stringa vuota (""). Questo campo NON DEVE cambiare per tutta la durata 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 deve essere necessariamente visibile agli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Questo nome di prodotto NON DEVE cambiare per tutta la durata del prodotto.
SERIE DEVE restituire "UNKNOWN".
TAG Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che contraddistinguono 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 tipiche di firma della piattaforma Android: chiavi di rilascio, chiavi dev e chiavi di test.
DURATA Un valore che rappresenta il timestamp di quando è avvenuta la build.
MACCHINA Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni tipiche di runtime Android: user, userdebug o eng.
UTENTE Il nome o l'ID utente dell'utente (o dell'utente automatico) che ha generato la build. Non esistono requisiti sul formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere null o la stringa vuota ("").
PATCH_DI_SICUREZZA Un valore che indica il livello patch di sicurezza di una build. DEVE indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti nel Bollettino sulla sicurezza pubblica di Android designato. DEVE essere nel formato [AAAA-MM-GG], corrispondente a una stringa definita documentata nel Bollettino sulla sicurezza pubblica di Android o nell'Avviso sulla sicurezza di Android, ad esempio "2015-11-01".
Sistema operativo BASE Un valore che rappresenta il parametro FINGERPRINT della build che è altrimenti identico a questa build, ad eccezione delle patch fornite nel Bollettino sulla sicurezza pubblica di Android. DEVE segnalare il valore corretto e, se la build non esiste, segnalare una stringa vuota ("").
BOOTLOADER Un valore scelto dall'implementatore del dispositivo che identifica la versione del bootloader interno specifica 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 identifichi la versione radio/modem interna specifica utilizzata nel dispositivo, in formato leggibile. Se un dispositivo non dispone di 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 per tutti i dispositivi con lo stesso MODELLO e PRODUTTORE. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-,]+$".

3.2.3. Compatibilità degli intent

3.2.3.1. Application Intent principali

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

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

    • Orologio da scrivania
    • Browser
    • Calendar
    • Contatti
    • Galleria
    • Ricerca globale
    • Avvio app
    • Musica
    • Impostazioni
3.2.3.2. Risoluzione dell'intenzione

  • [C-0-1] Poiché Android è una piattaforma estensibile, le implementazioni dei dispositivi DEVONO consentire che ogni pattern di intent a cui si fa riferimento nella sezione 3.2.3.1 , ad eccezione delle 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 attribuire privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema, né impedire alle applicazioni di terze parti di vincolarsi a questi pattern e di assumerne il controllo. Questo divieto include nello specifico, a titolo esemplificativo, la disattivazione dell'interfaccia utente "Selettore", che consente all'utente di scegliere tra più applicazioni che gestiscono tutte lo stesso pattern di intent.

  • [C-0-3] Le implementazioni sui 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 dei dati. Ad esempio, un pattern di filtro per intent che specifica l'URI di dati "http://www.android.com" è più specifico del pattern di intent principale del browser per "http://".

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

  • [C-0-4] DEVE tentare di convalidare eventuali filtri per intent eseguendo i passaggi di convalida definiti nella specifica Digital Asset Links come implementata dal gestore di pacchetti nel progetto open source Android a monte.
  • [C-0-5] DEVE tentare la convalida dei filtri per intent durante l'installazione dell'applicazione e impostare tutti i filtri per intent URI convalidati come gestori di app predefiniti per i relativi URI.
  • POTREBBE impostare filtri di intent specifici per gli URI come gestori di app predefiniti per i relativi URI, se vengono verificati correttamente, ma gli altri filtri URI candidati non superano la verifica. Se l'implementazione avviene in questo modo, DEVE fornire all'utente override appropriati di pattern per URI nel menu delle impostazioni.
  • DEVE fornire all'utente i controlli dei link alle app per ogni app nelle Impostazioni, come descritto di seguito:
    • [C-0-6] L'utente DEVE essere in grado di ignorare in modo olistico il comportamento predefinito dei link dell'app affinché un'app sia sempre aperta, sempre chiedere o mai aperta, il che DEVE essere applicato a tutti i filtri per intent dell'URI candidati allo stesso modo.
    • [C-0-7] L'utente DEVE essere in grado di visualizzare un elenco di filtri per intent dell'URI candidati.
    • L'implementazione del dispositivo POTREBBE offrire all'utente la possibilità di ignorare specifici filtri per intent dell'URI candidato che sono stati verificati correttamente, in base a un filtro per intent.
    • [C-0-8] L'implementazione del dispositivo DEVE offrire agli utenti la possibilità di visualizzare e sostituire specifici filtri per intent dell'URI candidato se l'implementazione del dispositivo consente ad alcuni filtri di intent di tipo URI candidati di completare la verifica, mentre altri no.
3.2.3.3. Spazi dei nomi per intent
  • [C-0-1] Le implementazioni dei dispositivi NON DEVONO includere componenti Android che rispettano i nuovi pattern di intent o di trasmissione degli intent utilizzando un parametro ACTION, CATEGORY o un'altra stringa chiave nello spazio dei nomi android. o com.android..
  • [C-0-2] Gli implementatori dei dispositivi NON DEVONO includere componenti Android che rispettano i nuovi pattern di intent o di trasmissione di intent utilizzando un'AZIONE, una CATEGORIA o un'altra stringa chiave in uno spazio di pacchetti appartenente a un'altra organizzazione.
  • [C-0-3] Gli utenti che implementano i dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent utilizzati dalle app principali elencate nella sezione 3.2.3.1.
  • Le implementazioni sui dispositivi POTREBBERO includere pattern di intent che utilizzano spazi dei nomi in modo chiaro e ovvio associati alla propria organizzazione. Questo divieto è analogo a quello specificato per le classi di linguaggio Java nella sezione 3.6.
3.2.3.4. Intent di trasmissione

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

Implementazioni dei dispositivi:

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

Android include impostazioni che consentono agli utenti di selezionare facilmente le applicazioni predefinite, ad esempio per la schermata Home o gli SMS.

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

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

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

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

Se le implementazioni del dispositivo supportano VoiceInteractionService e vengono installate contemporaneamente più di un'applicazione che utilizza questa API:

3.2.4. Attività su display secondari/multipli

Se le implementazioni dei dispositivi consentono di avviare le normali Attività Android su più display, questi:

  • [C-1-1] DEVE impostare il flag funzionalità android.software.activities_on_secondary_displays.
  • [C-1-2] DEVE garantire la compatibilità dell'API, analogamente a un'attività in esecuzione sul display principale.
  • [C-1-3] DEVE indirizzare la nuova attività alla stessa visualizzazione dell'attività che l'ha avviata, quando la nuova attività viene lanciata senza specificare una visualizzazione target tramite l'API ActivityOptions.setLaunchDisplayId().
  • [C-1-4] DEVE eliminare tutte le attività quando viene rimossa una visualizzazione con il flag Display.FLAG_PRIVATE.
  • [C-1-5] DEVE nascondere in modo sicuro i contenuti su tutti gli schermi quando il dispositivo è bloccato con una schermata di blocco sicura, a meno che l'app non attivi la visualizzazione nella parte superiore della schermata di blocco utilizzando l'API Activity#setShowWhenLocked().
  • DEVE avere android.content.res.Configuration che corrisponde a quel display per poter essere visualizzato, funzionare correttamente e mantenere la compatibilità se un'attività viene avviata sul display secondario.

Se le implementazioni del dispositivo consentono di avviare le normali Attività Android su display secondari e un display secondario presenta il flag android.view.Display.FLAG_PRIVATE:

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

3.3. Compatibilità API native

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

  • [SR] VIVAMENTE CONSIGLIATO di usare le implementazioni delle librerie elencate di seguito del progetto open source Android a monte.

3.3.1. Interfacce binarie dell'applicazione

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

Implementazioni dei dispositivi:

  • [C-0-1] DEVE essere compatibile con una o più ABI definite e implementare la compatibilità con Android NDK.
  • [C-0-2] DEVE includere il supporto per il codice in esecuzione nell'ambiente gestito per richiamare il codice nativo, utilizzando la semantica standard di Java Native Interface (JNI).
  • [C-0-3] DEVE essere compatibile con l'origine (ad esempio compatibile con l'intestazione) e compatibile con il programma binario (per l'ABI) con ciascuna libreria obbligatoria nell'elenco seguente.
  • [C-0-5] DEVE segnalare con precisione l'ABI (Application Binary Interface) nativa supportata dal dispositivo tramite i parametri android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, ognuno con un elenco separato da virgole di ABI ordinate dalla più alla meno preferita.

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

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

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

    • libaaudio.so (supporto audio nativo AAudio)

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

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

  • [C-0-9] DEVE elencare le librerie non AOSP aggiuntive esposte direttamente ad 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 superiore in quanto riservate.
  • [C-0-11] DEVE esportare tutti i simboli delle funzioni OpenGL ES 3.1 e Android Extension Pack, come definito nell'NDK, tramite la libreria libGLESv3.so. Si noti che sebbene tutti i simboli DEVONO essere presenti, la sezione 7.1.4.1 descrive più dettagliatamente i requisiti per quando è prevista l'implementazione completa di ciascuna funzione corrispondente.
  • [C-0-12] DEVE esportare i simboli di funzione per i simboli di funzione principali di Vulkan 1.0 e 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. Si noti che sebbene tutti i simboli DEVONO essere presenti, la sezione 7.1.4.2 descrive più dettagliatamente i requisiti per quando è prevista l'implementazione completa di ciascuna funzione corrispondente.
  • DOVREBBE essere create utilizzando il codice sorgente e i file di intestazione disponibili nel progetto open source Android a monte

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

3.3.2. Compatibilità del codice nativo ARM a 32 bit

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

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

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

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

    • Features:, seguita 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ù supportata del 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 implementata su un'architettura ARMv8, attraverso il supporto della CPU nativa o tramite l'emulazione software:

    • istruzioni per SWP e SWPB.
    • istruzione SETEND.
    • Operazioni con barriera CP15ISB, CP15DSB e CP15DMB.

  • [C-2-3] DEVE includere il supporto per l'estensione SIM avanzato (noto 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] DEVE segnalare android.software.webview.
  • [C-1-2] DEVE utilizzare la build del progetto Chromium dall'Android Open Source Project a monte sulla filiale Android 10 per l'implementazione dell'API android.webkit.WebView.

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

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

    • Il valore della stringa $(VERSION) DEVE essere uguale al valore di android.os.Build.VERSION.RELEASE.
    • La stringa $(MODEL) POTREBBE essere vuota, ma se non è vuota DEVE avere lo stesso valore di android.os.Build.MODEL.
    • "Build/$(BUILD)" POTREBBE essere omesso, ma se è presente, 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 a monte.
    • Le implementazioni dei dispositivi POSSONO omettere "Mobile" nella stringa dello user agent.

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

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

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

3.4.2. Compatibilità del browser

Se le implementazioni del dispositivo includono un'applicazione browser autonoma per la navigazione generica sul web, queste:

  • [C-1-1] DEVE supportare ciascuna di queste API associate a HTML5:
  • [C-1-2] DEVE supportare l'API webstorage HTML5/W3C e DEVE supportare l'API IndexedDB per HTML5/W3C. Tieni presente che, poiché gli enti degli standard di sviluppo web stanno passando a preferire IndexedDB rispetto allo spazio di archiviazione web, è previsto che IndexedDB diventerà un componente obbligatorio in una versione futura di Android.
  • POTREBBE spedire una stringa dello user agent personalizzata nell'applicazione browser autonoma.
  • DEVONO implementare il supporto per il maggior numero possibile di HTML5 sull'applicazione browser autonoma (in base all'applicazione browser WebKit a monte o a una sostituzione di terze parti).

Tuttavia, se le implementazioni del dispositivo 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à di comportamento delle API

Implementazioni dei dispositivi:

  • [C-0-9] DEVE garantire che la compatibilità comportamentale delle 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à comportamentale delle API solo per le app selezionate dagli implementatori dei dispositivi.

I comportamenti di ogni tipo di API (gestita, soft, nativa e web) DEVONO essere coerenti con l'implementazione preferita del progetto open source Android upstream. Ecco alcune aree specifiche di compatibilità:

  • [C-0-1] I dispositivi NON DEVONO modificare il comportamento o la semantica di un intent standard.
  • [C-0-2] I dispositivi NON DEVONO alterare la semantica del ciclo di vita o del ciclo di vita di un particolare tipo di componente di sistema (come Service, Activity, ContentProvider ecc.).
  • [C-0-3] I dispositivi NON DEVONO modificare la semantica di un'autorizzazione standard.
  • I dispositivi NON DEVONO alterare le limitazioni applicate alle applicazioni in background. Nello specifico, per le app in background:
    • [C-0-4] DEVONO interrompere l'esecuzione dei callback registrati dall'app per ricevere 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 superiore, NON DEVONO consentire la registrazione di broadcast receiver per le trasmissioni implicite di intent Android standard nel file manifest dell'app, a meno che l'intent di trasmissione non richieda un'autorizzazione "signature" o "signatureOrSystem" protectionLevel o non sia incluso nell'elenco di esenzione.
    • [C-0-7] Se l'app ha come target il livello API 25 o superiore, DEVONO 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 venga 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, DEVONO rilasciare i wakelock dell'app.
  • [C-0-9] I dispositivi DEVONO restituire i seguenti fornitori di sicurezza come primi sette valori di array del metodo Security.getProviders(), nell'ordine specificato e con i nomi (restituiti da Provider.getName()) e le classi, a meno che l'app non abbia modificato l'elenco tramite insertProviderAt() o removeProvider(). I dispositivi POSSONO restituire fornitori aggiuntivi dopo l'elenco di provider specificato di seguito.
    1. AndroidNSSP: android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider - sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCSolution - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSE: com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

L'elenco riportato sopra non è esaustivo. La Compatibility Test Suite (CTS) testa parti significative della piattaforma per verificarne la compatibilità comportamentale, ma non tutte. È responsabilità dell'implementatore di garantire la compatibilità comportamentale con Android Open Source Project. Per questo motivo, gli implementatori dei dispositivi DEVONO utilizzare il codice sorgente disponibile tramite il progetto open source Android, ove possibile, anziché reimplementare parti significative del sistema.

3.5.1. Limitazione in background

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

  • [C-1-1] DEVE fornire l'invito all'utente in cui l'utente può vedere l'elenco delle app limitate.
  • [C-1-2] DEVE fornire all'utente la possibilità di attivare / disattivare le limitazioni su ogni app.
  • [C-1-3] DEVE non applicare automaticamente le limitazioni senza prove di comportamenti inadeguati dell'integrità del sistema, ma POTREBBE applicare le limitazioni alle app al rilevamento di comportamenti non adeguati dello stato del sistema, come wakelock bloccati, servizi a lunga esecuzione e altri criteri. I criteri POSSONO essere determinati dagli utenti che implementano i dispositivi, 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 nel mercato, NON DEVONO essere utilizzati come criteri.
  • [C-1-4] DEVE non applicare automaticamente le limitazioni per le app quando un utente ha disattivato manualmente le limitazioni per le app e POTREBBE suggerire all'utente di applicarle.
  • [C-1-5] DEVE informare gli utenti se a un'app vengono applicate automaticamente limitazioni relative alle app.
  • [C-1-6] DEVE restituire true per ActivityManager.isBackgroundRestricted() quando l'app con limitazioni chiama questa API.
  • [C-1-7] NON DEVE limitare l'app principale in primo piano utilizzata esplicitamente dall'utente.
  • [C-1-8] DEVE sospendere le limitazioni per un'app che diventa la prima applicazione in primo piano quando l'utente inizia esplicitamente a utilizzare l'app che era soggetta a limitazioni.

3.6. Spazi dei nomi API

Android segue le convenzioni dello spazio dei nomi dei pacchetti e delle classi definite dal linguaggio di programmazione Java. Per garantire la compatibilità con applicazioni di terze parti, gli utenti che implementano i dispositivi NON DEVONO apportare modifiche vietate (vedi di seguito) agli spazi dei nomi dei pacchetti:

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

Vale a dire:

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

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

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

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

  • [C-0-5] NON DEVE trovarsi in uno spazio dei nomi di proprietà di o fare riferimento a un'altra organizzazione. Ad esempio, gli implementatori dei dispositivi NON DEVONO aggiungere API al com.google.* o a uno spazio dei nomi simile: solo Google può farlo. Analogamente, Google NON DEVE aggiungere API agli spazi dei nomi di altre aziende.
  • [C-0-6] DEVONO essere pacchettizzati in una libreria condivisa di Android, in modo che soltanto le app che le usano esplicitamente (tramite il meccanismo <uses-library>) siano interessate dall'aumento della memoria utilizzata da queste API.

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

Si noti che le restrizioni di cui sopra corrispondono alle convenzioni standard per la denominazione delle API nel linguaggio di programmazione Java; questa sezione mira semplicemente a rafforzare tali convenzioni e renderle vincolanti attraverso l'inclusione in questa definizione di compatibilità.

3.7. Compatibilità di runtime

Implementazioni dei dispositivi:

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

  • [C-0-2] DEVE configurare i runtime Dalvik per allocare la memoria in base alla 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.)

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

  • DEVONO eseguire fuzz test in varie modalità di esecuzione e con architetture di destinazione per garantire la stabilità del runtime. Fai riferimento a JFuzz e DexFuzz sul sito web del progetto open source Android.

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

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

3.8. Compatibilità con l'interfaccia utente

3.8.1. Avvio app (schermata Home)

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

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

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

Se le implementazioni del dispositivo includono un'Avvio app predefinito che supporta il blocco delle scorciatoie in-app, queste:

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

Se le implementazioni del dispositivo implementano un'Avvio app predefinito che consente di accedere rapidamente alle scorciatoie aggiuntive fornite da app di terze parti tramite l'API ShortcutManager, queste:

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

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

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

3.8.2. Widget

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

Se le implementazioni del dispositivo supportano i widget di app di terze parti, questi:

  • [C-1-1] DEVE dichiarare il supporto per la funzionalità della piattaforma android.software.app_widgets.
  • [C-1-2] DEVE includere il supporto integrato per AppWidgets ed esporre le autorizzazioni dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere AppWidget direttamente all'interno di Avvio app.
  • [C-1-3] DEVE essere in grado di visualizzare widget 4 x 4 nelle dimensioni della griglia standard. Per maggiori dettagli, consulta App Widget DesignGuidelines nella documentazione dell'SDK per Android.
  • POSSONO supportare widget delle applicazioni nella schermata di blocco.

Se le implementazioni del dispositivo supportano i widget di app di terze parti e il blocco in-app delle scorciatoie, questi:

3.8.3. Notifiche

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

3.8.3.1. Presentazione delle notifiche

Se le implementazioni dei dispositivi consentono ad app di terze parti di informare gli utenti di eventi importanti, queste:

  • [C-1-1] DEVE supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK e nella misura possibile con l'hardware di implementazione del dispositivo. Ad esempio, se l'implementazione di un dispositivo include una vibrazione, DEVE implementare correttamente le API di vibrazione. Se l'implementazione in un dispositivo è priva di hardware, le API corrispondenti DEVONO essere implementate in modalità autonoma. Questo comportamento è descritto più dettagliatamente nella sezione 7.
  • [C-1-2] DEVE eseguire il rendering corretto di tutte le risorse (icone, file di animazione e così via) fornite nelle API o nella guida di stile per le icone della barra di stato/di sistema, anche se POTREBBERO fornire un'esperienza utente alternativa per le notifiche rispetto a quella fornita nell'implementazione open source di Android di riferimento.
  • [C-1-3] DEVE rispettare e implementare correttamente i comportamenti descritti per consentire alle API di 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 l'invito all'utente per bloccare e modificare la notifica di una determinata app di terze parti per ogni canale e livello di pacchetto dell'app.
  • [C-1-6] DEVE anche fornire un invito all'utente per visualizzare i canali di notifica eliminati.
  • [C-1-7] DEVE visualizzare correttamente tutte le risorse (immagini, adesivi, icone e così via) fornite tramite Notification.MessagingStyle insieme al testo della notifica, senza ulteriori interazioni dell'utente. Ad esempio, DEVE mostrare tutte le risorse, comprese le icone fornite tramite android.app.Person in una conversazione di gruppo impostata mediante setGroupConversation.
  • [C-SR] È VIVAMENTE CONSIGLIATO di mostrare automaticamente un invito dell'utente per bloccare la notifica di una determinata app di terze parti per ogni canale e livello di pacchetto dell'app dopo che l'utente la chiude più volte.
  • DEVONO supportare notifiche avanzate.
  • DEVONO presentare alcune notifiche con priorità più alta come notifiche di avviso.
  • DEVONO avere l'autorizzazione dell'utente a posticipare le notifiche.
  • POTREBBERO gestire soltanto la visibilità e le tempistiche in cui le app di terze parti possono informare gli utenti di eventi importanti per mitigare i problemi di sicurezza, ad esempio la distrazione della guida.

Se le implementazioni dei dispositivi supportano le notifiche avanzate:

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

Se le implementazioni del dispositivo supportano le notifiche in evidenza:

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

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

Se le implementazioni dei dispositivi segnalano il flag di funzionalità android.hardware.ram.normal:

  • [C-1-1] DEVE aggiornare correttamente e tempestivamente le notifiche nella loro interezza a tutti i servizi listener installati e abilitati all'utente, inclusi tutti i metadati allegati all'oggetto Notification.
  • [C-1-2] DEVE rispettare la chiamata API snoozeNotification(), ignorare la notifica ed effettuare un callback dopo la durata della posticipazione impostata nella chiamata API.

Se le implementazioni del dispositivo hanno l'autorizzazione a posticipare le notifiche, l'utente:

  • [C-2-1] DEVE riflettere correttamente lo stato della notifica posticipata tramite le API standard come NotificationListenerService.getSnoozedNotifications().
  • [C-2-2] DEVE rendere disponibile l'invito dell'utente per posticipare le notifiche da 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à DND:

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

Android include API che consentono agli sviluppatori di incorporare la ricerca nelle loro applicazioni e di esporre i dati delle loro applicazioni nella ricerca globale di sistema. 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 gli utenti digitano testo e risultati. Le API Android consentono agli sviluppatori di riutilizzare questa interfaccia per fornire ricerche all'interno delle loro app e di fornire risultati all'interfaccia utente di ricerca globale comune.

  • Le implementazioni dei dispositivi Android DEVONO includere la ricerca globale, una singola interfaccia utente di ricerca 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, questi:

  • [C-1-1] DEVE implementare le API che consentano 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 DEVE essere quello di visualizzare i risultati e i suggerimenti del motore di ricerca web.

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

Se le implementazioni del dispositivo supportano l'azione evento indiretto, questi:

  • [C-2-1] DEVE indicare chiaramente all'utente finale quando il contesto viene condiviso tramite:
    • Ogni volta che l'app di assistenza accede al contesto, mostra una luce bianca attorno ai bordi dello schermo che raggiunge o supera la durata e la luminosità dell'implementazione di Android Open Source Project.
    • Per l'app di assistenza preinstallata, la fornitura di un'invito all'utente a meno di due navigazioni dal menu delle impostazioni predefinito dell'input vocale e dell'app dell'assistente e la condivisione del contesto soltanto quando l'app di assistenza viene richiamata esplicitamente dall'utente tramite l'inserimento di una hotword o di un tasto di navigazione di assistenza.
  • [C-2-2] L'interazione designata per avviare l'app di assistenza come descritto nella sezione 7.2.3 DEVE lanciare l'app di assistenza selezionata dall'utente, in altre parole l'app che implementa VoiceInteractionService, oppure un'attività che gestisce l'intent ACTION_ASSIST.

3.8.5. Avvisi e toast

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

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

  • [C-1-1] DEVE fornire all'utente l'invito per impedire a un'app di visualizzare finestre di avviso che utilizzano TYPE_APPLICATION_OVERLAY . L'implementazione di AOSP soddisfa questo requisito grazie ai controlli nell'area notifiche.

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

3.8.6. Temi

Android offre i "temi" come meccanismo per applicare stili a un'intera attività o applicazione.

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

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

Android include anche una famiglia di temi "Predefinito in base al dispositivo", ovvero un 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 delle varianti con barre di sistema traslucide, che consentono agli sviluppatori di applicazioni di riempire con i contenuti delle app l'area dietro la barra di stato e di navigazione. Per offrire agli sviluppatori un'esperienza coerente in questa configurazione, è importante che lo stile dell'icona della barra di stato venga mantenuto in diverse implementazioni dei dispositivi.

Se le implementazioni dei dispositivi includono una barra di stato del sistema, questi:

  • [C-2-1] DEVE essere utilizzato il bianco per le icone di stato del sistema (come 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 non richieda una barra di stato luminosa utilizzando il flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
  • [C-2-2] Le implementazioni sui dispositivi Android DEVONO cambiare il colore delle icone di stato del sistema in nero (per maggiori dettagli, fai riferimento a R.style) quando un'app richiede una barra di stato luminosa.

3.8.7. Sfondi animati

Android definisce un tipo di componente, nonché l'API e il ciclo di vita corrispondenti, che consente alle applicazioni di esporre uno o più "sfondi animati" all'utente finale. Gli sfondi animati sono animazioni, motivi o immagini simili con capacità di input limitate che vengono visualizzate come sfondo dietro altre applicazioni.

L'hardware è considerato in grado di eseguire in modo affidabile sfondi animati se è in grado di eseguire tutti gli sfondi animati, senza limitazioni di funzionalità, a una frequenza fotogrammi ragionevole senza effetti negativi su altre applicazioni. Se limitazioni dell'hardware causano l'arresto anomalo degli sfondi e/o delle applicazioni, il malfunzionamento, un consumo eccessivo di CPU o batteria o l'esecuzione a frequenze fotogrammi eccessivamente basse, l'hardware viene considerato incapace di eseguire lo sfondo animato. Ad esempio, alcuni sfondi animati potrebbero utilizzare un contesto OpenGL 2.0 o 3.x per eseguire il rendering dei contenuti. L'esecuzione dello sfondo animato non viene eseguita in modo affidabile su hardware che non supportano diversi contesti OpenGL, perché l'utilizzo di sfondi animati di un contesto OpenGL potrebbe essere in conflitto con altre applicazioni che usano anch'essi un contesto OpenGL.

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

Se le implementazioni dei dispositivi implementano gli sfondi animati, questi:

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

3.8.8. Cambio attività

Il codice sorgente Android upstream include la schermata Panoramica, un'interfaccia utente a livello di sistema per il cambio delle attività 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 nel momento in cui l'utente ha abbandonato l'applicazione per l'ultima volta.

Le implementazioni dei dispositivi, incluso il tasto di navigazione recente della funzione, come descritto nella sezione 7.2.3 POTREBBERO modificare l'interfaccia.

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

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

3.8.9. Gestione degli input

Android include il supporto per Gestione del metodo di immissione e per editor dei metodi di immissione di terze parti.

Se le implementazioni del dispositivo consentono agli utenti di utilizzare metodi di immissione di terze parti, 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.
  • [C-1-2] DEVE fornire un meccanismo accessibile all'utente per aggiungere e configurare metodi di immissione di terze parti in risposta all'intento android.settings.INPUT_METHOD_SETTINGS.

Se le implementazioni dei dispositivi dichiarano il flag funzionalità android.software.autofill:

3.8.10. Controllo contenuti multimediali schermata di blocco

L'API Remote Control Client è stata ritirata da Android 5.0 a favore del Media Notification Template, che consente l'integrazione delle applicazioni multimediali con i controlli di riproduzione visualizzati nella schermata di blocco.

3.8.11. Salvaschermi (in precedenza Sogni)

Android include il supporto dei salvaschermi interattivi, precedentemente chiamati Sogni. I salvaschermo consentono agli utenti di interagire con le applicazioni quando un dispositivo collegato a una fonte di alimentazione è inattivo o agganciato a una base di ricarica. I dispositivi Android Watch POTREBBERO implementare salvaschermo, ma altri tipi di implementazioni dispositivo DEVONO includere il supporto per questi salvaschermi e fornire un'opzione di impostazioni che consenta agli utenti di configurarli in risposta all'intento di android.settings.DREAM_SETTINGS.

3.8.12. Posizione

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

3.8.13. Unicode e Font

Android supporta i caratteri emoji definiti in Unicode 10.0.

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

  • [C-1-1] DEVE essere in grado di visualizzare questi caratteri emoji in glifo a colori.
  • [C-1-2] DEVE includere il supporto di:
    • Carattere Roboto 2 di spessore diverso: Sans Serif-thin, Sans Serif-leggero, Sans Serif-medium, Sans Serif-Black, Sans Serif Condensed, Sans Serif Condensato Luce Condensata per le lingue disponibili sul dispositivo.
    • Copertura completa di Unicode 7.0 in caratteri latini, greci e cirillici, inclusi gli intervalli Latin Extended A, B, C e D e tutti i glifi nel blocco di simboli di valuta di Unicode 7.0.
  • DEVONO supportare la tonalità della pelle e le diverse emoji per la famiglia, come specificato nell'Unicode Technical Report n. 51.

Se le implementazioni dei dispositivi includono un IME, questi:

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

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

Se le implementazioni dei dispositivi includono il supporto per il 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. Multifinestre

Se le implementazioni dei dispositivi hanno la possibilità di visualizzare più attività contemporaneamente:

  • [C-1-1] DEVE implementare queste modalità multi-finestra in base ai comportamenti dell'applicazione e alle API descritti nella documentazione di supporto per la modalità multi-finestra dell'SDK per 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 formato libero se l'altezza dello schermo è inferiore a 440 dp e la larghezza dello schermo è inferiore a 440 dp.
  • [C-1-4] Un'attività NON DEVE essere ridimensionata a una dimensione inferiore a 220 dp in modalità multi-finestra diverse da Picture in picture.
  • Le implementazioni dei dispositivi con dimensioni dello schermo xlarge DEVONO supportare la modalità in formato libero.

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

  • [C-2-1] DEVE precaricare per impostazione predefinita un'Avvio app ridimensionabile.
  • [C-2-2] DEVE ritagliare l'attività agganciata di una multi-finestra a schermo diviso, ma DOVREBBE mostrarne alcuni contenuti, se l'app Avvio app è la finestra con lo stato attivo.
  • [C-2-3] DEVE rispettare i valori AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight dichiarati dell'applicazione Avvio app di terze parti e non sostituire questi valori durante la visualizzazione di alcuni contenuti dell'attività agganciata.

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

  • [C-3-1] DEVE avviare attività in modalità multi-finestra Picture in picture quando l'app è: * Livello API target 26 o superiore e dichiara android:supportsPictureInPicture * Livello API target 25 o inferiore e dichiara android:resizeableActivity e 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 un'invito all'utente per impedire la visualizzazione di un'app in modalità PIP; l'implementazione AOSP soddisfa questo requisito con controlli nell'area notifiche.
  • [C-3-6] DEVE allocare larghezza e altezza minime di 108 dp per la finestra PIP e una larghezza minima di 240 dp e un'altezza di 135 dp per la finestra PIP quando Configuration.uiMode è configurato come UI_MODE_TYPE_TELEVISION.

3.8.15. Ritaglio display

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

Se le implementazioni dei dispositivi includono ritagli del display:

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

3,9 Amministrazione dispositivo

Android include funzionalità che consentono alle applicazioni sensibili alla sicurezza di eseguire funzioni di amministrazione dei dispositivi a livello di sistema, ad esempio l'applicazione di criteri relativi alle password o l'eliminazione da remoto, tramite l'API Android Device Administration.

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

  • [C-1-1] DEVE dichiarare android.software.device_admin.
  • [C-1-2] DEVE supportare il provisioning dei proprietari dei dispositivi come descritto nella sezione 3.9.1 e nella sezione 3.9.1.1.

3.9.1 Provisioning dei dispositivi

3.9.1.1 Provisioning dei proprietari del dispositivo

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

  • [C-1-1] DEVE supportare la registrazione di un client Criteri dispositivo (DPC) come app del proprietario del dispositivo come descritto di seguito:
  • [C-1-2] DEVE richiedere un intervento da parte tua durante il processo di provisioning per dare il consenso all'impostazione dell'app come proprietario del dispositivo. Il consenso può avvenire tramite azione dell'utente o con qualche mezzo programmatico durante il provisioning, ma NON DEVE essere hardcoded o impedire l'utilizzo di altre app del proprietario 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 dispositivo" standard come riconosciuto dalle API DevicePolicyManager standard di Android, questi:

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

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

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

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

  • [C-1-3] DEVE fornire i seguenti inviti all'utente all'interno delle Impostazioni per indicare all'utente quando una determinata funzione di sistema è stata disattivata dal controller dei criteri dei dispositivi (DPC):

    • Un'icona coerente o un altro invito all'utente (ad esempio l'icona delle informazioni AOSP upstream) da rappresentare quando una determinata impostazione è limitata da un amministratore del dispositivo.
    • Un breve messaggio esplicativo fornito dall'amministratore del dispositivo tramite setShortSupportMessage.
    • L'icona dell'applicazione DPC (controller criteri dispositivi).

3.9.2 Supporto dei profili gestiti

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

  • [C-1-1] DEVE supportare i profili gestiti tramite le API di android.app.admin.DevicePolicyManager.
  • [C-1-2] DEVE consentire la creazione di un solo profilo gestito.
  • [C-1-3] DEVE utilizzare un badge a forma di icona (simile al badge di lavoro upstream di AOSP) per rappresentare le applicazioni e i widget gestiti e altri elementi UI con badge come Recenti e Notifiche.
  • [C-1-4] DEVE mostrare un'icona di notifica (simile al badge di lavoro upstream di AOSP) per indicare quando l'utente si trova all'interno di un'applicazione con profilo gestito.
  • [C-1-5] DEVE mostrare un avviso popup che indica che l'utente è nel profilo gestito se e quando il dispositivo si attiva (ACTION_USER_PRESENT) e l'applicazione in primo piano si trova all'interno del profilo gestito.
  • [C-1-6] Se esiste un profilo gestito, DEVE mostrare un'invito visivo 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 dei dispositivi.
  • [C-1-7] Se esiste un profilo gestito, DEVE esporre le seguenti autorizzazioni utente sia per l'utente principale sia per il profilo gestito:
    • Account separati per l'utilizzo di batteria, posizione, dati mobili e spazio di archiviazione per l'utente principale e il profilo gestito.
    • Gestione indipendente delle applicazioni VPN installate all'interno dell'utente principale o del profilo gestito.
    • Gestione indipendente delle applicazioni installate nel profilo gestito o utente principale.
    • Gestione indipendente degli account all'interno dell'utente principale o del profilo gestito.
  • [C-1-8] DEVE garantire che la tastiera, i contatti e le applicazioni di messaggistica preinstallate possano cercare e cercare le informazioni sul chiamante dal profilo gestito (se esistente) insieme a quelli del profilo principale, se il controller dei criteri dei dispositivi lo consente.
  • [C-1-9] DEVE garantire che soddisfi tutti i requisiti di sicurezza applicabili a un dispositivo su cui sono attivi più utenti (consulta la sezione 9.5), anche se il profilo gestito non viene conteggiato come un altro utente oltre all'utente principale.
  • [C-1-10] DEVE supportare la possibilità di specificare una schermata di blocco separata che soddisfi i seguenti requisiti per concedere l'accesso alle app eseguite in un profilo gestito.
    • Le implementazioni dei dispositivi DEVONO rispettare l'intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrare un'interfaccia per configurare una credenziale separata nella schermata di blocco per il profilo gestito.
    • Le credenziali della schermata di blocco del profilo gestito DEVONO usare gli stessi meccanismi di archiviazione e gestione delle credenziali del profilo principale, come documentato sul sito del progetto open source Android.
    • I criteri relativi alle password del DPC DEVONO essere applicati solo alle credenziali della schermata di blocco del profilo gestito, a meno che non vengano richiamati l'istanza DevicePolicyManager restituita da getParentProfileInstance.
  • Quando i contatti del profilo gestito sono visualizzati nel registro chiamate preinstallato, nell'interfaccia utente in corso, nelle notifiche di chiamata in corso e persa, nei contatti e nelle app di messaggistica, DEVONO essere contrassegnati con lo stesso badge utilizzato per indicare le applicazioni del profilo gestito.

3.9.3 Supporto degli utenti gestiti

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

  • [C-1-1] DEVE fornire a un utente l'invito per uscire dall'utente corrente e tornare all'utente principale nella sessione con più utenti quando isLogoutEnabled restituisce true. L'invito dell'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 sui dispositivi. Inoltre, Android fornisce API delle piattaforme che consentono alle implementazioni dei servizi di accessibilità di ricevere callback per gli eventi dell'utente e del sistema e generano meccanismi di feedback alternativi, come sintesi vocale, feedback aptico e navigazione trackball/D-pad.

Se le implementazioni del dispositivo supportano i servizi di accessibilità di terze parti, questi:

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

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

  • [C-2-1] È NECESSARIO implementare questi servizi di accessibilità preinstallati come app Direct Boot Aware se lo spazio di archiviazione dei dati è criptato con la crittografia basata su file (FBE).
  • DOVREBBE fornire un meccanismo nel flusso di configurazione pronto all'uso per consentire agli utenti di abilitare i relativi servizi di accessibilità, nonché opzioni per regolare le dimensioni del carattere, le dimensioni di visualizzazione e i gesti di ingrandimento.

3.11. Sintesi vocale

Android include API che consentono alle applicazioni di usare servizi di sintesi vocale e ai fornitori di servizi di fornire implementazioni di questi servizi.

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

Se le implementazioni del dispositivo supportano l'installazione di motori di sintesi vocale di terze parti, questi:

  • [C-2-1] DEVE fornire l'invito all'utente per permettergli di selezionare un motore di sintesi vocale da utilizzare a livello di sistema.

3.12. Framework input TV

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

Se le implementazioni dei dispositivi supportano la funzionalità TIF:

  • [C-1-1] DEVE dichiarare la funzionalità della piattaforma android.software.live_tv.
  • [C-1-2] DEVE supportare tutte le API TIF in modo che un'applicazione che le utilizzi 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 UI Impostazioni rapide che consente di accedere rapidamente alle azioni utilizzate di frequente o urgenti.

Se le implementazioni dei dispositivi includono un componente UI Impostazioni rapide:

  • [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 dagli utenti da app di terze parti insieme ai riquadri delle impostazioni rapide forniti dal sistema.

3.14. UI multimediale

Se le implementazioni del dispositivo includono applicazioni non ad attivazione vocale (le App) che interagiscono con applicazioni di terze parti tramite MediaBrowser o MediaSession, le App:

  • [C-1-2] DEVE visualizzare chiaramente le icone ottenute tramite getIconBitmap() o getIconUri() e i titoli ottenuti tramite getTitle() come descritto in MediaDescription. I titoli potrebbero essere abbreviati per rispettare le normative di sicurezza (ad es. distrazioni alla guida).

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

  • [C-1-4] DEVE consentire all'utente di interagire con l'intera gerarchia di MediaBrowser. POSSONO limitare l'accesso a parte della gerarchia per rispettare le normative di sicurezza (ad esempio, distrazioni al conducente), ma NON DEVONO offrire un trattamento preferenziale in base ai contenuti o al fornitore di contenuti.

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

3.15. App istantanee

Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti:

  • [C-0-1] Alle app istantanee DEVONO essere concesse soltanto le autorizzazioni con l'elemento android:protectionLevel impostato su "instant".
  • [C-0-2] Le app istantanee NON DEVONO interagire con le app installate tramite intent impliciti, a meno che una delle seguenti condizioni non sia vera:
    • Il filtro del pattern per intent del componente è esposto e ha CATEGORY_BROWSABLE
    • L'azione è una tra ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • Il target è esposto esplicitamente con android:visibleTo InstantApps
  • [C-0-3] Le app istantanee NON DEVONO interagire esplicitamente con le app installate, a meno che il componente non venga esposto tramite android:visibleTo InstantApps.
  • [C-0-4] Le app installate NON DEVONO visualizzare i dettagli sulle app istantanee installate sul dispositivo, a meno che l'app istantanea non si connetta esplicitamente all'applicazione installata.
  • Le implementazioni del dispositivo DEVONO fornire le seguenti autorizzazioni utente per l'interazione con le app istantanee. Il software AOSP soddisfa i requisiti delle UI di sistema, delle impostazioni e di Avvio app predefiniti. Implementazioni dei dispositivi:
    • [C-0-5] DEVE fornire a un utente l'invito per visualizzare ed eliminare le app istantanee localmente memorizzate nella cache per ogni singolo pacchetto di app.
    • [C-0-6] DEVE fornire una notifica all'utente persistente che possa essere compressa mentre un'app istantanea è in esecuzione in primo piano. Questa notifica all'utente DEVE includere che le app istantanee non richiedono l'installazione e devono fornire un invito che indirizzi l'utente alla schermata con le informazioni sull'applicazione nelle Impostazioni. Per le app istantanee lanciate tramite intent web, come definito utilizzando un intent con azione impostata su Intent.ACTION_VIEW e con uno schema "http" o "https", un'accettazione utente aggiuntiva DEVE consentire all'utente di non avviare l'app istantanea e lanciare il link associato con il browser web configurato, se sul dispositivo è disponibile un browser.
    • [C-0-7] DEVE consentire l'accesso alle app istantanee in esecuzione dalla funzione Recenti se quest'ultima è disponibile sul dispositivo.

3.16. Associazione dispositivo companion

Android supporta l'accoppiamento di dispositivi associati per gestire più efficacemente l'associazione con questi dispositivi 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 associato, questi:

  • [C-1-1] DEVE dichiarare il flag della funzionalità FEATURE_COMPANION_DEVICE_SETUP .
  • [C-1-2] DEVE garantire che le API nel pacchetto android.companion siano completamente implementate.
  • [C-1-3] DEVE fornire agli utenti gli inviti per selezionare/confermare che un dispositivo associato è presente e operativo.

3.17. App pesanti

Se le implementazioni dei dispositivi dichiarano la funzionalità FEATURE_CANT_SAVE_STATE:

  • [C-1-1] DEVE avere installato una sola app alla volta in cui è in esecuzione cantSaveState nel sistema. Se l'utente esce dall'app senza chiuderla esplicitamente (ad esempio premendo Home mentre il sistema lascia un'attività attiva, invece di premere Indietro senza alcuna attività attiva rimanente nel sistema), le implementazioni del dispositivo DEVONO dare la priorità all'app nella RAM come avviene per altri elementi che dovrebbero rimanere in esecuzione, ad esempio i servizi in primo piano. Mentre un'app di questo tipo è in background, il sistema può comunque applicarvi funzionalità di gestione dell'alimentazione, ad esempio la limitazione della CPU e dell'accesso alla rete.
  • [C-1-2] DEVE fornire un'invito all'interfaccia utente per scegliere l'app che non parteciperà al normale meccanismo di salvataggio/ripristino dello stato dopo che l'utente avvia una seconda app dichiarata con l'attributo cantSaveState.
  • [C-1-3] NON DEVE applicare altre modifiche ai criteri alle app che specificano cantSaveState, ad esempio la modifica delle prestazioni della CPU o la modifica della priorità di pianificazione.

Se le implementazioni dei dispositivi non dichiarano la funzionalità FEATURE_CANT_SAVE_STATE:

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

4. Compatibilità con la confezione dell'applicazione

Implementazioni dei dispositivi:

  • [C-0-1] DEVE essere in grado di installare ed eseguire file ".apk" di Android come generati dallo strumento "aapt" incluso nell'SDK Android ufficiale.
  • Dato che il requisito di cui sopra può essere impegnativo, per le implementazioni dei dispositivi si consiglia di usare 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 bytecode .apk, Android Manifest, Dalvik bytecode o RenderScript in modo da impedire la corretta installazione e l'esecuzione di questi file su altri dispositivi compatibili.

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

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

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

    • DEVE dichiarare l'autorizzazione REQUEST_INSTALL_PACKAGES o avere android:targetSdkVersion impostato su un valore pari o inferiore a 24.
    • L'utente DEVE avere ricevuto l'autorizzazione per installare app da fonti sconosciute.

  • DOVREBBE fornire un'autorizzazione all'utente per concedere/revocare l'autorizzazione a installare app da fonti sconosciute per applicazione, ma POTREBBE scegliere di implementare questa autorizzazione in modo autonomo e restituire RESULT_CANCELED per startActivityForResult(), se l'implementazione del dispositivo non vuole consentire agli utenti di avere questa scelta. Tuttavia, anche in questi casi DEVONO indicare all'utente il motivo per cui non viene presentata questa scelta.

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

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

5. Compatibilità multimediale

Implementazioni dei dispositivi:

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

Implementazioni dei dispositivi:

  • DOVREBBERO puntare alla latenza minima del codec, in altre parole,
    • NON DEVE utilizzare e archiviare i buffer di input e restituirli solo una volta elaborati.
    • NON DEVE conservare i buffer decodificati per un tempo superiore a quello specificato dallo standard (ad es. SPS).
    • NON DEVE conservare i buffer codificati per un tempo superiore a quello richiesto dalla struttura GOP.

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

Tieni presente che né Google né l'Open Handset Alliance rilasciano alcuna dichiarazione secondo cui questi codec sono esenti da brevetti di terze parti. Coloro che intendono utilizzare questo codice sorgente in prodotti hardware o software sono informati che le implementazioni di questo codice, anche in software open source o shareware, potrebbero richiedere licenze di brevetto da parte dei rispettivi titolari dei brevetti.

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 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 per la funzionalità android.hardware.audio.output, DEVONO supportare la decodifica dei seguenti formati audio:

  • [C-1-1] Profilo AAC MPEG-4 (AAC LC)
  • [C-1-2] Profilo MPEG-4 HE AAC (AAC+)
  • [C-1-3] Profilo MPEG-4 HE AACv2 (AAC+ migliorato)
  • [C-1-4] AAC ELD (Basso ritardo AAC migliorato)
  • [C-1-11] xHE-AAC (Profilo HE AAC esteso ISO/IEC 23003-3, che include il profilo base USAC e il profilo di controllo dell’intervallo dinamico 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 con formati audio ad alta risoluzione fino a 24 bit, frequenza di campionamento a 192 kHz e 8 canali. Tieni presente che questo requisito riguarda unicamente la decodifica e che un dispositivo può eseguire il downcampionamento e il downmix durante la fase di riproduzione.
  • [C-1-10] Opus

Se le implementazioni del dispositivo supportano la decodifica dei buffer di ingresso AAC degli stream multicanale (ossia più di due canali) in PCM tramite il decodificatore audio AAC predefinito nell'API android.media.MediaCodec, quanto segue DEVE essere supportato:

  • [C-2-1] La decodifica DEVE essere eseguita senza downmixing (ad esempio, un flusso 5.0 AAC DEVE essere decodificato su cinque canali del PCM, uno stream 5.1 AAC DEVE essere decodificato in sei canali di PCM).
  • [C-2-2] I metadati dell'intervallo dinamico DEVONO essere quelli definiti in "Controllo intervallo dinamico (DRC)" della normativa ISO/IEC 14496-3 e i tasti DRC android.media.MediaFormat per configurare i comportamenti relativi all'intervallo dinamico del decodificatore audio. Le chiavi AAC DRC sono state introdotte nell'API 21 e sono: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_ENCODED_TARGET_LEVEL.
  • [SR] È VIVAMENTE CONSIGLIATO che i requisiti C-2-1 e C-2-2 di cui sopra siano soddisfatti da tutti i decoder audio AAC.

Quando si decodifica l’audio USAC, MPEG-D (ISO/IEC 23003-4):

  • [C-3-1] Il volume e i metadati DRC DEVONO essere interpretati e applicati secondo il Livello 1 del Profilo di controllo dell’intervallo dinamico DRC MPEG-D.
  • [C-3-2] Il decoder DEVE comportarsi secondo la configurazione impostata con i seguenti tasti android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_DRC_EFFECT_TYPE.

Decoder del profilo MPEG-4 AAC, HE AAC e HE AACv2:

  • POTREBBE supportare il volume e il controllo della gamma dinamica utilizzando il profilo di controllo della gamma dinamica ISO/IEC 23003-4.

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

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

Tutti i decoder audio DEVONO supportare l'output:

5.1.3. Dettagli codec audio

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

5.1.4. Codifica delle immagini

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

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

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

Se le implementazioni del dispositivo 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 di BITRATE_MODE_CQ, il profilo HEVCProfileMainStill e le dimensioni del fotogramma di 512 x 512 px.

5.1.5. Decodifica dell'immagine

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

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

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

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

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

5.1.6. Dettagli codec immagine

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

Codificatori e decoder di immagini esposti tramite l'API MediaCodec

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

  • [SR] VIVAMENTE CONSIGLIATO per il supporto del formato di colore RGB888 per l'input della modalità Surface.

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

5.1.7. Codec video

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

Se le implementazioni dei dispositivi includono un decodificatore o un codificatore video:

  • [C-1-1] I codec video DEVONO supportare dimensioni bytebuffer di output e input che ospitano il frame compresso e non compresso più grande fattibile come dettato dallo standard e dalla configurazione ma non nel complesso.

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

  • [C-1-3] I codificatori e i decoder 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). È VIVAMENTE CONSIGLIATO di supportare entrambi.

  • [SR] I codificatori e i decoder video sono VIVAMENTE CONSIGLIATI di supportare almeno uno di un formato colore YUV420 8:8:8 ottimizzato per hardware planare o semiplanare (YV12, NV12, NV21 o un formato equivalente ottimizzato dal fornitore).

  • [C-1-5] I decoder video che supportano un formato a profondità di bit elevata (9 o più bit per canale) DEVONO supportare l'output di un formato equivalente a 8 bit se richiesto dall'applicazione. Questo DEVE essere indicato supportando un formato di colore 8:8:8 YUV420 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 intra-aggiornamento tramite FEATURE_IntraRefresh nella classe MediaCodecInfo.CodecCapabilities, questi:

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

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

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

5.1.8. Elenco codec video

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

5.1.9. Sicurezza del codec multimediale

Le implementazioni dei dispositivi DEVONO garantire la conformità alle funzioni di sicurezza del codec multimediale, come descritto di seguito.

Android include il supporto per OMX, un'API di accelerazione multimediale multipiattaforma, e Codec 2.0, un'API di accelerazione multimediale a basso overhead.

Se le implementazioni dei dispositivi supportano i contenuti multimediali, questi:

  • [C-1-1] DEVE fornire supporto per i codec multimediali tramite API OMX o Codec 2.0 (o entrambi) come nell'Android Open Source Project e non disabilitare o aggirare le protezioni di sicurezza. Ciò in particolare non significa che ogni codec DEVE utilizzare l'API OMX o Codec 2.0, solo che il supporto per almeno una di queste API DEVE essere disponibile, e il supporto per le API disponibili DEVE includere le protezioni di sicurezza presenti.
  • [C-SR] Ti consigliamo vivamente di includere il supporto per l'API Codec 2.0.

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

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

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

  • [C-3-1] DEVE includere il codec software corrispondente del Codec 2.0 dell'Android Open Source Project (se disponibile) per ogni formato e tipo multimediale (encoder o decoder) supportato dal dispositivo.
  • [C-3-2] DEVE ospitare i codec software Codec 2.0 nel processo del codec software come fornito nell'Android Open Source Project per consentire di concedere in modo più limitato l'accesso ai codec software.
  • [C-3-3] Codec i cui nomi iniziano con "c2.android". DEVE essere basato sul codice sorgente del progetto open source Android.

5.1.10. Caratterizzazione del codec multimediale

Se le implementazioni dei dispositivi supportano i codec multimediali, questi:

  • [C-1-1] DEVE restituire i valori corretti della caratterizzazione del codec multimediale tramite l'API di 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 la denominazione 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 di denominazione Codec 2.0 per Android.
  • [C-1-4] Codec con nomi che iniziano con "OMX.google." o "c2.android". NON DEVE essere definito come fornitore o con accelerazione hardware.
  • [C-1-5] I codec eseguiti in un processo codec (fornitore o sistema) che hanno accesso a driver hardware diversi dagli allocatori di memoria e ai mappatori NON DEVONO essere definiti solo software.
  • [C-1-6] Codec non presenti nel progetto open source Android o non basati sul codice sorgente in tale progetto DEVONO essere contrassegnati come fornitore.
  • [C-1-7] I codec che utilizzano l'accelerazione hardware DEVONO essere contrassegnati come con accelerazione hardware.
  • [C-1-8] I nomi dei codec NON DEVONO essere fuorvianti. Ad esempio, i codec denominati "decoder" DEVONO supportare la decodifica, mentre quelli denominati "encoder" DEVONO supportare la codifica. I codec con nomi contenenti formati multimediali DEVONO supportare tali formati.

Se le implementazioni dei dispositivi supportano i codec video:

  • [C-2-1] Tutti i codec video DEVONO pubblicare dati sulla frequenza fotogrammi realizzabili per le seguenti dimensioni, se supportati dal codec:
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p UHD
Risoluzione video
  • 176 x 144 px (H263, MPEG2, MPEG4)
  • 352 x 288 px (encoder MPEG4, H263, MPEG2)
  • 320 x 180 px (VP8, VP8)
  • 320 x 240 px (altro)
  • 704 x 576 px (H263)
  • 640 x 360 px (VP8, VP9)
  • 640 x 480 px (codificatore MPEG4)
  • 720 x 480 px (altro)
  • 1408 x 1152 px (H263)
  • 1280 x 720 px (altro)
1920 x 1080 px (diverse da MPEG4) 3840 x 2160 px (HEVC, VP9)
  • [C-2-2] I codec video caratterizzati come accelerazione hardware DEVONO pubblicare informazioni sui punti di rendimento. DEVONO elencare tutti i punti di rendimento standard supportati (elencati nell'API di 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 quelli standard elencati.

5.2. Codifica video

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

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

Se le implementazioni dei dispositivi includono un display incorporato con una diagonale di almeno 2,5 pollici o includono una porta di uscita video o dichiarano il supporto di una videocamera tramite il flag funzionalità android.hardware.camera.any, questi:

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

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

  • [C-2-1] DEVE supportare la velocità in bit configurabile dinamicamente.
  • DEVONO supportare frequenze fotogrammi variabili, laddove 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 quella durata di frame.

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

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

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

  • [C-4-1] tutti i codificatori di immagini e video con accelerazione hardware DEVONO supportare la codifica dei fotogrammi dalle videocamere hardware.
  • DEVONO supportare i fotogrammi di codifica dalle fotocamere 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 ad app di terze parti, questi:

  • [C-1-1] DEVE supportare il livello 45 del profilo di riferimento.
  • DEVONO supportare 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 livello 3 del profilo di riferimento. Tuttavia, il supporto per ASO (Ordine delle sezioni arbitrario), Ordine flessibile delle sezioni (FMO) e RS (sezioni ridondanti) è FACOLTATIVO. Inoltre, per mantenere la compatibilità con altri dispositivi Android, è CONSIGLIATO che ASO, FMO e RS non vengano utilizzati per il profilo di base dai codificatori.
  • [C-1-2] DEVE supportare i profili di codifica video SD (Standard Definition) riportati nella tabella seguente.
  • DEVE supportare il livello del profilo principale 4.
  • DEVONO 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, questi:

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

5.2.3. VP8

Se le implementazioni del dispositivo supportano il codec VP8:

  • [C-1-1] DEVE supportare i profili di codifica video SD.
  • DEVONO supportare i seguenti profili di codifica video HD (alta definizione).
  • [C-1-2] DEVE supportare la scrittura di file Matroska WebM.
  • DEVE fornire un codec hardware VP8 che soddisfi i requisiti di codifica hardware RTC del progetto WebM, al fine di garantire una qualità accettabile dello streaming video sul web e dei servizi 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, questi:

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

5.2.4. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

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

Se le implementazioni del dispositivo dichiarano di supportare il Profilo 2 o 3 tramite le API multimediali:

  • Il supporto per il formato a 12 bit è FACOLTATIVO.

5.2.5. H.265

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

  • [C-1-1] DEVE supportare il livello 3 del profilo principale.
  • DEVONO supportare i profili di codifica HD come indicato nella tabella seguente.
  • [SR] è VIVAMENTE CONSIGLIATO per supportare i profili di codifica HD, come indicato nella seguente tabella, 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 del dispositivo supportano i codec VP8, VP9, H.264 o H.265:

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

Se il dispositivo viene implementato con decoder MPEG-4, questi:

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

5.3.4. H.264

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

  • [C-1-1] DEVE supportare Main Profile Level 3.1 e Baseline Profile. Il supporto per 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 seguente tabella e codificati con il profilo di base e il livello del profilo principale 3.1 (inclusi 720p30).
  • DOVREBBE essere in grado di decodificare i video con i profili HD (alta definizione) come indicato nella tabella seguente.

Se l'altezza riportata dal metodo Display.getSupportedModes() è uguale o superiore alla risoluzione video, le implementazioni del dispositivo:

  • [C-2-1] DEVE supportare i profili di decodifica video HD 720p nella tabella seguente.
  • [C-2-2] DEVE supportare i profili di decodifica video HD 1080p nella tabella seguente.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p
Risoluzione video 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
Frequenza fotogrammi video 30 fps 30 fps 60 FPS 30 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 3 del profilo principale e i profili di decodifica video SD, come indicato nella tabella seguente.
  • DEVONO supportare i profili di decodifica HD come indicato nella tabella seguente.
  • [C-1-2] DEVE supportare i profili di decodifica HD come indicato nella seguente tabella se è presente un decodificatore hardware.

Se l'altezza riportata 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 di profili 720, 1080 e UHD.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p UHD
Risoluzione video 352 x 288 px 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
Frequenza fotogrammi video 30 fps 30 fps 30 fps 30/60 f/s (60 f/stelevisore con decodifica hardware H.265) 60 FPS
Velocità in bit video 600 kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

Se le implementazioni del dispositivo dichiarano di supportare un profilo HDR (HEVCProfileMain10HDR10, HEVCProfileMain10HDR10Plus) tramite le API multimediali:

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

  • [C-SR] Le implementazioni dei dispositivi sono VIVAMENTE CONSIGLIATE per il supporto dell'output dei metadati MediaFormat#KEY_HDR10_PLUS_INFO per i profili HDR10Plus tramite MediaCodec#getOutputFormat(int).

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

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

5.3.6. VP8

Se le implementazioni del dispositivo supportano il codec VP8:

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

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

  • [C-2-1] Le implementazioni dei dispositivi DEVONO supportare i profili 720p riportati nella tabella seguente.
  • [C-2-2] Le implementazioni dei dispositivi DEVONO supportare i profili 1080p nella tabella seguente.
SD (bassa qualità) SD (alta qualità) HD 720p HD 1080p
Risoluzione video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Frequenza fotogrammi video 30 fps 30 fps 30 f/s (60 f/stelevisore) 30 (60 f/stelevisore)
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.
  • DEVONO supportare i profili di decodifica HD come indicato nella tabella seguente.

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

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

Se l'altezza riportata 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 f/s (60 f/stelevisore con decodifica hardware VP9) 60 FPS
Velocità in bit video 600 kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

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

  • Il supporto per il 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 del dispositivo DEVONO accettare i metadati HDR richiesti (MediaFormat#KEY_HDR_STATIC_INFO per tutti i profili HDR, nonché il parametro MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO per i profili HDR10Plus) dall'applicazione utilizzando l'API MediaCodec, nonché supportare l'estrazione dei metadati HDR richiesti (MediaFormat#KEY_HDR_STATIC_INFO per tutti i profili HDR e MediaFormat#KEY_HDR10_PLUS_INFO per i profili HDR10Plus) dal flusso di bit e/o dal contenitore, come definito dalle specifiche pertinenti. DEVONO inoltre supportare l'output dei metadati HDR richiesti (MediaFormat#KEY_HDR_STATIC_INFO per tutti i profili HDR) dal flusso di bit e/o dal container, come definito dalle specifiche pertinenti.

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

  • [C-SR] Le implementazioni dei dispositivi sono VIVAMENTE CONSIGLIATE per supportare l'output dei metadati MediaFormat#KEY_HDR10_PLUS_INFO per i profili HDR10Plus tramite MediaCodec#getOutputFormat(int).

  • [C-SR] Le implementazioni dei dispositivi sono VIVAMENTE CONSIGLIATE per visualizzare correttamente i contenuti HDR per i profili VP9Profile2HDR10Plus e VP9Profile3HDR10Plus sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).

5.3.8. Dolby Vision

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

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

5.3.9. AV1

Se le implementazioni dei dispositivi supportano il codec AV1:

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

5.4. Registrazione audio

Mentre alcuni dei requisiti descritti in questa sezione sono elencati come DOVREBBE a partire da Android 4.3, si prevede che la definizione di compatibilità per le versioni future li modifichi in DEVE. I dispositivi Android nuovi ed esistenti sono VIVAMENTE CONSIGLIATI per soddisfare questi requisiti che sono elencati come DOVRESTI, altrimenti non saranno in grado di raggiungere la compatibilità con Android quando viene eseguito l'upgrade alla versione futura.

5.4.1. Acquisizione audio non elaborata e informazioni del microfono

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

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

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

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

    • Formato: PCM lineare, 16 bit e 24 bit
    • Frequenze di campionamento: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
    • Canali: un numero di canali uguale al numero di microfoni sul dispositivo.

  • [C-1-2] DEVE effettuare l'acquisizione a frequenze di campionamento superiori senza eseguire l'up-sampling.

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

  • DOVREBBE consentire l'acquisizione di qualità radio AM e DVD di contenuti audio non elaborati, il che significa le seguenti caratteristiche:

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

  • [C-1-4] DEVE rispettare l'API MicrophoneInfo e 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 qualità radio AM e DVD di contenuti audio non elaborati:

  • [C-2-1] DEVE acquisire senza eseguire l'up-sampling a qualsiasi rapporto superiore a 16000:22050 o 44100:48000.

  • [C-2-2] DEVE includere un filtro anti-aliasing appropriato per ogni up-sampling o down-sampling.

5.4.2. Acquisisci per il riconoscimento vocale

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

  • [C-1-1] DEVE acquisire android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION sorgente audio a una delle frequenze di campionamento, 44100 e 48000.
  • [C-1-2] DEVE, per impostazione predefinita, disattivare l'elaborazione audio per la riduzione del rumore durante la registrazione di uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
  • [C-1-3] DEVE, per impostazione predefinita, disattivare eventuali controlli automatici del guadagno durante la registrazione di uno stream audio dalla sorgente audio AudioSource.VOICE_RECOGNITION.
  • DEVE registrare il flusso audio di riconoscimento vocale con un’ampiezza approssimativamente piatta rispetto alle caratteristiche di frequenza: in particolare, ±3 dB, da 100 Hz a 4000 Hz.
  • DOVREBBE registrare il riconoscimento vocale flusso audio con la sensibilità di ingresso impostata in modo che un 90 dB suono di potenza del livello (SPL) sorgente a 1000 Hz produce RMS di 2500 per i campioni a 16 bit.
  • DOVREBBE registrare il flusso di riconoscimento audio di riconoscimento vocale in modo che i livelli di ampiezza PCM tracciano linearmente l'SPL di ingresso cambi oltre un intervallo di almeno 30 dB da -18 dB a +12 dB re 90 dB SPL al microfono.
  • DEVE registrare lo stream audio con riconoscimento vocale con distorsione armonica totale (THD) inferiore all'1% per 1 kHz a 90 dB di livello di ingresso SPL a livello di microfono.

Se le implementazioni del dispositivo dichiarano le tecnologie android.hardware.microphone e di eliminazione (riduzione del rumore) ottimizzate per il riconoscimento vocale, queste:

  • [C-2-1] DEVE consentire che questo effetto audio sia controllabile 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

Il corso android.media.MediaRecorder.AudioSource include la sorgente audio REMOTE_SUBMIX.

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

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

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

5.4.4. Cancellatore dell'eco acustica

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

  • DEVI implementare una tecnologia Acoustic Echo Canceler (AEC) ottimizzata per la comunicazione vocale e applicata al percorso di acquisizione quando acquisisci usando AudioSource.VOICE_COMMUNICATION

Se le implementazioni del dispositivo forniscono un Cancellazione dell'eco acustica che viene inserito nel percorso di acquisizione dell'audio quando viene selezionato AudioSource.VOICE_COMMUNICATION, questi:

5.4.5. Acquisizione simultanea

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

  • [C-1-1] DEVE consentire l'accesso simultaneo al microfono tramite l'acquisizione di un servizio di accessibilità con AudioSource.VOICE_RECOGNITION e l'acquisizione di almeno un'applicazione con qualsiasi AudioSource.
  • [C-1-2] DEVE consentire l'accesso simultaneo al microfono da parte di un'applicazione preinstallata che dispone di un 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 silenziare l'acquisizione dell'audio per qualsiasi altra applicazione, ad eccezione di un servizio di accessibilità, durante l'acquisizione con AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER da parte di un'applicazione. Tuttavia, quando un'app viene acquisita tramite AudioSource.VOICE_COMMUNICATION, un'altra app può acquisire la chiamata vocale se si tratta di un'app con privilegi (preinstallati) con autorizzazione CAPTURE_AUDIO_OUTPUT.
  • [C-1-4] Se due o più applicazioni acquisiscono contemporaneamente e nessuna delle due app ha un'UI nella parte superiore, quella che ha iniziato ad acquisire l'app più di recente riceve l'audio.

5.4.6. Livelli di guadagno del microfono

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

  • DOVREBBE presentare approssimativamente caratteristiche di ampiezza piatta rispetto alla frequenza nella gamma di frequenza media: in particolare ± 3 dB da 100 Hz a 4000 Hz per ogni microfono utilizzato per registrare la sorgente audio di riconoscimento vocale.
  • DOVREBBE impostare la sensibilità di ingresso audio in modo che una sorgente di tono sinusoidale a 1000 Hz suonata a 90 dB di livello di pressione sonora (SPL) produca una risposta con RMS di 2500 per campioni a 16 bit (o -22,35 dB di scala completa per campioni a virgola mobile/doppia precisione) per ogni sorgente audio utilizzata per registrare il riconoscimento vocale.
  • I [C-SR] sono VIVAMENTE CONSIGLIATI di mostrare livelli di ampiezza nella gamma di frequenze basse: in particolare da ±20 dB da 5 Hz a 100 Hz rispetto alla gamma di media frequenza per ogni microfono utilizzato per registrare la sorgente audio del riconoscimento vocale.
  • I [C-SR] sono VIVAMENTE CONSIGLIATI di mostrare livelli di ampiezza nella gamma delle alte frequenze: in particolare da ±30 dB da 4000 Hz a 22 KHz rispetto alla gamma di media frequenza per ogni microfono usato per registrare la sorgente audio del riconoscimento vocale.

5.5. Riproduzione audio

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

5.5.1. Riproduzione audio RAW

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

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

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

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

    • Frequenze di campionamento: 24.000

5.5.2. Effetti audio

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

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

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

5.5.3. Volume di uscita audio

Implementazioni di dispositivi nel settore auto e motori:

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

5.6. Latenza audio

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

Ai fini di questa sezione, utilizza le seguenti definizioni:

  • latenza di output. L'intervallo tra il momento in cui un'applicazione scrive un frame di dati codificati in PCM e il momento in cui il suono corrispondente viene presentato nell'ambiente di un trasduttore o di un segnale sul dispositivo esce dal dispositivo tramite una porta e può essere osservato esternamente.
  • latenza di output a freddo. La latenza di output per il primo frame, quando il sistema di output audio è stato inattivo e si è spento prima della richiesta.
  • latenza di output continua. La latenza di output per i frame successivi, dopo che il dispositivo ha avviato la riproduzione dell'audio.
  • latenza dell'input. L'intervallo tra il momento in cui un suono viene presentato dall'ambiente al dispositivo su un trasduttore o il segnale sul dispositivo entra nel dispositivo tramite una porta e quando un'applicazione legge il frame corrispondente di dati codificati PCM.
  • input perso. La parte iniziale di un segnale di input che è inutilizzabile o non disponibile.
  • latenza di input a freddo. La somma del tempo di input perso e della latenza di input per il primo frame, quando il sistema di input audio è stato inattivo e spento prima della richiesta.
  • latenza di input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.
  • jitter di uscita a freddo. La variabilità tra misurazioni separate dei valori di latenza dell'output a freddo.
  • jitter ingresso a freddo. La variabilità tra misurazioni separate dei valori di latenza dell'input a freddo.
  • latenza di round trip continua. La somma della latenza di input continuo più la latenza di output continuo più un periodo di buffer. Il periodo di buffer lascia all'app il tempo di elaborare il segnale e il tempo necessario per mitigare la differenza di fase tra gli stream di input e quelli di uscita.
  • API OpenSL ES PCM buffer Queue Il set di API OpenSL ES correlate a PCM in Android NDK.
  • Un'API audio nativa audio. Il set di API AAudio in Android NDK.
  • timestamp. Coppia costituita dalla posizione relativa di un frame all'interno di un flusso e dal tempo stimato in cui quel frame entra o esce dalla pipeline di elaborazione audio sull'endpoint associato. Vedi anche AudioTimestamp.
  • glitch. Un'interruzione temporanea o un valore di campionamento errato nel segnale audio, in genere causata da un inversione del buffer in uscita, da un superamento del buffer per l'ingresso 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 di +/- 2 ms.
  • [C-1-2] Latenza dell'output a freddo pari o inferiore a 500 millisecondi.

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

  • [C-SR] Latenza dell'output a freddo pari o inferiore a 100 millisecondi. È CONSIGLIATO MOLTO VIVAMENTE i dispositivi nuovi ed esistenti che eseguono questa versione di Android per soddisfare questi requisiti. In una futura release della piattaforma del 2021, avremo bisogno di una latenza dell'output a freddo pari o inferiore a 200 ms, come DEVE.
  • [C-SR] Latenza di output continua al massimo di 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 di +/- 1 ms.

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

Se le implementazioni del dispositivo non soddisfano i requisiti per l'audio a bassa latenza sia tramite le API OpenSL ES PCM che con le API audio native AAudio:

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

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

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

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

  • [C-SR] Latenza input a freddo pari o inferiore a 100 millisecondi. È CONSIGLIATO MOLTO VIVAMENTE i dispositivi nuovi ed esistenti che eseguono questa versione di Android per soddisfare questi requisiti. In una futura release della piattaforma nel 2021 avremo bisogno di una latenza dell'input freddo pari o inferiore a 200 ms, come DEVE.
  • [C-SR] Latenza di input continua di 30 millisecondi o inferiore.
  • [C-SR] Latenza di round trip continua di 50 millisecondi o inferiore.
  • [C-SR] Riduci al minimo il tremolio dell'input a freddo.
  • [C-SR] Limita l'errore nei timestamp di input, come restituito 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 audio e video, come specificato nella documentazione dell'SDK Android.

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

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

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

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

Formati dei segmenti multimediali

Formati dei segmenti Riferimenti Supporto codec richiesto
Stream di trasporto MPEG-2 ISO 13818 Codec video:
  • AVC H264
  • MPEG-4 SP
  • MPEG-2
Consulta la sezione 5.1.3 per maggiori dettagli su H264 AVC, MPEG2-4 SP
e MPEG-2.

Codec audio:

  • AAC
Consulta la sezione 5.1.1 per informazioni dettagliate su AAC e sulle sue varianti.
AAC con inquadratura ADTS e tag ID3 ISO 13818-7 Consulta la sezione 5.1.1 per i dettagli su AAC e sulle sue varianti
WebVTT WebVTT

RTSP (RTP, SDP)

Nome del profilo Riferimenti Supporto codec richiesto
AVC H264 RFC 6184 Consulta la sezione 5.1.3 per maggiori dettagli sugli AVC H264
MP4A-LATM RFC 6416 Consulta la sezione 5.1.1 per i dettagli su AAC e sulle sue varianti
H263-1998 RFC 3551
RFC 4629
RFC 2190 		Consulta la sezione 5.1.3 per maggiori dettagli su H263
263-2000 RFC 4629 Consulta la sezione 5.1.3 per maggiori dettagli su H263
Retrospettiva RFC 4867 Consulta la sezione 5.1.1 per i dettagli su AMR-NB
AMR-WB RFC 4867 Consulta la sezione 5.1.1 per informazioni dettagliate su AMR-WB
MP4V-ES RFC 6416 Consulta la sezione 5.1.3 per maggiori dettagli su MPEG-4 SP
mpeg4-generico RFC 3640 Consulta la sezione 5.1.1 per i dettagli su AAC e sulle sue varianti
MP2T RFC 2250 Per maggiori dettagli, consulta MPEG-2 Transport Stream sotto Live Streaming HTTP

5.8 Contenuti multimediali sicuri

Se le implementazioni dei dispositivi supportano l'output video sicuro e sono in grado di supportare piattaforme sicure, questi:

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

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

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

Se le implementazioni dei dispositivi dichiarano il supporto per Display.FLAG_SECURE e supportano il display esterno con cavo:

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

5.9 MIDI (Musical Instrument Digital Interface)

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

  • [C-1-1] DEVE supportare la tecnologia MIDI su tutti i trasporti hardware compatibili con MIDI per i quali viene fornita una connettività generica non MIDI, laddove tali trasporti siano:

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

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

5.10. Audio professionale

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

  • [C-1-1] DEVE segnalare il supporto della funzionalità android.hardware.audio.low_latency.
  • [C-1-2] DEVE avere una latenza audio di andata e ritorno continua, come definita nella sezione 5.6 Latenza audio, pari o inferiore a 20 millisecondi e 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 i requisiti relativi alle latenze e all'audio USB utilizzando sia l'API OpenSL ES PCM buffer Queue e almeno un percorso dell'API AAudio native audio.
  • [SR] È VIVAMENTE CONSIGLIATO per soddisfare le latenze e i requisiti audio USB usando l'API AAudio native audio tramite il percorso MMAP.
  • [C-1-6] DEVE avere una latenza dell'output a freddo di 200 millisecondi o inferiore.
  • [C-1-7] DEVE avere una latenza dell'input freddo pari o inferiore a 200 millisecondi.
  • [SR] È VIVAMENTE CONSIGLIATO di fornire un livello coerente di prestazioni della CPU quando l'audio è attivo e il carico della CPU varia. DEVE essere testato usando la versione dell'app per Android dell'ID commit 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 "Automated Test" (Test automatico) e ottenere i seguenti risultati:
    • voicemark.90 >= 32 voci
    • latenzamark.fixed.little <= 15 msec
    • latenzamark.dynamic.little <= 50 msec

Consulta la documentazione di SynthMark per una spiegazione dei benchmark.

  • DEVE ridurre al minimo l'imprecisione e la deviazione dell'orologio audio rispetto all'ora standard.
  • DOVRESTI ridurre al minimo la deviazione del clock 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 in caso di audio digitale USB.
  • DEVE documentare le misurazioni della latenza audio su tutti i percorsi.
  • DEVE ridurre al minimo il tremolio nei tempi di ingresso del callback di completamento del buffer audio, in quanto influisce sulla percentuale utilizzabile della larghezza di banda completa della CPU da parte del callback.
  • DEVE fornire zero glitch audio in condizioni di normale utilizzo alla latenza segnalata.
  • DEVE fornire zero differenze di latenza tra canali.
  • DEVE ridurre al minimo la latenza media MIDI su tutti i trasporti.
  • DEVE ridurre al minimo la variabilità della latenza MIDI sotto carico (jitter) su tutti i trasporti.
  • DOVREBBE fornire timestamp MIDI precisi su tutti i trasporti.
  • DEVE ridurre al minimo il rumore del segnale audio sui trasduttori sul dispositivo, incluso il periodo immediatamente dopo l'avvio a freddo.
  • DOVREBBE fornire zero differenza di orologio audio tra i lati di ingresso e di uscita dei punti finali corrispondenti, quando entrambi sono attivi. Esempi di endpoint corrispondenti includono il microfono e l'altoparlante 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 output dei punti finali corrispondenti sullo stesso thread quando entrambi sono attivi e inserisci il callback di output subito dopo il ritorno dal callback di input. Oppure, se non è possibile gestire i callback sullo stesso thread, inserisci il callback di output subito dopo il callback di input per consentire all'applicazione di avere una tempistica coerente dei lati di input e output.
  • DEVE ridurre al minimo la differenza di fase tra il buffering audio HAL per i lati di ingresso e di uscita dei punti finali corrispondenti.
  • DEVE ridurre al minimo la latenza al tocco.
  • DEVE ridurre al minimo la variabilità della latenza al tocco sotto carico (jitter).
  • DEVE avere una latenza dall'input touch all'output audio inferiore o uguale a 40 ms.

Se le implementazioni dei dispositivi soddisfano tutti i requisiti di cui sopra:

Se le implementazioni del dispositivo includono un jack audio da 3,5 mm a 4 conduttori, questi:

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

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

Se le implementazioni dei dispositivi includono una porta HDMI:

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

5.11. Acquisisci per i dati non elaborati

Android include il supporto della 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 del dispositivo intendono supportare la sorgente audio non elaborata e renderla disponibile ad app di terze parti:

  • [C-1-1] DEVE segnalare l'assistenza tramite la proprietà android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

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

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

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

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

  • [C-1-6] DEVE avere un rapporto segnale-rumore (SNR) a 60 dB o superiore per ogni microfono usato per registrare la sorgente audio non elaborata. (mentre l'SNR viene misurato come differenza tra 94 dB SPL e SPL equivalente di autorumore, ponderato in base alla curva A).

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

  • DEVE non avere nessun'altra elaborazione del segnale (ad es. controllo automatico del guadagno, filtro passa-alto o cancellazione dell'eco) nel percorso che non sia un moltiplicatore di livello per portare il livello all'intervallo desiderato. In altre parole:

  • [C-1-8] Se per qualsiasi motivo è presente un'elaborazione del segnale nell'architettura, DEVE essere disabilitata e effettivamente introdurre zero ritardo o latenza aggiuntiva al percorso del segnale.
  • [C-1-9] Il moltiplicatore di livello, sebbene possa essere sul percorso, NON DEVE introdurre ritardo o latenza nel percorso del segnale.

Tutte le misurazioni SPL vengono effettuate direttamente accanto al microfono sottoposto a test. In caso di configurazioni multiple, 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 API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), per indicare correttamente la mancanza di supporto.
  • I [SR] sono comunque CONSIGLIATI VIVAMENTE per soddisfare tanti requisiti per il percorso del segnale per l'origine di registrazione non elaborata.

6. Compatibilità degli strumenti e delle opzioni per sviluppatori

6.1 Strumenti per sviluppatori

Implementazioni dei dispositivi:

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

  • Android Debug Bridge (adb)

    • [C-0-2] DEVE supportare adb come documentato nell'SDK Android e i comandi della shell forniti in AOSP, che possono essere utilizzati dagli sviluppatori di app, tra cui dumpsys cmd stats
    • [C-SR] È VIVAMENTE CONSIGLIATO il supporto del comando shell cmd testharness.
    • [C-0-3] NON DEVE alterare il formato o i contenuti degli eventi di sistema del dispositivo (batterystats , diskstats, fingerprint, graphicstats, netstats, notifiche, procstats) registrati tramite il comando dumpsys.
    • [C-0-10] DEVE registrare, senza omettere, e rendere i seguenti eventi accessibili e disponibili per il comando shell cmd stats e la classe API di sistema StatsManager.
      • StatoattivitàForegroundChanged
      • Rilevata anomalia
      • Report AppBreadcrumb
      • Si è verificato un arresto anomalo dell'applicazione
      • Occorrenza dell'avvio dell'applicazione
      • LivelloBatteria cambiato
      • Risparmio energeticoModeStateChanged
      • BleScanResultRicevuto
      • BleScanStateChanged
      • Stato di ricaricaModifica
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduleJobStateChanged
      • StatoScreenChanged
      • SyncStateChanged
      • SistemaElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • Si è verificato un allarme sveglia
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] DEVE avere il daemon adb lato dispositivo non attivo 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 dell'ADB sicuro. Secure adb abilita adb su host autenticati noti.

    • [C-0-6] DEVE fornire un meccanismo che consenta ad adb di essere connesso da una macchina host. Ecco alcuni esempi:

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

  • Dalvik Debug Monitor (DDMS)

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

  • Perfetto

    • [C-SR] È VIVAMENTE CONSIGLIATO di esporre un file binario /system/bin/perfetto all'utente della shell, il quale cmdline rispetta la documentazione perfetta.
    • [C-SR] Il binario perfetto è VIVAMENTE CONSIGLIATO di accettare come input una configurazione protobuf conforme allo schema definito nella documentazione di Perfetto.
    • [C-SR] È VIVAMENTE CONSIGLIATO di scrivere come output una traccia protobuf conforme allo schema definito nella documentazione Perfetto.
    • [C-SR] È VIVAMENTE CONSIGLIATO di fornire, tramite il programma binario perfetto, almeno le origini dati descritte nella documentazione perfetta.

  • Modalità test Harness

    Se le implementazioni del dispositivo supportano il comando shell cmd testharness ed eseguono cmd testharness enable, questi:

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

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

6.2. Opzioni sviluppatore

Android include il supporto per gli sviluppatori per la configurazione delle impostazioni relative allo sviluppo di applicazioni.

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

  • [C-0-1] DEVE rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo delle applicazioni. L'implementazione Android upstream nasconde per impostazione predefinita il menu Opzioni sviluppatore e consente agli utenti di avviare le Opzioni sviluppatore dopo aver premuto sette (7) volte sulla voce 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 anziché a un'altra per attivare le Opzioni sviluppatore. DEVE fornire un documento o un sito web visibile pubblicamente che descriva come attivare le Opzioni sviluppatore. Questo documento o sito web DEVE essere collegato ai documenti dell'SDK Android.
  • DOVREBBE avere una notifica visiva continua per l'utente quando le Opzioni sviluppatore sono attive e la sicurezza dell'utente è un problema.
  • POTREBBE limitare temporaneamente l'accesso al menu Opzioni sviluppatore, nascondendo o disattivandolo visivamente, per evitare distrazioni negli scenari in cui la sicurezza dell'utente è preoccupante.

7. Compatibilità hardware

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

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

Se un'API nell'SDK interagisce con un componente hardware che è stato dichiarato facoltativo e l'implementazione sul dispositivo non possiede questo componente:

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

Un esempio tipico di scenario in cui si applicano questi requisiti è l'API per la telefonia: anche sui dispositivi diversi dagli smartphone, queste API DEVONO essere implementate in modo ragionevole.

7.1 Display e grafica

Android include funzionalità che regolano automaticamente gli asset delle applicazioni e i layout dell'interfaccia utente in modo appropriato in base al dispositivo per garantire che le applicazioni di terze parti funzionino correttamente su diverse configurazioni hardware. Sui display compatibili con Android in cui possono essere eseguite tutte le applicazioni di terze parti compatibili con Android, le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in dettaglio in questa sezione.

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

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

7.1.1. Configurazione schermata

7.1.1.1. Dimensioni e forma dello schermo

Il framework della UI di Android supporta una varietà di dimensioni logiche di layout dello schermo e consente alle applicazioni di eseguire query sulle dimensioni del layout dello schermo della configurazione attuale tramite Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK e Configuration.smallestScreenWidthDp.

Implementazioni dei dispositivi:

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

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

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

  • POTREBBE avere display compatibili con Android con angoli arrotondati.

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

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

Anche se non sono previste limitazioni alle proporzioni del display fisico per i display compatibili con Android, le proporzioni del display logico su cui viene eseguito il rendering delle app di terze parti, che possono essere derivate dai valori di altezza e larghezza riportati tramite le API view.Display e le API Configurazione, DEVONO soddisfare i seguenti requisiti:

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

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

  • [C-0-2] Le implementazioni dei dispositivi con il criterio Configuration.uiMode impostato su UI_MODE_TYPE_NORMAL DEVONO avere un valore delle proporzioni uguale o superiore a 1,3333 (4:3), a meno che l'app non possa essere ampliata 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 per le proporzioni impostato su 1,0 (1:1).

7.1.1.3. Densità schermo

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

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

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

Se è necessario modificare le dimensioni di visualizzazione del dispositivo:

  • [C-1-1] La dimensione del display NON DEVE essere scalata superiore a 1,5 volte la densità nativa, né produrre una dimensione minima effettiva dello schermo inferiore a 320 dp (equivalente al qualificatore di risorsa sw320dp), a seconda dell'evento che si verifica per primo.
  • [C-1-2] La dimensione del display NON DEVE essere scalata di meno di 0,85 volte la densità nativa.
  • Per garantire una buona usabilità e dimensioni dei caratteri coerenti, consigliamo di fornire le seguenti opzioni di ridimensionamento nativo (nel rispetto dei limiti specificati sopra)
  • Piccola: 0,85x
  • Valore predefinito: 1x (scala display nativa)
  • Grande: 1,15x
  • Più grande: 1,3x
  • Il più grande 1,45x

7.1.2. Metriche di visualizzazione

Se le implementazioni dei dispositivi includono display o output video compatibili con Android sugli schermi dei display compatibili con Android, questi:

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

Se le implementazioni dei dispositivi non includono una schermata o un output video incorporati:

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

7.1.3. Orientamento schermo

Implementazioni dei dispositivi:

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

Se le implementazioni del dispositivo supportano entrambi gli orientamenti dello schermo:

  • [C-1-1] DEVE supportare l'orientamento dinamico delle applicazioni con l'orientamento dello schermo verticale o orizzontale. In altre parole, il dispositivo DEVE rispettare la richiesta dell'applicazione relativa a un orientamento dello schermo specifico.
  • [C-1-2] NON DEVE modificare le dimensioni o la densità dello schermo segnalate quando cambi l'orientamento.
  • POTREBBE selezionare l'orientamento verticale o orizzontale come impostazione predefinita.

7.1.4. Accelerazione delle schede grafiche 2D e 3D

7.1.4.1 OpenGL ES

Implementazioni dei dispositivi:

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

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

  • [C-1-1] DEVE supportare sia OpenGL ES 1.1 che 2.0, come incorporato e descritto in dettaglio nella documentazione relativa all'SDK per Android.
  • [C-SR] È VIVAMENTE CONSIGLIATO di supportare OpenGL ES 3.1.
  • DEVE supportare OpenGL ES 3.2.

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

  • [C-2-1] DEVE segnalare tramite le API gestite OpenGL ES e le API native eventuali altre estensioni OpenGL ES implementate e, viceversa, NON DEVE segnalare stringhe di estensioni che non supportano.
  • [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] È VIVAMENTE CONSIGLIATO di supportare le estensioni EGL_KHR_partial_update e OES_EGL_image_external.
  • DEVONO generare report precisi tramite il metodo getString(), qualsiasi formato di compressione delle texture supportato, che in genere è specifico del fornitore.

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

  • [C-3-1] DEVE esportare i simboli di funzione corrispondenti per questa versione in aggiunta ai simboli di funzione OpenGL ES 2.0 nella libreria libGLESv2.so.
  • [SR] È VIVAMENTE CONSIGLIATO di supportare l'estensione OES_EGL_image_external_essl3.

Se le implementazioni dei dispositivi supportano OpenGL ES 3.2:

  • [C-4-1] DEVE supportare completamente il pacchetto di estensioni Android OpenGL ES.

Se le implementazioni dei dispositivi supportano nella sua interezza il pacchetto di estensioni Android OpenGL ES, questi:

  • [C-5-1] DEVE 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 con overhead ridotto per una grafica 3D ad alte prestazioni.

Se le implementazioni dei dispositivi supportano OpenGL ES 3.1:

  • [SR] Ti consigliamo vivamente di includere il supporto per Vulkan 1.1.

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

  • DOVREBBE includere il supporto per Vulkan 1.1.

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

  • [C-1-1] DEVE segnalare il valore intero corretto con i flag delle funzionalità android.hardware.vulkan.level e android.hardware.vulkan.version.
  • [C-1-2] DEVE enumerare almeno un VkPhysicalDevice per l'API nativa Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] DEVE implementare completamente le API Vulkan 1.0 per ogni VkPhysicalDevice enumerato.
  • [C-1-4] DEVE enumerare i livelli, contenuti nelle librerie native denominate libVkLayer*.so nella directory della libreria nativa del pacchetto dell'applicazione, tramite le API native Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties() .
  • [C-1-5] NON DEVE enumerare i livelli forniti dalle librerie al di fuori del pacchetto dell'applicazione, né fornire altri modi per tracciare o intercettare l'API Vulkan, a meno che l'applicazione non abbia l'attributo android:debuggable impostato su true.
  • [C-1-6] DEVE segnalare tutte le stringhe di estensione supportate tramite le API native Vulkan e NON DEVE segnalare le stringhe di estensione non correttamente supportate.
  • [C-1-7] DEVE supportare le estensioni VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain e VK_KHR_incremental_present.
  • [C-SR] È VIVAMENTE CONSIGLIATO di supportare le estensioni VK_KHR_driver_properties e VK_GOOGLE_display_timing.

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

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

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

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

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

Implementazioni dei dispositivi:

  • [C-0-1] DEVE abilitare l'accelerazione hardware per impostazione predefinita e DEVE disattivarla se richiesto dallo sviluppatore impostando android:hardwareAccelerated="false" o disattivando l'accelerazione hardware direttamente tramite le API Android View.
  • [C-0-2] DEVE presentare un comportamento conforme alla documentazione relativa all'SDK per Android sull'accelerazione hardware.

Android include un oggetto TextureView che consente agli sviluppatori di integrare direttamente trame 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 mostrare un comportamento coerente con l'implementazione Android upstream.
7.1.4.5 Display ad ampia gamma

Se le implementazioni dei dispositivi rivendicano il supporto di display ad ampia gamma tramite Configuration.isScreenWideColorGamut() , questi:

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

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

  • [C-2-1] DOVREBBE coprire il 100% o più di sRGB nello spazio CIE 1931 xyY, sebbene la gamma di colori dello schermo sia indefinita.

7.1.5. Modalità di compatibilità delle applicazioni legacy

Android specifica una "modalità di compatibilità" in cui il framework opera in una modalità "normale" equivalente a dimensioni dello schermo (larghezza di 320 dp) a vantaggio delle applicazioni legacy non sviluppate per versioni precedenti di Android antecedenti all'indipendenza delle 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 definito dall'SDK Android, a meno che non siano specificamente consentiti in questo documento.

Tutti i display compatibili con Android nell'implementazione di un dispositivo:

  • [C-0-1] DEVE essere in grado di eseguire il rendering di grafica a colori a 16 bit.
  • DOVREBBE supportare display con grafica a colori a 24 bit.
  • [C-0-2] DEVE essere in grado di visualizzare le animazioni.
  • [C-0-3] DEVE avere proporzioni pixel (PAR) comprese tra 0,9 e 1,15. In altre parole, le proporzioni dei pixel DEVONO essere quasi quadrate (1,0) con una tolleranza del 10-15%.

7.1.7. Display secondari

Android include il supporto per display secondari compatibili con Android per attivare le funzionalità di condivisione dei contenuti multimediali e per le API per gli sviluppatori per l'accesso a display esterni.

Se le implementazioni dei dispositivi supportano un display esterno tramite una connessione cablata, wireless o incorporata per il display, questi:

  • [C-1-1] DEVE implementare l'API e il servizio di sistema di 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 per applicazioni IME (Input Method Editor) di terze parti, queste:

Implementazioni del dispositivo: * [C-0-1] NON DEVE includere una tastiera hardware che non corrisponde a uno dei formati specificati in android.content.res.Configuration.keyboard (QWERTY o a 12 tasti). * DEVE includere implementazioni aggiuntive delle tastiere software. * POTREBBE includere una tastiera hardware.

7.2.2. Navigazione non touch

Android include il supporto di D-pad, trackball e wheel come meccanismi per la navigazione non touch.

Implementazioni dei dispositivi:

Se le implementazioni del dispositivo non dispongono di navigazioni non touch, questi:

  • [C-1-1] DEVE fornire un meccanismo di interfaccia utente ragionevole e alternativo per la selezione e la modifica del testo, compatibile con i motori di gestione degli input. L'implementazione open source di Android upstream include un meccanismo di selezione adatto all'uso con dispositivi privi di input di navigazione non touch.

7.2.3. Tasti di navigazione

Le funzioni Home, Recenti e Indietro, generalmente fornite tramite l'interazione con un pulsante fisico dedicato o una parte distinta del touchscreen, sono essenziali per il paradigma di navigazione Android e, di conseguenza, le implementazioni dei dispositivi:

  • [C-0-1] DEVE fornire un'invito all'utente per avviare applicazioni installate che hanno un'attività con <intent-filter> impostato con ACTION=MAIN e CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER per le implementazioni dei dispositivi televisivi. La funzione Home DEVE essere il meccanismo per questo invito dell'utente.
  • DOVREBBE fornire i pulsanti per le funzioni Recenti e Indietro.

Se vengono fornite le funzioni Home, Recenti o Indietro, queste:

  • [C-1-1] DEVE essere accessibile con una singola azione (ad es. tocco, doppio clic o gesto) quando una di queste è accessibile.
  • [C-1-2] DEVE fornire una chiara indicazione di quale singola azione attiverà ciascuna funzione. Un'indicazione di questo tipo è rappresentata da un'icona visibile impressa sul pulsante, da un'icona del software nella parte dello schermo relativa alla barra di navigazione o da una procedura guidata passo passo della procedura di configurazione.

Implementazioni dei dispositivi:

  • [SR] è VIVAMENTE CONSIGLIATO di non fornire il meccanismo di input per la funzione Menu in quanto questa funzione è stata ritirata a favore della barra delle azioni da Android 4.0.

Se le implementazioni dei dispositivi forniscono la funzione Menu, queste:

  • [C-2-1] DEVE visualizzare il pulsante di overflow di azione ogni volta che il popup del menu extra di azione non è vuoto e la barra delle azioni è visibile.
  • [C-2-2] NON DEVE modificare la posizione del popup di overflow di azione visualizzato selezionando il pulsante di overflow nella barra delle azioni, ma POTREBBE visualizzare il popup di overflow di azione in una posizione modificata sullo schermo quando viene visualizzato selezionando la funzione Menu.

Se le implementazioni del dispositivo non offrono la funzione Menu, per la compatibilità con le versioni precedenti: * [C-SR] È VIVAMENTE CONSIGLIATA rendere disponibile la funzione Menu alle applicazioni quando targetSdkVersion è inferiore a 10, tramite un pulsante fisico, un tasto software o gesti. Questa funzione di menu 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, questi:

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

Se le implementazioni del dispositivo utilizzano una porzione distinta dello schermo per visualizzare i tasti di navigazione, questi:

  • [C-5-1] I tasti di navigazione DEVONO utilizzare una parte distinta dello schermo, non disponibile per le applicazioni e NON DEVONO oscurare o interferire in altro modo con la parte dello schermo disponibile per le applicazioni.
  • [C-5-2] DEVE rendere disponibile una parte del display alle applicazioni che soddisfano i requisiti definiti nella sezione 7.1.1.
  • [C-5-3] DEVE rispettare i flag impostati dall'app tramite il metodo API View.setSystemUiVisibility(), in modo che questa parte distinta dello schermo (ovvero la barra di navigazione) venga nascosta correttamente come documentato nell'SDK.

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

Se viene fornita una funzione di navigazione da qualsiasi punto dei bordi sinistro e destro dell'orientamento corrente dello schermo:

  • [C-7-1] La funzione di navigazione DEVE essere Indietro e consentire di scorrere dai bordi sinistro e destro dell'orientamento corrente dello schermo.
  • [C-7-2] Se sui bordi sinistro o destro vengono forniti pannelli di sistema con possibilità di scorrimento personalizzati, DEVONO essere posizionati all'interno del terzo superiore dello schermo con un'indicazione visiva chiara e persistente che il trascinamento potrebbe richiamare i riquadri sopra menzionati, e quindi non Indietro. Un pannello di sistema POTREBBE essere configurato da un utente in modo che atterra al di sotto del 1/3 della parte superiore dei bordi dello schermo, ma il pannello del sistema NON DEVE utilizzare più di 1/3 dei bordi.
  • [C-7-3] Se per l'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, documentato nell'SDK.
  • [C-7-4] Se per l'app in primo piano sono impostati i flag View.SYSTEM_UI_FLAG_IMMERSIVE o View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, i riquadri di sistema personalizzati a scorrimento DEVONO essere nascosti finché l'utente non visualizza le barre di sistema (ovvero la barra di navigazione e di stato) come implementato in AOSP.

7.2.4. Ingresso touchscreen

Android include il supporto di diversi sistemi di input del puntatore, ad esempio touchscreen, touchpad e dispositivi di input tocco falsi. Le implementazioni dei dispositivi basate su touchscreen sono associate a un display in modo che l'utente abbia l'impressione di manipolare direttamente gli elementi sullo schermo. Poiché l'utente tocca direttamente lo schermo, il sistema non richiede ulteriori inviti per indicare gli oggetti manipolati.

Implementazioni dei dispositivi:

  • DOVREBBE avere un sistema di input del puntatore (simile al mouse o al tocco).
  • DEVONO supportare puntatori monitorati in modo completamente indipendente.

Se le implementazioni dei dispositivi includono un touchscreen (singolo tocco o migliore), queste:

  • [C-1-1] DEVE segnalare TOUCHSCREEN_FINGER per il campo API Configuration.touchscreen.
  • [C-1-2] DEVE segnalare i flag funzionalità android.hardware.touchscreen e android.hardware.faketouch.

Se le implementazioni del dispositivo includono un touchscreen che può rilevare più di un singolo tocco, questi:

  • [C-2-1] DEVE segnalare i flag di funzionalità appropriati android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct e android.hardware.touchscreen.multitouch.jazzhand corrispondenti al tipo di touchscreen specifico sul dispositivo.

Se le implementazioni dei dispositivi non includono il touchscreen (e si basano soltanto su un dispositivo di puntamento) e soddisfano i requisiti relativi ai tattili falsi nella sezione 7.2.5, questi:

  • [C-3-1] NON DEVE segnalare eventuali flag di funzionalità che iniziano con android.hardware.touchscreen e DEVE segnalare solo android.hardware.faketouch.

7.2.5. Input tocco fittizio

L'interfaccia touch fittizia fornisce un sistema di input dell'utente che si avvicina a un sottoinsieme di funzionalità touchscreen. Ad esempio, un mouse o un telecomando che aziona il cursore sullo schermo è simile al tocco, ma richiede all'utente di puntare o mettere a fuoco e poi fare clic. Numerosi dispositivi di input come mouse, trackpad, air mouse basato su giroscopio, giroscopio, joystick e trackpad multi-touch possono supportare interazioni false con il tocco. Android include la funzionalità costante android.hardware.faketouch, che corrisponde a un dispositivo di input non touch (basato su puntatore) ad alta fedeltà, come un mouse o un trackpad, in grado di emulare in modo adeguato l'input basato sul tocco (incluso il supporto dei gesti di base), e indica che il dispositivo supporta un sottoinsieme emulato di funzionalità touchscreen.

Se le implementazioni dei dispositivi non includono un touchscreen, ma includono un altro sistema di input del puntatore che si vuole rendere disponibile, questi:

  • DEVE dichiarare il supporto per il flag della funzionalità android.hardware.faketouch.

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

  • [C-1-1] DEVE indicare le posizioni assolute nello schermo X e Y della posizione del puntatore e mostrare un puntatore visivo sullo schermo.
  • [C-1-2] DEVE segnalare l'evento touch con il codice di azione che specifica il cambiamento di stato che si verifica sul puntatore verso il basso o verso l'alto sullo schermo.
  • [C-1-3] DEVE supportare il puntatore verso il basso e verso l'alto su un oggetto sullo schermo, il che consente agli utenti di emulare il tocco su un oggetto sullo schermo.
  • [C-1-4] DEVE supportare i puntatori verso il basso, verso l'alto e verso il basso e poi verso l'alto nella stessa posizione su un oggetto dello schermo entro una soglia temporale, il che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo.
  • [C-1-5] DEVE supportare il puntatore verso il basso su un punto arbitrario dello schermo, il puntatore si sposta in qualsiasi altro punto arbitrario sullo schermo, seguito da un puntatore verso l'alto, che consente agli utenti di emulare un trascinamento al tocco.
  • [C-1-6] DEVE supportare il puntatore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in una posizione diversa sullo schermo e quindi di puntare il puntatore verso l'alto sullo schermo, il che consente agli utenti di far scorrere un oggetto sullo schermo.
  • [C-1-7] DEVE segnalare TOUCHSCREEN_NOTOUCH per il campo API Configuration.touchscreen.

Se le implementazioni dei dispositivi dichiarano il supporto per android.hardware.faketouch.multitouch.distinct:

  • [C-2-1] DEVE dichiarare il supporto per android.hardware.faketouch.
  • [C-2-2] DEVE supportare il tracciamento distinto di due o più input di cursori indipendenti.

Se le implementazioni dei dispositivi dichiarano il supporto per android.hardware.faketouch.multitouch.jazzhand:

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

7.2.6. Supporto del controller di gioco

7.2.6.1. Mappature pulsanti

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

  • [C-1-1] DEVE avere un controller incorporato o fornito con un controller separato nella casella, in modo da fornire un mezzo per inserire tutti gli eventi elencati nelle tabelle seguenti.
  • [C-1-2] DEVE essere in grado di mappare gli eventi HID alle costanti view.InputEvent di Android associate, come indicato nelle tabelle di seguito. L'implementazione upstream di Android include l'implementazione di controller di gioco che soddisfano questo requisito.
Pulsante Utilizzo HID2 Pulsante Android
R1 0x09 0x0001 KEYCODE_PULSANTE_A (96)
M1 0x09 0x0002 KEYCODE_PULSANTE_B (97)
X1 0x09 0x0004 KEYCODE_PULSANTE_X (99)
A1 0x09 0x0005 KEYCODE_PULSANTE_Y (100)
D-pad in alto1
D-pad in basso1 		0x01 0x00393 AXIS_HAT_Y4
D-pad sinistro1
D-pad destro1 		0x01 0x00393 AXIS_HAT_X4
Pulsante sulla spalla sinistra1 0x09 0x0007 KEYCODE_PULSANTE_L1 (102)
Pulsante sulla spalla destra1 0x09 0x0008 KEYCODE_PULSANTE_R1 (103)
Clic sulla levetta sinistra1 0x09 0x000E KEYCODE_button_THUMBL (106)
Clic sulla levetta destra1 0x09 0x000F KEYCODE_Button_THUMBR (107)
Home page1 0x0c 0x0223 KEYCODE_HOME (3)
Indietro1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 Gli utilizzi HID di cui sopra DEVONO essere dichiarati all'interno di un Gamepad CA (0x01 0x0005).

3 Questo utilizzo DEVE avere un minimo logico di 0, un massimo logico di 7, un minimo fisico di 0, un massimo fisico di 315, le unità in gradi e una dimensione del report di 4. Il valore logico è definito come la rotazione in senso orario rispetto all'asse verticale; ad esempio, un valore logico di 0 rappresenta nessuna rotazione e il pulsante su che viene premuto, mentre un valore logico di 1 rappresenta una rotazione di 45 gradi e vengono premuti sia i tasti in alto che a sinistra.

4 MotionEvent

Controlli analogici1 Utilizzo HID Pulsante Android
Trigger sinistro 0x02 0x00C5 AXIS_LTRIGGER
Grilletto destro 0x02 0x00C4 AXIS_RTRIGGER
Joystick sinistro 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
Joystick destro 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. Telecomando

Consulta la Sezione 2.3.1 per i requisiti specifici del dispositivo.

7.3. Sensori

Se le implementazioni del dispositivo includono un particolare tipo di sensore con un'API corrispondente per sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare tale API come descritto nella documentazione dell'SDK Android e nella documentazione open source di Android 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 il metodo SensorManager.getSensorList() e metodi simili.
  • [C-0-3] DEVE comportarsi in modo ragionevole per tutte le altre API dei sensori (ad esempio, restituendo true o false in modo appropriato quando le applicazioni tentano di registrare i listener, non chiamando i listener dei sensori quando i sensori corrispondenti non sono presenti e così via).

Se le implementazioni dei dispositivi includono un particolare tipo di sensore con un'API corrispondente per sviluppatori di terze parti, questi:

  • [C-1-1] DEVE segnalare tutte le misurazioni dei sensori utilizzando i valori del sistema internazionale di unità di misura (metrica) pertinenti per ciascun tipo di sensore, come definito nella documentazione dell'SDK per Android.
  • [C-1-2] DEVE riportare i dati dei sensori con una latenza massima di 100 millisecondi + 2 * sample_time per il caso di un flusso del sensore con una latenza massima richiesta di 0 ms quando il processore dell'applicazione è attivo. Questo ritardo non include eventuali ritardi dei filtri.
  • [C-1-3] DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time del sensore da attivare. È accettabile che questo campione abbia un'accuratezza pari a 0.

  • [SR] DEVE segnalare l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta l'ora in cui si è verificato l'evento e la sincronizzazione con l'orologio SystemClock.elapsedRealtimeNano(). Si consiglia vivamente di soddisfare questi requisiti sia per i dispositivi Android nuovi sia per quelli esistenti, in modo che possano eseguire l'upgrade alle future release della piattaforma dove questo potrebbe diventare un componente OBBLIGATORIO. L'errore di sincronizzazione DEVE essere inferiore a 100 millisecondi.

  • [C-1-4] Per qualsiasi API indicata nella documentazione relativa all'SDK per Android come sensore continuo, le implementazioni del dispositivo DEVONO fornire continuamente campioni di dati periodici che DEVONO avere un tremolio inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori timestamp riportati tra eventi consecutivi.

  • [C-1-5] DEVE garantire che il flusso di eventi del sensore NON DEVI impedire alla CPU del dispositivo di entrare in stato di sospensione o di riattivarsi da questo stato.

  • Quando sono attivati più sensori, il consumo di corrente NON DEVE superare la somma del consumo energetico segnalato del singolo sensore.

L'elenco riportato sopra non è esaustivo. Il comportamento documentato dell'SDK Android e della documentazione open source di Android sui sensori deve essere considerato autorevole.

Alcuni tipi di sensori sono composti, ovvero 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:

  • DEVONO implementare questi tipi di sensori, quando includono i prerequisiti fisici dei sensori, come descritto nella sezione Tipi di sensori.

Se le implementazioni dei dispositivi includono un sensore composito:

  • [C-2-1] DEVE implementare il sensore come descritto nella documentazione open source di Android sui sensori compositi.

7.3.1. Accelerometro

Implementazioni dei dispositivi:

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

Se le implementazioni dei dispositivi includono un accelerometro a 3 assi, questi:

  • [C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
  • [C-1-2] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER.
  • [C-1-3] DEVE essere conforme al sistema di coordinate dei sensori di Android come descritto nelle API di Android.
  • [C-1-4] DEVE essere in grado di misurare dalla caduta libera fino a quattro volte la gravità(4g) o più su qualsiasi asse.
  • [C-1-5] DEVE avere una risoluzione di almeno 12 bit.
  • [C-1-6] DEVE avere una deviazione standard non superiore a 0,05 m/s^, dove la deviazione standard DEVE essere calcolata per asse su campioni raccolti in un periodo di almeno 3 secondi alla velocità di campionamento più elevata.
  • [SR] è VIVAMENTE CONSIGLIATO di implementare il sensore composito TYPE_SIGNIFICANT_MOTION.
  • [SR] è VIVAMENTE CONSIGLIATO di implementare e segnalare il sensore TYPE_ACCELEROMETER_UNCALIBRATED. I dispositivi Android sono VIVAMENTE CONSIGLIATI per soddisfare questo requisito, pertanto potranno eseguire l'upgrade alla versione futura della piattaforma, laddove questo potrebbe diventare OBBLIGATORIO.
  • DEVI implementare i sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento relativo all'SDK Android.
  • DEVI segnalare eventi fino ad almeno 200 Hz.
  • DEVE avere una risoluzione di almeno 16 bit.
  • DEVE essere calibrata durante l'uso se le caratteristiche cambiano nel corso del ciclo di vita e vengono compensate, oltre a preservare i parametri di compensazione tra i riavvii del dispositivo.
  • DEVONO essere compensati in base alla temperatura.

Se le implementazioni del dispositivo includono un accelerometro a 3 assi e uno qualsiasi dei sensori composti TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER:

  • [C-2-1] La somma del loro consumo energetico DEVE essere sempre inferiore a 4 mW.
  • DOVREBBE essere al di sotto di 2 mW e 0,5 mW quando il dispositivo è in condizioni dinamiche o statiche.

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

  • [C-3-1] DEVE implementare i sensori composti TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • [C-SR] È VIVAMENTE 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, questi:

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

7.3.2. Magnetometro

Implementazioni dei dispositivi:

  • [C-SR] È VIVAMENTE CONSIGLIATO di includere un magnetometro a 3 assi (compasso).

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi, questi:

  • [C-1-1] DEVE implementare il sensore TYPE_MAGNETIC_FIELD.
  • [C-1-2] DEVE essere in grado di segnalare eventi fino ad una frequenza di almeno 10 Hz e DEVE segnalare eventi fino ad almeno 50 Hz.
  • [C-1-3] DEVE essere conforme al sistema di coordinate dei sensori di Android come descritto nelle API di 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 DEVE avere un valore inferiore a 200 μT, posizionando il magnetometro lontano dai campi magnetici dinamici (indotti dalla corrente) e statici (indotti dal magnete).
  • [C-1-6] DEVE avere una risoluzione uguale o più densa di 0,6 μT.
  • [C-1-7] DEVE supportare la calibrazione online e la compensazione dei bias in ferro duro e preservare i parametri di compensazione tra i riavvii del dispositivo.
  • [C-1-8] DEVE avere applicato la compensazione del ferro morbido; la calibrazione può essere eseguita mentre è in uso o durante la produzione del dispositivo.
  • [C-1-9] DEVE avere una deviazione standard, calcolata per asse sui campioni raccolti in un periodo di almeno 3 secondi alla frequenza di campionamento più veloce, non superiore a 1,5 μT; DEVE avere una deviazione standard non superiore a 0,5 μT.
  • DOVREBBE implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] È VIVAMENTE CONSIGLIATO di implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED sui dispositivi Android nuovi ed esistenti.

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

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

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi o un accelerometro, questi:

  • POTREBBE implementare il sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

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

7.3.3. GPS

Implementazioni dei dispositivi:

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

Se le implementazioni del dispositivo includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag della funzionalità android.hardware.location.gps, queste:

  • [C-1-1] DEVE supportare gli output di localizzazione a una frequenza di almeno 1 Hz quando richiesto tramite LocationManager#requestLocationUpdate.
  • [C-1-2] DEVE essere in grado di determinare la posizione in condizioni di cielo aperto (segnali forti, multipath trascurabile, HDOP < 2) entro 10 secondi (tempo veloce per la prima correzione), quando connesso a una connessione Internet con velocità dati di 0,5 Mbps o superiore. Questo requisito viene in genere soddisfatto utilizzando una qualche forma di tecnica GPS/GNSS assistito o prevista per ridurre al minimo il tempo di blocco del GPS/GNSS (i dati sull'assistenza includono ora di riferimento, posizione di riferimento ed efemerie/orologio satellitari).
    • [C-1-6] Dopo aver effettuato questo calcolo della posizione, le implementazioni del dispositivo DEVONO determinarne la posizione, in cielo aperto, entro 5 secondi, quando le richieste di posizione vengono riavviate, fino a un'ora dopo il calcolo iniziale della posizione, anche se la richiesta successiva viene effettuata senza una connessione dati e/o dopo un ciclo di spegnimento e riaccensione.

  • 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 almeno 8 satelliti di una costellazione tramite GnssStatus.Callback.
    • DOVREBBE essere in grado di tracciare contemporaneamente almeno 24 satelliti, da più costellazioni (ad esempio GPS + almeno uno di Glonass, Beidou, Galileo).
    • [C-SR] È VIVAMENTE CONSIGLIATO di continuare a fornire i normali output di posizione GPS/GNSS tramite le API GNSS Location Provider durante una telefonata di emergenza.
    • [C-SR] È VIVAMENTE CONSIGLIATO di registrare le misurazioni GNSS di tutte le costellazioni monitorate (come riportato nei messaggi GnssStatus), ad eccezione di SBAS.
    • [C-SR] È VIVAMENTE CONSIGLIATO di registrare i dati AGC e la frequenza delle misurazioni GNSS.
    • [C-SR] CONSIGLIATO VIVAMENTE di indicare tutte le stime di accuratezza (incluse orientamento, velocità e verticale) come parte di ciascuna posizione GPS/GNSS.
    • [C-SR] CONSIGLIATO VIVAMENTE di registrare le misurazioni GNSS non appena vengono rilevate, anche se non è stata ancora segnalata una posizione calcolata dal GPS/GNSS.
    • [C-SR] È VIVAMENTE CONSIGLIATO di riportare i tassi di pseudorange e pseudointervallo del GNSS, che, in condizioni di cielo aperto dopo aver determinato la posizione, da fermo o in movimento con meno di 0,2 metri al secondo quadrato di accelerazione, sono sufficienti per calcolare la posizione entro 20 metri e la velocità entro 0,2 metri al secondo, almeno il 95% del tempo.

7.3.4. Giroscopio

Implementazioni dei dispositivi:

  • [C-SR] È VIVAMENTE CONSIGLIATO di includere un sensore giroscopico, a meno che non sia incluso anche un accelerometro a 3 assi.

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

  • [C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
  • [C-1-2] DEVE implementare il sensore TYPE_GYROSCOPE; è VIVAMENTE CONSIGLIATO di implementare anche il sensore TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-4] DEVE avere una risoluzione di 12-bit o più e DEVE avere una risoluzione di 16-bit o più.
  • [C-1-5] DEVE essere compensato in temperatura.
  • [C-1-6] DEVE essere calibrato e compensato durante l'uso e preservare 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 si misura la varianza del giroscopio a una frequenza di campionamento di 1 Hz, DOVREBBE non essere superiore a 1e-7 rad^2/s^2.
  • [SR] L'errore di calibrazione è VIVAMENTE CONSIGLIATO essere inferiore a 0,01 rad/s quando il dispositivo è fermo a temperatura ambiente.
  • DEVI segnalare eventi fino ad almeno 200 Hz.

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

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

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

  • [C-3-1] DEVE implementare i sensori composti TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • [C-SR] È VIVAMENTE CONSIGLIATO di implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometro

Implementazioni dei dispositivi:

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

Se le implementazioni dei dispositivi includono un barometro, questi:

  • [C-1-1] DEVE implementare e segnalare il sensore TYPE_PRESSURE.
  • [C-1-2] DEVE essere in grado di inviare eventi a 5 Hz o superiore.
  • [C-1-3] DEVE essere compensato in temperatura.
  • [SR] VIVAMENTE CONSIGLIATO per poter riportare misurazioni di pressione nell'intervallo da 300 hPa a 1100 hPa.
  • DEVE avere una precisione assoluta di 1 hPa.
  • DOVREBBE avere una precisione relativa di 0,12 hPa su un intervallo di 20 hPa (equivalente a una precisione di ~ 1 m su un cambiamento di ~ 200 m a livello del mare).

7.3.6. Termometro

Implementazioni dei dispositivi:

  • POTREBBE includere un termometro ambientale (sensore di temperatura).
  • POTREBBE, ma NON DEVE includere un sensore di temperatura della CPU.

Se le implementazioni dei dispositivi includono un termometro ambientale (sensore di temperatura), questi:

  • [C-1-1] DEVE essere definita come SENSOR_TYPE_AMBIENT_TEMPERATURE e DEVE misurare la temperatura ambiente (della stanza/del veicolo) dal punto in cui l'utente interagisce con il dispositivo in gradi Celsius.
  • [C-1-2] DEVE essere definito come SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] DEVE misurare la temperatura della CPU del dispositivo.
  • [C-1-4] NON DEVE misurare nessun'altra temperatura.

Tieni presente che il tipo di sensore SENSOR_TYPE_TEMPERATURE è stato ritirato in Android 4.0.

7.3.7. Fotometro

  • Le implementazioni dei dispositivi POTREBBERO includere un fotometro (sensore della luce ambientale).

7.3.8. Sensore di prossimità

  • Le implementazioni dei dispositivi POTREBBERO includere un sensore di prossimità.

Se le implementazioni dei dispositivi includono un sensore di prossimità, questi:

  • [C-1-1] DEVE misurare la vicinanza di un oggetto nella stessa direzione dello schermo. In altre parole, il sensore di prossimità DEVE essere orientato in modo da rilevare oggetti vicini allo schermo, in quanto l'intento principale di questo tipo di sensore è rilevare lo 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 affidabilità

Se le implementazioni dei dispositivi includono un insieme di sensori di qualità superiore, come definito in questa sezione, e li mettono a disposizione di app di terze parti, questi:

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

Se le implementazioni dei dispositivi dichiarano android.hardware.sensor.hifi_sensors:

  • [C-2-1] DEVE avere un sensore TYPE_ACCELEROMETER che:

    • DEVE avere un intervallo di misurazione compreso tra almeno -8 g e +8 g, DEVE avere un intervallo di misurazione compreso tra almeno -16 g e +16 g.
    • DEVE avere una risoluzione di misurazione di almeno 2048 LSB/g.
    • DEVE avere una frequenza di misurazione minima di 12,5 Hz o inferiore.
    • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DEVE supportare il SensorDirectChannel RATE_VERY_FAST.
    • DEVE avere un rumore di misurazione non superiore a 400 μg/√Hz.
    • È NECESSARIO implementare una forma non riattivazione di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore.
    • DEVE avere un consumo energetico per i batch non inferiore a 3 mW.
    • [C-SR] È VIVAMENTE CONSIGLIATO disporre di una larghezza di banda di misurazione di 3 dB pari ad almeno l'80% della frequenza di Nyquist e dello spettro del rumore bianco all'interno di questa larghezza di banda.
    • DEVE avere una camminata casuale con 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 best-fit pari a ≤ 0,5%, e una variazione di sensibilità rispetto alla temperatura di ≤ 0,03%/C°.
    • DEVE avere una sensibilità trasversale < 2,5 % e una variazione della sensibilità trasversale < 0,2% nell'intervallo di temperatura di funzionamento del dispositivo.

  • [C-2-2] DEVE avere un elemento TYPE_ACCELEROMETER_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_ACCELEROMETER.

  • [C-2-3] DEVE avere un sensore TYPE_GYROSCOPE che:

    • DEVE avere un intervallo di misurazione compreso tra almeno -1000 e +1000 dps.
    • DEVE avere una risoluzione di misurazione di almeno 16 LSB/dps.
    • DEVE avere una frequenza di misurazione minima di 12,5 Hz o inferiore.
    • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DEVE supportare il SensorDirectChannel RATE_VERY_FAST.
    • DEVE avere un rumore di misurazione non superiore a 0,014°/s/√Hz.
    • [C-SR] È VIVAMENTE CONSIGLIATO disporre di una larghezza di banda di misurazione di 3 dB pari ad almeno l'80% della frequenza di Nyquist e dello spettro del rumore bianco all'interno di questa larghezza di banda.
    • DEVE avere una frequenza di camminata casuale inferiore a 0,001 °/s √Hz testata a temperatura ambiente.
    • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 0,05 °/ s / °C.
    • DEVE avere una variazione di sensibilità rispetto alla temperatura ≤ 0,02% / °C.
    • DEVE avere una non linearità della linea di best-fit pari a ≤ 0,2%.
    • DEVE avere una densità del rumore ≤ 0,007 °/s/√Hz.
    • DEVE avere un errore di calibrazione inferiore a 0,002 rad/s nell'intervallo di temperatura 10 ~ 40 °C quando il dispositivo è fermo.
    • DEVE avere una sensibilità g inferiore a 0,1°/s/g.
    • DEVE avere una sensibilità trasversale < 4,0 % e una variazione di sensibilità trasversale < 0,3% nell'intervallo di temperatura di funzionamento del dispositivo.

  • [C-2-4] DEVE avere un elemento TYPE_GYROSCOPE_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GYROSCOPE.

  • [C-2-5] DEVE avere un sensore TYPE_GEOMAGNETIC_FIELD che:

    • DEVE avere un intervallo di misurazione compreso tra almeno -900 e +900 μT.
    • DEVE avere una risoluzione di misurazione di almeno 5 LSB/uT.
    • DEVE avere una frequenza di misurazione minima di 5 Hz o inferiore.
    • DEVE avere una frequenza di misurazione massima di 50 Hz o superiore.
    • DEVE avere un rumore di misurazione non superiore a 0,5 uT.

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

    • È NECESSARIO implementare una forma non riattivazione di questo sensore con una capacità di buffering di almeno 600 eventi del sensore.
    • [C-SR] È VIVAMENTE CONSIGLIATO avere lo spettro del rumore bianco da 1 Hz ad almeno 10 Hz quando la frequenza del report è di 50 Hz o superiore.

  • [C-2-7] DEVE avere un sensore TYPE_PRESSURE che:

    • DEVE avere un intervallo di misurazione compreso tra almeno 300 e 1100 hPa.
    • DEVE avere una risoluzione di misurazione di almeno 80 LSB/hPa.
    • DEVE avere una frequenza di misurazione minima di 1 Hz o inferiore.
    • DEVE avere una frequenza di misurazione massima di 10 Hz o superiore.
    • DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz.
    • È NECESSARIO implementare una forma non riattivazione di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
    • DEVE avere un consumo energetico per i batch non inferiore a 2 mW.
  • [C-2-8] DEVE avere un sensore TYPE_GAME_ROTATION_VECTOR.
  • [C-2-9] DEVE avere un sensore TYPE_SIGNIFICANT_MOTION che:
    • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.
  • [C-2-10] DEVE avere un sensore TYPE_STEP_DETECTOR che:
    • È NECESSARIO implementare una forma non riattivazione di questo sensore con una capacità di buffering di almeno 100 eventi del sensore.
    • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.
    • DEVE avere un consumo energetico per i batch non inferiore a 4 mW.
  • [C-2-11] DEVE avere un sensore TYPE_STEP_COUNTER che:
    • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.
  • [C-2-12] DEVE avere un sensore TILT_DETECTOR che:
    • DEVE avere un consumo energetico non inferiore a 0,5 mW quando il dispositivo è statico e 1,5 mW quando il dispositivo è in movimento.
  • [C-2-13] Il timestamp dello stesso evento fisico riportato dall'accelerometro, dal giroscopio e dal magnetometro DEVE essere di massimo 2, 5 millisecondi l'uno dall'altro. Il timestamp dello stesso evento fisico riportato dall'accelerometro e dal giroscopio DEVE essere entro 0,25 millisecondi l'uno dall'altro.
  • [C-2-14] DEVONO avere i timestamp degli eventi del sensore giroscopio sulla stessa base temporale del sottosistema della fotocamera ed entro 1 millisecondi dall'errore.
  • [C-2-15] DEVE consegnare i campioni alle applicazioni entro 5 millisecondi dal momento in cui i dati sono disponibili su uno dei sensori fisici di cui sopra all'applicazione.
  • [C-2-16] NON DEVE avere un consumo energetico superiore a 0,5 mW con dispositivo statico e di 2 mW quando il dispositivo è in movimento se è attiva una qualsiasi combinazione dei seguenti sensori:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] POTREBBE avere un sensore TYPE_PROXIMITY, ma se presente DEVE avere una capacità di buffer minima di 100 eventi del sensore.

Tieni presente che tutti i requisiti di consumo di energia presenti in questa sezione non includono il consumo di corrente del processore di applicazioni. Include la potenza assorbita dall'intera catena dei sensori: il sensore, eventuali circuiti di supporto, qualsiasi sistema di elaborazione dei sensori dedicato e così via.

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

  • [C-3-1] DEVE dichiarare correttamente il supporto dei tipi di canali diretti e del livello delle tariffe dei report diretti tramite l'API isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
  • [C-3-2] DEVE supportare almeno uno dei due tipi di canali diretti dei sensori per tutti i sensori che dichiarano il supporto per il canale diretto dei sensori.
  • DEVONO supportare i report sugli eventi tramite il canale diretto del sensore per il sensore principale (variante non riattivazione) dei seguenti tipi:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensori biometrici

Per ulteriori informazioni sulla misurazione della sicurezza dello sblocco biometrico, consulta la documentazione sulla misurazione della sicurezza biometrica.

Se le implementazioni dei dispositivi includono una schermata di blocco sicura:

  • DEVE includere un sensore biometrico

I sensori biometrici possono essere classificati come Forte, Debole o Comodità in base ai tassi di accettazione di spoofing e impostori e alla sicurezza della pipeline biometrica. Questa classificazione determina le funzionalità del sensore biometrico di interfacciarsi con la piattaforma e con applicazioni di terze parti. Per impostazione predefinita, i sensori sono classificati come Comodità e, per essere classificati come Debole o Forte, devono soddisfare i requisiti aggiuntivi descritti di seguito. Sia la biometria debole che quella efficace offrono funzionalità aggiuntive, come descritto di seguito.

Per rendere disponibile un sensore biometrico alle applicazioni di terze parti, le implementazioni dei dispositivi:

  • [C-0-1] DEVE soddisfare i requisiti per l'identificazione biometrica forte o debole, come definiti nel presente documento.

Per consentire l'accesso alle chiavi dell'archivio chiavi ad applicazioni di terze parti, le implementazioni dei dispositivi:

  • [C-0-2] DEVE soddisfare i requisiti dello stato Forte definiti in questo documento.

Inoltre:

  • [C-0-3] DEVE essere abbinata a un'azione di conferma esplicita (ad esempio la pressione di un pulsante) se la biometria Forte è passiva (ad es. volto o iris dove non è presente alcun segnale esplicito dell'intenzione dell'utente).
    • [C-SR] L'azione di conferma della biometria passiva è VIVAMENTE CONSIGLIATA di essere protette in modo che un sistema operativo o la compromissione del kernel non possano eseguirne lo spoofing. Ad esempio, ciò significa che l'azione di conferma basata su un pulsante fisico viene instradata tramite un pin di input/output per uso generico (GPIO) di solo input di un elemento sicuro (SE) che non può essere azionato con nessun altro mezzo se non la pressione di un pulsante fisico.

Se le implementazioni dei dispositivi vogliono considerare un sensore biometrico come Comodità, queste:

  • [C-1-1] DEVE avere un tasso di accettazione falsa inferiore allo 0,002%.
  • [C-1-2] DEVE comunicare che questa modalità potrebbe essere meno sicura di una sequenza, una password o un PIN efficaci ed indicare chiaramente i rischi che ne derivano, se i tassi di accettazione di spoofing e impostori sono superiori al 7%.
  • [C-1-3] DEVE limitare la frequenza dei tentativi per almeno 30 secondi dopo cinque false prove per la verifica biometrica, in cui una prova falsa è una 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 nuovi dati biometrici senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare esistente o di aggiungere una nuova credenziale del dispositivo (PIN/pattern/password) protetta da TEE; l'implementazione del progetto open source Android fornisce il meccanismo nel framework per farlo.
  • [C-1-5] DEVE rimuovere completamente tutti i dati biometrici identificabili di un utente quando il suo account viene rimosso (anche tramite un ripristino dei dati di fabbrica).
  • [C-1-6] DEVE rispettare la segnalazione individuale per i dati biometrici (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 che vengono lanciati con la versione 10 di Android, una volta ogni 72 ore o meno per i dispositivi che eseguono l'upgrade da una versione precedente di Android.

  • [C-1-8] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) dopo uno dei seguenti modi:

    • Un periodo di timeout di inattività di 4 ore OPPURE
    • 3 tentativi di autenticazione biometrica non riusciti.
    • Il periodo di timeout per inattività e il conteggio delle autenticazioni non riuscite vengono reimpostati dopo una conferma di tutte le credenziali del dispositivo.

    L'upgrade dei dispositivi con una versione precedente di Android può essere esonerato da C-1-8.

  • [C-SR] È VIVAMENTE CONSIGLIATO avere un tasso di rifiuto errato inferiore al 10%, come misurato sul dispositivo.

  • [C-SR] CONSIGLIATO VIVAMENTE una latenza inferiore a 1 secondo, misurata dal rilevamento dei dati biometrici allo sblocco dello schermo, per ogni dato biometrico registrato.

Se le implementazioni dei dispositivi vogliono considerare un sensore biometrico come debole:

  • [C-2-1] DEVE soddisfare tutti i requisiti relativi alla Comodità di cui sopra, ad eccezione di [C-1-2].
  • [C-2-2] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 20%.
  • [C-2-3] DEVE avere un'implementazione di un archivio chiavi supportato da hardware ed eseguire la corrispondenza biometrica in un ambiente di esecuzione isolato, esterno allo spazio dell'utente Android o del kernel, come il Trusted Execution Environment (TEE) o su un chip con un canale sicuro verso l'ambiente di esecuzione isolato.
  • [C-2-4] DEVONO essere criptati e criptati tramite crittografia tutti i dati identificabili, 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 che rimandi all'ambiente di esecuzione isolato, come documentato nelle linee guida sull'implementazione sul sito dell'Android Open Source Project.
  • [C-2-5] Per la biometria basata su videocamera, durante l'autenticazione o la registrazione biometrica:
    • DEVE utilizzare la videocamera in una modalità che impedisca la lettura o l'alterazione dei fotogrammi della videocamera al di fuori dell'ambiente di esecuzione isolato o di un chip con un canale sicuro verso l'ambiente di esecuzione isolato.
    • Per le soluzioni RGB a fotocamera singola, i fotogrammi delle videocamere POSSONO essere leggibili al di fuori dell'ambiente di esecuzione isolato per supportare operazioni come l'anteprima per la registrazione, ma NON DEVONO comunque essere modificabili.
  • [C-2-6] NON DEVE consentire alle applicazioni di terze parti di distinguere tra le singole registrazioni biometriche.
  • [C-2-7] NON DEVE consentire al Responsabile delle applicazioni l'accesso non criptato a dati biometrici identificabili o a dati derivati dagli stessi (come gli incorporamenti) al di fuori del contesto del TEE.

  • [C-2-8] DEVE avere una pipeline di elaborazione sicura, tale che un sistema operativo o la compromissione del kernel non possano consentire l'inserimento diretto dei dati per autenticarsi erroneamente 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 software di sistema, i dispositivi POSSONO essere esentati dal requisito.

Se le implementazioni dei dispositivi vogliono considerare un sensore biometrico come Strong:

  • [C-3-1] DEVE soddisfare tutti i requisiti della classe Debole di cui sopra. L'upgrade di dispositivi da una versione precedente di Android non è esente da C-2-7.
  • [C-3-2] DEVE avere un tasso di accettazione di spoofing e impostori non superiore al 7%.
  • [C-3-3] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) una volta ogni 72 ore o meno.

7.3.12. Sensore di posizione

Implementazioni dei dispositivi:

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

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

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

7.4. Connettività dei dati

7.4.1. Telefonia

"Telefonia", come utilizzato dalle API Android, e il presente documento si riferisce specificamente all'hardware relativo all'effettuazione di chiamate vocali e all'invio di SMS tramite una rete GSM o CDMA. Anche se queste chiamate vocali possono o meno essere a commutazione di pacchetto, sono ai fini di Android considerate indipendenti da qualsiasi connettività dati che possa essere implementata utilizzando la stessa rete. In altre parole, le API e le funzionalità di "telefonia" di Android si riferiscono specificamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni dei dispositivi che non possono effettuare chiamate o inviare/ricevere SMS non sono considerate dispositivi di telefonia, indipendentemente dal fatto che utilizzino o meno una rete mobile per la connettività dati.

  • Android POTREBBE essere utilizzato su dispositivi che non includono hardware per la telefonia. Questo significa che Android è compatibile con dispositivi diversi dagli smartphone.

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

  • [C-1-1] DEVE dichiarare il flag della funzionalità android.hardware.telephony e altri flag della funzionalità secondaria 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 per la telefonia:

  • [C-2-1] DEVE implementare le API complete in modalità autonoma.

Se le implementazioni dei dispositivi supportano eUICC o eSIM/SIM incorporate e includono un meccanismo proprietario per rendere la funzionalità eSIM disponibile per gli sviluppatori di terze parti, questi:

7.4.1.1. Compatibilità con blocco numerico

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

  • [C-1-1] DEVE includere il supporto del blocco dei numeri
  • [C-1-2] DEVE implementare completamente BlockedNumberContract e l'API corrispondente come descritto nella documentazione dell'SDK.
  • [C-1-3] DEVE bloccare tutte le chiamate e i messaggi da un numero di telefono in "BlockNumberProvider" senza alcuna interazione con le app. L'unica eccezione si verifica quando il blocco del numero viene temporaneamente rimosso, come descritto nella documentazione dell'SDK.
  • [C-1-4] NON DEVE scrivere nel provider del registro chiamate della piattaforma per una chiamata bloccata.
  • [C-1-5] NON DEVE scrivere al provider di telefonia per un messaggio bloccato.
  • [C-1-6] DEVE implementare un'interfaccia utente di gestione dei numeri bloccata, 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 pieno controllo dei servizi di telefonia, una singola istanza, sul dispositivo. Tutte le UI correlate al blocco DEVONO essere nascoste per gli utenti secondari e l'elenco bloccato DEVE essere comunque rispettato.
  • DEVONO eseguire la migrazione dei numeri bloccati al provider quando un dispositivo viene aggiornato ad Android 7.0.
7.4.1.2. API Telecom

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

  • [C-1-1] DEVE supportare le API ConnectionService descritte nell'SDK.
  • [C-1-2] DEVE visualizzare una nuova chiamata in arrivo e fornire all'utente l'invito ad accettare o rifiutare la chiamata in arrivo quando è in corso una chiamata effettuata da un'app di terze parti che non supporta la funzionalità di attesa specificata tramite CAPABILITY_SUPPORT_HOLD.
  • [C-1-3] DEVE avere un'applicazione che implementa InCallService.

  • [C-SR] È VIVAMENTE CONSIGLIATO di informare l'utente che se si risponde a una chiamata in arrivo, una chiamata in corso verrà interrotta.

    L'implementazione AOSP soddisfa questi requisiti con un avviso che indica all'utente che rispondendo a una chiamata in arrivo, l'altra chiamata verrà interrotta.

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

  • [C-SR] È VIVAMENTE CONSIGLIATO di gestire gli eventi KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK delle cuffie audio per le API android.telecom come indicato di seguito:
    • Chiama il numero Connection.onDisconnect() quando viene rilevata una breve pressione dell'evento chiave durante una chiamata in corso.
    • Chiama il numero Connection.onAnswer() quando viene rilevata una breve pressione dell'evento chiave durante una chiamata in arrivo.
    • Chiama il numero Connection.onReject() quando viene rilevata una pressione prolungata dell'evento chiave durante una chiamata in arrivo.
    • Attiva/disattiva lo stato di disattivazione dell'audio di CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementazioni dei dispositivi:

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

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

  • [C-1-1] DEVE implementare l'API Android corrispondente.
  • [C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.wifi.
  • [C-1-3] DEVE implementare l'API multicast come descritto nella documentazione dell'SDK.
  • [C-1-4] DEVE supportare il DNS multicast (mDNS) e NON filtrare i pacchetti mDNS (224.0.0.251) in nessun momento del funzionamento, tra cui:
    • anche quando lo schermo non è in stato attivo.
    • Per implementazioni di dispositivi Android Television, anche in stato di alimentazione in standby.
  • [C-1-5] NON DEVE considerare la chiamata al metodo API WifiManager.enableNetwork() come un'indicazione sufficiente per cambiare il Network attualmente attivo che viene utilizzato per impostazione predefinita per il traffico dell'applicazione e viene restituito da metodi API ConnectivityManager come getActiveNetwork e registerDefaultNetworkCallback. In altre parole, POSSONO disattivare l'accesso a Internet fornito da qualsiasi altro provider di rete (ad esempio, i dati mobili) solo se viene verificato che la rete Wi-Fi fornisce l'accesso a Internet.
  • [C-1-6] È VIVAMENTE CONSIGLIATO, quando viene chiamato il metodo API ConnectivityManager.reportNetworkConnectivity(), rivalutare l'accesso a Internet su Network e, una volta che la valutazione determina che l'attuale Network non fornisce più l'accesso a Internet, passare a qualsiasi altra rete disponibile (ad esempio, dati mobili) che fornisca l'accesso a Internet.
  • [C-SR] È VIVAMENTE CONSIGLIATO di randomizzare l'indirizzo MAC di origine e il numero di sequenza dei frame di richiesta del probe, una volta all'inizio di ogni scansione, mentre STA è disconnesso.
    • Ogni gruppo di frame di richiesta di probe che comprende una scansione DEVE utilizzare un indirizzo MAC coerente (NON DEVE randomizzare l'indirizzo MAC a metà di una scansione).
    • Il numero di sequenza della richiesta di probe DEVE essere ripetuto normalmente (in sequenza) tra le richieste di probe in una scansione.
    • Il numero di sequenza della richiesta di probe DEVE essere randomizzato tra l'ultima richiesta di probe di una scansione e la prima richiesta di probe della scansione successiva.
  • [C-SR] È VIVAMENTE CONSIGLIATO, mentre STA è disconnessa, per consentire solo i seguenti elementi nei frame di richieste di probe:
    • Set di parametri SSID (0)
    • Set di parametri DS (3)

Se le implementazioni dei dispositivi includono il supporto per la modalità di risparmio energetico del Wi-Fi come definita nello standard IEEE 802.11:

  • [C-3-1] DEVE disattivare la modalità di risparmio energetico del Wi-Fi ogni volta che un'app acquisisce il blocco WIFI_MODE_FULL_HIGH_PERF o il blocco WIFI_MODE_FULL_LOW_LATENCY tramite le API WifiManager.createWifiLock() e WifiManager.WifiLock.acquire() e quest'ultimo è attivo.
  • [C-3-2] La latenza media di round trip tra il dispositivo e un punto di accesso quando il dispositivo è in una modalità di blocco a bassa latenza Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) DEVE essere inferiore alla latenza durante una modalità di blocco Wi-Fi High Perf (WIFI_MODE_FULL_HIGH_PERF).
  • [C-SR] È VIVAMENTE CONSIGLIATO per ridurre al minimo la latenza di round trip 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 utilizzano il Wi-Fi per la ricerca della posizione, questi:

7.4.2.1. Wi-Fi Direct

Implementazioni dei dispositivi:

  • DOVREBBE includere il supporto per Wi-Fi Direct (peer-to-peer Wi-Fi).

Se le implementazioni dei dispositivi includono il supporto per Wi-Fi Direct:

  • [C-1-1] DEVE implementare l'API Android corrispondente come descritto nella documentazione dell'SDK.
  • [C-1-2] DEVE segnalare la funzionalità hardware android.hardware.wifi.direct.
  • [C-1-3] DEVE supportare il normale funzionamento del Wi-Fi.
  • [C-1-4] DEVE supportare contemporaneamente operazioni Wi-Fi e Wi-Fi Direct.

Implementazioni dei dispositivi:

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

  • [C-1-1] DEVE dichiarare il supporto per TDLS tramite WifiManager.isTdlsSupported.
  • DOVREBBE usare TDLS solo quando è possibile E vantaggioso.
  • DOVREBBE avere un po' di euristica e NON usare TDLS quando le sue prestazioni potrebbero essere peggiori rispetto al passaggio attraverso il punto di accesso Wi-Fi.
7.4.2.3. Sensibile al Wi-Fi

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi includono il supporto per Wi-Fi Aware ed espongono la funzionalità ad app di terze parti:

  • [C-1-1] DEVE implementare le API di WifiAwareManager come descritto nella documentazione dell'SDK.
  • [C-1-2] DEVE dichiarare il flag della funzionalità android.hardware.wifi.aware.
  • [C-1-3] DEVE supportare contemporaneamente operazioni Wi-Fi e Wi-Fi Aware.
  • [C-1-4] DEVE randomizzare l'indirizzo dell'interfaccia di gestione di Wi-Fi Aware a intervalli non superiori a 30 minuti e ogni volta che è attivo il Wi-Fi Aware.

Se le implementazioni dei dispositivi includono il supporto per Wi-Fi Aware e Localizzazione Wi-Fi come descritto nella Sezione 7.4.2.5 ed espongono queste funzionalità ad app di terze parti, questi:

7.4.2.4. Passpoint Wi-Fi

Implementazioni dei dispositivi:

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

  • [C-1-1] DEVE implementare le API WifiManager relative a Passpoint come descritto nella documentazione dell'SDK.
  • [C-1-2] DEVE supportare lo standard IEEE 802.11u, specificamente correlato alla scoperta e selezione della rete, quali Generic Pubblicità Service (GAS) e Access Network Query Protocol (ANQP).

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

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

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi includono il supporto della posizione Wi-Fi ed espongono la funzionalità ad app di terze parti:

  • [C-1-1] DEVE implementare le API di WifiRttManager come descritto nella documentazione dell'SDK.
  • [C-1-2] DEVE dichiarare il flag della funzionalità android.hardware.wifi.rtt.
  • [C-1-3] DEVE randomizzare l'indirizzo MAC sorgente per ogni burst RTT che viene eseguito mentre l'interfaccia Wi-Fi su cui il RTT è in esecuzione non è associata ad un punto di accesso.
7.4.2.6. Offload keepalive Wi-Fi

Implementazioni dei dispositivi:

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

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

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

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

Se le implementazioni dei dispositivi non includono il supporto per il download keepalive Wi-Fi:

7.4.2.7. Wi-Fi Easy Connect (protocollo di provisioning dei dispositivi)

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi includono il supporto di Connessione rapida Wi-Fi ed espongono la funzionalità ad app di terze parti, questi:

7.4.3. Bluetooth

Se le implementazioni del dispositivo supportano il profilo audio Bluetooth:

  • DEVONO supportare i codec audio avanzati e i codec audio Bluetooth (ad esempio LDAC).

Se le implementazioni dei dispositivi supportano HFP, A2DP e AVRCP, questi:

  • DEVONO supportare almeno 5 dispositivi connessi in totale.

Se le implementazioni dei dispositivi dichiarano la funzionalità android.hardware.vr.high_performance:

  • [C-1-1] DEVE supportare Bluetooth 4.2 e Bluetooth LE estensione lunghezza dati.

Android include il supporto per Bluetooth e Bluetooth Low Energy.

Se le implementazioni dei dispositivi includono il supporto per Bluetooth e Bluetooth 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.
  • DEVI implementare profili Bluetooth pertinenti, come A2DP, AVRCP, OBEX, HFP e così via in base al dispositivo.

Se le implementazioni dei dispositivi includono il supporto per Bluetooth Low Energy:

  • [C-3-1] DEVE dichiarare la funzionalità hardware android.hardware.bluetooth_le.
  • [C-3-2] DEVE attivare le API Bluetooth basate su GATT (profilo attributo generico) come descritto nella documentazione dell'SDK e su android.bluetooth.
  • [C-3-3] DEVE segnalare il valore corretto per BluetoothAdapter.isOffloadedFilteringSupported() per indicare se la logica di filtro per le classi dell'API ScanFilter è implementata.
  • [C-3-4] DEVE segnalare il valore corretto per BluetoothAdapter.isMultipleAdvertisementSupported() per indicare se la pubblicità a bassa energia è supportata.
  • DOVREBBE supportare lo scarico della logica di filtro al chipset Bluetooth durante l'implementazione dell'API ScanFilter.
  • DOVREBBE supportare lo scarico della scansione in batch sul chipset Bluetooth.

  • DEVE supportare più annunci con almeno 4 aree annuncio.

  • [SR] VIVAMENTE CONSIGLIATO di implementare un timeout dell'indirizzo privato risolvibile (RPA) non superiore a 15 minuti e di ruotare l'indirizzo al timeout per proteggere la privacy degli utenti.

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

  • [C-4-1] DEVE fornire un'invito all'utente per abilitare/disabilitare il valore letto tramite l'API di sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se le implementazioni dei dispositivi includono il supporto per Bluetooth LE e il profilo degli apparecchi acustici, come descritto nell'articolo Supporto dell'audio degli apparecchi acustici con Bluetooth LE, questi:

7.4.4. Near Field Communication

Implementazioni dei dispositivi:

  • DEVE includere un ricetrasmettitore e l'hardware correlato per la tecnologia Near Field Communications (NFC).
  • [C-0-1] DEVE implementare le API android.nfc.NdefMessage e android.nfc.NdefRecord anche se non includono supporto per NFC o dichiarare 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 ad app di terze parti, questi:

  • [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, come indicato di seguito:
  • [C-1-2] DEVE essere in grado di agire come lettore/autore del forum NFC (come definito dalle specifiche tecniche NFCForum-TS-DigitalProtocol-1.0 dell'NFC Forum) tramite i seguenti standard NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Tipi di tag del forum NFC 1, 2, 3, 4, 5 (definiti dal forum NFC)

  • [SR] VIVAMENTE CONSIGLIATO che sia in grado di leggere e scrivere messaggi NDEF e di dati non elaborati tramite i seguenti standard NFC. Tieni presente che sebbene gli standard NFC siano indicati come VIVAMENTE CONSIGLIATI, si prevede che nella definizione di compatibilità per una versione futura vengano modificati in DEVI. Questi standard sono facoltativi in questa versione, ma saranno obbligatori nelle versioni future. I dispositivi nuovi ed esistenti che eseguono questa versione di Android sono MOLTO VIVAMENTE INvogliati a soddisfare questi requisiti ora, in modo da poter eseguire l'upgrade alle future release della piattaforma.

  • [C-1-13] DEVE effettuare un sondaggio per tutte le tecnologie supportate in modalità di rilevamento NFC.

  • DEVE essere in modalità di rilevamento NFC mentre il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.
  • 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 del forum citate sopra.

Android supporta la modalità HCE (NFC Host Card Emulation).

Se le implementazioni del dispositivo includono un chipset controller NFC in grado di eseguire HCE (per NfcA e/o NfcB) e supportare il routing ID applicazione (AID), questi:

  • [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 controller NFC in grado di eseguire HCE per NfcF e implementano la funzionalità per le applicazioni di terze parti, questi:

  • [C-3-1] DEVE segnalare la costante della funzionalità android.hardware.nfc.hcef.
  • [C-3-2] DEVE implementare le API NFC Card Emulation come definito nell'SDK Android.

Se le implementazioni dei dispositivi includono il supporto NFC generale come descritto in questa sezione e supportano le tecnologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF su MIFARE Classic) nel ruolo di lettore/scrittore:

  • [C-4-1] DEVE implementare le API Android corrispondenti, come documentato dall'SDK Android.
  • [C-4-2] DEVE segnalare la funzionalità com.nxp.mifare dal metodo android.content.pm.PackageManager.hasSystemFeature(). Tieni presente che non si tratta di una funzionalità Android standard e, di conseguenza, non viene visualizzata come costante nella classe android.content.pm.PackageManager.

7.4.5. Capacità di rete minima

Implementazioni dei dispositivi:

  • [C-0-1] DEVE includere il supporto di una o più forme di networking di dati. In particolare, le implementazioni dei dispositivi DEVONO includere il supporto di almeno uno standard di dati in grado di funzionare da 200 Kbit/sec o superiore. Esempi di tecnologie che soddisfano questo requisito includono EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
  • DEVE includere anche il supporto per almeno uno standard di dati wireless comune, ad esempio 802.11 (Wi-Fi), quando la connessione dati principale è uno standard di rete fisico (come Ethernet).
  • POTREBBE implementare più di una forma di connettività dati.
  • [C-0-2] DEVE includere uno stack di rete IPv6 e supportare la comunicazione IPv6 utilizzando le API gestite, quali java.net.Socket e java.net.URLConnection, nonché le API native, quali i socket AF_INET6.
  • [C-0-3] DEVE abilitare IPv6 per impostazione predefinita.
  • DEVE garantire che la comunicazione IPv6 sia affidabile quanto IPv4, ad esempio:
    • [C-0-4] DEVE mantenere la connettività IPv6 in modalità sospensione.
    • [C-0-5] La limitazione di frequenza NON DEVE causare la perdita della connettività IPv6 del dispositivo su qualsiasi rete conforme a IPv6 che utilizzi una durata RA di almeno 180 secondi.
  • [C-0-6] DEVE fornire alle applicazioni di terze parti la connettività diretta IPv6 alla rete quando si è connessi a una rete IPv6, senza che alcun tipo di traduzione di indirizzi o porte avvenga 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.

Il livello richiesto di supporto IPv6 dipende dal tipo di rete, come indicato nei requisiti seguenti.

Se le implementazioni del dispositivo supportano il Wi-Fi:

  • [C-1-1] DEVE supportare il funzionamento a doppio stack e solo IPv6 su Wi-Fi.

Se le implementazioni dei dispositivi supportano Ethernet:

  • [C-2-1] DEVE supportare l'operazione a doppio stack su Ethernet.

Se le implementazioni dei dispositivi supportano la rete dati:

  • DEVE supportare l'operazione IPv6 (solo IPv6 e probabilmente a doppio stack) sulla rete cellulare.

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

  • [C-3-1] DEVE soddisfare contemporaneamente i requisiti precedenti su ciascuna rete quando il dispositivo è connesso contemporaneamente a più di un tipo di rete.

7.4.6. Impostazioni sincronizzazione

Implementazioni dei dispositivi:

  • [C-0-1] DEVE avere l'impostazione di sincronizzazione automatica principale attivata per impostazione predefinita, in modo che il metodo getMasterSyncAutomatically() restituisca "true".

7.4.7. Risparmio dati

Se le implementazioni dei dispositivi includono una connessione a consumo, si tratta di:

  • [SR] VIVAMENTE CONSIGLIATA di fornire la modalità Risparmio dati.

Se le implementazioni dei dispositivi offrono la modalità Risparmio dati, questi:

Se le implementazioni dei dispositivi non offrono la modalità Risparmio dati:

  • [C-2-1] DEVE restituire il valore RESTRICT_BACKGROUND_STATUS_DISABLED per ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] NON DEVE trasmettere ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • [C-2-3] DEVE avere un'attività che gestisca l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ma POTREBBE implementarla come soluzione indipendente.

7.4.8. Secure Element

Se le implementazioni dei dispositivi supportano elementi sicuri Open Mobile API e li rendono disponibili ad app di terze parti, questi:

7.5. Videocamere

Se le implementazioni dei dispositivi includono almeno una fotocamera:

  • [C-1-1] DEVE dichiarare il flag della funzionalità android.hardware.camera.any.
  • [C-1-2] Un'applicazione deve poter allocare contemporaneamente 3 bitmap RGBA_8888 uguali alle dimensioni delle immagini prodotte dal sensore della fotocamera con la più grande risoluzione presente sul dispositivo, mentre la fotocamera è aperta ai fini dell'anteprima di base e dell'acquisizione.
  • [C-1-3] DEVE garantire che l'applicazione di gestione della fotocamera predefinita preinstallata per gli intent MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE o MediaStore.ACTION_VIDEO_CAPTURE, sia responsabile della rimozione della posizione dell'utente nei metadati dell'immagine prima di inviarla all'applicazione ricevente quando quest'ultima non dispone di ACCESS_FINE_LOCATION.

7.5.1. Fotocamera posteriore

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

Implementazioni dei dispositivi:

  • DEVE includere una fotocamera posteriore.

Se le implementazioni del dispositivo includono almeno una fotocamera posteriore:

  • [C-1-1] DEVE segnalare il flag della funzionalità android.hardware.camera e android.hardware.camera.any.
  • [C-1-2] DEVE avere una risoluzione di almeno 2 megapixel.
  • DEVONO avere la messa a fuoco automatica hardware o software implementata nel driver della fotocamera (trasparente al software dell'applicazione).
  • POTREBBERO avere hardware a fuoco fisso o EDOF (profondità di campo estesa).
  • POSSONO includere un flash.

Se la fotocamera include il flash:

  • [C-2-1] il flash NON DEVE essere acceso mentre è stata registrata un'istanza android.hardware.Camera.PreviewCallback su una superficie di anteprima della fotocamera, a meno che l'applicazione non abbia abilitato esplicitamente il flash abilitando 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 videocamera che si trova sullo stesso lato del dispositivo del display, ovvero una fotocamera solitamente utilizzata per immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.

Implementazioni dei dispositivi:

  • POTREBBE includere una fotocamera anteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera anteriore:

  • [C-1-1] DEVE segnalare il flag della funzionalità android.hardware.camera.any e android.hardware.camera.front.
  • [C-1-2] DEVE avere una risoluzione di almeno VGA (640x480 pixel).
  • [C-1-3] NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Fotocamera e NON DEVE configurare l'API per trattare una fotocamera anteriore come fotocamera posteriore predefinita, anche se è l'unica fotocamera presente 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 lungo l'asse orizzontale predefinito del dispositivo quando l'applicazione corrente non richiede esplicitamente la rotazione del display della videocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation().
  • [C-1-5] NON DEVE riflettere gli stream video o l'immagine statica acquisiti finali, restituiti ai callback dell'applicazione o impegnati nello spazio di archiviazione multimediale.
  • [C-1-6] DEVE eseguire il mirroring dell'immagine visualizzata dal postview allo stesso modo dello stream di immagini di anteprima della fotocamera.
  • POTREBBERO includere funzionalità (quali messa a fuoco automatica, flash e così via) disponibili per le fotocamere posteriori come descritto nella sezione 7.5.1.

Se le implementazioni del dispositivo possono essere ruotate dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite input 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 che non è necessariamente sempre collegata.

Se le implementazioni dei dispositivi includono il supporto per una fotocamera esterna:

  • [C-1-1] DEVE dichiarare i flag delle funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any.
  • [C-1-2] DEVE supportare USB Video Class (UVC 1.0 o superiore) se la fotocamera esterna si collega tramite la porta host USB.
  • [C-1-3] DEVE superare i test CTS della videocamera con una videocamera esterna fisica collegata. I dettagli dei test CTS della fotocamera sono disponibili all'indirizzo source.android.com.
  • DEVONO supportare le compresse video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ovvero stream di immagini non elaborati o compressi in modo indipendente).
  • POTREBBE supportare più fotocamere.
  • POTREBBE supportare la codifica video basata su fotocamera.

Se la codifica video basata su fotocamera è supportata:

  • [C-2-1] Uno stream non codificato / MJPEG simultaneo (QVGA o risoluzione superiore) DEVE essere accessibile all'implementazione del dispositivo.

7.5.4. Comportamento dell'API Camera

Android include due pacchetti API per accedere alla fotocamera, la più recente API android.hardware.camera2 espongono all'app un controllo della fotocamera di livello inferiore, inclusi flussi efficienti di streaming/burst zero-copy e controlli per fotogramma di esposizione, guadagno, guadagno del bilanciamento del bianco, conversione del colore, riduzione del rumore, nitidezza e altro ancora.

Il pacchetto API precedente, android.hardware.Camera, è contrassegnato come deprecato in Android 5.0, ma DOVREBBE essere ancora disponibile per l'uso da parte delle app. Le implementazioni sui dispositivi Android DEVONO garantire il supporto continuo dell'API come descritto in questa sezione e nell'SDK per Android.

Tutte le funzionalità comuni tra la classe android.hardware.Camera deprecata e il pacchetto android.hardware.camera2 più recente DEVONO avere prestazioni e qualità equivalenti in entrambe le API. Ad esempio, con impostazioni equivalenti, la velocità e la precisione della messa a fuoco automatica DEVONO essere identiche, mentre la qualità delle immagini acquisite DEVONO essere la stessa. Le funzionalità che dipendono dalla semantica diversa delle due API non devono garantire una velocità o una qualità corrispondenti, ma DEVONO corrispondere il più fedelmente possibile.

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

  • [C-0-1] DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione quando un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] DEVE 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 nel byte [] passati in onPreviewFrame(). Vale a dire che NV21 DEVE essere l'impostazione predefinita.
  • [C-0-3] DEVE supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime delle fotocamere per le fotocamere anteriori e posteriori di android.hardware.Camera. (Il codificatore video hardware e la videocamera possono utilizzare qualsiasi formato pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione a 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 android.hardware.camera2 dispositivi 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, a prescindere dal fatto che il dispositivo includa la messa a fuoco automatica hardware o altre funzionalità. Ad esempio, le fotocamere prive di messa a fuoco automatica DEVONO comunque richiamare qualsiasi istanza di android.hardware.Camera.AutoFocusCallback registrata, anche se non è pertinente 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 la messa a fuoco automatica, le richiamate API DEVONO essere comunque "false" come descritto.
  • [C-0-6] DEVE riconoscere e rispettare il nome di ogni parametro definito come costante nella classe android.hardware.Camera.Parameters e nella classe android.hardware.camera2.CaptureRequest. Al contrario, le implementazioni del dispositivo NON DEVONO rispettare o riconoscere costanti stringhe passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti nel android.hardware.Camera.Parameters. Ciò significa che le implementazioni del dispositivo DEVONO supportare tutti i parametri standard della fotocamera, se l'hardware lo consente, e NON DEVONO supportare tipi di parametri personalizzati della fotocamera. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini con 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 assistenza corretto per la proprietà android.info.supportedHardwareLevel come descritto nell'SDK Android e i flag delle funzionalità framework appropriati.
  • [C-0-8] DEVE inoltre dichiarare le funzionalità della singola fotocamera di android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag di funzionalità appropriati; DEVE definire il flag della funzionalità se uno dei dispositivi con fotocamera collegata supporta la funzionalità.
  • [C-0-9] DEVE trasmettere l'intent Camera.ACTION_NEW_PICTURE ogni volta che viene scattata una nuova foto dalla fotocamera e il relativo ingresso viene aggiunto al media store.
  • [C-0-10] DEVE trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e l'immagine è stata aggiunta al media store.
  • [C-0-11] DEVE avere tutte le videocamere accessibili tramite l'API android.hardware.Camera deprecata accessibile anche tramite l'API android.hardware.camera2.
  • [C-SR] Per i dispositivi con più fotocamere RGB rivolte nella stessa direzione, è VIVAMENTE CONSIGLIATO di supportare un dispositivo con fotocamera logica che elenca la funzionalità CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, composta da tutte le fotocamere RGB rivolte in quella direzione come dispositivi secondari fisici.

Se le implementazioni del dispositivo forniscono un'API della fotocamera di proprietà ad app di terze parti, queste:

7.5.5. Orientamento fotocamera

Se le implementazioni del dispositivo hanno una fotocamera anteriore o posteriore, ad esempio:

  • [C-1-1] DEVE essere orientato in modo che la dimensione lunga della fotocamera sia allineata alla dimensione lunga dello schermo. In altre parole, quando il dispositivo è mantenuto in orientamento orizzontale, le videocamere DEVONO acquisire le immagini con l'orientamento orizzontale. Ciò vale indipendentemente dall'orientamento naturale del dispositivo, ovvero è valido sia per i dispositivi principali in orizzontale che per quelli principali con orientamento 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 una Gestione dei download che le applicazioni POSSONO utilizzare per scaricare file di dati e che DEVONO essere in grado di scaricare singoli file di almeno 100 MB nella posizione predefinita della "cache".

7.6.2. Archiviazione condivisa delle applicazioni

Implementazioni dei dispositivi:

  • [C-0-1] DEVE offrire lo spazio di archiviazione condiviso dalle applicazioni, spesso indicato anche come “unità di archiviazione esterna condivisa”, “Spazio di archiviazione condiviso delle applicazioni” o tramite il percorso Linux “/sdcard” su cui è montato.
  • [C-0-2] DEVE essere configurato con l'archiviazione condivisa montata per impostazione predefinita, ovvero "pronta all'uso", indipendentemente dal fatto che l'archiviazione sia implementata su un componente di archiviazione interno o su un supporto di archiviazione rimovibile (ad esempio, lo slot per schede Secure Digital).
  • [C-0-3] DEVE montare lo spazio di archiviazione condiviso dell'applicazione direttamente sul percorso Linux sdcard o includere un link simbolico Linux da sdcard all'effettivo punto di montaggio.
  • [C-0-4] DEVE applicare in modo forzato l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE a questo spazio di archiviazione condiviso, come documentato nell'SDK.
  • [C-0-5] DEVE attivare l'archiviazione con ambito per impostazione predefinita per tutte le app che hanno come target il livello API 29 o versioni successive, tranne che nei seguenti casi:
    • Quando l'app è stata installata prima dell'upgrade del dispositivo al livello API 29, indipendentemente dall'API target dell'app.
    • quando l'app ha richiesto android:requestLegacyExternalStorage="true" nel file manifest.
    • quando all'app viene concessa l'autorizzazione android.permission.WRITE_MEDIA_STORAGE.
  • [C-0-6] DEVE imporre che le app con archiviazione con ambito attivata non abbiano accesso diretto al file system ai file al di fuori delle directory specifiche dell'applicazione, come restituito dai metodi dell'API Context come i metodi Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs() e Context.getObbDirs().
  • [C-0-7] DEVE oscurare i metadati sulla posizione, ad esempio i tag GPS Exif, memorizzati nei file multimediali quando questi file sono accessibili tramite MediaStore, tranne quando l'app chiamante dispone dell'autorizzazione ACCESS_MEDIA_LOCATION.

Le implementazioni dei dispositivi POSSONO soddisfare i requisiti sopra indicati utilizzando uno dei seguenti elementi:

  • Dispositivo di archiviazione rimovibile accessibile all'utente, ad esempio uno slot per schede SD (Secure Digital).
  • Una parte dello spazio di archiviazione interno (non rimovibile) implementato nell'Android Open Source Project (AOSP).

Se le implementazioni dei dispositivi utilizzano l'archiviazione rimovibile per soddisfare i requisiti di cui sopra, questi:

  • [C-1-1] DEVE implementare un avviso popup o un popup all'interfaccia utente che avvisa l'utente quando nello slot non è inserito un supporto di archiviazione.
  • [C-1-2] DEVE includere un supporto di archiviazione in formato FAT (ad esempio, una scheda SD) oppure indicare sulla confezione e altro materiale disponibile al momento dell'acquisto che il supporto di archiviazione deve essere acquistato separatamente.

Se le implementazioni del dispositivo utilizzano una parte dello spazio di archiviazione non rimovibile per soddisfare i requisiti di cui sopra, questi:

  • DEVE 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 includono più percorsi di archiviazione condivisa (ad esempio sia uno slot per scheda SD sia una memoria interna condivisa), questi:

  • [C-2-1] DEVE consentire solo alle applicazioni Android preinstallate e con privilegi che dispongono dell'autorizzazione WRITE_MEDIA_STORAGE di scrivere nella memoria esterna secondaria, tranne durante la scrittura nelle directory specifiche del pacchetto o all'interno dell'elemento URI restituito attivando l'intent ACTION_OPEN_DOCUMENT_TREE.
  • [C-2-2] DEVE richiedere che l'accesso diretto associato all'autorizzazione android.permission.WRITE_MEDIA_STORAGE venga concesso solo alle app visibili all'utente quando viene concessa anche l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE.
  • [SR] VIVAMENTE CONSIGLIATO che le app per Android preinstallate e con privilegi utilizzino API pubbliche come MediaStore per interagire con i dispositivi di archiviazione, invece di fare affidamento sull'accesso diretto concesso da android.permission.WRITE_MEDIA_STORAGE.

Se le implementazioni del dispositivo hanno una porta USB con supporto della modalità periferica USB:

  • [C-3-1] DEVE fornire un meccanismo per accedere ai dati sulla memoria condivisa dell'applicazione da un computer host.
  • DEVONO esporre in modo trasparente i contenuti di entrambi i percorsi di archiviazione tramite il servizio di scansione dei contenuti multimediali di Android e android.provider.MediaStore.
  • POSSONO utilizzare un archivio di massa USB, ma DEVI usare Media Transfer Protocol per soddisfare questo requisito.

Se le implementazioni del dispositivo hanno una porta USB con modalità periferica USB e supportano Media Transfer Protocol, questi:

  • DEVE essere compatibile con l'host Android MTP di riferimento, Android File Transfer.
  • DEVI segnalare una classe di dispositivi USB pari a 0x00.
  • DEVI segnalare un nome di interfaccia USB di "MTP".

7.6.3. Spazio di archiviazione utilizzabile

Se si prevede che il dispositivo sia mobile a differenza della televisione, le implementazioni dei dispositivi sono:

  • [SR] VIVAMENTE CONSIGLIATO di implementare lo spazio di archiviazione adottabile in una posizione stabile a lungo termine, poiché la disconnessione accidentale può causare la perdita/il danneggiamento dei dati.

Se la porta del dispositivo di archiviazione rimovibile si trova in un luogo stabile a lungo termine, ad esempio all'interno del vano batterie o di un'altra copertura protettiva, le implementazioni del dispositivo saranno:

7.7 USB

Se le implementazioni dei dispositivi hanno una porta USB:

  • DEVE 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 collegabile a un host USB dotato di porta USB standard di tipo A o C.
  • [C-1-2] DEVE segnalare il valore corretto di iSerialNumber nel descrittore del dispositivo standard USB tramite android.os.Build.SERIAL.
  • [C-1-3] DEVE rilevare i caricabatterie da 1,5 A e 3,0 A in base allo standard di resistenza di tipo C e DEVE rilevare eventuali cambiamenti nella pubblicità se supportano USB di tipo C.
  • [SR] La porta DEVE usare il fattore di forma USB micro-B, micro-AB o Tipo-C. I dispositivi Android nuovi ed esistenti sono VIVAMENTE CONSIGLIATI di soddisfare questi requisiti in modo che possano eseguire l'upgrade alle future release della piattaforma.
  • [SR] La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o abilitare la rotazione dello schermo del software per tutte le app (inclusa la schermata Home), in modo che il display venga mostrato correttamente quando il dispositivo è orientato con la porta in basso. I dispositivi Android nuovi ed esistenti sono VIVAMENTE CONSIGLIATI di soddisfare questi requisiti in modo che possano eseguire l'upgrade a release future della piattaforma.
  • [SR] DEVE implementare il supporto per assorbire 1,5 A di corrente durante il segnale acustico e il traffico HS, come specificato nella specifica per la ricarica della batteria USB, revisione 1.2. I dispositivi Android nuovi ed esistenti sono VIVAMENTE CONSIGLIATI di soddisfare questi requisiti in modo che possano eseguire l'upgrade alle future release della piattaforma.
  • [SR] VIVAMENTE CONSIGLIATO di non supportare metodi di ricarica proprietari che modificano la tensione Vbus oltre i livelli predefiniti o alterano i ruoli sink/source in quanto tali potrebbero causare problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard USB Power Delivery. Anche se questa opzione è definita "FORTEMENTE CONSIGLIATA", nelle future versioni di Android potremmo OBBLIGARE tutti i dispositivi di tipo C per il supporto della completa interoperabilità con i caricabatterie standard di tipo C.
  • [SR] VIVAMENTE CONSIGLIATO per supportare la funzionalità Power Delivery per lo scambio di dati e alimentazione quando supporta le modalità USB di tipo C e host USB.
  • DOVREBBE supportare la funzionalità Power Delivery per la ricarica ad alta tensione e il supporto di modalità alternative come il display out.
  • DEVI implementare l'API e la specifica Android Open Accessory (AOA) come documentato nella documentazione dell'SDK Android.

Se le implementazioni del dispositivo includono una porta USB e implementano la specifica AOA:

  • [C-2-1] DEVE dichiarare il supporto per la funzionalità hardware android.hardware.usb.accessory.
  • [C-2-2] La classe di archiviazione di massa USB DEVE includere la stringa "android" alla fine della descrizione dell'interfaccia iInterface stringa dell'archiviazione di massa USB.

7.7.2. Modalità host USB

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host:

  • [C-1-1] DEVE implementare l'API Android USB host come documentato nell'SDK Android e 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 spedire con cavi che ne adattano una porta proprietaria sul dispositivo a una porta USB type-C standard (dispositivo USB Type-C).
    • Avere un dispositivo di tipo A integrato o dotato di cavi che adattano una porta proprietaria sul dispositivo a una porta USB tipo A standard.
    • Avere una porta micro-AB sul dispositivo, che DEVE essere spedita con un cavo adattato a una porta di tipo A standard.
  • [C-1-3] NON DEVE essere fornito con un adattatore che converte le porte USB di tipo A o micro-AB in una porta di tipo C (presa).
  • [C-SR] Ti consigliamo vivamente di implementare la classe audio USB come documentato nella documentazione dell'SDK Android.
  • DEVE supportare la ricarica del dispositivo periferico USB connesso in modalità host; pubblicizzando una corrente di fonte di almeno 1,5 A come specificato nella sezione Parametri di terminazione della Revisione 1.2 della specifica del cavo e del connettore USB Type-C per i connettori USB Type-C o dell'intervallo della corrente di uscita della porta di ricarica downstream(CDP), come specificato nella sezione Specifiche per la ricarica delle batterie micro USB, revisione 1.2 per i connettori di ricarica micro-AB.
  • DOVREBBE implementare e supportare gli standard USB Type-C.

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host e la classe audio USB, questi:

  • [C-2-1] DEVE supportare la classe USB HID.
  • [C-2-2] DEVE supportare il rilevamento e la mappatura dei seguenti campi di dati HID specificati nelle Tabelle di utilizzo dell'HID USB e nella Richiesta di utilizzo di Voice Command alle costanti KeyEvent come indicato di seguito:
    • Pagina utilizzo (0xC) ID utilizzo (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Pagina di utilizzo (0xC) ID utilizzo (0x0E9): KEYCODE_VOLUME_UP
    • ID di utilizzo della pagina di utilizzo (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
    • Pagina di utilizzo (0xC) ID utilizzo (0x0CF): KEYCODE_VOICE_ASSIST

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host e il framework Storage Access Framework (SAF), questi:

  • [C-3-1] DEVE riconoscere i dispositivi MTP (Media Transfer Protocol) collegati da remoto e rendere i relativi contenuti accessibili tramite gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT.

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità host e USB Type-C:

  • [C-4-1] DEVE implementare la funzionalità Dual Role Port come definita dalla specifica USB Type-C (sezione 4.5.1.3.3).
  • [SR] VIVAMENTE CONSIGLIATA per supportare DisplayPort, DOVREBBE supportare USB SuperSpeed Data Rates e sono VIVAMENTE CONSIGLIATI per supportare Power Delivery per lo scambio di dati e ruoli di alimentazione.
  • [SR] VIVAMENTE CONSIGLIATO di NON supportare la modalità accessorio adattatore audio come descritto nell'appendice A della revisione 1.2 della specifica del cavo e del connettore USB Type-C.
  • DEVI implementare il modello Prova.* più appropriato per il fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DOVREBBE implementare il modello provare.SNK.

7.8 Audio

7.8.1. Microfono

Se le implementazioni dei dispositivi includono un microfono, questi:

  • [C-1-1] DEVE segnalare la costante della funzionalità android.hardware.microphone.
  • [C-1-2] DEVE soddisfare i requisiti per la registrazione audio di cui alla sezione 5.4.
  • [C-1-3] DEVE soddisfare i requisiti di latenza audio di cui alla sezione 5.6.
  • [SR] È VIVAMENTE CONSIGLIATO di supportare la registrazione quasi a ultrasuoni, come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono un microfono:

  • [C-2-1] NON DEVE segnalare la costante della funzionalità android.hardware.microphone.
  • [C-2-2] DEVE implementare l'API Registrazione audio almeno in modalità autonoma, come spiegato nella sezione 7.

7.8.2. Uscita audio

Se le implementazioni del dispositivo includono un altoparlante 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, questi:

  • [C-1-1] DEVE segnalare la costante della funzionalità android.hardware.audio.output.
  • [C-1-2] DEVE soddisfare i requisiti per la riproduzione audio di cui alla sezione 5.5.
  • [C-1-3] DEVE soddisfare i requisiti di latenza audio di cui alla sezione 5.6.
  • [SR] VIVAMENTE CONSIGLIATA per supportare la riproduzione a ultrasuoni, come descritto nella sezione 7.8.3.

Se le implementazioni del dispositivo non includono un altoparlante o una porta di uscita audio:

  • [C-2-1] NON DEVE segnalare la funzionalità android.hardware.audio.output.
  • [C-2-2] DEVE implementare le API relative all'output audio almeno in modalità autonoma.

Ai fini di questa sezione, per "porta di uscita" si intende un'interfaccia fisica, ad esempio una porta jack audio da 3, 5 mm oppure una porta in modalità host USB o HDMI con classe audio USB. Il supporto dell'uscita audio su protocolli basati su radio come Bluetooth, Wi-Fi o rete mobile non è idoneo come inclusione di una "porta di uscita".

7.8.2.1. Porte audio analogiche

Per essere compatibili con cuffie e altri accessori audio utilizzando il connettore audio da 3, 5 mm nell'ecosistema Android, se le implementazioni dei dispositivi includono una o più porte audio analogiche:

  • [C-SR] È VIVAMENTE CONSIGLIATO di includere almeno una delle porte audio come 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, questi:

  • [C-1-1] DEVE supportare la riproduzione audio su cuffie stereo e cuffie stereo dotate di microfono.
  • [C-1-2] DEVE supportare i connettori audio TRRS con l'ordine di pin-out CTIA.
  • [C-1-3] DEVE supportare il rilevamento e la mappatura sui codici chiave per i seguenti 3 intervalli di impedenza equivalente tra il microfono e i conduttori di terra sulla spina audio:
    • 70 ohm o meno: KEYCODE_HEADSETHOOK
    • 210-290 ohm: KEYCODE_VOLUME_UP
    • 360-680 ohm: KEYCODE_VOLUME_DOWN
  • [C-1-4] DEVE attivare ACTION_HEADSET_PLUG su un inserto, ma solo dopo che tutti i contatti sulla spina toccano i segmenti pertinenti sul jack.
  • [C-1-5] DEVE essere in grado di pilotare almeno 150 mV ± 10% della tensione di uscita su un'impedenza di altoparlanti da 32 ohm.
  • [C-1-6] DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V ~ 2,9 V.
  • [C-1-7] DEVE rilevare e mappare il codice della chiave per il seguente intervallo di impedenza equivalente tra il microfono e i conduttori di terra sulla spina audio:
    • 110-180 ohm: KEYCODE_VOICE_ASSIST
  • [C-SR] È VIVAMENTE CONSIGLIATO di supportare le prese audio con l'ordine di pin-out OMTP.
  • [C-SR] È VIVAMENTE CONSIGLIATO per il supporto della registrazione audio da cuffie stereo con microfono.

Se le implementazioni del dispositivo hanno un jack audio da 3,5 mm a 4 conduttori, supportano un microfono e trasmettono android.intent.action.HEADSET_PLUG con il microfono del valore aggiuntivo impostato su 1, questi:

  • [C-2-1] DEVE supportare il rilevamento del microfono sull'accessorio audio collegato.
7.8.2.2. Porte audio digitali

Per essere compatibili con le cuffie e altri accessori audio, utilizzano connettori USB-C e l'implementazione (classe audio USB) nell'ecosistema Android, come definito nelle specifiche delle cuffie USB USB di Android.

Consulta la Sezione 2.2.1 per i requisiti specifici del dispositivo.

7.8.3. Quasi a ultrasuoni

L'audio a ultrasuoni è la banda da 18,5 kHz a 20 kHz.

Implementazioni dei dispositivi:

  • DEVE segnalare correttamente il supporto della funzionalità audio quasi a ultrasuoni 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 DEVE essere non più di 15 dB al di sotto della risposta a 2 kHz.
  • [C-1-2] Il rapporto tra segnale e rumore non ponderato del microfono compreso tra 18,5 kHz e 20 kHz per un tono di 19 kHz a -26 dBFS DEVE essere non inferiore a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND è "true":

  • [C-2-1] La risposta media dell'altoparlante nella banda 18,5 kHz - 20 kHz DEVE essere non inferiore a 40 dB al di sotto della risposta a 2 kHz.

7.8.4. Integrità del segnale

Implementazioni dei dispositivi:

  • DEVE fornire un percorso del segnale audio privo di glitch per gli stream di ingresso e di uscita sui dispositivi portatili, come definito da zero glitch misurati durante un test della durata di un minuto per percorso. Esegui il test con [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) "Automated Glitch Test".

Il test richiede un dongle di loopback audio, utilizzato direttamente in un jack da 3,5 mm e/o in combinazione con un adattatore da USB-C a 3,5 mm. Tutte le porte di uscita audio DEVONO essere testate.

OboeTester al momento supporta i percorsi AAudio, quindi le seguenti combinazioni DEVONO essere testate per rilevare eventuali glitch usando AAudio:

Modalità prestazioni Condivisione Frequenza di campionamento in uscita Occasionalmente Margini di uscita
BASSO_LATEENZA ESCLUSIVA NON SPECIFICATO 1 2
BASSO_LATEENZA ESCLUSIVA NON SPECIFICATO 2 1
BASSO_LATEENZA CONDIVISO NON SPECIFICATO 1 2
BASSO_LATEENZA CONDIVISO NON SPECIFICATO 2 1
NESSUNO CONDIVISO 48000 1 2
NESSUNO CONDIVISO 48000 2 1
NESSUNO CONDIVISO 44100 1 2
NESSUNO CONDIVISO 44100 2 1
NESSUNO CONDIVISO 16000 1 2
NESSUNO CONDIVISO 16000 2 1

Uno stream affidabile DEVE soddisfare i seguenti criteri per il rapporto segnale-rumore (SNR) e la distorsione armonica totale (THD) per il seno a 2000 Hz.

Trasduttore THD SNR (SNR)
altoparlante principale integrato, misurato utilizzando un microfono esterno di riferimento < 3,0% >= 50 dB
microfono principale integrato, misurato utilizzando un altoparlante esterno di riferimento < 3,0% >= 50 dB
jack analogici da 3,5 mm integrati, testato con adattatore di loopback < 1% >= 60 dB
Adattatori USB forniti con lo smartphone, testati utilizzando l'adattatore di loopback < 1,0% >= 60 dB

7.9 Realtà virtuale

Android include API e strutture per realizzare applicazioni di "realtà virtuale" (VR), che includono esperienze VR di alta qualità sui dispositivi mobili. Le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in dettaglio in questa sezione.

7.9.1. Modalità realtà virtuale

Android include il supporto della modalità VR, una funzionalità che gestisce il rendering stereoscopico delle notifiche e disattiva i componenti dell'interfaccia utente del sistema monoculare mentre un'applicazione VR è incentrata sull'utente.

7.9.2. Modalità realtà virtuale - Alte prestazioni

Se le implementazioni dei dispositivi supportano la modalità VR:

  • [C-1-1] DEVE avere almeno 2 core fisici.
  • [C-1-2] DEVE dichiarare la funzionalità android.hardware.vr.high_performance.
  • [C-1-3] DEVE supportare la modalità di prestazioni sostenute.
  • [C-1-4] DEVE supportare OpenGL ES 3.2.
  • [C-1-5] DEVE supportare android.hardware.vulkan.level 0.
  • DOVREBBE supportare android.hardware.vulkan.level 1 o versioni successive.
  • [C-1-6] DEVE implementare EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace ed esporre le estensioni nell'elenco delle estensioni EGL disponibili.
  • [C-1-8] DEVE implementare GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
  • [C-SR] È VIVAMENTE CONSIGLIATO di implementare GL_EXT_external_buffer, GL_EXT_EGL_image_array e di esporre le estensioni nell'elenco delle estensioni GL disponibili.
  • [C-SR] CONSIGLIATE VIVAMENTE per il supporto di Vulkan 1.1.
  • [C-SR] È VIVAMENTE CONSIGLIATO di implementare VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image e di esporlo nell'elenco delle estensioni Vulkan disponibili.
  • [C-SR] È VIVAMENTE CONSIGLIATO di 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 front buffer condiviso in modo che il rendering a occhio alternato dei contenuti VR a 60 fps con due contesti di rendering venga visualizzato senza artefatti di strappo 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 AHardwareBuffer con qualsiasi combinazione dei flag di utilizzo AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE e 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] È VIVAMENTE CONSIGLIATO per supportare l'allocazione di AHardwareBuffer con più di un livello e flag e formati specificati in C-1-10.
  • [C-1-11] DEVE supportare la decodifica H.264 almeno 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 10 Mbps a 1920 x 10 Mbps o 2 istanze di 1920 x 10 Mbps a 1920 x 10 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 DEVE essere in grado di decodificare 3840 x 2160 a 30 fps-20 fps a 10 fps-20 Mbps istanze equivalenti a 10 fps-20 Mbps (10 Mbps equivalenti a 10 Mbps).
  • [C-1-13] DEVE supportare l'API HardwarePropertiesManager.getDeviceTemperatures e restituire valori precisi per la temperatura cutanea.
  • [C-1-14] DEVE avere uno schermo incorporato e la sua risoluzione DEVE essere di almeno 1920 x 1080.
  • [C-SR] CONSIGLIATO VIVAMENTE una risoluzione del display di almeno 2560 x 1440.
  • [C-1-15] Il display DEVE aggiornarsi di almeno 60 Hz in modalità VR.
  • [C-1-17] Il display DEVE supportare una modalità a bassa persistenza con una persistenza ≤ 5 millisecondi. Per persistenza si intende il tempo durante il quale 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 indicare 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] È VIVAMENTE CONSIGLIATO di 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] È VIVAMENTE CONSIGLIATO per il supporto della funzionalità android.hardware.sensor.hifi_sensors.
  • [C-1-22] DEVE avere una latenza end-to-end tra movimenti e fotoni non superiore a 28 millisecondi.
  • [C-SR] È VIVAMENTE CONSIGLIATO avere una latenza end-to-end tra movimenti e fotoni non superiore a 20 millisecondi.
  • [C-1-23] DEVE avere un rapporto del primo fotogramma, ovvero il rapporto tra la luminosità dei pixel sul primo fotogramma dopo una transizione dal nero al bianco e la luminosità dei pixel bianchi in stato stabile, pari ad almeno l'85%.
  • [C-SR] È VIVAMENTE CONSIGLIATO avere una percentuale di primo fotogramma di almeno il 90%.
  • POTREBBE fornire un core esclusivo all'applicazione in primo piano e supportare l'API Process.getExclusiveCores per restituire i numeri dei core CPU esclusivi dell'applicazione in primo piano.

Se è supportato un core esclusivo, il core:

  • [C-2-1] Non DEVE consentire qualsiasi altro processo dello spazio utente per l'esecuzione su di esso (tranne i driver di periferica utilizzati dall'applicazione), ma PUÒ consentire alcuni processi del kernel per essere eseguiti se necessario.

8. Prestazioni e potenza

Alcuni criteri minimi di potenza e prestazioni sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di base che gli sviluppatori avrebbero quando sviluppano un'app.

8.1. Coerenza dell'esperienza utente

È possibile fornire all'utente finale un'interfaccia utente semplice se esistono 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 delle attività, come descritto nella sezione 2.

8.2. Prestazioni accesso file I/O

Fornire una base comune per prestazioni di accesso ai file coerenti nell'archiviazione dei dati privati dell'applicazione (partizione /data) consente agli sviluppatori di app di stabilire un'aspettativa adeguata che aiuterebbe la progettazione 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 da 256 MB con un buffer di scrittura da 10 MB.
  • Prestazioni di scrittura casuale. Misurato scrivendo un file da 256 MB utilizzando un buffer di scrittura da 4 KB.
  • Prestazioni di lettura sequenziale. Misurato leggendo un file da 256 MB usando un buffer di scrittura da 10 MB.
  • Prestazioni di lettura casuale. Misurato leggendo un file da 256 MB utilizzando un buffer di scrittura da 4 KB.

8.3. Modalità di risparmio energetico

Se le implementazioni dei dispositivi includono funzionalità per migliorare la gestione dell'alimentazione dei dispositivi incluse in AOSP o estendere le funzionalità incluse in AOSP, queste:

  • [C-1-1] NON DEVE discostarsi dall'implementazione di AOSP per gli algoritmi di attivazione, manutenzione, riattivazione e l'uso delle impostazioni di sistema globali delle modalità di risparmio energetico di App Standby e Sospensione.
  • [C-1-2] NON DEVE discostarsi dall'implementazione AOSP per l'uso di impostazioni globali al fine di gestire la limitazione dei job, degli allarmi e della rete per le app in ogni bucket per l'utilizzo in standby delle app.
  • [C-1-3] NON DEVE discostarsi dall'implementazione di AOSP per il numero di bucket di standby dell'app utilizzati per lo standby delle app.
  • [C-1-4] DEVE implementare i bucket di standby delle app e la modalità Sospensione come descritto in Gestione alimentazione.
  • [C-1-5] DEVE restituire true per PowerManager.isPowerSaveMode() quando il dispositivo è in modalità di risparmio energetico.
  • [C-SR] È VIVAMENTE CONSIGLIATO di fornire all'utente l'autorizzazione ad attivare e disattivare la funzionalità di risparmio energetico.
  • [C-SR] È VIVAMENTE CONSIGLIATO per fornire all'utente l'autorizzazione a visualizzare tutte le app esenti dalle modalità di risparmio energetico di App Standby e Sospensione.

Oltre alle modalità di risparmio energetico, le implementazioni dei dispositivi Android POSSONO implementare uno o tutti i quattro stati di alimentazione a riposo definiti dalla configurazione avanzata e dall'interfaccia di alimentazione (ACPI).

Se le implementazioni del dispositivo implementano gli stati di alimentazione S4 come definito dall'ACPI:

  • [C-1-1] DEVE entrare in questo stato solo dopo che l'utente ha intrapreso un'azione esplicita per mettere il dispositivo in stato di inattività (ad esempio chiudendo un coperchio che fa fisicamente parte del dispositivo oppure spegnendo un veicolo o un televisore) e prima che l'utente lo riattivi (ad esempio aprendo il coperchio o riaccendendo il veicolo o il televisore).

Se le implementazioni del dispositivo implementano gli stati di alimentazione S3 come definito dall'ACPI:

  • [C-2-1] DEVE soddisfare il precedente C-1-1, oppure DEVE entrare nello stato S3 solo quando le applicazioni di terze parti non hanno bisogno delle risorse di sistema (ad esempio, lo schermo, CPU).

    Al contrario, DEVE uscire dallo stato S3 quando applicazioni di terze parti richiedono le risorse di sistema, come descritto in questo SDK.

    Ad esempio, anche se le applicazioni di terze parti richiedono di mantenere lo schermo attivo fino a FLAG_KEEP_SCREEN_ON o di mantenere la CPU in esecuzione fino al giorno 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 attivare lo stato inattivo del dispositivo. Al contrario, nel momento in cui viene attivata un'attività implementata da app di terze parti tramite JobScheduler o Firebase Cloud Messaging viene pubblicata in app di terze parti, il dispositivo DEVE uscire dallo stato S3, a meno che l'utente non abbia attivato lo stato inattivo. Non si tratta di esempi completi e AOSP implementa ampi segnali di riattivazione che innescano una riattivazione da questo stato.

8.4. Contabilità consumo energetico

Una contabilità e un report più accurati sul consumo energetico forniscono allo sviluppatore di app sia gli incentivi sia gli strumenti per ottimizzare il modello di consumo energetico dell'applicazione.

Implementazioni dei dispositivi:

  • [SR] VIVAMENTE CONSIGLIATO di fornire un profilo di alimentazione per componente che definisca il valore del consumo attuale per ciascun componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
  • [SR] VIVAMENTE CONSIGLIATA di indicare tutti i valori di consumo energetico in milliampere-ora (mAh).
  • [SR] VIVAMENTE CONSIGLIATO di segnalare il consumo di energia della CPU per ogni UID di processo. Il progetto open source Android soddisfa il requisito tramite l'implementazione del modulo kernel uid_cputime.
  • [SR] VIVAMENTE CONSIGLIATO di rendere disponibile agli sviluppatori dell'app questo consumo di energia tramite il comando shell adb shell dumpsys batterystats.
  • DEVE essere attribuito al componente hardware stesso se non è in grado di attribuire l'utilizzo dell'energia del componente hardware a un'applicazione.

8.5. Prestazioni costanti

Le prestazioni possono variare notevolmente per le app a lunga esecuzione ad alte prestazioni, a causa delle altre app in esecuzione in background o della limitazione della CPU dovuta ai limiti di temperatura. Android include interfacce programmatiche che, quando il dispositivo è in grado di funzionare, l'applicazione in primo piano principale può richiedere al sistema di ottimizzare l'allocazione delle risorse per risolvere queste fluttuazioni.

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi registrano il supporto della modalità Rendimento sostenuto:

  • [C-1-1] DEVE fornire all'applicazione in primo piano principale un livello costante di prestazioni 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 del dispositivo includono due o più core CPU:

  • DEVE fornire almeno un core esclusivo che possa essere riservato dall'applicazione in primo piano principale.

Se le implementazioni dei dispositivi supportano la prenotazione di un core esclusivo per l'applicazione in primo piano principale:

  • [C-2-1] DEVE segnalare tramite il metodo API di Process.getExclusiveCores() gli ID dei core esclusivi che possono essere prenotati dall'applicazione in primo piano principale.
  • [C-2-2] DEVE non consentire alcun processo dello spazio utente ad eccezione dei driver di periferica utilizzati dall'applicazione per essere eseguiti sui core esclusivi, ma POTREBBE consentire alcuni processi del kernel per essere eseguiti se necessario.

Se le implementazioni del dispositivo 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 per sicurezza e autorizzazioni nelle API della documentazione per gli sviluppatori Android.

  • [C-0-2] DEVE supportare l'installazione di applicazioni autofirmate 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 che seguono.

9.1. Autorizzazioni

Implementazioni dei dispositivi:

  • [C-0-1] DEVE supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android. In particolare, DEVONO applicare in modo forzato ogni autorizzazione definita come descritto nella documentazione dell'SDK; nessuna autorizzazione può essere omessa, modificata o ignorata.

  • POTREBBE aggiungere ulteriori autorizzazioni, a condizione che le nuove stringhe dell'ID autorizzazione non si trovino nello spazio dei nomi android.\*.

  • [C-0-2] Le autorizzazioni con protectionLevel di PROTECTION_FLAG_PRIVILEGED DEVONO essere concesse soltanto alle app preinstallate nei percorsi con privilegi dell'immagine di sistema e all'interno del sottoinsieme delle autorizzazioni esplicitamente incluse nella lista consentita 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 con privilegi.

Le autorizzazioni con un livello di protezione pericoloso sono autorizzazioni di runtime. Le applicazioni con targetSdkVersion > 22 lo richiedono in fase di runtime.

Implementazioni dei dispositivi:

  • [C-0-3] DEVE mostrare un'interfaccia dedicata all'utente per decidere se concedere le autorizzazioni di runtime richieste e anche fornire un'interfaccia per la gestione delle autorizzazioni di runtime.
  • [C-0-4] DEVE avere una sola implementazione per entrambe le interfacce utente.
  • [C-0-5] NON DEVE concedere autorizzazioni di runtime alle app preinstallate, a meno che:
    • Il consenso dell'utente può essere ottenuto prima che l'applicazione lo utilizzi.
    • Le autorizzazioni di runtime sono associate a un pattern di intent per il quale l'applicazione preinstallata è impostata come gestore predefinito.
  • [C-0-6] DEVE concedere l'autorizzazione android.permission.RECOVER_KEYSTORE solo alle app di sistema che registrano un Recovery Agent protetto correttamente. Per agente di ripristino adeguatamente protetto si intende un agente software sul dispositivo che si sincronizza con uno spazio di archiviazione remoto esterno al dispositivo, dotato di hardware sicuro con protezione equivalente o più potente di quanto descritto nel servizio Google Cloud Key Vault per prevenire attacchi di forza bruta al fattore di conoscenza della schermata di blocco.

Implementazioni dei dispositivi:

  • [C-0-7] DEVE rispettare le proprietà delle autorizzazioni 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. Tali 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 esempio SSID, BSSID, ID cella, scansioni Bluetooth o posizione della rete a cui è connesso il dispositivo).
    • Attività fisica dell'utente o classificazione dell'attività fisica.

In particolare, le implementazioni dei dispositivi:

  • [C-0-8] DEVE ottenere il consenso degli utenti 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 dispone di autorizzazioni sufficienti, come descritto nell'SDK. Ad esempio, TelephonyManager#getServiceState richiede android.permission.ACCESS_FINE_LOCATION.

Le autorizzazioni possono essere contrassegnate come limitate, che ne alterano 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 un ruolo associato alle autorizzazioni hardRestricted a un'app.
    • Il programma di installazione concede hardRestricted a un'app.
    • A un'app viene concesso il hardRestricted su una versione precedente di Android.

  • [C-0-11] Le app con autorizzazione softRestricted DEVONO avere solo accesso limitato e NON DEVONO ottenere l'accesso completo finché non vengono aggiunte a una lista consentita come descritto nell'SDK, dove viene definito l'accesso completo e limitato per ciascuna autorizzazione softRestricted (ad esempio, WRITE_EXTERNAL_STORAGE e READ_EXTERNAL_STORAGE).

Se le implementazioni dei dispositivi includono un'app preinstallata o vuoi consentire ad app di terze parti di accedere alle statistiche sull'utilizzo, queste:

  • [SR] sono VIVAMENTE CONSIGLIATI fornire un meccanismo accessibile dall'utente per concedere o revocare l'accesso alle statistiche sull'utilizzo in risposta all'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS per le app che dichiarano l'autorizzazione android.permission.PACKAGE_USAGE_STATS.

Se le implementazioni dei dispositivi intendono impedire a qualsiasi app, incluse le app preinstallate, di accedere alle statistiche sull'utilizzo:

  • [C-1-1] DEVE avere comunque un'attività che gestisca il pattern dell'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, ma DEVE implementarla come un sistema autonomo, ossia avere un comportamento equivalente a quello in cui l'utente viene rifiutato.

9.2. UID e isolamento dei processi

Implementazioni dei dispositivi:

  • [C-0-1] DEVE supportare il modello sandbox dell'applicazione Android, in cui ogni applicazione viene eseguita come UID Unixstyle univoco e in un processo separato.
  • [C-0-2] DEVE supportare l'esecuzione di più applicazioni con lo stesso ID utente Linux, a condizione che le applicazioni siano firmate e create correttamente, come definito nel riferimento 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 autorizzazione di Android, anche se includono ambienti di runtime che eseguono applicazioni utilizzando altri software o tecnologie diversi dal Dalvik Executable Format o dal codice nativo. In altre parole:

  • [C-0-1] I runtime alternativi DEVONO essere essi stessi applicazioni Android e rispettare il modello di sicurezza standard di Android, come descritto altrove nella sezione 9.

  • [C-0-2] NON DEVE essere concesso ai runtime alternativi l'accesso a 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 usare funzionalità protette da autorizzazioni Android limitate alle applicazioni di sistema.

  • [C-0-4] I runtime alternativi DEVONO rispettare il modello sandbox di Android e le applicazioni installate che utilizzano un runtime alternativo NON DEVONO riutilizzare la sandbox di qualsiasi altra app installata sul dispositivo, a meno che tramite i meccanismi Android standard dell'ID utente condiviso e del certificato di firma.

  • [C-0-5] I runtime alternativi NON DEVONO avviarsi con, concedere o avere l'accesso alle sandbox corrispondenti ad altre applicazioni Android.

  • [C-0-6] I runtime alternativi NON DEVONO essere avviati con, essere concessi o concedere ad altre applicazioni privilegi del super user (root) o di qualsiasi altro ID utente.

  • [C-0-7] Se 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 di 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 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 sarà in grado di accedere a tale risorsa.

  • [C-0-10] Quando l'ambiente di runtime non registra le capacità dell'applicazione in questo modo, l'ambiente di runtime DEVE elencare tutte le autorizzazioni di cui dispone il runtime durante l'installazione di qualsiasi applicazione che utilizza tale runtime.

  • I runtime alternativi DEVONO installare le app tramite il PackageManager in sandbox Android separate (ID utente Linux e così via).

  • I runtime alternativi POTREBBERO fornire un'unica sandbox Android condivisa da tutte le applicazioni che utilizzano il runtime alternativo.

9.5 Supporto di più utenti

Android include il supporto per più utenti e per l'isolamento completo degli utenti.

  • Le implementazioni dei dispositivi POSSONO, ma NON DEVONO attivare la funzionalità multiutente se utilizzano supporti rimovibili come unità di archiviazione esterna principale.

Se le implementazioni dei dispositivi includono più utenti, questi:

  • [C-1-1] DEVE soddisfare i seguenti requisiti relativi all'assistenza 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 su sicurezza e autorizzazioni nelle API.
  • [C-1-3] DEVE avere directory di archiviazione delle applicazioni condivise e isolate (ovvero /sdcard) per ogni istanza utente.
  • [C-1-4] DEVE garantire che le applicazioni di proprietà di ed eseguite per conto di un determinato utente non possano elencare, leggere o scrivere nei file di proprietà di qualsiasi altro utente, anche se i dati di entrambi gli utenti sono archiviati sullo stesso volume o file system.
  • [C-1-5] DEVE crittografare i contenuti della scheda SD quando l'opzione Multiutente è abilitata utilizzando una chiave archiviata solo su supporti non rimovibili accessibili solo al sistema se le implementazioni dei dispositivi utilizzano supporti rimovibili per le API di archiviazione esterna. Dal momento che ciò renderà i contenuti illeggibili da parte di 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. I messaggi SMS premium sono messaggi inviati a un servizio registrato con un operatore che può comportare un addebito per l'utente.

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

  • [C-1-1] DEVE avvisare gli utenti prima di inviare un messaggio SMS a numeri identificati da espressioni regolari definite nel file /data/misc/sms/codes.xml del dispositivo. Il progetto open source Android a monte fornisce un'implementazione che soddisfa questo requisito.

9.7 Funzionalità per la sicurezza

Le implementazioni dei dispositivi DEVONO garantire la conformità con le funzioni di sicurezza sia nel kernel che nella piattaforma, come descritto di seguito.

Android Sandbox include funzionalità che utilizzano il sistema di controllo dell'accesso obbligatorio (MAC) di Linux (SELinux), la sandbox seccomp e altre funzionalità di sicurezza nel kernel Linux. Implementazioni dei dispositivi:

  • [C-0-1] DEVE mantenere la compatibilità con le applicazioni esistenti, anche se SELinux o qualsiasi altra funzionalità di sicurezza sono implementati al di sotto del framework Android.
  • [C-0-2] NON DEVE avere un'interfaccia utente visibile quando viene rilevata una violazione della sicurezza e bloccata con successo dalla funzionalità di sicurezza implementata al di sotto del framework Android, ma POTREBBE avere un'interfaccia utente visibile quando si verifica una violazione della sicurezza sbloccata che determina un exploit.
  • [C-0-3] NON DEVE rendere configurabili all'utente o allo sviluppatore di app SELinux o qualsiasi altra funzionalità di sicurezza implementata al di sotto del framework Android.
  • [C-0-4] NON DEVE consentire a un'applicazione che può influire su un'altra applicazione tramite un'API (ad esempio un'API di amministrazione del dispositivo) di configurare un criterio che interrompe la compatibilità.
  • [C-0-5] DEVE suddividere il framework multimediale in più processi in modo che sia possibile concedere in modo più limitato l'accesso a ogni processo come descritto nel sito del progetto open source Android.
  • [C-0-6] DEVE implementare un meccanismo di sandboxing delle applicazioni kernel che permetta di filtrare le chiamate di sistema utilizzando un criterio configurabile da programmi multithread. Il progetto open source Android upstream soddisfa questo requisito mediante l'abilitazione di 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à del kernel e di autoprotezione sono parte integrante della sicurezza di Android. Implementazioni dei dispositivi:

  • [C-0-7] DEVE implementare meccanismi di protezione dall'overflow del buffer dello stack del kernel. Esempi di questi meccanismi sono CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
  • [C-0-8] DEVE implementare rigide protezioni della memoria del kernel in cui il codice eseguibile è di sola lettura, i dati di sola lettura non sono eseguibili e non scrivibili e i dati scrivibili non sono eseguibili (ad esempio, CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] DEVE 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) su dispositivi originariamente distribuiti con livello API 28 o superiore.
  • [C-0-10] NON DEVE eseguire memoria dello spazio utente durante l'esecuzione in modalità kernel (ad es. hardware PX o emulata tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) su dispositivi originariamente forniti con livello API 28 o superiore.
  • [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 esempio, PAN hardware, o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) su dispositivi originariamente forniti con livello API 28 o superiore.
  • [C-0-12] DEVE implementare l'isolamento della tabella delle pagine del kernel se l'hardware è vulnerabile a CVE-2017-5754 su tutti i dispositivi originariamente forniti con livello API 28 o superiore (ad es. CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0).
  • [C-0-13] DEVE implementare il rafforzamento delle previsioni di rami se l'hardware è vulnerabile a CVE-2017-5715 su tutti i dispositivi originariamente forniti con livello API 28 o superiore (ad es. CONFIG_HARDEN_BRANCH_PREDICTOR).
  • [SR] VIVAMENTE CONSIGLIATO per mantenere i dati del kernel scritti solo durante l'inizializzazione, contrassegnati come di sola lettura dopo l'inizializzazione (ad es. __ro_after_init).

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

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

  • [C-SR] È VIVAMENTE CONSIGLIATO di non disattivare l'integrità del flusso di controllo (CFI), lo stack di chiamate shadow (SCS) o la sanificazione dell'overflow intero (IntSan) sui componenti in cui è abilitato.
  • [C-SR] È VIVAMENTE CONSIGLIATO di abilitare CFI, SCS e IntSan per eventuali componenti aggiuntivi dello spazio utente sensibili alla sicurezza, come spiegato in CFI e IntSan.

Se le implementazioni dei dispositivi utilizzano un kernel Linux:

  • [C-1-1] DEVE implementare SELinux.
  • [C-1-2] DEVE impostare SELinux sulla modalità di applicazione globale.
  • [C-1-3] DEVE configurare tutti i domini in modalità di applicazione forzata. Non sono consentiti domini in modalità permissiva, inclusi quelli specifici di un dispositivo/fornitore.
  • [C-1-4] NON DEVE modificare, omettere o sostituire le regole non consentite all'interno della cartella del sistema/sepolicy fornita nell'AOSP (Android Open Source Project) upstream e il criterio DEVE essere compilato con tutte le regole non consentite presenti, sia per i domini AOSP SELinux sia per i domini specifici del dispositivo/fornitore.
  • [C-1-5] DEVE eseguire applicazioni di terze parti destinate al livello API 28 o superiore nelle sandbox SELinux per applicazione con restrizioni SELinux per app sulla directory dei dati privati di ciascuna applicazione.
  • DEVE mantenere il criterio SELinux predefinito fornito nella cartella di sistema/sepolicy del progetto open source Android a monte e aggiungere ulteriormente a questo criterio solo per la 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 software di sistema, POSSONO essere esentate da questi requisiti.

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

  • [C-2-1] DEVE utilizzare un sistema di controllo dell'accesso obbligatorio equivalente a SELinux.

Android contiene diverse funzionalità di difesa in profondità fondamentali per la sicurezza del dispositivo.

9.8 Privacy

9.8.1. Cronologia di utilizzo

Android archivia la cronologia delle scelte dell'utente e la gestisce tramite UsageStatsManager.

Implementazioni dei dispositivi:

  • [C-0-1] DEVE conservare un periodo di conservazione ragionevole di tale cronologia utente.
  • [SR] È VIVAMENTE CONSIGLIATO di mantenere il periodo di conservazione di 14 giorni come configurato per impostazione predefinita nell'implementazione AOSP.

Android archivia gli eventi di sistema utilizzando gli identificatori StatsLog e gestisce questa cronologia tramite l'API StatsManager e l'API di sistema IncidentManager.

Implementazioni dei dispositivi:

  • [C-0-2] DEVE includere solo i campi contrassegnati con DEST_AUTOMATIC nel report sugli incidenti creato dalla classe dell'API di sistema IncidentManager.
  • [C-0-3] Non DEVE utilizzare gli identificatori di eventi di sistema per registrare eventi diversi da quelli descritti nei documenti relativi all'SDK StatsLog. Se gli eventi di sistema aggiuntivi vengono registrati, POSSONO utilizzare un identificatore atomico diverso nell'intervallo tra 100.000 e 200.000.

9.8.2. Registrazione in corso…

Implementazioni dei dispositivi:

  • [C-0-1] NON DEVE precaricare o distribuire immediatamente componenti software che inviano informazioni private dell'utente (ad es. sequenze di tasti, testo visualizzato sullo schermo, segnalazione di bug) dal dispositivo senza il consenso dell'utente o cancellare le notifiche in corso.

  • [C-0-2] DEVE mostrare e ottenere il consenso esplicito dell'utente che includa sostanzialmente lo stesso messaggio di AOSP ogni volta che la trasmissione dello schermo o la registrazione dello schermo vengono attivate tramite MediaProjection o API proprietarie. NON DEVE fornire agli utenti un'invito per disattivare la futura visualizzazione del consenso dell'utente.

  • [C-0-3] DEVE avere una notifica fissa per l'utente mentre è attiva la trasmissione o la registrazione dello schermo. AOSP soddisfa questo requisito mostrando un'icona di notifica fissa nella barra di stato.

Se le implementazioni dei dispositivi includono funzionalità nel sistema che acquisiscono i contenuti visualizzati sullo schermo e/o registrano lo stream audio riprodotto sul dispositivo in modo diverso tramite l'API di sistema ContentCaptureService o altri mezzi proprietari descritti nella Sezione 9.8.6 Acquisizione di contenuti, questi:

  • [C-1-1] DEVE disporre di una notifica fissa all'utente ogni volta che questa funzionalità viene attivata e l'acquisizione/registrazione è attiva.

Se le implementazioni del dispositivo includono un componente già attivo e in grado di registrare l'audio ambientale e/o di registrare l'audio riprodotto sul dispositivo per dedurre informazioni utili sul contesto dell'utente, questi:

  • [C-2-1] NON DEVE memorizzare nello spazio di archiviazione permanente sul dispositivo né trasmettere sul dispositivo l'audio RAW registrato o qualsiasi formato che possa essere riconvertito nell'audio originale o in un facsimile, salvo esplicito consenso dell'utente.

9.8.3. Connettività

Se le implementazioni del dispositivo hanno una porta USB con supporto della modalità periferica USB:

  • [C-1-1] DEVE presentare un'interfaccia utente che richieda il consenso dell'utente prima di consentire l'accesso ai contenuti dell'archivio 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 dell'autorità di certificazione (CA) attendibile del sistema come forniti nell'Android Open Source Project a monte.
  • [C-0-2] DEVE essere fornito con un archivio CA radice dell'utente vuoto.
  • [C-0-3] DEVE mostrare all'utente un avviso che indica che il traffico di rete potrebbe essere monitorato quando viene aggiunta una CA radice dell'utente.

Se il traffico dei dispositivi viene instradato tramite VPN, le implementazioni dei dispositivi:

  • [C-1-1] DEVE mostrare all'utente un avviso che indichi quanto segue:
    • Il traffico di rete potrebbe essere monitorato.
    • Il traffico di rete viene instradato tramite l'applicazione VPN specifica che fornisce la VPN.

Se le implementazioni dei dispositivi hanno un meccanismo, abilitato per impostazione predefinita, che instrada il traffico dei dati di rete tramite un server proxy o un gateway VPN (ad esempio, precaricando un servizio VPN con android.permission.CONTROL_VPN concesso), questi:

  • [C-2-1] DEVE chiedere il consenso dell'utente prima di attivare questo meccanismo, a meno che la VPN non sia attivata dal controller dei criteri dei dispositivi tramite DevicePolicyManager.setAlwaysOnVpnPackage(). In questo caso l'utente non deve fornire un consenso separato, ma DEVE ricevere soltanto una notifica.

Se le implementazioni del dispositivo implementano l'autorizzazione dell'utente ad attivare la funzione "VPN sempre attiva" di un'app VPN di terze parti, l'utente deve:

  • [C-3-1] DEVE disattivare l'accettazione di questo utente 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 da un'app al numero di serie del dispositivo e, ove applicabile, a IMEI/MEID, numero di serie della SIM e IMSI (International Mobile Subscriber Identity), a meno che non soddisfi uno dei seguenti requisiti:
    • è un'app dell'operatore firmata e verificata dai produttori di dispositivi.
    • a cui è stata concessa l'autorizzazione READ_PRIVILEGED_PHONE_STATE.
    • dispone dei privilegi di operatore definiti in Privilegi degli operatori UICC.
    • è un proprietario del dispositivo o del profilo a cui è stata concessa l'autorizzazione READ_PHONE_STATE.
    • (Solo per il numero di serie della SIM/ICCID) il requisito delle normative locali prevede che l'app rilevi cambiamenti nell'identità dell'abbonato.

9.8.6. Acquisizione dei contenuti

Android, tramite l'API di sistema ContentCaptureService o con altri mezzi proprietari, supporta un meccanismo che consente alle implementazioni dei dispositivi di acquisire le seguenti interazioni tra le applicazioni e l'utente.

  • Testo e grafici visualizzati sullo schermo, inclusi, a titolo esemplificativo, le notifiche e i dati relativi all'evento indiretto tramite l'API AssistStructure.
  • Dati multimediali, ad esempio audio o video, registrati o riprodotti dal dispositivo.
  • Eventi di input (ad es. tasto, mouse, gesto, voce, video e accessibilità).
  • Eventuali altri eventi forniti da un'applicazione al sistema tramite l'API Content Capture o un'API proprietaria con funzionalità analoghe.

Se le implementazioni dei dispositivi acquisiscono i dati indicati sopra, questi:

  • [C-1-1] DEVE crittografare tutti questi dati quando sono memorizzati nel dispositivo. La crittografia PUÒ essere eseguita utilizzando la crittografia basata su file Android o una qualsiasi delle crittografie elencate come versione API 26 o successive descritte nell'SDK Cipher.
  • [C-1-2] NON DEVE eseguire il backup dei dati non elaborati o criptati utilizzando metodi di backup di Android o altri metodi di backup.
  • [C-1-3] DEVE inviare tutti questi dati e il log del dispositivo soltanto utilizzando un meccanismo che tutela la privacy. Il meccanismo di tutela della privacy è definito come "quelli che consentono solo l'analisi in forma aggregata e impediscono la corrispondenza di eventi registrati o risultati derivati per i singoli utenti", per impedire che qualsiasi dato per utente sia introspezionabile (ad es. implementato utilizzando una tecnologia della privacy differenziale come RAPPOR).
  • [C-1-4] NON DEVE associare questi dati a identità utente (ad esempio Account) sul dispositivo, salvo con il consenso esplicito dell'utente ogni volta che i dati vengono associati.
  • [C-1-5] NON DEVE condividere questi dati con altre app, salvo con il consenso esplicito dell'utente ogni volta che vengono condivisi.
  • [C-1-6] DEVE fornire all'utente il permesso di cancellare i dati raccolti da ContentCaptureService o dai mezzi proprietari se i dati vengono memorizzati in qualsiasi forma sul dispositivo.

Se le implementazioni dei dispositivi includono un servizio che implementa l'API di sistema ContentCaptureService o qualsiasi servizio proprietario che acquisisce i dati come descritto sopra, questi:

  • [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 app diverse dal meccanismo di acquisizione dei contenuti preinstallato di acquisire questi dati.
  • [C-2-3] DEVE fornire l'invito all'utente per disattivare il servizio di acquisizione dei contenuti.
  • [C-2-4] NON DEVE omettere l'autorizzazione dell'utente a gestire le autorizzazioni Android detenute dal servizio di acquisizione di contenuti e seguire il modello di autorizzazioni Android come descritto nella Sezione 9.1. Autorizzazione.

  • [C-SR] È VIVAMENTE CONSIGLIATO di mantenere separati i componenti del servizio di acquisizione dei contenuti, ad esempio, senza associare gli ID servizio o di processo di condivisione, da altri componenti di sistema, ad eccezione di quanto segue:

    • Telefonia, contatti, UI di sistema e contenuti multimediali

9.8.7. Accesso agli appunti

Implementazioni dei dispositivi:

  • [C-0-1] NON DEVE restituire dati troncati negli appunti (ad es. tramite l'API ClipboardManager) a meno che l'app non sia l'IME predefinito o sia 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 la sua iniziativa.
  • [C-0-2] DEVE fornire all'utente l'autorizzazione ad accedere a informazioni relative alla posizione, tra cui richieste di 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.setLocationSettings ignorid()] sia una sessione di emergenza avviata dall'utente (ad esempio, componi il numero 911 o invii un messaggio al numero 112).
  • [C-0-4] DEVE preservare la capacità dell'API Emergency Location Bypass di bypassare le impostazioni di geolocalizzazione del dispositivo senza modificare le impostazioni.
  • [C-0-5] DEVE pianificare una notifica che ricordi all'utente dopo che un'app in background ha avuto accesso alla sua posizione usando l'autorizzazione [ACCESS_BACKGROUND_LOCATION].

9,9 Crittografia archiviazione dati

Tutti i dispositivi DEVONO soddisfare i requisiti della sezione 9.9.1. I dispositivi che sono stati lanciati a un livello API precedente a quello di questo documento sono esentati dai requisiti delle sezioni 9.9.2 e 9.9.3; invece DEVONO soddisfare i requisiti della sezione 9.9 del documento Android Compatibility Definition corrispondente al livello API su cui il dispositivo è stato lanciato.

9.9.1. Avvio diretto

Implementazioni dei dispositivi:

  • [C-0-1] DEVONO implementare le API in modalità di avvio diretto anche se non supportano Storage Encryption.

  • [C-0-2] Gli intent ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED DEVONO comunque essere trasmessi per segnalare alle applicazioni sensibili all'avvio diretto che le posizioni di archiviazione con crittografia DE e con crittografia CE sono disponibili per gli utenti.

9.9.2. Requisiti di crittografia

Implementazioni dei dispositivi:

  • [C-0-1] DEVE criptare i dati privati dell'applicazione (partizione /data), nonché 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 nel momento in cui l'utente ha completato la configurazione predefinita.
  • [C-0-3] DEVE soddisfare il requisito di crittografia dello spazio di archiviazione dei dati di cui sopra tramite l'implementazione della crittografia basata su file (FBE).

9.9.3. Crittografia basata su file

Dispositivi criptati:

  • [C-1-1] DEVE avviarsi senza richiedere le credenziali all'utente e consentire alle app sensibili all'avvio diretto di accedere allo spazio di archiviazione con crittografia dei dispositivi (DE) dopo la trasmissione del messaggio ACTION_LOCKED_BOOT_COMPLETED.
  • [C-1-2] DEVE consentire l'accesso all'archivio con credenziali con crittografia CE solo dopo che l'utente ha sbloccato il dispositivo fornendo le proprie credenziali (ad esempio passcode, PIN, sequenza o impronta) e dopo che è stato trasmesso il messaggio ACTION_USER_UNLOCKED.
  • [C-1-3] NON DEVE offrire alcun metodo per sbloccare lo spazio di archiviazione protetto da CE senza le credenziali fornite dall'utente o una chiave di deposito a garanzia registrata.
  • [C-1-4] DEVE utilizzare l'Avvio verificato e assicurarsi che le chiavi DE siano associate tramite crittografia alla radice di attendibilità hardware del dispositivo.
  • [C-1-5] DEVE crittografare i contenuti dei file utilizzando AES-256-XTS o Adiantum. AES-256-XTS si riferisce all'Advanced Encryption Standard con una lunghezza di chiave di crittografia a 256 bit, gestita in modalità XTS; la lunghezza completa della chiave è di 512 bit. Adiantum si riferisce ad Adiantum-XChaCha12-AES, come specificato all'indirizzo https://github.com/google/adiantum.
  • [C-1-6] DEVE crittografare i nomi dei file utilizzando AES-256-CBC-CTS o Adiantum.

  • [C-1-12] DEVE utilizzare AES-256-XTS per i contenuti dei file e AES-256-CBC-CTS per i nomi dei file (invece di Adiantum) se il dispositivo dispone di istruzioni Advanced Encryption Standard (AES). Le istruzioni AES sono estensioni di crittografia ARMv8 su dispositivi basati su ARM o AES-NI su dispositivi basati su x86. Se il dispositivo non dispone di istruzioni AES, POTREBBE utilizzare Adiantum.

  • I token che proteggono le aree di stoccaggio CE e DE:

  • [C-1-7] DEVE essere crittograficamente associato a un archivio chiavi supportato da hardware.

  • [C-1-8] Le chiavi CE DEVONO essere associate alle credenziali della schermata di blocco di un utente.
  • [C-1-9] Le chiavi CE DEVONO essere associate a un passcode predefinito se 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 alle chiavi CE o DE di altri utenti.
  • [C-1-11] DEVE utilizzare le modalità, le lunghezze delle chiavi e le crittografie obbligatoriamente supportate.

  • [C-SR] È VIVAMENTE CONSIGLIATO di criptare i metadati del file system, come le dimensioni, la proprietà, le modalità e gli attributi estesi (xattrs), con una chiave crittograficamente associata alla radice di attendibilità hardware del dispositivo.

  • DEVI tenere presenti le app essenziali preinstallate (ad es. Sveglia, Telefono, Messenger) nell'Avvio diretto.

Il progetto open source Android upstream fornisce un'implementazione preferita di questa funzionalità basata sulla funzionalità di crittografia "fscrypt" del kernel Linux.

9.10. Integrità del dispositivo

I seguenti requisiti garantiscono la trasparenza sullo stato di integrità del dispositivo. Implementazioni dei dispositivi:

  • [C-0-1] DEVE segnalare correttamente tramite il metodo dell'API di sistema PersistentDataBlockManager.getFlashLockState() se il relativo stato del bootloader consente il flashing dell'immagine di sistema. Lo stato FLASH_LOCK_UNKNOWN è riservato alle implementazioni dei dispositivi che eseguono l'upgrade da una versione precedente di Android in cui questo nuovo metodo API di sistema non esisteva.

  • [C-0-2] DEVE supportare l'Avvio verificato per garantire l'integrità del dispositivo.

Se le implementazioni dei dispositivi sono già state lanciate senza il supporto dell'Avvio verificato su una versione precedente di Android e non è possibile aggiungere il supporto per questa funzionalità con un aggiornamento software di sistema, i dispositivi POSSONO essere esenti dal requisito.

Avvio verificato è una funzionalità che garantisce l'integrità del software del dispositivo. Se le implementazioni dei dispositivi supportano la funzionalità:

  • [C-1-1] DEVE dichiarare il flag della funzionalità della piattaforma android.software.verified_boot.
  • [C-1-2] DEVE eseguire la verifica a ogni sequenza di avvio.
  • [C-1-3] DEVE avviare la verifica da una chiave hardware immutabile che è la radice di attendibilità e arrivare fino alla partizione di sistema.
  • [C-1-4] DEVE implementare ogni fase di verifica per controllare l'integrità e l'autenticità di tutti i byte nella fase successiva prima di eseguire il codice nella fase successiva.
  • [C-1-5] DEVE utilizzare algoritmi di verifica efficaci quanto gli attuali consigli del NIST per gli algoritmi di hashing (SHA-256) e le dimensioni delle chiavi pubbliche (RSA-2048).
  • [C-1-6] NON DEVE consentire il completamento dell'avvio quando la verifica del sistema non va a buon fine, a meno che l'utente non acconsenta a tentare comunque l'avvio. In questo caso i dati di eventuali blocchi di archiviazione non verificati DEVONO essere utilizzati.
  • [C-1-7] NON DEVE consentire la modifica delle partizioni verificate sul dispositivo, a meno che l'utente non abbia sbloccato esplicitamente il bootloader.
  • [C-SR] Se nel dispositivo sono presenti più chip discreti (ad es. radio, processore di immagini specializzato), è VIVAMENTE CONSIGLIATO verificare ogni fase al momento dell'avvio del processo di avvio di ciascuno di questi chip.
  • [C-1-8] DEVE utilizzare uno spazio di archiviazione che evidenzia le manomissioni, per memorizzare se il bootloader è sbloccato. Lo spazio di archiviazione a prova di manomissione significa che il bootloader può rilevare se lo spazio di archiviazione è stato manomesso dall'interno di Android.
  • [C-1-9] DEVE inviare una richiesta all'utente mentre è in uso il dispositivo e richiedere una conferma fisica prima di consentire una transizione dalla modalità di blocco del bootloader alla modalità di sblocco del bootloader.
  • [C-1-10] DEVE implementare la protezione rollback per le partizioni utilizzate da Android (ad esempio, avvio, partizioni di sistema) e usare un'archiviazione che evidenzia le manomissioni per l'archiviazione dei metadati utilizzati per determinare la versione minima consentita del sistema operativo.
  • [C-SR] È VIVAMENTE CONSIGLIATO di verificare tutti i file APK delle app con privilegi con una catena di attendibilità radicata in partizioni protette da Avvio verificato.
  • [C-SR] È VIVAMENTE CONSIGLIATO di verificare eventuali artefatti eseguibili caricati da un'app con privilegi dall'esterno del file APK (come codice caricato dinamicamente o codice compilato) prima di eseguirli oppure VIVAMENTE CONSIGLIATO di non eseguirli affatto.
  • DEVE implementare la protezione rollback per qualsiasi componente con firmware permanente (ad esempio, modem, fotocamera) e DEVE utilizzare un'archiviazione che evidenzia le manomissioni per l'archiviazione dei metadati utilizzati per determinare la versione minima consentita.

Se le implementazioni dei dispositivi sono già state lanciate senza il supporto di C-1-8 a C-1-10 su una versione precedente di Android e non possono aggiungere il supporto per questi requisiti con un aggiornamento del software di sistema, questi POSSONO essere esentati dai requisiti.

Il progetto open source Android a monte offre un'implementazione preferita di questa funzionalità nel repository di external/avb/, che può essere integrata nel bootloader utilizzato per caricare Android.

Implementazioni dei dispositivi:

Se le implementazioni dei dispositivi supportano l'API Android Protected Confirmation, questi ultimi:

  • [C-3-1] DEVE segnalare true per l'API ConfirmationPrompt.isSupported().

  • [C-3-2] DEVE garantire che il codice in esecuzione nel sistema operativo Android, incluso il suo kernel, dannoso o di altro tipo, non possa generare una risposta positiva senza interazione dell'utente.

  • [C-3-3] DEVE garantire che l'utente sia riuscito a rivedere e approvare il messaggio richiesto anche nel caso in cui il sistema operativo Android, incluso il suo kernel, sia compromesso.

9.11. Chiavi e credenziali

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

  • [C-0-1] DEVE consentire almeno 8.192 chiavi da importare o generare.
  • [C-0-2] L'autenticazione della schermata di blocco DEVE limitare i tentativi di frequenza e DEVE avere un algoritmo di backoff esponenziale. Oltre i 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

Se l'implementazione del dispositivo supporta una schermata di blocco sicura:

  • [C-1-1] DEVE eseguire il backup dell'implementazione dell'archivio chiavi con un ambiente di esecuzione isolato.
  • [C-1-2] DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni di hash della famiglia MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema dell'archivio chiavi Android 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, compresa la DMA. L'upstream Android Open Source Project (AOSP) soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura esaminata da terze parti di un corretto isolamento basato su hypervisor sono opzioni alternative.
  • [C-1-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo in caso di esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere archiviate in un modo che consenta solo all'ambiente di esecuzione isolato di eseguire l'autenticazione. L'upstream Android Open Source Project fornisce il Gatekeeper Hardware Abstraction Layer (HAL) e Trusty, che possono essere utilizzati per soddisfare questo requisito.
  • [C-1-4] DEVE supportare l'attestazione della chiave 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 tra un numero sufficiente di dispositivi da evitare che vengano utilizzate come identificatori del dispositivo. 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, POTREBBE essere utilizzata una chiave diversa per ogni 100.000 unità.

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

  • [C-1-5] DEVE consentire all'utente di scegliere il timeout del sonno per la transizione dallo stato sbloccato a quello di blocco, con un timeout minimo consentito fino a 15 secondi.

9.11.1. Schermata di blocco sicura e autenticazione

L'implementazione di AOSP segue un modello di autenticazione a più livelli in cui un'autenticazione primaria basata su knowledge base può essere supportata da una biometria forte secondaria o da modalità terziarie più deboli.

Implementazioni dei dispositivi:

  • [C-SR] Ti consigliamo vivamente di impostare solo uno dei seguenti metodi di autenticazione principale:
    • Un PIN numerico
    • Una password alfanumerica.
    • Una sequenza di scorrimento su una griglia di 3 x 3 punti esatti

Tieni presente che in questo documento i metodi di autenticazione illustrati sopra sono indicati come metodi principali consigliati.

Se le implementazioni del dispositivo 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 in base a un secret noto e utilizzano un nuovo metodo di autenticazione da considerare come modo sicuro per bloccare lo schermo:

  • [C-3-1] L'entropia della più breve lunghezza 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 (ovvero PIN, sequenza, password) implementati e forniti in AOSP.
  • [C-3-4] Il nuovo metodo di autenticazione DEVE essere disattivato 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_SOMETHING.
  • [C-3-5] I nuovi metodi di autenticazione DEVONO ricorrere ai metodi principali consigliati (ovvero 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 del dispositivo 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 considerare come 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 Comodità.
  • [C-4-2] DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali consigliati che si basa su un segreto noto.
  • [C-4-3] DEVE essere disattivato e consentire solo l'autenticazione primaria consigliata per sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio per la funzionalità di blocco della chiave 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 lo standard Strong 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] L'utente DEVE essere richiesto all'utente di richiedere l'autenticazione principale consigliata (ad esempio: PIN, sequenza, password) dopo un periodo di timeout di inattività di 4 ore. Il periodo di timeout di inattività viene reimpostato dopo una conferma delle credenziali del dispositivo.
  • [C-5-3] I metodi NON DEVONO essere trattati come una schermata di blocco sicura e DEVONO soddisfare i requisiti che iniziano con C-8 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 è basato su un token fisico o sulla posizione:

  • [C-6-1] DEVONO avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali consigliati che si basa su un segreto noto e devono soddisfare i requisiti per essere trattati come una schermata di blocco sicura.
  • [C-6-2] Il nuovo metodo DEVE essere disattivato e consentire solo a uno dei metodi di autenticazione principali consigliati di sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio con il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED.
  • [C-6-3] L'utente DEVE richiedere uno dei metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) almeno una volta ogni 4 ore o meno.
  • [C-6-4] Il nuovo metodo NON DEVE essere trattato come una schermata di blocco sicura e DEVE seguire i vincoli elencati nel paragrafo C-8 di seguito.

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

  • [C-7-1] DEVE avere indicazioni chiare nel menu Impostazioni e nella schermata di blocco quando il blocco del dispositivo viene posticipato o può essere mantenuto sbloccato da agenti di attendibilità. Ad esempio, AOSP soddisfa questo requisito mostrando una descrizione di testo per le opzioni "Blocca automaticamente l'impostazione" e "Blocca immediatamente il tasto di accensione" nel menu Impostazioni e un'icona distinguibile nella schermata di blocco.
  • [C-7-2] DEVE rispettare e implementare completamente tutte le API dell'agente di attendibilità nella classe DevicePolicyManager, come 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 esempio, un dispositivo portatile), ma MA POTREBBE implementarla completamente nelle implementazioni dei dispositivi tipicamente condivise (ad esempio Android Television o Automotive).
  • [C-7-4] DEVE criptare tutti i token memorizzati aggiunti da TrustAgentService.addEscrowToken().
  • [C-7-5] NON DEVE archiviare la chiave di crittografia o il token di deposito a garanzia sullo stesso dispositivo in cui viene utilizzata la chiave. Ad esempio, una chiave memorizzata su un telefono può sbloccare un account utente su una TV.
  • [C-7-6] DEVE informare l'utente delle implicazioni per la sicurezza prima di abilitare il token del deposito a garanzia per decrittografare l'archiviazione dei dati.
  • [C-7-7] DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali consigliati.
  • [C-7-8] L'utente DEVE essere sottoposto a una richiesta di verifica di uno dei metodi di autenticazione primaria consigliati (ad es. PIN, sequenza, password) almeno una volta ogni 72 ore o meno, a meno che la sicurezza dell'utente (ad esempio la distrazione del conducente) non sia preoccupante.
  • [C-7-9] L'utente DEVE essere sottoposto a una richiesta di verifica di uno dei metodi di autenticazione primaria consigliati (ad esempio, PIN, sequenza, password) dopo un periodo di timeout di inattività di 4 ore, a meno che la sicurezza dell'utente (ad esempio, la distrazione del conducente) non sia preoccupante. Il periodo di timeout di inattività viene reimpostato dopo una conferma delle credenziali del dispositivo.
  • [C-7-10] NON DEVE essere considerato come una schermata di blocco sicura e DEVE seguire i vincoli elencati in C-8 di seguito.
  • [C-7-11] NON DEVE consentire a TrustAgent sui dispositivi personali principali (ad esempio i dispositivi portatili) di sbloccare il dispositivo e può utilizzarli solo per mantenere un dispositivo già sbloccato in stato sbloccato per un massimo di quattro ore al massimo. L'implementazione predefinita di TrustManagerService in AOSP soddisfa questo requisito.
  • [C-7-12] DEVE utilizzare un canale di comunicazione crittograficamente sicuro (ad esempio UKEY2) per passare il token di garanzia dal dispositivo di archiviazione al dispositivo di destinazione.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare una schermata di blocco che non è una schermata di blocco sicura come descritto sopra, e utilizza un nuovo metodo di autenticazione per sbloccare il blocco tastiera:

  • [C-8-1] Il nuovo metodo DEVE essere disattivato 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_UNSPECIFIED.
  • [C-8-2] NON DEVONO reimpostare i timer per la scadenza della password impostati da DevicePolicyManager.setPasswordExpirationTimeout().
  • [C-8-3] NON DEVONO esporre un'API per l'uso da parte di app di terze parti per modificare lo stato di blocco.

9.11.2. StrongBox

Il sistema di archiviazione chiavi Android consente agli sviluppatori di app di archiviare le chiavi di crittografia in un processore sicuro dedicato e nell'ambiente di esecuzione isolato descritto sopra. Questo processore sicuro dedicato è chiamato "StrongBox". I requisiti da C-1-3 a C-1-11 che seguono definiscono i requisiti che un dispositivo DEVE soddisfare per essere qualificato come StrongBox.

Implementazioni del dispositivo dotate di un processore sicuro dedicato:

  • [C-SR] È VIVAMENTE CONSIGLIATO per il supporto di StrongBox. StrongBox diventerà probabilmente un requisito in una release futura.

Se le implementazioni del dispositivo supportano StrongBox:

  • [C-1-1] DEVE dichiarare FEATURE_STRONGBOX_KEYSTORE.

  • [C-1-2] DEVE fornire hardware sicuro dedicato che venga utilizzato per l'archivio chiavi e l'autenticazione sicura degli utenti. L'hardware sicuro dedicato potrebbe essere utilizzato anche per altri scopi.

  • [C-1-3] DEVE avere una CPU discreta che non condivida cache, DRAM, coprocessori o altre risorse di base con il processore dell'applicazione (AP).

  • [C-1-4] DEVE garantire che le periferiche condivise con il punto di accesso non possano alterare in alcun modo l'elaborazione di StrongBox, né ottenere alcuna informazione da StrongBox. L'AP POTREBBE disattivare o bloccare l'accesso a StrongBox.

  • [C-1-5] DEVE avere un orologio interno con ragionevole precisione (+-10%) che sia immune alla manipolazione da parte dell'AP.

  • [C-1-6] DEVE avere un vero generatore di numeri casuali che generi un output uniformemente distribuito e imprevedibile.

  • [C-1-7] DEVONO essere resistenti alla manomissione, inclusa la resistenza alla penetrazione fisica e agli glitch.

  • [C-1-8] DEVE avere una resistenza nei canali laterali, inclusa la resistenza alla fuga di informazioni tramite i canali laterali di alimentazione, temporizzazione, radiazioni elettromagnetiche e termiche.

  • [C-1-9] DEVE disporre di un'archiviazione sicura che garantisca riservatezza, integrità, autenticità, coerenza e aggiornamento dei contenuti. Lo spazio di archiviazione NON DEVE essere letto o alterato, tranne nei casi consentiti dalle API StrongBox.

  • Per convalidare la conformità da [C-1-3] a [C-1-9], le implementazioni dei dispositivi:

    • [C-1-10] DEVE includere l'hardware certificato per il Secure IC Protection Profile BSI-CC-PP-0084-2014 o valutato da un laboratorio di collaudo accreditato a livello nazionale che incorpora la valutazione di vulnerabilità di alto potenziale di attacco in base al Common Criteria Application of Attack Potential to Smartcard.
    • [C-1-11] DEVE includere il firmware valutato da un laboratorio di collaudo accreditato a livello nazionale che incorpora la valutazione di vulnerabilità con potenziale di attacco elevato in base ai criteri Common Criteria Application of Attack Potential to Smartcard.
    • [C-SR] È VIVAMENTE CONSIGLIATO di includere l'hardware valutato utilizzando un Obiettivo di Sicurezza, Livello di Valutazione della Valutazione (EAL) 5, potenziato da AVA_VAN.5. La certificazione EAL 5 diventerà probabilmente un requisito in una release futura.

  • I [C-SR] sono VIVAMENTE CONSIGLIATI per la resistenza agli attacchi interni (IAR), il che significa che un utente interno con accesso alle chiavi di firma del firmware non può produrre un firmware che causa la divulgazione di secret da StrongBox, l'elusione dei requisiti di sicurezza funzionali o l'accesso a dati utente sensibili. Il metodo consigliato per implementare IAR è consentire gli aggiornamenti firmware solo quando la password dell'utente principale viene fornita tramite IAuthSecret HAL.

9.12. Eliminazione dei dati

Tutte le implementazioni sui dispositivi:

  • [C-0-1] DEVE fornire agli utenti un meccanismo per eseguire un "ripristino dei dati di fabbrica".
  • [C-0-2] DEVE eliminare tutti i dati sul file system dei dati utente.
  • [C-0-3] DEVE eliminare i dati in modo tale da soddisfare gli standard di settore pertinenti, come NIST SP800-88.
  • [C-0-4] DEVE attivare la procedura di "ripristino dei dati di fabbrica" indicata sopra quando l'API DevicePolicyManager.wipeData() viene chiamata dall'app Device Policy Controller dell'utente principale.
  • POTREBBE fornire un'opzione di cancellazione dei dati rapida che esegue solo una cancellazione logica dei dati.

9.13. Modalità di avvio protetto

Android offre la modalità di avvio protetto, che consente agli utenti di avviare una modalità in cui possono essere eseguite solo le app di sistema preinstallate e tutte le app di terze parti sono disattivate. Questa modalità, nota come "Avvio sicuro", offre all'utente la possibilità di disinstallare app di terze parti potenzialmente dannose.

Le implementazioni dei dispositivi sono:

  • [SR] VIVAMENTE CONSIGLIATA di implementare la modalità di avvio protetto.

Se le implementazioni dei dispositivi implementano la modalità di avvio protetto, questi:

  • [C-1-1] DEVE fornire all'utente un'opzione per attivare la modalità di avvio protetto in modo tale che non possa essere interrotta dalle app di terze parti installate sul dispositivo, tranne nel caso in cui l'app di terze parti sia un controller dei criteri dei dispositivi e abbia impostato il flag UserManager.DISALLOW_SAFE_BOOT su true.

  • [C-1-2] DEVE fornire all'utente la possibilità di disinstallare eventuali app di terze parti in modalità provvisoria.

  • DOVREBBE fornire all'utente un'opzione per entrare in modalità di avvio protetto dal menu di avvio utilizzando un flusso di lavoro diverso da quello di un normale avvio.

9.14. Isolamento dei sistemi per veicoli automobilistici

I dispositivi Android Automotive dovrebbero scambiare dati con sottosistemi critici dei veicoli utilizzando l'HAL del veicolo per inviare e ricevere messaggi su reti di veicoli come il bus CAN.

Lo scambio di dati può essere protetto implementando funzionalità di sicurezza al di sotto dei livelli del framework Android per impedire interazioni dannose o non intenzionali con questi sottosistemi.

9.15. Piani di abbonamento

I "piani di abbonamento" fanno riferimento ai dettagli dei piani di fatturazione forniti da un operatore di telefonia mobile tramite SubscriptionManager.setSubscriptionPlans().

Tutte le implementazioni sui dispositivi:

  • [C-0-1] DEVONO restituire i piani di abbonamento solo all'app dell'operatore di telefonia mobile che li ha originariamente forniti.
  • [C-0-2] NON DEVE effettuare il backup o il caricamento dei piani di abbonamento da remoto.
  • [C-0-3] DEVE consentire solo gli override, ad esempio SubscriptionManager.setSubscriptionOverrideCongested(), dall'app dell'operatore di telefonia mobile che attualmente fornisce piani di abbonamento validi.

10. Test di compatibilità del software

Le implementazioni dei dispositivi DEVONO superare tutti i test descritti in questa sezione. Tuttavia, tieni presente che nessun pacchetto di test è del tutto completo. Per questo motivo, agli utenti che implementano i dispositivi è VIVAMENTE CONSIGLIATO di apportare il numero minimo di modifiche possibile al riferimento e all'implementazione preferita di Android disponibili nell'Android Open Source Project. In questo modo ridurrai il rischio di introdurre bug che creano incompatibilità che richiedono rielaborazione e potenziali aggiornamenti dei dispositivi.

10.1 Suite di test di compatibilità

Implementazioni dei dispositivi:

  • [C-0-1] DEVE superare la suite per il test di compatibilità Android (CTS) disponibile nell'Android Open Source Project, utilizzando il software di spedizione finale sul dispositivo.

  • [C-0-2] DEVE garantire la compatibilità in casi di ambiguità in CTS e per eventuali reimplementazioni di parti del codice sorgente di riferimento.

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi altro software, il CTS stesso può contenere dei bug. Il CTS verrà sottoposto al controllo delle versioni indipendentemente da questa Definizione di compatibilità e potrebbero essere rilasciate più revisioni per Android 10.

Implementazioni dei dispositivi:

  • [C-0-3] DEVE superare l'ultima versione CTS disponibile al momento del completamento del software del dispositivo.

  • DEVI utilizzare il più possibile l'implementazione del riferimento nell'albero open source di Android.

10.2. Verificatore CTS

Lo strumento di verifica CTS è incluso nella suite di test di compatibilità ed è destinato a essere eseguito da un operatore umano per testare funzionalità che non possono essere testate da un sistema automatico, come il corretto funzionamento di una fotocamera e dei sensori.

Implementazioni dei dispositivi:

  • [C-0-1] DEVE eseguire correttamente tutti i casi applicabili nello strumento di verifica CTS.

Lo strumento di verifica CTS effettua test per molti tipi di hardware, inclusi alcuni hardware facoltativi.

Implementazioni dei dispositivi:

  • [C-0-2] DEVE superare tutti i test relativi all'hardware in suo possesso; ad esempio, se un dispositivo dispone di un accelerometro, DEVE eseguire correttamente lo scenario di test dell'accelerometro nello strumento di verifica CTS.

Gli scenari di test per le funzionalità indicate come facoltative nel presente documento sulla definizione di compatibilità POSSONO essere ignorati 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 implementer dei dispositivi eseguano in modo esplicito CTS Verifier su build che differiscono solo per aspetti banali. In particolare, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato lo strumento di verifica CTS solo per il set di paesi, branding e così via inclusi. POSSONO omettere il test di verifica CTS.

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", ossia potrebbe essere necessario riavviare il dispositivo. È possibile utilizzare qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, uno qualsiasi dei seguenti approcci soddisferà questo requisito:

    • Download di "over-the-air (OTA)" con aggiornamento offline tramite riavvio.
    • Aggiornamenti "con tethering" tramite USB da un PC host.
    • "Offline" si aggiorna tramite riavvio e aggiornamento da un file su uno spazio di archiviazione 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 conservare i dati privati e quelli condivisi dall'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 confrontandoli con una chiave pubblica memorizzata sul dispositivo.

  • [C-SR] Il meccanismo di firma è VIVAMENTE CONSIGLIATO di eseguire l'hashing dell'aggiornamento con SHA-256 e convalidare l'hash in base alla chiave pubblica utilizzando ECDSA NIST P-256.

Se le implementazioni dei dispositivi includono il supporto per una connessione dati unmetered come 802.11 o un profilo Bluetooth PAN (Personal Area Network), allora:

  • [C-1-1] DEVE supportare i download OTA con aggiornamento offline tramite riavvio.

Per le implementazioni dei dispositivi che verranno lanciate con Android 6.0 e versioni successive, il meccanismo di aggiornamento DEVE supportare la verifica che l'immagine di sistema sia identica al risultato previsto a seguito di un'OTA. L'implementazione OTA basata su blocchi nell'Android Open Source Project upstream, aggiunta a partire da Android 5.1, soddisfa questo requisito.

Inoltre, le implementazioni dei dispositivi DEVONO supportare gli aggiornamenti di sistema A/B. L'AOSP implementa questa funzionalità utilizzando l'HAL per il controllo di avvio.

Se viene rilevato un errore nell'implementazione di un dispositivo dopo il suo rilascio, ma entro il suo ciclo di vita ragionevole, determinato in consultazione con il team Android Compatibility, per avere effetto sulla compatibilità delle applicazioni di terze parti:

  • [C-2-1] L'implementatore del dispositivo DEVE correggere l'errore tramite un aggiornamento software disponibile che possa essere applicato in base al meccanismo appena descritto.

Android include funzionalità che consentono all'app Proprietario del dispositivo (se presente) di controllare l'installazione degli aggiornamenti di sistema. Se il sottosistema dell'aggiornamento di sistema per i dispositivi segnala android.software.device_admin:

12. Log delle modifiche del documento

Per un riepilogo delle modifiche alla definizione di compatibilità in questa release:

Per un riepilogo delle modifiche apportate alle sezioni delle singole persone:

  1. Introduzione
  2. Tipi di dispositivi
  3. Software
  4. Pacchetto dell'applicazione
  5. Contenuti multimediali
  6. Strumenti e opzioni per sviluppatori
  7. Compatibilità hardware
  8. Prestazioni e potenza
  9. Modello di sicurezza
  10. Test di compatibilità del software
  11. Software aggiornabile
  12. Log delle modifiche del documento
  13. Contattaci

12.1. Suggerimenti per la visualizzazione del log delle modifiche

Le modifiche sono contrassegnate come segue:

  • CDD
    Modifiche sostanziali ai requisiti di compatibilità.

  • Documenti
    Modifiche di tipo estetico o correlate alle costruzioni.

Per una visualizzazione ottimale, aggiungi i parametri URL pretty=full e no-merges agli URL del log delle modifiche.

13. Contattaci

Puoi partecipare al forum sulla compatibilità con Android e chiedere chiarimenti o segnalare eventuali problemi che ritieni non siano trattati nel documento.