
Redazione RHC : 16 Luglio 2025 07:08
All’inizio di quest’anno, Google ha annunciato che avrebbe sviluppato Android interamente a porte chiuse per semplificare e velocizzare le cose. Si parlava di passare a un’unica branca interna invece di diverse branche parallele. All’epoca, parte della comunità degli sviluppatori Android reagì alla notizia con allarme, ma la tempesta si placò rapidamente, poiché l’azienda aveva precedentemente apportato la maggior parte delle modifiche a porte chiuse, pur promettendo che il codice sorgente sarebbe stato comunque pubblicato. Tuttavia, le recenti modifiche alla parte aperta di Android hanno nuovamente sollevato un’ondata di preoccupazioni sul fatto che Google possa abbandonare la distribuzione completa del codice sorgente.
Questa settimana, come promesso, l’azienda ha finalmente rilasciato il codice sorgente di Android 16 nell’ambito del progetto AOSP con licenza open source Apache 2.0. Tuttavia, gli sviluppatori hanno notato che questa volta mancava qualcosa. I cosiddetti file “device tree” per i dispositivi Pixel sono scomparsi dalla pubblicazione: si tratta di un set di configurazioni che in precedenza semplificava la compilazione di Android per modelli specifici. Inoltre, non sono stati rilasciati nuovi driver binari e la cronologia dei commit nel codice sorgente del kernel è stata compressa in un unico commit comune. In precedenza, Google pubblicava regolarmente tutto questo e la scomparsa di tali elementi è diventata un segnale allarmante.
Alcuni hanno deciso che questo sia il primo passo verso la chiusura del progetto AOSP. In risposta, il vicepresidente della piattaforma Android di Google, Sean Chau, ha affermato che le voci sono infondate e ha sottolineato che il progetto rimane aperto. Ha spiegato che Android necessita di un dispositivo di riferimento indipendente da un produttore specifico e che possa essere utilizzato liberamente dagli sviluppatori. Il dispositivo virtuale Cuttlefish fungerà ora da piattaforma di riferimento, che funzionerà su PC standard e consentirà di testare nuove funzionalità Android senza essere vincolato all’hardware. Google continuerà inoltre a supportare le immagini di sistema GSI universali, adatte alla maggior parte dei dispositivi.
Christmas Sale -40% 𝗖𝗵𝗿𝗶𝘀𝘁𝗺𝗮𝘀 𝗦𝗮𝗹𝗲! Sconto del 𝟰𝟬% 𝘀𝘂𝗹 𝗽𝗿𝗲𝘇𝘇𝗼 𝗱𝗶 𝗰𝗼𝗽𝗲𝗿𝘁𝗶𝗻𝗮 del Corso "Dark Web & Cyber Threat Intelligence" in modalità E-Learning sulla nostra Academy!🚀
Fino al 𝟯𝟭 𝗱𝗶 𝗗𝗶𝗰𝗲𝗺𝗯𝗿𝗲, prezzi pazzi alla Red Hot Cyber Academy. 𝗧𝘂𝘁𝘁𝗶 𝗶 𝗰𝗼𝗿𝘀𝗶 𝘀𝗰𝗼𝗻𝘁𝗮𝘁𝗶 𝗱𝗲𝗹 𝟰𝟬% 𝘀𝘂𝗹 𝗽𝗿𝗲𝘇𝘇𝗼 𝗱𝗶 𝗰𝗼𝗽𝗲𝗿𝘁𝗶𝗻𝗮.
Per beneficiare della promo sconto Christmas Sale, scrivici ad [email protected] o contattaci su Whatsapp al numero di telefono: 379 163 8765.
Se ti piacciono le novità e gli articoli riportati su di Red Hot Cyber, iscriviti immediatamente alla newsletter settimanale per non perdere nessun articolo. La newsletter generalmente viene inviata ai nostri lettori ad inizio settimana, indicativamente di lunedì. |
Dal punto di vista di Google, la logica dei cambiamenti è chiara. L’azienda non vuole più utilizzare Pixel come benchmark per AOSP, poiché questo smartphone è un prodotto di consumo finale con molti miglioramenti proprietari. In questo senso, il Cuttlefish virtuale appare più universale, sebbene non sia in grado di riprodurre al cento per cento il comportamento dell’hardware reale.
Ancora più importante, questo avrà un impatto sulla community di sviluppatori di firmware personalizzati come LineageOS. Uno dei principali contributori al progetto, Nolan Johnson, ha affermato che sviluppare firmware per Pixel diventerà “dolorosamente” difficile. In precedenza, gli sviluppatori potevano semplicemente prendere configurazioni già pronte da Google, apportare le proprie modifiche e compilare il sistema. Ora dovranno utilizzare configurazioni obsolete di Android 15 e, attraverso tentativi ed errori, capire cosa è cambiato analizzando i file binari predefiniti.
Senza un albero dei dispositivi, è impossibile sviluppare Android completamente per un dispositivo specifico, poiché questi file descrivono l’hardware, i driver e altri parametri importanti. Inoltre, la scomparsa della cronologia dei commit del kernel impedisce agli sviluppatori di monitorare le correzioni di bug e le vulnerabilità. Sebbene Google non sia legalmente obbligata a pubblicare questi dati, lo fa da anni perché Pixel era considerato una piattaforma di test aperta.
Ora le cose sono cambiate. Per i team di LineageOS e GrapheneOS che creano build Android personalizzate per Pixel, il processo è diventato notevolmente più complesso. Sebbene tecnicamente possano ancora sviluppare AOSP, ora devono ricostruire l’intera configurazione da zero, come hanno fatto a lungo con altri dispositivi Android. L’unico vantaggio rimasto di Pixel è che è ancora facile sbloccare e flashare un’immagine di fabbrica, ma la strada per una ROM personalizzata stabile è diventata molto più tortuosa.
Redazione
All’interno del noto Dark Forum, l’utente identificato come “espansive” ha messo in vendita quello che descrive come l’accesso al pannello di amministrazione dell’Agenzia delle Entrate. Tu...

In seguito alla scoperta di due vulnerabilità zero-day estremamente critiche nel motore del browser WebKit, Apple ha pubblicato urgentemente degli aggiornamenti di sicurezza per gli utenti di iPhone ...

La recente edizione 2025.4 di Kali Linux è stata messa a disposizione del pubblico, introducendo significative migliorie per quanto riguarda gli ambienti desktop GNOME, KDE e Xfce. D’ora in poi, Wa...

La saga sulla sicurezza dei componenti di React Server continua questa settimana. Successivamente alla correzione di una vulnerabilità critica relativa all’esecuzione di codice remoto (RCE) che ha ...

Un nuovo allarme arriva dal sottobosco del cybercrime arriva poche ore fa. A segnalarlo l’azienda ParagonSec, società specializzata nel monitoraggio delle attività delle cyber gang e dei marketpla...