Note sulla release di Android 9

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

Crea

Generic System Image (GSI)

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

Architettura

Hardware Abstraction Layer (HAL)

Compatibilità con le versioni precedenti del framework HIDL

La 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

Gli HAL disponibili dinamicamente supportano lo spegnimento dinamico dei sottosistemi hardware di Android quando non sono in uso o non sono necessari.

HIDL

Blocco di memoria HIDL

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 della struttura del dispositivo

Overlay compressi

Android 9 e versioni successive includono il supporto per gli overlay compressi nell'immagine DTBO (Device Tree Blob Overlay) quando si utilizza la versione 1 dell'intestazione della tabella dell'albero del dispositivo.

Aggiornamenti dei DTO

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

Controllo della versione dell'intestazione delle immagini DTBO

Android 9 e versioni successive includono un campo della 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 DT del SoC, il bootloader deve sovrapporre dinamicamente un DT specifico del dispositivo al DT del SoC. Per ulteriori informazioni, consulta la sezione Compilazione e verifica.

Conformità del kernel

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

NDK del fornitore

Modifiche al design

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

Strumento di controllo ABI

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

Snapshot VNDK

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

Oggetto interfaccia fornitore (oggetto VINTF)

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

Programma di ritiro di HIDL

Le pagine seguenti descrivono come Android ritira e rimuove le 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 costruiti dal sistema di compilazione Android.

Conformità al motivo di avvio canonico

La pagina Motivo avvio canonico 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 mancate corrispondenze tra l'immagine di ripristino e la partizione DTBO sui dispositivi non A/B, l'immagine di ripristino deve contenere le informazioni dell'immagine DTBO.

Display

Ritagli del display

I ritagli del display consentono agli sviluppatori di app di creare esperienze immersive da un lato all'altro, lasciando comunque spazio per i sensori importanti sulla parte anteriore dei dispositivi.

Suggerimenti di rotazione

Gli aggiornamenti al comportamento di rotazione dello schermo Android 9 e versioni successive includono il supporto di un controllo rivolto agli utenti per bloccare la rotazione dello schermo in orizzontale o verticale anche se la posizione del dispositivo cambia.

Transizioni di 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 a gamma estesa

Android 9 e versioni successive includono il supporto del colore a gamma estesa, tra cui:

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

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

Compatibilità

Android Compatibility Definition Document

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

Impostazioni

Widget delle app migliori

Il framework per i widget delle app per Android offre una maggiore visibilità sulle 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 in dotazione con i dispositivi) per supportare questa funzionalità, se non basata su Avvio3. Gli OEM devono supportare il nuovo campo widgetFeatures nel loro launcher predefinito.

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

Notifiche relative alla modifica dello stato del dispositivo agli installatori dei pacchetti

Una trasmissione di sistema protetta può essere inviata alle app che dispongono dell'autorizzazione INSTALL_PACKAGES ogni volta che viene modificata una proprietà come la lingua o la densità del display. I ricevitori possono essere registrati nel manifest e un processo si attiva per ricevere la trasmissione. Questo è utile per gli installatori di pacchetti che vogliono installare componenti aggiuntivi delle app in seguito a queste modifiche, cosa insolita, perché le modifiche di configurazione idonee ad 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 dell'informazione

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

Test

Atest

Lo strumento a riga di comando Atest consente di compilare, installare ed eseguire test Android localmente, velocizzando notevolmente le ripetizioni dei test senza richiedere la conoscenza delle opzioni a riga di comando del test harness Trade Federation.

Compatibility Test Suite (CTS)

Download CTS

I pacchetti CTS (Compatibility Test Suite) che supportano Android 9 sono disponibili nella pagina Download 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 supporta il seguente comando e argomento:

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

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

Servizio Secure Element (SE)

Il servizio Secure Element cerca gli 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 dati dei sensori

La cassetta di fusione dei sensori viene utilizzata nel test di fusione dei sensori e nel test di sincronizzazione di più fotocamere della Camera Image Test Suite (Camera ITS) e fornisce un ambiente di test coerente per misurare l'accuratezza del timestamp della fotocamera e di altri sensori per gli smartphone Android. Per ulteriori informazioni, consulta queste pagine:

Sistema ITS-in-a-box ad ampio campo visivo

