Definizione di compatibilità di Android 9

1. Introduzione

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

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

Ai fini del presente documento, un "implementatore di dispositivi" o "implementatore" è una persona o un'organizzazione che sviluppa una soluzione hardware/software che esegue Android 9. Un'implementazione del dispositivo o "implementazione" è la soluzione hardware/software così sviluppata.

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

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

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

Molte delle risorse a cui viene fatto riferimento in questo documento derivano direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni contenute nella documentazione dell'SDK. Nei casi in cui questa definizione di compatibilità o la suite di test di compatibilità non sono in linea con la documentazione dell'SDK, quest'ultima è considerata autorevole. Tutti i 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, questi requisiti sono indicati come "Requisiti di base".

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 viene assegnato alcun ID.
• L'ID è composto da : ID tipo di dispositivo - ID condizione - ID requisito (ad es. C-0-1).

Ogni ID è definito come segue:

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

1.1.3. ID requisito nella sezione 2

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

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

2. Tipi di dispositivi

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

Questa sezione descrive questi tipi di dispositivi, nonché 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 dispositivo

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

2.2. Requisiti per i dispositivi portatili

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

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

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

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

2.2.1. Hardware

Implementazioni di dispositivi palmari:

• [7.1.1.1/H-0-1] DEVE avere uno schermo di almeno 2,5 pollici di dimensione diagonale fisica.
• [7.1.1.3/H-SR] È VIVAMENTE CONSIGLIATO fornire agli utenti la possibilità di modificare le dimensioni di visualizzazione (densità schermo).

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

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

Implementazioni di dispositivi palmari:

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

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

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

Se le implementazioni di dispositivi palmari includono un giroscopio:

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

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

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

Implementazioni di dispositivi palmari:

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

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

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

Implementazioni di dispositivi palmari:

• [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 il kernel e lo spazio utente hanno a disposizione meno di 1 GB di memoria.

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

• [7.6.1/H-1-1] La memoria disponibile per il kernel e lo spazio utente DEVE essere 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 del framebuffer fino a FHD (ad es. WSXGA+).

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

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

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

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

Se le implementazioni di dispositivi 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 di dispositivi palmari:

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

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

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

Implementazioni di dispositivi palmari:

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

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

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

2.2.2. Multimediali

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] MPEG-4 HE AAC Profile (AAC+)
• [5.1.1/H-0-5] AAC ELD (enhanced low delay AAC)

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 palmari 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 di dispositivi palmari:

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

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

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

Se le implementazioni di dispositivi palmari Android supportano una schermata di blocco:

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

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

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

Implementazioni di dispositivi palmari:

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

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

• [3.16/H-1-1] DEVE supportare la funzionalità di accoppiamento di dispositivi complementari.

2.2.4. Prestazioni e potenza

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

Implementazioni di dispositivi palmari:

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

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

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

Implementazioni di dispositivi palmari:

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

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

• [8.4/H-1-1] DEVE rispettare l'intento di android.intent.action.POWER_USAGE_SUMMARY e mostrare un menu delle impostazioni che indichi il consumo energetico.

2.2.5. Modello di sicurezza

Implementazioni di dispositivi palmari:

• [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 a 15 secondi o meno.
• [9.11/H-1-2] DEVE fornire all'utente la possibilità di nascondere le notifiche e disattivare tutte le forme di autenticazione, ad eccezione dell'autenticazione principale descritta in 9.11.1 Schermata di blocco sicura. AOSP soddisfa il requisito come modalità di blocco.

2.3. Requisiti della TV

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

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

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

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

2.3.1. Hardware

Implementazioni di dispositivi TV:

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

Se le implementazioni dei dispositivi televisivi includono un giroscopio:

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

Implementazioni di dispositivi TV:

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

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

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

Se le implementazioni dei dispositivi TV sono a 32 bit:

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

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

Se le implementazioni dei dispositivi TV sono a 64 bit:

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

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

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

Implementazioni di dispositivi TV:

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

2.3.2. Multimediali

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

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

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

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

Implementazioni di dispositivi TV:

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

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

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] 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

È VIVAMENTE CONSIGLIATO che le implementazioni dei dispositivi televisivi supportino i seguenti formati di decodifica video:

• [5.3.1/T-SR] MPEG-2

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

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

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

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

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

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

Le implementazioni dei dispositivi televisivi DEVONO supportare la decodifica VP8, come descritto in dettaglio nella sezione 5.3.6, a frame rate 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 televisivi con decoder hardware VP9 DEVONO supportare la decodifica VP9, come descritto nella sezione 5.3.7, a frame rate video e risoluzioni standard fino a:

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

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

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

Implementazioni di dispositivi TV:

• [5.5.3/T-0-1] DEVE includere il supporto per il volume principale del sistema e l'attenuazione del volume dell'output audio digitale sugli output supportati, ad eccezione dell'output passthrough audio compresso (in cui la decodifica audio non viene eseguita sul dispositivo).
• [5.8/T-0-1] DEVE impostare la modalità di uscita HDMI per selezionare la risoluzione massima supportata con una frequenza di aggiornamento di 50 Hz o 60 Hz per tutti i display con cavo.
• [5.8/T-SR] È VIVAMENTE CONSIGLIATO di fornire un selettore della frequenza di aggiornamento HDMI configurabile dall'utente per tutti i display cablati.
• [5.8/T-SR] Sono FORTEMENTE CONSIGLIATI per supportare la decodifica simultanea di stream protetti. È VIVAMENTE CONSIGLIATA la decodifica simultanea di almeno due flussi.
• [5.8] DEVE impostare la frequenza di aggiornamento della modalità di uscita HDMI su 50 Hz o 60 Hz, a seconda della frequenza di aggiornamento video per la regione in cui viene venduto il dispositivo per tutti i display cablati.

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

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

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

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

2.3.3. Software

Implementazioni di dispositivi TV:

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

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

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

Implementazioni di dispositivi TV:

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

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

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

Implementazioni di dispositivi TV:

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

2.3.4. Prestazioni e potenza

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

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

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

Implementazioni di dispositivi TV:

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

2.4. Requisiti dell'orologio

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

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

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

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

2.4.1. Hardware

Guarda le implementazioni dei dispositivi:

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

• [7.2.3/W-0-1] DEVE avere la funzione Home disponibile per l'utente e la funzione Indietro, tranne quando si trova 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 disponibile per il kernel e lo spazio utente.

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

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

2.4.2. Multimediali

Nessun altro requisito.

2.4.3. Software

Guarda le implementazioni dei dispositivi:

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

Guarda le implementazioni dei dispositivi:

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

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

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

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

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

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

2.4.4. Prestazioni e potenza

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

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

Guarda le implementazioni dei dispositivi:

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

2.5. Requisiti per il settore automobilistico

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

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

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

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

2.5.1. Hardware

Implementazioni di dispositivi per il settore automotive:

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

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

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

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

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

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

• [7.3.1/A-1-1] DEVE essere in grado di segnalare 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 Android.

Se le implementazioni di dispositivi per il settore automobilistico includono un giroscopio:

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

Implementazioni di dispositivi per il settore automotive:

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

Implementazioni di dispositivi per il settore automotive:

• [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 del cruscotto e DOVREBBE basarsi sull'input del sensore della luce ambientale.

• Il sensore della luce ambientale sottostante POTREBBE essere lo stesso del fotometro.

• [7.3.11.4/A-0-1] DEVE 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 Bluetooth LE.

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

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

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

• [7.4.5/A] PUÒ utilizzare la costante NetworkCapabilities#NET_CAPABILITY_OEM_PAID dell'API di sistema per le reti 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 il settore automotive:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implementazioni di dispositivi per il settore automotive:

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

Implementazioni di dispositivi per il settore automotive:

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

Implementazioni di dispositivi per il settore automotive:

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

2.5.2. Multimediali

Le implementazioni dei dispositivi per il settore auto e motori 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 (enhanced low delay AAC)

Le implementazioni dei dispositivi per il settore 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 il settore 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

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

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

2.5.3. Software

Implementazioni di dispositivi per il settore automotive:

• [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 le notifiche che utilizzano l'API Notification.CarExtender quando richiesto da applicazioni di terze parti.

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

• [3.13/A-SR] È VIVAMENTE CONSIGLIATO includere un componente UI 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 pressione breve del pulsante Push to Talk come interazione designata per avviare l'app di assistenza selezionata dall'utente, ovvero l'app che implementa VoiceInteractionService.

Implementazioni di dispositivi per il settore automotive:

• [3.14/A-0-1] DEVE includere un framework UI per supportare app di terze parti che utilizzano le API multimediali come descritto nella sezione 3.14.

2.5.4. Prestazioni e potenza

Se le implementazioni di dispositivi per il settore automobilistico 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] DEVE 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 esentate dalle modalità di risparmio energetico Standby delle app e Sospensione.

Implementazioni di dispositivi per il settore automotive:

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

2.5.5. Modello di sicurezza

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

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

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

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

Implementazioni di dispositivi per il settore automotive:

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

2.6. Requisiti per i tablet

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

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

Le implementazioni dei dispositivi tablet hanno requisiti simili a quelli dei dispositivi palmari. Le eccezioni sono indicate da un asterisco (*) nella sezione e sono riportate a titolo di riferimento in questa sezione.

2.4.1. Hardware

Dimensioni schermo

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

Memoria e spazio di archiviazione minimi (sezione 7.6.1)

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

Modalità periferica USB (Sezione 7.7.1)

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

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

Modalità Realtà virtuale (sezione 7.9.1)

Virtual Reality High Performance (Sezione 7.9.2)

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

3. Software

3.1. Compatibilità API gestita

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

Implementazioni del dispositivo:

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

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

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

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

• [C-0-5] DEVE limitare l'utilizzo di API nascoste da parte di app di terze parti, definite come API nello spazio dei nomi android decorate con l'annotazione @hidden, ma non con @SystemAPI o @TestApi, come descritto nei documenti SDK, e deve includere ogni singola API nascosta negli stessi elenchi con limitazioni forniti tramite l'elenco provvisorio e i file denylist nel percorso prebuilts/runtime/appcompat/ per il ramo del livello API appropriato in AOSP. Tuttavia,

  • MAGGIO, se un'API nascosta è assente o implementata in modo diverso nell'implementazione del dispositivo, sposta l'API nascosta nell'elenco negato o omettila da tutti gli elenchi con limitazioni.
  • MAGGIO: se un'API nascosta non esiste già in AOSP, aggiungila a uno degli elenchi con limitazioni.
  • PUÒ implementare un meccanismo di aggiornamento dinamico che sposta un'API nascosta da un elenco con restrizioni a un elenco meno restrittivo, ad eccezione della lista consentita.

3.1.1. Estensioni Android

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

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

3.1.2. Libreria Android

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

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

L'implementazione AOSP soddisfa questi requisiti.

3.2. Compatibilità API soft

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

3.2.1. Autorizzazioni

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

3.2.2. Parametri di build

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

• [C-0-1] Per fornire valori coerenti e significativi nelle implementazioni dei dispositivi, la tabella seguente include ulteriori limitazioni sui formati di questi valori a cui le implementazioni dei dispositivi DEVONO conformarsi.

Parametro	Dettagli
VERSIONE.RELEASE	La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE contenere uno dei valori stringa definiti in 9.
VERSION.SDK	La versione del sistema Android 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 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 indica la build specifica del sistema Android attualmente in esecuzione, in formato leggibile. Questo valore NON DEVE essere riutilizzato per build diverse rese disponibili agli utenti finali. Un utilizzo tipico di questo campo è indicare il numero di build o l'identificatore di modifica del controllo del codice sorgente utilizzato per generare la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne 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 noto agli utenti finali. DEVE essere in un formato leggibile e DOVREBBE rappresentare il produttore del dispositivo o il brand dell'azienda con cui viene commercializzato il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
SUPPORTED_32_BIT_ABIS	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
SUPPORTED_64_BIT_ABIS	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
CPU_ABI	Il nome del set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
CPU_ABI2	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3. Compatibilità API nativa.
DISPOSITIVO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice che identifica la configurazione delle funzionalità hardware e del design industriale del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$". Il nome del dispositivo NON DEVE cambiare durante il ciclo di vita del prodotto.
FINGERPRINT	Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ad esempio: acme/myproduct/     mydevice:9/LMYXX/3359:userdebug/test-keys L'impronta NON DEVE includere spazi. Se altri campi inclusi nel modello precedente contengono spazi vuoti, questi DEVONO essere sostituiti nel fingerprint 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). DEVE essere ragionevolmente leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9_-]+$".
HOST	Una stringa che identifica in modo univoco l'host su cui è stata creata la build, in formato leggibile. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota ("").
ID	Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in formato leggibile. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DOVREBBE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere tra le build software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
PRODUTTORE	Il nome commerciale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota (""). Questo campo NON deve cambiare durante il ciclo di vita del prodotto.
MODEL	Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo noto all'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota (""). Questo campo NON deve cambiare durante il ciclo di vita del prodotto.
PRODOTTO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice dello specifico prodotto (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.
SERIAL	DEVE restituire "UNKNOWN".
TAG	Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che distinguono ulteriormente la build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni di firma tipiche della piattaforma Android: release-keys, dev-keys, test-keys.
TEMPO	Un valore che rappresenta il timestamp di quando è stata eseguita la build.
TIPO	Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondenti alle tre configurazioni tipiche di Android Runtime: user, userdebug o eng.
UTENTE	Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON deve essere nullo o la stringa vuota ("").
SECURITY_PATCH	Un valore che indica il livello patch di sicurezza di una build. DEVE indicare che la build non è in alcun modo vulnerabile a nessuno dei problemi descritti nel Bollettino pubblico sulla sicurezza di Android designato. Deve essere nel formato [AAAA-MM-GG], corrispondente a una stringa definita documentata nel bollettino di sicurezza pubblico di Android o nell'avviso di sicurezza di Android, ad esempio "2015-11-01".
BASE_OS	Un valore che rappresenta il parametro FINGERPRINT della build che è altrimenti identica a questa build, ad eccezione delle patch fornite nel Bollettino sulla sicurezza pubblica di Android. Deve segnalare il valore corretto e, se tale build non esiste, segnalare una stringa vuota ("").
BOOTLOADER	Un valore scelto dall'implementatore del dispositivo che identifica la versione specifica del bootloader interno utilizzata nel dispositivo, in formato leggibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9._-]+$".
getRadioVersion()	DEVE (essere o restituire) un valore scelto dall'implementatore del dispositivo che identifica la versione specifica della radio/del modem interno utilizzata nel dispositivo, in 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à degli intent

3.2.3.1. Intent 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 del dispositivo DEVONO precaricare uno o più componenti di applicazioni o servizi con un gestore di intent, per tutti i pattern di filtri per intent pubblici definiti dalle seguenti applicazioni Android di base in AOSP:

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

3.2.3.2. Risoluzione dell'intent

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

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

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

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

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

• [C-0-4] DEVE tentare di convalidare tutti i filtri per intent eseguendo i passaggi di convalida definiti nella specifica Digital Asset Links implementata da Gestore pacchetti nel progetto Android Open Source Project upstream.
• [C-0-5] DEVE tentare la convalida dei filtri per intent durante l'installazione dell'applicazione e impostare tutti i filtri per intent URI convalidati correttamente come gestori di app predefiniti per i relativi URI.
• POSSONO impostare filtri per 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 lo fa, DEVE fornire all'utente override di pattern per URI appropriati nel menu delle impostazioni.
• DEVE fornire all'utente controlli dei link dell'app per app in Impostazioni come segue:
  • [C-0-6] L'utente DEVE essere in grado di ignorare in modo olistico il comportamento predefinito dei link per app per un'app da: aprire sempre, chiedere sempre o non aprire mai, il che deve valere per tutti i filtri per intent URI candidati in egual misura.
  • [C-0-7] L'utente DEVE essere in grado di visualizzare un elenco dei filtri per intent URI candidati.
  • L'implementazione del dispositivo PUÒ fornire all'utente la possibilità di ignorare filtri per intent URI candidati specifici verificati correttamente, in base al filtro per intent.
  • [C-0-8] L'implementazione del dispositivo DEVE consentire agli utenti di visualizzare e ignorare filtri di intent URI candidati specifici se l'implementazione del dispositivo consente la verifica di alcuni filtri di intent URI candidati, mentre altri possono non superarla.

3.2.3.3. Spazi dei nomi degli intent

• [C-0-1] Le implementazioni dei dispositivi NON DEVONO includere componenti Android che rispettino nuovi pattern di intent o intent di trasmissione utilizzando un'AZIONE, una CATEGORIA o un'altra stringa chiave nello spazio dei nomi android. o com.android..
• [C-0-2] Gli implementatori di dispositivi NON DEVONO includere componenti Android che rispettino nuovi intent o pattern di intent di trasmissione utilizzando una stringa ACTION, CATEGORY o un'altra stringa chiave in uno spazio di pacchetti appartenente a un'altra organizzazione.
• [C-0-3] Gli implementatori di dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent utilizzati dalle app principali elencate nella sezione 3.2.3.1.
• Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano spazi dei nomi chiaramente e ovviamente associati alla propria organizzazione. Questo divieto è analogo a quello specificato per le classi di linguaggio Java nella sezione 3.6.

3.2.3.4. Broadcast Intents

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

Implementazioni del dispositivo:

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

3.2.3.5. Impostazioni app predefinite

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

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

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

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

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

• [C-2-1] DEVE fornire un menu delle impostazioni che richiami 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 di mostrare una finestra di dialogo per consentire all'utente di modificare l'applicazione Telefono predefinita.

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

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

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

• [C-3-1] DEVE rispettare l'intent android.settings.NFC_PAYMENT_SETTINGS per mostrare un menu delle impostazioni dell'app predefinita per pagare contactless.

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

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

3.2.4. Attività sui display secondari

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

• [C-1-1] DEVE impostare il flag funzionalità android.software.activities_on_secondary_displays.
• [C-1-2] DEVE garantire la compatibilità dell'API in modo simile a un'attività in esecuzione sul display principale.
• [C-1-3] DEVE visualizzare la nuova attività sullo stesso display dell'attività che l'ha avviata, quando la nuova attività viene avviata senza specificare un display di destinazione tramite l'API ActivityOptions.setLaunchDisplayId().
• [C-1-4] DEVE eliminare tutte le attività quando viene rimosso un display con il flag Display.FLAG_PRIVATE.
• [C-1-5] DEVE ridimensionare di conseguenza tutte le attività su un VirtualDisplay se il display stesso viene ridimensionato.
• POTREBBE mostrare un IME (editor del metodo di input, un controllo utente che consente agli utenti di inserire testo) sul display principale quando un campo di immissione di testo viene messo a fuoco su un display secondario.
• DEVE implementare lo stato attivo dell'input sul display secondario indipendentemente dal display principale, quando sono supportati input tattili o da tastiera.
• DEVE avere android.content.res.Configuration corrispondente a quel display per essere visualizzata, funzionare correttamente e mantenere la compatibilità se un'attività viene avviata sul display secondario.

Se le implementazioni del dispositivo consentono l'avvio di attività Android normali su display secondari e i display principale e secondario hanno android.util.DisplayMetrics diversi:

• [C-2-1] Le attività non ridimensionabili (che hanno 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 l'avvio di attività Android normali su display secondari e un display secondario ha il flag android.view.Display.FLAG_PRIVATE:

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

3.3. Compatibilità con l'API nativa

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

• [SR] CONSIGLIATO VIVAMENTE di utilizzare le implementazioni delle librerie elencate di seguito dal progetto Android Open Source Project upstream.

3.3.1. Application Binary Interfaces

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

Implementazioni del dispositivo:

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

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

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

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

  • libaaudio.so (supporto audio nativo AAudio)

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

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

• [C-0-9] DEVE elencare librerie non AOSP aggiuntive esposte direttamente ad app di terze parti in /vendor/etc/public.libraries.txt.
• [C-0-10] NON DEVE esporre altre librerie native, implementate e fornite in AOSP come librerie di sistema, ad app di terze parti che hanno come target il livello API 24 o versioni successive, in quanto sono riservate.
• [C-0-11] DEVE esportare tutti i simboli di funzione OpenGL ES 3.1 e Android Extension Pack, come definiti nell'NDK, tramite la libreria libGLESv3.so. Tieni presente che, sebbene tutti i simboli DEBBANO essere presenti, la sezione 7.1.4.1 descrive in modo più dettagliato i requisiti per quando è prevista l'implementazione completa di ciascuna funzione corrispondente.
• [C-0-12] DEVE esportare i simboli di funzione per i simboli di funzione Vulkan 1.0 di base, 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, sebbene tutti i simboli DEBBANO essere presenti, la sezione 7.1.4.2 descrive in modo più dettagliato i requisiti per quando è prevista l'implementazione completa di ciascuna funzione corrispondente.
• DEVE essere creato utilizzando il codice sorgente e i file di intestazione disponibili nel progetto Android Open Source Project upstream

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

3.3.2. Compatibilità del codice nativo ARM a 32 bit

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

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

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

• [C-2-1] MUST include the following lines in /proc/cpuinfo, and SHOULD NOT alter the values on the same device, even when they are read by other ABIs.

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

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

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

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

3.4. Compatibilità web

3.4.1. Compatibilità di WebView

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

• [C-1-1] MUST report android.software.webview.
• [C-1-2] DEVE utilizzare la build del progetto Chromium dall'Android Open Source Project 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 essere nel seguente formato:

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

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

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

3.4.2. Compatibilità dei browser

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

• [C-1-1] DEVE supportare ciascuna di queste API associate a HTML5:
  • 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 passando a IndexedDB rispetto a webstorage, è previsto che IndexedDB diventi un componente obbligatorio in una versione futura di Android.
• POTREBBE spedire una stringa user agent personalizzata nell'applicazione browser autonoma.
• DEVE implementare il supporto per la maggior parte possibile di HTML5 nell'applicazione browser autonoma (basata sull'applicazione browser WebKit upstream o su una sostituzione di terze parti).

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

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

3.5. Compatibilità comportamentale delle API

Implementazioni del dispositivo:

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

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

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

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

3.5.1. Limitazione in background

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

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

3.6. API Namespaces

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

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

ovvero:

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

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

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

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

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

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

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

3.7. Compatibilità del runtime

Implementazioni del dispositivo:

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

• [C-0-2] MUST configure Dalvik runtimes to allocate memory in accordance with the upstream Android platform, and as specified by the following table. (Per le definizioni di dimensioni e densità dello schermo, consulta la sezione 7.1.1.)

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

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

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

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

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

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

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

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

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

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

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

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

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

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

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

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

3.8.2. Widget

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

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

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

3.8.3. Notifiche

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

3.8.3.1. Presentazione delle notifiche

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

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

Se le implementazioni dei dispositivi supportano le notifiche avanzate:

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

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

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

3.8.3.2. Servizio listener di notifiche

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

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

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

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

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

3.8.3.3. DND (Do Not Disturb, Non disturbare)

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

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

3.8.4. Cerca

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

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

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

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

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

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

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

Se le implementazioni dei dispositivi supportano l'azione Aiuto,

• [C-2-1] DEVE indicare chiaramente all'utente finale quando il contesto viene condiviso, tramite:
  • Ogni volta che l'app di assistenza accede al contesto, viene visualizzata una luce bianca intorno ai bordi dello schermo che soddisfa o supera la durata e la luminosità dell'implementazione del progetto open source Android.
  • Per l'app di assistenza preinstallata, fornire un'interfaccia utente a meno di due navigazioni di distanza dal menu delle impostazioni dell'app di assistenza e di input vocale predefinito e condividere il contesto solo quando l'app di assistenza viene richiamata esplicitamente dall'utente tramite una hotword o un input del tasto 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 notifiche di tipo toast

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

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

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

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

3.8.6. Temi

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

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

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

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

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

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

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

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

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

3.8.7. Sfondi animati

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

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

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

Se le implementazioni dei dispositivi implementano sfondi animati:

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

3.8.8. Passaggio da un'attività all'altra

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

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

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

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

3.8.9. Input Management

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

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

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

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

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

3.8.10. Controllo dei contenuti multimediali nella schermata di blocco

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

3.8.11. Salvaschermi (precedentemente chiamati Sogni)

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

3.8.12. Località

Se le implementazioni del dispositivo 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 all'interno delle Impostazioni.
• [C-1-3] NON DEVE mostrare le modalità di localizzazione nel menu Posizione all'interno delle Impostazioni.

3.8.13. Unicode e carattere

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

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

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

Se le implementazioni dei dispositivi includono un IME:

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

3.8.14. Multi-finestra

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

• [C-1-1] DEVE implementare una o più modalità multi-finestra in conformità con i comportamenti e le API dell'applicazione descritti nella documentazione sul 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 funzionare in modalità multi-finestra nel file AndroidManifest.xml, in modo esplicito impostando l'attributo android:resizeableActivity su true o implicitamente impostando targetSdkVersion > 24. Le app che impostano esplicitamente questo attributo su false nel proprio manifest NON DEVONO essere avviate in modalità multi-finestra. Le app meno recenti 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 indica che l'app potrebbe non funzionare come previsto in modalità multi-finestra.
• [C-1-3] NON DEVE offrire la modalità Split Screen o Freeform se l'altezza dello schermo è < 440 dp e la larghezza dello schermo è < 440 dp.
• Le implementazioni del dispositivo con dimensioni dello schermo xlarge DEVONO supportare la modalità a mano libera.

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

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

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

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

3.8.15. Ritaglio display

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

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

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

3.9. Amministrazione dispositivo

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

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

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

3.9.1 Provisioning dispositivo

3.9.1.1 Provisioning del proprietario del dispositivo

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

• [C-1-1] DEVE supportare la registrazione di un client Device Policy (DPC) come app Device Owner, come descritto di seguito:
  • Quando l'implementazione del dispositivo non ha ancora configurato i dati utente:
    • [C-1-3] DEVE segnalare true per DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] DEVE registrare l'applicazione DPC come app proprietario del dispositivo in risposta all'azione intent android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] DEVE registrare l'applicazione DPC come app proprietario del dispositivo se il dispositivo dichiara il supporto della tecnologia Near Field Communication (NFC) tramite il flag di funzionalità android.hardware.nfc e riceve un messaggio NFC contenente un record con tipo MIME MIME_TYPE_PROVISIONING_NFC.
  • Quando l'implementazione del dispositivo include dati utente:
    • [C-1-6] DEVE segnalare false per DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] NON deve più registrare alcuna applicazione DPC come app proprietario del dispositivo.
