Oggi rilasceremo la seconda versione beta di Android 17, continuando il nostro lavoro per creare una piattaforma che dia la priorità a privacy, sicurezza e prestazioni ottimizzate. Questo aggiornamento offre una serie di nuove funzionalità, tra cui l'API EyeDropper e un Selettore di contatti che rispetta la privacy. Stiamo inoltre aggiungendo API di ranging avanzate, di trasferimento cross-device e altro ancora.

Questa release continua il cambiamento della nostra cadenza di rilascio, seguendo questo rilascio annuale dell'SDK principale nel secondo trimestre con un aggiornamento dell'SDK secondario.

Esperienza utente e UI di sistema

Bolle

Le bolle sono una funzionalità della modalità di finestre che offre una nuova esperienza UI mobile separata dall'API delle bolle di messaggistica. Gli utenti possono creare una bolla dell'app sullo smartphone, sul dispositivo pieghevole o sul tablet tenendo premuta l'icona dell'app nel launcher. Sugli schermi di grandi dimensioni, è presente una barra delle bolle nella barra delle app in cui gli utenti possono organizzare, spostare e spostare le bolle da e verso i punti di ancoraggio sullo schermo.

Devi seguire le linee guida per il supporto della modalità multi-finestra per assicurarti che le tue app funzionino correttamente come bolle.

Le bolle non sono ancora completamente abilitate nella versione beta 2. Cercale in una build futura di Android 17.

API EyeDropper

Una nuova API EyeDropper a livello di sistema consente alla tua app di richiedere un colore da qualsiasi pixel sul display senza richiedere autorizzazioni di acquisizione dello schermo sensibili.

  val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
  result -> if (result.resultCode == Activity.RESULT_OK) {
    val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
    // Use the picked color in your app
  }
}

fun launchColorPicker() {
  val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
  eyeDropperLauncher.launch(intent)
}

Selettore di contatti

Un nuovo selettore di contatti a livello di sistema tramite ACTION_PICK_CONTACTS concede l'accesso in lettura temporaneo e basato sulla sessione solo ai campi di dati specifici richiesti dall'utente, riducendo la necessità di autorizzazioni READ_CONTACTS ampie. Consente inoltre di selezionare i profili personali o di lavoro del dispositivo.

  val contactPicker = rememberLauncherForActivityResult(StartActivityForResult()) {
    if (it.resultCode == RESULT_OK) {
        val uri = it.data?.data ?: return@rememberLauncherForActivityResult
        // Handle result logic
        processContactPickerResults(uri)
    }
}

val dataFields = arrayListOf(Email.CONTENT_ITEM_TYPE, Phone.CONTENT_ITEM_TYPE)
val intent = Intent(ACTION_PICK_CONTACTS).apply {
    putStringArrayListExtra(EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS, dataFields)
    putExtra(EXTRA_ALLOW_MULTIPLE, true)
    putExtra(EXTRA_PICK_CONTACTS_SELECTION_LIMIT, 5)
}

contactPicker.launch(intent)

Compatibilità più semplice dell'acquisizione del puntatore con i touchpad

In precedenza, i touchpad segnalavano gli eventi in modo molto diverso dai mouse quando un'app aveva acquisito il puntatore, segnalando le posizioni delle dita sul pad anziché i movimenti relativi che sarebbero stati segnalati da un mouse. Questo rendeva piuttosto difficile supportare correttamente i touchpad nei giochi in prima persona. Ora, per impostazione predefinita, il sistema riconoscerà i movimenti del puntatore e i gesti di scorrimento quando il touchpad viene acquisito e li segnalerà come eventi del mouse. Puoi comunque richiedere i vecchi dati dettagliati sulla posizione delle dita richiedendo esplicitamente l'acquisizione nella nuova modalità "assoluta".

  // To request the new default relative mode (mouse-like events)
// This is the same as requesting with View.POINTER_CAPTURE_MODE_RELATIVE
view.requestPointerCapture()

// To request the legacy absolute mode (raw touch coordinates)
view.requestPointerCapture(View.POINTER_CAPTURE_MODE_ABSOLUTE)

Limiti di riposo del selettore interattivo

Chiamando getInitialRestingBounds su ChooserSession di Android, la tua app può identificare la posizione target occupata dal selettore al termine delle animazioni e del caricamento dei dati, consentendo una migliore regolazione dell'UI.

Connettività e cross-device

Trasferimento dell'app cross-device

