Android 17 Beta 2: ecco come Google blinda gli SMS e i codici OTP

Con Android 17 Beta 2 Google prosegue il percorso verso una piattaforma più attenta a privacy, sicurezza e prestazioni, ma senza stravolgere l’esperienza d’uso. La nuova versione introduce alcune funzioni concrete che toccano interfaccia, connettività, rete locale e soprattutto la gestione dei codici OTP via SMS.

Questa beta si inserisce nel nuovo ritmo di rilascio di Android 17, con una fase di test piuttosto serrata in vista della Platform Stability prevista a marzo e di una serie di aggiornamenti trimestrali nel corso dell’anno.

La funzione Bubbles diventa una modalità di finestra flottante distinta dalle classiche bolle di messaggistica. L'utente può creare una bolla di un'app con una pressione prolungata sull'icona nel launcher, su smartphone, pieghevoli e tablet, e sui grandi schermi compare una barra delle bolle nella taskbar per organizzare e spostare queste finestre ancorate.

Arriva la nuova EyeDropper API a livello di sistema, che permette alle app di richiedere un colore da qualsiasi pixel sullo schermo senza dover usare permessi di cattura schermo sensibili. L'app avvia un'azione di sistema dedicata e riceve in risposta il valore del colore selezionato dall'utente.

Debutta anche un selettore dei contatti di sistema tramite l'azione ACTION_PICK_CONTACTS, che concede un accesso in lettura temporaneo e legato alla sessione solo ai campi dati richiesti. Le app possono specificare, ad esempio, se servono email o numeri di telefono, impostare la selezione multipla e un limite massimo di contatti, con supporto sia al profilo personale sia a quello lavorativo del dispositivo.

Per chi sviluppa giochi in prima persona o app che usano touchpad, Android 17 semplifica la pointer capture: quando un'app cattura il puntatore, il sistema ora interpreta di default i movimenti del touchpad come eventi relativi in stile mouse, più gestibili nei motori di gioco. Rimane comunque disponibile la modalità assoluta, che continua a fornire le coordinate grezze delle dita sul touchpad.

Android introduce inoltre i resting bounds per il Chooser: in questo modo un'app può sapere dove si posizionerà il pannello di condivisione dopo animazioni e caricamenti, così da adattare meglio la propria interfaccia.

In chiusura, questa ondata di novità sull'interfaccia mostra come Google stia cercando di rendere più coerente e controllabile il comportamento delle finestre e dei componenti di sistema, lasciando alle app meno margine di ambiguità e più strumenti per integrarsi in modo pulito.

Sul fronte cross-device arriva una nuova API di Handoff che consente di definire lo stato dell'applicazione da riprendere su un altro dispositivo, ad esempio un tablet Android. Il sistema sincronizza questi dati tramite CompanionDeviceManager e propone un suggerimento di handoff nel launcher dei dispositivi vicini, così da continuare un'attività senza doverla ricostruire da zero.

L'API di Handoff supporta sia il passaggio app‑to‑app tra applicazioni native, sia un fallback app‑to‑web quando l'app non è installata sul dispositivo di destinazione, in modo da mantenere comunque un flusso di lavoro completo.

Android 17 Beta 2 introduce anche nuove API di ranging avanzato. La prima riguarda UWB DL‑TDOA, che permette alle app di usare l'ultra wideband per la navigazione indoor e puntando a una localizzazione che preserva la privacy, evitando il tracciamento del dispositivo da parte dell'ancora.

La seconda novità è la Proximity Detection basata sulla nuova specifica di ranging adottata dalla Wi‑Fi Alliance (WFA). Questa tecnologia punta a una maggiore affidabilità e precisione rispetto alle soluzioni precedenti basate su Wi‑Fi Aware, sempre nell'ambito della misurazione della distanza tra dispositivi.

Per le app di streaming, Android 17 consente ora di leggere le velocità massime di dati che l'operatore assegna alle applicazioni multimediali, così da poter adeguare la qualità dei contenuti al profilo di rete previsto.

Nel complesso, queste API di connettività e ranging mostrano come Android stia cercando di strutturare meglio l'uso di dispositivi vicini e reti wireless, con strumenti più precisi e regolati per continuità operativa e localizzazione.

Con Android 17 arriva il nuovo permesso runtime ACCESS_LOCAL_NETWORK, pensato per proteggere l'accesso alla rete locale (LAN). Il permesso rientra nel gruppo NEARBY_DEVICES, quindi chi ha già concesso altri permessi di questo gruppo non vedrà un'ulteriore richiesta. Dichiarando e richiedendo questo permesso, un'app può scoprire e collegarsi a dispositivi sulla LAN, come dispositivi per la casa connessa o ricevitori di casting.

L'obiettivo è limitare l'uso non controllato della rete locale, che potrebbe favorire tracciamento e fingerprinting da parte di app malevole. Le app che puntano ad Android 17 o versioni successive hanno due strade: usare i selettori di dispositivo di sistema, che mediano la connessione senza richiedere il permesso, oppure chiedere esplicitamente ACCESS_LOCAL_NETWORK per mantenere una comunicazione diretta con i dispositivi LAN.

