Definizione di compatibilità di Android 9

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

1. Introduzione

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

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

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

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

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

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

Molte delle risorse a cui si fa riferimento in questo documento derivano direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni riportate nella documentazione dell'SDK. In tutti i casi in cui questa definizione di compatibilità o la suite di test di compatibilità non è in linea con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Eventuali dettagli tecnici forniti nelle risorse collegate in questo documento sono considerati parte di questa definizione di compatibilità.

1.1 Struttura del documento

1.1.1. Requisiti per tipo di dispositivo

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

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

1.1.2. ID requisito

L'ID requisito viene assegnato per i requisiti MUST.

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

Ogni ID è definito come segue:

• ID tipo di dispositivo (scopri di più in 2. Tipi di dispositivi)
  • C: Core (requisiti applicati a qualsiasi implementazione del dispositivo Android)
  • H: dispositivo palmare Android
  • T: dispositivo Android TV
  • A: Implementazione di Android Automotive
  • Scheda: implementazione del tablet Android
• ID condizione
  • Quando il requisito è incondizionato, questo ID viene impostato su 0.
  • Quando il requisito è condizionale, viene assegnato 1 per la prima condizione e il numero aumenta di 1 all'interno della stessa sezione e dello stesso tipo di dispositivo.
• ID requisito
  • Questo ID inizia da 1 e aumenta di 1 all'interno della stessa sezione e della stessa condizione.

1.1.3. ID requisito nella Sezione 2

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

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

2. Tipi di dispositivi

Sebbene il progetto open source Android fornisca uno stack software che può essere utilizzato per una serie di tipi di dispositivi e fattori di forma, esistono alcuni tipi di dispositivi che hanno un ecosistema di distribuzione delle applicazioni relativamente più consolidato.

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

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

2.1 Configurazioni del dispositivo

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

2.2. Requisiti del dispositivo portatile

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

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

• Avere una fonte di alimentazione che offra mobilità, ad esempio una batteria.
• Avere una dimensione dello schermo in diagonale fisica compresa tra 6,35 e 20,32 cm.

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

2.2.1. Hardware

Implementazioni dei dispositivi portatili:

• [7.1.1.1/H-0-1] DEVE avere uno schermo con dimensioni fisiche diagonali di almeno 6,35 cm.
• [7.1.1.3/H-SR] È MOLTO CONSIGLIATO fornire agli utenti un'opzione per modificare le dimensioni del display (densità dello schermo).

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

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

Implementazioni dei dispositivi portatili:

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

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

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

Se le implementazioni dei dispositivi palmari includono un giroscopio, devono:

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

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

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

Implementazioni dei dispositivi portatili:

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

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

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

Implementazioni dei dispositivi portatili:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implementazioni dei dispositivi portatili:

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

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

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

Implementazioni dei dispositivi portatili:

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

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

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

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 MPEG-4 AAC (AAC LC)
• [5.1.1/H-0-4] Profilo MPEG-4 HE AAC (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 per le applicazioni di terze parti:

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

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

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

2.2.3. Software

Implementazioni dei dispositivi portatili:

• [3.2.3.1/H-0-1] DEVE avere un'applicazione che gestisca gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE e ACTION_CREATE_DOCUMENT come descritto nei documenti dell'SDK e che fornisca all'utente la possibilità di accedere ai dati del provider di documenti utilizzando l'API DocumentsProvider.
• [3.4.1/H-0-1] DEVE fornire un'implementazione completa dell'API android.webkit.Webview.
• [3.4.2/H-0-1] DEVE includere un'applicazione di browser autonoma per la navigazione web degli utenti generici.
• [3.8.1/H-SR] È FORTEMENTE CONSIGLIATO implementare un Avvio app predefinito che supporti il bloccaggio in-app di scorciatoie, widget e widgetFeatures.
• [3.8.1/H-SR] È FORTEMENTE CONSIGLIATO implementare un Avvio app predefinito che fornisca un accesso rapido alle scorciatoie aggiuntive fornite dalle app di terze parti tramite l'API ShortcutManager.
• [3.8.1/H-SR] È MOLTO CONSIGLIATO includere un'app di avvio predefinita che mostri i badge per le icone delle app.
• [3.8.2/H-SR] Sono FORTEMENTE CONSIGLIATI per supportare i widget di app di terze parti.
• [3.8.3/H-0-1] DEVE consentire alle app di terze parti di notificare agli utenti eventi importanti tramite le classi API Notification e NotificationManager.
• [3.8.3/H-0-2] DEVE supportare le notifiche avanzate.
• [3.8.3/H-0-3] DEVE supportare le notifiche in primo piano.
• [3.8.3/H-0-4] DEVE includere una tendina delle notifiche, che consenta all'utente di controllare direttamente (ad es. rispondere, posticipare, ignorare, bloccare) le notifiche tramite elementi di usabilità come i pulsanti di azione o il pannello di controllo come implementato in AOSP.
• [3.8.3/H-0-5] DEVE mostrare le scelte fornite tramite RemoteInput.Builder setChoices() nell'area notifiche.
• [3.8.3/H-SR] È FORTEMENTE CONSIGLIATO di mostrare la prima scelta fornita tramite RemoteInput.Builder setChoices() nella barra delle notifiche senza ulteriore interazione dell'utente.
• [3.8.3/H-SR] È MOLTO CONSIGLIATO mostrare tutte le opzioni fornite tramite RemoteInput.Builder setChoices() nell'area notifiche quando l'utente espande tutte le notifiche nell'area notifiche.
• [3.8.4/H-SR] È FORTEMENTE CONSIGLIATO implementare un assistente sul dispositivo per gestire l'azione di assistenza.

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

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

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

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

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

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

Implementazioni dei dispositivi portatili:

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

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

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

2.2.4. Prestazioni e potenza

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

Implementazioni dei dispositivi portatili:

• [8.2/H-0-1] DEVE garantire prestazioni di scrittura sequenziale di almeno 5 MB/s.
• [8.2/H-0-2] DEVE garantire prestazioni di scrittura casuale di almeno 0,5 MB/s.
• [8.2/H-0-3] DEVE garantire 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 del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP:

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

Implementazioni dei dispositivi portatili:

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

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

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

2.2.5. Modello di sicurezza

Implementazioni dei dispositivi portatili:

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

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

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

2.3. Requisiti della TV

Un dispositivo Android TV è un'implementazione di un dispositivo Android che funge da interfaccia di intrattenimento per l'utilizzo di contenuti multimediali digitali, film, giochi, app e/o TV in diretta per gli utenti seduti a circa tre metri di distanza (un'interfaccia utente "lean back" o "10-foot").

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

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

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

2.3.1. Hardware

Implementazioni dei dispositivi TV:

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

Se le implementazioni dei dispositivi TV includono un giroscopio:

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

Implementazioni dei dispositivi TV:

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

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

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

Se le implementazioni dei dispositivi TV sono a 32 bit:

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

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

Se le implementazioni dei dispositivi TV sono a 64 bit:

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

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

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

Implementazioni dei dispositivi TV:

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

2.3.2. Multimediale

Le implementazioni dei dispositivi TV DEVONO supportare i seguenti formati di codifica audio:

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

Le implementazioni dei dispositivi TV DEVONO supportare i seguenti formati di codifica video:

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

Implementazioni dei dispositivi TV:

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

Le implementazioni dei dispositivi TV DEVONO supportare i seguenti formati di decodifica video:

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

È FORTEMENTE CONSIGLIATO che le implementazioni dei dispositivi TV supportino i seguenti formati di decodifica video:

• [5.3.1/T-SR] MPEG-2

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

• [5.3.4.4/T-1-1] HD 1080p a 60 frame al secondo con profilo Base
• [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 High Profile Level 4.2

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

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

Se le implementazioni dei dispositivi TV con decodificatori hardware H.265 supportano la decodifica H.265 e il profilo di decodifica UHD:

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

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

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

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

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

Se le implementazioni dei dispositivi TV con decodificatori hardware VP9 supportano la decodifica VP9 e il profilo di decodifica UHD:

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

Implementazioni dei dispositivi TV:

• [5.5.3/T-0-1] DEVE includere il supporto del volume principale del sistema e dell'attenuazione del volume dell'uscita audio digitale sulle uscite supportate, ad eccezione dell'uscita passthrough audio compresso (in cui non viene eseguita alcuna decodifica audio sul dispositivo).
• [5.8/T-0-1] È NECESSARIO impostare la modalità di uscita HDMI in modo da selezionare la risoluzione massima che può essere supportata con una frequenza di aggiornamento di 50 Hz o 60 Hz per tutti i display con cavo.
• [5.8/T-SR] È FORTEMENTE CONSIGLIATO fornire un selettore della frequenza di aggiornamento HDMI configurabile dall'utente per tutti i display con cavo.
• [5.8/T-SR] Sono FORTEMENTE CONSIGLIATI per supportare la decodifica simultanea di stream sicuri. È MOLTO CONSIGLIATO, come minimo, la decodifica simultanea di due stream.
• [5.8] DEBBA impostare la frequenza di aggiornamento della modalità di uscita HDMI su 50 Hz o 60 Hz, a seconda della frequenza di aggiornamento video per la regione in cui il dispositivo viene venduto, per tutti i display con cavo.

Se le implementazioni dei dispositivi TV supportano la decodifica UHD e supportano i display esterni, devono:

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

Se le implementazioni dei dispositivi TV non supportano la decodifica UHD, ma supportano gli schermi esterni:

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

2.3.3. Software

Implementazioni dei dispositivi TV:

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

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

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

Implementazioni dei dispositivi TV:

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

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

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

Implementazioni dei dispositivi TV:

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

2.3.4. Prestazioni e potenza

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

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

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

Implementazioni dei dispositivi TV:

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

2.4. Requisiti dell'orologio

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

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

• Avere uno schermo con una lunghezza diagonale fisica compresa tra 28 e 64 mm.
• Avere un meccanismo che ne consenta l'uso a contatto con il corpo.

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

2.4.1. Hardware

Guarda le implementazioni dei dispositivi:

• [7.1.1.1/W-0-1] DEVE avere uno schermo con dimensioni fisiche diagonali comprese tra 2,8 e 6,35 cm.

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

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

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

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

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

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

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

• [7.8.2/W] POTREBBE, ma NON DEVE, avere un'uscita audio.

2.4.2. Multimediale

Nessun altro requisito.

2.4.3. Software

Guarda le implementazioni dei dispositivi:

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

Guarda le implementazioni dei dispositivi:

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

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

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

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

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

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

2.4.4. Prestazioni e potenza

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

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

Guarda le implementazioni dei dispositivi:

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

2.5. Requisiti per il settore auto e motori

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

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

• Sono integrati in un veicolo auto e motori o possono essere collegati a un veicolo.
• Utilizzi uno schermo nella fila del sedile del conducente come display principale.

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

2.5.1. Hardware

Implementazioni di dispositivi per auto e motori:

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

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

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

• [7.2.3/A-0-2] DEVE inviare all'applicazione in primo piano sia l'evento di pressione normale sia quello di pressione prolungata della funzione Indietro (KEYCODE_BACK).

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

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

• [7.3.1/A-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 100 Hz.
• [7.3.1/A-1-2] DEVE essere conforme al sistema di coordinate del sensore dell'auto di Android.

Se le implementazioni dei dispositivi per auto includono un giroscopio:

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

Implementazioni di dispositivi per auto e motori:

• [7.3.11/A-0-1] È OBBLIGATORIO fornire l'attrezzatura attuale come SENSOR_TYPE_GEAR.

Implementazioni di dispositivi per 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 DOVREBBE essere basato sull'input del sensore di luce ambientale.

• Il sensore di luce ambientale sottostante POTREBBE essere lo stesso di Fotometro.

• [7.3.11.4/A-0-1] È OBBLIGATORIO fornire la velocità del veicolo come 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 il Bluetooth LE.

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

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

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

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

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

Implementazioni di dispositivi per auto e motori:

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

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

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

Se le implementazioni dei dispositivi Automotive sono a 32 bit:

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

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

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

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

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

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

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

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

Se le implementazioni dei dispositivi per auto e motori sono a 64 bit:

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

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

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

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

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

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

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

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

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

Implementazioni di dispositivi per auto e motori:

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

Implementazioni di dispositivi per auto e motori:

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

Implementazioni di dispositivi per auto e motori:

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

2.5.2. Multimediale

Le implementazioni dei dispositivi per auto DEVONO supportare la seguente codifica audio:

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

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

• [5.2/A-0-1] H.264 AVC
• [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] H.264 AVC
• [5.3/A-0-2] MPEG-4 SP
• [5.3/A-0-3] VP8
• [5.3/A-0-4] VP9

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

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

2.5.3. Software

Implementazioni di dispositivi per auto e motori:

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

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

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

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

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

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

• [3.13/A-SR] È MOLTO CONSIGLIATO includere un componente dell'interfaccia utente delle Impostazioni rapide.

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

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

Implementazioni di dispositivi per auto e motori:

• [3.14/A-0-1] DEVE includere un framework UI per supportare le 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 del dispositivo incluse in AOSP o estendono le funzionalità incluse in AOSP:

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

Implementazioni di dispositivi per auto e motori:

• [8.2/A-0-1] DEVE segnalare il numero di byte letti e scritti nella memoria non volatile per l'UID di ogni processo in modo che le statistiche siano disponibili per gli sviluppatori tramite l'API di sistema android.car.storagemonitoring.CarStorageMonitoringManager. Android Open Source Project soddisfa il requisito tramite il modulo del kernel uid_sys_stats.
• [8.4/A-0-1] DEVE fornire un profilo di alimentazione per componente che definisce il valore di consumo corrente per ogni componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
• [8.4/A-0-2] È obbligatorio segnalare tutti i valori di consumo di energia in milliampere ora (mAh).
• [8.4/A-0-3] DEVE segnalare il consumo di energia della CPU per ogni UID del processo. Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
• [8.4/A] DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.
• [8.4/A-0-4] DEVE rendere disponibile questo consumo di energia tramite il comando di shell adb shell dumpsys batterystats per lo sviluppatore dell'app.

2.5.5. Modello di sicurezza

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

• [9.5/A-1-1] DEVE includere un account ospite che consenta tutte le funzioni fornite dal sistema del veicolo senza che sia necessario che un utente acceda.

Se le implementazioni dei dispositivi per auto e motori supportano una schermata di blocco sicura:

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

Implementazioni di dispositivi per auto e motori:

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

2.6. Requisiti del tablet

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

• Di solito viene tenuto con entrambe le mani.
• Non ha una configurazione a conchiglia o convertibile.
• Qualsiasi implementazione di tastiera fisica utilizzata con il dispositivo DEVE essere collegata tramite una connessione standard.
• Ha una fonte di alimentazione che offre mobilità, ad esempio una batteria.
• Ha una dimensione dello schermo in diagonale fisica compresa tra 18 e 45 cm.

Le implementazioni dei tablet hanno requisiti simili a quelli dei dispositivi palmari. Le eccezioni sono indicate da * nella sezione in questione e riportate per riferimento in questa sezione.

2.4.1. Hardware

Dimensioni schermo

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

Memoria e spazio di archiviazione minimi (sezione 7.6.1)

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

Modalità periferica USB (sezione 7.7.1)

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

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

Modalità Realtà virtuale (sezione 7.9.1)

Realtà virtuale ad alte prestazioni (sezione 7.9.2)

I requisiti per la realtà virtuale non sono applicabili ai tablet.

3. Software

3.1. Compatibilità con le API gestite

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

Implementazioni dei dispositivi:

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

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

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

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

• [C-0-5] DEVE limitare l'utilizzo delle API nascoste da parte di app di terze parti, definite come API nel namespace Android decorate 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 limitazioni forniti tramite i file dell'elenco provvisorio e della lista di esclusione nel percorso prebuilts/runtime/appcompat/ per il ramo del livello API appropriato in AOSP. Tuttavia:

  • Può essere opportuno spostare l'API nascosta nella lista negativa o rimuoverla da tutti gli elenchi con limitazioni se l'API nascosta non è presente o è implementata in modo diverso nell'implementazione del dispositivo.
  • Può, se un'API nascosta non esiste già in AOSP, aggiungere l'API nascosta a uno degli elenchi con limitazioni.
  • PUO' implementare un meccanismo di aggiornamento dinamico che sposta un'API nascosta da un elenco con limitazioni a un elenco meno restrittivo, ad eccezione della lista consentita.

3.1.1. Estensioni Android

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

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

3.1.2. Libreria Android

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

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

L'implementazione AOSP soddisfa questi requisiti.

3.2. Compatibilità API soft

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

3.2.1. Autorizzazioni

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

3.2.2. Parametri di compilazione

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

• [C-0-1] Per fornire valori coerenti e significativi per tutte le implementazioni dei dispositivi, la tabella seguente include ulteriori limitazioni relative ai formati di questi valori a cui le implementazioni dei dispositivi DEVONO essere conformi.

Parametro	Dettagli
VERSION.RELEASE	La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE avere uno dei valori di stringa definiti in 9.
VERSION.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 avere 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 avere il valore intero 9_INT.
VERSION.INCREMENTAL	Un valore scelto dall'implementatore del dispositivo che designa la build specifica del sistema Android attualmente in esecuzione, in formato leggibile. Questo valore NON DEVE essere riutilizzato per build diverse rese disponibili agli utenti finali. Un utilizzo tipico di questo campo è indicare il numero di build o l'identificatore della modifica del controllo del codice sorgente utilizzato per generare la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo 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. Un possibile utilizzo di questo campo è indicare la revisione specifica della scheda che alimenta il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
BRAND	Un valore che riflette il nome del brand associato al dispositivo, come noto agli utenti finali. DEVE essere in un formato leggibile e DEVE rappresentare il produttore del dispositivo o il brand dell'azienda con cui viene commercializzato il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
SUPPORTED_32_BIT_ABIS	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
SUPPORTED_64_BIT_ABIS	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
CPU_ABI	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
CPU_ABI2	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità con le API native.
DISPOSITIVO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice che identifica la configurazione delle funzionalità hardware e il design industriale del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Il nome del dispositivo NON DEVE cambiare durante la vita utile del prodotto.
FINGERPRINT	Una stringa che identifica in modo univoco questa build. DOVREBBE essere ragionevolmente leggibile da una persona. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ad esempio: acme/myproduct/     mydevice:9/LMYXX/3359:userdebug/test-keys L'impronta NON DEVE includere caratteri di spazio vuoto. Se altri campi inclusi nel modello riportato sopra contengono spazi vuoti, DEVONO essere sostituiti nell'impronta della build con un altro carattere, ad esempio 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). DOVREBBE essere ragionevolmente leggibile da una persona. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
ORGANIZZATORE	Una stringa che identifica in modo univoco l'host su cui è stata eseguita la compilazione, in formato leggibile. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
ID	Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una versione specifica, in un formato leggibile. Questo campo può essere uguale ad android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere le build software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
PRODUTTORE	La ragione sociale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota (""). Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.
MODELLO	Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo noto all'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota (""). Questo campo NON DEVE cambiare durante il ciclo di vita del prodotto.
PRODOTTO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice del prodotto specifico (SKU) che DEVE essere univoco all'interno dello stesso brand. DEVE essere leggibile, ma non necessariamente destinato alla visualizzazione da parte degli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Il nome del prodotto NON DEVE cambiare durante il ciclo di vita del prodotto.
SERIALE	DEVE restituire "UNKNOWN".
TAG	Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che distingue ulteriormente la build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni di firma della piattaforma Android: release-keys, dev-keys, test-keys.
DURATA	Un valore che rappresenta il timestamp della compilazione.
MACCHINA	Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni di runtime Android tipiche: user, userdebug o eng.
UTENTE	Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
SECURITY_PATCH	Un valore che indica il livello della patch di sicurezza di una build. DEBBA indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti nel Bollettino pubblico sulla sicurezza di Android designato. DEVE essere nel formato [AAAA-MM-GG] e corrispondere a una stringa definita documentata nel Bollettino pubblico sulla sicurezza di Android o nell'Avviso sulla sicurezza di Android, ad esempio "2015-11-01".
BASE_OS	Un valore che rappresenta il parametro FINGERPRINT della build, che è altrimenti identico a questa build, ad eccezione delle patch fornite nel bollettino Android Public Security. DEVE riportare il valore corretto e, se una build di questo tipo non esiste, deve riportare una stringa vuota ("").
BOOTLOADER	Un valore scelto dall'implementatore del dispositivo che identifica la versione specifica del bootloader interno utilizzata nel dispositivo, in formato leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
getRadioVersion()	DEVE (essere o restituire) un valore scelto dall'implementatore del dispositivo che identifica la versione specifica della radio/del modem interna utilizzata nel dispositivo, in formato leggibile. Se un dispositivo non ha radio/modem interni, DEVE restituire NULL. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-,]+$".
getSerial()	DEVE (essere o restituire) un numero di serie hardware, che DEVE essere disponibile e univoco su tutti i dispositivi con lo stesso MODELLO e PRODUTTORE. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-,]+$".

3.2.3. Compatibilità con gli intent

3.2.3.1. Intent di applicazione principali

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

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

  • Orologio da scrivania
  • Browser
  • Calendar
  • Contatti
  • Galleria
  • GlobalSearch
  • Avvio app
  • Musica
  • Impostazioni

3.2.3.2. Risoluzione dell'intent

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

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

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

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

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

• [C-0-4] DEVE tentare di convalidare tutti i filtri per intent eseguendo i passaggi di convalida definiti nella specifica Digital Asset Links, come implementato dal gestore pacchetti nel progetto open source Android upstream.
• [C-0-5] DEVE tentare la convalida dei filtri di intent durante l'installazione dell'applicazione e impostare tutti i filtri di intent URI convalidati correttamente come gestori di app predefiniti per i relativi URI.
• PUO' impostare filtri di intent URI specifici come gestori di app predefiniti per i propri URI, se vengono verificati correttamente, ma altri filtri URI candidati non superano la verifica. Se un'implementazione del dispositivo esegue questa operazione, DEVE fornire all'utente le sostituzioni dei pattern per URI appropriate nel menu delle impostazioni.
• DEVE fornire all'utente i controlli dei link dell'app per app nelle Impostazioni come segue:
  • [C-0-6] L'utente DEVE essere in grado di sostituire in modo olistico il comportamento predefinito dei link alle app in modo che un'app sia: sempre aperta, sempre chiedi o mai aperta, che deve essere applicato allo stesso modo a tutti i filtri di intent URI candidati.
  • [C-0-7] L'utente DEVE essere in grado di visualizzare un elenco dei filtri di intent URI candidati.
  • L'implementazione del dispositivo PUÒ fornire all'utente la possibilità di ignorare filtri di intent URI candidati specifici che sono stati verificati correttamente, in base al filtro di intent.
  • [C-0-8] L'implementazione del dispositivo DEVE fornire agli utenti la possibilità di visualizzare e sostituire filtri di intent URI candidati specifici se l'implementazione del dispositivo consente a alcuni filtri di intent URI candidati di superare la verifica, mentre altri possono non riuscirci.

3.2.3.3. Spazi dei nomi degli intent

• [C-0-1] Le implementazioni dei dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando un'AZIONE, una CATEGORIA o un'altra stringa chiave nello spazio dei nomi android. o com.android.
• [C-0-2] Gli implementatori di dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando un'azione, una CATEGORY o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione.
• [C-0-3] Gli implementatori dei dispositivi NON DEVONO modificare o estendere nessuno dei pattern di intent utilizzati dalle app di base elencate nella sezione 3.2.3.1.
• Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano spazi dei nomi chiaramente e inequivocabilmente associati alla propria organizzazione. Questo divieto è analogo a quello specificato per i corsi di lingua Java nella sezione 3.6.

3.2.3.4. Intent di trasmissione

Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent al fine di essere avvisate delle modifiche nell'ambiente hardware o software.

Implementazioni dei dispositivi:

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

3.2.3.5. Impostazioni app predefinite

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

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

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

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

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

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

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

  • DEVE utilizzare l'interfaccia utente dell'app Telefono predefinita selezionata dall'utente per le chiamate in arrivo e in uscita, ad eccezione delle chiamate di emergenza, per le quali verrà utilizzata l'app Telefono preinstallata.

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

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

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

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

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

3.2.4. Attività sui display secondari

Se le implementazioni dei dispositivi consentono di avviare normali attività Android sui display secondari:

• [C-1-1] È NECESSARIO impostare il flag funzionalità android.software.activities_on_secondary_displays.
• [C-1-2] DEVE garantire la compatibilità con l'API simile a un'attività in esecuzione sul display principale.
• [C-1-3] DEVE mostrare la nuova attività sulla stessa visualizzazione dell'attività che l'ha lanciata, quando la nuova attività viene lanciata senza specificare una visualizzazione target tramite l'API ActivityOptions.setLaunchDisplayId().
• [C-1-4] DEVE distruggere tutte le attività quando viene rimosso un display con il flag Display.FLAG_PRIVATE.
• [C-1-5] È NECESSARIO ridimensionare di conseguenza tutte le attività su un VirtualDisplay se il display stesso viene ridimensionato.
• PUÒ mostrare un editor di metodi di inserimento (IME, un controllo utente che consente agli utenti di inserire testo) sul display principale quando un campo di immissione di testo diventa attivo su un display secondario.
• DEVE implementare lo stato attivo dell'input sul display secondario indipendentemente dal display principale, quando sono supportati input tocco o da tastiera.
• DEVE avere android.content.res.Configuration che corrisponde a quel display per essere visualizzato, funzionare correttamente e mantenere la compatibilità se un'attività viene avviata sul display secondario.

Se le implementazioni del dispositivo consentono di avviare normali attività Android sui display secondari e i display principale e secondario 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 precedente NON DEVONO essere consentite sui display secondari.

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

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

3.3. Compatibilità con le API native

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

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

3.3.1. Application Binary Interface

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

Implementazioni dei dispositivi:

• [C-0-1] DEVE essere compatibile con una o più ABI definite e implementare la compatibilità con il kit di sviluppo NDK per Android.
• [C-0-2] DEVE includere il supporto per il codice in esecuzione nell'ambiente gestito per chiamare il codice nativo utilizzando la semantica standard di Java Native Interface (JNI).
• [C-0-3] DEVE essere compatibile con il codice sorgente (ovvero con gli header) e con il codice binario (per l'ABI) di ogni libreria richiesta nell'elenco di seguito.
• [C-0-5] DEVE segnalare con precisione l'interfaccia a oggetti di base dell'applicazione (ABI) nativa supportata dal dispositivo tramite i parametri android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, ciascuno un elenco separato da virgole di ABI ordinati dal più preferito al meno preferito.

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

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

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

  • libaaudio.so (supporto audio nativo AAudio)

  • libandroid.so (supporto delle attività native di Android)
  • libc (libreria C)
  • libcamera2ndk.so
  • libdl (linker dinamico)
  • libEGL.so (gestione delle superfici OpenGL native)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (logging Android)
  • libmediandk.so (supporto delle API multimediali native)
  • libm (libreria matematica)
  • libneuralnetworks.so (API Neural Networks)
  • libOpenMAXAL.so (supporto di OpenMAX AL 1.0.1)
  • libOpenSLES.so (supporto audio OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (supporto minimo per C++)
  • libvulkan.so (Vulkan)
  • libz (compressione Zlib)
  • Interfaccia JNI

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

• [C-0-9] È OBBLIGATORIO elencare le librerie non AOSP aggiuntive esposte direttamente alle app di terze parti in /vendor/etc/public.libraries.txt.
• [C-0-10] NON DEVE esporre altre librerie native, implementate e fornite in AOSP come librerie di sistema, ad app di terze parti che hanno come target il livello API 24 o versioni successive, in quanto sono riservate.
• [C-0-11] È OBBLIGATORIO esportare tutti i simboli delle funzioni OpenGL ES 3.1 e del pacchetto di estensioni Android, come definiti nell'NDK, tramite la libreria libGLESv3.so. Tieni presente che, anche se tutti i simboli DEVONO essere presenti, la sezione 7.1.4.1 descrive in modo più dettagliato i requisiti per l'implementazione completa di ogni funzione corrispondente.
• [C-0-12] È OBBLIGATORIO esportare i simboli delle funzioni per i simboli delle funzioni di base di Vulkan 1.0, nonché le estensioni VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 tramite la libreria libvulkan.so. Tieni presente che, anche se tutti i simboli DEVONO essere presenti, la sezione 7.1.4.2 descrive in modo più dettagliato i requisiti per l'implementazione completa di ogni funzione corrispondente.
• DEVE essere compilato utilizzando il codice sorgente e i file di intestazione disponibili nel progetto open source Android upstream

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

3.3.2. Compatibilità con il codice nativo ARM a 32 bit

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

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

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

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

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

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

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

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

3.4. Compatibilità web

3.4.1. Compatibilità con WebView

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

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

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

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

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

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

3.4.2. Compatibilità del browser

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

• [C-1-1] DEVE supportare ciascuna di queste API associate a HTML5:
  • cache dell'applicazione/operazione offline
  • Tag<video>
  • geolocalizzazione
• [C-1-2] DEVE supportare l'API webstorage HTML5/W3C e DOVREBBE supportare l'API IndexedDB HTML5/W3C. Tieni presente che, poiché gli enti di standardizzazione dello sviluppo web stanno adottando IndexedDB al posto di webstorage, IndexedDB dovrebbe diventare un componente obbligatorio in una versione futura di Android.
• PUÒ includere una stringa user agent personalizzata nell'applicazione Browser autonoma.
• DOVREBBE implementare il supporto per il maggior numero possibile di funzionalità di HTML5 nell'applicazione Browser autonoma (in base all'applicazione Browser WebKit a monte o a una sostituzione di terze parti).

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

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

3.5. Compatibilità comportamentale dell'API

Implementazioni dei dispositivi:

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

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

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

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

3.5.1. Limitazione in background

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

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

3.6. Spazi dei nomi API

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

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

ovvero:

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

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

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

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

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

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

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

3.7. Compatibilità di runtime

Implementazioni dei dispositivi:

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

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

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

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

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

Layout dello schermo	Densità schermo	Memoria minima dell'applicazione
Orologio Android	120 dpi (ldpi)	32MB
	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à dell'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 l'Avvio app del dispositivo (schermata Home).

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

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

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

• [C-2-1] È OBBLIGATORIO segnalare true per ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] DEVE avere un'affordance che chieda all'utente prima di aggiungere una scorciatoia richiesta dalle app tramite il metodo dell'API ShortcutManager.requestPinShortcut().
• [C-2-3] DEVE supportare le scorciatoie fissate e le scorciatoie dinamiche e statiche come descritto nella pagina Scorciatoie app.

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

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

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

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

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

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

3.8.2. Widget

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

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

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

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

• [C-2-1] È OBBLIGATORIO segnalare true per AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] DEVE avere un'affordance che chieda all'utente prima di aggiungere una scorciatoia richiesta dalle app tramite il metodo dell'API AppWidgetManager.requestPinAppWidget().

3.8.3. Notifiche

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

3.8.3.1. Presentazione delle notifiche

Se le implementazioni dei dispositivi consentono alle app di terze parti di inviare notifiche agli utenti su eventi importanti:

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

Se le implementazioni dei dispositivi supportano le notifiche avanzate:

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

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

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

3.8.3.2. Servizio di listener di notifiche

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

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

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

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

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

3.8.3.3. DND (Non disturbare)

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

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

3.8.4. Cerca

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

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

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

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

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

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

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

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

• [C-2-1] DEVE indicare chiaramente all'utente finale quando il contesto viene condiviso, in uno dei seguenti modi:
  • Ogni volta che l'app di assistenza accede al contesto, viene visualizzata una luce bianca intorno ai bordi dello schermo che soddisfa o supera la durata e la luminosità dell'implementazione del progetto open source Android.
  • Per l'app di assistenza preinstallata, fornire all'utente un'affordance a meno di due navigazioni dal menu delle impostazioni dell'app di assistenza e dell'input vocale predefinito e condividere il contesto solo quando l'app di assistenza viene invocata esplicitamente dall'utente tramite una hotword o l'input della chiave di navigazione dell'assistente.
• [C-2-2] L'interazione designata per avviare l'app di assistenza come descritto nella sezione 7.2.3 DEVE avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService o un'attività che gestisce l'intent ACTION_ASSIST.

3.8.5. Avvisi e popup

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

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

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

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

3.8.6. Temi

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

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

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

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

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

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

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

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

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

3.8.7. Sfondi animati

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

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

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

Se le implementazioni dei dispositivi implementano sfondi animati:

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

3.8.8. Cambio attività

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

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

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

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

3.8.9. Gestione dell'input

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

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

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

Se le implementazioni del dispositivo dichiarano il flag della 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 delle impostazioni dell'app predefinito per attivare e disattivare il completamento automatico e modificare il servizio di completamento automatico predefinito per l'utente.

3.8.10. Controllo dei contenuti multimediali nella schermata di blocco

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

3.8.11. Salvaschermo (in precedenza Sogni)

Android include il supporto per i salvaschermo interattivi, precedentemente noti come Sogni. I salvaschermo consentono agli utenti di interagire con le applicazioni quando un dispositivo collegato a una fonte di alimentazione è inattivo o agganciato alla base di ricarica. I dispositivi Android Watch POSSONO implementare i salvaschermo, ma altri tipi di implementazioni dei dispositivi DEVONO includere il supporto per i salvaschermo e fornire un'opzione di impostazioni per consentire agli utenti di configurarli in risposta all'intent 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 della posizione,

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

3.8.13. Unicode e carattere

Android include il supporto dei caratteri emoji definiti in Unicode 10.0.

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

• [C-1-1] DEVE essere in grado di eseguire il rendering di questi caratteri emoji in un glifo a colori.
• [C-1-2] DEVE includere il supporto per:
  • Carattere Roboto 2 con diversi spessori: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light per le lingue disponibili sul dispositivo.
  • Copertura completa di Unicode 7.0 per latino, greco e cirillico, inclusi gli intervalli A, B, C e D estesi latini e tutti i glifi nel blocco dei simboli di valuta di Unicode 7.0.
• DOVREBBE supportare la tonalità della pelle e le diverse emoji di famiglia come specificato nel report tecnico Unicode n. 51.

Se le implementazioni del dispositivo includono un IME, devono:

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

3.8.14. Multi-finestra

Se le implementazioni dei dispositivi hanno la capacità di mostrare più attività contemporaneamente:

• [C-1-1] DEVE implementare queste modalità multi-finestra in conformità con i comportamenti e le API dell'applicazione descritti nella documentazione di supporto della modalità multi-finestra dell'SDK Android e soddisfare i seguenti requisiti:
• [C-1-2] 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 su un valore maggiore di 24. Le app che impostano esplicitamente questo attributo su false nel file manifest NON DEVONO essere avviate in modalità multifinestra. Le app precedenti con targetSdkVersion < 24 che non hanno impostato questo attributo android:resizeableActivity POSSONO essere avviate in modalità multi-finestra, ma il sistema DEVE fornire un avviso che l'app potrebbe non funzionare come previsto in modalità multi-finestra.
• [C-1-3] NON DEVE offrire la modalità schermo diviso o a forma libera se l'altezza dello schermo è inferiore a 440 dp e la larghezza dello schermo è inferiore a 440 dp.
• Le implementazioni dei dispositivi con dimensioni dello schermo xlarge DEVONO supportare la modalità a forma libera.

Se le implementazioni del dispositivo supportano le modalità a più finestre e la modalità schermo diviso:

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

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

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

3.8.15. Ritaglio display

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

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

• [C-1-1] DEVE avere ritagli solo sui lati corti del dispositivo. Al contrario, se le proporzioni del dispositivo sono 1,0 (1:1), NON DEVONO avere ritagli.
• [C-1-2] NON DEVE avere più di un ritaglio per bordo.
• [C-1-3] DEVE rispettare i flag di ritaglio del display impostati dall'app tramite l'API WindowManager.LayoutParams come descritto nell'SDK.
• [C-1-4] DEVE riportare 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 del dispositivo a livello di sistema, ad esempio l'applicazione di criteri per le password o l'esecuzione di una cancellazione dei dati da remoto, tramite l'API Android Device Administration.

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

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

3.9.1 Provisioning del dispositivo

3.9.1.1 Provisioning del proprietario del dispositivo

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

• [C-1-1] DEVE supportare la registrazione di un client Device Policy (DPC) come app di proprietà del dispositivo come descritto di seguito:
  • Quando l'implementazione del dispositivo non ha ancora configurato i dati utente:
    • [C-1-3] È OBBLIGATORIO segnalare true per DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] L'applicazione DPC DEVE essere registrata come app Proprietario dispositivo in risposta all'azione intent android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] È NECESSARIO registrare l'applicazione DPC come app Proprietario dispositivo se il dispositivo dichiara il supporto della tecnologia NFC (Near Field Communication) 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] È OBBLIGATORIO segnalare false per DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] NON devi più registrare alcuna applicazione DPC come app di proprietà del dispositivo.
