Aptoide entra in Google Play: cosa cambia davvero per APK, sideloading e F-Droid

Vedere Aptoide Games direttamente dentro Google Play sembra quasi un controsenso. Per anni gli store Android alternativi hanno rappresentato uno dei modi per distribuire applicazioni senza passare dallo store di Google; adesso una di queste piattaforme può essere scaricata dallo stesso Play Store e, una volta installata, accedere al suo ricco catalogo di giochi e applicazioni.

La novità è reale e molto importante, ma bisogna subito chiarire un punto: al momento riguarda solo gli USA. Dal 22 luglio 2026 Google permette infatti alle piattaforme Android statunitensi di terze parti che soddisfano determinati requisiti di essere distribuite attraverso Google Play agli utenti d’Oltreoceano, grazie al nuovo Programma per store di terze parti. E ad agosto 2026 Aptoide Games è diventato il primo store concorrente effettivamente disponibile attraverso Google Play.

L’apertura nasce dalla lunga controversia giudiziaria tra Epic Games e Google nonché dalle successive modifiche imposte al funzionamento di Google Play sul mercato statunitense. Google stessa ha fissato al 15 luglio 2026 l’inizio dell’onboarding per gli store concorrenti e al 22 luglio l’effettiva apertura del programma.

Gli APK installati attraverso Aptoide escono davvero dal controllo di Google? Che differenza c’è rispetto a F-Droid? E come si inquadra tutto questo con Android Developer Verification, il nuovo sistema che associa l’identità dello sviluppatore ai package Android e alle relative chiavi di firma?

Come ha fatto Aptoide a entrare in Google Play

Google ha creato il Programma per store di terze parti: uno store Android può diventare esso stesso un’applicazione distribuita attraverso Google Play.

In passato un utente che voleva installare Aptoide doveva normalmente procurarsi il relativo APK al di fuori di Play e autorizzare Android a installare applicazioni provenienti da quella sorgente. Negli USA, Aptoide Games può invece adesso arrivare sul dispositivo attraverso il medesimo processo utilizzato per una normale applicazione Android scaricata dal Play Store.

Per aderire al programma, uno store deve soddisfare una lunga serie di requisiti pubblicati da Google: deve essere gestito da un’organizzazione verificata, deve rappresentare una piattaforma che distribuisce applicazioni di sviluppatori terzi, deve disporre dei diritti necessari alla distribuzione e deve offrire procedure per aggiornamenti, rimozioni, reclami e controversie.

Sono previsti inoltre requisiti relativi alla sicurezza, al trattamento delle applicazioni potenzialmente dannose, alle violazioni delle policy e alla trasparenza verso gli utenti.

Gli APK di Aptoide su Google Play non passano inosservati a Google

Si potrebbe pensare che Google controlli soltanto l’app Aptoide Games e che, una volta installata, Aptoide possa distribuire qualsiasi APK senza ulteriori verifiche da parte della società di Mountain View. Le regole del programma dicono invece qualcosa di diverso.

Gli operatori che partecipano al Programma per store di terze parti devono fornire a Google gli APK e le versioni aggiornate delle applicazioni distribuite nell’ambito del programma stesso. Google dispone inoltre di strumenti per effettuare controlli automatici e manuali sulle app del catalogo.

Google autorizza uno store concorrente a usare Play Store come mezzo di distribuzione, ma contemporaneamente impone condizioni anche sul software che quello store intende successivamente proporre agli utenti. Aptoide dentro Play non rappresenta una “porta laterale” attraverso cui far entrare applicazioni completamente invisibili ai sistemi Google.

Google ha anche aperto in contemporanea, sempre negli USA, il Programma di accesso al catalogo Play: a partire dal 22 luglio 2026 gli store Android di terze parti aderenti possono accedere al catalogo Google Play e mostrare agli utenti applicazioni che fanno parte del marketplace Google. Il fatto che la scheda di un’app appaia dentro un marketplace concorrente non significa quindi che lo store terzo possieda e distribuisca il corrispondente APK.

Programma app store registrati Google: cosa significa

Google ha annunciato, entro fine settembre 2026, l’arrivo anche in Italia e in Europa del nuovo Programma app store registrati: lo ha descritto come un modo per semplificare l’installazione di store Android che continuano a essere distribuiti al di fuori di Google Play.

Oggi Android tratta ad esempio F-Droid come una normale applicazione proveniente da una sorgente esterna: il sistema richiede quindi le consuete autorizzazioni per l’installazione da quella fonte e, al momento, mostra gli avvisi previsti dal sideloading.

Il Programma app store registrati introduce la possibilità di un percorso differente: uno store che decide volontariamente di partecipare al programma può registrarsi presso Google e dimostrare di rispettare determinati criteri di qualità e sicurezza. Quando un utente prova successivamente a installare quello store tramite sideloading, Android può riconoscerlo come marketplace registrato e proporgli un processo di installazione più semplice.

Lo store, in questo caso, continua a provenire dal web o da un’altra sorgente esterna e non diventa un’app di Google Play.

L’adesione al Programma app store registrati è facoltativa: se lo store decide di non registrarsi, continua a essere installabile come qualsiasi altra applicazione caricata tramite sideloading.

E poi c’è Android Developer Verification: opera a un livello ancora diverso