Sul fronte dell'orario, Android introduce il broadcast ACTION_TIMEZONE_OFFSET_CHANGED, che si attiva quando cambia l'offset del fuso orario, ad esempio durante il passaggio all'ora legale. Questo si affianca ai broadcast già esistenti ACTION_TIME_CHANGED (variazione del timestamp Unix) e ACTION_TIMEZONE_CHANGED (cambio dell'ID di fuso orario), offrendo un segnale più preciso per chi deve reagire alle sole modifiche di offset.

Per l'accesso diretto alla NPU, le app che puntano ad Android 17 devono ora dichiarare nel manifest la feature introdotte con la nuova versione di Android, altrimenti il sistema blocca l'uso dell'unità neurale. La regola vale per chi utilizza il delegato LiteRT per NPU, gli SDK dei produttori e anche la NNAPI ormai obsoleta.

Le librerie di internazionalizzazione passano a ICU 78, con supporto ampliato a nuovi alfabeti, caratteri e blocchi di emoji, oltre alla possibilità di formattare direttamente gli oggetti di tipo orario. In questo modo il sistema aggiorna la base tecnica per la gestione delle lingue e dei simboli.

Questi interventi su permessi, orario e NPU indicano una direzione più rigorosa: accessi alla rete locale più controllati, gestione del tempo più granulare e uso dell'hardware di accelerazione vincolato a una dichiarazione esplicita.

Android 17 estende in modo deciso la protezione degli SMS con OTP, introducendo un ritardo automatico nell’accesso ai messaggi che contengono codici di verifica. Finora la protezione si concentrava sui messaggi nel formato SMS Retriever, ritardando per la maggior parte delle app la consegna di questi SMS di circa 3 ore, con eccezioni per l’app SMS predefinita e per l’app associata all’hash.

Con la nuova beta, il ritardo di 3 ore si applica a tutti gli SMS che contengono un OTP. Per la maggior parte delle app, il sistema blocca il broadcast SMS_RECEIVED_ACTION e filtra le query al database degli SMS, rendendo il messaggio disponibile solo dopo il tempo di attesa, così da ridurre il rischio di furto di codici.

Per gli SMS nel formato WebOTP, se un’app ha il permesso di leggere gli SMS ma non risulta il destinatario previsto del codice (in base alla verifica del dominio), il messaggio rimane inaccessibile per 3 ore. La modifica vale per tutte le app, indipendentemente dal livello di API di destinazione, e punta a far sì che solo le app legate al dominio indicato possano leggere automaticamente il codice.

Per gli SMS con OTP che non usano né WebOTP né SMS Retriever, Android applica lo stesso ritardo di 3 ore per la maggior parte delle app, ma solo se puntano ad Android 17 (API 37) o versioni successive. Restano esentate alcune categorie, come l’app SMS predefinita, l’assistente e le app companion dei dispositivi collegati.

Google invita tutte le app che leggono gli SMS per estrarre OTP a passare alle API SMS Retriever o SMS User Consent, così da continuare a funzionare correttamente in questo nuovo scenario di accesso differito ai messaggi.

Questa stretta sugli OTP via SMS mostra una chiara priorità: ridurre la superficie di attacco per il furto di codici di verifica, spingendo le app verso canali più strutturati e meno invasivi rispetto alla lettura indiscriminata degli SMS.

Per quanto riguarda la roadmap, Google punta a raggiungere la Platform Stability di Android 17 a marzo, momento in cui rilascerà le API SDK/NDK finali. Da quel punto in avanti, le app potranno puntare al SDK 37 e pubblicare su Google Play, così da completare i test e raccogliere feedback nei mesi che precedono la disponibilità generale.

Nel corso dell'anno, Android 17 riceverà una serie di aggiornamenti trimestrali. Il rilascio del secondo trimestre (Q2) sarà l'unico a introdurre modifiche di comportamento potenzialmente incompatibili per le app, mentre nel quarto trimestre (Q4) è previsto un minor SDK update con ulteriori API e funzionalità.

Chi possiede un Pixel supportato può iscriversi al programma Android Beta e ricevere Android 17 Beta 2 tramite aggiornamento OTA. In alternativa, sono disponibili le immagini di sistema a 64 bit per l'emulatore in Android Studio. Gli utenti già iscritti al programma riceveranno automaticamente l'aggiornamento a Beta 2.

Per chi utilizza la beta di Android 26Q1 e vuole passare alla versione stabile di 26Q1 uscendo dal programma, Google specifica di ignorare l'aggiornamento OTA a 26Q2 Beta 2 e attendere il rilascio della build finale di 26Q1.

In prospettiva, questa Beta 2 conferma un approccio fatto di passi ravvicinati e mirati: meno effetti speciali, più attenzione a permessi, sicurezza e comportamenti di sistema che incidono direttamente sul modo in cui le app interagiscono con l'ecosistema Android.

L'articolo Android 17 Beta 2: ecco come Google blinda gli SMS e i codici OTP sembra essere il primo su Smartworld.