Definizione di compatibilità con Android 9

1. Introduzione

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

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.

Per "implementatore del dispositivo" o "implementatore" si intende una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 9. Per "implementazione del dispositivo" o "implementazione" si intende la soluzione hardware/software così sviluppata.

Per essere considerate compatibili con Android 9, 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
  • 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 uno schermo di almeno 2,5 pollici di diagonale fisico.
• [7.1.1.3/H-SR] È VIVAMENTE CONSIGLIATO di fornire agli utenti un'invito per cambiare le dimensioni di visualizzazione.(Densità 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-1] DEVE fornire le funzioni Home, Recenti e Indietro.
• [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 giroscopio:

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

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.12/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.

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

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.

2.2.2. Multimediale

Le implementazioni dei dispositivi portatili DEVONO supportare la seguente codifica audio:

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

Le implementazioni dei dispositivi portatili DEVONO supportare la seguente decodifica audio:

• [5.1.2/H-0-1] AMR-NB
• [5.1.2/H-0-2] AMR-WB

Le implementazioni dei dispositivi portatili DEVONO supportare la seguente codifica video e renderla disponibile 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 la seguente decodifica video:

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

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:

• [8.4/H-1-1] DEVE rispettare l'intent android.intent.action.POWER_USAGE_SUMMARY e visualizzare un menu di impostazioni che mostri questo consumo energetico.

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.

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.

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

• [7.3.4/T-1-1] DEVE essere in grado di segnalare eventi con una frequenza di almeno 100 Hz.

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 audio:

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

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

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] AVC H.264
• [5.3.5/T-0-3] HEVC H.265
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9

Le implementazioni di dispositivi televisivi sono VIVAMENTE CONSIGLIATE di supportare i seguenti formati di decodifica video:

