L'Android Open Source Project (AOSP) mantiene uno stack software completo che può essere portato da OEM e altri implementatori di dispositivi ed eseguito sul proprio hardware. Per mantenere la qualità di Android, Google ha contribuito a tempo pieno a ingegneri, product manager, designer di interfacce utente, tester di garanzia della qualità e tutti gli altri ruoli necessari per portare sul mercato i dispositivi moderni.
Di conseguenza, manteniamo una serie di codeline per separare chiaramente l'attuale versione stabile di Android dal lavoro sperimentale instabile. Inseriamo l'amministrazione open source e la manutenzione delle codeline Android nel più ampio ciclo di sviluppo del prodotto.
Gestione del codice AOSP
Il grafico seguente illustra i concetti alla base della gestione e delle versioni del codice AOSP.
- In qualsiasi momento, è disponibile un'ultima versione corrente della piattaforma Android. Questo in genere assume la forma di un ramo nell'albero.
- I creatori di dispositivi e i collaboratori lavorano con l'ultima versione corrente, correggendo bug, lanciando nuovi dispositivi, sperimentando nuove funzionalità e così via.
- Parallelamente, Google lavora internamente alla prossima versione della piattaforma e del framework Android in base alle esigenze e agli obiettivi del prodotto. Sviluppiamo la prossima versione di Android collaborando con un dispositivo partner su un dispositivo di punta le cui specifiche sono state scelte per spingere Android nella direzione in cui crediamo dovrebbe andare.
- Quando la versione n+1 è pronta, viene pubblicata nell'albero dei sorgenti pubblico e diventa la nuova versione più recente.
Termini e avvertenze
- Una versione corrisponde a una versione formale della piattaforma Android, ad esempio 1.5 o 8.1. Una versione della piattaforma corrisponde alla versione nel campo
SdkVersion
dei fileAndroidManifest.xml
e definita all'interno diframeworks/base/api
nell'albero dei sorgenti. - Un progetto upstream è un progetto open source da cui lo stack Android estrae il codice. Oltre a progetti come il kernel Linux e WebKit, continuiamo a migrare alcuni progetti Android semi-autonomi come ART, gli strumenti Android SDK e Bionic per funzionare come progetti a monte. Generalmente, questi progetti sono sviluppati interamente nell'albero pubblico. Per alcuni progetti a monte, gli sviluppatori contribuiscono direttamente al progetto a monte. Per i dettagli, vedere Progetti a monte . In entrambi i casi, gli snapshot vengono periodicamente inseriti nelle versioni.
- In ogni momento, una codeline di rilascio (che può consistere in più di un ramo in git) è considerata l'unico codice sorgente canonico per una determinata versione della piattaforma Android. Gli OEM e altri gruppi che creano dispositivi dovrebbero eseguire il pull solo da un ramo di rilascio.
- Linee di codice sperimentali sono stabilite per catturare i cambiamenti dalla comunità in modo che possano essere ripetuti con un occhio alla stabilità.
- Le modifiche che si dimostrano stabili vengono infine inserite in un ramo di rilascio. Questo vale solo per correzioni di bug, miglioramenti delle applicazioni e altre modifiche che non influiscono sulle API della piattaforma.
- Le modifiche vengono trasferite nei rami di rilascio dei progetti a monte (inclusi i progetti a monte di Android), se necessario.
- La versione n+1 (la prossima versione principale del framework e delle API della piattaforma) è sviluppata internamente da Google. Per i dettagli, vedere Codeline private .
- Le modifiche vengono ritirate dai rami a monte, di rilascio e sperimentali nel ramo privato di Google, se necessario.
- Quando le API della piattaforma per la prossima versione sono stabilizzate e completamente testate, Google taglia una versione della prossima versione della piattaforma (nello specifico, una nuova
SdkVersion
). Ciò corrisponde alla codeline interna che viene trasformata in un ramo di rilascio pubblico e alla nuova codeline della piattaforma attuale. - Quando viene tagliata una nuova versione della piattaforma, viene creata contemporaneamente una linea di codice sperimentale corrispondente.
Codeline private
La strategia di gestione del codice sorgente di cui sopra include una linea di codice che Google mantiene privata per concentrare l'attenzione sull'attuale versione pubblica di Android.
Gli OEM e altri costruttori di dispositivi desiderano naturalmente spedire dispositivi con l'ultima versione di Android. Allo stesso modo, gli sviluppatori di applicazioni non vogliono gestire più versioni della piattaforma del necessario. Nel frattempo, Google mantiene la responsabilità della direzione strategica di Android come piattaforma e prodotto. Il nostro approccio si concentra su un numero limitato di dispositivi di punta per potenziare le funzionalità assicurando al contempo la protezione della proprietà intellettuale relativa ad Android.
Di conseguenza, Google è spesso in possesso di informazioni riservate di terzi e deve astenersi dal rivelare caratteristiche sensibili fino a quando non si assicura le protezioni appropriate. Inoltre, esistono rischi reali per la piattaforma se esistono troppe versioni della piattaforma contemporaneamente. Per questi motivi, abbiamo strutturato il progetto open source (compresi i contributi di terze parti) per concentrarci sulla versione stabile di Android attualmente pubblica. Lo sviluppo profondo sulla prossima versione della piattaforma avviene in privato fino a quando non sarà pronto per diventare un rilascio ufficiale.
Riconosciamo che molti contributori non sono d'accordo con questo approccio e rispettiamo i loro punti di vista. Tuttavia, questo è l'approccio che riteniamo sia il migliore e quello che abbiamo scelto di implementare per Android.