• [C-1-2] DEVE richiedere un'azione affermativa durante la procedura di provisioning per consentire all'app di essere impostata come proprietario del dispositivo. Il consenso può essere ottenuto tramite un'azione dell'utente o tramite alcuni mezzi programmatici durante il provisioning, ma NON DEVE essere hardcoded o impedire l'utilizzo di altre app di proprietà del dispositivo.

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

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

3.9.1.2 Provisioning dei profili gestiti

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

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

• [C-1-2] L'esperienza degli utenti durante la procedura di provisioning del profilo gestito (il flusso avviato da android.app.action.PROVISION_MANAGED_PROFILE) DEVE essere in linea con l'implementazione AOSP.

• [C-1-3] DEVE fornire le seguenti funzionalità per l'utente nelle Impostazioni per indicare all'utente quando una determinata funzionalità di sistema è stata disattivata dal Device Policy Controller (DPC):

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

3.9.2 Assistenza per i profili gestiti

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

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

3.9.3 Assistenza per gli utenti gestiti

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

• [C-1-1] È OBBLIGATORIO fornire un'affordance utente per uscire dall'utente corrente e tornare all'utente principale nella sessione con più utenti quando isLogoutEnabled restituisce true. L'affordance utente DEVE essere accessibile dalla schermata di blocco senza sbloccare il dispositivo.

3.10. Accessibilità

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

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

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

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

• [C-2-1] DEVE implementare questi servizi di accessibilità preinstallati come app Direct Boot Aware quando l'archiviazione dei dati è criptata con la crittografia basata su file (FBE).
• DOVREBBE fornire un meccanismo nel flusso di configurazione out-of-box per consentire agli utenti di attivare i servizi di accessibilità pertinenti, nonché opzioni per regolare le dimensioni dei caratteri, le dimensioni del display e i gesti di ingrandimento.

3.11. Sintesi vocale

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

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

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

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

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

3.12. TV Input Framework

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

Se le implementazioni del dispositivo supportano TIF:

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

3.13. Impostazioni rapide

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

Se le implementazioni del dispositivo includono un componente dell'interfaccia utente delle Impostazioni rapide:

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

3.14. UI multimediale

Se le implementazioni dei dispositivi includono il framework UI che supporta le app di terze parti che dipendono da MediaBrowser e MediaSession:

• [C-1-1] È OBBLIGATORIO mostrare le icone di MediaItem e le icone di notifica invariate.
• [C-1-2] DEVE mostrare gli elementi come descritti da MediaSession, ad esempio metadati, icone e immagini.
• [C-1-3] DEVE mostrare il titolo dell'app.
• [C-1-4] DEVE avere un riquadro o un altro meccanismo per presentare la gerarchia di MediaBrowser e fornire all'utente un'affordance per la gerarchia di MediaBrowser.
• [C-1-5] È OBBLIGATORIO considerare il doppio tocco di KEYCODE_HEADSETHOOK o KEYCODE_MEDIA_PLAY_PAUSE come KEYCODE_MEDIA_NEXT per MediaSession.Callback#onMediaButtonEvent.

3.15. App istantanee

Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti:

• [C-0-1] Alle app istantanee DEVONO essere concesse solo le autorizzazioni con android:protectionLevel impostato su "instant".
• [C-0-2] Le app istantanee NON DEVONO interagire con le app installate tramite intent impliciti, a meno che non sia vera una delle seguenti condizioni:
  • Il filtro pattern intent del componente è esposto e ha CATEGORY_BROWSABLE
  • L'azione è una di ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
  • Il target è esposto esplicitamente con android:visibleToInstantApps
• [C-0-3] Le app istantanee NON DEVONO interagire esplicitamente con le app installate, a meno che il componente non sia esposto tramite android:visibleToInstantApps.
• [C-0-4] Le app installate NON DEVONO vedere i dettagli delle app istantanee sul dispositivo, a meno che l'app istantanea non si connetta esplicitamente all'applicazione installata.

3.16. Accoppiamento dispositivo complementare

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

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

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

3.17. App pesanti

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

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

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

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

4. Compatibilità con il pacchettizzazione delle applicazioni

Implementazioni dei dispositivi:

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

Implementazioni dei dispositivi:

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

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

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

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

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

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

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

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

5. Compatibilità multimediale

Implementazioni dei dispositivi:

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

Implementazioni dei dispositivi:

• DEVONO mirare a una latenza minima del codec, in altre parole, devono
  • NON DEVE consumare e memorizzare i buffer di input e restituire i buffer di input solo dopo l'elaborazione.
  • NON DEVE conservare i buffer decodificati per più tempo di quanto specificato dallo standard (ad es. SPS).
  • NON DEVE conservare i buffer codificati più a lungo di quanto richiesto dalla struttura GOP.

Tutti i codec elencati nella sezione di seguito sono forniti come implementazioni software nell'implementazione Android preferita del progetto open source Android.

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

5.1. Codec multimediali

5.1.1. Codifica audio

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

Se le implementazioni del dispositivo dichiarano android.hardware.microphone, DEVONO supportare la 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 della funzionalità android.hardware.audio.output, devono supportare la decodifica dei seguenti formati audio:

• [C-1-1] Profilo MPEG-4 AAC (AAC LC)
• [C-1-2] Profilo MPEG-4 HE AAC (AAC+)
• [C-1-3] Profilo MPEG-4 HE AACv2 (AAC+ migliorato)
• [C-1-4] AAC ELD (AAC a basso ritardo migliorato)
• [C-1-11] xHE-AAC (profilo HE AAC esteso ISO/IEC 23003-3, che include il profilo di riferimento USAC e il profilo di controllo della gamma dinamica ISO/IEC 23003-4)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE
• [C-1-10] Opus

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

• [C-2-1] La decodifica DEVE essere eseguita senza downmixing (ad es. uno stream AAC 5.0 deve essere decodificato in cinque canali PCM, uno stream AAC 5.1 deve essere decodificato in sei canali PCM).
• [C-2-2] I metadati relativi all'intervallo dinamico DEVONO essere come definiti in "Controllo dell'intervallo dinamico (DRC)" in ISO/IEC 14496-3 e le chiavi DRC android.media.MediaFormat per configurare i comportamenti relativi all'intervallo dinamico del decodificatore audio. Le chiavi 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.

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

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

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

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

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

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

5.1.3. Dettagli sui codec audio

Formato/codec	Dettagli	Tipi di file/formati contenitore supportati
Profilo MPEG-4 AAC (AAC LC)	Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC non compresso ADTS (.aac, ADIF non supportato) MPEG-TS (.ts, non cercabile)
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+ avanzato)	Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.
AAC ELD (AAC a bassa latenza migliorata)	Supporto per contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.
USAC	Supporto per contenuti mono/stereo con frequenze di campionamento standard da 7,35 a 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	Da 4,75 a 12,2 Kbps campionati a 8 kHz	3GPP (.3gp)
AMR-WB	9 velocità da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz
FLAC	Mono/stereo (nessun multicanale). Frequenze di campionamento fino a 48 kHz (ma fino a 44,1 kHz è CONSIGLIATO sui dispositivi con uscita a 44,1 kHz, poiché il downsampler da 48 a 44,1 kHz non include un filtro passa basso). CONSIGLIATO 16 bit; nessun dither applicato per 24 bit.	Solo FLAC (.flac)
MP3	Mono/stereo 8-320 Kbps costante (CBR) o con velocità in bit variabile (VBR)	MP3 (.mp3)
MIDI	Tipo MIDI 0 e 1. Versioni 1 e 2 di DLS. XMF e Mobile XMF. Supporto per i formati delle sveglie RTTTL/RTX, OTA e iMelody	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		Ogg (.ogg) Matroska (.mkv, Android 4.0 e versioni successive)
PCM/WAVE	PCM lineare a 16 bit (frequenze fino al limite dell'hardware). I dispositivi DEVONO supportare le frequenze di campionamento per la registrazione PCM non compressa a 8000, 11025, 16000 e 44100 Hz.	WAVE (.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 delle seguenti immagini:

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

5.1.5. Decodifica delle immagini

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

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

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

5.1.6. Dettagli sui codec delle immagini

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

5.1.7. Codec video

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

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

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

• [C-1-2] I codificatori e decodificatori video DEVONO supportare il formato di 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 dell'aggiornamento interno tramite FEATURE_IntraRefresh nella classe MediaCodecInfo.CodecCapabilities:

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

5.1.8. Elenco dei codec video

Formato/codec	Dettagli	Tipi di file supportati/ Formati contenitore
H.263		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	Per maggiori dettagli, consulta le sezioni 5.2 e 5.3	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, solo audio AAC, non cercabile, Android 3.0 e versioni successive)
H.265 HEVC	Per informazioni dettagliate, consulta la sezione 5.3	MPEG-4 (.mp4)
MPEG-2	Profilo principale	MPEG2-TS
MPEG-4 SP		3GPP (.3gp)
VP8	Per maggiori dettagli, 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 per le app di terze parti:

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

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

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

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

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

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

• DOVREBBE supportare le 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 per le app di terze parti, devono:

• [C-1-1] DEVE supportare il livello 45 del profilo di baseline.
• DOVREBBE supportare le velocità in bit configurabili dinamicamente per il codificatore supportato.

5.2.2. H-264

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

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

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

• [C-2-1] DEVE supportare i profili di codifica riportati nella tabella seguente.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p
Risoluzione video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	20 f/s	30 fps	30 fps	30 fps
Velocità in bit video	384 kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

Se le implementazioni dei dispositivi supportano il codec VP8:

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

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

• [C-2-1] DEVE supportare i profili di codifica riportati nella tabella seguente.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps
Velocità in bit video	800 kbps	2 Mbps	4 Mbps	10 Mbps

5.2.4. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

• DOVREBBE supportare la scrittura di file Matroska WebM.

5.3. Decodifica video

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

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

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

• [C-2-1] È OBBLIGATORIO fornire un'apposita app per l'estrazione di file compatibile con Dolby Vision.
• [C-2-2] DEVE mostrare correttamente i contenuti Dolby Vision sullo schermo del dispositivo o su una porta di uscita video standard (ad es. HDMI).
• [C-2-3] L'indice traccia dei livelli base compatibili con le versioni precedenti (se presenti) DEVE essere uguale all'indice traccia del livello Dolby Vision combinato.

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

Se le implementazioni dei dispositivi con decodificatori MPEG-4:

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

5.3.4. H.264

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

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

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

• [C-2-1] DEVE supportare i profili di decodifica video HD 720p riportati nella tabella seguente.
• [C-2-2] DEVE supportare i profili di decodifica video HD 1080p riportati nella tabella seguente.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p
Risoluzione video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	60 FPS	30 fps (60 fpsTelevisore)
Velocità in bit video	800 kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

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

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

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

• [C-2-1] Le implementazioni dei dispositivi DEVONO supportare almeno una decodifica H.265 o VP9 dei profili 720, 1080 e UHD.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p	UHD
Risoluzione video	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30/60 f/s (60 f/sTelevisore con decodifica hardware H.265)	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3.6. VP8

Se le implementazioni dei dispositivi supportano il codec VP8:

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

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

• [C-2-1] Le implementazioni dei dispositivi DEVONO supportare i profili 720p indicati nella tabella seguente.
• [C-2-2] Le implementazioni dei dispositivi DEVONO supportare i profili 1080p indicati nella tabella seguente.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps (60 fpsTelevisore)	30 (60 fpsTelevisione)
Velocità in bit video	800 kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

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

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

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

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

• [C-3-1] Le implementazioni dei dispositivi DEVONO supportare almeno una decodifica VP9 o H.265 dei profili 720, 1080 e UHD.

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p	UHD
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps (60 fpsTelevisore con decodifica hardware VP9)	60 FPS
Velocità in bit video	600 kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.4. Registrazione audio

Sebbene alcuni dei requisiti descritti in questa sezione siano elencati come DOVREBBE fin da Android 4.3, è previsto che la definizione di compatibilità per le versioni future li modifichi in DEVE. Per i dispositivi Android esistenti e nuovi è FORTEMENTE CONSIGLIATO soddisfare questi requisiti indicati come DOVREBBE, altrimenti non potranno raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

5.4.1. Acquisizione audio non compresso

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

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

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

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

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

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

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

Se le implementazioni dei dispositivi consentono l'acquisizione di contenuti audio non elaborati con qualità DVD e radio AM, devono:

• [C-2-1] È NECESSARIO acquisire senza upsampling a qualsiasi rapporto superiore a 16000:22050 o 44100:48000.
• [C-2-2] DEVE includere un filtro anti-aliasing appropriato per qualsiasi upsampling o downsampling.

5.4.2. Acquisisci per il riconoscimento vocale

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

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

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

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

5.4.3. Acquisisci per il reindirizzamento della riproduzione

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

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

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

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

5.5. Riproduzione audio

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

5.5.1. Riproduzione audio non elaborata

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

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

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

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

  • Frequenze di campionamento: 24000, 48000

5.5.2. Effetti audio

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

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

• [C-1-1] DEVE supportare le implementazioni di EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controllabili tramite i sottoclassi AudioEffect Equalizer, LoudnessEnhancer.
• [C-1-2] DEVE supportare l'implementazione dell'API di visualizzazione, controllabile tramite la classe Visualizer.
• [C-1-3] DEVE supportare l'implementazione di EFFECT_TYPE_DYNAMICS_PROCESSING controllabile tramite la sottoclasse AudioEffect DynamicsProcessing.
• DOVREBBE supportare le implementazioni EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controllabili tramite le sottoclassi AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.

5.5.3. Volume uscita audio