• [C-1-2] DEVE richiedere un'azione affermativa durante il processo di provisioning per acconsentire all'impostazione dell'app come proprietario del dispositivo. Il consenso può essere ottenuto tramite l'azione dell'utente o con mezzi programmatici durante il provisioning, ma NON deve essere codificato o impedire l'utilizzo di altre app proprietarie del dispositivo.

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

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

3.9.1.2 Provisioning dei profili gestiti

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

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

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

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

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

3.9.2 Supporto dei profili gestiti

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

3.9.3 Assistenza utenti gestiti

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

• [C-1-1] DEVE fornire un'agevolazione per l'utente per uscire dall'utente corrente e tornare all'utente principale nella sessione multiutente quando isLogoutEnabled restituisce true. L'interfaccia utente DEVE essere accessibile dalla schermata di blocco senza sbloccare il dispositivo.

3.10. Accessibilità

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

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

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

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

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

3.11. Text-to-Speech

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

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

• [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. Framework per l'ingresso TV

Il framework di input della televisione Android (TIF) semplifica la distribuzione di contenuti live ai dispositivi Android TV. TIF fornisce un'API standard per creare moduli di input che controllano i dispositivi Android Television.

Se le implementazioni dei dispositivi supportano TIF:

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

3.13. Impostazioni rapide

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

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

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

3.14. UI dei contenuti multimediali

Se le implementazioni del dispositivo includono il framework UI che supporta app di terze parti che dipendono da MediaBrowser e MediaSession , queste:

• [C-1-1] DEVE mostrare le icone MediaItem e le icone di notifica inalterate.
• [C-1-2] DEVE visualizzare questi elementi come descritto da MediaSession, ad esempio metadati, icone, immagini.
• [C-1-3] MUST show app title.
• [C-1-4] DEVE avere un riquadro a scomparsa o un altro meccanismo per presentare la gerarchia di MediaBrowser e fornire all'utente un invito per la gerarchia di MediaBrowser.
• [C-1-5] DEVE considerare il doppio tocco di KEYCODE_HEADSETHOOK o KEYCODE_MEDIA_PLAY_PAUSE come KEYCODE_MEDIA_NEXT per MediaSession.Callback#onMediaButtonEvent.

3.15. App istantanee

Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti:

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

3.16. Accoppiamento del dispositivo complementare

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

Se le implementazioni dei dispositivi supportano la funzionalità di accoppiamento di dispositivi complementari:

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

3.17. App pesanti

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

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

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

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

4. Compatibilità con il packaging delle applicazioni

Implementazioni dei dispositivi:

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

Implementazioni del dispositivo:

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

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

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

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

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

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

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

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

5. Compatibilità multimediale

Implementazioni del dispositivo:

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

Implementazioni del dispositivo:

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

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

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

5.1. Codec multimediali

5.1.1. Codifica audio

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

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

• [C-1-1] Profilo MPEG-4 AAC (AAC LC)
• [C-1-2] Profilo MPEG-4 HE AAC (AAC+)
• [C-1-3] Profilo MPEG-4 HE AACv2 (AAC+ avanzato)
• [C-1-4] AAC ELD (enhanced low delay AAC)
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, che include il profilo di baseline USAC e ISO/IEC 23003-4 Dynamic Range Control Profile)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE
• [C-1-10] Opus

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

• [C-2-1] La decodifica DEVE essere eseguita senza downmix (ad es. un flusso AAC 5.0 deve essere decodificato in cinque canali PCM, un flusso AAC 5.1 deve essere decodificato in sei canali PCM).
• [C-2-2] I metadati dell'intervallo dinamico DEVONO essere definiti in "Dynamic Range Control (DRC)" in ISO/IEC 14496-3 e le chiavi DRC android.media.MediaFormat per configurare i comportamenti correlati 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 relativi al volume e al DRC DEVONO essere interpretati e applicati in base al profilo di controllo della gamma dinamica MPEG-D DRC di livello 1.
• [C-3-2] Il decoder DEVE comportarsi in base alla configurazione impostata con i seguenti tasti android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_DRC_EFFECT_TYPE.

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

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

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

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

5.1.3. Dettagli sui codec audio

Formato/codec	Dettagli	Tipi di file/formati contenitore supportati
Profilo AAC MPEG-4 (AAC LC)	Supporto per contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC non elaborato ADTS (.aac, ADIF non supportato) MPEG-TS (.ts, non ricercabile)
Profilo MPEG-4 HE AAC (AAC+)	Supporto di contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.
Profilo MPEG-4 HE AACv2 (AAC+ avanzato)	Supporto di contenuti mono/stereo/5.0/5.1 con frequenze di campionamento standard da 16 a 48 kHz.
AAC ELD (enhanced low delay AAC)	Supporto di contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.
USAC	Supporto di contenuti mono/stereo con frequenze di campionamento standard da 7,35 a 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	Da 4,75 a 12,2 kbps campionati a 8 kHz	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 dithering applicato per 24 bit.	Solo FLAC (.flac)
MP3	Mono/Stereo 8-320 Kbps costante (CBR) o velocità in bit variabile (VBR)	MP3 (.mp3)
MIDI	MIDI di tipo 0 e 1. DLS versione 1 e 2. XMF e Mobile XMF. Supporto dei formati di suoneria RTTTL/RTX, OTA e iMelody	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		Ogg (.ogg) Matroska (.mkv, Android 4.0+)
PCM/WAVE	PCM lineare a 16 bit (frequenze fino al limite dell'hardware). I dispositivi DEVONO supportare frequenze di campionamento per la registrazione PCM non elaborata a 8000, 11025, 16000 e 44100 Hz.	WAVE (.wav)
Opus		Matroska (.mkv), Ogg(.ogg)

5.1.4. Codifica dell'immagine

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

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

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

5.1.5. Decodifica dell'immagine

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

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

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

5.1.6. Dettagli codec immagine

Formato/codec	Dettagli	Tipi di file/formati contenitore supportati
JPEG	Base+progressive	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Dati		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 sul web e di videoconferenza, le implementazioni dei dispositivi DEVONO utilizzare un codec VP8 hardware che soddisfi i requisiti.

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

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

• [C-1-2] I codificatori e decodificatori video DEVONO supportare 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 intra-frame tramite FEATURE_IntraRefresh nella classe MediaCodecInfo.CodecCapabilities,

• [C-3-1] DEVE supportare i periodi di aggiornamento nell'intervallo di 10-60 fotogrammi e funzionare con 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 ulteriori dettagli, consulta le sezioni 5.2 e 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, solo audio AAC, non ricercabile, Android 3.0+)
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 ulteriori 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 un codificatore video e lo rendono disponibile per le app di terze parti:

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

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H-264

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

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

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

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

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

5.2.3. VP8

Se le implementazioni dei dispositivi supportano il codec VP8:

• [C-1-1] DEVE supportare i profili di codifica video SD.
• DEVE supportare i seguenti profili di codifica video HD (alta definizione).
• DEVE supportare la scrittura di file Matroska WebM.
• DEVE 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 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 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:

• DEVE 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 cambio dinamico della risoluzione video e della frequenza fotogrammi tramite le API Android standard all'interno dello stesso stream per tutti i codec VP8, VP9, H.264 e H.265 in tempo reale e fino alla risoluzione massima supportata da ciascun codec sul dispositivo.

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

Se le implementazioni del dispositivo con decoder MPEG-4:

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

5.3.4. H.264

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

• [C-1-1] DEVE supportare il profilo principale di livello 3.1 e il profilo di 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 video con i profili SD (Standard Definition) elencati nella tabella seguente e codificati con il profilo di baseline e il profilo Main di livello 3.1 (incluso 720p30).
• DEVE essere in grado di decodificare i video con i profili HD (alta definizione) come indicato nella tabella seguente.

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

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

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p	UHD
Risoluzione video	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30/60 fps (60 fpsTelevisione con decodifica hardware H.265)	60 f/s
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 nella tabella seguente.
• DEVE utilizzare un codec VP8 hardware che soddisfi i requisiti.
• DEVE supportare i profili di decodifica HD nella tabella seguente.

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

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

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

5.3.7. VP9

Se le implementazioni dei dispositivi supportano il codec VP9:

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

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

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

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

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

	SD (bassa qualità)	SD (alta qualità)	HD 720p	HD 1080p	UHD
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps (60 fpsTV con decodifica hardware VP9)	60 f/s
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 SHOULD a partire da Android 4.3, è previsto che la Definizione di compatibilità per le versioni future li modifichi in MUST. È FORTEMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti elencati come SHOULD, altrimenti non potranno ottenere la compatibilità con Android quando verranno aggiornati alla versione futura.

5.4.1. Acquisizione audio raw

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] DEVE acquisire a frequenze di campionamento superiori senza upsampling.

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

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

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

Se le implementazioni del dispositivo consentono la radio AM e l'acquisizione di contenuti audio grezzi di qualità DVD:

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

5.4.2. Acquisizione per il riconoscimento vocale

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

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

Se le implementazioni dei dispositivi dichiarano android.hardware.microphone e tecnologie di eliminazione dei rumori ottimizzate per il riconoscimento vocale:

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

5.4.3. Acquisizione per il reindirizzamento della riproduzione

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

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

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

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

5.5. Riproduzione audio

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

5.5.1. Riproduzione audio grezzo

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, virgola mobile
  • Canali: mono, stereo, configurazioni multicanale valide con un massimo di 8 canali
  • Frequenze di campionamento (in Hz):
    • 8000, 11025, 16000, 22050, 32000, 44100, 48000 nelle configurazioni dei canali elencate sopra
    • 96000 in mono e stereo

• DOVREBBE consentire la riproduzione di contenuti audio grezzi 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 EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controllabili tramite le sottoclassi AudioEffect Equalizer, LoudnessEnhancer.
• [C-1-2] DEVE supportare l'implementazione dell'API visualizzatore, controllabile tramite la classe Visualizer.
• [C-1-3] DEVE supportare l'implementazione di EFFECT_TYPE_DYNAMICS_PROCESSING controllabile tramite la sottoclasse AudioEffect DynamicsProcessing.
• DEVE supportare le implementazioni EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controllabili tramite le sottoclassi AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.

5.5.3. Volume di uscita audio

Implementazioni di dispositivi per il settore automotive:

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

5.6. Latenza audio

La latenza audio è il ritardo 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 della presente sezione, utilizza le seguenti definizioni:

• latenza di output. L'intervallo tra il momento in cui un'applicazione scrive un frame di dati codificati in PCM e il momento in cui il suono corrispondente viene presentato all'ambiente in un trasduttore sul dispositivo o il segnale esce dal dispositivo tramite una porta e può essere osservato esternamente.
• Latenza di output a freddo. La latenza di output per il primo frame, quando il sistema di output audio è rimasto inattivo e spento prima della richiesta.
• latenza di output continua. La latenza di output per i frame successivi, dopo che il dispositivo riproduce l'audio.
• Latenza input. L'intervallo tra il momento in cui un suono viene presentato dall'ambiente al dispositivo in un trasduttore on-device o il momento in cui un segnale entra nel dispositivo tramite una porta e il momento in cui un'applicazione legge il frame corrispondente di dati codificati in PCM.
• input perso. La parte iniziale di un segnale di input inutilizzabile o non disponibile.
• Latenza di input a freddo. La somma del tempo di input perso e della latenza di input per il primo frame, quando il sistema di input audio è rimasto inattivo e spento prima della richiesta.
• Latenza input continua. La latenza di input per i frame successivi, mentre il dispositivo acquisisce l'audio.
• jitter dell'output 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 di latenza di input a freddo.
• latenza di andata e ritorno continua. La somma della latenza di input continua, della latenza di output continua e di un periodo di buffer. Il periodo di buffer consente all'app di elaborare il segnale e di mitigare la differenza di fase tra i flussi di input e output.
• API OpenSL ES coda di buffer PCM. Il set di API OpenSL ES correlate a PCM all'interno di Android NDK.
• API audio nativa AAudio. Il set di API AAudio all'interno di Android NDK.
• Timestamp. Una coppia costituita da una posizione relativa del frame all'interno di un flusso e dall'ora stimata in cui il frame entra o esce dalla pipeline di elaborazione audio sull'endpoint associato. Vedi anche AudioTimestamp.

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

• [C-SR] Latenza di output a freddo di 100 millisecondi o meno
• [C-SR] Latenza di output continua di 45 millisecondi o meno
• [C-SR] Minimize the cold output jitter
• [C-SR] Il timestamp di output restituito da AudioTrack.getTimestamp e AAudioStream_getTimestamp è preciso con un margine di errore di +/- 1 ms.

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

• [C-SR] VIVAMENTE CONSIGLIATO di segnalare l'audio a bassa latenza dichiarando il flag della funzionalità android.hardware.audio.low_latency.
• [C-SR] VIVAMENTE CONSIGLIATO per soddisfare i requisiti per l'audio a bassa latenza tramite l'API AAudio.
• [C-SR] VIVAMENTE CONSIGLIATO per garantire che per gli stream che restituiscono AAUDIO_PERFORMANCE_MODE_LOW_LATENCY da AAudioStream_getPerformanceMode(), il valore restituito da AAudioStream_getFramesPerBurst() sia 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 di buffer PCM OpenSL ES e le API audio native AAudio:

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

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

• [C-SR] Latenza di input a freddo di 100 millisecondi o meno.
• [C-SR] Latenza di input continua di 30 millisecondi o meno.
• [C-SR] Latenza di round trip continua pari o inferiore a 50 millisecondi.
• [C-SR] Minimizza il jitter dell'input a freddo.
• [C-SR] Limita l'errore nei timestamp di input, restituiti da AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 1 ms.

5.7. Protocolli di rete

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

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

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

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

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

Formati dei segmenti multimediali

Formati dei segmenti	Riferimento/i	Supporto codec richiesto
Stream di trasporto MPEG-2	ISO 13818	Codec video: H264 AVC MPEG-4 SP MPEG-2 Per informazioni dettagliate su H264 AVC, MPEG2-4 SP e MPEG-2,consulta la sezione 5.1.3. Codec audio: AAC Per informazioni dettagliate su AAC e sulle relative varianti, consulta la sezione 5.1.1.
AAC con framing ADTS e tag ID3	ISO 13818-7	Per maggiori dettagli su AAC e sulle relative varianti, consulta la sezione 5.1.1.
WebVTT	WebVTT

RTSP (RTP, SDP)

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

5.8. Secure Media

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

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

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

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

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

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

5.9. Musical Instrument Digital Interface (MIDI)

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

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

  • Modalità host USB, sezione 7.7
  • Modalità periferica USB, sezione 7.7
  • MIDI su Bluetooth LE che funge da ruolo centrale, sezione 7.4.3

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

5.10. Audio professionale

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

• [C-1-1] DEVE segnalare il supporto per la funzionalità android.hardware.audio.low_latency.
• [C-1-2] DEVE avere una latenza audio di andata e ritorno continua, come definita nella sezione 5.6 Latenza audio, DEVE essere pari o inferiore a 20 millisecondi e DOVREBBE essere pari o inferiore a 10 millisecondi su almeno un percorso supportato.
• [C-1-3] DEVE includere una o più porte USB che supportano la modalità host USB e la modalità periferica USB.
• [C-1-4] DEVE segnalare il supporto per la funzionalità android.software.midi.
• [C-1-5] DEVE soddisfare i requisiti di latenza e audio USB utilizzando sia la coda di buffer PCM OpenSL ES sia le API AAudio native audio.
• [SR] Sono FORTEMENTE CONSIGLIATI per fornire un livello coerente di prestazioni della CPU mentre l'audio è attivo e il carico della CPU varia. Questo deve essere testato utilizzando il commit 1bd6391 di SimpleSynth. L'app SimpleSynth deve essere eseguita con i parametri riportati di seguito e deve raggiungere zero underrun dopo 10 minuti:
  • Cicli di lavoro: 200.000
  • Carico variabile: ON (alterna il valore dei cicli di lavoro tra il 100% e il 10% ogni 2 secondi ed è progettato per testare il comportamento del governor della CPU)
  • Carico stabilizzato: OFF
• DOVREBBE ridurre al minimo l'imprecisione e la deriva dell'orologio audio rispetto all'ora standard.
• DOVREBBE ridurre al minimo la deriva dell'orologio audio rispetto alla CPU CLOCK_MONOTONIC quando entrambi sono attivi.
• DEVE ridurre al minimo la latenza audio sui trasduttori del dispositivo.
• DEVE ridurre al minimo la latenza audio tramite l'audio digitale USB.
• DEVE documentare le misurazioni della latenza audio in tutti i percorsi.
• DEVE ridurre al minimo il jitter nei tempi di inserimento del callback di completamento del buffer audio, in quanto ciò influisce sulla percentuale utilizzabile della larghezza di banda della CPU completa da parte del callback.
• DEVE fornire zero sottotensioni (uscita) o sovratensioni (ingresso) audio durante il normale utilizzo alla latenza segnalata.
• DEVE fornire una differenza di latenza tra i canali pari a zero.
• DEVE ridurre al minimo la latenza media MIDI su tutti i trasporti.
• DEVE ridurre al minimo la variabilità della latenza MIDI sotto carico (jitter) su tutti i trasporti.
• DEVE fornire timestamp MIDI accurati su tutti i trasporti.
• DOVREBBE ridurre al minimo il rumore del segnale audio sui trasduttori del dispositivo, incluso il periodo immediatamente successivo all'avvio a freddo.
• DEVE fornire una differenza di clock audio pari a zero tra i lati di input e output degli endpoint corrispondenti, quando entrambi sono attivi. Esempi di endpoint corrispondenti includono il microfono e l'altoparlante sul dispositivo o l'input e l'output del jack audio.
• DEVE gestire i callback di completamento del buffer audio per i lati di input e output degli endpoint corrispondenti sullo stesso thread quando entrambi sono attivi ed entrare nel callback di output immediatamente dopo il ritorno dal callback di input. Se non è possibile gestire i callback nello stesso thread, inserisci il callback di output subito dopo aver inserito il callback di input per consentire all'applicazione di avere una tempistica coerente dei lati di input e output.
• DEVE ridurre al minimo la differenza di fase tra il buffering audio HAL per i lati di input e output degli endpoint corrispondenti.
• DEVE ridurre al minimo la latenza del tocco.
• DEVE ridurre al minimo la variabilità della latenza del tocco sotto carico (jitter).
• DOVREBBE 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] VIVAMENTE CONSIGLIATO di segnalare il supporto per la 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:

