Oggi rilasceremo la seconda 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 tutela la privacy. Stiamo anche aggiungendo API avanzate per la misurazione della distanza, il trasferimento cross-device e altro ancora.

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

Esperienza utente e UI di sistema

Bolle

Le bolle sono una funzionalità di modalità finestra che offre una nuova esperienza UI mobile separata dall'API Bolle di messaggistica. Gli utenti possono creare una bolla dell'app sul proprio smartphone, pieghevole o tablet tenendo premuta a lungo l'icona di un'app in Avvio app. Sugli schermi di grandi dimensioni, nella barra delle app è presente una barra delle bolle in cui gli utenti possono organizzare, spostarsi tra le bolle e spostarle da e verso i punti di ancoraggio sullo schermo.

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

Le bolle non sono ancora completamente abilitate nella beta 2. Li troverai 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 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 effettuare selezioni dai 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 rispetto ai 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. Ciò ha reso piuttosto difficile supportare correttamente i touchpad nei giochi in prima persona. Ora, per impostazione predefinita, il sistema riconosce i movimenti del puntatore e i gesti di scorrimento quando il touchpad viene acquisito e li segnala 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)

Interactive Chooser resting bounds

Chiamando getInitialRestingBounds in ChooserSession di Android, la tua app può identificare la posizione di destinazione occupata dal selettore al termine delle animazioni e del caricamento dei dati, consentendo migliori aggiustamenti dell'interfaccia utente.

Connettività e cross-device

Trasferimento delle app cross-device

Una nuova API Handoff ti consente di specificare lo stato dell'applicazione da riprendere su un altro dispositivo, ad esempio un tablet Android. Se l'utente ha attivato questa opzione, il sistema sincronizza lo stato tramite CompanionDeviceManager e mostra un suggerimento di trasferimento nell'app di avvio dei dispositivi nelle vicinanze dell'utente. Questa funzionalità è progettata per offrire una continuità perfetta delle attività, consentendo agli utenti di riprendere il lavoro esattamente da dove lo avevano interrotto nel loro flusso di lavoro nell'ecosistema Android. Fondamentalmente, Handoff supporta sia le transizioni da app ad app native 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 misurazione avanzata

Stiamo aggiungendo il supporto per due nuove tecnologie di misurazione della distanza: 

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

Miglioramenti al piano dati

Per ottimizzare la qualità dei contenuti multimediali, ora la tua app può recuperare le velocità di trasferimento 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 da accessi non autorizzati 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 a dispositivi sulla rete locale (LAN), come dispositivi per la smart home o 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. Le app che hanno come target Android 17 o versioni successive ora avranno due percorsi per mantenere la comunicazione con i dispositivi LAN: adottare selettori di dispositivi con mediazione del sistema e tutela della 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 della differenza 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 all'ora legale. Questo completa gli intent di trasmissione esistenti ACTION_TIME_CHANGED e ACTION_TIMEZONE_CHANGED, che vengono attivati quando il timestamp Unix cambia e quando l'ID fuso orario cambia, rispettivamente.

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 manifest per evitare di non poter accedere alla NPU. 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 ora.

Protezione OTP via SMS

Android sta ampliando 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 SMS Retriever viene ritardata di tre ore per la maggior parte delle app. Tuttavia, alcune app come l'app per SMS predefinita e l'app corrispondente 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 fornitore di servizi 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 dispone dell'autorizzazione a 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 garantendo che solo le app associate al dominio menzionato nel messaggio possano leggere il codice di verifica in modo programmatico. 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'OTP SMS 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 di messaggistica predefinita, l'app dell'assistente, nonché le app complementari per dispositivi connessi e così via, saranno esenti da questo ritardo.

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

Programma di Android 17

Passeremo rapidamente da questa versione beta al traguardo della stabilità della piattaforma, previsto per marzo. In questa fase, forniremo le API SDK/NDK finali. Da quel momento in poi, la tua app potrà avere come target l'SDK 37 e 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 uscite

Prevediamo che Android 17 continui a ricevere aggiornamenti in una serie di release trimestrali. La release in programma per il secondo trimestre è l'unica in cui verranno introdotte modifiche al comportamento che potrebbero causare problemi alle app. Prevediamo di rilasciare una versione secondaria dell'SDK 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 via OTA. 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 Android 26Q1 Beta e vuoi utilizzare la release stabile finale di 26Q1 e uscire dalla versione beta, devi ignorare l'aggiornamento OTA alla versione beta 2 di 26Q2 e attendere il rilascio di 26Q1.

Ci piacerebbe ricevere il tuo feedback, quindi segnala problemi e invia richieste di funzionalità nella pagina dei feedback. Prima riceviamo il tuo feedback, più elementi possiamo includere nel nostro lavoro sulla versione 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 cose che dovresti fare:

• Compila in base al nuovo SDK, esegui il test negli ambienti CI e segnala eventuali problemi nel nostro tracker nella pagina di feedback.
• Testa la tua app attuale per verificarne la compatibilità, scopri se è interessata dalle modifiche in Android 17 e installala su un dispositivo o un emulatore con Android 17 per testarla a fondo.

Aggiorneremo regolarmente le immagini di sistema di anteprima/beta e l'SDK durante il ciclo di rilascio di Android 17. Una volta installata una build beta, riceverai automaticamente gli aggiornamenti futuri 

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

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

Partecipa alla conversazione

Man mano che 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. Che tu sia un early adopter sul canale Canary o uno sviluppatore di app che esegue test sulla versione beta 2, ti consigliamo di unirti alle nostre community e inviare feedback. Ti ascoltiamo.