Implementazioni di dispositivi per auto e motori:

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

5.6. Latenza audio

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

Ai fini di questa sezione, utilizza le seguenti definizioni:

• Latenza in uscita. L'intervallo tra il momento in cui un'applicazione scrive un frame di dati codificati in PCM e il momento in cui il suono corrispondente viene presentato all'ambiente da un trasduttore on-device o il segnale esce dal dispositivo tramite una porta e può essere osservato esternamente.
• Latenza di output a freddo. La latenza di uscita per il primo frame, quando il sistema di uscita audio è inattivo e spento prima della richiesta.
• Latenza di output continua. La latenza di uscita per i frame successivi, dopo che il dispositivo ha iniziato a riprodurre l'audio.
• Latenza di input. L'intervallo tra il momento in cui un suono viene presentato dall'ambiente al dispositivo su un trasduttore on-device o il segnale entra nel dispositivo tramite una porta e il momento in cui un'applicazione legge il frame corrispondente dei dati codificati PCM.
• Ha perso l'input. La parte iniziale di un segnale di input inutilizzabile o non disponibile.
• Latenza di input a freddo. La somma del tempo di inserimento perso e della latenza di inserimento per il primo frame, quando il sistema di inserimento audio è inattivo e spento prima della richiesta.
• Latenza di input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.
• Jitter in uscita a freddo. La variabilità tra misurazioni separate dei valori di latenza di output a freddo.
• Jitter di input a freddo. La variabilità tra misurazioni separate dei valori della latenza di input a freddo.
• latenza di viaggio avanti e indietro continua. La somma della latenza di input continua più la latenza di output continua più un periodo di buffer. Il periodo di buffer consente all'app di elaborare il segnale e di attenuare la differenza di fase tra gli stream di input e di output.
• API OpenSL ES PCM buffer queue. L'insieme di API OpenSL ES correlate a PCM in Android NDK.
• API audio nativa AAudio. L'insieme di API AAudio in Android NDK.
• Timestamp. Una coppia composta da una posizione relativa del frame all'interno di uno stream e dall'ora stimata in cui il frame entra o esce dalla pipeline di elaborazione audio nell'endpoint associato. Vedi anche AudioTimestamp.

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

• [C-SR] Latenza di uscita a freddo pari o inferiore a 100 millisecondi
• [C-SR] Latenza di uscita continua di massimo 45 millisecondi
• [C-SR] Riduci al minimo il jitter dell'output a freddo
• [C-SR] Il timestamp di output restituito da AudioTrack.getTimestamp e AAudioStream_getTimestamp è preciso al massimo +/- 1 ms.

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

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

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

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

Se le implementazioni dei dispositivi includono android.hardware.microphone, è MOLTO CONSIGLIATO soddisfare i seguenti requisiti per l'input audio:

• [C-SR] Latenza di input a freddo pari o inferiore a 100 millisecondi.
• [C-SR] Latenza di input continua pari o inferiore a 30 millisecondi.
• [C-SR] Latenza nel tempo di round trip continua pari o inferiore a 50 millisecondi.
• [C-SR] Riduci al minimo il jitter dell'input a freddo.
• [C-SR] Limita l'errore nei timestamp di input, 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 di audio e video come specificato nella documentazione dell'SDK Android.

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

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

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

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

Formati dei segmenti multimediali

Formati dei segmenti	Riferimenti	Supporto dei codec obbligatori
Stream di trasporto MPEG-2	ISO 13818	Codec video: H264 AVC MPEG-4 SP MPEG-2 Consulta la sezione 5.1.3 per informazioni dettagliate su H264 AVC, MPEG2-4 SP e MPEG-2. Codec audio: AAC Per informazioni dettagliate sull'AAC e sulle sue varianti, consulta la sezione 5.1.1.
AAC con framing ADTS e tag ID3	ISO 13818-7	Per informazioni dettagliate sull'AAC e sulle sue varianti, consulta la sezione 5.1.1.
WebVTT	WebVTT

RTSP (RTP, SDP)

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

5.8. Contenuti multimediali sicuri

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

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

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

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

Se le implementazioni dei dispositivi dichiarano il supporto di Display.FLAG_SECURE e supportano lo schermo esterno con cavo, devono:

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

5.9. Musical Instrument Digital Interface (MIDI)

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

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

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

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

5.10. Audio professionale

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

• [C-1-1] DEVE segnalare il supporto della funzionalità android.hardware.audio.low_latency.
• [C-1-2] DEVE avere una latenza audio in tempo di round trip continua, come definito nella sezione 5.6 Latenza audio, DEVE essere inferiore o uguale a 20 millisecondi e DEVE essere inferiore o uguale a 10 millisecondi su almeno un percorso supportato.
• [C-1-3] DEVE includere una o più porte USB che supportano la modalità host USB e la modalità periferica USB.
• [C-1-4] DEVE segnalare il supporto della funzionalità android.software.midi.
• [C-1-5] DEVE soddisfare i requisiti di latenza e audio USB utilizzando sia la coda del buffer PCM di OpenSL ES sia le API di audio nativo AAudio.
• [SR] Sono FORTEMENTE CONSIGLIATI per fornire un livello coerente di prestazioni della CPU quando l'audio è attivo e il carico della CPU varia. Questo deve essere testato utilizzando il commit SimpleSynth 1bd6391. L'app SimpleSynth deve essere eseguita con i parametri riportati di seguito e non deve presentare sottocarichi dopo 10 minuti:
  • Cicli di lavoro: 200.000
  • Carico variabile: ON (passa dal 100% al 10% del valore dei cicli di lavoro ogni 2 secondi ed è progettato per testare il comportamento del governatore della CPU)
  • Carico stabilizzato: OFF
• DOVREBBE ridurre al minimo l'inaccuratezza e lo scostamento dell'orologio audio rispetto all'ora standard.
• DOVREBBE ridurre al minimo lo scostamento dell'orologio audio rispetto alla CPU CLOCK_MONOTONIC quando entrambe sono attive.
• DEVE ridurre al minimo la latenza audio sui trasduttori sul dispositivo.
• DEVE ridurre al minimo la latenza audio tramite l'audio digitale USB.
• DOVREBBE documentare le misurazioni della latenza audio su tutti i percorsi.
• DOVREBBE ridurre al minimo il jitter nei tempi di inserimento del callback di completamento del buffer audio, in quanto influisce sulla percentuale utilizzabile della larghezza di banda completa della CPU dal callback.
• DOVREBBE non presentare sottocarichi (uscita) o sovraccarichi (ingresso) audio durante l'uso normale con la latenza registrata.
• DOVREBBE fornire una differenza di latenza intercanale pari a zero.
• DOVREBBE ridurre al minimo la latenza media MIDI su tutti i trasporti.
• DOVREBBE ridurre al minimo la variabilità della latenza MIDI sotto carico (jitter) su tutti i trasporti.
• DOVREBBE fornire timestamp MIDI accurati su tutti i trasporti.
• DOVREBBE ridurre al minimo il rumore del segnale audio sui trasduttori sul dispositivo, incluso il periodo immediatamente successivo all'avvio a freddo.
• DEVE fornire una differenza di clock audio pari a zero tra i lati di input e di output degli endpoint corrispondenti, quando entrambi sono attivi. Alcuni esempi di endpoint corrispondenti sono il microfono e lo speaker sul dispositivo oppure l'ingresso e l'uscita del jack audio.
• DEVE gestire i callback di completamento del buffer audio per i lati di input e di output degli endpoint corrispondenti nello stesso thread quando entrambi sono attivi e deve inserire il callback di output immediatamente dopo il ritorno dal callback di input. In alternativa, se non è possibile gestire i callback nello stesso thread, inserisci il callback di output poco dopo aver inserito il callback di input per consentire all'applicazione di avere una tempistica coerente dei lati di input e output.
• DEVE ridurre al minimo la differenza di fase tra il buffering audio HAL per i lati di input e di output degli endpoint corrispondenti.
• DEVE ridurre al minimo la latenza del tocco.
• DOVREBBE ridurre al minimo la variabilità della latenza tocco sotto carico (jitter).
• DEVE avere una latenza dall'input tocco all'uscita audio inferiore o uguale a 40 ms.

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

• [SR] È FORTEMENTE CONSIGLIATO segnalare il supporto della funzionalità android.hardware.audio.pro tramite la classe android.content.pm.PackageManager.

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

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

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

• [C-3-1] È NECESSARIO implementare la classe audio USB.
• [C-3-2] DEVE avere una latenza audio continua nel tempo di round trip pari o inferiore a 20 ms sulla porta in modalità host USB utilizzando la classe audio USB.
• La latenza audio in tempo di round trip continuo DEVE essere pari o inferiore a 10 millisecondi sulla porta in modalità host USB utilizzando la classe audio USB.

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

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

5.11. Acquisisci per non elaborato

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

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

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

• [C-1-2] DEVE presentare caratteristiche di ampiezza rispetto alla frequenza approssimativamente piatte nell'intervallo di frequenza medio: in particolare ±10 dB da 100 Hz a 7000 Hz per ogni microfono utilizzato per registrare l'origine audio non elaborata.

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

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

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

• [C-1-6] DEVE avere un rapporto segnale/rumore (SNR) di almeno 60 dB per ogni microfono utilizzato per registrare l'origine audio non elaborata. (mentre il rapporto SNR viene misurato come differenza tra 94 dB SPL e SPL equivalente del rumore proprio, ponderato A).

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

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

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

Tutte le misurazioni SPL vengono effettuate direttamente accanto al microfono in prova. Per più configurazioni del microfono, questi requisiti si applicano a ogni microfono.

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

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

6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori

6.1. Strumenti per sviluppatori

Implementazioni dei dispositivi:

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

• Android Debug Bridge (ADB)

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

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

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

• Dalvik Debug Monitor Service (ddms)

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

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

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

6.2. Opzioni sviluppatore

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

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

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

7. Compatibilità hardware

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

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

Se un'API nell'SDK interagisce con un componente hardware dichiarato facoltativo e l'implementazione del dispositivo non dispone di questo componente:

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

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

7.1. Display e grafica

Android include funzionalità che regolano automaticamente gli asset dell'applicazione e i layout dell'interfaccia utente in base al dispositivo per garantire il corretto funzionamento delle applicazioni di terze parti su una varietà di configurazioni hardware. I dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

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

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

7.1.1. Configurazione schermo

7.1.1.1. Dimensioni e forma dello schermo

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

Implementazioni dei dispositivi:

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

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

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

• POTREBBE avere un display con angoli arrotondati.

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

• [C-1-1] È NECESSARIO assicurarsi che il raggio degli angoli arrotondati sia inferiore o uguale a 38 dp.
• DEVE includere l'affordance per consentire all'utente di passare alla modalità di visualizzazione con gli angoli rettangolari.

7.1.1.2. Proporzioni dello schermo

Sebbene non sia prevista alcuna limitazione per il valore delle proporzioni dello schermo del display fisico, le proporzioni dello schermo del display logico in cui vengono visualizzate le app di terze parti, come dedotto dai valori di altezza e larghezza riportati tramite le API view.Display e l'API Configuration, DEVONO soddisfare i seguenti requisiti:

• [C-0-1] Le implementazioni dei dispositivi con Configuration.uiMode impostato su UI_MODE_TYPE_NORMAL DEVONO avere un valore di proporzioni compreso tra 1,3333 (4:3) e 1,86 (circa 16:9), a meno che l'app non possa essere considerata pronta per essere allungata soddisfacendo una delle seguenti condizioni:

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

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

7.1.1.3. Densità schermo

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

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

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

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

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

7.1.2. Metriche relative alla visualizzazione

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

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

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

• [C-2-1] DEVE riportare valori ragionevoli per tutte le metriche di visualizzazione definite nell'API android.util.DisplayMetrics per il view.Display predefinito emulato.

7.1.3. Orientamento schermo

Implementazioni dei dispositivi:

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

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

• [C-1-1] DEVE supportare l'orientamento dinamico da parte delle applicazioni per l'orientamento dello schermo verticale o orizzontale. In altre parole, il dispositivo deve rispettare la richiesta dell'applicazione di un orientamento dello schermo specifico.
• [C-1-2] NON DEVE modificare le dimensioni o la densità dello schermo registrate quando si cambia l'orientamento.
• PUO' selezionare l'orientamento verticale o orizzontale come predefinito.

7.1.4. Accelerazione grafica 2D e 3D

7.1.4.1 OpenGL ES

Implementazioni dei dispositivi:

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

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

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

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

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

Se le implementazioni del dispositivo dichiarano il supporto di OpenGL ES 3.0, 3.1 o 3.2:

• [C-3-1] È NECESSARIO esportare i simboli di funzione corrispondenti per queste versioni, oltre ai simboli di funzione OpenGL ES 2.0, nella libreria libGLESv2.so.

Se le implementazioni dei dispositivi supportano OpenGL ES 3.2:

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

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

• [C-5-1] È NECESSARIO identificare il supporto tramite il flag della funzionalità android.hardware.opengles.aep.

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

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

7.1.4.2 Vulkan

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

Se le implementazioni del dispositivo supportano OpenGL ES 3.1:

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

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

• DOVREBBE includere il supporto di Vulkan 1.1.

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

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

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

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

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

• [C-3-1] DEVE esporre il supporto per i tipi di handle e semafori esterni SYNC_FD.
• [SR] Sono FORTEMENTE CONSIGLIATI per 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 nella documentazione dell'SDK Android.

7.1.4.4 Accelerazione grafica 2D

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

Implementazioni dei dispositivi:

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

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

Implementazioni dei dispositivi:

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

7.1.4.5 Display con gamma di colori ampliata

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

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

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

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

7.1.5. Modalità di compatibilità delle applicazioni precedenti

Android specifica una "modalità di compatibilità" in cui il framework opera in una modalità equivalente alle dimensioni dello schermo "normali" (larghezza di 320 dp) a vantaggio delle applicazioni precedenti non sviluppate per le versioni precedenti di Android precedenti all'indipendenza dalle dimensioni dello schermo.

7.1.6. Tecnologia dello schermo

La piattaforma Android include API che consentono alle applicazioni di eseguire il rendering di grafica avanzata sul display. I dispositivi DEVONO supportare tutte queste API come definite dall'SDK Android, a meno che non sia specificamente consentito in questo documento.

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare i display in grado di eseguire il rendering di grafica a colori a 16 bit.
• DOVREBBE supportare i display in grado di gestire la grafica a colori a 24 bit.
• [C-0-2] DEVE supportare i display in grado di eseguire il rendering delle animazioni.
• [C-0-3] È OBBLIGATORIO utilizzare la tecnologia di visualizzazione con un rapporto di aspetto dei pixel (PAR) compreso tra 0,9 e 1,15. In altre parole, le proporzioni dei pixel DEVONO essere quasi quadrate (1,0) con una tolleranza del 10-15%.

7.1.7. Display secondari

Android include il supporto per il display secondario per abilitare le funzionalità di condivisione dei contenuti multimediali e le API per sviluppatori per accedere ai display esterni.

Se le implementazioni dei dispositivi supportano un display esterno tramite una connessione con cavo, wireless o un display aggiuntivo integrato, devono:

• [C-1-1] DEVE implementare il servizio di sistema e l'API DisplayManager come descritto nella documentazione dell'SDK Android.

7.2. Dispositivi di immissione

Implementazioni dei dispositivi:

• [C-0-1] DEVE includere un meccanismo di input, ad esempio un touchscreen o la navigazione non tocco, per spostarsi tra gli elementi dell'interfaccia utente.

7.2.1. Tastiera

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

• [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità android.software.input_methods.
• [C-1-2] DEVE essere implementato 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 corrisponda a uno dei formati specificati in android.content.res.Configuration.keyboard (QWERTY o 12 tasti). * DEVE includere implementazioni aggiuntive della tastiera virtuale. * POTREBBE includere una tastiera hardware.

7.2.2. Navigazione non tocco

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

Implementazioni dei dispositivi:

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

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

• [C-1-1] DEVE fornire un meccanismo di interfaccia utente alternativo ragionevole per la selezione e la modifica del testo, compatibile con gli Input Management Engine. L'implementazione open source di Android upstream include un meccanismo di selezione adatto all'uso con dispositivi che non dispongono di input di navigazione non touch.

7.2.3. Tasti di navigazione

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

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

Se sono fornite le funzioni Home, Recenti o Indietro:

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

Implementazioni dei dispositivi:

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

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

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

Se le implementazioni dei dispositivi non forniscono la funzione Menu, per la compatibilità con le versioni precedenti: * [C-3-1] DEVONO rendere disponibile la funzione Menu per le applicazioni quando targetSdkVersion è inferiore a 10, tramite un pulsante fisico, una chiave software o gesti. Questa funzione Menu dovrebbe essere accessibile, a meno che non sia nascosta insieme ad altre funzioni di navigazione.

Se le implementazioni del dispositivo forniscono la funzione di assistenza: * [C-4-1] DEVONO rendere accessibile la funzione di assistenza con una singola azione (ad es. tocco, doppio clic o gesto) quando sono accessibili altri tasti di navigazione. * [SR] È MOLTO CONSIGLIATO utilizzare la pressione prolungata sulla funzione HOME come interazione designata.

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

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

7.2.4. Input touchscreen

Android include il supporto di una serie di sistemi di input del cursore, come touchscreen, touchpad e dispositivi di input touch simulati. Le implementazioni dei dispositivi basati su touchscreen sono associate a un display in modo che l'utente abbia l'impressione di manipolare direttamente gli elementi sullo schermo. Poiché l'utente tocca direttamente lo schermo, il sistema non richiede alcun'altra funzionalità per indicare gli oggetti manipolati.

Implementazioni dei dispositivi:

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

Se le implementazioni dei dispositivi includono un touchscreen (monotocco o superiore), devono:

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

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

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

Se le implementazioni dei dispositivi non includono un touchscreen (e si basano solo su un dispositivo di puntamento) e soddisfano i requisiti per i tocchi falsi descritti nella sezione 7.2.5, devono:

• [C-3-1] NON DEVE segnalare alcun flag della funzionalità che inizia con android.hardware.touchscreen e DEVE segnalare solo android.hardware.faketouch.

7.2.5. Input tocco simulato

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

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

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

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

• [C-1-1] DEVE indicare le posizioni sullo schermo X e Y assolute della posizione del cursore e mostrare un cursore visivo sullo schermo.
• [C-1-2] È OBBLIGATORIO registrare l'evento tocco con il codice azione che specifica la modifica dello stato che si verifica quando il cursore si sposta verso il basso o verso l'alto sullo schermo.
• [C-1-3] DEVE supportare il movimento del cursore verso il basso e verso l'alto su un oggetto sullo schermo, il che consente agli utenti di emulare il tocco di un oggetto sullo schermo.
• [C-1-4] DEVE supportare il cursore verso il basso, il cursore verso l'alto, il cursore verso il basso e poi il cursore verso l'alto nello stesso punto su un oggetto sullo schermo entro una soglia di tempo, il che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo.
• [C-1-5] DEVE supportare il cursore verso il basso in un punto arbitrario dello schermo, il cursore si sposta in un altro punto arbitrario dello schermo, seguito da un cursore verso l'alto, che consente agli utenti di emulare un trascinamento con tocco.
• [C-1-6] DEVE supportare il cursore verso il basso, quindi consentire agli utenti di spostare rapidamente l'oggetto in un'altra posizione sullo schermo e poi il cursore verso l'alto sullo schermo, in modo da consentire agli utenti di lanciare un oggetto sullo schermo.
• [C-1-7] È OBBLIGATORIO segnalare TOUCHSCREEN_NOTOUCH per il campo dell'API Configuration.touchscreen.

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

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

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

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

7.2.6. Supporto del controller di gioco

7.2.6.1. Mappature dei pulsanti

Se le implementazioni del dispositivo dichiarano il flag della funzionalità android.hardware.gamepad:

• [C-1-1] DEVE avere un controller integrato o essere fornito con un controller separato nella confezione, che fornisca i mezzi per inserire tutti gli eventi elencati nelle tabelle seguenti.
• [C-1-2] DEVE essere in grado di mappare gli eventi HID alle costanti view.InputEvent di Android associate, come elencato nelle tabelle seguenti. L'implementazione di Android a monte include l'implementazione per i controller di gioco che soddisfano questo requisito.

Pulsante	Utilizzo HID2	Pulsante Android
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Pulsante direzionale su1 Pulsante direzionale giù1	0x01 0x00393	AXIS_HAT_Y4
D-pad sinistra1 D-pad destra1	0x01 0x00393	AXIS_HAT_X4
Pulsante del tasto sinistro1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Pulsante del tasto funzione destro1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic con la levetta sinistra1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic con il tasto destro della levetta1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Home1	0x0c 0x0223	KEYCODE_HOME (3)
Indietro1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Gli utilizzi HID sopra indicati devono essere dichiarati all'interno di una CA per gamepad (0x01 0x0005).

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

4 MotionEvent

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

1 MotionEvent

7.2.7. Telecomando

Per i requisiti specifici dei dispositivi, consulta la sezione 2.3.1.

7.3. Sensori

Se le implementazioni del dispositivo includono un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android e nella documentazione Android Open Source sui sensori.

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare con precisione la presenza o l'assenza di sensori in base alla classe android.content.pm.PackageManager.
• [C-0-2] DEVE restituire un elenco accurato dei sensori supportati tramite SensorManager.getSensorList() e metodi simili.
• [C-0-3] DEVE comportarsi in modo ragionevole per tutte le altre API di sensori (ad esempio, restituendo true o false a seconda dei casi quando le applicazioni tentano di registrare gli ascoltatori, non chiamando gli ascoltatori dei sensori quando i sensori corrispondenti non sono presenti e così via).

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

• [C-1-1] È NECESSARIO segnalare tutte le misurazioni del sensore utilizzando i valori pertinenti del Sistema internazionale di unità di misura (metrico) per ogni tipo di sensore, come definito nella documentazione dell'SDK Android.
• [C-1-2] DEVE segnalare i dati del sensore con una latenza massima di 100 millisecondi + 2 * sample_time per il caso di 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 i ritardi dovuti ai filtri.
• [C-1-3] DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time dall'attivazione del sensore. È accettabile che questo campione abbia una precisione pari a 0.

• [SR] DOVREBBE registrare l'ora dell'evento in nanosecondi come definito nella documentazione dell'SDK Android, che rappresenta l'ora in cui si è verificato l'evento e sincronizzata con l'orologio SystemClock.elapsedRealtimeNano(). È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma, dove questo potrebbe diventare un componente OBBLIGATORIO. L'errore di sincronizzazione DEVE essere inferiore a 100 millisecondi.

• [C-1-4] Affinché qualsiasi API indicata dalla documentazione dell'SDK Android sia un sensore continuo, le implementazioni dei dispositivi DEVONO fornire continuamente campioni di dati periodici che DEVONO avere un jitter inferiore al 3%, dove il jitter è definito come la deviazione standard della differenza dei valori timestamp registrati tra eventi consecutivi.

• [C-1-5] DEVE garantire che lo stream di eventi del sensore NON DEVE impedire alla CPU del dispositivo di entrare in uno stato di sospensione o di riattivarsi da uno stato di sospensione.

• Quando sono attivati più sensori, il consumo di energia NON DEVE superare la somma del consumo di energia registrato dal singolo sensore.

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

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

Implementazioni dei dispositivi:

• DEBBA implementare questi tipi di sensori, se includono i sensori fisici prerequisiti descritti nella sezione tipi di sensori.

Se le implementazioni dei dispositivi includono un sensore composito:

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

7.3.1. Accelerometro

• Le implementazioni dei dispositivi DEVONO includere un accelerometro a 3 assi.

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

• [C-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 50 Hz.
• [C-1-2] È NECESSARIO implementare e segnalare il sensore TYPE_ACCELEROMETER.
• [C-1-3] DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nelle API Android.
• [C-1-4] DEVE essere in grado di misurare da caduta libera fino a quattro volte la gravità(4 g) o più su qualsiasi asse.
• [C-1-5] DEVE avere una risoluzione di almeno 12 bit.
• [C-1-6] DEVE avere una deviazione standard non superiore a 0,05 m/s^, dove la deviazione standard deve essere calcolata in base all'asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più elevata.
• [SR] sono FORTEMENTE CONSIGLIATI per implementare il sensore composito TYPE_SIGNIFICANT_MOTION.
• [SR] È MOLTO CONSIGLIATO implementare il sensore TYPE_ACCELEROMETER_UNCALIBRATED se è disponibile la calibrazione dell'accelerometro online.
• DEBBA implementare i sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento dell'SDK Android.
• DEVE registrare eventi fino ad almeno 200 Hz.
• DEVE avere una risoluzione di almeno 16 bit.
• DEVE essere calibrato durante l'uso se le caratteristiche cambiano nel ciclo di vita e vengono compensate e deve conservare i parametri di compensazione tra i riavvii del dispositivo.
• DEVE essere compensato in base alla temperatura.
• DOVREBBE anche implementare il sensore TYPE_ACCELEROMETER_UNCALIBRATED.

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

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

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

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

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

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

7.3.2. Magnetometro

• Le implementazioni dei dispositivi DEVONO includere un magnetometro a 3 assi (bussola).

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

• [C-1-1] È NECESSARIO implementare il sensore TYPE_MAGNETIC_FIELD.
• [C-1-2] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 10 Hz e DOVREBBE registrare eventi fino ad almeno 50 Hz.
• [C-1-3] DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nelle API Android.
• [C-1-4] DEVE essere in grado di misurare tra -900 µT e +900 µT su ogni asse prima della saturazione.
• [C-1-5] DEVE avere un valore di offset del ferro duro inferiore a 700 µT e DOVREBBE avere un valore inferiore a 200 µT, posizionando il magnetometro lontano da campi magnetici dinamici (indotti dalla corrente) e statici (indotti dal magnete).
• [C-1-6] DEVE avere una risoluzione uguale o superiore a 0,6 µT.
• [C-1-7] DEVE supportare la calibrazione e la compensazione online del bias hardware e conservare i parametri di compensazione tra i riavvii del dispositivo.
• [C-1-8] È OBBLIGATORIO applicare la compensazione del ferro dolce. La calibrazione può essere eseguita durante l'uso o durante la produzione del dispositivo.
• [C-1-9] DEVE avere una deviazione standard, calcolata in base all'asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più elevata, non superiore a 1,5 µT; DEVE avere una deviazione standard non superiore a 0,5 µT.
• DOVREBBE implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] È FORTEMENTE CONSIGLIATO di implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED sui dispositivi Android esistenti e nuovi.

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

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

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

• PUO' implementare il sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

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

7.3.3. GPS

Implementazioni dei dispositivi:

• DEVE includere un ricevitore GPS/GNSS.

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

• [C-1-1] DEVE supportare le uscite di posizione a una frequenza di almeno 1 Hz quando richieste tramite LocationManager#requestLocationUpdate.
• [C-1-2] DEVE essere in grado di determinare la posizione in condizioni di cielo aperto (segnali forti, multipath trascurabile, HDOP < 2) entro 10 secondi (tempo di prima correzione rapido), quando è connesso a una connessione a internet con velocità di dati di almeno 0,5 Mbps. Questo requisito viene generalmente soddisfatto mediante l'utilizzo di una qualche forma di tecnica GPS/GNSS assistita o prevista per ridurre al minimo il tempo di accoppiamento GPS/GNSS (i dati di assistenza includono ora di riferimento, posizione di riferimento ed effemeride/orologio satellitare).
  • [C-1-6] Dopo aver eseguito questo calcolo della posizione, le implementazioni del dispositivo DEVONO determinare la posizione, in cielo aperto, entro 5 secondi, quando le richieste di geolocalizzazione vengono riavviate, fino a un'ora dopo il calcolo iniziale della posizione, anche quando la richiesta successiva viene effettuata senza una connessione dati e/o dopo un ciclo di alimentazione.

• In condizioni di cielo aperto dopo aver determinato la posizione, a veicolo fermo o in movimento con un'accelerazione inferiore a 1 metro al secondo quadrato:

  • [C-1-3] DEVE essere in grado di determinare la posizione entro 20 metri e la velocità entro 0, 5 metri al secondo, almeno il 95% delle volte.
  • [C-1-4] DEVE monitorare e segnalare contemporaneamente tramite GnssStatus.Callback almeno 8 satelliti di una costellazione.
  • DOVREBBE essere in grado di rilevare contemporaneamente almeno 24 satelliti di più costellazioni (ad es. GPS + almeno uno di Glonass, Beidou, Galileo).
  • [C-1-5] DEVE segnalare la generazione della tecnologia GNSS tramite l'API di test "getGnssYearOfHardware".
  • [SR] Continuare a fornire normali output di posizione GPS/GNSS durante una chiamata di emergenza.
  • [SR] Segnala le misurazioni GNSS di tutte le costellazioni monitorate (come indicato nei messaggi GnssStatus), ad eccezione di SBAS.
  • [SR] Segnala AGC e la frequenza della misurazione GNSS.
  • [SR] Segnala tutte le stime di accuratezza (tra cui direzione, velocità e verticale) all'interno di ogni posizione GPS/GNSS.
  • [SR] È FORTEMENTE CONSIGLIATO soddisfare il maggior numero possibile di requisiti obbligatori aggiuntivi per i dispositivi che riportano l'anno "2016" o "2017" tramite l'API di test LocationManager.getGnssYearOfHardware().

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

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

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

• [C-3-1] DEVE continuare a fornire normali output di posizione GPS/GNSS durante una chiamata di emergenza.
• [C-3-2] DEVE segnalare le misurazioni GNSS di tutte le costellazioni monitorate (come indicato nei messaggi GnssStatus), ad eccezione di SBAS.
• [C-3-3] È OBBLIGATORIO segnalare l'AGC e la frequenza della misurazione GNSS.
• [C-3-4] È OBBLIGATORIO segnalare tutte le stime di accuratezza (incluse direzione, velocità e verticale) all'interno di ogni posizione GPS/GNSS.

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

• [C-4-1] DEVE continuare a fornire normali output GPS/GNSS alle applicazioni durante una chiamata di emergenza avviata dalla rete basata su stazioni mobili (MS).
• [C-4-2] DEVE segnalare le posizioni e le misurazioni alle API GNSS Location Provider.

7.3.4. Giroscopio

Implementazioni dei dispositivi:

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

Se le implementazioni del dispositivo includono un giroscopio:

• [C-1-1] DEVE essere in grado di registrare eventi fino a una frequenza di almeno 50 Hz.
• [C-1-2] DEVE implementare il sensore TYPE_GYROSCOPE e DOVREBBE implementare anche il sensore TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-3] DEVE essere in grado di misurare le variazioni di orientamento fino a 1000 gradi al secondo.
• [C-1-4] DEVE avere una risoluzione di almeno 12 bit e DOVREBBE avere una risoluzione di almeno 16 bit.
• [C-1-5] DEVE essere compensato in base alla temperatura.
• [C-1-6] DEVE essere calibrato e compensato durante l'uso e deve conservare i parametri di compensazione tra i riavvii del dispositivo.
• [C-1-7] DEVE avere una varianza non superiore a 1e-7 rad^2 / s^2 per Hz (varianza per Hz o rad^2 / s). La varianza può variare con la frequenza di campionamento, ma DEVE essere vincolata da questo valore. In altre parole, se misuri la varianza del giroscopio a una frequenza di campionamento di 1 Hz, NON deve essere superiore a 1e-7 rad^2/s^2.
• [SR] È FORTEMENTE CONSIGLIATO di implementare il sensore SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sui dispositivi Android esistenti e nuovi.
• [SR] È FORTEMENTE CONSIGLIATO che l'errore di calibrazione sia inferiore a 0,01 rad/s quando il dispositivo è fermo a temperatura ambiente.
• DEVE registrare eventi fino ad almeno 200 Hz.

