Android cambia sideloading, Jetpack XR va in beta e Tinder accelera con R8

🤖 Cosa cambia

• Advanced Sideloading inizia il rollout con riavvio e attesa di 24 ore per installare app distribuite da sviluppatori Android non verificati.
• SceneCore, ARCore for Jetpack XR e XR Runtime raggiungono la beta, avvicinando le API fondamentali di Android XR alla stabilità.
• Tinder usa R8 Configuration Analyzer e riduce del 47% i cold start lenti, del 29% il download e del 28% gli ANR.

Google interviene contemporaneamente su distribuzione delle applicazioni, realtà estesa e prestazioni Android. Il nuovo flusso Advanced Sideloading ha iniziato una distribuzione progressiva sui dispositivi prima dell’entrata in vigore della verifica obbligatoria degli sviluppatori in alcuni mercati. Parallelamente, Jetpack SceneCore, ARCore for Jetpack XR e XR Runtime raggiungono lo stato beta, rendendo più stabile la base software di Android XR. Sul fronte delle prestazioni, Google e Tinder mostrano infine cosa può produrre R8 Configuration Analyzer su un’applicazione reale: meno codice inutile, download più piccolo, meno ANR e una riduzione significativa degli avvii a freddo percepiti come lenti.

Advanced Sideloading entra gradualmente nella distribuzione Android

La prima versione operativa di Advanced Sideloading sta iniziando ad apparire progressivamente sui dispositivi Android, anticipando l’applicazione delle nuove regole di Developer Verification. Il meccanismo nasce per preservare la possibilità di installare software proveniente da sviluppatori non verificati senza rendere però l’operazione immediata come il sideloading tradizionale. Google aveva descritto ufficialmente l’Advanced Flow a marzo come una procedura destinata agli utenti consapevoli e costruita soprattutto per spezzare le dinamiche delle truffe telefoniche nelle quali la vittima viene guidata passo dopo passo alla disattivazione delle protezioni.

Il rollout attuale conferma questa impostazione: bisogna entrare nelle Developer Options, abilitare l’installazione da sviluppatori non verificati, autenticarsi, dichiarare di non essere sotto pressione, riavviare il dispositivo e attendere 24 ore prima di poter completare l’abilitazione per sette giorni oppure senza scadenza. ADB resta escluso dalla verifica, mantenendo un canale diretto per sviluppatori e attività tecniche. Il sistema completa il percorso già emerso con il rafforzamento del Verifier e del sideloading in Android 17 e con le nuove regole analizzate da LineageOS.

La verifica sviluppatori parte il 30 settembre in quattro Paesi

L’attrito aggiunto dall’Advanced Flow diventa comprensibile osservando il calendario della nuova Android Developer Verification. Google ha confermato nella roadmap ufficiale della verifica che dal 30 settembre 2026 le protezioni inizieranno a essere applicate in Brasile, Indonesia, Singapore e Thailandia, per poi espandersi globalmente dal 2027. Gli sviluppatori che distribuiscono applicazioni al di fuori di Google Play possono registrarsi attraverso Android Developer Console, mentre chi utilizza Play Console può registrare anche APK distribuiti attraverso store o canali esterni. Google sostiene che la verifica riguardi l’identità del soggetto che distribuisce il software e non una revisione editoriale dell’applicazione, mantenendo quindi distinta questa architettura dal modello chiuso di uno store unico. La società afferma inoltre di avere individuato una quantità di malware oltre 90 volte superiore nelle sorgenti sideloaded rispetto a Google Play, dato utilizzato per giustificare l’introduzione di un’identità verificabile dietro ogni distributore. La libertà di installazione non scompare, ma cambia forma: il percorso standard privilegia software registrato, mentre quello non verificato viene spostato dietro una procedura deliberatamente lenta e consapevole.

Jetpack XR porta tre librerie fondamentali allo stato beta