• [5.3.1/T-SR] MPEG-2

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.4/T-1-1] HD 1080p a 60 frame al secondo con Basline Profile
• [5.3.4.4/T-1-2] HD 1080p a 60 frame al secondo con profilo principale
• [5.3.4.4/T-1-3] HD 1080p a 60 frame al secondo con livello di profilo elevato 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.4/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.5/T-2-1] DEVE supportare il profilo di decodifica UHD a 60 frame al secondo con il profilo di livello principale di livello 5 principale.

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.4/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.4/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.5/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.5/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.3/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).
• [5.8/T-0-1] DEVE impostare la modalità di uscita HDMI per selezionare la risoluzione massima che può essere supportata con frequenza di aggiornamento di 50 Hz o 60 Hz per tutti i display con cavo.
• [5.8/T-SR] È VIVAMENTE CONSIGLIATO di fornire un selettore della frequenza di aggiornamento HDMI configurabile dall'utente per tutti i display con cavo.
• [5.8/T-SR] È VIVAMENTE CONSIGLIATO per supportare la decodifica simultanea di stream sicuri. Come minimo, è VIVAMENTE CONSIGLIATA la decodifica simultanea di due vapore.
• [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 per tutti i display con cavo.

Se le implementazioni dei dispositivi televisivi supportano la decodifica UHD e anche i display esterni, questi:

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

Se le implementazioni dei dispositivi televisivi non supportano la decodifica UHD ma supportano display esterni, questi:

• [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.
• [8.3/T-1-2] DEVE fornire all'utente l'invito a visualizzare tutte le app esenti dalle modalità di risparmio energetico di Standby delle app 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.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.

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

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

• [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.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.1/A-SR] È VIVAMENTE CONSIGLIATO di includere un accelerometro a 3 assi.

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

• [7.3.1/A-1-1] DEVE essere in grado di segnalare eventi con una frequenza di almeno 100 Hz.
• [7.3.1/A-1-2] DEVE essere conforme al sistema di coordinate dei sensori dell'auto di Android.

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

• [7.3.4/A-1-1] DEVE essere in grado di segnalare eventi con una frequenza di almeno 100 Hz.

Implementazioni di dispositivi nel settore auto e motori:

• [7.3.11/A-0-1] DEVE fornire l'ingranaggio attuale come SENSOR_TYPE_GEAR.

Implementazioni di dispositivi nel settore auto e motori:

• [7.3.11.2/A-0-1] DEVE supportare la modalità giorno/notte definita come SENSOR_TYPE_NIGHT.
• [7.3.11.2/A-0-2] Il valore del flag SENSOR_TYPE_NIGHT 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.11.4/A-0-1] DEVE fornire la velocità del veicolo definita da SENSOR_TYPE_CAR_SPEED.

• [7.3.11.5/A-0-1] DEVE fornire lo stato del freno di stazionamento come definito da SENSOR_TYPE_PARKING_BRAKE.

• [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 che dovrebbero essere disponibili per le app di sistema.

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

Implementazioni di dispositivi nel settore auto e motori:

• [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 la seguente codifica audio:

• [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 per auto e motori DEVONO supportare la seguente codifica video:

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

Le implementazioni dei dispositivi per auto e motori DEVONO supportare la seguente decodifica video:

• [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.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 implementare un assistente sul dispositivo per gestire l'azione di assistenza.

• [3.13/A-SR] È VIVAMENTE CONSIGLIATO di includere un componente UI Impostazioni rapide.

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.14/A-0-1] DEVE includere un framework dell'interfaccia utente per supportare app di terze parti che utilizzano le API multimediali, come descritto nella sezione 3.14.

2.5.4. Prestazioni e potenza

Se le implementazioni dei dispositivi Automotive includono funzionalità per migliorare la gestione dell'alimentazione dei dispositivi incluse in AOSP o estendere le funzionalità incluse in AOSP, queste:

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

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

• [9.5/A-1-1] DEVE includere un account ospite che consenta tutte le funzioni fornite dal sistema del veicolo senza richiedere all'utente di accedere.

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

• [9.9.2/A-1-1] DEVE supportare la crittografia in base alle chiavi di autenticazione specifiche dell'utente. La crittografia basata su file (FBE) è un modo per farlo.

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.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 e * in questa sezione e indicate come riferimento in questa sezione.

2.4.1. Hardware

Dimensioni schermo

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

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.

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] DEVE limitare l'uso dell'utilizzo da parte di app di terze parti di API nascoste, definite come API nello spazio dei nomi Android decorato con l'annotazione @hidden, ma non con @SystemAPI o @TestApi, come descritto nei documenti dell'SDK e includere ogni API nascosta negli stessi elenchi con restrizioni fornite tramite l'elenco provvisorio e i file della lista bloccata nel percorso prebuilts/runtime/appcompat/ per il ramo di 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.
  • POTREBBE implementare un meccanismo di aggiornamento dinamico che sposta un'API nascosta da un elenco con restrizioni a uno meno restrittivo, ad eccezione della lista consentita.

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 9.
VERSIONE.SDK	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 9, questo campo DEVE contenere il valore intero 9_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 9, questo campo DEVE contenere il valore intero 9_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. Non esistono requisiti sul formato specifico di questo campo, ad eccezione del fatto che NON DEVE essere null o la stringa vuota ("").
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:9/LMYXX/3359:userdebug/test-keys L'impronta NON DEVE includere spazi vuoti. Se altri campi inclusi nel modello precedente contengono spazi vuoti, questi DEVONO essere sostituiti nella fingerprint della build con un altro carattere, come il trattino basso ("_"). 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. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni tipiche di firma della piattaforma Android: chiavi di rilascio, chiavi di sviluppo 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 implementer di servizi 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 associarsi e assumere il controllo di questi pattern. 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 richiesta o mai aperta, il che deve essere applicato allo stesso modo a tutti i filtri per intent dell'URI candidato.
  • [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:

• [C-1-1] DEVE rispettare l'intent android.settings.HOME_SETTINGS per mostrare un menu delle impostazioni dell'app predefinito per la schermata Home.

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

• [C-2-1] DEVE fornire un menu di impostazioni che richiami l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT per mostrare una finestra di dialogo per modificare l'applicazione predefinita per gli SMS.

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

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

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

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

• [C-3-1] DEVE rispettare l'intent android.settings.NFC_PAYMENT_SETTINGS per mostrare un menu di impostazioni dell'app predefinito per la funzionalità Tocca e paga.

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

• [C-4-1] DEVE rispettare l'intent android.settings.ACTION_VOICE_INPUT_SETTINGS per mostrare un menu di impostazioni dell'app predefinito per l'input vocale e l'assistente.

3.2.4. Attività su display secondari

Se le implementazioni del dispositivo consentono di avviare le normali Attività Android su display secondari:

• [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 ridimensionare di conseguenza tutte le attività su una VirtualDisplay se il display stesso viene ridimensionato.
• POTREBBE mostrare un IME (editor del metodo di immissione, un controllo utente che consente agli utenti di inserire testo) sul display principale, quando un campo di immissione di testo viene attivato su un display secondario.
• DEVE implementare lo stato attivo dell'input sul display secondario indipendentemente dal display principale, quando sono supportati gli input tocco o dei tasti.
• 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 i display principali e secondari hanno android.util.DisplayMetrics diversi:

• [C-2-1] Le attività non ridimensionabili (con resizeableActivity=false in AndroidManifest.xml) e le app che hanno come target il livello API 23 o un livello inferiore NON DEVONO essere consentite sui display secondari.

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)

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

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:
  • operazione offline/cache dell'applicazione
  • Tag<video>
  • geolocalizzazione
• [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-SR] È VIVAMENTE CONSIGLIATO di fornire l'invito all'utente dove può visualizzare l'elenco delle app con limitazioni.
• [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 un comportamento inadeguato per lo stato del sistema, ma POTREBBE applicare le limitazioni alle app quando vengono rilevati comportamenti non corretti sullo 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. NON DEVONO essere utilizzati come criteri altri criteri non strettamente correlati all'integrità del sistema, come la scarsa popolarità dell'app nel mercato.
• [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
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36MB
	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
	160 dpi (mdpi)
	213 dpi (tvdpi)	48MB
	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
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	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
	160 dpi (mdpi)	80MB
	213 dpi (tvdpi)	96MB
	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:

• [C-2-1] DEVE segnalare true per ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] DEVE consentire all'utente di chiedere l'autorizzazione prima di aggiungere una scorciatoia richiesta dalle app tramite il metodo API ShortcutManager.requestPinShortcut().
• [C-2-3] DEVE supportare le scorciatoie fissate e le scorciatoie dinamiche e statiche come documentato nella pagina Scorciatoie app.

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

• [C-3-1] DEVE segnalare false per ShortcutManager.isRequestPinShortcutSupported().

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, ad esempio 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:

• [C-2-1] DEVE segnalare true per AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] DEVE consentire all'utente di chiedere l'autorizzazione prima di aggiungere una scorciatoia richiesta dalle app tramite il metodo API AppWidgetManager.requestPinAppWidget().

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.

3.8.4. Cerca

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:

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

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.

• Le implementazioni dei dispositivi POSSONO modificare gli attributi del tema predefinito del dispositivo esposti alle applicazioni.

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:

• [C-2-1] DEVE implementare completamente le API AutofillService e AutofillManager e rispettare l'intent android.settings.REQUEST_SET_AUTOFILL_SERVICE per mostrare un menu di impostazioni dell'app predefinito per attivare e disattivare la compilazione automatica e modificare il servizio di compilazione automatica predefinito per l'utente.

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,

• [C-1-2] DEVE visualizzare lo stato attuale della posizione nel menu Posizione delle Impostazioni.
• [C-1-3] NON DEVE visualizzare le modalità di geolocalizzazione nel menu Posizione nelle Impostazioni.

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.

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] Le applicazioni possono indicare se sono in grado di operare in modalità multi-finestra nel file AndroidManifest.xml, esplicitamente impostando l'attributo android:resizeableActivity su true o implicitamente impostando targetSdkVersion > 24. Le app che impostano esplicitamente questo attributo su false nel file manifest NON DEVONO essere avviate in modalità multi-finestra. Le app meno recenti con targetSdkVersion < 24 e che non impostavano questo attributo android:resizeableActivity POTREBBERO essere avviate in modalità multi-finestra, ma il sistema DEVE inviare un avviso relativo al fatto che l'app potrebbe non funzionare come previsto in modalità multi-finestra.
• [C-1-3] NON DEVE offrire la modalità schermo diviso o formato libero se l'altezza dello schermo è < 440 dp e la larghezza dello schermo < 440 dp.
• 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:
  • Se non sono ancora stati configurati dati utente, l'implementazione del dispositivo:
    • [C-1-3] DEVE segnalare true per DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] DEVE registrare l'applicazione DPC (controller criteri dispositivi) come app del proprietario del dispositivo in risposta all'azione intent android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] DEVE registrare l'applicazione DPC come app del proprietario del dispositivo se il dispositivo dichiara il supporto della tecnologia Near Field Communications (NFC) tramite il flag di funzionalità android.hardware.nfc e riceve un messaggio NFC contenente un record con tipo MIME MIME_TYPE_PROVISIONING_NFC.
  • Quando l'implementazione del dispositivo contiene dati utente:
    • [C-1-6] DEVE segnalare false per DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] Non DEVE più registrare alcuna applicazione DPC come app proprietario del dispositivo.