• [C-2-1] DEVE avere una latenza audio continua di andata e ritorno pari o inferiore a 20 millisecondi sul percorso del jack audio.
• [SR] VIVAMENTE CONSIGLIATO di rispettare la sezione Specifiche del dispositivo mobile (jack) della specifica per le cuffie audio con cavo (v1.1).
• La latenza audio continua di andata e ritorno DOVREBBE essere pari o inferiore a 10 millisecondi sul 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] DEVE implementare la classe audio USB.
• [C-3-2] DEVE avere una latenza audio di round trip continua pari o inferiore a 20 millisecondi sulla porta in modalità host USB utilizzando la classe audio USB.
• La latenza audio continua nel tempo di round trip DOVREBBE essere pari o inferiore a 10 millisecondi sulla porta della modalità host USB utilizzando la classe audio USB.

Se le implementazioni dei dispositivi includono una porta HDMI:

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

5.11. Acquisizione per Non elaborato

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-2-1] DEVE restituire null per il metodo API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), per indicare correttamente la mancanza di supporto.
• [SR] are still STRONGLY RECOMMENDED to satisfy as many of the requirements for the signal path for the unprocessed recording source.

6. Compatibilità di strumenti e opzioni per sviluppatori

6.1. Strumenti per sviluppatori

Implementazioni del dispositivo:

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

• Android Debug Bridge (ADB)

  • [C-0-2] DEVE supportare adb come documentato nell'SDK Android e i comandi della shell forniti in AOSP, che possono essere utilizzati dagli sviluppatori di app, inclusi dumpsys 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 API di sistema StatsManager.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] Il daemon ADB lato dispositivo DEVE essere inattivo per impostazione predefinita e DEVE esistere un meccanismo accessibile all'utente per attivare Android Debug Bridge.
  • [C-0-5] DEVE supportare adb sicuro. Android include il supporto di adb sicuro. Secure adb consente adb su host autenticati noti.

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

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

• Dalvik Debug Monitor Service (DDMS)

  • [C-0-7] DEVE supportare tutte le funzionalità di ddms come documentato nell'SDK Android. Poiché ddms utilizza adb, il supporto di ddms DEVE essere inattivo per impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato Android Debug Bridge, come indicato sopra.
• Scimmia
  • [C-0-8] DEVE includere il framework Monkey e renderlo disponibile per l'utilizzo da parte delle applicazioni.
• SysTrace
  • [C-0-9] MUST support the systrace tool as documented in the Android SDK. 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 delle funzionalità android.hardware.vulkan.version:

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

6.2. Opzioni sviluppatore

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

Le implementazioni dei dispositivi DEVONO fornire un'esperienza coerente per le opzioni sviluppatore, ovvero:

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

7. Compatibilità hardware

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

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

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

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

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

7.1. Display e grafica

Android include funzionalità che regolano automaticamente gli asset delle applicazioni e i layout dell'interfaccia utente in modo appropriato per il dispositivo, per garantire che le applicazioni di terze parti funzionino correttamente su una varietà di configurazioni hardware. 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:

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

7.1.1. Configurazione dello schermo

7.1.1.1. Dimensioni e forma dello schermo

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

Implementazioni del dispositivo:

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

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

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

• POTREBBE avere un display con angoli arrotondati.

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

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

7.1.1.2. Proporzioni dello schermo

Sebbene non vi siano restrizioni al valore delle proporzioni dello schermo fisico, le proporzioni dello schermo logico in cui vengono visualizzate le app di terze parti, come si può dedurre 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 del dispositivo 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 rapporto di formato dello schermo più ampio tramite il valore dei metadati android.max_aspect.
  • L'app dichiara di essere ridimensionabile tramite l'attributo android:resizeableActivity.
  • L'app ha come target il livello API 24 o versioni successive e non dichiara un android:MaxAspectRatio che limiterebbe le proporzioni consentite.

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

7.1.1.3. Densità schermo

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

• [C-0-1] Per impostazione predefinita, le implementazioni del dispositivo DEVONO segnalare solo una delle seguenti densità logiche del framework Android 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 di visualizzazione) impostate dopo l'avvio iniziale.

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

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

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

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

7.1.2. Metriche display

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

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

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

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

7.1.3. Orientamento schermo

Implementazioni del dispositivo:

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

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

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

7.1.4. Accelerazione grafica 2D e 3D

7.1.4.1 OpenGL ES

Implementazioni del dispositivo:

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

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

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

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

• [C-2-1] DEVE segnalare tramite le API gestite OpenGL ES e le API native qualsiasi altra estensione OpenGL ES che ha implementato e, viceversa, NON DEVE segnalare stringhe di estensione che non supporta.
• [C-2-2] DEVE supportare le estensioni EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage e EGL_ANDROID_recordable.
• [SR] sono FORTEMENTE CONSIGLIATI per 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 dei dispositivi dichiarano il supporto di OpenGL ES 3.0, 3.1 o 3.2:

• [C-3-1] MUST export the corresponding function symbols for these version in addition to the OpenGL ES 2.0 function symbols in the libGLESv2.so library.

Se le implementazioni dei dispositivi supportano OpenGL ES 3.2:

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

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

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

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

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

7.1.4.2 Vulkan

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

Se le implementazioni dei dispositivi supportano OpenGL ES 3.1:

• [SR] È VIVAMENTE CONSIGLIATO includere il supporto di Vulkan 1.1.

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

• DOVREBBE includere il supporto di Vulkan 1.1.

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

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

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

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

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

• [C-3-1] MUST expose support for the SYNC_FD external semaphore and handle types.
• [SR] Are STRONGLY RECOMMENDED to support the VK_ANDROID_external_memory_android_hardware_buffer extension.

7.1.4.3 RenderScript

• [C-0-1] Le implementazioni del dispositivo DEVONO supportare Android RenderScript, come descritto nella documentazione dell'SDK Android.

7.1.4.4 Accelerazione grafica 2D

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

Implementazioni del dispositivo:

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

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

Implementazioni del dispositivo:

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

7.1.4.5 Display con ampia gamma cromatica

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

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

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

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

7.1.5. Modalità di compatibilità con le applicazioni legacy

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

7.1.6. Tecnologia dello schermo

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

Implementazioni del dispositivo:

• [C-0-1] MUST support displays capable of rendering 16-bit color graphics.
• DEVE supportare display in grado di visualizzare grafica a 24 bit.
• [C-0-2] DEVE supportare i display in grado di eseguire il rendering delle animazioni.
• [C-0-3] DEVE utilizzare la tecnologia di visualizzazione con proporzioni pixel (PAR) comprese tra 0,9 e 1,15. ovvero le proporzioni pixel DEVONO essere quasi quadrate (1.0) con una tolleranza del 10-15%.

7.1.7. Display secondari

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

Se le implementazioni dei dispositivi supportano un display esterno tramite una connessione cablata, wireless o un'ulteriore connessione display incorporata:

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

7.2. Dispositivi di immissione

Implementazioni del dispositivo:

• [C-0-1] DEVE includere un meccanismo di input, ad esempio un touchscreen o una navigazione non touch, per spostarsi tra gli elementi della UI.

7.2.1. Tastiera

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

• [C-1-1] DEVE dichiarare il flag funzionalità android.software.input_methods.
• [C-1-2] MUST implement fully Input Management Framework
• [C-1-3] DEVE avere una tastiera su schermo 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). * DOVREBBE includere implementazioni aggiuntive della tastiera virtuale. * POTREBBE includere una tastiera hardware.

7.2.2. Navigazione non touch

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

Implementazioni del dispositivo:

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

Se le implementazioni dei dispositivi non prevedono navigazioni non touch:

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

7.2.3. Tasti di navigazione

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

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

Se vengono fornite le funzioni Home, Recenti o Indietro:

• [C-1-1] DEVE essere accessibile con una singola azione (ad es. tocco, doppio clic o gesto) quando una qualsiasi di queste azioni è accessibile.
• [C-1-2] DEVE fornire un'indicazione chiara di quale singola azione attiverebbe ogni funzione. Un'indicazione di questo tipo può essere un'icona visibile impressa sul pulsante, un'icona software nella parte della barra di navigazione dello schermo o una demo guidata passo passo durante la configurazione iniziale.

Implementazioni del dispositivo:

• [SR] è FORTEMENTE CONSIGLIATO di non fornire il meccanismo di input per la funzione Menu, in quanto è deprecata a favore della barra delle azioni a partire da Android 4.0.

Se le implementazioni del dispositivo forniscono la funzione Menu:

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

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

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

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

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

7.2.4. Input touchscreen

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

Implementazioni del dispositivo:

• DEVE avere un sistema di input del puntatore di qualche tipo (simile al mouse o al tocco).
• DEVE supportare puntatori tracciati in modo completamente indipendente.

Se le implementazioni dei dispositivi includono un touchscreen (single-touch o superiore):

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

Se le implementazioni dei dispositivi includono un touchscreen in grado di tracciare più di un tocco,

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

Se le implementazioni del dispositivo non includono un touchscreen (e si basano solo su un dispositivo di puntamento) e soddisfano i requisiti di tocco simulato nella sezione 7.2.5,

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

7.2.5. Input tocco simulato

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

Se le implementazioni del dispositivo non includono un touchscreen, ma includono un altro sistema di input del puntatore che vogliono rendere disponibile:

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

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

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

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

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

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

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

7.2.6. Supporto del controller di gioco

7.2.6.1. Mappature dei pulsanti

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

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

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

1 KeyEvent

2 Gli utilizzi HID precedenti devono essere dichiarati all'interno di una CA Gamepad (0x01 0x0005).

3 Questo utilizzo deve avere un minimo logico di 0, un massimo logico di 7, un minimo fisico di 0, un massimo fisico di 315, unità in gradi e una dimensione report di 4. Il valore logico è definito come la rotazione in senso orario rispetto all'asse verticale. Ad esempio, un valore logico pari a 0 non rappresenta alcuna rotazione e indica la pressione del tasto Su, mentre un valore logico pari a 1 rappresenta una rotazione di 45 gradi e la pressione dei tasti Su e Sinistra.

4 MotionEvent

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

1 MotionEvent

7.2.7. Telecomando

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

7.3. Sensori

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

Implementazioni del dispositivo:

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

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

• [C-1-1] DEVE segnalare tutte le misurazioni dei sensori utilizzando i valori pertinenti del Sistema internazionale di unità di misura (metrico) per ogni tipo di sensore, come definito nella documentazione dell'SDK Android.
• [C-1-2] DEVE segnalare i dati dei sensori con una latenza massima di 100 millisecondi + 2 * sample_time per il caso di un sensore trasmesso in streaming con una latenza minima richiesta di 5 ms + 2 * sample_time quando il processore dell'applicazione è attivo. Questo ritardo non include eventuali ritardi di filtraggio.
• [C-1-3] DEVE segnalare il primo campione del sensore entro 400 millisecondi + 2 * sample_time dall'attivazione del sensore. È accettabile che questo campione abbia una precisione pari a 0.

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

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

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

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

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

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

Implementazioni del dispositivo:

• DOVREBBE implementare questi tipi di sensori, quando includono i sensori fisici prerequisiti descritti in Tipi di sensori.

Se le implementazioni dei dispositivi includono un sensore composito:

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

7.3.1. Accelerometro

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

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

• [C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
• [C-1-2] DEVE implementare e segnalare il sensore TYPE_ACCELEROMETER.
• [C-1-3] DEVE rispettare il sistema di coordinate 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 per asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più rapida.
• [SR] è FORTEMENTE CONSIGLIATO implementare il sensore composito TYPE_SIGNIFICANT_MOTION.
• [SR] è FORTEMENTE CONSIGLIATO di implementare il sensore TYPE_ACCELEROMETER_UNCALIBRATED se è disponibile la calibrazione dell'accelerometro online.
• DEVE implementare i sensori compositi TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER come descritto nel documento dell'SDK Android.
• DEVE segnalare eventi fino ad almeno 200 Hz.
• DOVREBBE avere una risoluzione di almeno 16 bit.
• DEVE essere calibrato durante l'uso se le caratteristiche cambiano durante il ciclo di vita e compensato e conservare i parametri di compensazione tra i riavvii del dispositivo.
• DEVE essere compensato in base alla temperatura.
• DOVREBBE implementare anche il sensore TYPE_ACCELEROMETER_UNCALIBRATED.

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

• [C-2-1] La somma del loro consumo energetico DEVE sempre essere inferiore a 4 mW.
• DOVREBBE essere inferiore a 2 mW e 0,5 mW quando il dispositivo si trova in una condizione dinamica o statica.

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

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

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

• [C-4-1] DEVE 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 dei dispositivi includono un magnetometro a 3 assi:

• [C-1-1] DEVE implementare il sensore TYPE_MAGNETIC_FIELD.
• [C-1-2] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 10 Hz e DOVREBBE segnalare eventi fino ad almeno 50 Hz.
• [C-1-3] DEVE rispettare il sistema di coordinate 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 di saturarsi.
• [C-1-5] DEVE avere un valore di compensazione del ferro duro inferiore a 700 µT e DOVREBBE avere un valore inferiore a 200 µT posizionando il magnetometro lontano da campi magnetici dinamici (indotti dalla corrente) e statici (indotti dal magnete).
• [C-1-6] DEVE avere una risoluzione uguale o più densa di 0,6 µT.
• [C-1-7] DEVE supportare la calibrazione e la compensazione online della distorsione del ferro duro e conservare i parametri di compensazione tra i riavvii del dispositivo.
• [C-1-8] DEVE essere applicata la compensazione del ferro dolce. La calibrazione può essere eseguita durante l'uso o la produzione del dispositivo.
• [C-1-9] DEVE avere una deviazione standard, calcolata per asse sui campioni raccolti per un periodo di almeno 3 secondi alla frequenza di campionamento più rapida, non superiore a 1,5 µT; DOVREBBE avere una deviazione standard non superiore a 0,5 µT.
• DEVE implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] È VIVAMENTE CONSIGLIATO di implementare il sensore TYPE_MAGNETIC_FIELD_UNCALIBRATED sui dispositivi Android nuovi ed esistenti.

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

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

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

• MAY implement the TYPE_GEOMAGNETIC_ROTATION_VECTOR sensor.

Se le implementazioni dei dispositivi includono un magnetometro a 3 assi, un accelerometro e un sensore TYPE_GEOMAGNETIC_ROTATION_VECTOR:

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

7.3.3. GPS

Implementazioni del dispositivo:

• DEVE includere un ricevitore GPS/GNSS.

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

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

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

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

Se le implementazioni del dispositivo includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag di funzionalità android.hardware.location.gps e l'API di test LocationManager.getGnssYearOfHardware() segnala l'anno "2016" o successivo,

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

Se le implementazioni del dispositivo 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() segnala l'anno "2017" o successivo,

• [C-3-1] DEVE continuare a fornire i 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 riportato nei messaggi GnssStatus), ad eccezione di SBAS.
• [C-3-3] DEVE segnalare il controllo automatico del guadagno e la frequenza di misurazione GNSS.
• [C-3-4] DEVE segnalare tutte le stime di accuratezza (inclusi orientamento, velocità e verticale) nell'ambito di ogni posizione GPS/GNSS.

Se le implementazioni del dispositivo includono un ricevitore GPS/GNSS e segnalano la funzionalità alle applicazioni tramite il flag di funzionalità android.hardware.location.gps e l'API di test LocationManager.getGnssYearOfHardware() segnala l'anno "2018" o successivo, queste:

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

7.3.4. Giroscopio

Implementazioni del dispositivo:

• 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 dei dispositivi includono un giroscopio:

• [C-1-1] DEVE essere in grado di segnalare eventi fino a una frequenza di almeno 50 Hz.
• [C-1-2] DEVE implementare il sensore TYPE_GYROSCOPE e DOVREBBE implementare anche il sensore TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-3] DEVE essere in grado di misurare i cambiamenti 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 temperatura.
• [C-1-6] DEVE essere calibrato e compensato durante l'uso e conservare i parametri di compensazione tra i riavvii del dispositivo.
• [C-1-7] DEVE avere una varianza non superiore a 1e-7 rad^2 / s^2 per Hz (varianza per Hz o rad^2 / s). La varianza può variare in base alla frequenza di campionamento, ma DEVE essere vincolata da questo valore. In altre parole, se misuri la varianza del giroscopio a una frequenza di campionamento di 1 Hz, NON DEVE essere superiore a 1e-7 rad^2/s^2.
• [SR] È VIVAMENTE CONSIGLIATO di implementare il sensore SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sui dispositivi Android nuovi ed esistenti.
• [SR] Si CONSIGLIA VIVAMENTE che l'errore di calibrazione sia inferiore a 0,01 rad/s quando il dispositivo è fermo a temperatura ambiente.
• DEVE segnalare eventi fino ad almeno 200 Hz.

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

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

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

• [C-3-1] DEVE implementare i sensori compositi TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [SR] È VIVAMENTE CONSIGLIATO di implementare il sensore TYPE_GAME_ROTATION_VECTOR sui dispositivi Android nuovi ed esistenti.
• 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] DEVE implementare e segnalare il sensore TYPE_PRESSURE.
• [C-1-2] DEVE essere in grado di fornire eventi a 5 Hz o superiore.
• [C-1-3] DEVE essere compensato in temperatura.
• [SR] VIVAMENTE CONSIGLIATO per poter segnalare misurazioni della pressione nell'intervallo compreso tra 300 hPa e 1100 hPa.
• DOVREBBE avere una precisione assoluta di 1 hPa.
• DOVREBBE avere una precisione relativa di 0,12 hPa in un intervallo di 20 hPa (equivalente a una precisione di circa 1 m in una variazione di circa 200 m a livello del mare).

7.3.6. Termometro

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

Se le implementazioni dei dispositivi includono un termometro ambientale (sensore di temperatura):

• [C-1-1] DEVE essere definito come SENSOR_TYPE_AMBIENT_TEMPERATURE e DEVE misurare la temperatura ambiente (stanza/abitacolo del veicolo) da dove l'utente interagisce con il dispositivo in gradi Celsius.
• [C-1-2] MUST be defined as SENSOR_TYPE_TEMPERATURE.
• [C-1-3] DEVE misurare la temperatura della CPU del dispositivo.
• [C-1-4] NON DEVE misurare altre temperature.

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

7.3.7. Fotometro

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

7.3.8. Sensore di prossimità

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

Se le implementazioni dei dispositivi includono un sensore di prossimità:

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

7.3.9. Sensori ad alta fedeltà

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

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

Se le implementazioni 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 di 12,5 Hz o inferiore.
  • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DOVREBBE supportare SensorDirectChannel RATE_VERY_FAST.
  • DEVE avere un rumore di misurazione non superiore a 400 μg/√Hz.
  • DEVE implementare una forma non di riattivazione di questo sensore con una capacità di buffering di almeno 3000 eventi del sensore.
  • DEVE avere un consumo energetico di batching non superiore a 3 mW.
  • [C-SR] È VIVAMENTE 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 di accelerazione inferiore a 30 μg √Hz testata a temperatura ambiente.
  • DOVREBBE avere una variazione della distorsione rispetto alla temperatura di ≤ +/- 1 mg/°C.
  • DOVREBBE avere una non linearità della linea di migliore adattamento ≤ 0,5% e una variazione della sensibilità rispetto alla temperatura ≤ 0,03%/°C.
  • DOVREBBE avere una sensibilità all'asse trasversale < 2,5 % e una variazione della sensibilità all'asse trasversale < 0,2% nell'intervallo di temperatura di funzionamento del dispositivo.

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

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

  • DEVE avere un intervallo di misurazione compreso tra almeno -1000 e +1000 dps.
  • DEVE avere una risoluzione di misurazione di almeno 16 LSB/dps.
  • DEVE avere una frequenza di misurazione minima di 12,5 Hz o inferiore.
  • DEVE avere una frequenza di misurazione massima di 400 Hz o superiore; DOVREBBE supportare SensorDirectChannel RATE_VERY_FAST.
  • DEVE avere un rumore di misurazione non superiore a 0,014°/s/√Hz.
  • [C-SR] È VIVAMENTE 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 della velocità inferiore a 0,001 °/s √Hz testata a temperatura ambiente.
  • DOVREBBE avere una variazione di polarizzazione rispetto alla temperatura ≤ +/- 0,05 °/ s / °C.
  • DOVREBBE avere una variazione di sensibilità rispetto alla temperatura ≤ 0,02% / °C.
  • DEVE avere una non linearità della linea di miglior adattamento ≤ 0,2%.
  • DEVE avere una densità di rumore ≤ 0,007 °/s/√Hz.
  • DOVREBBE avere un errore di calibrazione inferiore a 0,002 rad/s nell'intervallo di temperatura 10 ~ 40 °C quando il dispositivo è fermo.
  • DEVE avere una sensibilità all'accelerazione inferiore a 0,1 °/s/g.
  • DEVE avere una sensibilità all'asse trasversale < 4,0 % e una variazione della sensibilità all'asse trasversale < 0,3% nell'intervallo di temperatura di funzionamento del dispositivo.

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

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

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

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

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

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

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

Tieni presente che tutti i requisiti di consumo energetico in questa sezione non includono il consumo energetico del processore dell'applicazione. Include la potenza assorbita dall'intera catena di sensori: il sensore, qualsiasi circuito di supporto, qualsiasi sistema di elaborazione dei sensori dedicato e così via.

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

• [C-3-1] DEVE dichiarare correttamente il supporto dei tipi di canali diretti e del livello di tassi di 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
• DEVE supportare la generazione di report sugli eventi tramite il canale diretto del sensore per il sensore principale (variante non di riattivazione) dei seguenti tipi:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensori biometrici

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 digitali e lo rendono disponibile per app di terze parti:

