Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Gestione del software Android

Il progetto Android Open Source (AOSP) mantiene uno stack software completo per il porting da parte di OEM e altri implementatori di dispositivi e per l'esecuzione sul proprio hardware. Per mantenere la qualità di Android, Google ha contribuito a progettare a tempo pieno ingegneri, responsabili di prodotto, progettisti di interfacce utente, tester di garanzia della qualità e tutti gli altri ruoli richiesti per portare sul mercato i dispositivi moderni.

Di conseguenza, manteniamo una serie di linee guida per separare chiaramente l'attuale versione stabile di Android dal lavoro sperimentale instabile. Integriamo l'amministrazione open source e la manutenzione delle codeline Android nel più ampio ciclo di sviluppo del prodotto.

Gestione del codice AOSP

La tabella seguente illustra i concetti alla base della gestione e delle versioni del codice AOSP.

diagramma codeline
Figura 1. Codice AOSP e versioni
  1. In qualsiasi momento, è disponibile una versione più recente della piattaforma Android. Questo in genere assume la forma di un ramo nell'albero.
  2. I costruttori di dispositivi e i collaboratori lavorano con l'ultima versione attuale, correggendo i bug, avviando nuovi dispositivi, sperimentando nuove funzionalità e così via.
  3. 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 lavorando con un partner di dispositivo su un dispositivo di punta le cui specifiche sono state scelte per spingere Android nella direzione in cui crediamo che dovrebbe andare.
  4. Quando la n + 1a versione è pronta, viene pubblicata nella struttura di origine pubblica e diventa la nuova versione più recente.

Termini e avvertenze

  • Una versione corrisponde a una versione formale della piattaforma Android, come 1.5 o 8.1. Una versione della piattaforma corrisponde alla versione nel campo SdkVersion dei file AndroidManifest.xml e definita all'interno di frameworks/base/api nella struttura dei sorgenti.
  • Un progetto a monte è 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 lavorare 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, le istantanee vengono periodicamente inserite 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 costruiscono dispositivi dovrebbero estrarre solo da un ramo di rilascio.
  • Sono state stabilite linee guida sperimentali per acquisire i cambiamenti dalla comunità in modo che possano essere ripetuti con un occhio alla stabilità.
  • I cambiamenti che risultano stabili vengono infine inseriti in un ramo di rilascio. Ciò si applica solo a correzioni di bug, miglioramenti dell'applicazione e altre modifiche che non influiscono sulle API della piattaforma.
  • Le modifiche vengono inserite nelle filiali di rilascio da progetti a monte (inclusi i progetti a monte di Android), se necessario.
  • La n + 1a versione (la prossima versione principale delle API del framework e della piattaforma) è sviluppata da Google internamente. Per i dettagli, consultare Codeline private .
  • Le modifiche vengono estratte da filiali a monte, rilascio e sperimentali nella filiale privata 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 (in particolare, una nuova versione di SdkVersion ). Ciò corrisponde al fatto che la codeline interna sia diventata un ramo di rilascio pubblico e la nuova codeline della piattaforma corrente.
  • Quando viene tagliata una nuova versione della piattaforma, viene creata contemporaneamente una codeline sperimentale corrispondente.

Codeline private

La strategia di gestione delle fonti di cui sopra include una codeline che Google mantiene privata per focalizzare l'attenzione sull'attuale versione pubblica di Android.

Gli OEM e altri costruttori di dispositivi desiderano naturalmente spedire i 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 guidare le funzionalità garantendo allo stesso tempo la protezione della proprietà intellettuale legata ad Android.

Di conseguenza, Google è spesso in possesso di informazioni riservate di terzi e deve astenersi dal rivelare funzionalità sensibili fino a garantire le protezioni appropriate. Inoltre, ci sono 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 attualmente pubblica di Android. Lo sviluppo approfondito della prossima versione della piattaforma avviene in privato fino a quando non è pronto per diventare una versione ufficiale.

Riconosciamo che molti partecipanti non sono d'accordo con questo approccio e rispettiamo i loro punti di vista. Tuttavia, questo è l'approccio che riteniamo migliore e quello che abbiamo scelto di implementare per Android.