Google avrebbe modificato il sistema di distribuzione del codice sorgente per i dispositivi Pixel, sostituendo gli aggiornamenti automatici con una procedura manuale basata su un modulo online. La nuova modalità, segnalata dal team di GrapheneOS, potrebbe rendere più complesso lo sviluppo di sistemi operativi alternativi e rallentare la pubblicazione di aggiornamenti e patch di sicurezza.
google cambia l’accesso al codice dei pixel
In passato, il codice necessario per lavorare sui componenti software dei Pixel veniva pubblicato su piattaforme accessibili agli sviluppatori, permettendo il download immediato e una consultazione trasparente della cronologia delle modifiche. Secondo GrapheneOS, Google richiederebbe ora la compilazione di un Google Form prima di fornire i file attraverso un collegamento a Google Drive.
Un’attività che in precedenza poteva richiedere poche ore sarebbe così diventata una procedura capace di richiedere diverse settimane. Inoltre, la cronologia degli aggiornamenti risulterebbe riunita in un unico file più difficile da analizzare, con conseguenze sulla possibilità di seguire in modo ordinato le modifiche apportate al codice.
perché il codice del kernel è importante
Lo sviluppo di software personalizzato per smartphone dipende da due elementi principali: le ROM alternative, come GrapheneOS, e il kernel, cioè il componente che collega il sistema operativo all’hardware del dispositivo.
obblighi open source e ritardi per gli sviluppatori
Le licenze open source, tra cui la GPLv2, impongono la distribuzione del codice del kernel. In precedenza Google lo rendeva disponibile tramite aggiornamenti automatici su una piattaforma pubblica. La procedura segnalata da GrapheneOS introdurrebbe invece una richiesta individuale e un’attesa per ricevere i file.
Senza un kernel aggiornato e verificato, i sistemi operativi alternativi non possono procedere regolarmente con i nuovi porting di Android e con le patch di sicurezza. I ritardi nella consegna del codice possono quindi rallentare l’intera pipeline di sviluppo.
- Attese più lunghe per ottenere il codice del kernel dei Pixel.
- Minore visibilità sulla cronologia delle modifiche.
- Possibili ritardi nella distribuzione di aggiornamenti e patch per le ROM personalizzate.
conseguenze per chi possiede un google pixel
Gli utenti che utilizzano il Pixel con la versione standard di Android non dovrebbero rilevare cambiamenti immediati. Gli aggiornamenti software ordinari e le patch di sicurezza continuerebbero ad arrivare direttamente da Google secondo le modalità consuete.
La situazione riguarda soprattutto chi acquista un Pixel per installare sistemi operativi focalizzati sulla privacy e sulla personalizzazione, come GrapheneOS. In questo caso, l’accesso tardivo al codice potrebbe causare un ritardo rispetto agli aggiornamenti ufficiali del dispositivo.
- Aggiornamenti più lenti per i sistemi operativi alternativi.
- Maggiore difficoltà per i ricercatori indipendenti nell’analisi delle modifiche.
- Minore trasparenza sulle componenti software e sui cambiamenti effettuati.
il rapporto tra grapheneos e motorola
Secondo il team di GrapheneOS, il problema riguarderebbe specificamente i Pixel e non Android nel suo complesso. La partnership con Motorola, destinata a portare sul mercato smartphone basati su GrapheneOS, dovrebbe evitare questo tipo di ostacolo perché il produttore gestirà direttamente il proprio codice hardware.
La collaborazione con Motorola segna inoltre la fine dell’esclusiva pluriennale di GrapheneOS sui dispositivi Pixel. Il progetto avrebbe indicato proprio le crescenti difficoltà nella realizzazione di versioni alternative di Android per i Pixel tra le ragioni della nuova partnership.
pixel e sviluppo android: cosa è cambiato
In passato Google distribuiva non solo il codice del kernel richiesto dalle licenze open source, ma anche la relativa cronologia completa dei commit. L’azienda forniva inoltre alberi dei dispositivi e file binari dei driver, elementi che non era obbligata a pubblicare.
Il Pixel era considerato una piattaforma di riferimento per AOSP e rappresentava quindi un dispositivo particolarmente utile per gli sviluppatori. Con Android 16, Google avrebbe spostato il riferimento di AOSP dal Pixel a un dispositivo virtuale chiamato “cuttlefish”. In seguito avrebbe interrotto la distribuzione degli alberi dei dispositivi e dei driver binari dei Pixel.
Attualmente, l’elemento più orientato agli sviluppatori rimasto sui Pixel sarebbe la possibilità di sbloccare facilmente il bootloader, insieme alla disponibilità delle immagini di fabbrica. Google non avrebbe ancora spiegato le ragioni dell’introduzione della procedura manuale né indicato se intenda ridurre i tempi di risposta.
Lascia un commento