Installare APK richiederà una connessione, limiti notevoli per hobbisti e appassionati

Google vuole rivoluzionare il sideloading su Android. Una nuova politica di verifica degli sviluppatori, pur mantenendo la funzionalità, introduce barriere significative per sviluppatori indipendenti, studenti e per l’intero ecosistema di app alternative come F-Droid.

La necessità di una connessione internet per l’installazione di alcuni APK è solo la punta dell’iceberg.

Sideloading in pericolo su Android?

A partire dal prossimo anno, il panorama del sideloading su Android, ovvero l’installazione manuale di applicazioni tramite file APK al di fuori del Play Store, è destinato a cambiare in modo radicale. Google ha confermato una nuova politica che bloccherà l’installazione di app provenienti da sviluppatori non verificati, una mossa che aveva inizialmente scatenato il timore della fine del sideloading stesso.

Dopo settimane di silenzio, l’azienda ha chiarito la sua posizione: il sideloading non sparirà, ma sarà soggetto a un nuovo e più stringente processo di verifica che, in alcuni scenari, richiederà una connessione di rete attiva.

In un video esplicativo e in un post sul blog intitolato “il sideloading è fondamentale per Android“, Google ha dettagliato il funzionamento del nuovo sistema, cercando di placare le preoccupazioni ma, al contempo, confermando l’arrivo di limitazioni che avranno un impatto notevole su una vasta platea di utenti e creatori.

Come funzionerà la verifica delle app?

Attualmente, quando un utente tenta di installare un’app, il sistema operativo Android esegue già una serie di controlli: verifica che non sia già installata un’app con lo stesso ID di pacchetto, che non sia obsoleta e, soprattutto, che non sia stata segnalata come malware da Google Play Protect.

A questo processo si aggiungerà un nuovo passaggio obbligatorio. Al momento dell’installazione, ogni nuova app dovrà superare una verifica gestita da una nuova entità di sistema preinstallata, denominata Android Developer Verifier. Questo servizio comunicherà con il sistema operativo per determinare se lo sviluppatore dell’app è stato verificato, se sono emersi problemi durante il controllo e quale politica di installazione applicare.

Per stabilire se uno sviluppatore è verificato, l’Android Developer Verifier dovrà controllare che il pacchetto dell’app e la chiave crittografica utilizzata per firmarlo siano stati registrati presso Google.

Poiché è impossibile mantenere un database completo e aggiornato di tutte le possibili combinazioni direttamente sul dispositivo, in quello che Google definisce “lo scenario peggiore“, lo smartphone avrà bisogno di una connessione a internet per completare la verifica.

Per mitigare questo requisito, Google prevede due soluzioni. In primo luogo, il servizio di verifica manterrà una cache delle app più popolari e già verificate, consentendone l’installazione offline. In secondo luogo, gli app store alternativi potranno integrare un “token di pre-autorizzazione“, un “blob crittograficamente verificabile” associato al pacchetto, che permetterà di convalidare lo sviluppatore senza ulteriori chiamate ai server di Google.

Queste modifiche saranno introdotte nativamente con il secondo aggiornamento trimestrale di Android 16 (QPR2), previsto per dicembre, sebbene le policy non saranno immediatamente applicate. La funzionalità verrà inoltre estesa alle versioni precedenti di Android tramite un aggiornamento di Google Play Protect.

Duro colpo per hobbisti e studenti

Una delle concessioni annunciate da Google era la creazione di un tipo di account speciale nella Developer Console per hobbisti e studenti, con requisiti di verifica ridotti e l’esenzione dalla quota di registrazione di 25 dollari.

A prima vista, una soluzione ideale per gli sviluppatori indipendenti che distribuiscono gratuitamente le loro creazioni su piattaforme come GitHub o F-Droid. Tuttavia, la realtà è ben diversa.

Gli sviluppatori che opteranno per questo tipo di account affronteranno restrizioni di distribuzione estremamente severe. La principale è un limite al numero di dispositivi su cui le loro app possono essere installate.

Per far rispettare questo vincolo, ogni utente che desidera installare l’app dovrà prima ottenere un identificatore univoco dal proprio dispositivo e comunicarlo allo sviluppatore. Quest’ultimo dovrà quindi inserire manualmente questo codice nella Android Developer Console per autorizzare l’installazione su quello specifico dispositivo.

Questo meccanismo è stato volutamente progettato per limitare la distribuzione su larga scala, relegando questi account a un uso puramente personale o per la condivisione con un numero ristretto e noto di persone.

Sebbene sia possibile convertire l’account in uno standard, questa barriera iniziale rappresenta un ostacolo insormontabile per chiunque desideri semplicemente condividere un piccolo progetto con una community online.

Store alternativi e privacy

Le nuove policy sollevano anche serie preoccupazioni per la privacy e per la sopravvivenza di store alternativi. Google ha affermato che non renderà pubbliche le informazioni sugli sviluppatori, riconoscendo l’esistenza di motivi legittimi per l’anonimato (come nel caso di app per dissidenti), ma non si è impegnata a non condividere tali dati con le autorità governative.

Il problema più spinoso riguarda F-Droid, il cui modello operativo è intrinsecamente incompatibile con il nuovo sistema. F-Droid, infatti, compila le app direttamente dal codice sorgente fornito dagli sviluppatori e le firma con le proprie chiavi. Questo crea due versioni della stessa app con lo stesso nome di pacchetto, ma firmate da due entità diverse: lo sviluppatore originale e il team di F-Droid.

Google ha dichiarato che, per evitare che più soggetti rivendichino la proprietà dello stesso pacchetto, darà la preferenza allo sviluppatore la cui versione ha il maggior numero di installazioni note.

Per molte app su F-Droid, questo significa che il team dello store diventerebbe di fatto il “proprietario” verificato, costringendo lo sviluppatore originale a cambiare il nome del pacchetto per distribuire la sua versione altrove, una pratica che viola la filosofia di F-Droid e crea una frammentazione insensata.

Esistono delle eccezioni, come per le app distribuite tramite strumenti di gestione aziendale (MDM) su dispositivi gestiti, che non richiederanno la verifica. Tuttavia, per chi distribuisce app su dispositivi offline, Google ha laconicamente suggerito di “determinare autonomamente come gestire le richieste di verifica“, ad esempio connettendosi periodicamente a internet.

Molte domande restano ancora senza risposta, come il futuro di strumenti avanzati come Shizuku che sfruttano i permessi ADB.

Se da un lato l’intento di Google è palesemente quello di rafforzare la sicurezza dell’ecosistema Android contro il malware, dall’altro il prezzo di questa sicurezza sembra essere una significativa erosione della libertà e dell’apertura che hanno sempre caratterizzato la piattaforma, erigendo nuove e complesse barriere per la fiorente comunità di sviluppatori indipendenti e appassionati.