L'ITS-in-a-box con ampio campo visivo è un sistema automatico progettato per testare i sistemi di videocamere con campo visivo sia ampio che normale nell'ITS con videocamera.

Vendor Test Suite

Architettura del controller host

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

Test HAL attenti al nome del servizio

I test HAL basati sul nome del servizio VTS supportano 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 verificabilità dei test VTS HAL include un metodo di runtime per l'utilizzo della configurazione del dispositivo per identificare i test VTS da saltare per il dispositivo di destinazione.

Infrastruttura di test automatica

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

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 i problemi relativi a dispositivi o app. Ciò ha reso difficile, se non impossibile, identificare le cause principali dei problemi.

Android 9 include la statsdfunzionalità di telemetria, che risolve questo mancato rispetto raccogliendo dati migliori più velocemente. statsd raccoglie statistiche sull'utilizzo delle app, della batteria e dei processi, nonché 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 delle chiavi 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 del tuo stack biometrico in modo da includere BiometricPrompt, consulta Dati biometrici.

Analisi dinamica

Android 9 include il supporto di altri 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 impedisce le modifiche al grafo del flusso di controllo originale di un file binario compilato, rendendo notevolmente più difficile eseguire questi attacchi.

CFI del kernel

Oltre all'integrità del flusso di controllo di sistema, abilitata 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 adottabile. I nuovi dispositivi dovrebbero utilizzare la crittografia basata su file anziché la crittografia completa del disco.

Crittografia dei metadati

Android 9 e versioni successive includono il supporto della crittografia dei metadati, se è presente il supporto hardware. Con la crittografia dei metadati, una singola chiave presente al momento dell'avvio utilizza la crittografia basata su file per criptare tutti i contenuti non criptati.

Archivio chiavi

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

StrongBox

Android 9 e versioni successive includono il supporto per le chiavi del Keystore di Android che vengono memorizzate e utilizzate in una CPU fisicamente separata progettata appositamente per applicazioni ad alta sicurezza, come un elemento di sicurezza (SE) integrato. StrongBox Keymaster è un'implementazione dell'HAL Keymaster in hardware sicuro discreto. Una cassetta di sicurezza ha:

  • CPU discreta
  • Archiviazione sicura integrale
  • Generatore di numeri casuali veri di alta qualità
  • Imballaggio a prova di manomissione
  • Resistenza ai side channel

Importazione sicura delle chiavi

Per importare in sicurezza 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 di 3DES

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

Vincolo 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 delle versioni delle chiavi in modo da avere livelli di patch distinti per ogni partizione. In questo modo, ogni partizione può essere aggiornata in modo indipendente, garantendo al contempo la protezione del rollback.

Android Protected Confirmation API

I dispositivi supportati che vengono lanciati con Android 9 installato consentono agli sviluppatori 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 effettuare un pagamento.

SELinux

Sandbox SELinux per app

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

Modifiche a SELinux di Treble

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

Inizializzazione del fornitore

Vendor init chiude la falla nella suddivisione del sistema/del 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 di compilazione che assicurano 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 includevano la conversione dell'elaborazione degli effetti dal formato int16 a quello float e l'aumento delle tracce di output client simultanee, della memoria client/server massima e delle tracce miste totali.

Fotocamera

Videocamere USB esterne

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

Rilevamento del movimento

I dispositivi con fotocamera possono pubblicizzare la funzionalità di monitoraggio dei movimenti.

Supporto della modalità multicamera

Il supporto della modalità multicamera include il supporto dell'API per i dispositivi multicamera tramite un nuovo dispositivo fotocamera logico composto da due o più dispositivi fotocamera fisici rivolti nella stessa direzione.

Parametri della 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 onerosi durante la fase di inizializzazione della sessione di acquisizione.

Buffer con un solo produttore e più consumatori

Trasporto del buffer della videocamera con un solo produttore e più consumatori è un insieme di metodi che consente 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 i piani dati

Android 9 e versioni successive offrono un supporto migliorato 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 di gestire le chiamate in arrivo dell'operatore in contemporanea 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 contribuire all'identificazione dell'operatore. Il database minimizza la logica duplicata e le esperienze con app frammentate fornendo un modo comune per identificare i corrieri.

eSIM

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

Supporto multi-SIM per le impostazioni IMS