Se le implementazioni del dispositivo includono un giroscopio, un sensore di accelerazione e un sensore di magnete:

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

Se le implementazioni del dispositivo includono un giroscopio e un sensore di accelerazione, devono:

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

7.3.5. Barometro

• Le implementazioni dei dispositivi DEVONO includere un barometro (sensore di pressione dell'aria ambiente).

Se le implementazioni del dispositivo includono un barometro:

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

7.3.6. Termometro

Implementazioni del dispositivo: * POTREBBE includere un termometro ambiente (sensore di temperatura). * PUO\', ma NON DEVE, includere un sensore di temperatura della CPU.

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

• [C-1-1] DEVE essere definito come SENSOR_TYPE_AMBIENT_TEMPERATURE e DEVE misurare la temperatura ambiente (della stanza/della cabina del veicolo) da dove 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 altre temperature.

Tieni presente che il tipo di sensore SENSOR_TYPE_TEMPERATURE è stato ritirato in Android 4.0.

7.3.7. Fotometro

• Le implementazioni del dispositivo POSSONO includere un fotometro (sensore di luce ambientale).

7.3.8. Sensore di prossimità

• Le implementazioni del dispositivo POSSONO includere un sensore di prossimità.

Se le implementazioni del dispositivo includono un sensore di prossimità:

• [C-1-1] DEVE misurare la prossimità di un oggetto nella stessa direzione dello schermo. In altre parole, il sensore di prossimità DEVE essere orientato in modo da rilevare gli oggetti vicini allo schermo, poiché lo scopo principale di questo tipo di sensore è rilevare uno smartphone in uso dall'utente. Se le implementazioni del dispositivo includono un sensore di prossimità con qualsiasi altro orientamento, NON DEVE essere accessibile tramite questa API.
• [C-1-2] DEVE avere una precisione di almeno 1 bit.

7.3.9. Sensori ad alta fedeltà

Se le implementazioni dei dispositivi includono un insieme di sensori di qualità superiore come definito in questa sezione e li rendono disponibili per le app di terze parti, devono:

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

Se le implementazioni del dispositivo dichiarano android.hardware.sensor.hifi_sensors:

• [C-2-1] DEVE avere un sensore TYPE_ACCELEROMETER che:

  • DEVE avere un intervallo di misurazione compreso tra almeno -8 g e +8 g, DOVREBBE avere un intervallo di misurazione compreso tra almeno -16 g e +16 g.
  • DEVE avere una risoluzione di misurazione di almeno 2048 LSB/g.
  • DEVE avere una frequenza di misurazione minima pari o inferiore a 12,5 Hz.
  • DEVE avere una frequenza di misurazione massima di almeno 400 Hz; DEVE supportare il canale SensorDirectChannel RATE_VERY_FAST.
  • DEVE avere un rumore di misurazione non superiore a 400 μg/√Hz.
  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore.
  • DEVE avere un consumo energetico per il raggruppamento non superiore a 3 mW.
  • [C-SR] È FORTEMENTE CONSIGLIATO di avere una larghezza di banda di misurazione di 3 dB di almeno l'80% della frequenza di Nyquist e uno spettro di rumore bianco all'interno di questa larghezza di banda.
  • DEVE avere una passeggiata casuale dell'accelerazione inferiore a 30 μg √Hz testata a temperatura ambiente.
  • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 1 mg/°C.
  • DEVE avere una non linearità della linea di adattamento ottimale pari o inferiore allo 0,5% e una variazione di sensibilità rispetto alla temperatura pari o inferiore allo 0,03%/°C.
  • DEVE avere una sensibilità trasversale inferiore al 2,5 % e una variazione della sensibilità trasversale inferiore allo 0,2% nell'intervallo di temperatura di funzionamento del dispositivo.

• [C-2-2] DEVE avere un TYPE_ACCELEROMETER_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_ACCELEROMETER.

• [C-2-3] DEVE avere un sensore TYPE_GYROSCOPE che:

  • DEVE avere un intervallo di misurazione compreso tra almeno -1000 e +1000 dps.
  • DEVE avere una risoluzione di misurazione di almeno 16 LSB/dps.
  • DEVE avere una frequenza di misurazione minima pari o inferiore a 12,5 Hz.
  • DEVE avere una frequenza di misurazione massima di almeno 400 Hz; DEVE supportare il canale SensorDirectChannel RATE_VERY_FAST.
  • DEVE avere un rumore di misurazione non superiore a 0,014°/s/√Hz.
  • [C-SR] È FORTEMENTE CONSIGLIATO di avere una larghezza di banda di misurazione di 3 dB di almeno l'80% della frequenza di Nyquist e uno spettro di rumore bianco all'interno di questa larghezza di banda.
  • DEVE avere una deriva casuale della frequenza inferiore a 0,001 °/s √Hz testata a temperatura ambiente.
  • DEVE avere una variazione di bias rispetto alla temperatura di ≤ +/- 0,05 °/ s / °C.
  • DOVREBBE avere una variazione di sensibilità rispetto alla temperatura di ≤ 0,02% / °C.
  • DEVE avere una non linearità della linea di miglior adattamento pari o inferiore allo 0,2%.
  • DEVE avere una densità di rumore ≤ 0,007 °/s/√Hz.
  • DEVE avere un errore di calibrazione inferiore a 0,002 rad/s nell'intervallo di temperatura compreso tra 10 e 40 °C quando il dispositivo è fermo.
  • DEVE avere una sensibilità g inferiore a 0,1°/s/g.
  • DEVE avere una sensibilità trasversale inferiore al 4,0 % e una variazione di sensibilità trasversale inferiore allo 0,3% nell'intervallo di temperatura di funzionamento del dispositivo.

• [C-2-4] DEVE avere un TYPE_GYROSCOPE_UNCALIBRATED con gli stessi requisiti di qualità di TYPE_GYROSCOPE.

• [C-2-5] DEVE avere un sensore TYPE_GEOMAGNETIC_FIELD che:

  • DEVE avere un intervallo di misurazione compreso tra almeno -900 e +900 μT.
  • DEVE avere una risoluzione di misurazione di almeno 5 LSB/uT.
  • DEVE avere una frequenza di misurazione minima pari o inferiore a 5 Hz.
  • DEVE avere una frequenza di misurazione massima di 50 Hz o superiore.
  • DEVE avere un rumore di misurazione non superiore a 0,5 uT.

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

  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 600 eventi del sensore.
  • [C-SR] È FORTEMENTE CONSIGLIATO di avere uno spettro di rumore bianco da 1 Hz ad almeno 10 Hz quando la frequenza di generazione dei report è pari o superiore a 50 Hz.

• [C-2-7] DEVE avere un sensore TYPE_PRESSURE che:

  • DEVE avere un intervallo di misurazione compreso tra almeno 300 e 1100 hPa.
  • DEVE avere una risoluzione di misurazione di almeno 80 LSB/hPa.
  • DEVE avere una frequenza di misurazione minima pari o inferiore a 1 Hz.
  • DEVE avere una frequenza di misurazione massima di almeno 10 Hz.
  • DEVE avere un rumore di misurazione non superiore a 2 Pa/√Hz.
  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
  • DEVE avere un consumo energetico per il raggruppamento non superiore a 2 mW.
• [C-2-8] DEVE avere un sensore TYPE_GAME_ROTATION_VECTOR che:
  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 300 eventi del sensore.
  • DEVE avere un consumo energetico per l'aggregazione non superiore a 4 mW.
• [C-2-9] DEVE avere un sensore TYPE_SIGNIFICANT_MOTION che:
  • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
• [C-2-10] DEVE avere un sensore TYPE_STEP_DETECTOR che:
  • DEVE implementare una forma non di risveglio di questo sensore con una capacità di buffering di almeno 100 eventi del sensore.
  • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
  • DEVE avere un consumo energetico per l'aggregazione non superiore a 4 mW.
• [C-2-11] DEVE avere un sensore TYPE_STEP_COUNTER che:
  • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
• [C-2-12] DEVE avere un sensore TILT_DETECTOR che:
  • DEVE avere un consumo di energia non superiore a 0,5 mW quando il dispositivo è fermo e 1,5 mW quando è in movimento.
• [C-2-13] Il timestamp dello stesso evento fisico registrato dall'accelerometro, dal giroscopio e dal magnetometro DEVE essere compreso tra 2, 5 millisecondi. Il timestamp dello stesso evento fisico registrato dall'accelerometro e dal giroscopio DEVE essere compreso in un intervallo di 0,25 millisecondi.
• [C-2-14] DEVE avere i timestamp degli eventi del sensore giroscopico sulla stessa base di tempo del sottosistema della videocamera e con un errore massimo di 1 millisecondo.
• [C-2-15] DEVE inviare i campioni alle applicazioni entro 5 millisecondi dal momento in cui i dati sono disponibili su uno dei sensori fisici sopra indicati per l'applicazione.
• [C-2-16] NON DEVE avere un consumo di energia superiore a 0,5 mW quando il dispositivo è fermo e 2,0 mW quando il dispositivo è in movimento quando è attiva qualsiasi combinazione dei seguenti sensori:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] PUO' avere un sensore TYPE_PROXIMITY, ma se presente DEVE avere una capacità di buffer minima di 100 eventi del sensore.

Tieni presente che tutti i requisiti di consumo energetico in questa sezione non includono il consumo energetico dell'Application Processor. Sono incluse le potenze assorbite dall'intera catena del sensore: il sensore, eventuali circuiti di supporto, qualsiasi sistema di elaborazione del sensore dedicato e così via.

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

• [C-3-1] È NECESSARIO dichiarare correttamente il supporto dei tipi di canali diretti e del livello di frequenza dei report diretti tramite le API isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
• [C-3-2] DEVE supportare almeno uno dei due tipi di canali diretti del sensore per tutti i sensori che dichiarano il supporto del canale diretto del sensore.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DOVREBBE supportare i report sugli eventi tramite il canale diretto del sensore per il sensore principale (variante senza risveglio) 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 del dispositivo includono una schermata di blocco sicura:

• DEVE includere un sensore di impronte digitali.

Se le implementazioni del dispositivo includono un sensore di impronte e lo rendono disponibile per le app di terze parti, devono:

• [C-1-1] DEVE dichiarare il supporto della funzionalità android.hardware.fingerprint.
• [C-1-2] DEVE implementare completamente l'API corrispondente come descritto nella documentazione dell'SDK Android.
• [C-1-3] DEVE avere un tasso di accettazione di falsi positivi non superiore allo 0,002%.
• [SR] È FORTEMENTE CONSIGLIATO di avere un tasso di accettazione di attività fraudolente e di furto d'identità non superiore al 7%.
• [C-1-4] È OBBLIGATORIO indicare che questa modalità potrebbe essere meno sicura di una sequenza, un PIN o una password efficaci ed elencare chiaramente i rischi di attivazione, se i tassi di accettazione di spoofing e furto d'identità sono superiori al 7%.
• [C-1-5] È OBBLIGATORIO applicare un limite di frequenza dei tentativi per almeno 30 secondi dopo cinque tentativi falsi per la verifica dell'impronta.
• [C-1-6] DEVE avere un'implementazione del keystore basata su hardware ed eseguire la corrispondenza delle impronte in un Trusted Execution Environment (TEE) o su un chip con un canale sicuro per il TEE.
• [C-1-7] DEVE avere tutti i dati delle 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 per l'implementazione sul sito del progetto open source Android.
• [C-1-8] DEVE impedire l'aggiunta di un'impronta senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare una credenziale del dispositivo esistente o di aggiungerne una nuova (PIN/pattern/password) protetta dal TEE; l'implementazione del progetto open source Android fornisce il meccanismo nel framework per farlo.
• [C-1-9] NON DEVE consentire ad applicazioni di terze parti di distinguere tra impronte individuali.
• [C-1-10] DEVE rispettare il flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• [C-1-11] È NECESSARIO, quando viene eseguito l'upgrade da una versione precedente ad Android 6.0, eseguire la migrazione sicura dei dati delle impronte per soddisfare i requisiti precedenti o rimuoverli.
• [C-1-12] È OBBLIGATORIO rimuovere completamente tutti i dati delle impronte digitali identificabili di un utente quando l'account dell'utente viene rimosso (anche tramite un ripristino dei dati di fabbrica).
• [C-1-13] NON deve consentire l'accesso non criptato ai dati dell'impronta identificabili o a qualsiasi dato derivi da questi (ad esempio gli embedding) all'Elaboratore delle applicazioni.
• [SR] È FORTEMENTE CONSIGLIATO di avere un tasso di falsi rifiuti inferiore al 10%, misurato sul dispositivo.
• [SR] È MOLTO CONSIGLIATO avere una latenza inferiore a 1 secondo, misurata dal momento in cui viene toccato il sensore di impronte digitali fino al momento in cui lo schermo viene sbloccato, per un dito registrato.
• DEBBA utilizzare l'icona Impronta 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 su impronte digitali e li rendono disponibili per le app di terze parti, devono:

• [C-1-1] DEVE avere un tasso di accettazione di falsi non superiore allo 0,002%.
• [C-SR] È FORTEMENTE CONSIGLIATO di avere un tasso di accettazione di spoofing e furti d'identità non superiore al 7%.
• [C-1-2] È OBBLIGATORIO indicare che questa modalità potrebbe essere meno sicura di una sequenza, un PIN o una password efficaci ed elencare chiaramente i rischi di attivazione, se i tassi di accettazione di spoofing e furto d'identità sono superiori al 7%.
• [C-1-3] DEVE applicare un limite di frequenza dei tentativi per almeno 30 secondi dopo cinque prove false per la verifica biometrica, dove una prova falsa è una con una qualità di acquisizione adeguata (ACQUIRED_GOOD) che non corrisponde a un dato biometrico registrato
• [C-1-4] DEVE avere un'implementazione del keystore basata su hardware ed eseguire la corrispondenza biometrica in un TEE o su un chip con un canale sicuro per il 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 oppure un chip con un canale sicuro per il TEE come documentato nelle linee guida per l'implementazione sul sito del progetto open source Android.
• [C-1-6] DEVE impedire l'aggiunta di nuove informazioni biometriche senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare le credenziali esistenti o di aggiungerne di nuove (PIN/pattern/password) protette dal TEE; l'implementazione del progetto open source Android fornisce il meccanismo necessario nel framework.
• [C-1-7] NON DEVE consentire ad applicazioni di terze parti di distinguere tra registrazioni biometriche.
• [C-1-8] DEVE rispettare il singolo flag per la biometrica in questione (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 l'account dell'utente viene rimosso (anche tramite un ripristino dei dati di fabbrica).
• [C-1-10] NON deve consentire l'accesso non criptato a dati biometrici identificabili o a dati derivati (ad esempio embedding) all'Elaboratore di applicazioni al di fuori del contesto del TEE.
• [C-SR] È FORTEMENTE CONSIGLIATO di avere un tasso di falsi rifiuti inferiore al 10%, misurato sul dispositivo.
• [C-SR] È FORTEMENTE CONSIGLIATO di avere una latenza inferiore a 1 secondo, misurata dal momento in cui viene rilevato il dato biometrico fino allo sblocco dello schermo, per ogni dato biometrico registrato.

7.3.11. Sensori solo per Android Automotive

I sensori specifici per i veicoli a motore sono definiti in android.car.CarSensorManager API.

7.3.11.1. Marcia attuale

Per i requisiti specifici del dispositivo, consulta la sezione 2.5.1.

7.3.11.2. Modalità Giorno/Notte

Per i requisiti specifici del dispositivo, consulta la sezione 2.5.1.

7.3.11.3. Stato di guida

Questo requisito è deprecato.

7.3.11.4. Velocità della ruota

Per i requisiti specifici del dispositivo, consulta la sezione 2.5.1.

7.3.11.5. Freno di stazionamento

Per i requisiti specifici del dispositivo, consulta la sezione 2.5.1.

7.3.12. Sensore di posizione

Implementazioni dei dispositivi:

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

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

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

7.4. Connettività dei dati

7.4.1. Telefonia

Per "Telefonia", come utilizzato dalle API Android e in questo documento, si intende in modo specifico l'hardware relativo all'invio di chiamate vocali e di messaggi SMS tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano o meno essere con commutazione di pacchetti, ai fini di Android sono considerate indipendenti da qualsiasi connettività dati che possa essere implementata utilizzando la stessa rete. In altre parole, le API e la funzionalità "telefonia" di Android si riferiscono specificamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni di dispositivi che non possono effettuare chiamate o inviare/ricevere messaggi SMS non sono considerate dispositivi di telefonia, indipendentemente dal fatto che utilizzino una rete cellulare per la connettività dati.

• Android PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. In altre parole, Android è compatibile con dispositivi diversi dagli smartphone.

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

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

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

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

7.4.1.1. Compatibilità con il blocco dei numeri

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

• [C-1-1] DEVE includere il supporto per il blocco dei numeri
• [C-1-2] DEVE implementare completamente BlockedNumberContract e l'API corrispondente come descritto nella documentazione dell'SDK.
• [C-1-3] DEVE bloccare tutte le chiamate e i messaggi da un numero di telefono in "BlockedNumberProvider" senza alcuna interazione con le app. L'unica eccezione è quando il blocco dei numeri viene rimosso temporaneamente, come descritto nella documentazione dell'SDK.
• [C-1-4] NON DEVE scrivere al provider del registro chiamate della piattaforma per una chiamata bloccata.
• [C-1-5] NON DEVE scrivere al Fornitore di telefonia per un messaggio bloccato.
• [C-1-6] DEVE implementare un'interfaccia utente per la gestione dei numeri bloccati, che viene aperta con l'intent restituito dal metodo TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] NON DEVE consentire agli utenti secondari di visualizzare o modificare i numeri bloccati sul dispositivo, in quanto la piattaforma Android presuppone che l'utente principale abbia il controllo completo dei servizi di telefonia, una singola istanza, sul dispositivo. Tutta l'interfaccia utente relativa al blocco DEVE essere nascosta per gli utenti secondari e l'elenco bloccato DEVE essere rispettato.
• DOVREBBE eseguire la migrazione dei numeri bloccati nel fornitore quando un dispositivo viene aggiornato ad Android 7.0.

7.4.1.2. API Telecom

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

• [C-1-1] DEVE supportare le API ConnectionService descritte nell'SDK.
• [C-1-2] DEVE mostrare una nuova chiamata in arrivo e fornire all'utente la possibilità di accettarla o rifiutarla quando è in corso una chiamata effettuata da un'app di terze parti che non supporta la funzionalità di messa in attesa specificata tramite CAPABILITY_SUPPORT_HOLD.

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

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

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

