Note sulla release di Android 9

Questa pagina riassume le principali funzionalità della release Android 9 e fornisce link a ulteriori informazioni. Questi riepiloghi delle funzionalità sono organizzati in base alla posizione della documentazione della funzionalità su questo sito. Consulta gli aggiornamenti di agosto 2018 per i siti per una guida allo spostamento e alla ridenominazione delle sezioni.

Build

Generic System Image (GSI)

Un'immagine di sistema generica (GSI) è un'immagine di sistema con configurazioni modificate per i dispositivi Android. Generic System Image (GSI) include dettagli sulle differenze tra le GSI per i dispositivi lanciati con Android 9 e i dispositivi che eseguono l'upgrade ad Android 9.

Architettura

Hardware Abstraction Layer (HAL)

Compatibilità con le versioni precedenti del framework HIDL

Verifica della compatibilità con le versioni precedenti del framework HIDL è un metodo per verificare la compatibilità con le versioni precedenti del framework.

HAL disponibili dinamicamente

Le HAL disponibili dinamicamente supportano l'arresto dinamico dei sottosistemi hardware Android quando non sono in uso o non sono necessari.

HIDL

HIDL MemoryBlock

HIDL MemoryBlock è un livello astratto basato su hidl_memory, HIDL @1.0::IAllocator e HIDL @1.0::IMapper. È progettato per i servizi HIDL che hanno più blocchi di memoria che condividono un singolo heap di memoria.

Overlay del Device Tree

Overlay compressi

Android 9 e versioni successive includono il supporto per overlay compressi nell'immagine dell'overlay del blob dell'albero dei dispositivi (DTBO) quando si utilizza la versione 1 dell'intestazione della tabella dell'albero dei dispositivi.

Aggiornamenti dei DTO

Android 9 e versioni successive richiedono che il bootloader passi il blob dell'albero dei dispositivi unificato al kernel prima di modificare le proprietà definite negli overlay dell'albero dei dispositivi (DTO).

Controllo delle versioni dell'intestazione dell'immagine DTBO

Android 9 e versioni successive includono un campo versione nell'intestazione dell'immagine DTBO.

Verifica DTBO

Android 9 e versioni successive richiedono una partizione DTBO. Per aggiungere nodi o apportare modifiche alle proprietà nel SoC DT, il bootloader deve sovrapporre dinamicamente un DT specifico del dispositivo al SoC DT. Per ulteriori informazioni, consulta la sezione Compilazione e verifica.

Conformità del kernel

Android 9 e versioni successive includono requisiti che interessano il kernel, le relative interfacce e l'utilizzo di DTBO. Per ulteriori informazioni, consulta queste pagine:

NDK fornitore

Modifiche al design

Per informazioni sulle modifiche alla progettazione di VNDK in Android 9 e versioni successive, consulta queste pagine:

Controllo ABI

La pagina Stabilità ABI descrive il controllo dell'interfaccia binaria dell'applicazione (ABI), che garantisce che le modifiche apportate alle librerie VNDK mantengano la conformità ABI.

Snapshot VNDK

Un'immagine di sistema può utilizzare gli snapshot VNDK per fornire le librerie VNDK corrette alle immagini fornitore anche quando le immagini di sistema e fornitore sono create da versioni diverse di Android.

Oggetto dell'interfaccia fornitore (oggetto VINTF)

Le seguenti pagine della sezione Oggetto interfaccia fornitore descrivono gli aggiornamenti in Android 9 e versioni successive:

Pianificazione del ritiro di HIDL

Le pagine seguenti descrivono come Android ritira e rimuove gli HAL HIDL:

Bootloader

Partizioni di prodotti

Android 9 e versioni successive supportano la creazione di partizioni /product utilizzando il sistema di compilazione Android. In precedenza, Android 8.x imponeva la separazione dei componenti specifici del system-on-chip (SoC) dalla partizione /system alla partizione /vendor senza dedicare spazio ai componenti specifici dell'OEM creati dal sistema di build di Android.

Conformità al motivo di avvio canonico

La pagina Canonical Boot Reason descrive le modifiche alla specifica del motivo di avvio del bootloader in Android 9 e versioni successive.

Sistema come root

Tutti i dispositivi lanciati con Android 9 e versioni successive devono utilizzare system-as-root, che unisce ramdisk.img a system.img (noto anche come no-ramdisk), che a sua volta viene montato come rootfs.

Controllo delle versioni dell'intestazione dell'immagine di avvio

