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.
PARTE LA PROMO ESTATE -40%
RedHotCyber Academy lancia una promozione esclusiva e a tempo limitato per chi vuole investire nella propria crescita professionale nel mondo della tecnologia e della cybersecurity!
Approfitta del 40% di sconto sull’acquisto congiunto di 3 corsi da te scelti dalla nostra Academy. Ad esempio potresti fare un percorso formativo includendo Cyber Threat intelligence + NIS2 + Criptovalute con lo sconto del 40%. Tutto questo lo potrai fruire, dove e quando vuoi e con la massima flessibilità, grazie a lezioni di massimo 30 minuti ciascuna.
Contattaci tramite WhatsApp al 375 593 1011 per richiedere ulteriori informazioni oppure scriviti alla casella di posta [email protected]
Supporta RHC attraverso:
Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.
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.
RedazioneA cura del Cyber Defence Center Maticmind (Andrea Mariucci, Riccardo Michetti, Federico Savastano, Ada Spinelli) Il threat actor SCATTERED SPIDER, UNC9344 fa la sua comparsa nel 2022, con due attacchi...
In seguito alla conferenza per la ricostruzione dell’Ucraina gli hacktivisti del gruppo russofono di NoName(057)16 hanno avviato una nuova campagna di attacchi DDoS con obiettivo diversi target...
Questa mattina, gli hacker di NoName057(16) hanno sferrato attacchi DDoS contro diversi obiettivi italiani. Name057(16) è un gruppo di hacker che si è dichiarato a m...
Questo strumento è destinato esclusivamente a scopi didattici e di penetration testing autorizzati. L’autore non si assume alcuna responsabilità per eventuali usi impropri o dann...
Gli esperti di sicurezza di 0din hanno individuato una falla critica in Google Gemini for Workspace, la quale permette ai malintenzionati di inserire direttive malevole all’interno delle email....
Copyright @ REDHOTCYBER Srl
PIVA 17898011006