• [C-SR] È FORTEMENTE CONSIGLIATO gestire gli eventi KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK dell'auricolare audio per le API android.telecom come indicato di seguito:
  • Chiama Connection.onDisconnect() quando viene rilevata una breve pressione dell'evento chiave durante una chiamata in corso.
  • Chiama Connection.onAnswer() quando viene rilevata una breve pressione dell'evento chiave durante una chiamata in arrivo.
  • Chiama Connection.onReject() quando viene rilevata una pressione prolungata dell'evento chiave durante una chiamata in arrivo.
  • Attiva/disattiva lo stato di disattivazione dell'audio del CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementazioni dei dispositivi:

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

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

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

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

• [C-2-1] DEVE fornire un'affordance utente per attivare/disattivare il valore letto tramite il metodo dell'API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementazioni dei dispositivi:

• DEVE includere il supporto di Wi-Fi Direct (Wi-Fi peer-to-peer).

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

• [C-1-1] DEVE implementare l'API Android corrispondente come descritto nella documentazione dell'SDK.
• [C-1-2] DEVE segnalare la funzionalità hardware android.hardware.wifi.direct.
• [C-1-3] DEVE supportare il normale funzionamento del Wi-Fi.
• [C-1-4] DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Direct.

7.4.2.2. Configurazione del link diretto con tunnel Wi-Fi

Implementazioni dei dispositivi:

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

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

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

7.4.2.3. Wi-Fi Aware

Implementazioni dei dispositivi:

• DEVE includere il supporto di Wi-Fi Aware.

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

• [C-1-1] DEVE implementare le API WifiAwareManager come descritto nella documentazione dell'SDK.
• [C-1-2] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.wifi.aware.
• [C-1-3] DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Aware.
• [C-1-4] DEVE randomizzare l'indirizzo dell'interfaccia di gestione Wi-Fi Aware a intervalli non superiori a 30 minuti e ogni volta che Wi-Fi Aware è attivo.

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

• [C-2-1] DEVE implementare le API di rilevamento basate sulla posizione: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

Implementazioni dei dispositivi:

• DEVE includere il supporto di Wi-Fi Passpoint.

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

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

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

• [C-2-1] L'implementazione delle API WifiManager relative a Passpoint DEVE generare un UnsupportedOperationException.

7.4.2.5. Posizione Wi-Fi (tempo di round trip Wi-Fi - RTT)

Implementazioni dei dispositivi:

• DOVREBBE includere il supporto della località Wi-Fi.

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

• [C-1-1] DEVE implementare le API WifiRttManager come descritto nella documentazione dell'SDK.
• [C-1-2] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.wifi.rtt.
• [C-1-3] DEVE randomizzare l'indirizzo MAC di origine per ogni burst RTT che viene eseguito mentre l'interfaccia Wi-Fi su cui viene eseguito l'RTT non è associata a un punto di accesso.

7.4.3. Bluetooth

Se le implementazioni dei dispositivi supportano il profilo Bluetooth Audio:

• DOVREBBE supportare codec audio avanzati e codec audio Bluetooth (ad es. LDAC).

Se le implementazioni dei dispositivi supportano HFP, A2DP e AVRCP:

• DEVE supportare almeno 5 dispositivi connessi in totale.

Se le implementazioni del dispositivo dichiarano la funzionalità android.hardware.vr.high_performance:

• [C-1-1] DEVE supportare Bluetooth 4.2 e l'estensione della lunghezza dei dati Bluetooth LE.

Android include il supporto per Bluetooth e Bluetooth Low Energy.

Se le implementazioni dei dispositivi includono il supporto di Bluetooth e Bluetooth Low Energy:

• [C-2-1] DEVE dichiarare le funzionalità della piattaforma pertinenti (rispettivamente android.hardware.bluetooth e android.hardware.bluetooth_le) e implementare le API della piattaforma.
• DEVE implementare profili Bluetooth pertinenti come A2DP, AVRCP, OBEX, HFP e così via, a seconda del dispositivo.

Se le implementazioni dei dispositivi includono il supporto di Bluetooth Low Energy:

• [C-3-1] È OBBLIGATORIO dichiarare la funzionalità hardware android.hardware.bluetooth_le.
• [C-3-2] È NECESSARIO attivare le API Bluetooth basate su GATT (Generic Attribute Profile) come descritto nella documentazione dell'SDK e in android.bluetooth.
• [C-3-3] DEVE riportare il valore corretto per BluetoothAdapter.isOffloadedFilteringSupported() per indicare se è implementata la logica di filtro per le classi dell'API ScanFilter.
• [C-3-4] È OBBLIGATORIO indicare il valore corretto per BluetoothAdapter.isMultipleAdvertisementSupported() per indicare se la pubblicità a basso consumo energetico è supportata.
• DOVREBBE supportare lo sgravio della logica di filtro sul chipset Bluetooth durante l'implementazione dell'API ScanFilter.
• DOVREBBE supportare lo sgravio della scansione collettiva sul chipset Bluetooth.

• DEVE supportare più annunci con almeno 4 slot.

• [RP] È FORTEMENTE CONSIGLIATO implementare un timeout per gli indirizzi privati risolvibili (RPA) non superiore a 15 minuti e ruotare l'indirizzo al termine del timeout per proteggere la privacy dell'utente.

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

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

7.4.4. Near Field Communication

Implementazioni dei dispositivi:

• DOVREBBE includere un transceiver e hardware correlato per la tecnologia Near Field Communication (NFC).
• [C-0-1] DEVE implementare le API android.nfc.NdefMessage e android.nfc.NdefRecord anche se non includono il supporto per NFC o dichiarano la funzionalità android.hardware.nfc poiché le classi rappresentano un formato di rappresentazione dei dati indipendente dal protocollo.

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

• [C-1-1] DEVE segnalare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature().
• DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC:
• [C-1-2] DEVE essere in grado di agire come lettore/scrittore NFC Forum (come definito dalla specifica tecnica NFC Forum NFCForum-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Tipi di tag NFC Forum 1, 2, 3, 4, 5 (definiti dal NFC Forum)

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

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

  • ISO 18092
  • LLCP 1.2 (definito dal NFC Forum)
  • SDP 1.0 (definito dal NFC Forum)
  • Protocollo push NDEF
  • SNEP 1.0 (definito dal NFC Forum)
• [C-1-4] DEVE includere il supporto di Android Beam e DOVREBBE attivare Android Beam per impostazione predefinita.
• [C-1-5] DEVE essere in grado di inviare e ricevere utilizzando Android Beam, quando questa funzionalità è attivata o è attivata un'altra modalità P2P NFC proprietaria.
• [C-1-6] DEVE implementare il server SNEP predefinito. I messaggi NDEF validi ricevuti dal server SNEP predefinito DEVONO essere inviati alle applicazioni che utilizzano l'intent android.nfc.ACTION_NDEF_DISCOVERED. La disattivazione di Android Beam nelle impostazioni NON DEVE disattivare l'invio del messaggio NDEF in arrivo.
• [C-1-7] DEVE rispettare l'intent android.settings.NFCSHARING_SETTINGS per mostrare le impostazioni di condivisione NFC.
• [C-1-8] È OBBLIGATORIO implementare il server NPP. I messaggi ricevuti dal server NPP DEVONO essere elaborati nello stesso modo del server SNEP predefinito.
• [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.
• DOVREBBE utilizzare un gesto o una conferma sullo schermo, ad esempio "Tocca per trasmettere", prima di inviare messaggi NDEF P2P in uscita.
• [C-1-11] DEVE supportare il trasferimento della connessione NFC al Bluetooth quando il dispositivo supporta il profilo Bluetooth Object Push.
• [C-1-12] DEVE supportare il trasferimento della connessione al Bluetooth quando si utilizza android.nfc.NfcAdapter.setBeamPushUris, implementando le specifiche "Connection Handover version 1.2" e "Bluetooth Secure Simple Pairing Using NFC version 1.0" del NFC Forum. Una simile implementazione DEVE implementare il servizio LLCP di trasferimento con il nome di servizio "urn:nfc:sn:handover" per lo scambio dei record di richiesta/selezione del trasferimento tramite NFC e DEVE utilizzare il profilo Bluetooth Object Push per il trasferimento effettivo dei dati Bluetooth. Per motivi di compatibilità con i dispositivi Android 4.1, l'implementazione DOVREBBE comunque accettare le richieste GET SNEP per lo scambio della richiesta di trasferimento/seleziona i record tramite NFC. Tuttavia, un'implementazione stessa NON DEVE inviare richieste GET SNEP per eseguire il trasferimento della connessione.
• [C-1-13] DEVE eseguire la ricerca di tutte le tecnologie supportate in modalità di rilevamento NFC.
• DOVREBBE essere in modalità di rilevamento NFC quando il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.
• DOVREBBE essere in grado di leggere il codice a barre e l'URL (se codificato) dei prodotti Thinfilm NFC Barcode.

Tieni presente che i link disponibili pubblicamente non sono disponibili per le specifiche JIS, ISO e NFC Forum citate sopra.

Android include il supporto per la modalità NFC Host Card Emulation (HCE).

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

• [C-2-1] DEVE segnalare la costante della funzionalità android.hardware.nfc.hce.
• [C-2-2] DEVE supportare le API NFC HCE come definite nell'SDK Android.

Se le implementazioni del dispositivo includono un chipset del controller NFC in grado di supportare HCE per NfcF e implementano la funzionalità per applicazioni di terze parti, devono:

• [C-3-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.nfc.hcef.
• [C-3-2] DEVE implementare le API di emulazione di carte NfcF come definite nell'SDK Android.

Se le implementazioni dei dispositivi includono il supporto generale NFC come descritto in questa sezione e supportano le tecnologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF su MIFARE Classic) nel ruolo di lettore/scrittore, devono:

• [C-4-1] DEVE implementare le API Android corrispondenti come documentato dall'SDK Android.
• [C-4-2] DEVE segnalare la funzionalità com.nxp.mifare dal metodo android.content.pm.PackageManager.hasSystemFeature(). Tieni presente che questa non è una funzionalità standard di Android e, pertanto, non viene visualizzata come costante nella classe android.content.pm.PackageManager.

7.4.5. Capacità di rete minima

Implementazioni dei dispositivi:

• [C-0-1] DEVE includere il supporto di una o più forme di reti di dati. Nello specifico, le implementazioni dei dispositivi DEVONO includere il supporto di almeno uno standard di dati in grado di supportare una velocità di almeno 200 Kbit/sec. Alcuni esempi di tecnologie che soddisfano questo requisito sono EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
• DEVE includere anche il supporto di almeno uno standard di dati wireless comune, come 802.11 (Wi-Fi), quando uno standard di rete fisica (come Ethernet) è la connessione dati principale.
• PUO' implementare più di una forma di connettività dei dati.
• [C-0-2] DEVE includere uno stack di rete IPv6 e supportare la comunicazione IPv6 utilizzando le API gestite, come java.net.Socket e java.net.URLConnection, nonché le API native, come le socket AF_INET6.
• [C-0-3] DEVE attivare IPv6 per impostazione predefinita.
• DEVE garantire che la comunicazione IPv6 sia affidabile quanto quella IPv4, ad esempio:
  • [C-0-4] DEVE mantenere la connettività IPv6 in modalità sospensione.
  • [C-0-5] Il limite di velocità NON DEVE causare la perdita della connettività IPv6 sul dispositivo su qualsiasi rete IPv6 conforme che utilizza durate RA di almeno 180 secondi.
• [C-0-6] DEVE fornire alle applicazioni di terze parti una connettività IPv6 diretta alla rete quando è connesso a una rete IPv6, senza alcuna forma di traduzione di indirizzi o porte localmente sul dispositivo. Sia le API gestite come Socket#getLocalAddress o Socket#getLocalPort sia le API NDK come getsockname() o IPV6_PKTINFO DEVONO restituire l'indirizzo IP e la porta effettivamente utilizzati per inviare e ricevere pacchetti sulla rete.

Il livello di supporto IPv6 richiesto dipende dal tipo di rete, come indicato nei seguenti requisiti.

Se le implementazioni dei dispositivi supportano il Wi-Fi:

• [C-1-1] DEVE supportare il funzionamento a doppio stack e solo IPv6 su Wi-Fi.

Se le implementazioni dei dispositivi supportano Ethernet:

• [C-2-1] DEVE supportare il funzionamento dual-stack su Ethernet.

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

• DOVREBBE supportare il funzionamento IPv6 (solo IPv6 e possibilmente a doppio stack) su rete mobile.

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

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

7.4.6. Impostazioni sincronizzazione

Implementazioni dei dispositivi:

• [C-0-1] L'impostazione di sincronizzazione automatica principale DEVE essere attiva per impostazione predefinita in modo che il metodo getMasterSyncAutomatically() restituisca "true".

7.4.7. Risparmio dati

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

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

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

• [C-1-1] DEVE supportare tutte le API della classe ConnectivityManager come descritto nella documentazione dell'SDK
• [C-1-2] DEVE fornire un'interfaccia utente nelle impostazioni che gestisce 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 forniscono la modalità Risparmio dati, devono:

• [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 gestisce l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ma PUÒ implementarlo come no-op.

7.4.8. Secure Element

Se le implementazioni dei dispositivi supportano elementi sicuri compatibili con l'API Open Mobile e li rendono disponibili per le app di terze parti, devono:

• [C-1-1] DEVE elencare i lettori di elementi sicuri disponibili quando viene chiamato il metodo android.se.omapi.SEService.getReaders().

7.5. Fotocamere

Se le implementazioni dei dispositivi includono almeno una videocamera:

• [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità android.hardware.camera.any.
• [C-1-2] DEVE essere possibile per un'applicazione allocare contemporaneamente tre bitmap RGBA_8888 uguali alle dimensioni delle immagini prodotte dal sensore della fotocamera con la risoluzione più alta sul dispositivo, mentre la fotocamera è aperta a scopo di anteprima di base e acquisizione di foto.

7.5.1. Fotocamera posteriore

Una fotocamera posteriore è una fotocamera posizionata sul lato del dispositivo opposto al display, ovvero acquisisce le immagini delle scene sul lato opposto del dispositivo, come una fotocamera tradizionale.

Implementazioni dei dispositivi:

• DOVREBBE includere una fotocamera posteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera posteriore, devono:

• [C-1-1] È OBBLIGATORIO segnalare i flag funzionalità android.hardware.camera e android.hardware.camera.any.
• [C-1-2] DEVE avere una risoluzione di almeno 2 megapixel.
• DEVE avere l'autofocus hardware o l'autofocus software implementato nel driver della fotocamera (trasparente al software dell'applicazione).
• POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
• PUO' includere un flash.

Se la fotocamera include un flash:

• [C-2-1] la spia del flash NON DEVE essere accesa quando è stata registrata un'istanza di android.hardware.Camera.PreviewCallback su una superficie di anteprima della fotocamera, a meno che l'applicazione non abbia attivato esplicitamente il flash attivando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON di un oggetto Camera.Parameters. Tieni presente che questo vincolo non si applica all'applicazione della fotocamera di sistema integrata del dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

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

Implementazioni dei dispositivi:

• PUO' includere una fotocamera anteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera anteriore, devono:

• [C-1-1] È OBBLIGATORIO segnalare i flag funzionalità android.hardware.camera.any e android.hardware.camera.front.
• [C-1-2] DEVE avere una risoluzione di almeno VGA (640 x 480 pixel).
• [C-1-3] NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Camera e NON DEVE configurare l'API in modo da trattare una fotocamera anteriore come fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
• [C-1-4] L'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto all'orientamento specificato dall'applicazione quando l'applicazione corrente ha richiesto esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation(). Al contrario, l'anteprima DEVE essere speculare rispetto all'asse orizzontale predefinito del dispositivo quando l'applicazione corrente non richiede esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NON DEVE rispecchiare gli stream di video o immagini acquisiti finali restituiti ai callback dell'applicazione o sottoposti a commit nello spazio di archiviazione multimediale.
• [C-1-6] L'immagine visualizzata dalla visualizzazione post DEVE essere speculare rispetto a quella dello stream di immagini dell'anteprima della fotocamera.
• PUO' includere funzionalità (come messa a fuoco automatica, flash e così via) disponibili per le fotocamere posteriori come descritto nella sezione 7.5.1.

Se le implementazioni dei dispositivi possono essere ruotate dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente):

• [C-2-1] L'anteprima della fotocamera DEVE essere ribaltata orizzontalmente rispetto all'orientamento corrente del dispositivo.

7.5.3. Videocamera esterna

Implementazioni dei dispositivi:

• POTREBBE includere il supporto di una videocamera esterna non necessariamente sempre connessa.

Se le implementazioni dei dispositivi includono il supporto di una videocamera esterna:

• [C-1-1] È OBBLIGATORIO dichiarare i flag funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any.
• [C-1-2] DEVE supportare la classe video USB (UVC 1.0 o versioni successive) se la videocamera esterna si connette tramite la porta host USB.
• [C-1-3] DEVE superare i test CTS della videocamera con una videocamera esterna fisica collegata. I dettagli dei test CTS della videocamera sono disponibili all'indirizzo source.android.com.
• DOVREBBE supportare compressioni video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ad es. stream di immagini non compressi o compressi in modo indipendente).
• POTREBBE supportare più videocamere.
• POTREBBE supportare la codifica video basata sulla fotocamera.

Se la codifica video basata sulla videocamera è supportata:

• [C-2-1] È OBBLIGATORIO che l'implementazione del dispositivo sia accessibile a uno stream non codificato / MJPEG simultaneo (risoluzione QVGA o superiore).

7.5.4. Comportamento dell'API Camera

Android include due pacchetti API per accedere alla fotocamera. La più recente API android.hardware.camera2 espone all'app il controllo della fotocamera a livello inferiore, inclusi flussi di scatti/streaming efficienti senza copia e controlli per fotogramma di esposizione, guadagno, guadagni del bilanciamento del bianco, conversione del colore, riduzione del rumore, nitidezza e altro ancora.

Il pacchetto API precedente,android.hardware.Camera, è contrassegnato come deprecato in Android 5.0, ma dovrebbe essere ancora disponibile per le app. Le implementazioni dei dispositivi Android DEVONO garantire il supporto continuo dell'API come descritto in questa sezione e nell'SDK Android.

Tutte le funzionalità comuni tra la classe deprecata android.hardware.Camera e il pacchetto più recente android.hardware.camera2 DEVONO avere prestazioni e qualità equivalenti in entrambe le API. Ad esempio, con impostazioni equivalenti, la velocità e la precisione dell'autofocus devono essere identiche e la qualità delle immagini acquisite deve essere la stessa. Le funzionalità che dipendono dalla semantica diversa delle due API non devono necessariamente avere la stessa velocità o qualità, ma DEVONO corrispondere il più possibile.

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

• [C-0-1] È OBBLIGATORIO utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione quando un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] DEVE essere inoltre nel formato di codifica NV21 quando un'applicazione registra un'istanza android.hardware.Camera.PreviewCallback e il sistema chiama il metodo onPreviewFrame() e il formato di anteprima è YCbCr_420_SP, i dati in byte[] passati a onPreviewFrame(). In altre parole, NV21 DEVE essere il valore predefinito.
• [C-0-3] DEVE supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia per le fotocamere anteriori che posteriori per android.hardware.Camera. Il codificatore video hardware e la videocamera possono utilizzare qualsiasi formato di pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione in YV12.
• [C-0-4] DEVE supportare i formati android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG come output tramite l'API android.media.ImageReader per i dispositivi android.hardware.camera2 che pubblicizzano la funzionalità REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities.
• [C-0-5] DEVE comunque implementare l'API Camera completa inclusa nella documentazione dell'SDK Android, indipendentemente dal fatto che il dispositivo includa l'autofocus hardware o altre funzionalità. Ad esempio, le fotocamere prive di messa a fuoco automatica DEVONO comunque chiamare le eventuali istanze android.hardware.Camera.AutoFocusCallback registrate (anche se questo non ha alcuna rilevanza per una fotocamera senza messa a fuoco automatica). Tieni presente che questo vale per le fotocamere anteriori; ad esempio, anche se la maggior parte delle fotocamere anteriori non supporta l'autofocus, i callback dell'API devono comunque essere "falsi" come descritto.
• [C-0-6] DEVE riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters. Al contrario, le implementazioni dei dispositivi NON DEVONO rispettare o riconoscere costanti di stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. In altre parole, le implementazioni dei dispositivi DEVONO supportare tutti i parametri Camera standard, se l'hardware lo consente, e NON DEVONO supportare i tipi di parametri Camera personalizzati. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini utilizzando tecniche di imaging HDR (High Dynamic Range) DEVONO supportare il parametro della fotocamera Camera.SCENE_MODE_HDR.
• [C-0-7] DEVE segnalare il livello di supporto appropriato con la proprietà android.info.supportedHardwareLevel come descritto nell'SDK Android e segnalare gli flag delle funzionalità del framework appropriati.
• [C-0-8] DEVE anche dichiarare le singole funzionalità della videocamera di android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag di funzionalità appropriati; DEVE definire il flag di funzionalità se uno dei dispositivi videocamera collegati supporta la funzionalità.
• [C-0-9] DEVE trasmettere l'intent Camera.ACTION_NEW_PICTURE ogni volta che la fotocamera scatta una nuova foto e la voce della foto è stata aggiunta al media store.
• [C-0-10] DEVE trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e la voce della foto è stata aggiunta al media store.
• [C-SR] È FORTEMENTE CONSIGLIATO supportare un dispositivo di fotocamera logica che elenca la funzionalità CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA per i dispositivi con più fotocamere rivolte nella stessa direzione, costituite da ogni fotocamera fisica rivolta in quella direzione, a condizione che il tipo di fotocamera fisica sia supportato dal framework e che CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL per le fotocamere fisiche sia LIMITED, FULL o LEVEL_3.

7.5.5. Orientamento della fotocamera

Se le implementazioni del dispositivo dispongono di una fotocamera anteriore o posteriore, queste fotocamere:

• [C-1-1] DEVE essere orientata in modo che la dimensione più lunga della fotocamera sia allineata alla dimensione più lunga dello schermo. In altre parole, quando il dispositivo è tenuto in orizzontale, le fotocamere DEVONO acquisire le immagini in orizzontale. Questo vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica ai dispositivi con orientamento principale orizzontale e verticale.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

Implementazioni dei dispositivi:

• [C-0-1] DEVE includere un gestore dei download che le applicazioni POSSONO utilizzare per scaricare file di dati e DEVE essere in grado di scaricare singoli file di dimensioni di almeno 100 MB nella posizione predefinita "cache".

7.6.2. Spazio di archiviazione condiviso dell'applicazione

Implementazioni dei dispositivi:

• [C-0-1] DEVE offrire spazio di archiviazione da condividere con le applicazioni, spesso indicato anche come "spazio di archiviazione esterno condiviso", "spazio di archiviazione condiviso per le applicazioni" o dal percorso Linux "/sdcard" su cui è montato.
• [C-0-2] DEVE essere configurato con lo spazio di archiviazione condiviso montato per impostazione predefinita, in altre parole "out of the box", indipendentemente dal fatto che lo spazio di archiviazione sia implementato su un componente di archiviazione interno o su un supporto di archiviazione rimovibile (ad es. slot per schede Secure Digital).
• [C-0-3] È NECESSARIO montare lo spazio di archiviazione condiviso dell'applicazione direttamente sul percorso Linux sdcard o includere un link simbolico Linux da sdcard al punto di montaggio effettivo.
• [C-0-4] È OBBLIGATORIO applicare l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE a questo spazio di archiviazione condiviso, come descritto nell'SDK. In caso contrario, lo spazio di archiviazione condiviso DEVE essere scrivibile da qualsiasi applicazione che ottenga l'autorizzazione.

Le implementazioni dei dispositivi POSSONO soddisfare i requisiti sopra indicati utilizzando una delle seguenti opzioni:

• Spazio di archiviazione rimovibile accessibile all'utente, ad esempio uno slot per schede Secure Digital (SD).
• Una parte dello spazio di archiviazione interno (non rimovibile) implementata nell'Android Open Source Project (AOSP).

Se le implementazioni dei dispositivi utilizzano lo spazio di archiviazione rimovibile per soddisfare i requisiti sopra indicati:

• [C-1-1] DEVE implementare un'interfaccia utente popup o di tipo toast che avvisi l'utente quando non è presente alcun supporto di archiviazione inserito nello slot.
• [C-1-2] DEVE includere un supporto di archiviazione con formato FAT (ad es. una scheda SD) o indicare sulla confezione e su altro materiale disponibile al momento dell'acquisto che il supporto di archiviazione deve essere acquistato separatamente.

Se le implementazioni dei dispositivi utilizzano una parte dello spazio di archiviazione non rimovibile per soddisfare i requisiti sopra indicati:

• DOVREBBE utilizzare l'implementazione AOSP dello spazio di archiviazione condiviso dell'applicazione interna.
• POTREBBE condividere lo spazio di archiviazione con i dati privati dell'applicazione.

Se le implementazioni dei dispositivi includono più percorsi di archiviazione condivisi (ad esempio uno slot per schede SD e una memoria interna condivisa), devono:

• [C-2-1] DEVE consentire solo ad applicazioni Android predefinite e privilegiate con l'autorizzazione WRITE_EXTERNAL_STORAGE di scrivere nell'unità di archiviazione esterna secondaria, tranne quando si scrive nelle directory specifiche del pacchetto o all'interno del URI restituito dall'attivazione dell'intent ACTION_OPEN_DOCUMENT_TREE.

Se le implementazioni dei dispositivi dispongono di una porta USB con supporto della modalità periferica USB, devono:

• [C-3-1] DEVE fornire un meccanismo per accedere ai dati nello spazio di archiviazione condiviso dell'applicazione da un computer host.
• DOVREBBE esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione multimediale di Android e android.provider.MediaStore.
• PUO' utilizzare la memoria di massa USB, ma DEVE utilizzare il protocollo Media Transfer per soddisfare questo requisito.

Se le implementazioni dei dispositivi dispongono di una porta USB con modalità periferica USB e supportano il protocollo Media Transfer, devono:

• DEVE essere compatibile con l'host MTP Android di riferimento, Android File Transfer.
• DOVREBBE segnalare una classe di dispositivo USB pari a 0x00.
• DOVREBBE riportare il nome dell'interfaccia USB "MTP".

7.6.3. Spazio di archiviazione utilizzabile

Se il dispositivo è di natura mobile, a differenza della televisione, le implementazioni del dispositivo sono:

• [RP] È FORTEMENTE CONSIGLIATO di implementare lo spazio di archiviazione adottabile in una posizione stabile a lungo termine, poiché la disconnessione accidentale può causare la perdita/corruzione dei dati.

Se la porta del dispositivo di archiviazione rimovibile si trova in una posizione stabile a lungo termine, ad esempio all'interno del vano batteria o di un'altra copertura protettiva, le implementazioni del dispositivo sono:

• [SR] È MOLTO CONSIGLIATO implementare lo spazio di archiviazione adottabile.

7.7. USB

Se le implementazioni dei dispositivi dispongono di una porta USB:

• DEVE supportare la modalità periferica USB e DEVE supportare la modalità host USB.

7.7.1. Modalità periferica USB

Se le implementazioni del dispositivo includono una porta USB che supporta la modalità periferica:

• [C-1-1] La porta DEVE essere connettibile a un host USB con una porta USB standard di tipo A o C.
• [C-1-2] DEVE riportare il valore corretto di iSerialNumber nel descrittore del dispositivo standard USB tramite android.os.Build.SERIAL.
• [C-1-3] DEVE rilevare i caricabatterie da 1,5 A e 3 A in base allo standard del resistore di tipo C e DEVE rilevare le modifiche nell'annuncio se supportano USB di tipo C.
• [SR] La porta DEVE utilizzare il fattore di forma USB micro-B, micro-AB o Type-C. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
• [SR] La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o attivare la rotazione dello schermo software per tutte le app (inclusa la schermata Home), in modo che il display venga visualizzato correttamente quando il dispositivo è orientato con la porta in basso. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
• [SR] DOVREBBE implementare il supporto per assorbire una corrente di 1,5 A durante il traffico e il chirp HS come specificato nella specifica di ricarica della batteria USB, revisione 1.2. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
• [SR] È FORTEMENTE CONSIGLIATO di non supportare metodi di ricarica proprietari che modificano la tensione Vbus oltre i livelli predefiniti o alterano i ruoli di sink/sorgente, in quanto potrebbero verificarsi problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard di Power Delivery USB. Sebbene questa opzione sia indicata come "FORTEMENTE CONSIGLIATA", nelle versioni future di Android potremmo RICHIEDERE a tutti i dispositivi Type-C di supportare la piena interoperabilità con i caricabatterie Type-C standard.
• [SR] È FORTEMENTE CONSIGLIATO supportare Power Delivery per lo scambio di ruoli di alimentazione e dati quando supportano USB Type-C e la modalità host USB.
• DOVREBBE supportare Power Delivery per la ricarica ad alta tensione e le modalità alternative come la visualizzazione.
• DEVE implementare l'API e la specifica Android Open Accessory (AOA) come descritto nella documentazione dell'SDK Android.

Se le implementazioni dei dispositivi includono una porta USB e implementano la specifica AOA, devono:

• [C-2-1] DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.accessory.
• [C-2-2] La classe di archiviazione di massa USB DEVE includere la stringa "android" alla fine della stringa iInterface della descrizione dell'interfaccia dell'archiviazione di massa USB

7.7.2. Modalità host USB

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

• [C-1-1] DEVE implementare l'API host USB Android come documentato nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host.
• [C-1-2] DEVONO implementare il supporto per il collegamento di periferiche USB standard, in altre parole DEVONO:
  • Avere una porta di tipo C sul dispositivo o essere dotato di cavi che adattano una porta proprietaria sul dispositivo a una porta USB Type-C standard (dispositivo USB Type-C).
  • Avere un connettore di tipo A sul dispositivo o essere fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB di tipo A standard.
  • Avere una porta micro-AB sul dispositivo, che DOVREBBE essere fornita con un cavo adattabile a una porta di tipo A standard.
• [C-1-3] NON deve essere fornito con un adattatore che converte da porte USB di tipo A o micro-AB a una porta di tipo C (presa).
• [SR] È MOLTO CONSIGLIATO implementare la classe audio USB come descritto nella documentazione dell'SDK Android.
• DEVE supportare la ricarica del dispositivo periferico USB collegato in modalità host; deve pubblicizzare una corrente di alimentazione di almeno 1,5 A come specificato nella sezione Parametri di terminazione della USB Type-C Cable and Connector Specification Revision 1.2 per i connettori USB Type-C o utilizzare l'intervallo di corrente di uscita della porta di ricarica a valle(CDP) come specificato nelle USB Battery Charging specifications, revision 1.2 per i connettori Micro-AB.
• DEVE implementare e supportare gli standard USB Type-C.

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

• [C-2-1] DEVE supportare la classe HID USB.
• [C-2-2] DEVE supportare il rilevamento e la mappatura dei seguenti campi di dati HID specificati nelle tabelle di utilizzo HID USB e nella richiesta di utilizzo dei comandi vocali alle costanti KeyEvent come indicato di seguito:
  • Pagina di utilizzo (0xC) ID utilizzo (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Pagina di utilizzo (0xC) ID utilizzo (0x0E9): KEYCODE_VOLUME_UP
  • Pagina di utilizzo (0xC) ID utilizzo (0x0EA): KEYCODE_VOLUME_DOWN
  • Pagina di utilizzo (0xC) ID utilizzo (0x0CF): KEYCODE_VOICE_ASSIST

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e Storage Access Framework (SAF), devono:

• [C-3-1] DEVE riconoscere tutti i dispositivi MTP (Media Transfer Protocol) connessi da remoto e rendere accessibili i relativi contenuti tramite gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e USB Type-C:

• [C-4-1] DEVE implementare la funzionalità della porta con doppio ruolo come definito dalla specifica USB Type-C (sezione 4.5.1.3.3).
• [SR] È MOLTO CONSIGLIATO supportare DisplayPort, DOVREBBE supportare le velocità di trasferimento dati USB SuperSpeed ed È MOLTO CONSIGLIATO supportare Power Delivery per lo scambio di ruoli di alimentazione e dati.
• [RP] È FORTEMENTE CONSIGLIATO di NON supportare la modalità accessorio dell'adattatore audio come descritto nell'appendice A della Revisione 1.2 della specifica del cavo e del connettore USB Type-C.
• DOVREBBE implementare il modello Try.* più appropriato per il fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DOVREBBE implementare il modello Try.SNK.

7.8. Audio

7.8.1. Microfono

Se le implementazioni del dispositivo includono un microfono:

• [C-1-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.microphone.
• [C-1-2] DEVE soddisfare i requisiti di registrazione audio descritti nella sezione 5.4.
• [C-1-3] DEVE soddisfare i requisiti di latenza audio descritti nella sezione 5.6.
• [SR] È MOLTO CONSIGLIATO supportare la registrazione in modalità quasi ultrasuoni come descritto nella sezione 7.8.3.

Se le implementazioni del dispositivo omettono un microfono:

• [C-2-1] NON DEVE segnalare la costante della funzionalità android.hardware.microphone.
• [C-2-2] È OBBLIGATORIO implementare l'API di registrazione audio almeno come no-op, come indicato nella sezione 7.

7.8.2. Uscita audio

Se le implementazioni del dispositivo includono uno speaker o una porta di uscita audio/multimediale per una periferica di uscita audio, ad esempio un jack audio da 3,5 mm a 4 conduttori o una porta in modalità host USB che utilizza la classe audio USB, devono:

• [C-1-1] È OBBLIGATORIO segnalare la costante della funzionalità android.hardware.audio.output.
• [C-1-2] DEVE soddisfare i requisiti di riproduzione audio descritti nella sezione 5.5.
• [C-1-3] DEVE soddisfare i requisiti di latenza audio descritti nella sezione 5.6.
• [SR] È MOLTO CONSIGLIATO supportare la riproduzione a frequenza quasi ultrasonica come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono uno speaker o una porta di uscita audio, devono:

• [C-2-1] NON DEVE segnalare la funzionalità android.hardware.audio.output.
• [C-2-2] È NECESSARIO implementare le API relative all'output audio almeno come no-op.

Ai fini di questa sezione, una "porta di uscita" è un'interfaccia fisica, ad esempio un jack audio da 3,5 mm, HDMI o una porta in modalità host USB con classe audio USB. Il supporto dell'uscita audio tramite protocolli basati su radio, come Bluetooth, Wi-Fi o rete mobile, non è considerato come "porta di uscita".

7.8.2.1. Porte audio analogiche

Per essere compatibili con le cuffie e altri accessori audio che utilizzano il jack audio da 3,5 mm nell'ecosistema Android, se le implementazioni del dispositivo includono una o più porte audio analogiche, devono:

• [C-SR] È FORTEMENTE CONSIGLIATO includere almeno una delle porte audio con un jack audio da 3,5 mm a 4 conduttori.

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

• [C-1-1] DEVE supportare la riproduzione audio su cuffie stereo e cuffie stereo con microfono.
• [C-1-2] DEVE supportare i connettori audio TRRS con l'ordine dei pin CTIA.
• [C-1-3] DEVE supportare il rilevamento e la mappatura ai codici a tasti per i seguenti tre intervalli di impedenza equivalente tra i conduttori del microfono e della terra sul connettore audio:
  • Massimo 70 ohm: KEYCODE_HEADSETHOOK
  • 210-290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] DEVE attivare ACTION_HEADSET_PLUG quando viene inserito il connettore, ma solo dopo che tutti i contatti del connettore toccano i relativi segmenti sul jack.
• [C-1-5] DEVE essere in grado di alimentare almeno 150 mV ± 10% di tensione di uscita su un'impedenza dello speaker di 32 ohm.
• [C-1-6] DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V e 2,9 V.
• [C-1-7] DEVE rilevare e mappare al codice a chiave il seguente intervallo di impedenza equivalente tra i conduttori del microfono e della messa a terra sul connettore audio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR] È FORTEMENTE CONSIGLIATO supportare i connettori audio con l'ordine di pinout OMTP.
• [C-SR] È MOLTO CONSIGLIATO supportare la registrazione audio da cuffie stereo con microfono.

Se le implementazioni del dispositivo hanno un jack audio da 3, 5 mm a 4 conduttori e supportano un microfono e trasmettono android.intent.action.HEADSET_PLUG con il valore extra del microfono impostato su 1, devono:

• [C-2-1] DEVE supportare il rilevamento del microfono sull'accessorio audio collegato.

7.8.3. Near-Ultrasound

L'audio quasi a ultrasuoni è la banda da 18,5 kHz a 20 kHz.

Implementazioni dei dispositivi:

• DEVE segnalare correttamente il supporto della funzionalità audio a ultrasuoni vicini tramite l'API AudioManager.getProperty come segue:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND è "true", le sorgenti audio VOICE_RECOGNITION e UNPROCESSED DEVONO soddisfare i seguenti requisiti:

• [C-1-1] La risposta di potenza media del microfono nella banda da 18,5 kHz a 20 kHz NON DEVE essere superiore a 15 dB al di sotto della risposta a 2 kHz.
• [C-1-2] Il rapporto segnale/rumore non pesato del microfono in un intervallo di frequenza compreso tra 18,5 kHz e 20 kHz per un tono a 19 kHz a -26 dBFS NON DEVE essere inferiore a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND è "true":

• [C-2-1] La risposta media dell'altoparlante nella gamma di frequenze 18,5 kHz - 20 kHz NON DEVE essere inferiore a 40 dB rispetto alla risposta a 2 kHz.

7.9. Realtà virtuale

Android include API e funzionalità per creare applicazioni di "Realtà virtuale" (VR), incluse esperienze VR mobile di alta qualità. Le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

7.9.1. Modalità realtà virtuale

Android include il supporto della modalità VR, una funzionalità che gestisce il rendering stereoscopico delle notifiche e disattiva i componenti dell'interfaccia utente di sistema monoculare quando un'applicazione VR ha l'attenzione dell'utente.

7.9.2. Modalità Realtà virtuale - Prestazioni elevate

Se le implementazioni dei dispositivi supportano la modalità VR:

• [C-1-1] DEVE avere almeno 2 core fisici.
• [C-1-2] È OBBLIGATORIO dichiarare la funzionalità android.hardware.vr.high_performance.
• [C-1-3] DEVE supportare la modalità di rendimento sostenuto.
• [C-1-4] DEVE supportare OpenGL ES 3.2.
• [C-1-5] DEVE supportare android.hardware.vulkan.level 0.
• DEVE supportare android.hardware.vulkan.level 1 o versioni successive.
• [C-1-6] È OBBLIGATORIO implementare EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace ed esporre le estensioni nell'elenco delle estensioni EGL disponibili.
• [C-1-8] DEVE implementare GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
• [C-SR] È FORTEMENTE CONSIGLIATO di implementare GL_EXT_external_buffer, GL_EXT_EGL_image_array ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
• [C-SR] È MOLTO CONSIGLIATO supportare Vulkan 1.1.
• [C-SR] È FORTEMENTE CONSIGLIATO implementare VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image e esporli nell'elenco delle estensioni Vulkan disponibili.
• [C-SR] È FORTEMENTE CONSIGLIATO esporre almeno una famiglia di code Vulkan in cui flags contenga sia VK_QUEUE_GRAPHICS_BIT che VK_QUEUE_COMPUTE_BIT e queueCount sia almeno 2.
• [C-1-7] La GPU e il display DEVONO essere in grado di sincronizzare l'accesso al buffer anteriore condiviso in modo che il rendering con l'occhio alternato dei contenuti VR a 60 fps con due contesti di rendering venga visualizzato senza artefatti di tearing visibili.
• [C-1-9] È OBBLIGATORIO implementare il supporto per i flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT come descritto nell'NDK.
• [C-1-10] DEVE implementare il supporto per i AHardwareBuffer con qualsiasi combinazione di flag di utilizzo AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT per almeno i seguenti formati: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare l'allocazione di AHardwareBuffer con più livelli e flag e formati specificati in C-1-10.
• [C-1-11] DEVE supportare la decodifica H.264 di almeno 3840 x 2160 a 30 fps, compressa a una media di 40 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps - 10 Mbps o 2 istanze di 1920 x 1080 a 60 fps - 20 Mbps).
• [C-1-12] DEVE supportare HEVC e VP9, DEVE essere in grado di decodificare almeno 1920 x 1080 a 30 fps compressi a una media di 10 Mbps e DOVREBBE essere in grado di decodificare 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps-5 Mbps).
• [C-1-13] DEVE supportare l'API HardwarePropertiesManager.getDeviceTemperatures e restituire valori accurati per la temperatura cutanea.
• [C-1-14] DEVE avere uno schermo integrato e la sua risoluzione DEVE essere di almeno 1920 x 1080.
• [C-SR] È FORTEMENTE CONSIGLIATO avere una risoluzione del display di almeno 2560 x 1440.
• [C-1-15] Il display DEVE aggiornarsi ad almeno 60 Hz in modalità VR.
• [C-1-17] Il display DEVE supportare una modalità a bassa persistenza con una persistenza massima di 5 millisecondi, dove persistenza viene definita come il periodo di tempo per cui un pixel emette luce.
• [C-1-18] DEVE supportare Bluetooth 4.2 e l'estensione della lunghezza dei dati Bluetooth LE sezione 7.4.3.
• [C-1-19] DEVE supportare e segnalare correttamente il tipo di canale diretto per tutti i seguenti tipi di sensori predefiniti:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] È MOLTO CONSIGLIATO supportare il tipo di canale diretto TYPE_HARDWARE_BUFFER per tutti i tipi di canale diretto elencati sopra.
• [C-1-21] DEVE soddisfare i requisiti relativi a giroscopio, accelerometro e magnetometro per android.hardware.hifi_sensors, come specificato nella sezione 7.3.9.
• [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare la funzionalità android.hardware.sensor.hifi_sensors.
• [C-1-22] DEVE avere una latenza end-to-end del movimento al fotone non superiore a 28 millisecondi.
• [C-SR] È FORTEMENTE CONSIGLIATO di avere una latenza end-to-end del movimento al fotone non superiore a 20 millisecondi.
• [C-1-23] DEVE avere un rapporto del primo fotogramma, ovvero il rapporto tra la luminosità dei pixel del primo fotogramma dopo una transizione dal nero al bianco e la luminosità dei pixel bianchi in stato stazionario, di almeno l'85%.
• [C-SR] È FORTEMENTE CONSIGLIATO avere un rapporto del primo frame di almeno il 90%.
• PUO' fornire un core esclusivo all'applicazione in primo piano e PUO' supportare l'API Process.getExclusiveCores per restituire i numeri dei core della CPU esclusivi dell'applicazione in primo piano principale.

Se il core esclusivo è supportato, il core:

• [C-2-1] NON DEVE consentire l'esecuzione di altri processi nello spazio utente (tranne i driver di dispositivo utilizzati dall'applicazione), ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