In Android 9 e versioni successive, l'intestazione dell'immagine di avvio contiene un campo per indicare la versione dell'intestazione. Il bootloader deve controllare questo campo della versione e analizzare l'intestazione di conseguenza.

DTBO in recovery

Per evitare errori OTA dovuti a mancata corrispondenza tra l'immagine di ripristino e la partizione DTBO sui dispositivi non A/B, l'immagine di ripristino deve contenere informazioni dall'immagine DTBO.

Visualizzazione

Ritagli display

I ritagli del display consentono agli sviluppatori di app di creare esperienze coinvolgenti da bordo a bordo, lasciando comunque spazio per sensori importanti sulla parte anteriore dei dispositivi.

Ruotare i suggerimenti

Aggiornamenti al comportamento di rotazione dello schermo Android 9 e versioni successive supportano un controllo rivolto all'utente per bloccare la rotazione dello schermo in modalità orizzontale o verticale anche se la posizione del dispositivo cambia.

Transizioni delle app sincronizzate

Le transizioni delle app sincronizzate consentono nuove animazioni di transizione delle app.

Classificazione del testo (in precedenza TEXTCLASSIFIER)

Android 9 e versioni successive includono un servizio di classificazione del testo, che è il modo consigliato per implementare la classificazione del testo e un'implementazione del servizio predefinita.

Colore ad ampia gamma

Android 9 e versioni successive includono il supporto per colori ad ampia gamma, tra cui:

  • HDR (High Dynamic Range)
  • Elaborazione dei contenuti nello spazio colore BT2020, ma non come spazio dati di destinazione finale

Per utilizzare i colori ad ampia gamma, l'intero stack di visualizzazione di un dispositivo (come schermo, compositore hardware, GPU) deve supportare i colori ad ampia gamma o i formati buffer. I dispositivi non sono tenuti a dichiarare il supporto per i contenuti ad ampia gamma anche se l'hardware lo supporta. Tuttavia, per sfruttare al meglio l'hardware, è necessario attivare il colore ad ampia gamma. Per evitare un'esperienza visiva incoerente, il colore ad ampia gamma non deve essere disattivato durante l'esecuzione.

Compatibilità

Compatibility Definition Document di Android

Il Compatibility Definition Document (CDD) di Android 9 si basa sulle versioni precedenti con aggiornamenti per nuove funzionalità e modifiche ai requisiti per le funzionalità rilasciate in precedenza.

Impostazioni

Widget delle app migliori

Il framework dei widget per app per Android offre una maggiore visibilità delle interazioni degli utenti, in particolare quando un utente elimina o aggiunge manualmente i widget. Questa funzionalità è disponibile per impostazione predefinita con Launcher3.

I produttori devono aggiornare le app di avvio (fornite con i dispositivi) per supportare questa funzionalità se non sono basate su Launcher3. Gli OEM devono supportare il nuovo campo widgetFeatures nel launcher predefinito.

Tieni presente che la funzionalità funziona end-to-end solo se i launcher la implementano come previsto. AOSP include un'implementazione di esempio. Consulta l'ID modifica AOSP Iccd6f965fa3d61992244a365efc242122292c0ca per il codice di esempio fornito.

Notifiche di modifica dello stato del dispositivo ai programmi di installazione dei pacchetti

Una trasmissione di sistema protetta può essere inviata alle app che dispongono dell'autorizzazione INSTALL_PACKAGES ogni volta che vengono modificate proprietà come le impostazioni internazionali o la densità di visualizzazione. I ricevitori possono essere registrati nel manifest e un processo si riattiva per ricevere la trasmissione. Ciò è utile per i programmi di installazione dei pacchetti che vogliono installare componenti aggiuntivi delle app in seguito a queste modifiche, il che è raro, perché le modifiche alla configurazione idonee a attivare questa trasmissione sono rare.

Il codice sorgente della notifica di modifica dello stato del dispositivo si trova nelle seguenti posizioni in platform/frameworks/base:

  • api/system-current.txt
  • core/java/android/content/Intent.java
  • core/res/AndroidManifest.xml
  • services/core/java/com/android/server/am/ActivityManagerService.java

Architettura delle informazioni

Le modifiche all'architettura delle informazioni per l'app Impostazioni offrono più funzionalità e un'implementazione più semplice.

Test

Atest

Lo strumento a riga di comando Atest ti consente di creare, installare ed eseguire test Android in locale, velocizzando notevolmente le ripetizioni dei test senza richiedere la conoscenza delle opzioni della riga di comando del framework di test Trade Federation.