• [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 (vedi 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:

• [C-1-1] DEVE supportare le API del framework Android TTS.

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 dei dispositivi includono il framework UI che supporta app di terze parti che dipendono da MediaBrowser e MediaSession , queste:

• [C-1-1] DEVE mostrare le icone di MediaItem e le icone di notifica inalterate.
• [C-1-2] DEVE visualizzare questi elementi come descritto da MediaSession, ad esempio metadati, icone e immagini.
• [C-1-3] DEVE mostrare il titolo dell'app.
• [C-1-4] DEVE disporre di un riquadro a scomparsa o di un altro meccanismo per presentare la gerarchia MediaBrowser e fornire l'accettazione dell'utente per la gerarchia MediaBrowser.
• [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 relativi alle app istantanee sul dispositivo, a meno che l'app istantanea non si connetta esplicitamente all'applicazione installata.

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 seguente codifica audio:

• [C-1-1] PCM/WAVE

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
• [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, uno stream 5.0 AAC deve essere decodificato su cinque canali di 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.

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.

5.1.3. Dettagli codec audio

Formato/Codec	Dettagli	Tipi di file/formati container supportati
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)
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.
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.
AAC ELD (AAC a basso ritardo migliorato)	Supporto di contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.
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
FLAC	Mono/Stereo (no multicanale). Frequenze di campionamento fino a 48 kHz (ma fino a 44,1 kHz è CONSIGLIATA su dispositivi con uscita a 44,1 kHz, poiché il downsampler da 48 a 44,1 kHz non include un filtro passa-basso). 16-bit CONSIGLIATA; nessun dither applicato per 24-bit.	Solo FLAC (.flac)
MP3	Costante mono/stereo da 8-320 Kbps (CBR) o velocità in bit variabile (VBR)	MP3 (.mp3)
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) Matroska (.mkv, Android 4.0 e versioni successive)
PCM/WAVE	PCM lineare a 16 bit (ratenze fino al limite dell'hardware). I dispositivi DEVONO supportare le frequenze di campionamento per la registrazione PCM non elaborata alle frequenze 8000, 11025, 16000 e 44100 Hz.	onda (.wav)
Opus		Matroska (.mkv), Ogg(.ogg)

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

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)

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)

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 il formato colore flessibile YUV420 (COLOR_FormatYUV420Flexible).

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.

5.1.8. Elenco codec video

Formato/Codec	Dettagli	Tipi di file supportati/ formati dei container
H.263		3 GPP (0,3 gp) MPEG-4 (.mp4)
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, solo audio AAC, non ricercabile, Android 3.0 e versioni successive)
HEVC H.265	Per informazioni dettagliate, consulta la sezione 5.3.	MPEG-4 (.mp4)
MPEG-2	Profilo principale	MPEG2-TS
MPEG-4 SP		3 GPP (0,3 gp)
VP8	Per informazioni dettagliate, consulta le sezioni 5.2 e 5.3	WebM (.webm) Matroska (.mkv)
VP9	Per informazioni dettagliate, consulta la sezione 5.3.	WebM (.webm) Matroska (.mkv)

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 a circa il 15% rispetto alla velocità in bit tra gli intervalli di 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.

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).
• DEVE supportare la scrittura di file Matroska WebM.
• DEVE utilizzare 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:

• DEVE supportare la scrittura di file Matroska WebM.

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.

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

• [C-2-1] DEVE fornire un estrattore compatibile con Dolby Vision.
• [C-2-2] DEVE visualizzare correttamente i contenuti Dolby Vision sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).
• [C-2-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.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/s^televisore)
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/s^televisore con decodifica hardware H.265)	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

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/s^televisore)	30 (60 f/s^televisore)
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/s^televisore con decodifica hardware VP9)	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

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 CONSIGLIATI VIVAMENTE 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 RAW

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 Hz
  • Canali: mono

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

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

  • Formato: 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, 48.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, 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.

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.

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
• [C-SR] Latenza di output continua al massimo pari a 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:

• [C-SR] VIVAMENTE CONSIGLIATO di segnalare l'audio a bassa latenza dichiarando il flag della funzionalità android.hardware.audio.low_latency.
• [C-SR] VIVAMENTE CONSIGLIATO per soddisfare i requisiti per l'audio a bassa latenza tramite l'API AAudio.
• [C-SR] VIVAMENTE CONSIGLIATO per garantire che per gli stream che restituiscono AAUDIO_PERFORMANCE_MODE_LOW_LATENCY da AAudioStream_getPerformanceMode(), il valore restituito da AAudioStream_getFramesPerBurst() sia inferiore o uguale al valore restituito da android.media.AudioManager.getProperty(String) per la chiave di proprietà AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

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-1-1] NON DEVE segnalare il supporto per audio a bassa latenza.

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

  • Modalità host USB, sezione 7.7
  • Modalità periferica USB, sezione 7.7
  • MIDI over Bluetooth LE con ruolo centrale, sezione 7.4.3

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

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 la latenza audio di andata e ritorno continua, come definita nella sezione 5.6 Latenza audio, DEVE essere pari o inferiore a 20 millisecondi e DEVE essere pari o inferiore a 10 millisecondi su almeno un percorso supportato.
• [C-1-3] DEVE includere una o più porte USB che supportano la modalità host USB e la modalità periferica USB.
• [C-1-4] DEVE segnalare il supporto della funzionalità android.software.midi.
• [C-1-5] DEVE soddisfare i requisiti relativi alle latenze e all'audio USB utilizzando sia la coda del buffer PCM OpenSL ES sia le API audio native AAudio.
• [SR] È VIVAMENTE CONSIGLIATO di fornire un livello coerente di prestazioni della CPU quando l'audio è attivo e il carico della CPU varia. Questo comando deve essere testato utilizzando il commit SimpleSynth 1bd6391. L'app SimpleSynth deve essere eseguita con i parametri seguenti e non deve avere valori inferiori a 10 minuti:
  • Cicli di lavoro: 200.000
  • Carico variabile: ON (cambia tra il 100% e il 10% del valore dei cicli di lavoro ogni 2 secondi ed è progettato per testare il comportamento del governatore della CPU)
  • Carico stabilizzato: OFF
• 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.
• DOVREBBE fornire zero underrun (output) o sovraccarichi (input) 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:

• [SR] CONSIGLIATO VIVAMENTE di segnalare il supporto della funzionalità android.hardware.audio.pro tramite il corso android.content.pm.PackageManager.

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