• [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 errata non superiore allo 0,002%.
• [SR] Are STRONGLY RECOMMENDED to have a spoof and imposter acceptance rate not higher than 7%.
• [C-1-4] DEVE comunicare che questa modalità potrebbe essere meno sicura di una sequenza, un PIN o una password efficaci ed elencare chiaramente i rischi della sua attivazione, se i tassi di accettazione di spoofing e impersonificazione sono superiori al 7%.
• [C-1-5] MUST rate limit attempts for at least 30 seconds after five false trials for fingerprint verification.
• [C-1-6] DEVE avere un'implementazione di keystore supportata dall'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 identificabili delle impronte criptati e autenticati crittograficamente 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 di Android Open Source Project.
• [C-1-8] DEVE impedire l'aggiunta di un'impronta senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare le credenziali del dispositivo esistenti o di aggiungerne di nuove (PIN/sequenza/password) protette da TEE. L'implementazione di Android Open Source Project fornisce il meccanismo nel framework per farlo.
• [C-1-9] NON DEVE consentire alle applicazioni di terze parti di distinguere tra le singole impronte.
• [C-1-10] DEVE rispettare il flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• [C-1-11] DEVE, in caso di upgrade da una versione precedente ad Android 6.0, eseguire la migrazione sicura dei dati dell'impronta per soddisfare i requisiti di cui sopra o rimuoverli.
• [C-1-12] DEVE rimuovere completamente tutti i dati identificabili delle impronte digitali di un utente quando il suo account viene rimosso (anche tramite un ripristino dei dati di fabbrica).
• [C-1-13] NON DEVE consentire l'accesso non criptato al processore dell'applicazione a dati di impronte identificabili o a dati da essi derivati (ad esempio incorporamenti).
• [SR] Sono FORTEMENTE CONSIGLIATI per avere un tasso di falso rifiuto inferiore al 10%, misurato sul dispositivo.
• [SR] È VIVAMENTE CONSIGLIATO che abbiano una latenza inferiore a 1 secondo, misurata dal momento in cui viene toccato il sensore di impronte digitali fino allo sblocco dello schermo, per un dito registrato.
• DEVE utilizzare l'icona dell'impronta di Android fornita in Android Open Source Project.

7.3.10.2. Altri sensori biometrici

Se le implementazioni dei dispositivi includono uno o più sensori biometrici non basati sull'impronta e li rendono disponibili ad app di terze parti:

• [C-1-1] DEVE avere un tasso di falsa accettazione non superiore allo 0,002%.
• [C-SR] È VIVAMENTE CONSIGLIATO di avere un tasso di accettazione di spoofing e impersonificazione non superiore al 7%.
• [C-1-2] DEVE comunicare che questa modalità potrebbe essere meno sicura di una sequenza, un PIN o una password efficaci ed elencare chiaramente i rischi della sua attivazione, se i tassi di accettazione di spoofing e impostori sono superiori al 7%.
• [C-1-3] I tentativi di limitazione della velocità DEVONO essere eseguiti per almeno 30 secondi dopo cinque tentativi errati di verifica biometrica, dove un tentativo errato è uno con una qualità di acquisizione adeguata (ACQUISITO_BUONO) che non corrisponde a una biometria registrata
• [C-1-4] DEVE avere un'implementazione di un keystore con crittografia 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 in modo crittografico 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 Android Open Source.
• [C-1-6] DEVE impedire l'aggiunta di nuove biometrie senza prima stabilire una catena di attendibilità chiedendo all'utente di confermare le credenziali del dispositivo esistenti o di aggiungerne di nuove (PIN/sequenza/password) protette da TEE. L'implementazione di Android Open Source Project fornisce il meccanismo nel framework per farlo.
• [C-1-7] NON DEVE consentire ad applicazioni di terze parti di distinguere tra le registrazioni biometriche.
• [C-1-8] DEVE rispettare il flag individuale per quella biometria (ad es. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE o DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-9] DEVE rimuovere completamente tutti i dati biometrici identificabili di un utente quando il suo account viene rimosso (anche tramite un ripristino dei dati di fabbrica).
• [C-1-10] NON DEVE consentire l'accesso non criptato a dati biometrici identificabili o a qualsiasi dato da essi derivato (ad esempio incorporamenti) al processore dell'applicazione al di fuori del contesto del TEE.
• [C-SR] Sono FORTEMENTE CONSIGLIATI per avere un tasso di falsi rifiuti inferiore al 10%, misurato sul dispositivo.
• [C-SR] È VIVAMENTE CONSIGLIATO che abbiano una latenza inferiore a 1 secondo, misurata dal momento in cui viene rilevata la biometria fino allo sblocco dello schermo, per ogni biometria registrata.

7.3.11. Sensori solo per Android Automotive

I sensori specifici per l'automotive sono definiti in android.car.CarSensorManager API.

7.3.11.1. Current Gear

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 postura

Implementazioni del dispositivo:

• POTREBBE supportare il sensore di postura con 6 gradi di libertà.

Se le implementazioni dei dispositivi supportano il sensore di postura con 6 gradi di libertà:

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

7.4. Connettività dei dati

7.4.1. Telefonia

Il termine "telefonia" utilizzato dalle API Android e in questo documento si riferisce in modo specifico all'hardware correlato all'effettuazione di chiamate vocali e all'invio di messaggi SMS tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano o meno essere a commutazione di pacchetto, ai fini di Android sono considerate indipendenti da qualsiasi connettività dati che possa essere implementata utilizzando la stessa rete. In altre parole, le funzionalità e le API "telefonia" di Android si riferiscono specificamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni di dispositivi che non possono effettuare chiamate o inviare/ricevere SMS non sono considerate dispositivi di telefonia, indipendentemente dal fatto che utilizzino una rete cellulare per la connettività dati.

• Android PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. ovvero Android è compatibile con dispositivi diversi dagli smartphone.

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

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

Se le implementazioni dei dispositivi non includono hardware di telefonia:

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

7.4.1.1. Compatibilità con il blocco dei numeri

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

• [C-1-1] DEVE includere il supporto per il blocco dei numeri
• [C-1-2] DEVE implementare completamente BlockedNumberContract e l'API corrispondente come descritto nella documentazione dell'SDK.
• [C-1-3] DEVE bloccare tutte le chiamate e i messaggi provenienti da un numero di telefono in "BlockedNumberProvider" senza alcuna interazione con le app. L'unica eccezione si verifica quando il blocco dei numeri viene temporaneamente rimosso, come descritto nella documentazione dell'SDK.
• [C-1-4] NON DEVE scrivere nel provider del registro chiamate della piattaforma per una chiamata bloccata.
• [C-1-5] NON DEVE scrivere al provider di telefonia per un messaggio bloccato.
• [C-1-6] DEVE implementare un'UI di gestione dei numeri bloccati, che viene aperta con l'intent restituito dal metodo TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] NON DEVE consentire agli utenti secondari di visualizzare o modificare i numeri bloccati sul dispositivo, in quanto la piattaforma Android presuppone che l'utente principale abbia il controllo completo dei servizi di telefonia, una singola istanza, sul dispositivo. Tutta l'interfaccia utente relativa al blocco DEVE essere nascosta agli utenti secondari e l'elenco bloccati DEVE comunque essere rispettato.
• DOVREBBE eseguire la migrazione dei numeri bloccati nel provider quando un dispositivo viene aggiornato ad Android 7.0.

7.4.1.2. API Telecom

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

• [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 attesa specificata tramite CAPABILITY_SUPPORT_HOLD.

• [C-SR] È FORTEMENTE CONSIGLIATO notificare all'utente che rispondere a una chiamata in arrivo interromperà una chiamata in corso.

  L'implementazione AOSP soddisfa questi requisiti tramite una notifica in evidenza che indica all'utente che se risponde a una chiamata in arrivo, l'altra chiamata verrà interrotta.

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

• [C-SR] È VIVAMENTE CONSIGLIATO di gestire gli eventi KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK delle cuffie audio per le API android.telecom come indicato di seguito:
  • Chiama Connection.onDisconnect() quando viene rilevata una pressione breve dell'evento chiave durante una chiamata in corso.
  • Chiama Connection.onAnswer() quando viene rilevata una pressione breve dell'evento chiave durante una chiamata in arrivo.
  • Chiama Connection.onReject() quando viene rilevata una pressione prolungata dell'evento chiave durante una chiamata in arrivo.
  • Attiva/disattiva lo stato di disattivazione dell'audio di CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementazioni del dispositivo:

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

Se le implementazioni del dispositivo includono il supporto di 802.11 ed espongono la funzionalità a un'applicazione di terze parti:

• [C-1-1] DEVE implementare l'API Android corrispondente.
• [C-1-2] DEVE segnalare il flag della funzionalità hardware android.hardware.wifi.
• [C-1-3] DEVE implementare l'API multicast come descritto nella documentazione dell'SDK.
• [C-1-4] DEVE supportare il DNS multicast (mDNS) e NON DEVE filtrare i pacchetti mDNS (224.0.0.251) in qualsiasi momento del funzionamento, tra cui:
  • Anche quando lo schermo non è in stato attivo.
  • Per le implementazioni di dispositivi Android Television, anche in modalità di alimentazione in standby.
• [C-1-5] NON DEVE considerare la chiamata al metodo API WifiManager.enableNetwork() come indicazione sufficiente per cambiare l'Network attualmente attivo, utilizzato per impostazione predefinita per il traffico dell'applicazione e restituito dai metodi API ConnectivityManager come getActiveNetwork e registerDefaultNetworkCallback. In altre parole, POSSONO disattivare l'accesso a internet fornito da qualsiasi altro operatore di rete (ad es. dati mobili) solo se verificano correttamente che la rete Wi-Fi fornisce l'accesso a internet.
• [C-SR] Sono FORTEMENTE CONSIGLIATI, quando viene chiamato il metodo API ConnectivityManager.reportNetworkConnectivity(), per rivalutare l'accesso a internet su Network e, una volta che la valutazione determina che l'attuale Network non fornisce più l'accesso a internet, passare a qualsiasi altra rete disponibile (ad es. dati mobili) che fornisca l'accesso a internet.
• [C-SR] È FORTEMENTE CONSIGLIATO di randomizzare l'indirizzo MAC di origine e il numero di sequenza dei frame di richiesta di probe, una volta all'inizio di ogni scansione, mentre la STA è disconnessa.
  • Ogni gruppo di frame di richiesta di probe che comprende una scansione deve utilizzare un indirizzo MAC coerente (NON deve randomizzare l'indirizzo MAC a metà scansione).
  • Il numero di sequenza della richiesta di probe deve essere iterato normalmente (in sequenza) tra le richieste di probe in una scansione.
  • Il numero di sequenza della richiesta di probe deve essere randomizzato tra l'ultima richiesta di probe di una scansione e la prima richiesta di probe della scansione successiva.
• [C-SR] Sono FORTEMENTE CONSIGLIATI, mentre STA è disconnesso, per consentire solo i seguenti elementi nei frame delle richieste di probe:
  • Set di parametri SSID (0)
  • Set di parametri DS (3)

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

• [C-2-1] DEVE fornire un'interfaccia utente per attivare/disattivare la lettura del valore tramite il metodo API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementazioni del dispositivo:

• DEVE includere il supporto per Wi-Fi Direct (Wi-Fi peer-to-peer).

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

• [C-1-1] DEVE implementare l'API Android corrispondente come descritto nella documentazione dell'SDK.
• [C-1-2] DEVE segnalare la funzionalità hardware android.hardware.wifi.direct.
• [C-1-3] DEVE supportare il normale funzionamento del Wi-Fi.
• [C-1-4] DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Direct.

7.4.2.2. Configurazione di Wi-Fi Tunneled Direct Link

Implementazioni del dispositivo:

• DEVE includere il supporto per la configurazione del collegamento diretto con tunneling 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,

• [C-1-1] DEVE dichiarare il supporto di TDLS tramite WifiManager.isTdlsSupported.
• DEVE utilizzare TDLS solo quando è possibile E vantaggioso.
• DOVREBBE utilizzare alcune euristiche e NON utilizzare TDLS quando le sue prestazioni potrebbero essere peggiori rispetto a quelle del punto d'accesso Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementazioni del dispositivo:

• DEVE includere il supporto per Wi-Fi Aware.

Se le implementazioni del dispositivo includono il supporto di Wi-Fi Aware ed espongono la funzionalità ad app di terze parti, allora:

• [C-1-1] DEVE implementare le API WifiAwareManager come descritto nella documentazione dell'SDK.
• [C-1-2] DEVE dichiarare il flag funzionalità android.hardware.wifi.aware.
• [C-1-3] DEVE supportare contemporaneamente le operazioni Wi-Fi e Wi-Fi Aware.
• [C-1-4] DEVE randomizzare l'indirizzo dell'interfaccia di gestione Wi-Fi Aware a intervalli non superiori a 30 minuti e ogni volta che Wi-Fi Aware è abilitato.

Se le implementazioni dei dispositivi includono il supporto di Wi-Fi Aware e della posizione Wi-Fi come descritto nella Sezione 7.4.2.5 ed espongono queste funzionalità ad app di terze parti, allora:

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

• DEVE includere il supporto per Wi-Fi Passpoint.

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

• [C-1-1] DEVE implementare le API WifiManager correlate a Passpoint come descritto nella documentazione dell'SDK.
• [C-1-2] DEVE supportare lo standard IEEE 802.11u, in particolare per quanto riguarda l'individuazione e la selezione della rete, ad esempio il servizio di pubblicità generica (GAS) e il protocollo di query della rete di accesso (ANQP).

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

• [C-2-1] L'implementazione delle API WifiManager correlate a Passpoint DEVE generare un UnsupportedOperationException.

7.4.2.5. Posizione Wi-Fi (tempo di round trip - RTT - del Wi-Fi)

Implementazioni del dispositivo:

• DEVE includere il supporto per la posizione Wi-Fi.

Se le implementazioni del dispositivo includono il supporto della posizione Wi-Fi ed espongono la funzionalità ad app di terze parti, allora:

• [C-1-1] DEVE implementare le API WifiRttManager come descritto nella documentazione dell'SDK.
• [C-1-2] DEVE dichiarare il flag funzionalità android.hardware.wifi.rtt.
• [C-1-3] DEVE randomizzare l'indirizzo MAC di origine per ogni burst RTT eseguito mentre l'interfaccia Wi-Fi su cui viene eseguito l'RTT non è associata a un punto di accesso.

7.4.3. Bluetooth

Se le implementazioni dei dispositivi supportano il profilo audio Bluetooth:

• DEVE supportare i codec audio avanzati e i codec audio Bluetooth (ad es. LDAC).

Se le implementazioni dei dispositivi supportano HFP, A2DP e AVRCP:

• DEVE supportare almeno 5 dispositivi connessi in totale.

Se le implementazioni del dispositivo dichiarano la funzionalità android.hardware.vr.high_performance:

• [C-1-1] DEVE supportare Bluetooth 4.2 e l'estensione della lunghezza dei dati Bluetooth LE.

Android supporta Bluetooth e Bluetooth Low Energy.

Se le implementazioni dei dispositivi includono il supporto di Bluetooth e Bluetooth Low Energy:

• [C-2-1] DEVE dichiarare le funzionalità della piattaforma pertinenti (android.hardware.bluetooth e android.hardware.bluetooth_le rispettivamente) e implementare le API della piattaforma.
• DEVE implementare profili Bluetooth pertinenti come A2DP, AVRCP, OBEX, HFP e così via, a seconda del dispositivo.

Se le implementazioni dei dispositivi includono il supporto di Bluetooth Low Energy, devono:

• [C-3-1] DEVE dichiarare la funzionalità hardware android.hardware.bluetooth_le.
• [C-3-2] DEVE abilitare le API Bluetooth basate su GATT (generic attribute profile) come descritto nella documentazione dell'SDK e in android.bluetooth.
• [C-3-3] DEVE segnalare il valore corretto per BluetoothAdapter.isOffloadedFilteringSupported() per indicare se è implementata la logica di filtraggio per le classi API ScanFilter.
• [C-3-4] DEVE segnalare il valore corretto per BluetoothAdapter.isMultipleAdvertisementSupported() per indicare se la pubblicità a basso consumo energetico è supportata.
• DEVE supportare l'offload della logica di filtraggio al chipset Bluetooth durante l'implementazione dell'API ScanFilter.
• DEVE supportare l'offload della scansione batch al chipset Bluetooth.

• DEVE supportare più pubblicità con almeno 4 spazi.

• [SR] È VIVAMENTE CONSIGLIATO di implementare un timeout per l'indirizzo privato risolvibile (RPA) non superiore a 15 minuti e di ruotare l'indirizzo al timeout per proteggere la privacy dell'utente.

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

• [C-4-1] DEVE fornire un'interfaccia utente per attivare/disattivare la lettura del valore tramite l'API di sistema BluetoothAdapter.isBleScanAlwaysAvailable().

7.4.4. Near Field Communication

Implementazioni del dispositivo:

• DEVE includere un ricetrasmettitore e l'hardware correlato per la tecnologia Near Field Communication (NFC).
• [C-0-1] DEVE implementare le API android.nfc.NdefMessage e android.nfc.NdefRecord anche se non includono il supporto NFC o non dichiarano la funzionalità android.hardware.nfc, in quanto le classi rappresentano un formato di rappresentazione dei dati indipendente dal protocollo.

Se le implementazioni del dispositivo includono hardware NFC e prevedono di renderlo disponibile per app di terze parti:

• [C-1-1] DEVE segnalare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature().
• DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC:
• [C-1-2] DEVE essere in grado di fungere da lettore/scrittore NFC Forum (come definito dalla specifica tecnica NFCForum-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Tipi di tag NFC Forum 1, 2, 3, 4, 5 (definiti da NFC Forum)

• [SR] VIVAMENTE CONSIGLIATO di essere in grado di leggere e scrivere messaggi NDEF e dati non elaborati tramite i seguenti standard NFC. Tieni presente che, sebbene gli standard NFC siano indicati come FORTEMENTE CONSIGLIATI, è 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. È vivamente consigliato ai dispositivi esistenti e nuovi che eseguono questa versione di Android di soddisfare questi requisiti ora, in modo da poter eseguire l'upgrade alle versioni future della piattaforma.

• [C-1-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 da NFC Forum)
  • SDP 1.0 (definito da NFC Forum)
  • Protocollo NDEF Push
  • SNEP 1.0 (definito da NFC Forum)
• [C-1-4] DEVE includere il supporto per 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 Android Beam è attivato o quando è attiva un'altra modalità NFC P2p proprietaria.
• [C-1-6] DEVE implementare il server predefinito SNEP. I messaggi NDEF validi ricevuti dal server SNEP predefinito DEVONO essere inviati alle applicazioni utilizzando l'intent android.nfc.ACTION_NDEF_DISCOVERED. La disattivazione di Android Beam nelle impostazioni NON DEVE disattivare l'invio del messaggio NDEF in arrivo.
• [C-1-7] DEVE rispettare l'intent android.settings.NFCSHARING_SETTINGS di mostrare le impostazioni di condivisione NFC.
• [C-1-8] DEVE implementare il server NPP. I messaggi ricevuti dal server NPP DEVONO essere elaborati allo stesso modo del server predefinito SNEP.
• [C-1-9] DEVE implementare un client SNEP e tentare di inviare NDEF P2P in uscita al server SNEP predefinito quando Android Beam è abilitato. Se non viene trovato alcun server SNEP predefinito, il client DEVE tentare di inviare a un server NPP.
• [C-1-10] MUST allow foreground activities to set the outbound P2P NDEF message using android.nfc.NfcAdapter.setNdefPushMessage, and android.nfc.NfcAdapter.setNdefPushMessageCallback, and android.nfc.NfcAdapter.enableForegroundNdefPush.
• DEVE utilizzare un gesto o una conferma sullo schermo, ad esempio "Tocca per Beam", 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 versione 1.2" e "Bluetooth Secure Simple Pairing Using NFC versione 1.0" del forum NFC. Una simile implementazione DEVE implementare il servizio LLCP di trasferimento con il nome del 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 DEVE comunque accettare le richieste SNEP GET per lo scambio dei record di richiesta/selezione di trasferimento tramite NFC. Tuttavia, un'implementazione NON DEVE inviare richieste GET SNEP per eseguire il trasferimento della connessione.
• [C-1-13] DEVE eseguire il polling di tutte le tecnologie supportate in modalità di rilevamento NFC.
• DEVE essere in modalità di rilevamento NFC mentre il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.
• DEVE essere in grado di leggere il codice a barre e l'URL (se codificato) dei prodotti Thinfilm NFC Barcode.

Tieni presente che i link disponibili pubblicamente non sono disponibili per le specifiche JIS, ISO e NFC Forum citate sopra.

Android include il supporto per la modalità NFC Host Card Emulation (HCE).

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

• [C-2-1] DEVE segnalare la costante della funzionalità android.hardware.nfc.hce.
• [C-2-2] DEVE supportare le API NFC HCE come definite nell'SDK Android.

Se le implementazioni dei dispositivi includono un chipset del controller NFC in grado di supportare HCE per NfcF e implementano la funzionalità per applicazioni di terze parti:

• [C-3-1] DEVE segnalare la costante della funzionalità android.hardware.nfc.hcef.
• [C-3-2] DEVE implementare le API di emulazione della scheda NfcF come definite nell'SDK Android.

Se le implementazioni dei dispositivi includono il supporto NFC generale come descritto in questa sezione e supportano le tecnologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF su MIFARE Classic) nel ruolo di lettore/scrittore:

• [C-4-1] DEVE implementare le API Android corrispondenti come documentato dall'SDK Android.
• [C-4-2] DEVE segnalare la funzionalità com.nxp.mifare dal metodo android.content.pm.PackageManager.hasSystemFeature(). Tieni presente che questa non è una funzionalità Android standard e pertanto non viene visualizzata come costante nella classe android.content.pm.PackageManager.

7.4.5. Capacità di rete minima

Implementazioni del dispositivo:

• [C-0-1] DEVE includere il supporto per una o più forme di rete di dati. Nello specifico, le implementazioni del dispositivo DEVONO includere il supporto di almeno uno standard di dati in grado di raggiungere una velocità di 200 Kbit/sec o superiore. Alcuni esempi di tecnologie che soddisfano questo requisito includono EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
• DOVREBBE includere anche il supporto di almeno uno standard comune per i dati wireless, ad esempio 802.11 (Wi-Fi), quando uno standard di rete fisico (ad esempio Ethernet) è la connessione dati principale.
• PUÒ implementare più di una forma di connettività dei dati.
• [C-0-2] DEVE includere uno stack di rete IPv6 e supportare la comunicazione IPv6 utilizzando le API gestite, come java.net.Socket e java.net.URLConnection, nonché le API native, come i socket AF_INET6.
• [C-0-3] DEVE abilitare IPv6 per impostazione predefinita.
• DEVE garantire che la comunicazione IPv6 sia affidabile quanto IPv4, ad esempio:
  • [C-0-4] DEVE mantenere la connettività IPv6 in modalità Doze.
  • [C-0-5] La limitazione della velocità NON DEVE causare la perdita della connettività IPv6 sul dispositivo su qualsiasi rete compatibile con IPv6 che utilizza durate RA di almeno 180 secondi.
• [C-0-6] DEVE fornire alle applicazioni di terze parti connettività IPv6 diretta alla rete quando è connesso a una rete IPv6, senza alcuna forma di traduzione di indirizzi o porte a livello locale sul dispositivo. Sia le API gestite, come Socket#getLocalAddress o Socket#getLocalPort, sia le API NDK, come getsockname() o IPV6_PKTINFO, DEVONO restituire l'indirizzo IP e la porta effettivamente utilizzati per inviare e ricevere pacchetti sulla rete.

Il livello di supporto IPv6 richiesto dipende dal tipo di rete, come mostrato nei seguenti requisiti.

Se le implementazioni dei dispositivi supportano il Wi-Fi:

• [C-1-1] DEVE supportare il funzionamento a doppio stack e solo IPv6 su Wi-Fi.

Se le implementazioni dei dispositivi supportano Ethernet:

• [C-2-1] DEVE supportare il funzionamento dual-stack su Ethernet.

Se le implementazioni dei dispositivi supportano la rete dati:

• DEVE supportare il funzionamento di IPv6 (solo IPv6 e possibilmente dual-stack) sulla rete cellulare.

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

• [C-3-1] DEVE soddisfare contemporaneamente i requisiti di cui sopra su ogni rete quando il dispositivo è connesso contemporaneamente a più di un tipo di rete.

7.4.6. Impostazioni di sincronizzazione

Implementazioni del dispositivo:

• [C-0-1] DEVE avere l'impostazione di sincronizzazione automatica principale attiva per impostazione predefinita, in modo che il metodo getMasterSyncAutomatically() restituisca "true".

7.4.7. Risparmio dati

Se le implementazioni dei dispositivi includono una connessione a consumo, sono:

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

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

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

Se le implementazioni del dispositivo non forniscono la modalità Risparmio dati:

• [C-2-1] MUST return the value RESTRICT_BACKGROUND_STATUS_DISABLED for ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] MUST NOT broadcast ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
• [C-2-3] DEVE avere un'attività che gestisce l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ma PUÒ implementarlo come no-op.

7.4.8. Secure Element

Se le implementazioni dei dispositivi supportano Open Mobile API in grado di proteggere gli elementi sicuri e renderli disponibili per app di terze parti:

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

7.5. Videocamere

Se le implementazioni dei dispositivi includono almeno una videocamera:

• [C-1-1] DEVE dichiarare il flag funzionalità android.hardware.camera.any.
• [C-1-2] DEVE essere possibile per un'applicazione allocare simultaneamente 3 bitmap RGBA_8888 di dimensioni pari a quelle delle immagini prodotte dal sensore della fotocamera con la risoluzione più alta sul dispositivo, mentre la fotocamera è aperta per lo scopo di anteprima di base e acquisizione di foto.

7.5.1. Fotocamera posteriore

Una fotocamera posteriore è una fotocamera posizionata sul lato del dispositivo opposto al display, ovvero riprende scene sul lato opposto del dispositivo, come una fotocamera tradizionale.

Implementazioni del dispositivo:

• DOVREBBE includere una fotocamera posteriore.

Se le implementazioni dei dispositivi includono almeno una fotocamera posteriore:

• [C-1-1] DEVE 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 la messa a fuoco automatica hardware o software implementata nel driver della fotocamera (trasparente per il software applicativo).
• POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa).
• POTREBBE includere un flash.