Compatibility Test Suite (CTS)

Download di CTS

I pacchetti della suite di test di compatibilità (CTS) che supportano Android 9 sono disponibili nella pagina Download di CTS. Il codice sorgente dei test inclusi può essere sincronizzato con il tag android-cts-9.0_r1 nell'albero open source.

Opzioni CTS

Per Android 9, CTS v2 acquisisce il seguente comando e argomento:

  • run retry riprova tutti i test non riusciti o non eseguiti nelle sessioni precedenti.
  • ‘--shard-count suddivide un'esecuzione di CTS in un determinato numero di blocchi indipendenti, da eseguire su più dispositivi in parallelo.

Inoltre, è stato aggiunto il comando --retry-type, precedentemente non documentato, allo stesso riferimento ai comandi della console CTS versione 2.

Servizio Secure Element (SE)

Il servizio Secure Element verifica la presenza di elementi di sicurezza supportati dalla piattaforma globale identificando se i dispositivi hanno un'implementazione HAL SE e, in caso affermativo, quanti. Viene utilizzato come base per testare l'API e l'implementazione dell'elemento sicuro sottostante.

Scatola di fusione dei sensori

La scatola di fusione dei sensori viene utilizzata nel test di fusione dei sensori e nel test di sincronizzazione multicamera della suite di test delle immagini della videocamera (Camera ITS) e fornisce un ambiente di test coerente per misurare l'accuratezza del timestamp della videocamera e di altri sensori per gli smartphone Android. Per ulteriori informazioni, consulta queste pagine:

ITS-in-a-box con ampio campo visivo

Il sistema ITS-in-a-box ad ampio campo visivo è un sistema automatizzato progettato per testare sia i sistemi di videocamere ad ampio campo visivo (WFoV) sia quelli a campo visivo normale (RFoV) in Camera ITS.

Vendor Test Suite (VTS)

Architettura del controller host

L'architettura del controller host della Vendor Test Suite (VTS) è l'architettura del framework di test VTS integrato con il servizio di pubblicazione dei test basato sul cloud.

Test HAL con riconoscimento del nome del servizio

Test HAL con riconoscimento del nome del servizio VTS supporta l'ottenimento del nome del servizio di una determinata istanza HAL in base al dispositivo su cui vengono eseguiti i test VTS.

Controllo della testabilità HAL

Il controllo di testabilità HAL VTS include un metodo di runtime per utilizzare la configurazione del dispositivo per identificare quali test VTS devono essere ignorati per la destinazione del dispositivo.

Infrastruttura di test automatizzati

L'infrastruttura di test automatizzati è un'infrastruttura VTS per il test automatizzato di VTS, CTS o altri test su dispositivi partner che eseguono l'immagine di sistema generica (GSI) AOSP.

Debug…

Telemetria avanzata

In Android, la telemetria è il processo di raccolta automatica di informazioni sull'utilizzo e sulla diagnostica del dispositivo, del sistema Android e delle app. Nelle versioni precedenti di Android, lo stack di telemetria era limitato e non acquisiva le informazioni necessarie per identificare e risolvere i problemi di affidabilità del sistema e dei dispositivi o delle app. Ciò ha reso difficile, se non impossibile, identificare le cause principali dei problemi.

Android 9 include la funzionalità di telemetria statsd, che risolve questa carenza raccogliendo dati migliori più rapidamente. statsd raccoglie l'utilizzo delle app, le statistiche su batteria e processi e gli arresti anomali. I dati vengono analizzati e utilizzati per migliorare prodotti, hardware e servizi.

Per maggiori dettagli, vedi frameworks/base/cmds/statsd/.

Funzionalità di sicurezza

Firma dell'app

Lo schema di firma dell'APK v3 supporta la rotazione della chiave dell'APK.

Supporto biometrico

Android 9 include la classe pubblica BiometricPrompt, che le app possono utilizzare per integrare il supporto dell'autenticazione biometrica in modo indipendente dal dispositivo e dalla modalità. Per saperne di più sull'integrazione della tua biometria per includere BiometricPrompt, consulta Biometria.

Analisi dinamica

Android 9 include il supporto di più strumenti di analisi e mitigazione degli exploit.

Integrità del flusso di controllo (CFI)

L'integrità del flusso di controllo (CFI) è un meccanismo di sicurezza che vieta le modifiche al grafico del flusso di controllo originale di un binario compilato, rendendo molto più difficile eseguire questi attacchi.

Kernel CFI