Una nuova API Handoff consente di specificare lo stato dell'applicazione da riprendere su un altro dispositivo, ad esempio un tablet Android. Se attivato, il sistema sincronizza lo stato tramite CompanionDeviceManager e visualizza un suggerimento di trasferimento nel launcher dei dispositivi nelle vicinanze dell'utente. Questa funzionalità è progettata per offrire una continuità delle attività senza interruzioni, consentendo agli utenti di riprendere esattamente da dove avevano interrotto il flusso di lavoro nell'ecosistema Android. È fondamentale che Handoff supporti sia le transizioni native da app ad app sia il fallback da app a web, offrendo la massima flessibilità e garantendo un'esperienza completa anche se l'app nativa non è installata sul dispositivo di ricezione.

API di ranging avanzate

Stiamo aggiungendo il supporto per 2 nuove tecnologie di ranging:

1. UWB DL-TDOA che consente alle app di utilizzare UWB per la navigazione indoor. Questa superficie API è conforme alla specifica FIRA (Fine Ranging Consortium) 4.0 DL-TDOA e consente la navigazione indoor che rispetta la privacy  (evitando il monitoraggio del dispositivo da parte dell'ancoraggio).
2. Rilevamento della prossimità che consente alle app di utilizzare la nuova specifica di ranging adottata da WFA (WiFi Alliance). Questa tecnologia offre una maggiore affidabilità e precisione rispetto alla specifica di ranging esistente basata su Wi-Fi Aware.

Miglioramenti del piano dati

Per ottimizzare la qualità dei contenuti multimediali, la tua app può ora recuperare le velocità dati massime allocate dall'operatore per le applicazioni di streaming utilizzando getStreamingAppMaxDownlinkKbps e getStreamingAppMaxUplinkKbps.

Funzionalità di base, privacy e prestazioni

Accesso alla rete locale

Android 17 introduce l'autorizzazione di runtime ACCESS_LOCAL_NETWORK per proteggere gli utenti dall'accesso non autorizzato alla rete locale. Poiché rientra nel gruppo di autorizzazioni NEARBY_DEVICES esistente, agli utenti che hanno già concesso altre autorizzazioni NEARBY_DEVICES non verrà richiesto di nuovo. Dichiarando e richiedendo questa autorizzazione, la tua app può rilevare e connettersi ai dispositivi sulla rete locale (LAN), come i dispositivi per la smart home o i ricevitori di trasmissione. In questo modo, le app dannose non possono sfruttare l'accesso illimitato alla rete locale per il monitoraggio utenti e il fingerprinting nascosti. Le app che hanno come target Android 17 o versioni successive avranno ora due modi per mantenere la comunicazione con i dispositivi LAN: adottare i selettori di dispositivi intermediati dal sistema che rispettano la privacy per saltare la richiesta di autorizzazione oppure richiedere esplicitamente questa nuova autorizzazione in fase di runtime per mantenere la comunicazione di rete locale.

Trasmissione della modifica dell'offset del fuso orario

Android ora fornisce un intent di trasmissione affidabile, ACTION_TIMEZONE_OFFSET_CHANGED, attivato quando l'offset del fuso orario del sistema cambia, ad esempio durante le transizioni dell'ora legale. Questo completa gli intent di trasmissione esistenti ACTION_TIME_CHANGED e ACTION_TIMEZONE_CHANGED, che vengono attivati rispettivamente quando il timestamp Unix cambia e quando l'ID del fuso orario cambia.

Gestione e assegnazione delle priorità della NPU

Le app che hanno come target Android 17 e che devono accedere direttamente alla NPU devono dichiarare FEATURE_NEURAL_PROCESSING_UNIT nel file manifest per evitare che l'accesso alla NPU venga bloccato. Sono incluse le app che utilizzano il delegato NPU LiteRT, gli SDK specifici del fornitore e l'NNAPI ritirato.

Supporto di ICU 78 e Unicode 17

Le librerie di internazionalizzazione principali sono state aggiornate a ICU 78, ampliando il supporto per nuovi script, caratteri e blocchi di emoji e consentendo la formattazione diretta degli oggetti temporali.

Protezione OTP via SMS

Android sta espandendo la protezione OTP via SMS ritardando automaticamente l'accesso ai messaggi SMS con OTP. In precedenza, la protezione era incentrata principalmente sul formato SMS Retriever, in cui la consegna dei messaggi contenenti un hash di SMS Retriever viene ritardata per la maggior parte delle app per tre ore. Tuttavia, alcune app come l'app per SMS predefinita e l'app che corrisponde all'hash sono esenti da questo ritardo. Questo aggiornamento estende la protezione a tutti i messaggi SMS con OTP. Per la maggior parte delle app, i messaggi SMS contenenti un OTP saranno accessibili solo dopo un ritardo di tre ore per contribuire a prevenire il furto di OTP. La trasmissione SMS_RECEIVED_ACTION verrà sospesa e le query del database del provider di SMS verranno filtrate. Il messaggio SMS sarà disponibile per queste app dopo il ritardo. 

Accesso ritardato ai messaggi SMS in formato WebOTP

Se l'app ha l'autorizzazione per leggere i messaggi SMS, ma non è il destinatario previsto dell'OTP (come determinato dalla verifica del dominio), il messaggio SMS in formato WebOTP sarà accessibile solo dopo tre ore. Questa modifica è progettata per migliorare la sicurezza degli utenti, assicurando che solo le app associate al dominio menzionato nel messaggio possano leggere a livello di programmazione il codice di verifica. Questa modifica si applica a tutte le app, indipendentemente dal livello API target.

Accesso ritardato ai messaggi SMS standard con OTP

Per i messaggi SMS contenenti un OTP che non utilizzano i formati WebOTP o SMS Retriever, l'SMS OTP sarà accessibile solo dopo tre ore per la maggior parte delle app. Questa modifica si applica solo alle app che hanno come target Android 17 (livello API 37) o versioni successive.

Alcune app, come l'app SMS predefinita, l'app Assistente e le app complementari dei dispositivi connessi, saranno esenti da questo ritardo.

Tutte le app che si basano sulla lettura dei messaggi SMS per l'estrazione dell'OTP devono passare all'utilizzo delle API SMS Retriever o SMS User Consent per garantire la continuità delle funzionalità.

La pianificazione di Android 17

Passeremo rapidamente da questa versione beta alla pietra miliare della stabilità della piattaforma, prevista per marzo. In questo traguardo, forniremo le API SDK/NDK finali. Da quel momento in poi, la tua app potrà avere come target l'SDK 37 ed essere pubblicata su Google Play per aiutarti a completare i test e raccogliere il feedback degli utenti nei mesi precedenti la disponibilità generale di Android 17.

Un anno di release

Abbiamo in programma di continuare a ricevere aggiornamenti di Android 17 in una serie di release trimestrali. La prossima release nel secondo trimestre è l'unica in cui introdurremo modifiche al comportamento delle app pianificate. Abbiamo in programma di rilasciare un SDK secondario nel quarto trimestre con API e funzionalità aggiuntive.

Iniziare a utilizzare Android 17

Puoi registrare qualsiasi dispositivo Pixel supportato per ricevere questo e i futuri aggiornamenti di Android beta over-the-air. Se non hai un dispositivo Pixel, puoi utilizzare le immagini di sistema a 64 bit con l'emulatore Android in Android Studio.

Se attualmente partecipi al programma Android Beta, ti verrà offerto un aggiornamento over-the-air alla versione beta 2.

Se hai la versione beta 26Q1 di Android e vuoi utilizzare la release stabile finale di 26Q1 e uscire dalla versione beta, devi ignorare l'aggiornamento over-the-air alla versione beta 2 di 26Q2 e attendere la release di 26Q1.

Ci interessa il tuo feedback, quindi ti preghiamo di segnalare i problemi e inviare le richieste di funzionalità nella pagina di feedback. Prima riceviamo il tuo feedback, più possiamo includerlo nel nostro lavoro sulla release finale.

Per un'esperienza di sviluppo ottimale con Android 17, ti consigliamo di utilizzare l'ultima anteprima di Android Studio (Panda). Una volta configurato, ecco alcune delle cose che devi fare:

• Compila con il nuovo SDK, esegui i test negli ambienti CI e segnala eventuali problemi nel nostro tracker nella pagina di feedback.
• Testa la compatibilità dell'app attuale, scopri se la tua app è interessata dalle modifiche in Android 17, installa l'app su un dispositivo o un emulatore con Android 17 ed esegui test approfonditi.

Aggiorneremo regolarmente le immagini di sistema di anteprima/beta e l'SDK durante il ciclo di release di Android 17. Dopo aver installato una build beta, riceverai automaticamente i futuri aggiornamenti

over-the-air per tutte le anteprime e le versioni beta successive.

Per informazioni complete, visita il sito per sviluppatori di Android 17.

Partecipa alla conversazione

Mentre ci avviciniamo alla stabilità della piattaforma e alla disponibilità generale di Android 17 entro la fine dell'anno, il tuo feedback rimane la nostra risorsa più preziosa. Se sei un utente che adotta le nuove tecnologie sul canale Canary o uno sviluppatore di app che esegue i test sulla versione beta 2, ti invitiamo a unirti alle nostre community e a inviare feedback. Teniamo conto dei tuoi gusti.