• [C-2-1] DEVE avere una latenza audio di andata e ritorno continua di 20 millisecondi o meno sul percorso del jack audio.
• [SR] VIVAMENTE CONSIGLIATA di rispettare la sezione Specifiche per i dispositivi mobili (jack) della Specifica delle cuffie audio con cavo (v1.1).
• La latenza audio di andata e ritorno continua DEVE essere di massimo 10 millisecondi sopra il percorso del jack audio.

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.

Se le implementazioni dei dispositivi includono una porta HDMI:

• [C-4-1] DEVE supportare l'uscita in stereo e otto canali a profondità di 20-bit o 24-bit e a 192 kHz senza perdita di profondità di bit o ricampionamento, 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 e cmd stats.
  • [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.

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. I 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'estensione lineare orizzontale o verticale 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 un display con gli angoli arrotondati.

Se le implementazioni dei dispositivi supportano UI_MODE_TYPE_NORMAL e includono un display con angoli arrotondati:

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

Sebbene non vi siano limitazioni al valore delle proporzioni dello schermo fisico, le proporzioni del display logico in cui viene eseguito il rendering delle app di terze parti, che possono essere derivate dai valori di altezza e larghezza riportati tramite le API di view.Display e l'API Configuration, DEVONO soddisfare i seguenti requisiti:

• [C-0-1] Le implementazioni dei dispositivi con il valore Configuration.uiMode impostato su UI_MODE_TYPE_NORMAL DEVONO avere un valore per le proporzioni compreso tra 1,3333 (4:3) e 1,86 (circa 16:9), a meno che l'app non possa essere considerata pronta per essere prolungata soddisfacendo 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 campo 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 seguenti densità del framework Android tramite l'API DENSITY_DEVICE_STABLE e questo valore NON DEVE cambiare in qualsiasi momento; tuttavia, il dispositivo POTREBBE segnalare una densità arbitraria diversa a seconda delle modifiche alla configurazione del display apportate dall'utente (ad esempio, le dimensioni di visualizzazione) impostate dopo l'avvio iniziale.

  • 120 dpi (ldpi)
  • 160 dpi (mdpi)
  • 213 dpi (tvdpi)
  • 240 dpi (hdpi)
  • 260 dpi (260dpi)
  • 280 dpi (280dpi)
  • 300 dpi (300dpi)
  • 320 dpi (xhdpi)
  • 340 dpi (340dpi)
  • 360 dpi (360dpi)
  • 400 dpi (400dpi)
  • 420 dpi (420dpi)
  • 480 dpi (xxhdpi)
  • 560 dpi (560dpi)
  • 640 dpi (xxxhdpi)

• 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 un'uscita schermo o video, questi:

• [C-1-1] DEVE segnalare i valori corretti per tutte le metriche display 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 valori ragionevoli per tutte le metriche di visualizzazione definite 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. Ciò significa che 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.
• [SR] è VIVAMENTE CONSIGLIATO per il supporto di 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 e EGL_ANDROID_recordable.
• I [SR] sono VIVAMENTE CONSIGLIATI per supportare EGL_KHR_partial_update.
• 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.

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.

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:

• [C-3-1] DEVE esporre il supporto per i semafori e i tipi di handle esterni SYNC_FD.
• [SR] È VIVAMENTE CONSIGLIATO di supportare 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 e EGL_KHR_gl_colorspace_display_p3.
• [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 sul display. I dispositivi DEVONO supportare tutte queste API come definito dall'SDK Android, a meno che non siano specificamente consentiti in questo documento.

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare display 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 supportare display in grado di visualizzare le animazioni.
• [C-0-3] DEVE utilizzare la tecnologia di visualizzazione con 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 del display secondario per attivare le funzionalità di condivisione dei contenuti multimediali e delle 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:

• [C-0-1] DEVE includere un meccanismo di inserimento, ad esempio una schermata touchscreen o una navigazione non touch, per navigare tra gli elementi dell'interfaccia utente.

7.2.1. Tastiera

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

• [C-1-1] DEVE dichiarare il flag della funzionalità android.software.input_methods.
• [C-1-2] DEVE implementare completamente Input Management Framework
• [C-1-3] DEVE avere una tastiera software preinstallata.

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:

• [C-0-1] DEVE segnalare il valore corretto per android.content.res.Configuration.navigation.

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-3-1] DEVE rendere disponibile la funzione Menu alle applicazioni quando targetSdkVersion è inferiore a 10 tramite un pulsante fisico, un tasto software o gesti. Questa funzione del menu deve essere accessibile, a meno che non sia nascosta insieme ad altre funzioni di navigazione.

Se le implementazioni del dispositivo offrono la funzione di assistenza, * [C-4-1] DEVE rendere accessibile la funzione di assistenza con una singola azione (ad esempio 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.

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 HID^2	Pulsante Android
R^1	0x09 0x0001	KEYCODE_PULSANTE_A (96)
M^1	0x09 0x0002	KEYCODE_PULSANTE_B (97)
X^1	0x09 0x0004	KEYCODE_PULSANTE_X (99)
A^1	0x09 0x0005	KEYCODE_PULSANTE_Y (100)
D-pad in alto^1 D-pad in basso^1	0x01 0x0039^3	AXIS_HAT_Y^4
D-pad sinistro1 D-pad destro^1	0x01 0x0039^3	AXIS_HAT_X^4
Pulsante sulla spalla sinistra^1	0x09 0x0007	KEYCODE_PULSANTE_L1 (102)
Pulsante sulla spalla destra^1	0x09 0x0008	KEYCODE_PULSANTE_R1 (103)
Clic sulla levetta sinistra^1	0x09 0x000E	KEYCODE_button_THUMBL (106)
Clic sulla levetta destra^1	0x09 0x000F	KEYCODE_Button_THUMBR (107)
Home page^1	0x0c 0x0223	KEYCODE_HOME (3)
Indietro^1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Gli utilizzi dell'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 analogici^1	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 sensore in streaming con una latenza minima richiesta di 5 ms + 2 * sample_time 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(). I dispositivi Android nuovi ed esistenti sono CONSIGLIATI VIVAMENTE per soddisfare questi requisiti, 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

• Le implementazioni del dispositivo DEVONO 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 frequenza di campionamento più elevata.
• I [SR] sono CONSIGLIATI VIVAMENTE per implementare il sensore composito TYPE_SIGNIFICANT_MOTION.
• [SR] è VIVAMENTE CONSIGLIATO di implementare il sensore TYPE_ACCELEROMETER_UNCALIBRATED se è disponibile la calibrazione dell'accelerometro online.
• 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.
• DOVREBBE anche implementare il sensore TYPE_ACCELEROMETER_UNCALIBRATED.

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 giroscopico, questi:

• [C-3-1] DEVE implementare i sensori composti TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• DOVREBBE implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.
• [SR] È VIVAMENTE CONSIGLIATO di implementare il sensore TYPE_GAME_ROTATION_VECTOR sui dispositivi Android nuovi ed esistenti.

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

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

7.3.2. Magnetometro

• Le implementazioni del dispositivo DEVONO includere un magnetometro a 3 assi (bussola).

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 dei dispositivi includono un magnetometro a 3 assi, un sensore accelerometro e un sensore giroscopio, 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:

• DEVE 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-1-5] DEVE segnalare la generazione di tecnologia GNSS tramite l'API di test "getGnssYearOfHardware".
  • [SR] Continua a fornire i normali output di posizione GPS/GNSS durante una chiamata di emergenza.
  • [SR] Registra le misurazioni GNSS di tutte le costellazioni monitorate (come riportate nei messaggi GnssStatus), ad eccezione di SBAS.
  • [SR] Report AGC e frequenza della misurazione GNSS.
  • [SR] Segnala tutte le stime di accuratezza (incluse orientamento, velocità e verticale) come parte di ciascuna posizione GPS/GNSS.
  • [SR] è VIVAMENTE CONSIGLIATO di soddisfare il maggior numero possibile di requisiti obbligatori aggiuntivi per i dispositivi che riportano l'anno "2016" o "2017" tramite l'API Test LocationManager.getGnssYearOfHardware().

Se le implementazioni dei dispositivi includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag della funzionalità android.hardware.location.gps e l'API di test LocationManager.getGnssYearOfHardware() riporta l'anno "2016" o più, questi:

• [C-2-1] DEVE riportare le misurazioni GNSS, non appena vengono rilevate, anche se non è stata ancora riportata una posizione calcolata da GPS/GNSS.
• [C-2-2] DEVE riportare gli pseudorange e i tassi di pseudointervallo del GNSS, che, in condizioni di cielo aperto dopo aver determinato la posizione, se 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% delle volte.

Se le implementazioni dei dispositivi includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag della funzionalità android.hardware.location.gps e l'API di test LocationManager.getGnssYearOfHardware() riporta l'anno "2017" o più, questi:

• [C-3-1] DEVE continuare a fornire i normali output di posizione GPS/GNSS durante una chiamata di emergenza.
• [C-3-2] DEVE riportare le misurazioni GNSS provenienti da tutte le costellazioni tracciate (come riportate nei messaggi GnssStatus), ad eccezione di SBAS.
• [C-3-3] DEVE riportare l'AGC e la frequenza della misurazione GNSS.
• [C-3-4] DEVE riportare tutte le stime di accuratezza (incluse orientamento, velocità e verticale) come parte di ciascuna posizione GPS/GNSS.

Se le implementazioni dei dispositivi includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag della funzionalità android.hardware.location.gps e l'API di test LocationManager.getGnssYearOfHardware() riporta l'anno "2018" o più, questi:

• [C-4-1] DEVE continuare a fornire le normali uscite GPS/GNSS alle applicazioni durante una chiamata a una sessione di emergenza avviata dalla rete (Mobile Station Based (MS-Based)).
• [C-4-2] DEVE segnalare posizioni e misurazioni all'API del fornitore di località GNSS.

7.3.4. Giroscopio

Implementazioni dei dispositivi:

• DEVE includere un giroscopio (sensore a variazione angolare).
• NON DEVE includere un sensore giroscopico a meno che non sia incluso anche un accelerometro a 3 assi.

Se le implementazioni dei dispositivi includono un giroscopio, questi:

• [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 e DEVE implementare anche il sensore TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-3] DEVE essere in grado di misurare cambiamenti di orientamento fino a 1000 gradi al secondo.
• [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] È VIVAMENTE CONSIGLIATO di implementare il sensore SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sui dispositivi Android nuovi ed esistenti.
• [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, un sensore dell'accelerometro e un sensore magnetometro, questi:

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

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

• [C-3-1] DEVE implementare i sensori composti TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [SR] È VIVAMENTE CONSIGLIATO di implementare il sensore TYPE_GAME_ROTATION_VECTOR sui dispositivi Android nuovi ed esistenti.
• DOVREBBE implementare il sensore composito TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometro

• Le implementazioni del dispositivo DEVONO 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 del dispositivo: * 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 che:
  • È 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 4 mW.
• [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.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• 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

7.3.10.1. Sensori di impronte digitali

Se le implementazioni dei dispositivi includono una schermata di blocco sicura:

• DEVE includere un sensore di impronte digitali.

Se le implementazioni dei dispositivi includono un sensore di impronte digitali e lo rendono disponibile per app di terze parti, questi:

• [C-1-1] DEVE dichiarare il supporto per la funzionalità android.hardware.fingerprint.
• [C-1-2] DEVE implementare completamente l'API corrispondente come descritto nella documentazione dell'SDK per Android.
• [C-1-3] DEVE avere un tasso di falsa accettazione non superiore allo 0,002%.
• [SR] È VIVAMENTE CONSIGLIATO avere un tasso di accettazione di spoofing e impostori non superiore al 7%.
• [C-1-4] DEVE comunicare che questa modalità potrebbe essere meno sicura di una sequenza, una password o un PIN efficaci ed indicare chiaramente i rischi che comporta l'attivazione di tale modalità, se i tassi di accettazione di spoofing e impostori sono superiori al 7%.
• [C-1-5] DEVE limitare la frequenza dei tentativi per almeno 30 secondi dopo cinque false prove di verifica dell'impronta.
• [C-1-6] DEVE avere un'implementazione di un archivio chiavi supportato da hardware ed eseguire la corrispondenza delle impronte in un ambiente di esecuzione affidabile (Trusted Execution Environment, TEE) o su un chip con un canale sicuro verso il TEE.
• [C-1-7] DEVE avere tutti i dati relativi alle impronte identificabili criptati e autenticati tramite crittografia in modo che non possano essere acquisiti, letti o alterati al di fuori del TEE o di un chip con un canale sicuro per il TEE, come documentato nelle linee guida sull'implementazione sul sito Android Open Source Project.
• [C-1-8] DEVE impedire l'aggiunta di un'impronta senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare l'esistenza o aggiungere una nuova credenziale del dispositivo (PIN/pattern/password) protetta da TEE; l'implementazione di Android Open Source Project fornisce il meccanismo nel framework per farlo.
• [C-1-9] NON DEVE consentire alle applicazioni di terze parti di distinguere tra le singole fingerprint.
• [C-1-10] DEVE rispettare il flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• [C-1-11] DEVE, quando viene eseguito l'upgrade da una versione precedente ad Android 6.0, i dati relativi alle impronte digitali in sicurezza per soddisfare i requisiti riportati sopra oppure rimuoverli.
• [C-1-12] DEVE rimuovere completamente tutti i dati identificabili relativi alle impronte di un utente quando il suo account viene rimosso (anche tramite un ripristino dei dati di fabbrica).
• [C-1-13] Non DEVE consentire l'accesso non criptato a dati fingerprint identificabili o a qualsiasi dato derivato da questi (come gli incorporamenti) al responsabile delle applicazioni.
• [SR] È VIVAMENTE CONSIGLIATO avere un tasso di rifiuto errato inferiore al 10%, come misurato sul dispositivo.
• [SR] È VIVAMENTE CONSIGLIATO avere una latenza inferiore a 1 secondo, misurata dal momento in cui si tocca il sensore di impronte digitali fino allo sblocco dello schermo, per un dito registrato.
• DEVE utilizzare l'icona dell'impronta di Android fornita nell'Android Open Source Project.

7.3.10.2. Altri sensori biometrici

Se le implementazioni dei dispositivi includono uno o più sensori biometrici non basati sulle impronte e li mettono a disposizione di app di terze parti:

• [C-1-1] DEVE avere un tasso di falsa accettazione non superiore allo 0,002%.
• [C-SR] È VIVAMENTE CONSIGLIATO avere un tasso di accettazione di spoofing e impostori non superiore al 7%.
• [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, dove una prova falsa è una con una qualità di acquisizione adeguata (ACQUIRED_GOOD) che non corrisponde a una prova biometrica registrata
• [C-1-4] DEVE avere un'implementazione di un archivio chiavi supportato da hardware ed eseguire la corrispondenza biometrica in un TEE o su un chip con un canale sicuro al TEE.
• [C-1-5] DEVE avere tutti i dati identificabili criptati e autenticati tramite crittografia in modo che non possano essere acquisiti, letti o alterati al di fuori del TEE o di un chip con un canale sicuro per il TEE, come documentato nelle linee guida sull'implementazione sul sito Android Open Source Project.
• [C-1-6] 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-7] NON DEVE consentire alle applicazioni di terze parti di distinguere tra registrazioni biometriche.
• [C-1-8] 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-9] 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-10] DEVE non consentire l'accesso non criptato a dati biometrici identificabili o a qualsiasi dato derivato (come gli incorporamenti) al Responsabile delle applicazioni al di fuori del contesto del TEE.
• [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.

7.3.11. Sensori solo per Android Automotive

I sensori specifici del settore automobilistico sono definiti in android.car.CarSensorManager API.

7.3.11.1. Attrezzo attuale

Consulta la Sezione 2.5.1 per i requisiti specifici del dispositivo.

7.3.11.2. Modalità Giorno/Notte

Consulta la Sezione 2.5.1 per i requisiti specifici del dispositivo.

7.3.11.3. Stato di guida

Questo requisito è stato ritirato.

7.3.11.4. Velocità della ruota

Consulta la Sezione 2.5.1 per i requisiti specifici del dispositivo.

7.3.11.5. Freno di stazionamento

Consulta la Sezione 2.5.1 per i requisiti specifici del dispositivo.

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.

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-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-SR] È VIVAMENTE CONSIGLIATO, quando viene chiamato il metodo API ConnectivityManager.reportNetworkConnectivity(), di rivalutare l'accesso a internet su Network e, una volta che la valutazione determina che l'attuale Network non fornisce più l'accesso a internet, passare a qualsiasi altra rete disponibile (ad es. dati mobili) che fornisca l'accesso a internet.
• [C-SR] È VIVAMENTE CONSIGLIATO di randomizzare l'indirizzo MAC di origine e il numero di sequenza dei frame di richiesta 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 supportano il Wi-Fi e utilizzano il Wi-Fi per la ricerca della posizione, questi:

• [C-2-1] DEVE fornire un'invito all'utente per abilitare/disabilitare il valore letto tramite il metodo API WifiManager.isScanAlwaysAvailable.

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.

7.4.2.2. Configurazione del collegamento diretto tramite tunnel Wi-Fi

Implementazioni dei dispositivi:

• DOVREBBE includere il supporto per la configurazione del collegamento diretto tramite tunnel Wi-Fi (TDLS) come descritto nella documentazione dell'SDK Android.

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:

• DEVE includere il supporto per Wi-Fi Aware.

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:

• [C-2-1] DEVE implementare le API di rilevamento della posizione: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscovered WithinRange.

7.4.2.4. Passpoint Wi-Fi

Implementazioni dei dispositivi:

• DEVE includere il supporto per Passpoint Wi-Fi.

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:

• DEVE includere il supporto della posizione Wi-Fi.

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.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().

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 vivamente consigliati di soddisfare questi requisiti ora in modo da poter eseguire l'upgrade alle future release della piattaforma.

• [C-1-3] DEVE essere in grado di trasmettere e ricevere dati attraverso i seguenti standard e protocolli peer-to-peer:

  • ISO 18092
  • LLCP 1.2 (definito dall'NFC Forum)
  • SDP 1.0 (definito dall'NFC Forum)
  • Protocollo push NDEF
  • SNEP 1.0 (definito dall'NFC Forum)
• [C-1-4] DEVE includere il supporto per Android Beam e DEVE attivare Android Beam per impostazione predefinita.
• [C-1-5] DEVE essere in grado di inviare e ricevere messaggi tramite Android Beam se è attiva la funzionalità Android Beam o è attiva un'altra modalità NFC proprietaria P2p.
• [C-1-6] DEVE implementare il server predefinito SNEP. I messaggi NDEF validi ricevuti dal server SNEP predefinito DEVONO essere inviati alle applicazioni utilizzando l'intent android.nfc.ACTION_NDEF_DISCOVERED. La disattivazione di Android Beam nelle impostazioni NON DEVE disattivare l'invio di messaggi NDEF in arrivo.
• [C-1-7] DEVE rispettare l'intent android.settings.NFCSHARING_SETTINGS per mostrare le impostazioni di condivisione NFC.
• [C-1-8] DEVE implementare il server NPP. I messaggi ricevuti dal server NPP DEVONO essere elaborati allo stesso modo del server predefinito SNEP.
• [C-1-9] DEVE implementare un client SNEP e tentare di inviare NDEF P2P in uscita al server SNEP predefinito quando Android Beam è abilitato. Se non viene trovato alcun server SNEP predefinito, il client DEVE tentare di inviare a un server NPP.
• [C-1-10] DEVE consentire alle attività in primo piano di impostare il messaggio NDEF P2P in uscita utilizzando android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback e android.nfc.NfcAdapter.enableForegroundNdefPush.
• DEVI utilizzare un gesto o una conferma sullo schermo, ad esempio "Tocca per trasmettere", prima di inviare messaggi P2P NDEF in uscita.
• [C-1-11] DEVE supportare il trasferimento della connessione NFC a Bluetooth quando il dispositivo supporta Bluetooth Object Push Profile.
• [C-1-12] DEVE supportare il trasferimento della connessione a Bluetooth quando si utilizza android.nfc.NfcAdapter.setBeamPushUris, implementando le specifiche "Connection Handover versione 1.2" e "Bluetooth Secure Simple Pairing Using NFC versione 1.0" del forum NFC. Tale implementazione DEVE implementare il servizio LLCP di passaggio con il nome del servizio "urn:nfc:sn:handover" per lo scambio della richiesta di trasferimento/dei record di selezione tramite NFC e DEVE utilizzare il Bluetooth Object Push Profile per l'effettivo trasferimento di dati Bluetooth. Per motivi legacy (per rimanere compatibile con i dispositivi Android 4.1), l'implementazione DEVE comunque accettare richieste SNEP GET per lo scambio della richiesta di passaggio/selezione dei record tramite NFC. Tuttavia, un'implementazione stessa NON DEVE inviare richieste SNEP GET per l'esecuzione del trasferimento della connessione.
• [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:

• [C-1-1] DEVE supportare tutte le API nella classe ConnectivityManager come descritto nella documentazione dell'SDK
• [C-1-2] DEVE fornire nelle impostazioni un'interfaccia utente che gestisca l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, consentendo agli utenti di aggiungere o rimuovere applicazioni dalla lista consentita.

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:

• [C-1-1] DEVE enumerare i lettori Secure Element disponibili quando viene chiamato il metodo android.se.omapi.SEService.getReaders().

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.

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 e la qualità delle immagini acquisite deve 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 comunque essere "false" come descritto.
• [C-0-6] DEVE riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters. 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-SR] È VIVAMENTE CONSIGLIATO di supportare un dispositivo con fotocamera logica che elenca le funzionalità CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, per i dispositivi con più videocamere rivolte nella stessa direzione, ovvero ciascuna videocamera fisica rivolta in quella direzione, purché il tipo di fotocamera fisica sia supportato dal framework e CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL per le fotocamere fisiche è LIMITED, FULL o LEVEL_3.

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. L'archivio condiviso DEVE essere altrimenti scrivibile da qualsiasi applicazione che ottiene tale autorizzazione.

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

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:

• [SR] VIVAMENTE CONSIGLIATO di implementare lo spazio di archiviazione utilizzabile.

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 CONSIGLIATI VIVAMENTE per soddisfare questi requisiti, in modo da essere in grado di 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 CONSIGLIATI VIVAMENTE per soddisfare questi requisiti, in modo da essere in grado di 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 CONSIGLIATI VIVAMENTE per soddisfare questi requisiti, in modo da essere in grado di 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).
• [SR] VIVAMENTE CONSIGLIATO 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 di supportare la 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.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.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 acceso fino al giorno 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:

• [C-0-1] DEVE segnalare in modo preciso il supporto della modalità di rendimento sostenuto tramite il metodo API PowerManager.isSustainedPerformanceModeSupported().

• DEVE supportare la modalità di rendimento sostenuto.

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:

• [C-3-1] DEVE restituire un elenco vuoto tramite il metodo API Process.getExclusiveCores().

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.

Se le implementazioni dei dispositivi includono un'app preinstallata o vuoi consentire ad app di terze parti di accedere alle statistiche sull'utilizzo:

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

• [C-0-1] DEVE supportare il modello di autorizzazioni di accesso ai file Android come definito nel riferimento su sicurezza e autorizzazioni.

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.

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

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

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

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

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 protezioni contro l'overflow del buffer dello stack del kernel (ad esempio, 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 su tutti i dispositivi originariamente forniti con livello API 28 o superiore (ad es. CONFIG_PAGE_TABLE_ISOLATION o "CONFIG_UNMAP_KERNEL_AT_EL0).
• [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).
• [SR] VIVAMENTE CONSIGLIATO per randomizzare il layout del codice e della memoria del kernel, nonché per 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).

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.

Implementazioni dei dispositivi:

• [C-SR] È VIVAMENTE CONSIGLIATO di non disattivare l'integrità del flusso di controllo (CFI) o la sanificazione dell'overflow intero (IntSan) sui componenti su cui è abilitata.
• [C-SR] È VIVAMENTE CONSIGLIATO di abilitare sia CFI che IntSan per eventuali componenti aggiuntivi dello spazio utente sensibili alla sicurezza, come spiegato in CFI e IntSan.

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) fuori dal dispositivo senza il consenso dell'utente o cancellare le notifiche in corso.

Se le implementazioni dei dispositivi includono nel sistema funzionalità che acquisiscono i contenuti visualizzati sullo schermo e/o registrano lo stream audio riprodotto sul dispositivo:

• [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à pronto all'uso in grado di registrare l'audio ambientale 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,9 Crittografia archiviazione dati

Se le prestazioni crittografiche Advanced Encryption Standard (AES), misurate con la tecnologia AES più performante disponibile sul dispositivo (ad es. le estensioni ARM Cryptography), sono superiori a 50 MiB/sec, implementazioni dispositivo:

• [C-1-1] DEVE supportare la crittografia dell'archiviazione dei dati dei dati privati dell'applicazione (partizione /data), così come la partizione dello spazio di archiviazione condiviso dell'applicazione (partizione /sdcard) se si tratta di una parte permanente e non rimovibile del dispositivo, ad eccezione delle implementazioni dei dispositivi che in genere vengono condivise (ad esempio, la televisione).
• [C-1-2] DEVE attivare la crittografia dello spazio di archiviazione dei dati per impostazione predefinita quando l'utente ha completato l'esperienza di configurazione pronta all'uso, ad eccezione delle implementazioni dei dispositivi che sono tipicamente condivise (ad esempio, i televisori).

Se le prestazioni delle criptovalute AES sono pari o inferiori a 50 MiB/sec, le implementazioni dei dispositivi POSSONO utilizzare Adiantum-XChaCha12-AES anziché il formato AES elencato in uno qualsiasi dei seguenti formati: AES-256-XTS nella Sezione 9.9.2 [C-1-5]; AES-256 in modalità CBS-CTS nella Sezione 2-CtS.

Se le implementazioni dei dispositivi sono già state lanciate su una versione precedente di Android e non possono soddisfare i requisiti tramite un aggiornamento software di sistema, POTREBBE essere esentate dai requisiti di cui sopra.

Implementazioni dei dispositivi:

• DEVONO 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.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. Crittografia basata su file

Se le implementazioni dei dispositivi supportano FBE:

• [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 supportare l'Avvio verificato e garantire che le chiavi DE siano associate tramite crittografia alla radice di attendibilità hardware del dispositivo.
• [C-1-5] DEVE supportare la crittografia dei contenuti dei file utilizzando AES-256-XTS. AES-256-XTS si riferisce all'Advanced Encryption Standard con una lunghezza della chiave di 256 bit, operata in modalità XTS. L'intera lunghezza della chiave XTS è di 512 bit.

• [C-1-6] DEVE supportare la crittografia dei nomi dei file utilizzando AES-256 in modalità CBC-CTS.

• 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 per impostazione predefinita crittografie, lunghezze della chiave e modalità 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.

• POTREBBE supportare modalità e lunghezze delle chiavi alternative per la crittografia dei file e per la crittografia dei nomi dei file.

Il progetto open source Android upstream fornisce un'implementazione preferita di questa funzionalità basata sulla funzionalità di crittografia ext4 del kernel Linux.

9.9.3. Crittografia completa del disco

Se le implementazioni dei dispositivi supportano la crittografia completa del disco (FDE):

• [C-1-1] DEVE utilizzare AES in una modalità progettata per l'archiviazione (per esempio, XTS o CBC-ESSIV) e con una lunghezza di chiave di crittografia di 128 bit o superiore.
• [C-1-2] DEVE utilizzare un passcode predefinito per eseguire il wrapping della chiave di crittografia e NON DEVE scrivere la chiave di crittografia nello spazio di archiviazione in nessun momento senza essere criptata.
• [C-1-3] DEVE crittografare la chiave di crittografia per impostazione predefinita a meno che l'utente non disattivi esplicitamente la crittografia, tranne quando è in uso attivo, con le credenziali della schermata di blocco allungate utilizzando un algoritmo di stretching lento (ad esempio, PBKDF2 o scrypt).
• [C-1-4] L'algoritmo di stretching della password predefinito di cui sopra DEVE essere crittograficamente vincolato a tale archivio chiavi quando l'utente non ha specificato le credenziali della schermata di blocco o ha disattivato l'uso del passcode per la crittografia e il dispositivo fornisce un archivio chiavi supportato dall'hardware.
• [C-1-5] NON DEVE inviare la chiave di crittografia dal dispositivo (nemmeno se il dispositivo è aggregato con il passcode dell'utente e/o la chiave associata all'hardware).

Il progetto open source Android upstream fornisce un'implementazione preferita di questa funzionalità, basata sulla funzionalità kernel Linux dm-crypt.

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 indica 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 /system, che è protetta dall'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:

• [C-R] È CONSIGLIATO di supportare l'API Android Protected Confirmation.

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 l'hardware sicuro assuma il pieno controllo del display in modo che il sistema operativo Android non possa bloccarlo senza che venga rilevato dall'hardware protetto.
• [C-3-3] DEVE garantire che l'hardware sicuro assuma il pieno controllo del touchscreen.

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

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.

9.11.1. Schermata di blocco sicura

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:

• [C-2-1] DEVE essere il metodo di autenticazione utente descritto nella sezione Richiedere l'autenticazione utente per l'utilizzo della chiave.
• [C-2-2] DEVE sbloccare tutti i tasti che un'app sviluppatore di terze parti può utilizzare quando l'utente sblocca la schermata di blocco sicura. Ad esempio, tutte le chiavi DEVONO essere disponibili per un'app per sviluppatori di terze parti tramite API pertinenti, come createConfirmDeviceCredentialIntent e setUserAuthenticationRequired.

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.

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.2.
• [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 principale consigliata per sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio della funzionalità keGuard 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).
• [C-4-4] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) almeno una volta ogni 72 ore o meno.
• [C-4-5] DEVE avere un tasso di accettazione falsa uguale o superiore a quello richiesto per un sensore di impronte digitali come descritto nella sezione 7.3.10 oppure DEVE essere disattivato e consentire l'autenticazione primaria consigliata per sbloccare lo schermo soltanto se l'applicazione del controller dei criteri dei dispositivi (Device Policy Controller) (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva rispetto a PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-SR] È VIVAMENTE CONSIGLIATO di avere tassi di accettazione di spoofing e impostori pari o superiori a quelli richiesti per un sensore di impronte digitali, come descritto nella sezione 7.3.10.
• [C-4-6] 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.
• [C-4-7] DEVE essere abbinata a un'azione di conferma esplicita (ad esempio la pressione di un pulsante) per consentire l'accesso alle chiavi dell'archivio chiavi se l'applicazione imposta true per KeyGenParameterSpec.Built.setUserAuthenticationRequired() e la biometria è passiva (ad esempio faccia o iris in assenza di un segnale di intenzione esplicito).
• [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 i metodi di autenticazione biometrica non soddisfano i tassi di accettazione di spoofing e impostori 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 72 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 un'indicazione chiara nel menu Impostazioni e nella schermata di blocco quando il blocco del dispositivo viene posticipato o può essere 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 sullo stesso dispositivo in cui viene utilizzata. 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 verifica per uno dei metodi di autenticazione primaria consigliati (ad es. PIN, sequenza, password) almeno una volta ogni 72 ore o meno.
• [C-7-9] L'utente DEVE essere interrogato per uno dei metodi di autenticazione primaria consigliati (ad es. 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-7-10] NON DEVE essere considerato come una schermata di blocco sicura e DEVE seguire i vincoli elencati in C-8 di seguito.

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 autenticare l'accesso agli archivi chiavi quando l'applicazione imposta true per KeyGenParameterSpec.Builder.setUserAuthenticationRequired().

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.

Implementazioni dei dispositivi:

• [C-SR] È VIVAMENTE CONSIGLIATO per il supporto di StrongBox.

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.

• [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 generati dagli utenti. In altre parole, tutti i dati, eccetto i seguenti:
  • L'immagine di sistema
  • Tutti i file del sistema operativo richiesti dall'immagine di sistema
• [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 è CONSIGLIATO di apportare il numero minimo di modifiche possibile al riferimento e all'implementazione preferita di Android disponibili nel progetto open source Android. 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 9.

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.

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:

• [C-3-1] DEVE implementare il comportamento descritto nella classe SystemUpdatePolicy.

12. Log delle modifiche del documento

Per un riepilogo delle modifiche alla definizione di compatibilità in questa release:

• Log delle modifiche dei documenti

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.