Se il Programma app store registrati risponde alla domanda “Android riconosce questo software come uno store registrato?”, Android Developer Verification risponde invece a al quesito seguente: “chi è responsabile dell’applicazione che sto installando e quali chiavi sono autorizzate a firmarla?”

Android Developer Verification che il sistema associa l’identità del distributore software ai package Android destinati ai dispositivi certificati.

Google sottolinea che il controllo riguarda chi ha sviluppato e registrato l’applicazione, non il luogo dal quale l’APK proviene. Nella pagina di supporto dedicata, Google paragona il sistema a un controllo d’identità separato dal controllo del contenuto: vuole sapere chi c’è dietro il software, indipendentemente dal canale utilizzato per distribuirlo.

I portavoce di Mountain View hanno fatto presente che il sideloading resterà possibile su Android e che gli sviluppatori verificati potranno continuare a distribuire applicazioni direttamente oppure attraverso qualunque store.

Le app provenienti da sviluppatori non verificati resteranno installabili: come abbiamo raccontato in altri nostri articoli, Google ha introdotto un advanced flow destinato agli utenti esperti. La FAQ ufficiale precisa che, dopo una configurazione iniziale e l’accettazione esplicita dei rischi, sarà possibile installare software proveniente da sviluppatori non verificati. Inoltre ADB continuerà a consentire l’installazione di app non verificate, come Google conferma nella stessa documentazione. Il percorso da seguire è tuttavia nettamente più lungo e complesso rispetto alla soluzione precedente.

Perché F-Droid contesta Android Developer Verification

Il caso F-Droid mette in luce uno degli aspetti tecnicamente più delicati di Android Developer Verification. F-Droid non funziona necessariamente come Google Play o Aptoide: per molte applicazioni il repository non riceve semplicemente un APK già compilato dallo sviluppatore, ma parte dal codice sorgente, lo compila attraverso la propria infrastruttura e produce il pacchetto destinato agli utenti. Storicamente F-Droid ha inoltre creato una chiave di firma dedicata per ciascuna app, quindi lo stesso progetto può esistere come APK firmato dallo sviluppatore originale e come APK F-Droid firmato con una chiave differente.

Ed è proprio qui che si creano problemi con il modello approvato da Google: Android Developer Verification non registra soltanto il nome di un’app ma associa il package name a uno o più certificati di firma.

La nuova Android Developer ID Status API permette di controllare la coppia formata da package e fingerprint SHA-256 del certificato. Essa prevede esplicitamente lo stato REGISTERED_WITH_ANOTHER_CERTIFICATE_FINGERPRINT quando il package risulta registrato, ma non con la firma dell’APK sottoposto al controllo. Google consente di registrare più signing key per lo stesso package ma tali chiavi devono comunque entrare nel sistema di registrazione. Per F-Droid significa che una sua build dell’app Android org.example.app, firmata con una chiave differente da quella utilizzata dallo sviluppatore che pubblica sul Play Store, non può essere considerata automaticamente equivalente alla versione registrata dall’autore originale.

F-Droid sta riducendo da tempo la divergenza attraverso le build riproducibili: il repository ricompila autonomamente il sorgente e confronta il risultato con l’APK prodotto dallo sviluppatore; se i due oggetti coincidono, fatta eccezione per gli elementi legati alla firma, F-Droid può distribuire il pacchetto APK firmato direttamente dallo sviluppatore upstream.

Il vero punto dello scontro tra F-Droid e Google

Nel caso descritto, Developer Verification crea meno problemi: l’app scaricata da F-Droid conserva lo stesso package e la stessa identità crittografica della versione distribuita dal suo autore. F-Droid utilizza inoltre il campo AllowedAPKSigningKeys per memorizzare il digest SHA-256 del certificato autorizzato e rifiutare un APK se la firma non corrisponde a quella prevista. È interessante notare che, sul piano tecnico, sia F-Droid sia Google finiscono quindi per controllare la relazione tra package e chiave di firma, ma con una differenza fondamentale: F-Droid usa questo dato per verificare l’integrità del software all’interno di un processo di build aperto, mentre Google lo collega anche all’identità registrata dello sviluppatore.

Ed è soprattutto da quest’ultimo punto che nasce la polemica. In una presa di posizione molto critica, F-Droid sostiene che Google stia trasformando la registrazione dello sviluppatore in una sorta di autorità centrale necessaria per la normale distribuzione del software sui dispositivi Android certificati, anche quando Google Play non entra affatto nella catena di distribuzione.

Secondo il progetto, la sicurezza può essere ottenuta anche attraverso codice sorgente pubblico, log di compilazione verificabili, build riproducibili e sistemi come Play Protect, senza obbligare chi pubblica software libero a registrare presso Google la propria identità e i propri package. Google presenta invece Developer Verification come una misura di accountability: collegare le applicazioni a sviluppatori verificati dovrebbe rendere più difficile per gli autori di malware cambiare continuamente identità e tornare a distribuire software dannoso.

Come già evidenziato in precedenza, Google afferma che gli store alternativi potranno continuare a essere utilizzati ma F-Droid contesta il principio secondo cui la normale installazione di un APK su un dispositivo di proprietà dell’utente debba dipendere da una registrazione gestita da Google.