Oltre alla CFI di sistema, che è attivata per impostazione predefinita, Android 9 e versioni successive includono il supporto per l'integrità del flusso di controllo (CFI) del kernel.

Crittografia

Crittografia basata su file

La crittografia basata su file (FBE) è stata aggiornata per funzionare con lo spazio di archiviazione adattabile. I nuovi dispositivi devono utilizzare la crittografia basata su file anziché la crittografia completa del disco.

Crittografia dei metadati

Android 9 e versioni successive includono il supporto per la crittografia dei metadati, se è presente il supporto hardware. Con la crittografia dei metadati, una singola chiave presente all'avvio utilizza la crittografia basata su file per criptare qualsiasi contenuto non criptato.

Archivio chiavi

Android 9 e versioni successive includono Keymaster 4, che ha queste funzionalità.

StrongBox

Android 9 e versioni successive supportano le chiavi Android Keystore che vengono memorizzate e utilizzate in una CPU fisicamente separata progettata appositamente per applicazioni di alta sicurezza, come un Secure Element (SE) incorporato. StrongBox Keymaster è un'implementazione dell'HAL Keymaster in hardware sicuro discreto. Una StrongBox ha:

  • CPU discreta
  • Spazio di archiviazione sicuro integrato
  • Generatore di numeri casuali reali di alta qualità
  • Imballaggio a prova di manomissione
  • Resistenza agli attacchi side-channel

Importazione sicura delle chiavi

Per importare in modo sicuro una chiave in Keymaster 4, una chiave creata al di fuori del dispositivo viene criptata con una specifica delle autorizzazioni che definiscono come può essere utilizzata la chiave.

Supporto 3DES

Keymaster 4 include 3DES per la compatibilità con i sistemi legacy che utilizzano 3DES.

Binding della versione

Per supportare la struttura modulare di Treble e interrompere il binding di system.img a boot.img, Keymaster 4 ha modificato il modello di binding della versione della chiave in modo da avere livelli di patch separati per ogni partizione. Ciò consente di aggiornare ogni partizione in modo indipendente, fornendo al contempo la protezione del rollback.

Android Protected Confirmation API

I dispositivi supportati che vengono lanciati con Android 9 installato offrono agli sviluppatori la possibilità di utilizzare l' API Android Protected Confirmation. Con questa API, le app possono utilizzare un'istanza di ConfirmationPrompt per mostrare all'utente una richiesta di approvazione di una breve dichiarazione. Questa dichiarazione consente a un'app di confermare che l'utente vuole completare una transazione sensibile, ad esempio un pagamento.

SELinux

Sandbox SELinux per app

La sandbox applicazioni dispone di nuove protezioni e casi di test per garantire che tutte le app non privilegiate che hanno come target Android 9 e versioni successive eseguano sandbox SELinux individuali.

Modifiche a SELinux Treble

Gli aggiornamenti a Treble SELinux in Android 9 e versioni successive sono documentati in diverse pagine nella sezione SELinux.

Vendor init

Vendor init chiude il buco nella divisione sistema/fornitore di Treble utilizzando un dominio SELinux separato per eseguire i comandi /vendor con autorizzazioni specifiche del fornitore.

Proprietà di sistema

Android 9 impedisce la condivisione non necessaria delle proprietà di sistema tra le partizioni system e vendor e fornisce un metodo per garantire la coerenza tra le proprietà di sistema condivise.

Test degli attributi SELinux

Android 9 include nuovi test in fase di compilazione che garantiscono che tutti i file in posizioni specifiche abbiano gli attributi appropriati. Ad esempio, tutti i file in sysfs hanno l'attributo sysfs_type obbligatorio.

Audio

Effetti audio ad alta risoluzione

Gli aggiornamenti agli effetti audio ad alta risoluzione includono la conversione dell'elaborazione degli effetti dal formato int16 a quello float e aumenti delle tracce di output simultanee del client, della memoria massima del client/server e delle tracce mixate totali.

Fotocamera

Videocamere USB esterne

Android 9 e versioni successive supportano l'utilizzo di fotocamere USB plug-and-play (ovvero webcam) utilizzando l'API Camera2 di Android standard e l'interfaccia HIDL della fotocamera.

Rilevamento del movimento

I dispositivi con videocamera possono pubblicizzare la funzionalità di rilevamento del movimento.

Supporto multicamera

Il supporto multicamera include il supporto API per dispositivi multicamera tramite un nuovo dispositivo fotocamera logica composto da due o più dispositivi fotocamera fisici che puntano nella stessa direzione.

Parametri sessione