8. Prestazioni e potenza

Alcuni criteri minimi di prestazioni e potenza sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di riferimento che gli sviluppatori dovrebbero fare durante lo sviluppo di un'app.

8.1. Coerenza dell'esperienza utente

È possibile fornire all'utente finale un'interfaccia utente fluida se sono presenti determinati requisiti minimi per garantire una frequenza frame e tempi di risposta coerenti per applicazioni e giochi. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POTREBBERO avere requisiti misurabili per la latenza dell'interfaccia utente e il passaggio da un'attività all'altra, come descritto nella sezione 2.

8.2. Prestazioni di accesso all'I/O di file

Fornire una linea di base comune per un rendimento coerente dell'accesso ai file nell'archiviazione dei dati privati dell'applicazione (partizione /data) consente agli sviluppatori di app di impostare un'aspettativa adeguata che possa essere utile per il design del software. Le implementazioni dei dispositivi, a seconda del tipo, POTREBBERO avere determinati requisiti descritti nella sezione 2 per le seguenti operazioni di lettura e scrittura:

• Prestazioni di scrittura sequenziale. Misurato scrivendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
• Rendimento delle scritture casuali. Misurato scrivendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.
• Rendimento di lettura sequenziale. Misurato leggendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
• Rendimento delle letture casuali. Misurato leggendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.

8.3. Modalità di risparmio energetico

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

• [C-1-1] NON DEVE discostarsi dall'implementazione di AOSP per gli algoritmi di attivazione, manutenzione e risveglio e per l'utilizzo delle impostazioni di sistema globali delle modalità di risparmio energetico App Standby e Sospensione.
• [C-1-2] NON DEVE discostarsi dall'implementazione di AOSP per l'utilizzo delle impostazioni globali per gestire il throttling di job, sveglie e rete per le app in ogni bucket per la modalità in attesa delle app.
• [C-1-3] NON DEVE discostarsi dall'implementazione AOSP per il numero di bucket di app in standby utilizzati per la modalità App in standby.
• [C-1-4] È OBBLIGATORIO implementare i bucket di app in standby e la modalità Sospensione come descritto in Gestione dell'alimentazione.
• [C-1-5] DEVE restituire true per PowerManager.isPowerSaveMode() quando il dispositivo è in modalità di risparmio energetico.
• [C-SR] È FORTEMENTE CONSIGLIATO fornire all'utente la possibilità di attivare e disattivare la funzionalità di risparmio energetico.
• [C-SR] È FORTEMENTE CONSIGLIATO fornire all'utente la possibilità di visualizzare tutte le app esenti dalle modalità di risparmio energetico App Standby e Sospensione.

Oltre alle modalità di risparmio energetico, le implementazioni dei dispositivi Android POSSONO implementare uno o tutti e quattro gli stati di alimentazione in sospensione come definiti dall'Advanced Configuration and Power Interface (ACPI).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S4 come definiti dall'ACPI, devono:

• [C-1-1] DEVE entrare in questo stato solo dopo che l'utente ha eseguito un'azione esplicita per mettere il dispositivo in uno stato non attivo (ad es. chiudendo un coperchio che fa parte fisicamente del dispositivo o spegnendo un veicolo o una TV) e prima che l'utente riattivi il dispositivo (ad es. aprendo il coperchio o riaccendendo il veicolo o la TV).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S3 come definiti dall'ACPI, devono:

• [C-2-1] DEVE soddisfare C-1-1 sopra indicato OPPURE DEVE entrare nello stato S3 solo quando le applicazioni di terze parti non richiedono le risorse di sistema (ad es. lo schermo, la CPU).

  Al contrario, DEVE uscire dallo stato S3 quando le applicazioni di terze parti hanno bisogno delle risorse di sistema, come descritto in questo SDK.

  Ad esempio, mentre le applicazioni di terze parti richiedono di mantenere lo schermo acceso tramite FLAG_KEEP_SCREEN_ON o mantenere in esecuzione la CPU tramite PARTIAL_WAKE_LOCK, il dispositivo NON DEVE entrare nello stato S3, a meno che, come descritto in C-1-1, l'utente non abbia intrapreso un'azione esplicita per mettere il dispositivo in uno stato inattivo. Al contrario, quando viene attivata un'attività implementata da app di terze parti tramite JobScheduler o quando Firebase Cloud Messaging viene inviato ad app di terze parti, il dispositivo DEVE uscire dallo stato S3, a meno che l'utente non lo abbia messo in uno stato inattivo. Questi non sono esempi esaustivi e AOSP implementa indicatori di risveglio estesi che attivano un risveglio da questo stato.

8.4. Contabilità del consumo energetico

Una contabilità e una generazione di report più accurati sul consumo di energia forniscono allo sviluppatore di app gli incentivi e gli strumenti per ottimizzare il pattern di utilizzo dell'energia dell'applicazione.

Implementazioni dei dispositivi:

• [SR] È FORTEMENTE CONSIGLIATO fornire un profilo di alimentazione per componente che definisca il valore di consumo corrente per ciascun componente hardware e il consumo approssimativo della batteria causato dai componenti nel tempo, come documentato nel sito del progetto open source Android.
• [SR] È FORTEMENTE CONSIGLIATO segnalare tutti i valori di consumo di energia in milliampere ora (mAh).
• [SR] È FORTEMENTE CONSIGLIATO segnalare il consumo di energia della CPU per l'UID di ogni processo. Android Open Source Project soddisfa il requisito tramite l'implementazione del modulo del kernel uid_cputime.
• [SR] VIVAMENTE CONSIGLIATO di rendere disponibile questo utilizzo di energia tramite il comando shell adb shell dumpsys batterystats per lo sviluppatore dell'app.
• DEVE essere attribuito al componente hardware stesso se non è possibile attribuire il consumo di energia del componente hardware a un'applicazione.

8.5. Prestazioni costanti

Le prestazioni possono variare notevolmente per le app ad alte prestazioni a lungo termine, a causa delle altre app in esecuzione in background o del throttling della CPU a causa dei limiti di temperatura. Android include interfacce programmatiche in modo che, se il dispositivo è compatibile, l'applicazione in primo piano più importante possa richiedere al sistema di ottimizzare l'allocazione delle risorse per gestire queste fluttuazioni.

Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare con precisione il supporto della modalità di rendimento costante tramite il metodo dell'API PowerManager.isSustainedPerformanceModeSupported().

• DOVREBBE supportare la modalità Rendimento prolungato.

Se le implementazioni dei dispositivi segnalano il supporto della modalità di prestazioni sostenute:

• [C-1-1] DEVE fornire all'applicazione in primo piano un livello di prestazioni costante per almeno 30 minuti, quando l'app lo richiede.
• [C-1-2] DEVE rispettare l'API Window.setSustainedPerformanceMode() e altre API correlate.

Se le implementazioni dei dispositivi includono due o più core della CPU:

• DEVE fornire almeno un core esclusivo che può essere riservato dall'applicazione in primo piano principale.

Se le implementazioni del dispositivo supportano la prenotazione di un core esclusivo per l'applicazione in primo piano principale, devono:

• [C-2-1] DEVE segnalare tramite il metodo dell'API Process.getExclusiveCores() i numeri ID dei core esclusivi che possono essere riservati dall'applicazione in primo piano principale.
• [C-2-2] NON DEVE consentire l'esecuzione di processi nello spazio utente, ad eccezione dei driver di dispositivo utilizzati dall'applicazione, sui core esclusivi, ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

Se le implementazioni dei dispositivi non supportano un core esclusivo:

• [C-3-1] DEVE restituire un elenco vuoto tramite il metodo dell'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 Sicurezza e autorizzazioni nelle API della documentazione per sviluppatori Android.