Android 9 e versioni successive offrono miglioramenti alle impostazioni utente per il sottosistema multimediale IP (IMS). Puoi configurare la voce su LTE (VoLTE), le videochiamate e le chiamate Wi-Fi su base abbonamento anziché condividerle su tutti gli abbonamenti.

Trasmissioni dello stato della SIM

In Android 9 e versioni successive, Intent.ACTION_SIM_STATE_CHANGED è deprecato e vengono aggiunte due mandate separate per lo stato della carta e lo stato della richiesta 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 è presente una scheda non devono ascoltare le modifiche dello stato dell'applicazione e i ricevitori che devono solo sapere se le richieste di schede sono pronte non devono ascoltare le modifiche dello stato della scheda.

Le due nuove trasmissioni sono @SystemApis e non sono fisse. Solo i ricevitori 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 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 zone con elevato volume di utilizzo o con copertura cellulare minima, come uno stadio o una stazione ferroviaria della metropolitana, la rete Wi-Fi dell'operatore contribuisce a migliorare la connettività e a scaricare il traffico.

Randomizzazione MAC

La randomizzazione MAC consente ai dispositivi di usare indirizzi MAC casuali quando cercano nuove reti quando non sono attualmente associati a una rete. In Android 9 e versioni successive, è possibile attivare un'opzione per gli sviluppatori per far sì 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 è attiva, il Wi-Fi viene riattivato automaticamente ogni volta che il dispositivo si trova nelle vicinanze di 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 transito (RTT) del Wi-Fi consente ai dispositivi di misurare la distanza da altri dispositivi di supporto, che si tratti di punti di accesso (AP) o peer Wi-Fi Aware (se Wi-Fi Aware è supportato sul dispositivo). Questa funzionalità è basata sul protocollo IEEE 802.11mc e consente alle app di utilizzare una maggiore precisione e consapevolezza della posizione.

Miglioramenti al punteggio del Wi-Fi

I modelli di punteggio Wi-Fi migliorati determinano in modo rapido e preciso quando un dispositivo deve uscire da una rete Wi-Fi connessa o accedere a una nuova rete Wi-Fi. Questi modelli offrono un'esperienza affidabile e senza interruzioni agli utenti evitando lacune nella connettività.

Esamina e ottimizza i valori RSSI nelle risorse config.xml, in particolare i seguenti:

  • 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 contemporaneità STA/AP Wi-Fi è la capacità dei dispositivi di operare contemporaneamente in modalità stazione (STA) e punto di accesso (AP). Per i dispositivi che supportano il Wi-Fi dual band simultaneo (DBS), questa funzionalità consente di non interrompere il Wi-Fi STA quando un utente vuole attivare un hotspot (SoftAP).

Miglioramenti a WiFiStateMachine

WifiStateMachine è la classe principale utilizzata per controllare l'attività Wi-Fi, coordinare l'input dell'utente (modalità di funzionamento: hotspot, ricerca, connessione o off) e controllare le azioni della rete Wi-Fi (ad esempio la ricerca o la connessione).

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

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

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

Ogni modalità Wi-Fi ha requisiti diversi per i servizi in esecuzione 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 quella modalità, riducendo i tempi di debug e il rischio di introdurre nuovi bug a causa della complessità. Oltre alla gestione esplicita della funzionalità della modalità, la gestione dei thread viene gestita in modo coerente e l'uso dei 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 per le 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'CHANGE_WIFI_STATE autorizzazione non è concessa.

Ritiro di WPS

A causa di problemi di sicurezza, la Configurazione protetta Wi-Fi (WPS) in WiFiManager è stata ritirata e disattivata in Android 9 e versioni successive. Tuttavia, WiFiDirect utilizza ancora WPS nell'applicant 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 monitoraggio delle transizioni delle finestre

Android 9 e versioni successive includono lo strumento WinScope per il monitoraggio delle transizioni delle finestre. WinScope fornisce l'infrastruttura e gli strumenti per registrare e analizzare lo stato del gestore della finestra durante e dopo le transizioni. Consente di registrare e eseguire il walkthrough delle transizioni delle finestre, registrando al contempo tutto lo stato pertinente del gestore delle finestre in un file di traccia. Puoi utilizzare questi dati per riprodurre e analizzare la transizione.

Il codice sorgente dello strumento WinScope si trova all'indirizzo platform/development/tools/winscope.

Interazione

Audio per auto e motori