L'implementazione dei parametri di sessione può ridurre i ritardi consentendo ai client della videocamera di configurare attivamente un sottoinsieme di parametri di richiesta costosi come parte della fase di inizializzazione della sessione di acquisizione.

Buffer di un singolo produttore e più consumatori

Il trasporto del buffer della videocamera con un singolo produttore e più consumatori è un insieme di metodi che consentono ai client della videocamera di aggiungere e rimuovere dinamicamente le superfici di output mentre la sessione di acquisizione è attiva e lo streaming della videocamera è in corso.

Connettività

Chiamate e messaggistica

Implementare piani dati

Android 9 e versioni successive offrono un supporto migliore per gli operatori che implementano piani dati utilizzando le API SubscriptionPlan.

App di chiamata di terze parti

Android 9 e versioni successive forniscono API che consentono alle app di chiamata di terze parti (3P) di gestire le chiamate in arrivo simultanee e di registrare le chiamate nel registro chiamate di sistema.

Operatore

Identificazione dell'operatore

In Android 9, AOSP aggiunge un database di ID operatore per facilitare l'identificazione dell'operatore. Il database riduce al minimo la logica duplicata e le esperienze frammentate delle app fornendo un modo comune per identificare gli operatori.

eSIM

La SIM incorporata (eSIM o eUICC) è la tecnologia più recente che consente agli utenti di dispositivi mobili di scaricare il profilo di un operatore e attivare il servizio di un operatore senza una scheda SIM fisica. In Android 9 e versioni successive, il framework Android fornisce API standard per accedere all'eSIM e gestire i profili di abbonamento sull'eSIM. Per ulteriori informazioni, consulta:

Supporto multi-SIM per le impostazioni IMS

Android 9 e versioni successive offrono miglioramenti alle impostazioni utente per IP Multimedia Subsystem (IMS). Puoi configurare VoLTE (voiceover LTE), videochiamate e chiamate Wi-Fi per ogni abbonamento anziché condividere queste impostazioni tra tutti gli abbonamenti.

Trasmissioni sullo stato della SIM

In Android 9 e versioni successive, Intent.ACTION_SIM_STATE_CHANGED è deprecato e vengono aggiunte due trasmissioni separate per lo stato della carta e lo stato dell'applicazione della carta, TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED e TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED.

Con queste modifiche, i ricevitori che devono solo sapere se una carta è presente non devono ascoltare le modifiche dello stato dell'applicazione e i ricevitori che devono solo sapere se le applicazioni delle carte sono pronte non devono ascoltare le modifiche dello stato della carta.

Le due nuove trasmissioni sono @SystemApis e non sono permanenti. Solo i destinatari con l'autorizzazione READ_PRIVILEGED_PHONE_STATE possono ricevere le trasmissioni.

Gli intent non vengono ritrasmessi quando sblocchi il dispositivo. I ricevitori che dipendono dalle trasmissioni inviate prima dello sblocco devono utilizzare directBootAware o devono eseguire una query sullo stato dopo lo sblocco dell'utente. È possibile eseguire query sugli stati utilizzando le API corrispondenti in TelephonyManager, getSimCardState() egetSimApplicationState().

Wi-Fi

Wi-Fi dell'operatore

La funzionalità Wi-Fi dell'operatore consente ai dispositivi di connettersi automaticamente alle reti Wi-Fi implementate dall'operatore. Nelle aree con elevata congestione o con copertura cellulare minima, come uno stadio o una stazione ferroviaria sotterranea, il Wi-Fi dell'operatore contribuisce a migliorare la connettività e a ridurre il traffico.

Randomizzazione dell'indirizzo MAC

La randomizzazione MAC consente ai dispositivi di utilizzare indirizzi MAC casuali durante la ricerca di nuove reti quando non sono attualmente associati a una rete. In Android 9 e versioni successive, è possibile attivare un'opzione sviluppatore per fare in modo che un dispositivo utilizzi un indirizzo MAC casuale quando si connette a una rete Wi-Fi.

Attiva Wi‑Fi automaticamente

Quando la funzionalità Attiva Wi-Fi automaticamente è attivata, il Wi-Fi viene riattivato automaticamente ogni volta che il dispositivo si trova vicino a una rete Wi-Fi salvata con un indicatore di intensità del segnale ricevuto (RSSI) relativo sufficientemente elevato.

Tempo di round trip del Wi-Fi

