Obblighi di certificazione per le app, incertezza sui tempi di supporto per i Pixel 10, una partnership hardware inattesa: negli ultimi mesi attorno a GrapheneOS si sono accumulati segnali contrastanti, e non tutti raccontano la stessa storia. In questo video Davide Galanti mette in fila quello che sappiamo con ragionevole certezza, quello che resta speculazione e quello che tutto questo significa concretamente per chi vuole un telefono che sia davvero suo.
La notizia che circola da mesi, e che a un certo punto è diventata quasi un ritornello, dice più o meno questo: da settembre 2026 Android non consentirà più di installare applicazioni non certificate, cioè app che non siano passate dal Google Play Store e che non portino con sé un certificato di uno sviluppatore riconosciuto.
Tradotto in pratica: chi sviluppa dovrà accreditarsi presso Google, e la sua applicazione dovrà avere un certificato che la renda “valida” per girare sul sistema operativo. La data indicata per l’entrata a regime di questi cambiamenti è settembre 2026.
La reazione prevedibile è stata:
Ma come, Android non era l’open source fatto persona? Non era il sistema dove installavi quello che ti pareva, da dove ti pareva?
Da lì a fare due più due il passo è stato breve: se le app devono passare da una validazione centrale, allora progetti come GrapheneOS, costruiti su Android ma volutamente fuori dal perimetro Google, hanno i mesi contati, e la scadenza è proprio settembre 2026.
Il punto interessante, però, non è la notizia in sé. È capire cosa cambia davvero: nella possibilità di installare software liberamente, nella sostenibilità di progetti come GrapheneOS, e nel grado di controllo che un’azienda o una persona conserva sul proprio dispositivo
GrapheneOS è una distribuzione Android costruita attorno a tre priorità: privacy, riduzione della superficie di attacco e controllo effettivo dell’utente sul dispositivo. Il lavoro non si limita a togliere componenti: c’è un’attività continua di hardening del sistema e delle applicazioni che va oltre quello che offre Android nella sua versione standard. (Nel parlo anche qui: GrapheneOS sul Pixel: il primo passo verso una vera sicurezza aziendale)
La differenza rispetto ad Android “classico” sta soprattutto nel rapporto con i servizi Google. Su GrapheneOS i Google Play Services non sono preinstallati né privilegiati: si possono installare, ma girano in modalità sandboxed, come una qualsiasi applicazione senza permessi speciali. È una scelta architetturale precisa, perché sposta i servizi Google da componente di sistema a software applicativo, con tutto quello che ne consegue in termini di accessi e di visibilità sui dati. A questo si accompagna la possibilità di installare applicazioni da fonti diverse dal Play Store, con una logica che ricorda da vicino quella di una macchina Linux: ci metti quello che ti serve, senza chiedere il permesso a uno store centrale.
Per chi gestisce infrastruttura IT, questa impostazione ha ricadute concrete. Significa poter costruire e distribuire package interni per applicazioni verticali senza passare da un canale di validazione esterno, avere visibilità su quali componenti di tracciamento sono effettivamente presenti sul dispositivo, e adottare un modello di gestione più vicino a quello che si usa da sempre in un’infrastruttura tradizionale che a quello di un ecosistema consumer chiuso.
Da qui la domanda che in molti si stanno facendo: un modello così regge davvero ai cambiamenti annunciati da Google?
Nel corso del 2026 sono emersi alcuni elementi che, messi in fila, aiutano a capire in che direzione stiano andando le cose. E raccontano qualcosa di diverso rispetto alla narrazione della fine annunciata.
A cavallo tra fine 2025 e inizio 2026 la situazione sui Pixel 10 era in sospeso. Non era chiaro quando sarebbero arrivate le versioni per la nuova famiglia (Pixel 10, 10A, 10 Pro, Pro XL, fold): dal progetto arrivava l’intenzione di supportarli, ma nessuna data.
Poi, a pochi giorni di distanza dalle polemiche su sorgenti e licensing, GrapheneOS ha rilasciato la build con piena compatibilità per l’intera famiglia Pixel 10. Il dettaglio non è secondario: significa che, tensioni con Google a parte, il progetto riesce ancora a stare al passo con l’hardware appena uscito. Non è esattamente il comportamento di un progetto in fase di spegnimento.
A marzo 2026 Motorola ha annunciato una partnership con GrapheneOS Foundation, e la notizia è stata letta in modi radicalmente opposti. C’è chi vi ha visto un segnale positivo. “Finalmente un vendor diverso da Google” C’è poi chi invece ha sollevato dubbi sull’assetto societario di Motorola, controllata dal 2014 dal gruppo cinese Lenovo, e su quali garanzie possa realmente offrire in materia di privacy e controllo.
Al netto delle letture politiche, sul piano tecnico il segnale è piuttosto leggibile. Poter contare su più piattaforme hardware compatibili, e non solo sui Pixel, riduce la dipendenza del progetto da una singola linea di dispositivi. E un progetto che dipende da un solo fornitore di hardware è, per definizione, un progetto più fragile nel medio periodo.
A inizio agosto 2026 il progetto ha sollevato un problema che merita attenzione, perché tocca un meccanismo di base. Secondo GrapheneOS, Google non starebbe rilasciando in modo completo e tempestivo alcuni sorgenti necessari, e in particolare mancherebbero i repository git pubblici per diversi componenti. Il codice arriverebbe a contagocce, con una procedura che va richiesta via Google Form, scaricata da Drive e che restituisce archivi frammentati, privi dello storico completo dei commit.
La differenza non è formale, anche se a prima vista può sembrarlo. Un repository git pubblico espone l’intera cronologia delle modifiche, commit per commit: permette di vedere cosa è cambiato, quando e per quale motivo, e di tenere allineata una distribuzione derivata senza lavorare al buio. Un archivio compresso rilasciato a intervalli irregolari, invece, offre solo fotografie discontinue del codice, molto più onerose da integrare e sostanzialmente impossibili da auditare nel dettaglio.
Per GrapheneOS questo comportamento violerebbe in modo esplicito la licenza GPL v2, alla quale Google aderisce per le parti open source di Android. Vale la pena sottolineare che si tratta di una posizione espressa dal progetto, non di una violazione accertata da un’autorità terza.
Il modo in cui la questione è stata sollevata dice comunque qualcosa: un progetto che denuncia pubblicamente problemi di trasparenza e licensing non è un progetto che sta preparando le valigie.
Rimettendo insieme i pezzi del 2026, la conclusione ragionevole è che GrapheneOS non sembra affatto “fuori gioco” a settembre. Il progetto è attivo, ha appena aggiunto il supporto per hardware appena uscito, ha aperto un canale con Motorola e ha la lucidità di denunciare pubblicamente quello che ritiene un problema di licensing. Sono tutti indicatori di vitalità, non di chiusura.
Gli elementi che restano fermi, allo stato attuale, sono tre. Il primo: nessun obbligo di registrazione per gli sviluppatori imposto dal progetto stesso, il che significa poter costruire pacchetti interni e installarli direttamente, senza passaggi da validazioni esterne. È una condizione che in ambito industriale o aziendale fa una differenza sostanziale. Il secondo: nessun meccanismo di age verification forzata. Il terzo, e forse il più importante: nessun soggetto centrale che decida cosa puoi installare sul tuo dispositivo.
Detto in altri termini, il telefono resta un dispositivo su cui è l’utente o l’IT manager a decidere cosa gira. La stessa logica di una distribuzione Linux.
Questo non significa che il tema sia chiuso. Molto dipenderà da come Google evolverà le policy sul bootloader, sul verified boot e sull’integrità del sistema, da come verranno applicati i requisiti di certificazione delle app sui dispositivi Android, e da quanta pressione continuerà a esserci sui sorgenti e sui rilasci GPL. Ma tra “scenario da monitorare” e “fine annunciata” c’è una distanza notevole, ed è utile non confonderli.
Se sei un responsabile IT o un system administrator, la domanda pratica non è filosofica ma operativa: quando ha senso valutare GrapheneOS, o soluzioni analoghe, e quali sono i costi reali rispetto a un parco dispositivi Android standard gestito via MDM (Mobile Device Management, la piattaforma con cui si amministrano centralmente i dispositivi aziendali)?
Il vantaggio è il controllo: si sa quali componenti Google sono presenti e come sono confinati, e si gestiscono aggiornamenti e permessi con criteri propri. Il prezzo è l’integrazione. Rinunciare o limitare l’ecosistema Play Services significa che alcune applicazioni enterprise, alcune notifiche push e alcuni flussi di autenticazione che si davano per scontati richiedono verifica preventiva. Non è un ostacolo insormontabile, ma è lavoro che va messo a budget prima, non scoperto dopo.
GrapheneOS riduce la superficie di attacco e applica hardening a un livello superiore rispetto ad Android standard: limita quello che può girare in background e restringe i canali di comunicazione verso l’esterno. Su dispositivi che trattano dati sensibili, o in scenari dove i requisiti di compliance sono stringenti, è un elemento coerente con un approccio zero trust e con una segmentazione ragionata del parco dispositivi. Il rovescio della medaglia è la gestione nel tempo: vanno verificati modello per modello la compatibilità con gli strumenti di MDM/EMM già in uso, l’integrazione con i sistemi di identità e l’impatto sull’esperienza d’uso di utenti abituati ad Android “classico”.
La partnership con Motorola conferma che il progetto sta cercando di allargare la propria base hardware, ed è una buona notizia per chi ragiona in ottica di continuità. Resta però un punto da presidiare: le linee di dispositivi realmente supportate cambiano nel tempo, e la valutazione va fatta modello per modello, verificando supporto ufficiale, tempistiche di rilascio degli aggiornamenti e politiche di allineamento alle patch di sicurezza.
Alla luce di quello che è disponibile oggi, non emergono elementi che indichino la scomparsa di GrapheneOS a settembre 2026. Il progetto supporta già i Pixel 10, ha avviato una collaborazione con Motorola e continua a sollevare pubblicamente problemi di trasparenza e licensing con Google.
Il modello resta orientato all’assenza di obblighi di registrazione per gli sviluppatori, di verifica forzata dell’età e di soggetti terzi che filtrino cosa installare.
Per chi gestisce infrastruttura IT, la domanda utile non è “GrapheneOS morirà?”, ma un’altra: in quali scenari ha senso introdurre GrapheneOS o soluzioni simili, quali compromessi si è disposti ad accettare sul piano dell’ecosistema e della gestione, e come si posiziona questa scelta rispetto alle proprie politiche di sicurezza e di compliance.
Settembre 2026 arriverà, e probabilmente porterà con sé qualche elemento in più per capire come si stanno muovendo davvero Google e i progetti che ne stanno fuori. Nel frattempo, resta una scommessa aperta — e le scommesse aperte sono tecnicamente le più interessanti, perché costringono a guardare l’architettura invece di limitarsi ai titoli.
Se il tema ti interessa,e vuoi seguire come evolve la vicenda sul canale YouTube di Serverlab e nella newsletter continuiamo a ragionare su questi temi con lo stesso approccio: capire come funzionano le cose prima di decidere.
Nel frattempo, una domanda vale la pena portarsela a casa: quanto controllo hai davvero sui dispositivi mobili della tua organizzazione, e quanto invece dipende da scelte prese altrove?
FONTI e LINK UTILI:
https://grapheneos.social/@GrapheneOS/117078064184215730
https://developer.android.com/developer-verification
https://android-developers.googleblog.com/2026/06/android-developer-verification.html
https://discuss.grapheneos.org/d/32656-motorola-partnership-announcement
Ottimizza l'efficienza del tuo lavoro
