Android 17 rompe una vecchia regola dopo 15 anni: nuove API senza rilascio AOSP

Per oltre 15 anni Google ha mantenuto una regola piuttosto importante per chi costruisce sistemi operativi derivati da Android: quando una release introduce nuove API pubbliche della piattaforma, il relativo codice arriva anche nell’Android Open Source Project (AOSP). Android 17 QPR1 rompe, almeno per ora, questa consuetudine. GrapheneOS sostiene infatti che si tratti della prima versione dai tempi di Android 3.x Honeycomb a mettere a disposizione degli sviluppatori nuove API senza accompagnarle con una corrispondente release completa della piattaforma su AOSP.

Ovviamente non significa che Android 17 stia diventando “proprietario”, né che Google abbia smesso di pubblicare codice open source. Al contrario, il ramo pubblico android17-release continua a esistere, Google lo indica ancora come riferimento corrente di AOSP e il kernel Android 17 riceve aggiornamenti pubblici regolari.

Il problema sollevato da GrapheneOS riguarda un livello diverso: Android 17 QPR1 contiene API di piattaforma nuove, documentate da Google come API level 37.1, mentre il codice necessario per implementare integralmente quella versione non risulta pubblicato nello stesso momento attraverso AOSP.

Perché GrapheneOS richiama addirittura Android Honeycomb

Il precedente storico citato da GrapheneOS è significativo. Android 3.0 Honeycomb uscì nel 2011 soprattutto per i tablet, ma Google decise di non pubblicare l’intero codice sorgente della piattaforma. La documentazione AOSP conserva ancora oggi una nota esplicita: per Honeycomb il sorgente completo non è disponibile; risultano pubblicati soltanto i componenti soggetti a licenze GPL e LGPL.

All’epoca Google spiegò che Honeycomb era stato progettato per dispositivi con schermi grandi e che la piattaforma non era ancora pronta per essere adattata ad altre categorie di prodotti. Il codice completo tornò a essere pubblicamente disponibile con la successiva generazione di Android. Dal punto di vista storico, quindi, il paragone di GrapheneOS è calzante: Android 3.x rappresenta davvero una delle anomalie più evidenti nella storia della pubblicazione dei sorgenti Android.

Android 17 QPR1 introduce davvero nuove API pubbliche

Il rapporto ufficiale API Differences Report confronta API level 37, associato ad Android 17, con API level 37.1. Il documento elenca un nuovo package, android.hardware.hid, oltre a modifiche che interessano numerose aree del framework e parti delle librerie Java.

Non parliamo quindi soltanto di correzioni interne o di un diverso numero di build: HID significa Human Interface Device, termine che fa riferimento a tastiere, mouse, controller di gioco e altre periferiche che scambiano report strutturati con il sistema operativo. HidDevice permette, tra le altre cose, di conoscere vendor ID e product ID, leggere il report descriptor, identificare il tipo di trasporto e inviare feature report oppure output report. I trasporti previsti comprendono USB, Bluetooth, I2C, SPI e dispositivi virtuali.

Dal punto di vista di uno sviluppatore è un aspetto tecnico importate: se un’app viene compilata per sfruttare un’API disponibile a partire da 37.1, la presenza dell’interfaccia deve poi trovare una reale implementazione nel framework del dispositivo. Ed è proprio qui che il rapporto fra SDK, framework e sorgenti AOSP diventa importante.

Cosa cambia per i produttori Android

GrapheneOS, che abbiamo presentato in una nostra guida dedicata, non può limitarsi a installare il firmware Pixel e considerare concluso il lavoro. Deve integrare il codice della piattaforma, applicare le proprie modifiche di sicurezza, ricompilare il sistema, verificare compatibilità e regressioni e adattare i componenti specifici dell’hardware. Senza i sorgenti della release effettivamente distribuita sui dispositivi Google Pixel, alcune parti devono essere temporaneamente recuperate o adattate in altro modo.

I manutentori del progetto GrapheneOS lamentano soprattutto il fatto che AOSP non opera più necessariamente sulla stessa fotografia della piattaforma che Google usa sui Pixel. Più cresce la distanza temporale fra codice pubblico e software distribuito, più aumenta il lavoro necessario per mantenere parità funzionale, supporto hardware e compatibilità.

La situazione degli OEM tradizionali è più difficile da valutare dall’esterno. Samsung, Qualcomm, MediaTek e altri partner lavorano con Google attraverso accordi e canali ai quali il pubblico non ha accesso; non possiamo quindi concludere che ricevano il codice nello stesso momento di AOSP, più tardi oppure attraverso repository separati.

La denuncia di GrapheneOS dimostra una differenza tra ciò che Google distribuisce sui Pixel e ciò che rende contemporaneamente disponibile nel repository AOSP pubblico. Non conferma, da sola, che tutti i produttori Android siano tecnicamente esclusi dalle API 37.1.

Non sappiamo ancora se si tratta di una scelta permanente

Al momento manca un elemento essenziale: una spiegazione ufficiale di Google sul motivo per cui Android 17 QPR1, pur introducendo API 37.1, non abbia ricevuto contestualmente una nuova release completa del codice AOSP corrispondente.

Potrebbe trattarsi di un ritardo nella pubblicazione, di una modifica del calendario delle QPR oppure dell’inizio di una diversa politica di distribuzione dei sorgenti. I dati disponibili non permettono ancora di scegliere una di queste interpretazioni.

Va detto però che Android 16 aveva già mostrato una pubblicazione AOSP non perfettamente sincronizzata con il calendario atteso: GrapheneOS ricorda che Android 16 QPR1 arrivò su AOSP l’11 novembre 2025 invece del 3 settembre. Android 17 QPR1 aggiunge un elemento nuovo, perché nel frattempo Google documenta API pubbliche specifiche della release.

È proprio questo il punto da osservare nei prossimi aggiornamenti. Se Google pubblicherà a breve il codice completo di QPR1, l’episodio potrà essere interpretato soprattutto come un ritardo. Se le future QPR continueranno invece a introdurre API disponibili prima sui Pixel e solo successivamente – o non integralmente – nel ramo pubblico, cambierà concretamente il rapporto fra Android distribuito da Google e Android ricostruibile partendo da AOSP.