Il tempo di andata e ritorno (RTT) del Wi-Fi consente ai dispositivi di misurare la distanza da altri dispositivi di supporto, che siano punti di accesso (AP) o peer Wi-Fi Aware (se Wi-Fi Aware è supportato sul dispositivo). Questa funzionalità si basa sul protocollo IEEE 802.11mc e consente alle app di utilizzare una maggiore precisione e consapevolezza della posizione.

Miglioramenti del punteggio Wi-Fi

I modelli di valutazione del Wi-Fi migliorati determinano in modo rapido e preciso quando un dispositivo deve uscire da una rete Wi-Fi connessa o entrare in una nuova rete Wi-Fi. Questi modelli offrono un'esperienza affidabile e fluida agli utenti evitando interruzioni della connettività.

Esamina e regola i valori RSSI nelle risorse config.xml, in particolare quanto segue:

  • config_wifi_framework_wifi_score_bad_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_bad_rssi_threshold_24GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_24GHz

Concorrenza STA/AP Wi-Fi

La concorrenza Wi-Fi STA/AP è la capacità dei dispositivi di funzionare contemporaneamente in modalità stazione (STA) e punto di accesso (AP). Per i dispositivi che supportano il Wi-Fi dual-band simultaneo (DBS), questo apre funzionalità come la possibilità di non interrompere il Wi-Fi STA quando un utente vuole attivare un hotspot (SoftAP).

Miglioramenti di WiFiStateMachine

WifiStateMachine è la classe principale utilizzata per controllare l'attività Wi-Fi, coordinare l'input dell'utente (modalità operative: hotspot, scansione, connessione o disattivazione) e controllare le azioni della rete Wi-Fi (come la scansione o la connessione).

In Android 9 e versioni successive, il codice del framework Wi-Fi e l'implementazione di WifiStateMachine sono stati riprogettati, il che ha portato a una riduzione delle dimensioni del codice, a una logica di controllo del Wi-Fi più facile da seguire, a una maggiore granularità del controllo e a una maggiore copertura e qualità dei test delle unità.

A livello generale,WifiStateMachine consente al Wi-Fi di trovarsi in uno dei quattro stati seguenti:

  • Modalità client (può connettersi ed eseguire la scansione)
  • Modalità Solo scansione
  • Modalità SoftAP (hotspot Wi-Fi)
  • Disattivato (Wi-Fi completamente disattivato)

Ogni modalità Wi-Fi ha requisiti diversi per l'esecuzione dei servizi e deve essere configurata in modo coerente, gestendo solo gli eventi pertinenti al suo funzionamento. La nuova implementazione limita il codice agli eventi correlati a questa modalità, riducendo i tempi di debug e il rischio di introdurre nuovi bug a causa della complessità. Oltre alla gestione esplicita della funzionalità di modalità, la gestione dei thread viene gestita in modo coerente e l'utilizzo di canali asincroni viene eliminato come meccanismo di sincronizzazione.

Aggiornamenti delle autorizzazioni Wi-Fi

In Android 9 e versioni successive, l'autorizzazione app CHANGE_WIFI_STATE è attivata per impostazione predefinita. Puoi disattivare l'autorizzazione per qualsiasi app nella pagina delle impostazioni in Impostazioni > App e notifiche > Accesso speciale alle app > Controllo Wi-Fi.

Le app devono essere in grado di gestire i casi in cui l'autorizzazione CHANGE_WIFI_STATE non viene concessa.

Per convalidare questo comportamento, esegui i test roboelectric e manuali.

Per i test manuali:

  1. Vai a Impostazioni > App e notifiche > Accesso speciale alle app > Controllo Wi-Fi.
  2. Seleziona e disattiva l'autorizzazione per la tua app.
  3. Verifica che la tua app possa gestire lo scenario in cui l'autorizzazione CHANGE_WIFI_STATE non viene concessa.

Deprecazione di WPS

A causa di problemi di sicurezza, la Configurazione protetta Wi-Fi (WPS) in WiFiManager è deprecata e disattivata in Android 9 e versioni successive. Tuttavia, WiFiDirect utilizza ancora WPS nel supplicante WPA.

Grafica

Implementazione

API Vulkan 1.1

Android 9 e versioni successive supportano l'implementazione dell'API grafica Vulkan 1.1.

Strumento WinScope per il tracciamento della transizione delle finestre

Android 9 e versioni successive includono lo strumento WinScope per tracciare le transizioni delle finestre. WinScope fornisce infrastruttura e strumenti per registrare e analizzare lo stato del window manager durante e dopo le transizioni. Consente di registrare e scorrere le transizioni delle finestre, registrando al contempo tutto lo stato pertinente del window manager in un file di traccia. Puoi utilizzare questi dati per riprodurre e scorrere la transizione.