Se la videocamera include un flash:

• [C-2-1] La lampada flash NON DEVE essere accesa mentre è stata registrata un'istanza android.hardware.Camera.PreviewCallback su una superficie di anteprima della videocamera, a meno che l'applicazione non abbia attivato esplicitamente il flash attivando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON di un oggetto Camera.Parameters. Tieni presente che questo vincolo non si applica all'applicazione della fotocamera di sistema integrata nel dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

Una fotocamera frontale è una fotocamera posizionata sullo stesso lato del dispositivo del display, ovvero una fotocamera in genere utilizzata per riprendere l'utente, ad esempio per le videoconferenze e applicazioni simili.

Implementazioni del dispositivo:

• POTREBBE includere una fotocamera anteriore.

Se le implementazioni dei dispositivi includono almeno una videocamera frontale:

• [C-1-1] DEVE segnalare i flag funzionalità android.hardware.camera.any e android.hardware.camera.front.
• [C-1-2] DEVE avere una risoluzione di almeno VGA (640x480 pixel).
• [C-1-3] NON DEVE utilizzare una fotocamera frontale come predefinita per l'API Camera e NON DEVE configurare l'API in modo che tratti una fotocamera frontale come fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
• [C-1-4] L'anteprima della videocamera DEVE essere specchiata orizzontalmente rispetto all'orientamento specificato dall'applicazione quando l'applicazione corrente ha richiesto esplicitamente la rotazione del display della videocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation(). Al contrario, l'anteprima DEVE essere specchiata lungo l'asse orizzontale predefinito del dispositivo quando l'applicazione corrente non richiede esplicitamente la rotazione del display della videocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NON DEVE eseguire il mirroring dei flussi video o del fermo immagine finale acquisito restituiti ai callback dell'applicazione o salvati nella memoria multimediale.
• [C-1-6] DEVE rispecchiare l'immagine visualizzata dalla postview nello stesso modo del flusso di immagini di anteprima della videocamera.
• POSSONO includere funzionalità (come messa a fuoco automatica, flash e così via) disponibili per le fotocamere posteriori, come descritto nella sezione 7.5.1.

Se le implementazioni del dispositivo possono essere ruotate dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente):

• [C-2-1] L'anteprima della videocamera DEVE essere specchiata orizzontalmente rispetto all'orientamento attuale del dispositivo.

7.5.3. Videocamera esterna

Implementazioni del dispositivo:

• POTREBBE includere il supporto di una fotocamera esterna che non è necessariamente sempre connessa.

Se le implementazioni dei dispositivi includono il supporto di una videocamera esterna:

• [C-1-1] DEVE dichiarare i flag delle funzionalità della piattaforma android.hardware.camera.external e android.hardware camera.any.
• [C-1-2] DEVE supportare USB Video Class (UVC 1.0 o versioni successive) se la videocamera esterna si connette tramite la porta host USB.
• [C-1-3] DEVE superare i test CTS della fotocamera con un dispositivo fotocamera esterno fisico collegato. I dettagli dei test CTS della videocamera sono disponibili all'indirizzo source.android.com.
• DEVE supportare compressioni video come MJPEG per consentire il trasferimento di stream non codificati di alta qualità (ad es. stream di immagini grezze o compressi in modo indipendente).
• POTREBBE supportare più videocamere.
• POTREBBE supportare la codifica video basata sulla videocamera.

Se la codifica video basata sulla videocamera è supportata:

• [C-2-1] L'implementazione del dispositivo DEVE poter accedere a uno stream simultaneo non codificato / MJPEG (risoluzione QVGA o superiore).

7.5.4. Comportamento dell'API Camera

Android include due pacchetti API per accedere alla fotocamera. La nuova API android.hardware.camera2 espone il controllo della fotocamera di livello inferiore all'app, inclusi flussi di streaming/scatto a raffica efficienti senza copia e controlli per frame di esposizione, guadagno, guadagni del bilanciamento del bianco, conversione del colore, riduzione del rumore, nitidezza e altro ancora.

Il pacchetto API precedente,android.hardware.Camera, è contrassegnato come deprecato in Android 5.0, ma dovrebbe comunque essere disponibile per l'utilizzo da parte delle app. Le implementazioni dei dispositivi Android DEVONO garantire il supporto continuo dell'API come descritto in questa sezione e nell'SDK Android.

Tutte le funzionalità comuni tra la classe android.hardware.Camera deprecata e il pacchetto android.hardware.camera2 più recente DEVONO avere prestazioni e qualità equivalenti in entrambe le API. Ad esempio, con impostazioni equivalenti, la velocità e la precisione della messa a fuoco automatica devono essere identiche e la qualità delle immagini acquisite deve essere la stessa. Le funzionalità che dipendono dalle diverse semantiche delle due API non devono avere velocità o qualità corrispondenti, ma DEVONO corrispondere il più possibile.

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API correlate alla fotocamera, per tutte le fotocamere disponibili. Implementazioni del dispositivo:

• [C-0-1] DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione quando un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] DEVE inoltre essere nel formato di codifica NV21 quando un'applicazione registra un'istanza android.hardware.Camera.PreviewCallback e il sistema chiama il metodo onPreviewFrame() e il formato di anteprima è YCbCr_420_SP, i dati nel byte[] passati a onPreviewFrame(). ovvero NV21 DEVE essere il formato predefinito.
• [C-0-3] DEVE supportare il formato YV12 (indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia per le fotocamere anteriori che per quelle posteriori per android.hardware.Camera. Il codificatore video hardware e la videocamera possono utilizzare qualsiasi formato pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione in YV12.
• [C-0-4] DEVE supportare i formati android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG come output tramite l'API android.media.ImageReader per i dispositivi android.hardware.camera2 che pubblicizzano la funzionalità REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE in android.request.availableCapabilities.
• [C-0-5] DEVE comunque implementare l'API Camera completa inclusa nella documentazione dell'SDK Android, indipendentemente dal fatto che il dispositivo includa la messa a fuoco automatica hardware o altre funzionalità. Ad esempio, le videocamere senza messa a fuoco automatica DEVONO comunque chiamare le istanze android.hardware.Camera.AutoFocusCallback registrate (anche se non è pertinente per una videocamera senza messa a fuoco automatica). Tieni presente che questo vale per le fotocamere frontali; ad esempio, anche se la maggior parte delle fotocamere frontali non supporta la messa a fuoco automatica, i callback API devono comunque essere "falsificati" come descritto.
• [C-0-6] DEVE riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters. Al contrario, le implementazioni del dispositivo NON DEVONO rispettare o riconoscere le costanti stringa trasmesse al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. ovvero le implementazioni del dispositivo DEVONO supportare tutti i parametri standard della fotocamera se l'hardware lo consente e NON DEVONO supportare tipi di parametri della fotocamera personalizzati. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini utilizzando tecniche di imaging High Dynamic Range (HDR) DEVONO supportare il parametro della videocamera Camera.SCENE_MODE_HDR.
• [C-0-7] DEVE segnalare il livello di supporto appropriato con la proprietà android.info.supportedHardwareLevel, come descritto nell'SDK Android, e segnalare i flag delle funzionalità del framework appropriati.
• [C-0-8] DEVE anche dichiarare le funzionalità della singola videocamera android.hardware.camera2 tramite la proprietà android.request.availableCapabilities e dichiarare i flag delle funzionalità appropriati; DEVE definire il flag della funzionalità se uno qualsiasi dei dispositivi videocamera collegati la supporta.
• [C-0-9] DEVE trasmettere l'intent Camera.ACTION_NEW_PICTURE ogni volta che la videocamera scatta una nuova foto e la voce della foto è stata aggiunta all'archivio multimediale.
• [C-0-10] DEVE trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e la voce dell'immagine è stata aggiunta all'archivio multimediale.
• [C-SR] È VIVAMENTE CONSIGLIATO di supportare un dispositivo videocamera logica che elenca la funzionalità CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, per i dispositivi con più videocamere rivolte nella stessa direzione, costituita da ogni videocamera fisica rivolta in quella direzione, a condizione che il tipo di videocamera fisica sia supportato dal framework e che CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL per le videocamere fisiche sia LIMITED, FULL o LEVEL_3.

7.5.5. Orientamento della videocamera

Se le implementazioni del dispositivo hanno una fotocamera anteriore o posteriore, queste fotocamere:

• [C-1-1] DEVE essere orientata in modo che la dimensione lunga della videocamera sia allineata alla dimensione lunga dello schermo. ovvero, quando il dispositivo è tenuto in orientamento orizzontale, le videocamere DEVONO acquisire immagini in orientamento orizzontale. Ciò vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica sia ai dispositivi con orientamento orizzontale principale sia a quelli con orientamento verticale principale.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

Implementazioni del dispositivo:

• [C-0-1] DEVE includere un gestore dei download che le applicazioni POSSONO utilizzare per scaricare file di dati e DEVE essere in grado di scaricare singoli file di almeno 100 MB nella posizione "cache" predefinita.

7.6.2. Spazio di archiviazione condiviso dell'applicazione

Implementazioni del dispositivo:

• [C-0-1] DEVE offrire uno spazio di archiviazione da condividere tra le applicazioni, spesso indicato anche come "spazio di archiviazione esterno condiviso", "spazio di archiviazione condiviso dell'applicazione" o dal percorso Linux "/sdcard" su cui è montato.
• [C-0-2] DEVE essere configurato con spazio di archiviazione condiviso montato per impostazione predefinita, ovvero "pronto all'uso", indipendentemente dal fatto che l'archiviazione sia implementata su un componente di memoria interna o su un supporto di archiviazione rimovibile (ad es. slot per schede Secure Digital).
• [C-0-3] DEVE montare lo spazio di archiviazione condiviso dell'applicazione direttamente sul percorso Linux sdcard o includere un link simbolico Linux da sdcard al punto di montaggio effettivo.
• [C-0-4] DEVE applicare l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE a questo spazio di archiviazione condiviso come documentato nell'SDK. Lo spazio di archiviazione condiviso DEVE essere scrivibile da qualsiasi applicazione che ottenga l'autorizzazione.

Le implementazioni dei dispositivi POSSONO soddisfare i requisiti di cui sopra utilizzando una delle seguenti opzioni:

• Memoria rimovibile accessibile all'utente, ad esempio uno slot per schede Secure Digital (SD).
• Una parte dello spazio di archiviazione interno (non rimovibile) come implementato in Android Open Source Project (AOSP).

Se le implementazioni dei dispositivi utilizzano supporti di archiviazione rimovibili per soddisfare i requisiti sopra indicati:

• [C-1-1] DEVE implementare un avviso nell'interfaccia utente sotto forma di toast o popup quando non è inserito alcun supporto di archiviazione nello slot.
• [C-1-2] DEVE includere un supporto di archiviazione formattato FAT (ad es. scheda SD) o mostrare sulla confezione e su altro materiale disponibile al momento dell'acquisto che il supporto di archiviazione deve essere acquistato separatamente.

Se le implementazioni dei dispositivi utilizzano una parte dello spazio di archiviazione non rimovibile per soddisfare i requisiti di cui sopra:

• DEVE utilizzare l'implementazione AOSP dello spazio di archiviazione condiviso interno dell'applicazione.
• POTREBBE condividere lo spazio di archiviazione con i dati privati dell'applicazione.

Se le implementazioni del dispositivo includono più percorsi di archiviazione condivisa (ad esempio uno slot per scheda SD e una memoria interna condivisa):

• [C-2-1] DEVE consentire la scrittura nell'archivio esterno secondario solo alle applicazioni Android preinstallate e privilegiate con l'autorizzazione WRITE_EXTERNAL_STORAGE, tranne quando si scrive nelle directory specifiche del pacchetto o all'interno di URI restituito dall'attivazione dell'intent ACTION_OPEN_DOCUMENT_TREE.

Se le implementazioni dei dispositivi hanno una porta USB con supporto della modalità periferica USB:

• [C-3-1] DEVE fornire un meccanismo per accedere ai dati nell'archivio condiviso dell'applicazione da un computer host.
• DEVE esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione dei contenuti multimediali di Android e android.provider.MediaStore.
• PUÒ utilizzare l'archiviazione di massa USB, ma DEVE utilizzare il protocollo di trasferimento multimediale per soddisfare questo requisito.

Se le implementazioni dei dispositivi hanno una porta USB con modalità periferica USB e supportano il protocollo di trasferimento multimediale,

• DEVE essere compatibile con l'host MTP Android di riferimento, Android File Transfer.
• DEVE segnalare una classe di dispositivo USB pari a 0x00.
• DEVE segnalare il nome dell'interfaccia USB "MTP".

7.6.3. Spazio di archiviazione utilizzabile

Se il dispositivo è mobile per natura, a differenza della televisione, le implementazioni del dispositivo sono:

• [SR] È VIVAMENTE CONSIGLIATO di implementare la memoria adottabile in una posizione stabile a lungo termine, poiché la disconnessione accidentale può causare la perdita/il danneggiamento dei dati.

Se la porta del dispositivo di archiviazione rimovibile si trova in 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] VIVAMENTE CONSIGLIATO di implementare la memoria adottabile.

7.7. USB

Se le implementazioni del dispositivo hanno una porta USB:

• DEVE supportare la modalità periferica USB e la modalità host USB.

7.7.1. Modalità periferica USB

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

