Questo documento contiene le risposte a domande generali sulla piattaforma Android Open Source (AOSP).
Informazioni su android-latest-release
Perché non posso inviare contenuti ad aosp-main?
Non puoi inviare a aosp-main perché questo ramo è ora di sola lettura.
Dove devo proporre modifiche ad AOSP?
Devi proporre nuove modifiche a android-latest-release (quando utilizzi Repo) o
al ramo di rilascio più recente specificato nel manifest android-latest-release
(quando utilizzi Git direttamente). Le modifiche proposte esistenti in altri rami (ad esempio
aosp-main) non devono essere spostate.
A quale ramo devo sincronizzare?
Quando utilizzi Repo, sincronizza con
android-latest-releaseutilizzando il seguente comando:repo init --partial-clone --no-use-superproject -b android-latest-release -u https://android.googlesource.com/platform/manifestQuando utilizzi Git direttamente, esegui la sincronizzazione con il ramo di revisione predefinito specificato nel
android-latest-releasemanifest.
Per ulteriori dettagli sulla sincronizzazione dei rami, consulta Inizializzare il client Repo.
Il codice di android-latest-release verrà unito ad aosp-main?
No, il codice non verrà unito a aosp-main, che è un ramo di sola lettura a partire dal
27 marzo 2025.
Dove viene eseguito il push del codice per la prossima release?
Google esegue il push del codice per la release successiva nel ramo dell'ultima release pubblica
e aggiorna il android-latest-release manifest in modo che punti a quel ramo.
La mia richiesta di modifica verrà selezionata dal ramo android-latest-release e inserita nel Gerrit interno?
Dopo aver caricato una modifica proposta, Google la esaminerà e, se accettata, la selezionerà per inserirla nel Gerrit interno.
Come faccio a sapere se la mia richiesta di modifica è stata accettata?
Le modifiche accettate e selezionate vengono visualizzate in un push futuro a un ramo di rilascio sull'host Android e possono essere sincronizzate con repo utilizzando android-latest-release.
Non esiste un meccanismo di notifica per l'accettazione o il rifiuto di una modifica proposta.
Qual è il flusso di lavoro generale dal momento in cui una modifica viene proposta da un collaboratore esterno al momento in cui viene unita al branch dell'ultima release?
Un collaboratore esterno propone una modifica a
android-latest-release(quando utilizzi Repo) o al ramo di rilascio più recente specificato nel manifestandroid-latest-release(quando utilizzi Git direttamente).Google esamina la modifica. Se la modifica è:
Accettata, Google seleziona la modifica e la unisce al ramo di sviluppo interno.
Non accettata, Google non seleziona la modifica.
Il collaboratore esterno controlla la sua modifica in
android-latest-release.
Cosa succede se non ho più bisogno della modifica proposta?
Se non hai più bisogno della modifica proposta, non vuoi che venga unita o sai che Google l'ha già esaminata, abbandonala in modo che rimanga nella cronologia delle modifiche proposte sull'host Android.
Domande sull'open source
Perché Google ha aperto il codice sorgente di Android?
Google ha avviato l'AOSP in risposta alle proprie esperienze di lancio di app mobile. Volevamo assicurarci che ci fosse sempre una piattaforma aperta a disposizione di operatori, OEM e sviluppatori per trasformare le loro idee innovative in realtà. Volevamo anche evitare qualsiasi punto centrale di errore, in modo che nessun singolo attore del settore potesse limitare o controllare le innovazioni di altri. Il nostro obiettivo più importante con AOSP è garantire che il software Android open source venga implementato nel modo più ampio e compatibile possibile, a vantaggio di tutti.
Che tipo di progetto open source è Android?
Google supervisiona lo sviluppo di AOSP di base e si impegna a creare community solide di sviluppatori e utenti. Per la maggior parte, il codice sorgente di Android è concesso in licenza ai sensi della licenza Apache 2.0, piuttosto che di una licenza copyleft. Abbiamo scelto la licenza Apache 2.0 perché riteniamo che incoraggi l'adozione diffusa del software Android. Per maggiori dettagli, vedi Licenze.
Perché Google è responsabile di Android?
Il lancio di una piattaforma software è complesso. L'apertura è fondamentale per il successo a lungo termine di una piattaforma, perché attira investimenti da parte degli sviluppatori e garantisce condizioni di parità. Inoltre, la piattaforma deve essere un prodotto interessante per gli utenti.
Google ha impegnato le risorse di ingegneria professionale necessarie per garantire che Android sia una piattaforma software pienamente competitiva. Google considera il progetto Android come un'operazione di sviluppo di prodotti su vasta scala e conclude gli accordi commerciali necessari per garantire che sul mercato arrivino ottimi dispositivi con Android.
Assicurandoci che Android abbia successo tra gli utenti, contribuiamo a garantire la vitalità di Android come piattaforma e come progetto open source. Dopo tutto, chi vuole il codice sorgente di un prodotto che non ha avuto successo?
Il nostro obiettivo è garantire un ecosistema di successo intorno ad Android. Abbiamo reso open source il codice sorgente di Android in modo che chiunque possa modificare e distribuire il software per soddisfare le proprie esigenze.
Qual è la strategia generale di Google per lo sviluppo di prodotti Android?
Lanciamo dispositivi eccezionali in un mercato competitivo. Successivamente, incorporiamo le innovazioni e i miglioramenti apportati nella piattaforma principale come versione successiva.
In pratica, il team di ingegneria di Android si concentra su un numero ridotto di dispositivi "di punta" e sviluppa la versione successiva del software Android per supportare questi lanci di prodotti. Questi dispositivi di punta assorbono gran parte del rischio del prodotto e aprono la strada alla vasta community di OEM, che segue con più dispositivi che sfruttano le nuove funzionalità. In questo modo, ci assicuriamo che la piattaforma Android si evolva in base alle esigenze dei dispositivi reali.
Come viene sviluppato il software Android?
Ogni versione della piattaforma Android (ad esempio 1.5 o 8.1) ha un ramo corrispondente
nell'albero open source. Il ramo più recente è considerato la versione del ramo stabile
corrente a cui fa riferimento il manifest android-latest-release.
Questo è il ramo che i produttori trasferiscono sui loro
dispositivi. Questo ramo viene mantenuto sempre adatto al rilascio.
Infine, Google lavora alla prossima versione della piattaforma Android in tandem con lo sviluppo di un dispositivo di punta.
Perché alcune parti di Android vengono sviluppate in privato?
In genere, occorre più di un anno per lanciare un dispositivo sul mercato. E, naturalmente, i produttori di dispositivi vogliono spedire il software più recente possibile. Al contempo, gli sviluppatori non vogliono monitorare costantemente le nuove versioni della piattaforma durante la scrittura delle app. Entrambi i gruppi vivono una tensione tra la spedizione dei prodotti e la paura di rimanere indietro.
Per risolvere questo problema, alcune parti della prossima versione di Android, incluse le API della piattaforma principale, vengono sviluppate in un ramo privato. Queste API costituiscono la prossima versione di Android. Il nostro obiettivo è concentrare l'attenzione sulla versione stabile attuale del codice sorgente di Android durante la creazione della prossima versione della piattaforma. Ciò consente a sviluppatori e OEM di utilizzare una singola versione senza dover tenere traccia di lavori futuri non completati solo per rimanere al passo.
Quando vengono rilasciati i codici sorgente?
Quando sono pronti. Il rilascio del codice sorgente è una procedura piuttosto complessa. Alcune parti di Android, come il kernel, sono sviluppate in modo aperto e il codice sorgente è sempre disponibile. Altre parti vengono sviluppate prima in un albero privato e il codice sorgente viene rilasciato quando la versione successiva della piattaforma è pronta.
In alcune release, le API della piattaforma principale sono pronte con un anticipo sufficiente per consentirci di pubblicare il codice sorgente per una visualizzazione anticipata prima del rilascio del dispositivo. In altre versioni, questa operazione non è possibile. In tutti i casi, rilasciamo il codice sorgente della piattaforma quando riteniamo che la versione sia stabile e quando il processo di sviluppo lo consente.
Cosa comporta il rilascio del codice sorgente per una nuova versione di Android?
Il rilascio del codice sorgente per una nuova versione della piattaforma Android è un processo significativo. Innanzitutto, il software è integrato in un'immagine di sistema per un dispositivo e sottoposto a varie forme di certificazione, tra cui la certificazione normativa governativa per le regioni in cui verranno distribuiti gli smartphone. Il codice viene sottoposto anche a test dell'operatore. Si tratta di una fase importante del processo, perché aiuta a rilevare i bug del software.
Quando la release viene approvata dagli enti regolatori e dagli operatori, il produttore inizia la produzione di massa dei dispositivi e noi iniziamo a rilasciare il codice sorgente.
Contemporaneamente alla produzione di massa, il team di Google avvia diverse iniziative per preparare il rilascio open source. Questi sforzi includono l'apporto di modifiche finali all'API, l'aggiornamento della documentazione (per riflettere eventuali modifiche apportate durante i test di qualificazione, ad esempio), la preparazione di un SDK per la nuova versione e il lancio delle informazioni sulla compatibilità della piattaforma.
Il nostro team legale esegue una firma finale per rilasciare il codice in open source. Proprio come i collaboratori open source sono tenuti a firmare un Contratto di licenza per i collaboratori che attesti la proprietà intellettuale del loro contributo, Google deve verificare che la fonte sia autorizzata a fornire contributi.
Dal momento in cui inizia la produzione di massa, il processo di rilascio del software richiede in genere circa un mese, pertanto i rilasci del codice sorgente avvengono spesso nello stesso periodo in cui i dispositivi raggiungono gli utenti.
Qual è il rapporto tra AOSP e il Programma di compatibilità Android?
AOSP si occupa della manutenzione del software Android e sviluppa nuove versioni. Poiché è open source, questo software può essere utilizzato per qualsiasi scopo, incluso lo sviluppo di dispositivi non compatibili con altri dispositivi basati sulla stessa origine.
La funzione del programma di compatibilità Android è definire un'implementazione di base di Android compatibile con le app di terze parti scritte dagli sviluppatori. I dispositivi compatibili con Android possono partecipare all'ecosistema Android, incluso Google Play; i dispositivi che non soddisfano i requisiti di compatibilità non fanno parte di questo ecosistema.
In altre parole, il Programma di compatibilità Android è il modo in cui separiamo i dispositivi compatibili con Android da quelli che eseguono semplicemente derivati del codice sorgente. Accogliamo con favore tutti gli utilizzi del codice sorgente Android, ma per partecipare all'ecosistema Android, un dispositivo deve essere identificato come compatibile con Android dal programma.
Come posso contribuire ad Android?
Puoi segnalare bug, scrivere app per Android o contribuire al codice sorgente all'AOSP.
Esistono limiti ai tipi di contributi di codice che accettiamo. Ad esempio, qualcuno potrebbe voler contribuire con un'API app alternativa, come un ambiente completo basato su C++. Rifiuteremmo questo contributo perché Android incoraggia l'esecuzione delle app nell'ambiente di runtime ART. Allo stesso modo, non accetteremo contributi come librerie GPL o LGPL incompatibili con i nostri obiettivi di licenza.
Invitiamo chi è interessato a contribuire con il codice sorgente a contattarci tramite i canali elencati nella community Android prima di iniziare qualsiasi lavoro. Per maggiori dettagli, vedi Contributi.
Come faccio a diventare un committer di Android?
L'AOSP non ha una nozione di committer. Tutti i contributi (inclusi quelli creati dai dipendenti di Google) vengono elaborati tramite un sistema basato sul web noto come Gerrit, che fa parte del processo di ingegneria di Android. Questo sistema funziona in tandem con il sistema di gestione del codice sorgente Git per gestire in modo pulito i contributi al codice sorgente.
Un responsabile dell'approvazione designato deve esaminare e accettare tutte le modifiche proposte. Gli approvatori sono in genere dipendenti di Google, ma gli stessi approvatori sono responsabili di tutti gli invii, indipendentemente dall'origine.
Per maggiori dettagli, vedi Invio di patch.