Sul fronte dello sviluppo, Google porta contemporaneamente a un livello molto più maturo il Jetpack XR SDK. Nel rilascio ufficiale del 18 agosto raggiungono la beta Jetpack SceneCore, ARCore for Jetpack XR e XR Runtime, mentre Jetpack Compose for XR rimane per ora in alpha e dovrebbe seguire successivamente. SceneCore gestisce scene tridimensionali, modelli 3D, audio spaziale ed entity-component system; ARCore for Jetpack XR fornisce percezione dell’ambiente attraverso depth estimation, persistent anchors, hit testing e riconoscimento dei piani; XR Runtime costituisce invece la base per ciclo di vita dei dispositivi, creazione delle sessioni e configurazione del sistema. Il passaggio da preview a beta significa soprattutto che le API stanno stabilizzandosi, rendendo più ragionevole integrarle in progetti destinati alla produzione. Google ha inoltre esteso gli strumenti di testing, trasformato Session.create in una suspend function coerente con le coroutine Kotlin e rinominato AnchorEntity in AnchorSpace, uniformando la gestione degli spazi. Le librerie SceneCore, ARCore e Runtime arrivano alla versione 1.0.0-beta02 e possono essere testate su Samsung Galaxy XR oppure attraverso Android XR Emulator. Il passaggio consolida il percorso già seguito con Android XR e le nuove protezioni dedicate agli occhiali AI.

R8 Configuration Analyzer trova il collo di bottiglia nascosto in Tinder

Google utilizza Tinder come caso concreto per mostrare il valore del nuovo R8 Configuration Analyzer. Prima dell’intervento, circa il 70% del codice dell’app Android non risultava ottimizzato nonostante R8 fosse già attivo, perché una keep rule interna eccessivamente ampia impediva al compilatore di applicare shrinking e ottimizzazioni a un’enorme quantità di classi. Il case study ufficiale pubblicato da Android Developers mostra come Configuration Analyzer abbia permesso di individuare la regola problematica misurando separatamente Shrinking Score, Optimization Score e Obfuscation Score.

Lo strumento evidenzia regole troppo generiche, ridondanti, obsolete o ereditate dalle librerie, consentendo agli sviluppatori di capire esattamente quali classi rimangono escluse dalle trasformazioni di R8. Nel caso Tinder una regola -keep applicata praticamente a tutte le classi pubbliche aveva accumulato negli anni debito tecnico e impediva ottimizzazioni anche su componenti che non utilizzavano reflection. Dopo aver ristretto la regola alle sole classi realmente necessarie, l’Optimization Score dell’app è passato dal 28 al 50%, liberando immediatamente margine per minification e riorganizzazione del codice.

Tinder riduce cold start, dimensioni e ANR con una modifica alla build

Gli effetti misurati mostrano perché l’ottimizzazione della build possa essere importante quanto un processore più veloce. Tinder ha registrato una riduzione del 47% degli utenti colpiti da cold start lenti, mentre il download dell’app è passato da 86,6 a 61,5 MB, pari a un calo del 28,98%. I file DEX sono scesi da 17 a 11, con soltanto due dedicati allo startup invece di tre, mentre gli ANR percepiti dagli utenti sono passati dallo 0,35 allo 0,28%. Google riporta anche un incremento dell’engagement del 3%, particolarmente evidente nei mercati dove gli smartphone con poca RAM rappresentano una quota maggiore del parco installato. Tinder ha quindi inserito il controllo delle metriche R8 nella pipeline CI/CD, in modo da individuare regressioni generate da nuove dipendenze o keep rule prima della pubblicazione. I tre sviluppi della giornata mostrano tre livelli differenti della stessa strategia Android: controllare meglio chi distribuisce software, stabilizzare le API per le nuove categorie hardware e ridurre il costo computazionale delle applicazioni già esistenti. L’innovazione non passa soltanto dalle nuove funzioni del sistema operativo, ma anche dai meccanismi che determinano come un’app viene installata, compilata ed eseguita.