• [C-1-1] La porta DEVE essere collegabile a un host USB con una porta USB standard di tipo A o di tipo C.
• [C-1-2] DEVE segnalare il valore corretto di iSerialNumber nel descrittore del dispositivo standard USB tramite android.os.Build.SERIAL.
• [C-1-3] DEVE rilevare caricabatterie da 1,5 A e 3 A in base allo standard di resistenza Type-C e DEVE rilevare le modifiche alla pubblicità se supportano USB Type-C.
• [SR] La porta DEVE utilizzare il fattore di forma USB micro-B, micro-AB o Type-C. È VIVAMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti, in modo che possano essere aggiornati alle versioni future della piattaforma.
• [SR] La porta DEVE trovarsi nella parte inferiore del dispositivo (in base all'orientamento naturale) o abilitare la rotazione dello schermo software per tutte le app (inclusa la schermata Home), in modo che il display venga disegnato correttamente quando il dispositivo è orientato con la porta in basso. È VIVAMENTE CONSIGLIATO che i dispositivi Android nuovi ed esistenti soddisfino questi requisiti, in modo che possano essere aggiornati alle versioni future della piattaforma.
• [SR] DEVE implementare il supporto per assorbire una corrente di 1,5 A durante il segnale acustico HS e il traffico come specificato nella specifica di ricarica della batteria USB, revisione 1.2. È VIVAMENTE CONSIGLIATO che i dispositivi Android esistenti e nuovi soddisfino questi requisiti, in modo che possano essere aggiornati alle versioni future della piattaforma.
• [SR] È VIVAMENTE CONSIGLIATO di non supportare metodi di ricarica proprietari che modificano la tensione Vbus oltre i livelli predefiniti o alterano i ruoli di sink/source, in quanto ciò potrebbe causare problemi di interoperabilità con i caricabatterie o i dispositivi che supportano i metodi standard di alimentazione USB. Sebbene sia indicato come "FORTEMENTE CONSIGLIATO", nelle future versioni di Android potremmo RICHIEDERE che tutti i dispositivi di tipo C supportino la piena interoperabilità con i caricabatterie standard di tipo C.
• [SR] VIVAMENTE CONSIGLIATO per supportare Power Delivery per lo scambio di ruoli di dati e alimentazione quando supportano USB Type-C e la modalità host USB.
• DOVREBBE supportare Power Delivery per la ricarica ad alta tensione e le modalità alternative come l'uscita video.
• DEVE implementare l'API e la specifica Android Open Accessory (AOA) come documentato nella documentazione dell'SDK Android.

Se le implementazioni dei dispositivi includono una porta USB e implementano la specifica AOA:

• [C-2-1] DEVE dichiarare il supporto per la funzionalità hardware android.hardware.usb.accessory.
• [C-2-2] La classe di archiviazione di massa USB DEVE includere la stringa "android" alla fine della stringa iInterface della descrizione dell'interfaccia dell'archiviazione di massa USB

7.7.2. Modalità host USB

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

• [C-1-1] DEVE implementare l'API host USB di Android come documentato nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardware android.hardware.usb.host.
• [C-1-2] DEVE implementare il supporto per connettere periferiche USB standard, ovvero DEVE:
  • Avere una porta di tipo C sul dispositivo o essere fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB Type-C standard (dispositivo USB Type-C).
  • Avere un tipo A sul dispositivo o essere fornito con cavi che adattano una porta proprietaria sul dispositivo a una porta USB standard di tipo A.
  • Avere una porta micro-AB sul dispositivo, che DOVREBBE essere fornito con un cavo di adattamento a una porta Type-A standard.
• [C-1-3] NON DEVE essere spedito con un adattatore che converte le porte USB di tipo A o micro-AB in una porta (presa) di tipo C.
• [SR] È VIVAMENTE CONSIGLIATO di implementare la classe audio USB come descritto nella documentazione dell'SDK Android.
• DEVE supportare la ricarica del dispositivo periferico USB collegato in modalità host; pubblicizzare una corrente di alimentazione di almeno 1,5 A come specificato nella sezione Parametri di terminazione della specifica del cavo e del connettore USB Type-C, revisione 1.2 per i connettori USB Type-C o utilizzare l'intervallo di corrente di uscita della porta di ricarica downstream(CDP) come specificato nelle specifiche di ricarica della batteria USB, revisione 1.2 per i connettori Micro-AB.
• DEVONO implementare e supportare gli standard USB Type-C.

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

• [C-2-1] DEVE supportare la classe USB HID.
• [C-2-2] DEVE supportare il rilevamento e la mappatura dei seguenti campi di dati HID specificati nelle tabelle di utilizzo HID USB e nella richiesta di utilizzo dei comandi vocali alle costanti KeyEvent come indicato di seguito:
  • Pagina di utilizzo (0xC) ID utilizzo (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Pagina di utilizzo (0xC) ID utilizzo (0x0E9): KEYCODE_VOLUME_UP
  • Pagina di utilizzo (0xC) ID utilizzo (0x0EA): KEYCODE_VOLUME_DOWN
  • Pagina di utilizzo (0xC) ID utilizzo (0x0CF): KEYCODE_VOICE_ASSIST

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e Storage Access Framework (SAF),

• [C-3-1] DEVE riconoscere tutti i dispositivi MTP (Media Transfer Protocol) connessi da remoto e rendere accessibili i relativi contenuti tramite gli intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

Se le implementazioni dei dispositivi includono una porta USB che supporta la modalità host e USB Type-C:

• [C-4-1] DEVE implementare la funzionalità Dual Role Port come definita dalla specifica USB Type-C (sezione 4.5.1.3.3).
• [SR] VIVAMENTE CONSIGLIATO per supportare DisplayPort, DOVREBBE supportare velocità di trasferimento dati USB SuperSpeed ed è VIVAMENTE CONSIGLIATO per supportare Power Delivery per lo scambio di ruoli di dati e alimentazione.
• [SR] È VIVAMENTE CONSIGLIATO di NON supportare la modalità accessorio adattatore audio come descritto nell'appendice A della specifica del cavo e del connettore USB Type-C Revisione 1.2.
• DEVE implementare il modello Try.* più appropriato per il fattore di forma del dispositivo. Ad esempio, un dispositivo portatile DEVE implementare il modello Try.SNK.

7.8. Audio

7.8.1. Microfono

Se le implementazioni del dispositivo includono un microfono:

• [C-1-1] DEVE segnalare la costante della funzionalità android.hardware.microphone.
• [C-1-2] DEVE soddisfare i requisiti di registrazione audio indicati nella sezione 5.4.
• [C-1-3] DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
• [SR] Sono FORTEMENTE CONSIGLIATI per supportare la registrazione di suoni quasi impercettibili come descritto nella sezione 7.8.3.

Se le implementazioni del dispositivo omettono un microfono:

• [C-2-1] NON DEVE segnalare la costante della funzionalità android.hardware.microphone.
• [C-2-2] DEVE implementare l'API di registrazione audio almeno come no-ops, come indicato nella sezione 7.

7.8.2. Uscita audio

Se le implementazioni dei dispositivi includono un altoparlante o una porta di output audio/multimediale per una periferica di output audio come un jack audio da 3,5 mm a 4 conduttori o una porta in modalità host USB che utilizza la classe audio USB, queste:

• [C-1-1] DEVE segnalare la costante della funzionalità android.hardware.audio.output.
• [C-1-2] DEVE soddisfare i requisiti di riproduzione audio riportati nella sezione 5.5.
• [C-1-3] DEVE soddisfare i requisiti di latenza audio riportati nella sezione 5.6.
• [SR] VIVAMENTE CONSIGLIATO per supportare la riproduzione di suoni quasi ultrasonici, come descritto nella sezione 7.8.3.

Se le implementazioni dei dispositivi non includono un altoparlante o una porta di uscita audio:

• [C-2-1] NON DEVE segnalare la funzionalità android.hardware.audio.output.
• [C-2-2] DEVE implementare almeno le API correlate all'output audio come no-op.

Ai fini di questa sezione, una "porta di uscita" è un'interfaccia fisica come un jack audio da 3, 5 mm, HDMI o una porta in modalità host USB con classe audio USB. Il supporto dell'uscita audio tramite protocolli basati su segnale radio come Bluetooth, Wi-Fi o rete mobile non è considerato un "output port".

7.8.2.1. Porte audio analogiche

Per essere compatibili con le cuffie e altri accessori audio che utilizzano la spina audio da 3, 5 mm nell'ecosistema Android, se le implementazioni dei dispositivi includono una o più porte audio analogiche:

• [C-SR] È VIVAMENTE CONSIGLIATO includere almeno una delle porte audio come jack audio da 3,5 mm a 4 conduttori.

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

• [C-1-1] DEVE supportare la riproduzione audio su cuffie stereo e cuffie stereo con microfono.
• [C-1-2] DEVE supportare i connettori audio TRRS con l'ordine dei pin CTIA.
• [C-1-3] DEVE supportare il rilevamento e la mappatura dei codici chiave per i seguenti tre intervalli di impedenza equivalente tra il microfono e i conduttori di terra sul connettore audio:
  • 70 ohm o meno: KEYCODE_HEADSETHOOK
  • 210-290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] DEVE attivare ACTION_HEADSET_PLUG all'inserimento di una spina, ma solo dopo che tutti i contatti della spina toccano i segmenti pertinenti del jack.
• [C-1-5] DEVE essere in grado di pilotare almeno 150 mV ± 10% della tensione di uscita su un'impedenza dell'altoparlante di 32 ohm.
• [C-1-6] DEVE avere una tensione di polarizzazione del microfono compresa tra 1,8 V e 2,9 V.
• [C-1-7] DEVE rilevare e mappare il keycode per il seguente intervallo di impedenza equivalente tra il microfono e i conduttori di terra sul jack audio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare i jack audio con l'ordine di piedinatura OMTP.
• [C-SR] È FORTEMENTE CONSIGLIATO supportare la registrazione audio da cuffie stereo con microfono.

Se le implementazioni dei dispositivi hanno un jack audio da 3, 5 mm a 4 conduttori e supportano un microfono e trasmettono android.intent.action.HEADSET_PLUG con il valore aggiuntivo del microfono impostato su 1, allora:

• [C-2-1] DEVE supportare il rilevamento del microfono sull'accessorio audio collegato.

7.8.3. Near-Ultrasound

L'audio quasi ultrasonico è la banda da 18,5 kHz a 20 kHz.

Implementazioni del dispositivo:

• DEVE segnalare correttamente il supporto della funzionalità audio a ultrasuoni tramite l'API AudioManager.getProperty nel seguente modo:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND è "true", le seguenti condizioni DEVONO essere soddisfatte dalle sorgenti audio VOICE_RECOGNITION e UNPROCESSED:

• [C-1-1] La risposta di potenza media del microfono nella banda da 18,5 kHz a 20 kHz NON DEVE essere inferiore di oltre 15 dB rispetto alla risposta a 2 kHz.
• [C-1-2] Il rapporto segnale/rumore non ponderato del microfono nell'intervallo da 18,5 kHz a 20 kHz per un tono a 19 kHz a -26 dBFS NON DEVE essere inferiore a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND è "true":

• [C-2-1] La risposta media dell'altoparlante a 18,5 kHz - 20 kHz NON DEVE essere inferiore a 40 dB rispetto alla risposta a 2 kHz.

7.9. Realtà virtuale

Android include API e funzionalità per creare applicazioni di "realtà virtuale" (VR), tra cui esperienze VR mobile di alta qualità. Le implementazioni dei dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

7.9.1. Modalità Realtà virtuale

Android include il supporto della modalità VR, una funzionalità che gestisce il rendering stereoscopico delle notifiche e disattiva i componenti dell'interfaccia utente di sistema monoculare mentre un'applicazione VR è in primo piano.

7.9.2. Modalità Realtà virtuale - Alte prestazioni

Se le implementazioni dei dispositivi supportano la modalità VR:

• [C-1-1] DEVE avere almeno 2 core fisici.
• [C-1-2] DEVE dichiarare la funzionalità android.hardware.vr.high_performance.
• [C-1-3] DEVE supportare la modalità Prestazioni sostenute.
• [C-1-4] DEVE supportare OpenGL ES 3.2.
• [C-1-5] MUST support android.hardware.vulkan.level 0.
• DEVE supportare android.hardware.vulkan.level 1 o versioni successive.
• [C-1-6] DEVE implementare EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace ed esporre le estensioni nell'elenco delle estensioni EGL disponibili.
• [C-1-8] DEVE implementare GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
• [C-SR] È VIVAMENTE CONSIGLIATO implementare GL_EXT_external_buffer, GL_EXT_EGL_image_array ed esporre le estensioni nell'elenco delle estensioni GL disponibili.
• [C-SR] Sono VIVAMENTE CONSIGLIATI per 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 ed esporlo nell'elenco delle estensioni Vulkan disponibili.
• [C-SR] È FORTEMENTE CONSIGLIATO esporre almeno una famiglia di code Vulkan in cui flags contenga sia VK_QUEUE_GRAPHICS_BIT sia VK_QUEUE_COMPUTE_BIT e queueCount sia almeno 2.
• [C-1-7] La GPU e il display DEVONO essere in grado di sincronizzare l'accesso al buffer frontale condiviso in modo che il rendering alternato per occhio dei contenuti VR a 60 fps con due contesti di rendering venga visualizzato senza artefatti di tearing visibili.
• [C-1-9] DEVE implementare il supporto dei flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT come descritto nell'NDK.
• [C-1-10] DEVE implementare il supporto per i AHardwareBuffer con qualsiasi combinazione dei flag di utilizzo AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT per almeno i seguenti formati: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] Sono VIVAMENTE CONSIGLIATI per supportare l'allocazione di AHardwareBuffer con più di un livello e flag e formati specificati in C-1-10.
• [C-1-11] DEVE supportare la decodifica H.264 almeno a 3840 x 2160 a 30 fps, compressa a una media di 40 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps - 10 Mbps o 2 istanze di 1920 x 1080 a 60 fps - 20 Mbps).
• [C-1-12] DEVE supportare HEVC e VP9, DEVE essere in grado di decodificare almeno 1920 x 1080 a 30 fps compresso a una media di 10 Mbps e DOVREBBE essere in grado di decodificare 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 istanze di 1920 x 1080 a 30 fps-5 Mbps).
• [C-1-13] DEVE supportare l'API HardwarePropertiesManager.getDeviceTemperatures e restituire valori accurati per la temperatura cutanea.
• [C-1-14] DEVE avere uno schermo integrato e la sua risoluzione DEVE essere almeno 1920 x 1080.
• [C-SR] Sono FORTEMENTE CONSIGLIATI per una risoluzione dello schermo di almeno 2560 x 1440.
• [C-1-15] Il display DEVE aggiornarsi almeno a 60 Hz in modalità VR.
• [C-1-17] Il display DEVE supportare una modalità a bassa persistenza con persistenza ≤ 5 millisecondi, dove la persistenza è definita come il periodo di tempo durante il quale un pixel emette luce.
• [C-1-18] DEVE supportare Bluetooth 4.2 e l'estensione della lunghezza dei dati Bluetooth LE sezione 7.4.3.
• [C-1-19] DEVE supportare e segnalare correttamente il tipo di canale diretto per tutti i seguenti tipi di sensori predefiniti:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare il tipo di canale diretto TYPE_HARDWARE_BUFFER per tutti i tipi di canali diretti elencati sopra.
• [C-1-21] DEVE soddisfare i requisiti relativi a giroscopio, accelerometro e magnetometro per android.hardware.hifi_sensors, come specificato nella sezione 7.3.9.
• [C-SR] Sono FORTEMENTE CONSIGLIATI per supportare la funzionalità android.hardware.sensor.hifi_sensors.
• [C-1-22] DEVE avere una latenza end-to-end dal movimento al fotone non superiore a 28 millisecondi.
• [C-SR] È VIVAMENTE CONSIGLIATO che la latenza end-to-end dal movimento al fotone non superi i 20 millisecondi.
• [C-1-23] DEVE avere un rapporto del primo fotogramma, ovvero il rapporto tra la luminosità dei pixel del primo fotogramma dopo una transizione dal nero al bianco e la luminosità dei pixel bianchi in stato stazionario, di almeno l'85%.
• [C-SR] È FORTEMENTE CONSIGLIATO che abbiano un rapporto tra il primo frame e il totale di almeno il 90%.
• PUÒ fornire un core esclusivo all'applicazione in primo piano e PUÒ supportare l'API Process.getExclusiveCores per restituire il numero di core della CPU esclusivi per l'applicazione in primo piano principale.

Se il core esclusivo è supportato, il core:

• [C-2-1] NON DEVE consentire l'esecuzione di altri processi dello spazio utente (ad eccezione dei driver 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 consumo energetico sono fondamentali per l'esperienza utente e influiscono sulle ipotesi di base che gli sviluppatori avrebbero durante lo sviluppo di un'app.

8.1. Coerenza dell'esperienza utente

È possibile fornire un'interfaccia utente fluida all'utente finale se sono presenti determinati requisiti minimi per garantire una frequenza dei fotogrammi e tempi di risposta coerenti per applicazioni e giochi. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POSSONO avere requisiti misurabili per la latenza dell'interfaccia utente e il cambio di attività, come descritto nella sezione 2.

8.2. Prestazioni di accesso I/O di file

Fornire una base di riferimento comune per prestazioni di accesso ai file coerenti nell'archivio dati privato dell'applicazione (partizione /data) consente agli sviluppatori di app di impostare un'aspettativa adeguata che aiuti la progettazione del software. Le implementazioni dei dispositivi, a seconda del tipo di dispositivo, POSSONO avere determinati requisiti descritti nella sezione 2 per le seguenti operazioni di lettura e scrittura:

• Prestazioni di scrittura sequenziale. Misurato scrivendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
• Prestazioni di scrittura casuale. Misurato scrivendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.
• Prestazioni di lettura sequenziale. Misurato leggendo un file di 256 MB utilizzando un buffer di scrittura di 10 MB.
• Rendimento di lettura casuale. Misurata leggendo un file di 256 MB utilizzando un buffer di scrittura di 4 KB.

8.3. Modalità di risparmio energetico

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

• [C-1-1] NON DEVE discostarsi dall'implementazione AOSP per gli algoritmi di attivazione, manutenzione e riattivazione e per l'utilizzo delle impostazioni di sistema globali delle modalità di risparmio energetico Standby delle app e Sospensione.
• [C-1-2] NON DEVE discostarsi dall'implementazione AOSP per l'utilizzo delle impostazioni globali per gestire la limitazione di attività, sveglie e rete per le app in ogni bucket per la funzionalità App in standby.
• [C-1-3] NON DEVE discostarsi dall'implementazione AOSP per il numero di bucket di standby delle app utilizzati per lo standby delle app.
• [C-1-4] DEVE implementare Bucket di standby delle app e Doze 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] È VIVAMENTE CONSIGLIATO di fornire agli utenti la possibilità di attivare e disattivare la funzionalità di risparmio energetico.
• [C-SR] Sono VIVAMENTE CONSIGLIATE per fornire agli utenti la possibilità di visualizzare tutte le app esentate dalle modalità di risparmio energetico Standby delle app e Sospensione.

Oltre alle modalità di risparmio energetico, le implementazioni dei dispositivi Android POSSONO implementare uno o tutti e quattro gli stati di sospensione definiti da Advanced Configuration and Power Interface (ACPI).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S4 come definiti da ACPI:

• [C-1-1] DEVE entrare in questo stato solo dopo che l'utente ha intrapreso un'azione esplicita per mettere il dispositivo in uno stato inattivo (ad es. chiudendo un coperchio che fa parte fisicamente del dispositivo o spegnendo un veicolo o una televisione) e prima che l'utente riattivi il dispositivo (ad es. aprendo il coperchio o riaccendendo il veicolo o la televisione).

Se le implementazioni dei dispositivi implementano gli stati di alimentazione S3 come definiti da ACPI,