• [C-0-2] DEVE supportare l'installazione di applicazioni con firma autografa senza richiedere autorizzazioni/certificati aggiuntivi da parte di terze parti/autorità. In particolare, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle sottosezioni seguenti.

9.1. Autorizzazioni

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android. Nello specifico, DEVONO applicare ogni autorizzazione definita come descritto nella documentazione dell'SDK; nessuna autorizzazione può essere omessa, alterata o ignorata.

• PUO' aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe di ID autorizzazione non siano nello spazio dei nomi android.\*.

• [C-0-2] Le autorizzazioni con un valore protectionLevel pari a PROTECTION_FLAG_PRIVILEGED DEVONO essere concesse solo alle app preinstallate nei percorsi privilegiati dell'immagine di sistema e all'interno del sottoinsieme di autorizzazioni esplicitamente consentite per ogni app. L'implementazione AOSP soddisfa questo requisito leggendo e rispettando le autorizzazioni consentite per ogni app dai file nel percorso etc/permissions/ e utilizzando il percorso system/priv-app come percorso privilegiato.

Le autorizzazioni con un livello di protezione pericoloso sono autorizzazioni di runtime. Le applicazioni con targetSdkVersion > 22 le richiedono in fase di esecuzione.

Implementazioni dei dispositivi:

• [C-0-3] DEVE mostrare un'interfaccia dedicata che consenta all'utente di decidere se concedere le autorizzazioni di runtime richieste e fornire un'interfaccia per la gestione delle autorizzazioni di runtime.
• [C-0-4] DEVE avere una sola implementazione di entrambe le interfacce utente.
• [C-0-5] NON DEVE concedere autorizzazioni di runtime alle app preinstallate, a meno che:
  • Il consenso dell'utente può essere ottenuto prima che l'applicazione lo utilizzi.
  • Le autorizzazioni di runtime sono associate a un pattern di intent per il quale l'applicazione preinstallata è impostata come gestore predefinito.
• [C-0-6] È NECESSARIO concedere l'autorizzazione android.permission.RECOVER_KEYSTORE solo alle app di sistema che registrano un agente di recupero protetto correttamente. Un agente di recupero protetto correttamente è definito come un agente software on-device che si sincronizza con uno spazio di archiviazione remoto off-device, dotato di hardware sicuro con protezione equivalente o superiore a quella descritta nel servizio Google Cloud Key Vault per impedire attacchi di forza bruta al fattore di conoscenza della schermata di blocco.

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

• [SR] È MOLTO CONSIGLIATO fornire un meccanismo accessibile agli utenti per concedere o revocare l'accesso alle statistiche di utilizzo in risposta all'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS per le app che dichiarano l'autorizzazione android.permission.PACKAGE_USAGE_STATS.

Se le implementazioni dei dispositivi non vogliono consentire ad alcuna app, incluse quelle preinstallate, di accedere alle statistiche di utilizzo, devono:

• [C-1-1] DEVE comunque avere un'attività che gestisce il pattern di intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, ma DEVE implementarlo come no-op, ovvero avere un comportamento equivalente a quello che si verifica quando all'utente viene negato l'accesso.

9.2. Isolamento UID e dei processi

Implementazioni dei dispositivi:

• [C-0-1] DEVE supportare il modello di sandbox delle applicazioni Android, in cui ogni applicazione viene eseguita come UID Unix univoco e in un processo separato.
• [C-0-2] DEVE supportare l'esecuzione di più applicazioni con lo stesso ID utente Linux, a condizione che le applicazioni siano firmate e create correttamente, come definito nella documentazione di riferimento su sicurezza e autorizzazioni.

9.3. Autorizzazioni del file system

Implementazioni dei dispositivi:

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

9.4. Ambienti di esecuzione alternativi

Le implementazioni dei dispositivi DEVONO mantenere la coerenza del modello di sicurezza e delle autorizzazioni di Android, anche se includono ambienti di runtime che eseguono applicazioni utilizzando un altro software o tecnologia rispetto al formato eseguibile Dalvik o al codice nativo. In altre parole:

• [C-0-1] I runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella sezione 9.

• [C-0-2] Ai runtime alternativi NON DEVE essere concesso l'accesso alle risorse protette da autorizzazioni non richieste nel file AndroidManifest.xml del runtime tramite il meccanismo <uses-permission>.

• [C-0-3] I runtime alternativi NON DEVONO consentire alle applicazioni di utilizzare funzionalità protette dalle autorizzazioni Android limitate alle applicazioni di sistema.

• [C-0-4] I runtime alternativi DEVONO rispettare il modello di sandbox di Android e le applicazioni installate che utilizzano un runtime alternativo NON DEVONO riutilizzare la sandbox di qualsiasi altra app installata sul dispositivo, tranne tramite i meccanismi standard di Android per ID utente e certificato di firma condivisi.

• [C-0-5] I runtime alternativi NON DEVONO essere avviati con le sandbox corrispondenti ad altre applicazioni Android, né devono concedere o ricevere l'accesso alle sandbox.

• [C-0-6] I runtime alternativi NON DEVONO essere avviati con, essere concessi o concedere ad altre applicazioni privilegi del superutente (root) o di qualsiasi altro ID utente.

• [C-0-7] Quando i file .apk dei runtime alternativi sono inclusi nell'immagine di sistema delle implementazioni del dispositivo, DEVONO essere firmati con una chiave diversa da quella utilizzata per firmare le altre applicazioni incluse nelle implementazioni del dispositivo.

• [C-0-8] Durante l'installazione delle applicazioni, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione.

• [C-0-9] Quando un'applicazione deve utilizzare una risorsa del dispositivo per la quale esiste un'autorizzazione Android corrispondente (ad esempio Fotocamera, GPS e così via), il runtime alternativo DEVE informare l'utente che l'applicazione potrà accedere a quella risorsa.

• [C-0-10] Quando l'ambiente di runtime non registra le funzionalità dell'applicazione in questo modo, l'ambiente di runtime DEVE elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che lo utilizza.

• I runtime alternativi DOVREBBERO installare le app tramite PackageManager in sandbox Android separate (ID utente Linux e così via).

• I runtime alternativi POSSONO fornire una singola sandbox Android condivisa da tutte le applicazioni che li utilizzano.

9.5. Supporto di più utenti

Android include il supporto di più utenti e l'isolamento completo degli utenti.

• Le implementazioni dei dispositivi POSSONO, ma NON DEVONO, attivare il multiutente se utilizzano supporti rimovibili per lo spazio di archiviazione esterno principale.

Se le implementazioni dei dispositivi includono più utenti, questi:

• [C-1-1] DEVE soddisfare i seguenti requisiti relativi al supporto multiutente.
• [C-1-2] DEVE, per ogni utente, implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API.
• [C-1-3] DEVE avere directory di spazio di archiviazione delle applicazioni condivise (ovvero /sdcard) separate e isolate per ogni istanza utente.
• [C-1-4] DEVE garantire che le applicazioni di proprietà di un determinato utente e in esecuzione per suo conto non possano elencare, leggere o scrivere nei file di proprietà di altri utenti, anche se i dati di entrambi gli utenti sono archiviati nello stesso volume o file system.
• [C-1-5] DEVE criptare i contenuti della scheda SD quando il multiutente è abilitato utilizzando una chiave memorizzata solo su supporti non rimovibili accessibili solo al sistema se le implementazioni del dispositivo utilizzano supporti rimovibili per le API di archiviazione esterna. Poiché i contenuti multimediali non saranno più leggibili da un PC host, le implementazioni dei dispositivi dovranno passare a MTP o a un sistema simile per fornire ai PC host l'accesso ai dati dell'utente corrente.

Se le implementazioni dei dispositivi includono più utenti e non dichiarano il flag della funzionalità android.hardware.telephony, si verificano i seguenti casi:

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

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

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

9.6. Avviso SMS premium

Android include il supporto per avvisare gli utenti di qualsiasi messaggio SMS premium in uscita. Gli SMS premium sono messaggi inviati a un servizio registrato presso un operatore che potrebbero comportare un addebito per l'utente.

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

• [C-1-1] DEVE avvisare gli utenti prima di inviare un messaggio SMS ai numeri identificati dalle espressioni regolari definite nel file /data/misc/sms/codes.xml del dispositivo. L'Android Open Source Project upstream fornisce un'implementazione che soddisfa questo requisito.

9.7. Funzionalità per la sicurezza

Le implementazioni dei dispositivi DEVONO garantire la conformità alle funzionalità di sicurezza sia nel kernel sia nella piattaforma, come descritto di seguito.

La sandbox di Android include funzionalità che utilizzano il sistema di controllo dell'accesso obbligatorio (MAC) di Security-Enhanced Linux (SELinux), il sandboxing seccomp e altre funzionalità di sicurezza nel kernel Linux. Implementazioni dei dispositivi:

• [C-0-1] DEVE mantenere la compatibilità con le applicazioni esistenti, anche quando SELinux o altre funzionalità di sicurezza sono implementate sotto il framework Android.
• [C-0-2] NON DEVE avere un'interfaccia utente visibile quando viene rilevata una violazione della sicurezza e bloccata correttamente dalla funzionalità di sicurezza implementata sotto il framework Android, ma PUÒ avere un'interfaccia utente visibile quando si verifica una violazione della sicurezza non bloccata che si traduce in uno sfruttamento riuscito.
• [C-0-3] NON DEVE consentire all'utente o allo sviluppatore di app di configurare SELinux o altre funzionalità di sicurezza implementate sotto il framework Android.
• [C-0-4] NON DEVE consentire a un'applicazione che può influire su un'altra applicazione tramite un'API (ad esempio un'API di amministrazione del dispositivo) di configurare un criterio che violi la compatibilità.
• [C-0-5] È OBBLIGATORIO suddividere il framework multimediale in più processi in modo da poter concedere l'accesso in modo più specifico per ogni processo, come descritto nel sito del progetto open source Android.
• [C-0-6] È NECESSARIO implementare un meccanismo di sandboxing delle applicazioni del kernel che consenta di filtrare le chiamate di sistema utilizzando un criterio configurabile da programmi multithread. Il progetto Android Open Source upstream soddisfa questo requisito attivando seccomp-BPF con la sincronizzazione del gruppo di thread (TSYNC) come descritto nella sezione Configurazione del kernel di source.android.com.

Le funzionalità di integrità e autoprotezione del kernel sono parte integrante della sicurezza di Android. Implementazioni dei dispositivi:

• [C-0-7] DEVE implementare le protezioni contro gli overflow del buffer dello stack del kernel (ad es. CONFIG_CC_STACKPROTECTOR_STRONG).
• [C-0-8] È OBBLIGATORIO implementare protezioni rigorose della memoria del kernel in cui il codice eseguibile è di sola lettura, i dati di sola lettura non sono eseguibili e non sono scrivibili e i dati scrivibili non sono eseguibili (ad es. CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] È OBBLIGATORIO implementare il controllo dei limiti di dimensione degli oggetti statici e dinamici delle copie tra spazio utente e spazio kernel (ad es. CONFIG_HARDENED_USERCOPY) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
• [C-0-10] NON DEVE eseguire la memoria dello spazio utente durante l'esecuzione in modalità kernel (ad es. PXN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
• [C-0-11] NON DEVE leggere o scrivere la memoria dello spazio utente nel kernel al di fuori delle normali API di accesso usercopy (ad es. PAN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
• [C-0-12] È OBBLIGATORIO implementare l'isolamento della tabella delle pagine del kernel su tutti i dispositivi originariamente forniti con il livello API 28 o versioni successive (ad es. CONFIG_PAGE_TABLE_ISOLATION o "CONFIG_UNMAP_KERNEL_AT_EL0").
• [SR] È FORTEMENTE CONSIGLIATO mantenere i dati del kernel scritti solo durante l'inizializzazione contrassegnati come di sola lettura dopo l'inizializzazione (ad es. __ro_after_init).
• [SR] È FORTEMENTE CONSIGLIATO di randomizzare il layout del codice e della memoria del kernel ed evitare esposizioni che potrebbero compromettere la randomizzazione (ad es. CONFIG_RANDOMIZE_BASE con l'entropia del bootloader tramite /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).

Se le implementazioni dei dispositivi utilizzano un kernel Linux:

• [C-1-1] È NECESSARIO implementare SELinux.
• [C-1-2] È NECESSARIO impostare SELinux sulla modalità di applicazione globale.
• [C-1-3] È NECESSARIO configurare tutti i domini in modalità di applicazione. Non sono consentiti domini in modalità permissiva, inclusi i domini specifici di un dispositivo/fornitore.
• [C-1-4] NON DEVE modificare, omettere o sostituire le regole neverallow presenti nella cartella system/sepolicy fornita nell'Android Open Source Project (AOSP) in upstream e il criterio DEVE essere compilato con tutte le regole neverallow presenti, sia per i domini SELinux AOSP sia per i domini specifici del dispositivo/del fornitore.
• [C-1-5] È NECESSARIO eseguire applicazioni di terze parti che hanno come target il livello API 28 o versioni successive in sandbox SELinux per applicazione con limitazioni SELinux per app nella directory dei dati privati di ogni applicazione.
• DOVREBBE mantenere il criterio SELinux predefinito fornito nella cartella system/sepolicy del progetto open source Android upstream e aggiungere ulteriori elementi a questo criterio solo per la propria configurazione specifica del dispositivo.

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

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

• [C-2-1] È NECESSARIO utilizzare un sistema di controllo degli accessi obbligatorio equivalente a SELinux.

Android contiene più funzionalità di difesa in profondità che sono parte integrante della sicurezza del dispositivo.

Implementazioni dei dispositivi:

• [C-SR] È FORTEMENTE CONSIGLIATO di non disattivare l'integrità del flusso di controllo (CFI) o la convalida degli overflow di interi (IntSan) nei componenti in cui sono abilitati.
• [C-SR] È FORTEMENTE CONSIGLIATO attivare sia CFI sia IntSan per eventuali componenti dello spazio utente sensibili alla sicurezza, come spiegato in CFI e IntSan.

9.8. Privacy

9.8.1. Cronologia utilizzo

Android archivia la cronologia delle scelte dell'utente e la gestisce tramite UsageStatsManager.

Implementazioni dei dispositivi:

• [C-0-1] DEVE mantenere un periodo di conservazione ragionevole di questa cronologia utente.
• [SR] È FORTEMENTE CONSIGLIATO di mantenere il periodo di conservazione di 14 giorni come configurato per impostazione predefinita nell'implementazione AOSP.

Android memorizza gli eventi di sistema utilizzando gli identificatori StatsLog e gestisce questa cronologia tramite le API di sistema StatsManager e IncidentManager.

Implementazioni dei dispositivi:

• [C-0-2] È obbligatorio includere solo i campi contrassegnati con DEST_AUTOMATIC nel report sugli incidenti creato dalla classe dell'API di sistema IncidentManager.
• [C-0-3] NON devi utilizzare gli identificatori di eventi di sistema per registrare eventi diversi da quelli descritti nella documentazione dell'SDK StatsLog. Se vengono registrati altri eventi di sistema, POTREBBE essere utilizzato un identificatore di atomi diverso nell'intervallo compreso tra 100.000 e 200.000.

9.8.2. Registrazione in corso…

Implementazioni dei dispositivi:

• [C-0-1] NON DEVE precaricare o distribuire componenti software out-of-box che inviano le informazioni private dell'utente (ad es. sequenze di tasti, testo visualizzato sullo schermo) dal dispositivo senza il consenso dell'utente o senza mostrare notifiche chiare 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, queste:

• [C-1-1] DEVE essere presente una notifica continua all'utente ogni volta che questa funzionalità è attiva e acquisisce/registra attivamente.

Se le implementazioni dei dispositivi includono un componente abilitato out-of-the-box, in grado di registrare l'audio ambientale per dedurre informazioni utili sul contesto dell'utente, devono:

• [C-2-1] NON DEVE memorizzare nello spazio di archiviazione permanente sul dispositivo o trasmettere dal dispositivo l'audio non elaborato registrato o qualsiasi formato che possa essere convertito nuovamente nell'audio originale o in una copia quasi esatta, tranne con il consenso esplicito dell'utente.

9.8.3. Connettività

Se le implementazioni dei dispositivi dispongono di una porta USB con supporto della modalità periferica USB, devono:

• [C-1-1] DEVE presentare un'interfaccia utente che richieda il consenso dell'utente prima di consentire l'accesso ai contenuti dello spazio di archiviazione condiviso tramite la porta USB.

9.8.4. Traffico di rete

Implementazioni dei dispositivi:

• [C-0-1] DEVE preinstallare gli stessi certificati radice per l'archivio delle autorità di certificazione (CA) attendibili di sistema forniti nel progetto open source Android upstream.
• [C-0-2] DEVE essere fornito con un magazzino di CA radice utente vuoto.
• [C-0-3] DEVE mostrare un avviso all'utente che indica che il traffico di rete potrebbe essere monitorato quando viene aggiunta una CA principale dell'utente.

Se il traffico del dispositivo viene instradato tramite una VPN, le implementazioni del dispositivo:

• [C-1-1] DEVE mostrare un avviso all'utente che indica:
  • Il traffico di rete potrebbe essere monitorato.
  • Il traffico di rete viene instradato tramite l'applicazione VPN specifica che fornisce la VPN.

Se le implementazioni dei dispositivi dispongono di un meccanismo, abilitato per impostazione predefinita, che instrada il traffico di dati di rete tramite un server proxy o un gateway VPN (ad esempio, il precaricamento di un servizio VPN con android.permission.CONTROL_VPN concesso), devono:

• [C-2-1] DEVE chiedere il consenso dell'utente prima di attivare il meccanismo, a meno che la VPN non sia attivata dal Device Policy Controller tramite DevicePolicyManager.setAlwaysOnVpnPackage() , nel qual caso l'utente non deve fornire un consenso separato, ma DEVE solo essere informato.

Se le implementazioni dei dispositivi implementano un'affordance utente per attivare/disattivare la funzionalità "VPN sempre attiva" di un'app VPN di terze parti, devono:

• [C-3-1] È OBBLIGATORIO disattivare questa funzionalità per gli utenti per le app che non supportano il servizio VPN sempre attivo nel file AndroidManifest.xml impostando l'attributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON su false.

9.9. Crittografia dell'archiviazione dei dati

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

• [C-1-1] DEVE supportare la crittografia dell'archiviazione dei dati dei dati privati dell'applicazione (partizione /data) e della partizione di archiviazione condivisa dell'applicazione (partizione /sdcard) se si tratta di una parte permanente e non rimovibile del dispositivo, ad eccezione delle implementazioni del dispositivo che sono in genere condivise (ad es. la televisione).
• [C-1-2] DEVE attivare la crittografia dello spazio di archiviazione dei dati per impostazione predefinita al momento in cui l'utente ha completato l'esperienza di configurazione dell'out-of-box, ad eccezione delle implementazioni dei dispositivi in genere condivisi (ad es. la televisione).

Se le prestazioni della crittografia AES sono pari o inferiori a 50 MiB/sec, le implementazioni dei dispositivi POSSONO utilizzare Adiantum-XChaCha12-AES anziché la forma di AES elencata in una delle seguenti: AES-256-XTS nella Sezione 9.9.2 [C-1-5]; AES-256 in modalità CBS-CTS nella Sezione 9.9.2 [C-1-6]; AES nella Sezione 9.9.3 [C-1-1]; AES nella Sezione 9.9.3 [C-1-3].

Se le implementazioni dei dispositivi sono già state lanciate su una versione precedente di Android e non possono soddisfare il requisito tramite un aggiornamento del software di sistema, POTREBBERO essere esenti dai requisiti sopra indicati.

Implementazioni dei dispositivi:

• DEVE soddisfare il requisito di crittografia dell'archiviazione dei dati riportato sopra tramite l'implementazione della crittografia basata su file (FBE).

9.9.1. Avvio diretto

Implementazioni dei dispositivi:

• [C-0-1] DEVE implementare le API della modalità di avvio diretto anche se non supportano la crittografia dello spazio di archiviazione.

• [C-0-2] Gli intent ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED DEVONO comunque essere trasmessi per segnalare alle applicazioni compatibili con il Boot diretto che le posizioni di archiviazione con crittografia del dispositivo (DE) e con crittografia delle credenziali (CE) sono disponibili per l'utente.

9.9.2. Crittografia basata su file

Se le implementazioni dei dispositivi supportano FBE:

• [C-1-1] DEVE avviarsi senza richiedere all'utente le credenziali e consentire alle app compatibili con il riavvio diretto di accedere allo spazio di archiviazione criptato del dispositivo dopo l'invio del messaggio ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] DEVE consentire l'accesso allo spazio di archiviazione con crittografia delle credenziali (CE) solo dopo che l'utente ha sbloccato il dispositivo fornendo le proprie credenziali (ad es. passcode, PIN, sequenza o impronta) e il messaggio ACTION_USER_UNLOCKED viene trasmesso.
• [C-1-3] NON DEVE offrire alcun metodo per sbloccare lo spazio di archiviazione protetto CE senza le credenziali fornite dall'utente o una chiave escrow registrata.
• [C-1-4] DEVE supportare l'Avvio verificato e garantire che le chiavi DE siano legate in modo crittografico all'hardware root of trust 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, operato in modalità XTS. La lunghezza completa della chiave XTS è di 512 bit.

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

• Le chiavi che proteggono le aree di archiviazione CE e DE:

• [C-1-7] DEVE essere associato in modo crittografico a un Keystore basato su hardware.

• [C-1-8] Le chiavi CE DEVONO essere associate alle credenziali della schermata di blocco di un utente.
• [C-1-9] Le chiavi CE DEVONO essere associate a un passcode predefinito quando l'utente non ha specificato le credenziali della schermata di blocco.

• [C-1-10] DEVE essere univoco e distinto, in altre parole nessuna chiave CE o DE di un utente corrisponde alle chiavi CE o DE di un altro utente.

• [C-1-11] DEVE utilizzare per impostazione predefinita le modalità, le lunghezze delle chiavi e le cifre supportate obbligatoriamente.

• [C-SR] È FORTEMENTE CONSIGLIATO di criptare i metadati del file system, come dimensioni dei file, proprietà, modalità e attributi estesi (xattr), con una chiave legata in modo crittografico all'hardware root of trust del dispositivo.

• DOVREBBE rendere le app essenziali preinstallate (ad es. Sveglia, Telefono, Messenger) compatibili con il riavvio diretto.

• PUO' supportare algoritmi di crittografia alternativi, lunghezze e modalità delle chiavi per la crittografia dei contenuti e dei nomi dei file.

Il progetto Android Open Source 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), devono:

• [C-1-1] DEVE utilizzare AES in una modalità progettata per l'archiviazione (ad esempio XTS o CBC-ESSIV) e con una lunghezza della chiave di crittografia di almeno 128 bit.
• [C-1-2] DEVE utilizzare un passcode predefinito per il wrapping della chiave di crittografia e NON DEVE scrivere la chiave di crittografia nello spazio di archiviazione in nessun momento senza che sia criptata.
• [C-1-3] La chiave di crittografia DEVE essere criptata con AES per impostazione predefinita, a meno che l'utente non disattivi esplicitamente questa opzione, tranne quando è in uso attivo, con le credenziali della schermata di blocco allungate utilizzando un algoritmo di allungamento lento (ad es. PBKDF2 o scrypt).
• [C-1-4] L'algoritmo di stretching della password predefinito riportato sopra DEVE essere legato in modo crittografico a quel keystore 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 keystore basato su hardware.
• [C-1-5] NON DEVE inviare la chiave di crittografia dal dispositivo (anche se sottoposta a wrapping con il passcode dell'utente e/o la chiave legata all'hardware).

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

9.10. Integrità del dispositivo

I seguenti requisiti garantiscono la trasparenza dello stato dell'integrità del dispositivo. Implementazioni dei dispositivi:

• [C-0-1] DEVE segnalare correttamente tramite il metodo dell'API di sistema PersistentDataBlockManager.getFlashLockState() se lo stato del bootloader consente il flashing dell'immagine di sistema. Lo stato FLASH_LOCK_UNKNOWN è riservato alle implementazioni dei dispositivi che eseguono l'upgrade da una versione precedente di Android in cui non esisteva questo nuovo metodo dell'API di sistema.

• [C-0-2] DEVE supportare l'Avvio verificato per l'integrità del dispositivo.

Se le implementazioni dei dispositivi sono già state lanciate senza supportare Avvio verificato su una versione precedente di Android e non è possibile aggiungere il supporto di questa funzionalità con un aggiornamento del software di sistema, POTREBBERO essere esenti dal requisito.

L'Avvio verificato è una funzionalità che garantisce l'integrità del software del dispositivo. Se le implementazioni dei dispositivi supportano la funzionalità:

• [C-1-1] È OBBLIGATORIO dichiarare il flag funzionalità della piattaforma android.software.verified_boot.
• [C-1-2] È NECESSARIO eseguire la verifica a ogni sequenza di avvio.
• [C-1-3] È NECESSARIO avviare la verifica da una chiave hardware immutabile che è la radice della attendibilità e arrivare fino alla partizione di sistema.
• [C-1-4] DEVE implementare ogni fase di verifica per controllare l'integrità e l'autenticità di tutti i byte nella fase successiva prima di eseguire il codice nella fase successiva.
• [C-1-5] È NECESSARIO utilizzare algoritmi di verifica altrettanto efficaci dei consigli attuali del NIST per gli algoritmi di hashing (SHA-256) e le dimensioni delle chiavi pubbliche (RSA-2048).
• [C-1-6] NON DEVE consentire il completamento dell'avvio quando la verifica del sistema non va a buon fine, a meno che l'utente non accetti di tentare comunque l'avvio, nel qual caso i dati di eventuali blocchi di archiviazione non verificati NON DEVONO essere utilizzati.
• [C-1-7] NON DEVE consentire la modifica delle partizioni verificate sul dispositivo, a meno che l'utente non abbia sbloccato esplicitamente il bootloader.
• [C-SR] Se il dispositivo contiene più chip distinti (ad es. radio, processore di immagini specializzato), è MOLTO CONSIGLIATO verificare ogni fase del processo di avvio di ciascuno di questi chip all'avvio.
• [C-1-8] È NECESSARIO utilizzare uno spazio di archiviazione con dispositivo antimanomissione per memorizzare se il bootloader è sbloccato. Lo spazio di archiviazione con rilevamento di manomissione indica che il bootloader può rilevare se lo spazio di archiviazione è stato manomesso dall'interno di Android.
• [C-1-9] DEVE richiedere all'utente, durante l'utilizzo del dispositivo, una conferma fisica prima di consentire la transizione dalla modalità di blocco del bootloader alla modalità di sblocco del bootloader.
• [C-1-10] DEVE implementare la protezione del rollback per le partizioni utilizzate da Android (ad es. avvio, partizioni di sistema) e utilizzare lo spazio di archiviazione con rilevamento di manomissione per memorizzare i metadati utilizzati per determinare la versione minima del sistema operativo consentita.
• [C-SR] È FORTEMENTE CONSIGLIATO verificare tutti i file APK delle app con privilegi con una catena di attendibilità basata su /system, protetta da Verified Boot.
• [C-SR] È FORTEMENTE CONSIGLIATO verificare gli elementi eseguibili caricati da un'app privilegiata dall'esterno del file APK (ad esempio codice caricato dinamicamente o codice compilato) prima di eseguirli o FORTEMENTE CONSIGLIATO di non eseguirli affatto.
• DEVE implementare la protezione del rollback per qualsiasi componente con firmware persistente (ad es. modem, videocamera) e DEVE utilizzare uno spazio di archiviazione con protezione antimanomissione per archiviare i metadati utilizzati per determinare la versione minima consentita.

Se le implementazioni dei dispositivi sono già state lanciate senza supportare C-1-8 fino a C-1-10 su una versione precedente di Android e non è possibile aggiungere il supporto per questi requisiti con un aggiornamento del software di sistema, i dispositivi POTREBBERO essere esentati dai requisiti.

Il progetto Android Open Source upstream fornisce un'implementazione preferita di questa funzionalità nel repository external/avb/, che può essere integrata nel bootloader utilizzato per il caricamento di Android.

Implementazioni dei dispositivi:

• [C-R] Sono CONSIGLIATI per supportare l'API Android Protected Confirmation.

Se le implementazioni dei dispositivi supportano l'API Android Protected Confirmation:

• [C-3-1] È OBBLIGATORIO segnalare true per l'API ConfirmationPrompt.isSupported().
• [C-3-2] È NECESSARIO assicurarsi che l'hardware sicuro assuma il controllo completo del display in modo che il sistema operativo Android non possa bloccarlo senza essere rilevato dall'hardware sicuro.
• [C-3-3] È NECESSARIO assicurarsi che l'hardware sicuro assuma il controllo completo del touchscreen.

9.11. Chiavi e credenziali

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

• [C-0-1] DEVE consentire l'importazione o la generazione di almeno 8192 chiavi.
• [C-0-2] L'autenticazione nella schermata di blocco DEVE limitare la frequenza dei tentativi e DEVE avere un algoritmo di backoff esponenziale. Oltre 150 tentativi non riusciti, il ritardo DEVE essere di almeno 24 ore per tentativo.
• NON deve limitare il numero di chiavi che possono essere generate

Quando l'implementazione del dispositivo supporta una schermata di blocco sicura:

• [C-1-1] È NECESSARIO eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
• [C-1-2] DEVE avere implementazioni di algoritmi crittografici RSA, AES, ECDSA e HMAC e funzioni hash di famiglie MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e sopra. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi attraverso i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, inclusa la DMA. Il progetto Android Open Source (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura sottoposta a revisione da parte di terze parti di un'isolamento basato su hypervisor adeguato sono opzioni alternative.
• [C-1-3] DEVE eseguire l'autenticazione della schermata di blocco nell'ambiente di esecuzione isolato e, solo se l'autenticazione va a buon fine, consentire l'utilizzo delle chiavi legate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto Android Open Source upstream fornisce l'HAL (Hardware Abstraction Layer) Gatekeeper e Trusty, che possono essere utilizzati per soddisfare questo requisito.
• [C-1-4] DEVE supportare l'attestazione delle chiavi in cui la chiave di firma dell'attestazione è protetta da hardware sicuro e la firma viene eseguita in hardware sicuro. Le chiavi di firma dell'attestazione DEVONO essere condivise su un numero sufficientemente elevato di dispositivi per impedire che vengano utilizzate come identificatori dei dispositivi. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, È POSSIBILE utilizzare una chiave diversa per ogni 100.000 unità.
• [C-1-5] DEVE consentire all'utente di scegliere il timeout della modalità Sospensione per la transizione dallo stato sbloccato a quello bloccato, con un timeout minimo consentito fino a 15 secondi.

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

9.11.1. Schermata di blocco sicura

L'implementazione di AOSP segue un modello di autenticazione a più livelli in cui un'autenticazione principale basata su knowledge-factory può essere supportata da un'autenticazione biometrica secondaria efficace o da modalità terziarie meno efficaci.

Implementazioni dei dispositivi:

• [C-SR] È FORTEMENTE CONSIGLIATO impostare solo uno dei seguenti come metodo di autenticazione principale:
  • Un PIN numerico
  • Una password alfanumerica
  • Un pattern di scorrimento su una griglia di esattamente 3 x 3 punti

Tieni presente che i metodi di autenticazione sopra indicati sono indicati come metodi di autenticazione principali consigliati in questo documento.

Se le implementazioni dei dispositivi aggiungono o modificano i metodi di autenticazione principali consigliati e utilizzano un nuovo metodo di autenticazione come metodo sicuro per bloccare lo schermo, il nuovo metodo di autenticazione:

• [C-2-1] DEVE essere il metodo di autenticazione utente descritto in Requisire l'autenticazione utente per l'utilizzo della chiave.
• [C-2-2] DEVE sbloccare tutte le chiavi per l'utilizzo da parte di un'app di sviluppatore di terze parti 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 se si basano su una chiave segreta nota e utilizzano un nuovo metodo di autenticazione da trattare come un modo sicuro per bloccare lo schermo:

• [C-3-1] L'entropia della lunghezza minima consentita degli input DEVE essere maggiore di 10 bit.
• [C-3-2] L'entropia massima di tutti gli input possibili DEVE essere maggiore di 18 bit.
• [C-3-3] Il nuovo metodo di autenticazione NON DEVE sostituire nessuno dei metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) implementati e forniti in AOSP.
• [C-3-4] Il nuovo metodo di autenticazione DEVE essere disattivato quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_SOMETHING.

Se le implementazioni dei dispositivi aggiungono o modificano i metodi di autenticazione principali consigliati per sbloccare la schermata di blocco e utilizzano un nuovo metodo di autenticazione basato sulla biometria da trattare come un modo sicuro per bloccare lo schermo, il nuovo metodo:

• [C-4-1] DEVE soddisfare tutti i requisiti descritti nella sezione 7.3.10.2.
• [C-4-2] DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principale consigliati basati su una chiave segreta nota.
• [C-4-3] DEVE essere disattivato e consentire solo l'autenticazione principale consigliata per sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio della funzionalità 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.
• [C-4-5] DEVE avere un tasso di accettazione di falsi positivi uguale o superiore a quello richiesto per un sensore di impronte digitali come descritto nella sezione 7.3.10, altrimenti 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 di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-SR] È FORTEMENTE CONSIGLIATO di avere tassi di accettazione di spoofing e furto d'identità uguali 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 in modo che una compromissione del sistema operativo o del kernel non possa consentire l'iniezione diretta di dati per autenticarsi falsamente come utente.
• [C-4-7] DEVE essere accoppiato a un'azione di conferma esplicita (ad es.la pressione di un pulsante) per consentire l'accesso alle chiavi del keystore se l'applicazione imposta true per KeyGenParameterSpec.Built.setUserAuthenticationRequired() e il dato biometrico è passivo (ad es. volto o iride se non esiste un segnale esplicito di intenzione).
• [C-SR] È FORTEMENTE CONSIGLIATO proteggere l'azione di conferma per i dati biometrici passivi in modo che non possa essere compromessa da un sistema operativo o un kernel compromessi. Ad esempio, significa che l'azione di conferma basata su un pulsante fisico viene inoltrata tramite un pin di input/output (GPIO) generico di sola entrata di un elemento sicuro (SE) che non può essere azionato in nessun altro modo se non premendo un pulsante fisico.

Se i metodi di autenticazione biometrica non soddisfano i tassi di accettazione di spoofing e furto d'identità come descritto nella sezione 7.3.10:

• [C-5-1] I metodi DEVONO essere disattivati se l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] All'utente DEVE essere richiesta l'autenticazione principale consigliata (ad es. PIN, sequenza, password) dopo un periodo di inattività di 4 ore. Il periodo di timeout inattivo viene reimpostato dopo ogni conferma delle credenziali del dispositivo.
• [C-5-3] I metodi NON DEVONO essere considerati come una schermata di blocco sicura e DEVONO soddisfare i requisiti che iniziano con C-8 in questa sezione di seguito.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco e un nuovo metodo di autenticazione si basa su un token fisico o sulla posizione:

• [C-6-1] Devono avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principale consigliati basato su una chiave segreta nota e soddisfare i requisiti per essere considerati una schermata di blocco sicura.
• [C-6-2] Il nuovo metodo DEVE essere disattivato e deve consentire solo a uno dei metodi di autenticazione principale consigliati di sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio con il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o con il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] All'utente DEVE essere richiesto uno dei metodi di autenticazione principale consigliati (ad es. PIN, sequenza, password) almeno una volta ogni 72 ore.
• [C-6-4] Il nuovo metodo NON DEVE essere considerato una schermata di blocco sicura e DEVE rispettare le limitazioni elencate in C-8 di seguito.

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

• [C-7-1] DEVE essere presente un'indicazione chiara nel menu delle impostazioni e nella schermata di blocco quando il blocco del dispositivo è differito o può essere sbloccato dagli agenti attendibili. Ad esempio, AOSP soddisfa questo requisito mostrando una descrizione del testo per le impostazioni "Blocca automaticamente" e "Il tasto di accensione blocca immediatamente" nel menu delle impostazioni e un'icona distinguibile nella schermata di blocco.
• [C-7-2] DEVE rispettare e implementare completamente tutte le API di agenti di attendibilità nella classe DevicePolicyManager, ad esempio la costante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NON DEVE implementare completamente la funzione TrustAgentService.addEscrowToken() su un dispositivo utilizzato come dispositivo personale principale (ad es. palmare), ma PUÒ implementare completamente la funzione sulle implementazioni dei dispositivi che in genere sono condivisi (ad es. Android TV o dispositivo per auto e motori).
• [C-7-4] DEVE criptare tutti i token memorizzati aggiunti da TrustAgentService.addEscrowToken().
• [C-7-5] NON DEVE memorizzare la chiave di crittografia sullo stesso dispositivo su cui viene utilizzata. Ad esempio, è consentito che una chiave memorizzata su uno smartphone sblocchi un account utente su una TV.
• [C-7-6] È OBBLIGATORIO informare l'utente sulle implicazioni per la sicurezza prima di attivare il token escrow per decriptare lo spazio di archiviazione dei dati.
• [C-7-7] DEVE avere un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principale consigliati.
• [C-7-8] All'utente DEVE essere richiesta una verifica per uno dei metodi di autenticazione principale consigliati (ad es. PIN, sequenza, password) almeno una volta ogni 72 ore.
• [C-7-9] All'utente DEVE essere richiesta una verifica per uno dei metodi di autenticazione principale consigliati (ad es. PIN, sequenza, password) dopo un periodo di inattività di 4 ore. Il periodo di timeout inattivo viene reimpostato dopo ogni conferma delle credenziali del dispositivo.
• [C-7-10] NON DEVE essere trattata come una schermata di blocco sicura e DEVE rispettare i vincoli elencati in C-8 di seguito.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco che non è una schermata di blocco sicura come descritto sopra e utilizzano un nuovo metodo di autenticazione per sbloccare la schermata di blocco:

• [C-8-1] Il nuovo metodo DEVE essere disattivato quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] NON DEVONO reimpostare i timer di scadenza della password impostati da DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] NON DEVONO autenticare l'accesso ai magazzini delle chiavi quando l'applicazione imposta true per KeyGenParameterSpec.Builder.setUserAuthenticationRequired().

9.11.2. StrongBox

Il sistema Android Keystore consente agli sviluppatori di app di archiviare le chiavi di crittografia in un processore sicuro dedicato, nonché nell'ambiente di esecuzione isolato descritto sopra.

Implementazioni dei dispositivi:

• [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare StrongBox.

Se le implementazioni dei dispositivi supportano StrongBox:

• [C-1-1] È OBBLIGATORIO dichiarare FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] È NECESSARIO fornire hardware sicuro dedicato utilizzato per eseguire il backup del keystore e per proteggere l'autenticazione utente.

• [C-1-3] DEVE avere una CPU discreta che non condivide cache, DRAM, coprocessori o altre risorse di base con l'AP (Application Processor).

• [C-1-4] DEVE garantire che le periferiche condivise con l'AP non possano alterare in alcun modo l'elaborazione di StrongBox o ottenere informazioni da StrongBox. L'AP POTREBBE disattivare o bloccare l'accesso a StrongBox.

• [C-1-5] DEVE avere un orologio interno con un'accuratezza ragionevole (+-10%) che sia immune alle manipolazioni da parte dell'AP.

• [C-1-6] DEVE avere un generatore di numeri casuali veri che produca un output distribuito in modo uniforme e imprevedibile.

• [C-1-7] DEVE essere resistente alle manomissioni, inclusa la penetrazione fisica e i glitch.

• [C-1-8] DEVE avere resistenza ai canali laterali, inclusa la resistenza alla fuga di informazioni tramite canali laterali di alimentazione, temporizzazione, radiazioni elettromagnetiche e radiazioni termiche.

• [C-1-9] DEVE avere uno spazio di archiviazione sicuro che garantisca la riservatezza, l'integrità, l'autenticità, la coerenza e la novità dei contenuti. Lo spazio di archiviazione NON DEVE essere leggibile o modificabile, tranne nei casi consentiti dalle API StrongBox.

• Per convalidare la conformità ai punti [C-1-3] fino a [C-1-9], le implementazioni dei dispositivi:

  • [C-1-10] DEVE includere l'hardware certificato in base al profilo di protezione delle smart card sicure BSI-CC-PP-0084-2014 o valutato da un laboratorio di test accreditato a livello nazionale che includa la valutazione della vulnerabilità con potenziale di attacco elevato in base ai Common Criteria Application of Attack Potential to Smartcards.
  • [C-1-11] DEVE includere il firmware valutato da un laboratorio di test accreditato a livello nazionale che includa la valutazione della vulnerabilità con potenziale di attacco elevato in base ai Common Criteria Application of Attack Potential to Smartcards.
  • [C-SR] È FORTEMENTE CONSIGLIATO includere l'hardware valutato utilizzando un target di sicurezza, Evaluation Assurance Level (EAL) 5, aumentato da AVA_VAN.5. La certificazione EAL 5 diventerà probabilmente un requisito in una versione futura.

• [C-SR] sono FORTEMENTE CONSIGLIATI per fornire resistenza agli attacchi di tipo insider (IAR), il che significa che un insider con accesso alle chiavi di firma del firmware non può produrre firmware che causino la fuga di segreti da StrongBox, aggirino i requisiti di sicurezza funzionale o consentano in altro modo l'accesso a dati utente sensibili. Il modo consigliato per implementare l'IAR è consentire gli aggiornamenti del firmware solo quando la password dell'utente principale viene fornita tramite l'HAL IAuthSecret.

9.12. Eliminazione dei dati

Tutte le implementazioni dei dispositivi:

• [C-0-1] DEVE fornire agli utenti un meccanismo per eseguire un "Ripristino dei dati di fabbrica".
• [C-0-2] È NECESSARIO eliminare tutti i dati generati dagli utenti. ovvero tutti i dati, ad eccezione di quanto segue:
  • L'immagine di sistema
  • Eventuali file del sistema operativo richiesti dall'immagine di sistema
• [C-0-3] DEVE eliminare i dati in modo da soddisfare gli standard di settore pertinenti, come NIST SP800-88.
• [C-0-4] DEVE attivare la procedura di "Ripristino dei dati di fabbrica" riportata sopra quando l'API DevicePolicyManager.wipeData() viene chiamata dall'app Device Policy Controller dell'utente principale.
• POTREBBE fornire un'opzione di eliminazione rapida dei dati che esegue solo un'eliminazione logica dei dati.

9.13. Modalità Avvio sicuro

Android fornisce la modalità Avvio sicuro, che consente agli utenti di avviarsi in una modalità in cui è consentita l'esecuzione solo delle app di sistema preinstallate e tutte le app di terze parti sono disattivate. Questa modalità, nota come "Modalità di avvio sicuro", consente all'utente di disinstallare app di terze parti potenzialmente dannose.

Le implementazioni dei dispositivi sono:

• [SR] MOLTO CONSIGLIATO implementare la modalità Avvio protetto.

Se le implementazioni dei dispositivi implementano la modalità di avvio sicuro, devono:

• [C-1-1] DEVE fornire all'utente un'opzione per avviare la modalità provvisoria in modo che non possa essere interrotta dalle app di terze parti installate sul dispositivo, tranne quando l'app di terze parti è un controller Device Policy e ha impostato il flag UserManager.DISALLOW_SAFE_BOOT su true.

• [C-1-2] DEVE fornire all'utente la possibilità di disinstallare qualsiasi app di terze parti in modalità provvisoria.

• DOVREBBE fornire all'utente un'opzione per accedere alla modalità di avvio sicuro dal menu di avvio utilizzando un flusso di lavoro diverso da quello di un normale avvio.

9.14. Isolamento del sistema di veicoli a motore

I dispositivi Android Automotive devono scambiare dati con i sottosistemi critici del veicolo utilizzando l'HAL del veicolo per inviare e ricevere messaggi tramite le reti del veicolo, come il bus CAN.

Lo scambio di dati può essere protetto implementando funzionalità di sicurezza sotto i livelli del framework Android per impedire l'interazione dannosa o involontaria con questi sottosistemi.

9.15. Piani di abbonamento

Per "Piani di abbonamento" si intendono i dettagli del piano del rapporto di fatturazione forniti da un operatore di telefonia mobile tramite SubscriptionManager.setSubscriptionPlans().

Tutte le implementazioni dei dispositivi:

• [C-0-1] DEVE restituire i piani di abbonamento solo all'app dell'operatore di telefonia mobile che li ha forniti in origine.
• [C-0-2] NON DEVE eseguire il backup o caricare i piani di abbonamento da remoto.
• [C-0-3] DEVE consentire le sostituzioni, ad esempio SubscriptionManager.setSubscriptionOverrideCongested(), solo dall'app dell'operatore di telefonia mobile che 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 software è completamente completo. Per questo motivo, agli implementatori dei dispositivi è FORTEMENTE CONSIGLIATO di apportare il minor numero possibile di modifiche all'implementazione di riferimento e preferita di Android disponibile nell'Android Open Source Project. In questo modo, ridurrai al minimo il rischio di introdurre bug che creano incompatibilità che richiedono rielaborazioni e potenziali aggiornamenti del dispositivo.

10.1. Compatibility Test Suite (CTS)

Implementazioni dei dispositivi:

• [C-0-1] DEVE superare la Compatibility Test Suite (CTS) di Android disponibile nell'Android Open Source Project, utilizzando il software di spedizione finale sul dispositivo.

• [C-0-2] DEVE garantire la compatibilità in caso di ambiguità nel CTS e per eventuali reimplementazioni di parti del codice sorgente di riferimento.

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi software, anche il CTS potrebbe contenere bug. La versione del CTS sarà indipendente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni del CTS per Android 9.

Implementazioni dei dispositivi:

• [C-0-3] DEVE superare la versione CTS più recente disponibile al momento del completamento del software del dispositivo.

• DOVREBBE utilizzare l'implementazione di riferimento nella struttura Android Open Source il più possibile.

10.2. Verificatore CTS

CTS Verifier è incluso nella Compatibility Test Suite e deve essere eseguito da un operatore umano per testare le funzionalità che non possono essere testate da un sistema automatico, ad esempio il corretto funzionamento di una fotocamera e dei sensori.

Implementazioni dei dispositivi:

• [C-0-1] DEVE eseguire correttamente tutti i casi applicabili nel verificatore CTS.

CTS Verifier include test per molti tipi di hardware, incluso hardware facoltativo.

Implementazioni dei dispositivi:

• [C-0-2] DEVE superare tutti i test per l'hardware di cui è dotato; ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente lo scenario di test Accelerometer in CTS Verifier.

Gli scenari di test per le funzionalità indicate come facoltative da questo documento di definizione della compatibilità POSSONO essere saltati o omessi.

• [C-0-2] Ogni dispositivo e ogni build DEVONO eseguire correttamente lo strumento di verifica CTS, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori dei dispositivi eseguano esplicitamente CTS Verifier su build che differiscono solo in modo banale. In particolare, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato CTS Verifier solo per l'insieme di lingue, branding e così via inclusi POSSONO omettere il test CTS Verifier.

11. Software aggiornabile

• [C-0-1] Le implementazioni dei dispositivi DEVONO includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire upgrade "in tempo reale", ovvero POTREBBE essere necessario riavviare il dispositivo. È possibile utilizzare qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, qualsiasi dei seguenti approcci soddisfa questo requisito:

  • I download "over-the-air (OTA)" con aggiornamento offline tramite riavvio.
  • Aggiornamenti "in tethering" tramite USB da un PC host.
  • Aggiornamenti "offline" tramite un riavvio e un aggiornamento da un file su una memoria rimovibile.

• [C-0-2] Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. In altre parole, il meccanismo di aggiornamento DEVE preservare i dati privati e condivisi dell'applicazione. Tieni presente che il software Android upstream include un meccanismo di aggiornamento che soddisfa questo requisito.

Se le implementazioni del dispositivo includono il supporto di una connessione dati non misurata, come il profilo 802.11 o PAN (Personal Area Network) Bluetooth, devono:

• [C-1-1] DEVE supportare i download OTA con aggiornamento offline tramite riavvio.

Per le implementazioni dei dispositivi che vengono lanciate con Android 6.0 e versioni successive, il meccanismo di aggiornamento DOVREBBE supportare la verifica che l'immagine di sistema sia identica al risultato previsto dopo un aggiornamento OTA. L'implementazione OTA basata su blocchi nell'Android Open Source Project upstream, aggiunta da Android 5.1, soddisfa questo requisito.

Inoltre, le implementazioni dei dispositivi DEVONO supportare gli aggiornamenti di sistema A/B. AOSP implementa questa funzionalità utilizzando l'HAL di controllo del boot.

Se in un'implementazione di un dispositivo viene rilevato un errore dopo il rilascio, ma entro il periodo di tempo ragionevole del prodotto, che viene stabilito in consultazione con il team di compatibilità di Android, che influisce sulla compatibilità delle applicazioni di terze parti:

• [C-2-1] L'implementatore del dispositivo DEVE correggere l'errore tramite un aggiornamento software disponibile che può essere applicato secondo il meccanismo appena descritto.

Android include funzionalità che consentono all'app Proprietario dispositivo (se presente) di controllare l'installazione degli aggiornamenti di sistema. Se il sottosistema di aggiornamento di sistema per i dispositivi segnala android.software.device_admin, questi:

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

• Documentare il log delle modifiche

Per un riepilogo delle modifiche alle sezioni relative alle persone:

1. Introduzione
2. Tipi di dispositivi
3. Software
4. Confezione dell'applicazione
5. Contenuti multimediali
6. Strumenti e opzioni per sviluppatori
7. Compatibilità hardware
8. Prestazioni e potenza
9. Modello di sicurezza
10. Test di compatibilità del software
11. Software aggiornabile
12. Log delle modifiche della documentazione
13. Contattaci

12.1. Suggerimenti per la visualizzazione del log delle modifiche

Le modifiche sono contrassegnate come segue:

• CDD
  Modifiche sostanziali ai requisiti di compatibilità.

• Documenti
  Modifiche estetiche o relative alla compilazione.

Per una visualizzazione ottimale, aggiungi i parametri URL pretty=full e no-merges agli URL del log delle modifiche.

13. Contattaci

Puoi partecipare al forum Android Compatibility e chiedere chiarimenti o segnalare eventuali problemi che ritieni non coperti dal documento.