Il codice sorgente dello strumento WinScope si trova in platform/development/tools/winscope.

Interazione

Audio per auto

Automotive Audio descrive l'architettura audio per le implementazioni Android correlate al settore automobilistico.

L'HAL Neural Networks (NN) definisce un'astrazione dei vari acceleratori. I driver per questi acceleratori devono essere conformi a questo HAL.

Vehicle HAL

Vehicle Properties descrive le modifiche all'interfaccia HAL del veicolo.

Selezione dei satelliti GNSS

Quando si utilizzano nuove HAL (Hardware Abstraction Layer) del sistema satellitare di navigazione globale (GNSS) (v1.1+), il framework Android monitora le impostazioni di Android. I partner possono modificare le impostazioni da Google Play Services o da altri aggiornamenti di sistema. Queste impostazioni indicano all'HAL GNSS se determinati satelliti GNSS non devono essere utilizzati. Questo può essere utile in caso di errori persistenti di costellazioni o satelliti GNSS oppure per reagire più rapidamente a problemi di implementazione di GNSS HAL che possono verificarsi quando si combinano costellazioni utilizzando diversi sistemi temporali ed eventi esterni, come i rollover di secondi intercalari, giorni o numeri di settimana.

Modello hardware GNSS

In Android 9, la versione 1.1 o successive di GNSS HAL può trasferire informazioni sull'API hardware alla piattaforma. La piattaforma deve implementare l'interfaccia IGnssCallback e passare un handle all'HAL. L'HAL GNSS trasmette le informazioni sul modello hardware tramite il metodo LocationManager#getGnssHardwareModelName(). I produttori di dispositivi devono collaborare con i fornitori di HAL GNSS per fornire queste informazioni, se possibile.

Autorizzazioni

Configurazione degli aggiornamenti del controllo dell'accesso discrezionale

Configurazione del controllo dell'accesso discrezionale (DAC) contiene aggiornamenti al meccanismo degli ID Android (AID) per estendere le funzionalità del file system.

Autorizzazione delle autorizzazioni delle app con privilegi

In Android 9 e versioni successive, se sono presenti autorizzazioni che devono essere negate, modifica l'XML in modo da utilizzare il tag deny-permission anziché il tag permission utilizzato nelle versioni precedenti.

Dati

Miglioramenti alla stima della larghezza di banda

Android 9 offre un supporto migliorato per la stima della larghezza di banda. Le app per Android possono impostare risoluzioni più appropriate per le videochiamate e lo streaming video se possono accedere alla larghezza di banda disponibile.

Sui dispositivi con Android 6.0 o versioni successive, un chiamante che vuole una stima della larghezza di banda per una rete cellulare chiama ConnectivityManager.requestBandwidthUpdate(), e il framework potrebbe fornire una larghezza di banda di downlink stimata.

Tuttavia, sui dispositivi con Android 9 o versioni successive, il callback onCapabilitiesChanged() viene attivato automaticamente quando si verifica una variazione significativa della larghezza di banda stimata e la chiamata a requestBandwidthUpdate() è un'operazione nulla; i campi getLinkDownstreamBandwidthKbps() e getLinkUpstreamBandwidthKbps() vengono compilati con le informazioni aggiornate fornite dal livello fisico.

Inoltre, i dispositivi possono controllare le larghezze di banda delle celle LTE tramite ServiceState.getCellBandwidths(). In questo modo, le applicazioni possono determinare la quantità di larghezza di banda (frequenza) disponibile in una determinata cella. Le informazioni sulla larghezza di banda della cella sono disponibili tramite un menu nascosto, in modo che i tester sul campo possano controllare le informazioni più aggiornate.

Monitoraggio del traffico eBPF

Lo strumento di monitoraggio del traffico di rete eBPF utilizza una combinazione di implementazione dello spazio kernel e dello spazio utente per monitorare l'utilizzo della rete su un dispositivo dall'ultimo avvio. Questo strumento offre funzionalità aggiuntive come il tagging dei socket, la separazione del traffico in primo piano/in background e il firewall per UID per bloccare l'accesso alla rete delle app a seconda dello stato del dispositivo.

Ripristinare le API precedenti

Ora i dispositivi possono essere ripristinati da versioni future del sistema operativo. Ciò è particolarmente utile quando gli utenti hanno eseguito l'upgrade dei propri smartphone, ma poi li hanno persi o rotti.