• [C-2-1] DEVE soddisfare il requisito C-1-1 sopra indicato OPPURE DEVE entrare nello stato S3 solo quando le applicazioni di terze parti non necessitano delle risorse di sistema (ad es. 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 di mantenere la CPU in esecuzione tramite PARTIAL_WAKE_LOCK, il dispositivo NON DEVE entrare nello stato S3 a meno che, come descritto in C-1-1, l'utente non abbia intrapreso un'azione esplicita per mettere il dispositivo in uno stato inattivo. Al contrario, quando viene attivata un'attività implementata da app di terze parti tramite JobScheduler o quando Firebase Cloud Messaging viene inviato ad app di terze parti, il dispositivo DEVE uscire dallo stato S3, a meno che l'utente non abbia messo il dispositivo in uno stato inattivo. Questi non sono esempi esaustivi e AOSP implementa numerosi indicatori di riattivazione che attivano la riattivazione da questo stato.

8.4. Contabilizzazione del consumo energetico

Una contabilizzazione e un report più accurati del consumo energetico forniscono allo sviluppatore di app sia gli incentivi che gli strumenti per ottimizzare il modello di utilizzo dell'energia dell'applicazione.

Implementazioni del dispositivo:

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

8.5. Prestazioni costanti

Le prestazioni possono variare notevolmente per le app a esecuzione prolungata ad alte prestazioni, a causa delle altre app in esecuzione in background o della limitazione della CPU dovuta ai limiti di temperatura. Android include interfacce programmatiche in modo che, quando il dispositivo è in grado, l'applicazione in primo piano principale possa richiedere al sistema di ottimizzare l'allocazione delle risorse per gestire queste fluttuazioni.

Implementazioni del dispositivo:

• [C-0-1] DEVE segnalare con precisione il supporto della modalità Prestazioni sostenute tramite il metodo API PowerManager.isSustainedPerformanceModeSupported().

• DEVE supportare la modalità Prestazioni sostenute.

Se le implementazioni dei dispositivi segnalano il supporto della modalità 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 dei dispositivi supportano la prenotazione di un core esclusivo per l'applicazione in primo piano principale:

• [C-2-1] DEVE segnalare tramite il metodo API Process.getExclusiveCores() i numeri ID dei core esclusivi che possono essere riservati dall'applicazione in primo piano principale.
• [C-2-2] NON DEVE consentire l'esecuzione di processi nello spazio utente, ad eccezione dei driver del dispositivo utilizzati dall'applicazione, sui core esclusivi, ma PUÒ consentire l'esecuzione di alcuni processi del kernel, se necessario.

Se le implementazioni dei dispositivi non supportano un core esclusivo:

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

9. Compatibilità del modello di sicurezza

Implementazioni del dispositivo:

• [C-0-1] DEVE implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento su sicurezza e autorizzazioni nelle API nella documentazione per sviluppatori Android.

• [C-0-2] DEVE supportare l'installazione di applicazioni autofirmate senza richiedere autorizzazioni/certificati aggiuntivi da terze parti/autorità. Nello specifico, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle sottosezioni seguenti.

9.1. Autorizzazioni

Implementazioni del dispositivo:

• [C-0-1] DEVE supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android. Nello specifico, DEVONO applicare ogni autorizzazione definita come descritto nella documentazione dell'SDK; nessuna autorizzazione può essere omessa, modificata o ignorata.

• POSSONO aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe ID autorizzazione non si trovino nello spazio dei nomi android.\*.

• [C-0-2] Le autorizzazioni con un protectionLevel di PROTECTION_FLAG_PRIVILEGED DEVONO essere concesse solo alle app preinstallate nei percorsi privilegiati dell'immagine di sistema e nel sottoinsieme delle autorizzazioni esplicitamente consentite per ogni app. L'implementazione AOSP soddisfa questo requisito leggendo e rispettando le autorizzazioni consentite per ogni app dai file nel percorso etc/permissions/ e utilizzando il percorso system/priv-app come percorso privilegiato.

Le autorizzazioni con un livello di protezione pericoloso sono autorizzazioni di runtime. Le applicazioni con targetSdkVersion > 22 le richiedono al runtime.

Implementazioni del dispositivo:

• [C-0-3] DEVE mostrare un'interfaccia dedicata all'utente per decidere se concedere le autorizzazioni di runtime richieste e fornire anche un'interfaccia per gestire le 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] DEVE concedere l'autorizzazione android.permission.RECOVER_KEYSTORE solo alle app di sistema che registrano un agente di recupero adeguatamente protetto. Un agente di recupero protetto correttamente è definito come un agente software sul dispositivo che si sincronizza con uno spazio di archiviazione remoto esterno al dispositivo, dotato di hardware sicuro con protezione equivalente o superiore a quella descritta nel servizio Google Cloud Key Vault per impedire attacchi brute force al fattore di conoscenza della schermata di blocco.

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

• [SR] è FORTEMENTE CONSIGLIATO fornire un meccanismo accessibile agli utenti per concedere o revocare l'accesso alle statistiche sull'utilizzo in risposta all'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS per le app che dichiarano l'autorizzazione android.permission.PACKAGE_USAGE_STATS.

Se le implementazioni dei dispositivi intendono impedire a qualsiasi app, incluse quelle preinstallate, di accedere alle statistiche sull'utilizzo:

• [C-1-1] DEVE comunque avere un'attività che gestisce il pattern di intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, ma DEVE implementarlo come no-op, ovvero avere un comportamento equivalente a quando l'accesso dell'utente viene negato.

9.2. UID e isolamento dei processi

Implementazioni del dispositivo:

• [C-0-1] DEVE supportare il modello di sandbox delle app per Android, in cui ogni applicazione viene eseguita come UID in stile Unix univoco e in un processo separato.
• [C-0-2] DEVE supportare l'esecuzione di più applicazioni con lo stesso ID utente Linux, a condizione che le applicazioni siano firmate e create correttamente, come definito nel riferimento a sicurezza e autorizzazioni.

9.3. Autorizzazioni del file system

Implementazioni del dispositivo:

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

9.4. Ambienti di esecuzione alternativi

Le implementazioni dei dispositivi DEVONO mantenere la coerenza del modello di sicurezza e autorizzazioni di Android, anche se includono ambienti di runtime che eseguono applicazioni utilizzando software o tecnologie diversi dal formato eseguibile Dalvik o dal codice nativo. In altre parole:

• [C-0-1] Gli ambienti di runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella sezione 9.

• [C-0-2] I runtime alternativi NON DEVONO avere 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 da autorizzazioni Android limitate alle applicazioni di sistema.

• [C-0-4] I runtime alternativi DEVONO rispettare il modello di sandbox di Android e le applicazioni installate utilizzando un runtime alternativo NON DEVONO riutilizzare la sandbox di altre app installate sul dispositivo, se non tramite i meccanismi standard di Android di ID utente condiviso e certificato di firma.

• [C-0-5] Gli ambienti di runtime alternativi NON DEVONO essere avviati con, concedere o ricevere l'accesso ai sandbox corrispondenti ad altre applicazioni per Android.

• [C-0-6] I runtime alternativi NON DEVONO essere avviati con, ricevere o concedere ad altre applicazioni privilegi di superutente (root) o di qualsiasi altro ID utente.

• [C-0-7] Quando i file .apk di runtime alternativi sono inclusi nell'immagine di sistema delle implementazioni del dispositivo, DEVONO essere firmati con una chiave distinta da quella utilizzata per firmare altre applicazioni incluse nelle implementazioni del dispositivo.

• [C-0-8] Durante l'installazione delle applicazioni, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione.

• [C-0-9] Quando un'applicazione deve utilizzare una risorsa del dispositivo per la quale esiste un'autorizzazione Android corrispondente (ad esempio fotocamera, GPS e così via), l'ambiente di runtime alternativo DEVE informare l'utente che l'applicazione potrà accedere a quella risorsa.

• [C-0-10] Quando l'ambiente di runtime non registra le funzionalità dell'applicazione in questo modo, DEVE elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che utilizza quel runtime.

• I runtime alternativi DEVONO installare le app tramite PackageManager in sandbox Android separate (ID utente Linux e così via).

• Runtime alternativi POSSONO fornire una singola sandbox Android condivisa da tutte le applicazioni che utilizzano il runtime alternativo.

9.5. Supporto multiutente

Android include il supporto multiutente e fornisce il supporto per l'isolamento completo degli utenti.

• Le implementazioni del dispositivo POSSONO, ma NON DEVONO, attivare il multiutente se utilizzano supporti rimovibili per l'archiviazione esterna principale.

Se le implementazioni dei dispositivi includono più utenti:

• [C-1-1] DEVE soddisfare i seguenti requisiti relativi al supporto multiutente.
• [C-1-2] DEVE, per ogni utente, implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento su sicurezza e autorizzazioni nelle API.
• [C-1-3] MUST have separate and isolated shared application storage (a.k.a. /sdcard) directories for each user instance.
• [C-1-4] DEVE garantire che le applicazioni di proprietà di un determinato utente e in esecuzione per suo conto non possano elencare, leggere o scrivere nei file di proprietà di qualsiasi altro utente, anche se i dati di entrambi gli utenti sono archiviati nello stesso volume o file system.
• [C-1-5] DEVE criptare i contenuti della scheda SD quando è abilitato l'utilizzo multiutente utilizzando una chiave memorizzata solo su supporti non rimovibili accessibili solo al sistema se le implementazioni del dispositivo utilizzano supporti rimovibili per le API di archiviazione esterna. Poiché in questo modo i contenuti multimediali non saranno leggibili da un PC host, le implementazioni dei dispositivi dovranno passare a MTP o a un sistema simile per fornire ai PC host l'accesso ai dati dell'utente corrente.

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

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

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

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

9.6. Avviso SMS premium

Android include il supporto per avvisare gli utenti di eventuali messaggi SMS premium in uscita. Gli SMS premium sono messaggi di testo inviati a un servizio registrato presso un operatore che potrebbe comportare un addebito per l'utente.

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

• [C-1-1] DEVE avvisare gli utenti prima di inviare un messaggio SMS ai numeri identificati dalle espressioni regolari definite nel file /data/misc/sms/codes.xml del dispositivo. Il progetto Android Open Source Project upstream fornisce un'implementazione che soddisfa questo requisito.

9.7. Security Features

Le implementazioni dei dispositivi DEVONO garantire la conformità alle funzionalità di sicurezza sia nel kernel sia nella piattaforma, come descritto di seguito.

La sandbox Android include funzionalità che utilizzano il sistema di controllo dell'accesso obbligatorio (MAC) Security-Enhanced Linux (SELinux), il sandboxing seccomp e altre funzionalità di sicurezza nel kernel Linux. Implementazioni del dispositivo:

• [C-0-1] DEVE mantenere la compatibilità con le applicazioni esistenti, anche quando SELinux o altre funzionalità di sicurezza sono implementate al di sotto del framework Android.
• [C-0-2] NON DEVE avere un'interfaccia utente visibile quando viene rilevata e bloccata correttamente una violazione della sicurezza dalla funzionalità di sicurezza implementata sotto il framework Android, ma PUÒ avere un'interfaccia utente visibile quando si verifica una violazione della sicurezza non bloccata che comporta un exploit riuscito.
• [C-0-3] NON DEVE rendere SELinux o altre funzionalità di sicurezza implementate al di sotto del framework Android configurabili per l'utente o lo sviluppatore di app.
• [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 compromette la compatibilità.
• [C-0-5] DEVE dividere il framework multimediale in più processi in modo da poter concedere l'accesso in modo più specifico per ogni processo, come descritto nel sito di Android Open Source Project.
• [C-0-6] DEVE implementare un meccanismo di sandboxing delle applicazioni del kernel che consenta il filtraggio delle chiamate di sistema utilizzando un criterio configurabile da programmi multithread. L'Android Open Source Project upstream soddisfa questo requisito attivando seccomp-BPF con la sincronizzazione del gruppo di thread (TSYNC) come descritto nella sezione Kernel Configuration di source.android.com.

Le funzionalità di integrità e autoprotezione del kernel sono parte integrante della sicurezza di Android. Implementazioni del dispositivo:

• [C-0-7] DEVE implementare protezioni dal buffer overflow dello stack del kernel (ad es. CONFIG_CC_STACKPROTECTOR_STRONG).
• [C-0-8] DEVE implementare protezioni rigorose della memoria del kernel in cui il codice eseguibile è di sola lettura, i dati di sola lettura non sono eseguibili e non sono scrivibili e i dati scrivibili non sono eseguibili (ad es. CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] DEVE implementare il controllo dei limiti delle dimensioni degli oggetti statici e dinamici delle copie tra lo spazio utente e lo spazio kernel (ad es. CONFIG_HARDENED_USERCOPY) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
• [C-0-10] NON DEVE eseguire la memoria dello spazio utente durante l'esecuzione in modalità kernel (ad es. PXN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
• [C-0-11] NON DEVE leggere o scrivere nella memoria dello spazio utente nel kernel al di fuori delle normali API di accesso usercopy (ad es. PAN hardware o emulato tramite CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) sui dispositivi originariamente forniti con il livello API 28 o versioni successive.
• [C-0-12] DEVE implementare l'isolamento della tabella delle pagine del kernel su tutti i dispositivi forniti originariamente con il livello API 28 o versioni successive (ad es. CONFIG_PAGE_TABLE_ISOLATION o `CONFIG_UNMAP_KERNEL_AT_EL0`).
• [SR] STRONGLY RECOMMENDED to keep kernel data which is written only during initialization marked read-only after initialization (e.g. __ro_after_init).
• [SR] VIVAMENTE CONSIGLIATO di randomizzare il layout del codice kernel e della memoria ed evitare esposizioni che comprometterebbero la randomizzazione (ad es. CONFIG_RANDOMIZE_BASE con entropia del bootloader tramite /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).

Se le implementazioni dei dispositivi utilizzano un kernel Linux:

• [C-1-1] DEVE implementare SELinux.
• [C-1-2] DEVE impostare SELinux sulla modalità di applicazione globale.
• [C-1-3] MUST configure all domains in enforcing mode. Non sono consentiti domini in modalità permissiva, inclusi i domini specifici di un dispositivo/fornitore.
• [C-1-4] NON DEVE modificare, omettere o sostituire le regole neverallow presenti nella cartella system/sepolicy fornita nel progetto Android Open Source Project (AOSP) upstream e il criterio DEVE essere compilato con tutte le regole neverallow presenti, sia per i domini SELinux AOSP sia per i domini specifici del dispositivo/fornitore.
• [C-1-5] DEVONO eseguire applicazioni di terze parti che hanno come target il livello API 28 o superiore in sandbox SELinux per applicazione con restrizioni SELinux per app sulla directory dei dati privati di ogni applicazione.
• DEVE conservare il criterio SELinux predefinito fornito nella cartella system/sepolicy del progetto Android Open Source e aggiungervi solo la propria configurazione specifica del dispositivo.

Se le implementazioni dei dispositivi sono già state lanciate su una versione precedente di Android e non soddisfano i requisiti [C-1-1] e [C-1-5] tramite un aggiornamento del software di sistema, POSSONO essere esentate da questi requisiti.

Se le implementazioni dei dispositivi utilizzano un kernel diverso da Linux:

• [C-2-1] DEVE utilizzare un sistema di controllo dell'accesso obbligatorio equivalente a SELinux.

Android include diverse funzionalità di difesa in profondità che sono parte integrante della sicurezza del dispositivo.

Implementazioni del dispositivo:

• [C-SR] È VIVAMENTE CONSIGLIATO di non disattivare l'integrità del flusso di controllo (CFI) o la sanificazione dell'overflow di interi (IntSan) sui componenti su cui è attivata.
• [C-SR] È FORTEMENTE CONSIGLIATO attivare sia CFI che IntSan per qualsiasi componente aggiuntivo dello spazio utente sensibile alla sicurezza, come spiegato in CFI e IntSan.

9.8. Privacy

9.8.1. Cronologia di utilizzo

Android memorizza la cronologia delle scelte dell'utente e la gestisce tramite UsageStatsManager.

Implementazioni del dispositivo:

• [C-0-1] DEVE mantenere un periodo di conservazione ragionevole di questa cronologia utente.
• [SR] È VIVAMENTE CONSIGLIATO di mantenere il periodo di conservazione di 14 giorni configurato per impostazione predefinita nell'implementazione AOSP.

Android archivia gli eventi di sistema utilizzando gli identificatori StatsLog e gestisce la cronologia tramite l'API di sistema StatsManager e IncidentManager.

Implementazioni del dispositivo:

• [C-0-2] DEVE includere solo i campi contrassegnati con DEST_AUTOMATIC nella segnalazione di un problema creata dalla classe API di sistema IncidentManager.
• [C-0-3] NON DEVE utilizzare gli identificatori di eventi di sistema per registrare eventi diversi da quelli descritti nei documenti dell'SDK StatsLog. Se vengono registrati eventi di sistema aggiuntivi, questi POTREBBERO utilizzare un identificatore atomo diverso nell'intervallo compreso tra 100.000 e 200.000.

9.8.2. Registrazione

Implementazioni del dispositivo:

• [C-0-1] NON DEVE precaricare o distribuire componenti software pronti all'uso che inviano informazioni private dell'utente (ad es. sequenze di tasti, testo visualizzato sullo schermo) dal dispositivo senza il consenso dell'utente o senza notifiche chiare e continue.

Se le implementazioni del dispositivo includono funzionalità nel sistema che acquisiscono i contenuti visualizzati sullo schermo e/o registrano il flusso audio riprodotto sul dispositivo:

• [C-1-1] DEVE mostrare una notifica continua all'utente ogni volta che questa funzionalità è abilitata e sta acquisendo/registrando attivamente.

Se le implementazioni dei dispositivi includono un componente abilitato out-of-box, in grado di registrare l'audio ambientale per dedurre informazioni utili sul contesto dell'utente:

• [C-2-1] NON DEVE memorizzare in modo permanente nella memoria del dispositivo o trasmettere al di fuori del dispositivo l'audio grezzo registrato o qualsiasi formato che possa essere riconvertito nell'audio originale o in una copia quasi esatta, se non con il consenso esplicito dell'utente.

9.8.3. Connettività

Se le implementazioni dei dispositivi hanno una porta USB con supporto della modalità periferica USB:

• [C-1-1] DEVE presentare un'interfaccia utente che chieda il consenso dell'utente prima di consentire l'accesso ai contenuti dello spazio di archiviazione condiviso tramite la porta USB.

9.8.4. Traffico di rete

Implementazioni del dispositivo:

• [C-0-1] DEVE preinstallare gli stessi certificati radice per l'archivio delle autorità di certificazione (CA) attendibili dal sistema come fornito nel progetto open source Android upstream.
• [C-0-2] MUST ship with an empty user root CA store.
• [C-0-3] DEVE mostrare un avviso all'utente che indica che il traffico di rete potrebbe essere monitorato quando viene aggiunta una CA radice utente.

Se il traffico del dispositivo viene indirizzato tramite una VPN, le implementazioni del dispositivo:

• [C-1-1] DEVE mostrare all'utente un avviso che indica:
  • Il traffico di rete potrebbe essere monitorato.
  • Il traffico di rete viene instradato tramite l'applicazione VPN specifica che fornisce la VPN.

Se le implementazioni dei dispositivi hanno un meccanismo, attivato per impostazione predefinita, che indirizza il traffico di dati di rete tramite un server proxy o un gateway VPN (ad esempio, il precaricamento di un servizio VPN con android.permission.CONTROL_VPN concesso), allora:

• [C-2-1] DEVE chiedere il consenso dell'utente prima di attivare questo meccanismo, a meno che la VPN non sia attivata dal controller delle norme del dispositivo tramite DevicePolicyManager.setAlwaysOnVpnPackage() , nel qual caso l'utente non deve fornire un consenso separato, ma DEVE solo ricevere una notifica.

Se le implementazioni del dispositivo implementano una funzionalità utente per attivare/disattivare la funzione "VPN sempre attiva" di un'app VPN di terze parti:

• [C-3-1] DEVE disattivare questa funzionalità per le app che non supportano il servizio VPN sempre attiva nel file AndroidManifest.xml impostando l'attributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON su false.

9.9. Crittografia dell'archiviazione dei dati

Se le prestazioni di 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 privati dell'applicazione (partizione /data), nonché della partizione di archiviazione condivisa dell'applicazione (partizione /sdcard) se è una parte permanente e non rimovibile del dispositivo, ad eccezione delle implementazioni del dispositivo che vengono in genere condivise (ad es. la televisione).
• [C-1-2] DEVE attivare la crittografia dell'archiviazione dei dati per impostazione predefinita al termine della configurazione guidata, ad eccezione delle implementazioni del dispositivo che vengono in genere condivise (ad es. la televisione).

Se le prestazioni di crittografia AES sono pari o inferiori a 50 MiB/sec, le implementazioni del dispositivo POSSONO utilizzare Adiantum-XChaCha12-AES anziché la forma di AES elencata in uno dei seguenti elementi: 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 esentate dai requisiti di cui sopra.

Implementazioni del dispositivo:

• DEVE soddisfare il requisito di crittografia dell'archiviazione dei dati sopra indicato implementando la crittografia basata su file (FBE).

9.9.1. Avvio diretto

Implementazioni del dispositivo:

• [C-0-1] DEVE implementare le API della modalità Avvio diretto anche se non supportano la crittografia dell'archiviazione.

• [C-0-2] Gli intent ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED DEVONO comunque essere trasmessi per segnalare alle applicazioni compatibili con l'avvio diretto che le posizioni di archiviazione con crittografia del dispositivo (DE) e 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 le credenziali all'utente e consentire alle app compatibili con l'avvio diretto di accedere allo spazio di archiviazione con crittografia del dispositivo (DE) dopo la trasmissione del messaggio ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] DEVE consentire l'accesso allo spazio di archiviazione Credential Encrypted (CE) solo dopo che l'utente ha sbloccato il dispositivo fornendo le proprie credenziali (ad es. passcode, PIN, sequenza o impronta) e viene trasmesso il messaggio ACTION_USER_UNLOCKED.
• [C-1-3] NON DEVE offrire alcun metodo per sbloccare lo spazio di archiviazione protetto da CE senza le credenziali fornite dall'utente o una chiave di deposito a garanzia registrata.
• [C-1-4] DEVE supportare l'Avvio verificato e garantire che le chiavi DE siano associate in modo crittografico alla radice di attendibilità hardware del dispositivo.
• [C-1-5] DEVE supportare la crittografia dei contenuti dei file utilizzando AES-256-XTS. AES-256-XTS si riferisce all'Advanced Encryption Standard con una lunghezza della chiave di 256 bit, utilizzato in modalità XTS. La lunghezza completa della chiave XTS è di 512 bit.

• [C-1-6] DEVE supportare la crittografia dei nomi dei 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 vincolate alle credenziali della schermata di blocco di un utente.
• [C-1-9] Le chiavi CE DEVONO essere associate a un passcode predefinito quando l'utente non ha specificato le credenziali della schermata di blocco.

• [C-1-10] DEVE essere univoca e distinta, in altre parole la chiave CE o DE di un utente non corrisponde a quella di un altro utente.

• [C-1-11] DEVE utilizzare per impostazione predefinita le cifrature, le lunghezze delle chiavi e le modalità supportate obbligatoriamente.

• [C-SR] È FORTEMENTE CONSIGLIATO criptare i metadati del file system, come dimensioni, proprietà, modalità e attributi estesi (xattr), con una chiave crittograficamente associata alla radice di attendibilità hardware del dispositivo.

• DOVREBBE rendere le app essenziali preinstallate (ad es. Sveglia, Telefono, Messenger) compatibili con l'avvio diretto.

• POTREBBE supportare cifrari, lunghezze delle chiavi e modalità alternative per la crittografia dei contenuti e del nome 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),

• [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 eseguire 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] DEVE criptare la chiave di crittografia 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 estese utilizzando un algoritmo di estensione lento (ad es. PBKDF2 o scrypt).
• [C-1-4] L'algoritmo di stretching della password predefinito sopra indicato DEVE essere associato in modo crittografico a questo keystore quando l'utente non ha specificato credenziali della schermata di blocco o ha disattivato l'utilizzo del passcode per la crittografia e il dispositivo fornisce un keystore basato sull'hardware.
• [C-1-5] NON DEVE inviare la chiave di crittografia al di fuori del dispositivo (anche se è protetta dal passcode utente e/o dalla chiave associata 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 del dispositivo:

• [C-0-1] DEVE segnalare correttamente tramite il metodo dell'API di sistema PersistentDataBlockManager.getFlashLockState() se lo stato del bootloader consente il flashing dell'immagine di sistema. Lo stato FLASH_LOCK_UNKNOWN è riservato alle implementazioni dei dispositivi che eseguono l'upgrade da una versione precedente di Android in cui questo nuovo metodo API di sistema non esisteva.

• [C-0-2] DEVE supportare l'Avvio verificato per l'integrità del dispositivo.

Se le implementazioni dei dispositivi sono già state lanciate senza supportare l'Avvio verificato su una versione precedente di Android e non possono aggiungere il supporto per questa funzionalità con un aggiornamento del software di sistema, POTREBBERO essere esentate dal requisito.

L'Avvio verificato è una funzionalità che garantisce l'integrità del software del dispositivo. Se le implementazioni dei dispositivi supportano la funzionalità:

• [C-1-1] DEVE dichiarare il flag della funzionalità della piattaforma android.software.verified_boot.
• [C-1-2] DEVE eseguire la verifica a ogni sequenza di avvio.
• [C-1-3] DEVE avviare la verifica da una chiave hardware immutabile che è la radice di attendibilità e arrivare fino alla partizione di sistema.
• [C-1-4] DEVE implementare ogni fase di verifica per controllare l'integrità e l'autenticità di tutti i byte nella fase successiva prima di eseguire il codice nella fase successiva.
• [C-1-5] DEVE utilizzare algoritmi di verifica efficaci quanto le attuali raccomandazioni del NIST per gli algoritmi di hashing (SHA-256) e le dimensioni delle chiavi pubbliche (RSA-2048).
• [C-1-6] NON DEVE consentire il completamento dell'avvio quando la verifica del sistema non va a buon fine, a meno che l'utente non acconsenta a tentare comunque l'avvio, nel qual caso i dati di eventuali blocchi di archiviazione non verificati NON DEVONO essere utilizzati.
• [C-1-7] NON DEVE consentire la modifica delle partizioni verificate sul dispositivo, a meno che l'utente non abbia sbloccato esplicitamente il bootloader.
• [C-SR] Se nel dispositivo sono presenti più chip discreti (ad es. radio, processore di immagini specializzato), è VIVAMENTE CONSIGLIATO verificare ogni fase del processo di avvio di ciascun chip.
• [C-1-8] DEVE utilizzare un'archiviazione antimanomissione: per memorizzare se il bootloader è sbloccato. L'archiviazione a prova di manomissione significa che il bootloader può rilevare se l'archiviazione è stata manomessa dall'interno di Android.
• [C-1-9] DEVE richiedere all'utente, durante l'utilizzo del dispositivo, una conferma fisica prima di consentire la transizione dalla modalità di bootloader bloccato alla modalità di bootloader sbloccato.
• [C-1-10] DEVE implementare la protezione dal rollback per le partizioni utilizzate da Android (ad es. partizioni di avvio e di sistema) e utilizzare l'archiviazione antimanomissione per memorizzare i metadati utilizzati per determinare la versione minima consentita del sistema operativo.
• [C-SR] È FORTEMENTE CONSIGLIATO verificare tutti i file APK delle app con privilegi con una catena di attendibilità basata su /system, che è protetta da Avvio verificato.
• [C-SR] È VIVAMENTE CONSIGLIATO di verificare gli artefatti eseguibili caricati da un'app con privilegi dall'esterno del file APK (ad esempio codice caricato dinamicamente o codice compilato) prima di eseguirli o È VIVAMENTE CONSIGLIATO di non eseguirli affatto.
• DEVE implementare la protezione dal rollback per qualsiasi componente con firmware persistente (ad es. modem, fotocamera) e DEVE utilizzare l'archiviazione 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 e C-1-10 su una versione precedente di Android e non è possibile aggiungere il supporto per questi requisiti con un aggiornamento del software di sistema, POTREBBERO essere esentate dai requisiti.

Il progetto open source Android upstream fornisce un'implementazione preferita di questa funzionalità nel repository external/avb/, che può essere integrata nel bootloader utilizzato per caricare Android.

Implementazioni del dispositivo:

• [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] MUST report true for the ConfirmationPrompt.isSupported() API.
• [C-3-2] DEVE garantire che l'hardware sicuro assuma il pieno controllo del display in modo che il sistema operativo Android non possa bloccarlo senza essere rilevato dall'hardware sicuro.
• [C-3-3] DEVE garantire 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 del dispositivo:

• [C-0-1] DEVE consentire l'importazione o la generazione di almeno 8192 chiavi.
• [C-0-2] L'autenticazione della schermata di blocco DEVE limitare la frequenza dei tentativi e DEVE avere un algoritmo di backoff esponenziale. Oltre 150 tentativi non riusciti, il ritardo DEVE essere di almeno 24 ore per tentativo.
• Non deve limitare il numero di chiavi che possono essere generate

Quando l'implementazione del dispositivo supporta una schermata di blocco sicura:

• [C-1-1] DEVE eseguire il backup dell'implementazione del keystore con un ambiente di esecuzione isolato.
• [C-1-2] DEVE avere implementazioni degli algoritmi crittografici RSA, AES, ECDSA e HMAC e delle funzioni hash MD5, SHA1 e SHA-2 per supportare correttamente gli algoritmi supportati dal sistema Android Keystore in un'area isolata in modo sicuro dal codice in esecuzione sul kernel e versioni successive. L'isolamento sicuro DEVE bloccare tutti i potenziali meccanismi mediante i quali il codice del kernel o dello spazio utente potrebbe accedere allo stato interno dell'ambiente isolato, incluso il DMA. Il progetto open source Android (AOSP) upstream soddisfa questo requisito utilizzando l'implementazione Trusty, ma un'altra soluzione basata su ARM TrustZone o un'implementazione sicura di terze parti di un isolamento basato su 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 ha esito positivo, consentire l'utilizzo delle chiavi associate all'autenticazione. Le credenziali della schermata di blocco DEVONO essere memorizzate in modo da consentire solo all'ambiente di esecuzione isolato di eseguire l'autenticazione della schermata di blocco. Il progetto Android Open Source Project upstream fornisce l'Hardware Abstraction Layer (HAL) 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 di dispositivo. Un modo per soddisfare questo requisito è condividere la stessa chiave di attestazione,a meno che non vengano prodotte almeno 100.000 unità di un determinato SKU. Se vengono prodotte più di 100.000 unità di uno SKU, POTREBBE essere utilizzata una chiave diversa per ogni 100.000 unità.
• [C-1-5] DEVE consentire all'utente di scegliere il timeout di sospensione per la transizione dallo stato sbloccato a quello bloccato, con un timeout minimo consentito fino a 15 secondi.

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

9.11.1. Schermata di blocco sicura

L'implementazione di AOSP segue un modello di autenticazione a più livelli in cui l'autenticazione primaria basata su un fattore di conoscenza può essere supportata da una biometria secondaria forte o da modalità terziarie più deboli.

Implementazioni del dispositivo:

• [C-SR] È VIVAMENTE CONSIGLIATO di impostare solo uno dei seguenti metodi come metodo di autenticazione principale:
  • Un PIN numerico
  • Una password alfanumerica
  • Un pattern di scorrimento su una griglia di esattamente 3x3 punti

Tieni presente che i metodi di autenticazione sopra indicati sono indicati in questo documento come metodi di autenticazione principali consigliati.

Se le implementazioni dei dispositivi aggiungono o modificano i metodi di autenticazione principali consigliati e utilizzano un nuovo metodo di autenticazione come modo sicuro per bloccare lo schermo, il nuovo metodo di autenticazione:

• [C-2-1] DEVE essere il metodo di autenticazione dell'utente descritto in Richiedere l'autenticazione dell'utente per l'utilizzo della chiave.
• [C-2-2] DEVE sbloccare tutte le chiavi per l'utilizzo da parte di un'app di sviluppatori di terze parti quando l'utente sblocca la schermata di blocco sicura. Ad esempio, tutte le chiavi DEVONO essere disponibili per un'app di 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 basati su un segreto noto e utilizzano un nuovo metodo di autenticazione da trattare come un modo sicuro per bloccare lo schermo:

• [C-3-1] L'entropia della lunghezza minima consentita degli input DEVE essere maggiore di 10 bit.
• [C-3-2] L'entropia massima di tutti gli input possibili DEVE essere maggiore di 18 bit.
• [C-3-3] Il nuovo metodo di autenticazione NON DEVE sostituire nessuno dei metodi di autenticazione principali consigliati (ad es. PIN, sequenza, password) implementati e forniti in AOSP.
• [C-3-4] Il nuovo metodo di autenticazione DEVE essere disattivato quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_SOMETHING.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione principali consigliati per sbloccare la schermata di blocco e utilizzano un nuovo metodo di autenticazione basato sulla biometria da 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 disporre di un meccanismo di fallback per utilizzare uno dei metodi di autenticazione principali consigliati basati su un segreto noto.
• [C-4-3] DEVE essere disattivato e consentire solo l'autenticazione principale consigliata per sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio della funzionalità di protezione delle chiavi chiamando il metodo DevicePolicyManager.setKeyguardDisabledFeatures() con uno qualsiasi dei flag biometrici associati (ad es. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE o KEYGUARD_DISABLE_IRIS).
• [C-4-4] DEVE richiedere all'utente l'autenticazione principale consigliata (ad es. PIN, sequenza, password) almeno una volta ogni 72 ore o meno.
• [C-4-5] DEVE avere un tasso di falsa accettazione uguale o superiore a quello richiesto per un sensore di impronte digitali, come descritto nella sezione sezione 7.3.10, oppure 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 che abbiano tassi di accettazione di spoofing e impostori uguali o superiori a quelli richiesti per un sensore di impronte digitali, come descritto nella sezione 7.3.10.
• [C-4-6] DEVE disporre di una pipeline di elaborazione sicura in modo che la compromissione di un sistema operativo o di un kernel non possa consentire l'inserimento diretto di dati per l'autenticazione fraudolenta come utente.
• [C-4-7] DEVE essere abbinato 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 la biometria è passiva (ad es. volto o iride in cui non esiste un segnale esplicito di intento).
• [C-SR] L'azione di conferma per la biometria passiva è FORTEMENTE CONSIGLIATA per essere protetta in modo che una compromissione del sistema operativo o del kernel non possa falsificarla. Ad esempio, ciò significa che l'azione di conferma basata su un pulsante fisico viene indirizzata tramite un pin di input/output (GPIO) per uso generico solo di input di un Secure Element (SE) che non può essere azionato in altro modo se non premendo un pulsante fisico.

Se i metodi di autenticazione biometrica non soddisfano i tassi di accettazione di spoofing e impostori descritti nella sezione 7.3.10:

• [C-5-1] I metodi DEVONO essere disattivati se l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] All'utente DEVE essere richiesta l'autenticazione principale consigliata (ad es. PIN, sequenza, password) dopo un periodo di timeout di inattività di 4 ore. Il periodo di timeout di inattività viene reimpostato dopo qualsiasi conferma riuscita delle credenziali del dispositivo.
• [C-5-3] I metodi NON DEVONO essere trattati come una schermata di blocco sicura e DEVONO soddisfare i requisiti che iniziano con C-8 nella sezione seguente.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco e un nuovo metodo di autenticazione si basa su un token fisico o sulla posizione:

• [C-6-1] Deve essere presente un meccanismo di fallback per utilizzare uno dei metodi di autenticazione principali consigliati, basato su un segreto noto e che soddisfi i requisiti per essere considerato una schermata di blocco sicura.
• [C-6-2] Il nuovo metodo DEVE essere disattivato e consentire solo a uno dei metodi di autenticazione principale consigliati di sbloccare lo schermo quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio con il metodo DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] All'utente DEVE essere richiesta una delle modalità di autenticazione principale consigliate (ad es. PIN, sequenza, password) almeno una volta ogni 72 ore o meno.
• [C-6-4] Il nuovo metodo NON DEVE essere trattato come una schermata di blocco sicura e DEVE rispettare i vincoli elencati in C-8 di seguito.