Automotive Audio descrive l'architettura audio per le implementazioni di Android correlate all'automotive.

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

Vehicle HAL

Proprietà veicolo descrive le modifiche all'interfaccia HAL del veicolo.

Selezione del satellite GNSS

Quando si utilizzano nuovi HAL (v1.1 e versioni successive) del sistema di navigazione satellitare globale (GNSS), 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 non devono essere utilizzati determinati satelliti GNSS. Questo può essere utile in caso di errori persistenti delle costellazioni o dei satelliti GNSS o per reagire più rapidamente ai problemi di implementazione dell'HAL GNSS che possono verificarsi quando si mescolano costellazioni che utilizzano sistemi di tempo diversi ed eventi esterni, come i rollover dei secondi intercalari, dei giorni o dei numeri di settimana.

Modello hardware GNSS

In Android 9, la versione 1.1 o successive dell'HAL GNSS può trasmettere alla piattaforma informazioni sull'API hardware. 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 propri 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.

Autorizzare le autorizzazioni delle app con privilegi

In Android 9 e versioni successive, se ci sono autorizzazioni che devono essere negate, modifica il file XML in modo da utilizzare il tag deny-permission anziché il tag permission utilizzato nelle release 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 di dati disponibile.

Sui dispositivi con Android 6.0 o versioni successive, un chiamante che vuole una stima della larghezza di banda per una rete mobile chiama ConnectivityManager.requestBandwidthUpdate() e il framework potrebbe fornire una larghezza di banda in 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 senza effetti; i valori associati 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 per il monitoraggio del traffico di rete eBPF utilizza una combinazione di implementazione nello spazio utente e nel kernel per monitorare l'utilizzo della rete su un dispositivo dall'ultimo avvio. Questo strumento fornisce funzionalità aggiuntive come il tagging delle socket, la separazione del traffico in primo piano/in background e il firewall per UID per bloccare l'accesso alla rete da parte delle app in base allo stato del dispositivo.

Ripristino alle API precedenti

Ora i dispositivi possono essere ripristinati da versioni future del sistema operativo. Questa funzionalità è 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 eseguiti su versioni successive della piattaforma senza arresti anomali e ripristinando almeno alcuni dati.

Valuta la possibilità di utilizzare uno strumento di convalida per verificare la presenza di valori non validi di un determinato insieme di 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 espanda uno degli agenti di backup inclusi nella ROM (o ne aggiunga uno personalizzato).

Questa funzionalità consente i ripristini di 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 della versione del formato. Le estensioni qui devono essere compatibili con il codice di ripristino corrente o seguire le istruzioni della classe, che includono l'aumento 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 dell'API successiva se esiste un validatore per l'impostazione nel sistema operativo di destinazione. L'aggiunta di qualsiasi impostazione deve essere accompagnata dal relativo convalidatore. Controlla il corso per i dettagli.

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

Aziende

Miglioramenti ai profili gestiti

Le modifiche all'esperienza utente per i profili gestiti consentono agli utenti di identificare, accedere e controllare più facilmente il profilo gestito.

Mettere in pausa le OTA

Un nuovo @SystemApi consente ai proprietari di dispositivi di mettere in pausa indefinitamente 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 upgrade della versione principale dall'HAL health@1.0. Per ulteriori informazioni, consulta queste pagine:

Soluzione di memorizzazione nella cache dell'APK

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

Ottimizzazione basata sul profilo

Android 9 e versioni successive supportano l'utilizzo della ottimizzazione basata sul profilo (PGO) di Clang sui moduli Android nativi con regole di compilazione del blueprint.

Log write-ahead

Una modalità speciale di SQLiteDatabase chiamata logging di compatibilità con scrittura anticipata (WAL) consente a un database di utilizzare journal_mode=WAL mantenendo al contempo un massimo di una connessione per database.

Tempi di avvio

Android 9 modifica l'ottimizzazione dei tempi di avvio come descritto in Ottimizzare i tempi di avvio.

Potenza

Restrizioni in background

Android 9 e versioni successive includono le limitazioni in background che consentono agli utenti di limitare le app che potrebbero scaricare la batteria. Il sistema potrebbe anche suggerire di disattivare le app che influiscono negativamente sul corretto funzionamento di un 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 per impostazione predefinita presumevano la presenza di una batteria carica al 100% e in buono stato con una lettura della temperatura normale sul termistore.