Se un OEM modifica gli agenti di backup per uno dei pacchetti di sistema (android, system, settings), questi agenti devono gestire il ripristino dei set di backup creati su versioni successive della piattaforma senza arresti anomali e con il ripristino di almeno alcuni dati.

Valuta la possibilità di utilizzare uno strumento di convalida per verificare la presenza di valori non validi in una determinata parte dei dati di backup e ripristinare solo i dati validi, come in core/java/android/provider/SettingsValidators.java.

La funzionalità è attiva per impostazione predefinita. Il supporto di SettingsBackupAgent per il ripristino da versioni future può essere disattivato tramite Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION. Non è richiesta alcuna implementazione aggiuntiva, a meno che il produttore del dispositivo non estenda uno degli agenti di backup inclusi nella ROM (o aggiunga un agente personalizzato).

Questa funzionalità consente i ripristini del sistema dalle versioni future della piattaforma; tuttavia, è ragionevole aspettarsi che i dati ripristinati non siano completi. Le seguenti istruzioni si applicano ai seguenti agenti di backup:

  • PackageManagerBackupAgent supporta le versioni future dei dati di backup tramite il controllo delle versioni del formato; le estensioni qui devono essere compatibili con il codice di ripristino corrente o seguire le istruzioni nella classe, che includono l'incremento delle costanti appropriate.

  • SystemBackupAgent specifica restoreAnyVersion = false in Android 9 e versioni successive. Non supporta il ripristino da versioni successive dell'API.

  • SettingsBackupAgent specifica restoreAnyVersion = true in Android 9 e versioni successive. Esiste un supporto parziale tramite i validatori. Un'impostazione può essere ripristinata da una versione API superiore se esiste un validatore per questa impostazione nel sistema operativo di destinazione. L'aggiunta di qualsiasi impostazione deve essere accompagnata dal relativo strumento di convalida. Controlla la lezione per i dettagli.

  • Qualsiasi agente di backup personalizzato incluso nella ROM deve aumentare il codice versione ogni volta che viene apportata una modifica incompatibile al formato dei dati di backup e assicurarsi che restoreAnyVersion = false (il valore predefinito) se il suo agente non è pronto a gestire i dati di backup di una versione futura del suo codice.

Aziende

Miglioramenti ai profili gestiti

Le modifiche all'esperienza utente per i profili gestiti rendono più facile per gli utenti identificare, accedere e controllare il profilo gestito.

Mettere in pausa le OTA

Una nuova @SystemApi consente ai proprietari dei dispositivi di mettere in pausa a tempo indeterminato gli aggiornamenti OTA, inclusi gli aggiornamenti della sicurezza.

Prestazioni

Salute 2.0

Android 9 e versioni successive includono android.hardware.health HAL 2.0, un importante aggiornamento della versione di health@1.0 HAL. Per ulteriori informazioni, consulta queste pagine:

Soluzione di memorizzazione nella cache degli APK

Android 9 e versioni successive includono una soluzione di memorizzazione nella cache degli APK per l'installazione rapida di app precaricate su un dispositivo che supporta le partizioni A/B. Gli OEM possono inserire precaricamenti e app popolari nella cache APK archiviata principalmente nella partizione B vuota sui nuovi dispositivi con partizioni A/B senza influire sullo spazio dati visibile all'utente.

Ottimizzazione guidata dal profilo

Android 9 e versioni successive supportano l'utilizzo dell'ottimizzazione guidata dal profilo (PGO) di Clang sui moduli Android nativi che hanno regole di compilazione del progetto.

Log write-ahead

Una modalità speciale di SQLiteDatabase chiamata compatibilità write-ahead logging (WAL) consente a un database di utilizzare journal_mode=WAL mantenendo un massimo di una connessione per database.

Tempi di avvio

Android 9 modifica l'ottimizzazione del tempo di avvio come descritto in Ottimizzazione dei tempi di avvio.

Potenza

Limitazioni in background

Android 9 e versioni successive includono limitazioni in background che consentono agli utenti di limitare le app che potrebbero consumare la batteria. Il sistema potrebbe anche suggerire di disattivare le app che influiscono negativamente sullo stato del dispositivo.

Dispositivi senza batteria

Android 9 gestisce i dispositivi senza batteria in modo più elegante rispetto alle versioni precedenti. Android 9 rimuove il codice per i dispositivi senza batteria che presupponevano per impostazione predefinita che una batteria fosse presente, carica al 100% e in buone condizioni con una lettura normale della temperatura sul termistore.