Se le implementazioni del dispositivo hanno una schermata di blocco sicura e includono uno o più 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 è posticipato o può essere sbloccato da uno o più trust agent. Ad esempio, AOSP soddisfa questo requisito mostrando una descrizione testuale per le impostazioni "Blocco automatico" e "Tasto di accensione blocca istantaneamente" nel menu delle impostazioni e un'icona distinguibile nella schermata di blocco.
• [C-7-2] DEVE rispettare e implementare completamente tutte le API dell'agente 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. dispositivo portatile), ma PUÒ implementare completamente la funzione su implementazioni di dispositivi che vengono in genere condivise (ad es. Android TV o dispositivo per auto).
• [C-7-4] DEVE criptare tutti i token archiviati aggiunti da TrustAgentService.addEscrowToken().
• [C-7-5] NON DEVE archiviare la chiave di crittografia sullo stesso dispositivo in cui viene utilizzata. Ad esempio, è consentito a una chiave memorizzata su uno smartphone sbloccare un account utente su una TV.
• [C-7-6] DEVE informare l'utente delle implicazioni per la sicurezza prima di attivare il token di deposito a garanzia per decriptare l'archiviazione dei dati.
• [C-7-7] DEVE disporre di un meccanismo di riserva per utilizzare uno dei metodi di autenticazione principali consigliati.
• [C-7-8] All'utente DEVE essere richiesta l'autenticazione primaria consigliata (ad es. PIN, sequenza, password) almeno una volta ogni 72 ore o meno.
• [C-7-9] Dopo un periodo di inattività di 4 ore, all'utente DEVE essere richiesta l'autenticazione primaria consigliata (ad es. PIN, sequenza, password). Il periodo di timeout di inattività viene reimpostato dopo qualsiasi conferma riuscita delle credenziali del dispositivo.
• [C-7-10] NON DEVE essere trattato come una schermata di blocco sicura e DEVE rispettare i vincoli elencati in C-8 di seguito.

Se le implementazioni del dispositivo aggiungono o modificano i metodi di autenticazione per sbloccare la schermata di blocco che non è una schermata di blocco sicura come descritto sopra e utilizzano un nuovo metodo di autenticazione per sbloccare il keyguard:

• [C-8-1] Il nuovo metodo DEVE essere disattivato quando l'applicazione Device Policy Controller (DPC) ha impostato il criterio di qualità della password tramite il metodo DevicePolicyManager.setPasswordQuality() con una costante di qualità più restrittiva di PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] NON DEVONO reimpostare i timer di scadenza della password impostati da DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] NON DEVE autenticare l'accesso ai keystore 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 in precedenza.

Implementazioni del dispositivo:

• [C-SR] Sono VIVAMENTE CONSIGLIATI per supportare StrongBox.

Se le implementazioni dei dispositivi supportano StrongBox:

• [C-1-1] DEVE dichiarare FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] DEVE fornire un hardware sicuro dedicato utilizzato per il keystore e l'autenticazione utente sicura.

• [C-1-3] DEVE avere una CPU discreta che non condivida cache, DRAM, coprocessori o altre risorse di core con il processore dell'applicazione (AP).

• [C-1-4] DEVE garantire che qualsiasi periferica condivisa con l'AP non possa alterare in alcun modo l'elaborazione di StrongBox o ottenere informazioni da StrongBox. L'amministratore di Google Workspace potrebbe disattivare o bloccare l'accesso a StrongBox.

• [C-1-5] DEVE avere un orologio interno con una precisione ragionevole (+/-10%) immune alla manipolazione da parte dell'AP.

• [C-1-6] DEVE disporre di un generatore di numeri casuali che produca un output distribuito in modo uniforme e imprevedibile.

• [C-1-7] DEVE essere a prova di manomissione, inclusa la resistenza alla penetrazione fisica e ai malfunzionamenti.

• [C-1-8] DEVE essere resistente agli attacchi side-channel, inclusa la resistenza alla divulgazione di informazioni tramite i canali secondari di alimentazione, temporizzazione, radiazione elettromagnetica e radiazione termica.

• [C-1-9] DEVE disporre di un archivio sicuro che garantisca riservatezza, integrità, autenticità, coerenza e aggiornamento dei contenuti. L'archivio NON DEVE poter essere letto o modificato, ad eccezione di quanto consentito dalle API StrongBox.

• Per convalidare la conformità ai requisiti [C-1-3] - [C-1-9], le implementazioni dei dispositivi:

  • [C-1-10] DEVE includere l'hardware certificato in base al profilo di protezione IC sicuro BSI-CC-PP-0084-2014 o valutato da un laboratorio di test accreditato a livello nazionale che incorpora la valutazione della vulnerabilità con potenziale di attacco elevato in base ai Common Criteria Application of Attack Potential to Smartcards.
  • [C-1-11] DEVE includere il firmware valutato da un laboratorio di test accreditato a livello nazionale che incorpora la valutazione della vulnerabilità con elevato potenziale di attacco in base ai Common Criteria Application of Attack Potential to Smartcards.
  • [C-SR] È FORTEMENTE CONSIGLIATO includere l'hardware valutato utilizzando un Security Target, un livello di garanzia di valutazione (EAL) 5, aumentato da AVA_VAN.5. È probabile che la certificazione EAL 5 diventerà un requisito in una release futura.

• [C-SR] sono FORTEMENTE CONSIGLIATI per fornire resistenza agli attacchi interni (IAR), il che significa che un insider con accesso alle chiavi di firma del firmware non può produrre firmware che causino la perdita di segreti da parte di StrongBox, che aggirino i requisiti di sicurezza funzionali o che consentano in altro modo l'accesso a dati utente sensibili. Il modo consigliato per implementare IAR è consentire gli aggiornamenti firmware solo quando la password dell'utente principale viene fornita tramite IAuthSecret HAL.

9.12. Eliminazione dei dati

Tutte le implementazioni dei dispositivi:

• [C-0-1] DEVE fornire agli utenti un meccanismo per eseguire un "Ripristino dei dati di fabbrica".
• [C-0-2] È NECESSARIO eliminare tutti i dati generati dagli utenti. ovvero tutti i dati, ad eccezione di:
  • L'immagine di sistema
  • Qualsiasi file del sistema operativo richiesto dall'immagine di sistema
• [C-0-3] DEVE eliminare i dati in modo da soddisfare gli standard di settore pertinenti, ad esempio NIST SP800-88.
• [C-0-4] DEVE attivare la procedura di "Ripristino dei dati di fabbrica" di cui sopra quando l'API DevicePolicyManager.wipeData() viene chiamata dall'app Policy Controller dei dispositivi dell'utente principale.
• POTREBBE fornire un'opzione di cancellazione rapida dei dati che esegue solo un'eliminazione logica dei dati.

9.13. Modalità di avvio sicuro

Android fornisce la modalità provvisoria, che consente agli utenti di avviare il dispositivo in una modalità in cui è consentita l'esecuzione solo delle app di sistema preinstallate e tutte le app di terze parti sono disattivate. Questa modalità, nota come "modalità di avvio sicuro", consente all'utente di disinstallare app di terze parti potenzialmente dannose.

Le implementazioni del dispositivo sono:

• [SR] VIVAMENTE CONSIGLIATO di implementare la modalità provvisoria.

Se le implementazioni dei dispositivi implementano la modalità di avvio protetto:

• [C-1-1] DEVE fornire all'utente un'opzione per accedere alla modalità provvisoria in modo non interrompibile da app di terze parti installate sul dispositivo, tranne quando l'app di terze parti è un controller delle norme relative ai dispositivi e ha impostato il flag UserManager.DISALLOW_SAFE_BOOT su true.

• [C-1-2] DEVE fornire all'utente la possibilità di disinstallare app di terze parti in modalità provvisoria.

• DEVE fornire all'utente un'opzione per accedere alla modalità di avvio sicuro dal menu di avvio utilizzando un flusso di lavoro diverso da quello di un avvio normale.

9.14. Isolamento del sistema del veicolo

I dispositivi Android Automotive dovrebbero scambiare dati con i sottosistemi critici del veicolo utilizzando l'Vehicle HAL per inviare e ricevere messaggi tramite le reti del veicolo, come il bus CAN.

Lo scambio di dati può essere protetto implementando funzionalità di sicurezza al di sotto dei livelli del framework Android per impedire interazioni dannose o involontarie con questi sottosistemi.

9.15. Piani di abbonamento

"Piani di abbonamento" si riferisce ai dettagli del piano di fatturazione forniti da un operatore di telefonia mobile tramite SubscriptionManager.setSubscriptionPlans().

Tutte le implementazioni dei dispositivi:

• [C-0-1] DEVE restituire i piani di abbonamento solo all'app dell'operatore di telefonia mobile che li ha forniti originariamente.
• [C-0-2] NON DEVE eseguire il backup o caricare da remoto i piani di abbonamento.
• [C-0-3] DEVE consentire solo gli override, ad esempio SubscriptionManager.setSubscriptionOverrideCongested(), dall'app dell'operatore di telefonia mobile che attualmente fornisce piani in abbonamento validi.

10. Test di compatibilità del software

Le implementazioni dei dispositivi DEVONO superare tutti i test descritti in questa sezione. Tuttavia, tieni presente che nessun pacchetto di test software è completamente esaustivo. Per questo motivo, è FORTEMENTE CONSIGLIATO agli implementatori di dispositivi apportare il minor numero possibile di modifiche all'implementazione di riferimento e preferita di Android disponibile da Android Open Source Project. In questo modo, ridurrai al minimo il rischio di introdurre bug che creano incompatibilità che richiedono rielaborazioni e potenziali aggiornamenti del dispositivo.

10.1. Compatibility Test Suite (CTS)

Implementazioni del dispositivo:

• [C-0-1] DEVE superare la suite di test di compatibilità Android (CTS) disponibile nell'Android Open Source Project, utilizzando il software di spedizione finale sul dispositivo.

• [C-0-2] DEVE garantire la compatibilità in caso di ambiguità nel CTS e per qualsiasi reimplementazione di parti del codice sorgente di riferimento.

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi software, il CTS potrebbe contenere bug. La suite di test di compatibilità (CTS) avrà una versione indipendente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni della CTS per Android 9.

Implementazioni del dispositivo:

• [C-0-3] DEVE superare l'ultima versione di CTS disponibile al momento del completamento del software del dispositivo.

• DEVE utilizzare l'implementazione di riferimento nell'albero Android Open Source il più possibile.

10.2. Strumento di verifica CTS

CTS Verifier è incluso in Compatibility Test Suite e deve essere eseguito da un operatore umano per testare funzionalità che non possono essere testate da un sistema automatizzato, come il corretto funzionamento di una fotocamera e dei sensori.

Implementazioni del dispositivo:

• [C-0-1] DEVE eseguire correttamente tutti i casi applicabili nel programma di verifica CTS.

CTS Verifier include test per molti tipi di hardware, tra cui alcuni hardware opzionali.

Implementazioni del dispositivo:

• [C-0-2] DEVE superare tutti i test per l'hardware in suo possesso; ad esempio, se un dispositivo possiede un accelerometro, DEVE eseguire correttamente lo scenario di test dell'accelerometro in CTS Verifier.

Gli scenari di test per le funzionalità indicate come facoltative in questo Compatibility Definition Document POSSONO essere ignorati o omessi.

• [C-0-2] Ogni dispositivo e ogni build DEVE eseguire correttamente CTS Verifier, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori di dispositivi eseguano esplicitamente CTS Verifier su build che differiscono solo in modo banale. Nello specifico, le implementazioni del dispositivo che differiscono da un'implementazione che ha superato il CTS Verifier solo per l'insieme di impostazioni internazionali, brand e così via INCLUDONO il test CTS Verifier.

11. Software aggiornabile

• [C-0-1] Le implementazioni del dispositivo DEVONO includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire upgrade "live", ovvero potrebbe essere necessario riavviare il dispositivo. Può essere utilizzato qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, uno qualsiasi dei seguenti approcci soddisferà questo requisito:

  • Download "over-the-air (OTA)" con aggiornamento offline tramite riavvio.
  • Aggiornamenti "in tethering" tramite USB da un PC host.
  • Aggiornamenti "offline" tramite riavvio e aggiornamento da un file su un dispositivo di archiviazione rimovibile.

• [C-0-2] Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. ovvero il meccanismo di aggiornamento DEVE preservare i dati privati 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 senza limiti, ad esempio 802.11 o il profilo PAN (Personal Area Network) Bluetooth, allora:

• [C-1-1] DEVE supportare i download OTA con aggiornamento offline tramite riavvio.

Per le implementazioni dei dispositivi che vengono lanciate con Android 6.0 e versioni successive, il meccanismo di aggiornamento DOVREBBE supportare la verifica che l'immagine di sistema sia identica al risultato previsto dopo un aggiornamento OTA. L'implementazione OTA basata su blocchi nel progetto Android Open Source upstream, aggiunta a partire da Android 5.1, soddisfa questo requisito.

Inoltre, le implementazioni dei dispositivi DEVONO supportare gli aggiornamenti di sistema A/B. AOSP implementa questa funzionalità utilizzando l'HAL di controllo dell'avvio.

Se viene rilevato un errore nell'implementazione di un dispositivo dopo il suo rilascio, ma entro la sua ragionevole durata del prodotto, che viene determinata in consultazione con il team di compatibilità Android per influire sulla compatibilità delle applicazioni di terze parti, allora:

• [C-2-1] L'implementatore del dispositivo DEVE correggere l'errore tramite un aggiornamento software disponibile che può essere applicato secondo il meccanismo appena descritto.

Android include funzionalità che consentono all'app Proprietario del dispositivo (se presente) di controllare l'installazione degli aggiornamenti di sistema. Se il sottosistema di aggiornamento di sistema per i dispositivi segnala android.software.device_admin, significa che:

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

12. Log delle modifiche del documento

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

• Log delle modifiche del documento

Per un riepilogo delle modifiche alle sezioni individuali:

1. Introduzione
2. Tipi di dispositivi
3. Software
4. Packaging dell'applicazione
5. Contenuti multimediali
6. Strumenti e opzioni per sviluppatori
7. Compatibilità hardware
8. Prestazioni e potenza
9. Modello di sicurezza
10. Test di compatibilità del software
11. Software aggiornabile
12. Log delle modifiche del documento
13. Contattaci

12.1. Suggerimenti per la visualizzazione del log delle modifiche

Le modifiche sono contrassegnate come segue:

• CDD
  Modifiche sostanziali ai requisiti di compatibilità.

• Documenti
  Modifiche estetiche o relative alla build.

Per una visualizzazione ottimale, aggiungi i parametri URL pretty=full e no-merges agli URL del log delle modifiche.

13. Contattaci

Puoi partecipare al forum sulla compatibilità di Android e chiedere chiarimenti o segnalare eventuali problemi che ritieni non siano trattati nel documento.