Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Android Software Management

Das Android Open Source Project (AOSP) verwaltet einen vollständigen Software-Stack, der von OEMs und anderen Geräteimplementierern portiert und auf ihrer eigenen Hardware ausgeführt werden kann. Um die Qualität von Android aufrechtzuerhalten, hat Google Vollzeitingenieure, Produktmanager, Benutzeroberflächendesigner, Qualitätssicherungstester und alle anderen Rollen bereitgestellt, die für die Markteinführung moderner Geräte erforderlich sind.

Dementsprechend pflegen wir eine Reihe von Codelines, um die aktuelle stabile Version von Android klar von instabilen experimentellen Arbeiten zu trennen. Wir rollen die Open-Source-Verwaltung und Wartung der Android-Codelines in den größeren Produktentwicklungszyklus ein.

AOSP-Codeverwaltung

Die folgende Tabelle zeigt die Konzepte für die Verwaltung und Freigabe von AOSP-Code.

Codeline-Diagramm
Abbildung 1. AOSP-Code und Releases
  1. Zu jedem Zeitpunkt gibt es eine aktuelle Version der Android-Plattform. Dies erfolgt normalerweise in Form eines Zweigs im Baum.
  2. Gerätehersteller und Mitwirkende arbeiten mit der aktuellen Version, beheben Fehler, starten neue Geräte, experimentieren mit neuen Funktionen usw.
  3. Parallel dazu arbeitet Google intern an der nächsten Version der Android-Plattform und des Android-Frameworks entsprechend den Anforderungen und Zielen des Produkts. Wir entwickeln die nächste Version von Android, indem wir mit einem Gerätepartner an einem Flaggschiff-Gerät arbeiten, dessen Spezifikationen ausgewählt wurden, um Android in die Richtung zu lenken, in die es unserer Meinung nach gehen sollte.
  4. Wenn die n + 1-Version fertig ist, wird sie im öffentlichen Quellenbaum veröffentlicht und wird zur neuen neuesten Version.

Begriffe und Vorbehalte

  • Eine Version entspricht einer formalen Version der Android-Plattform, z. B. 1.5 oder 8.1. Eine Freigabe der Plattform entspricht die Version im SdkVersion Bereich der AndroidManifest.xml Dateien und innerhalb definierter frameworks/base/api im Quellbaum.
  • Ein Upstream- Projekt ist ein Open Source-Projekt, aus dem der Android-Stack Code abruft. Neben Projekten wie dem Linux-Kernel und WebKit migrieren wir weiterhin einige halbautonome Android-Projekte wie ART, die Android SDK-Tools und Bionic, um als Upstream-Projekte zu arbeiten. Im Allgemeinen werden diese Projekte vollständig im öffentlichen Baum entwickelt. Bei einigen vorgelagerten Projekten tragen Entwickler direkt zum vorgelagerten Projekt bei. Weitere Informationen finden Sie unter Upstream-Projekte . In beiden Fällen werden Snapshots regelmäßig in Releases gezogen.
  • Zu jeder Zeit wird eine Release-Codeline (die aus mehr als einem Zweig in git bestehen kann) als einziger kanonischer Quellcode für eine bestimmte Android-Plattformversion betrachtet. OEMs und andere Gruppen, die Geräte erstellen, sollten nur aus einem Release-Zweig ziehen.
  • Experimentelle Codelines werden erstellt, um Änderungen aus der Community zu erfassen, sodass sie mit Blick auf Stabilität wiederholt werden können.
  • Änderungen, die sich als stabil erweisen, werden schließlich in einen Release-Zweig gezogen. Dies gilt nur für Fehlerkorrekturen, Anwendungsverbesserungen und andere Änderungen, die sich nicht auf die APIs der Plattform auswirken.
  • Änderungen werden nach Bedarf in Release-Zweige von Upstream-Projekten (einschließlich der Android-Upstream-Projekte) übernommen.
  • Die n + 1-Version (die nächste Hauptversion der Framework- und Plattform-APIs) wird von Google intern entwickelt. Weitere Informationen finden Sie unter Private Codelines .
  • Änderungen werden bei Bedarf aus Upstream-, Release- und experimentellen Zweigen in den privaten Zweig von Google übernommen.
  • Wenn die Plattform-APIs für die nächste Version stabilisiert und vollständig getestet sind, schneidet Google eine Version der nächsten Plattformversion (insbesondere eine neue SdkVersion ). Dies entspricht der internen Codeline, die zu einem Zweig für öffentliche Veröffentlichungen gemacht wird, und der neuen aktuellen Plattform-Codeline.
  • Wenn eine neue Plattformversion geschnitten wird, wird gleichzeitig eine entsprechende experimentelle Codeline erstellt.

Private Codelines

Die oben genannte Quellcodeverwaltungsstrategie enthält eine Codeline, die Google privat hält, um die Aufmerksamkeit auf die aktuelle öffentliche Version von Android zu lenken.

OEMs und andere Gerätehersteller möchten natürlich Geräte mit der neuesten Version von Android ausliefern. Ebenso möchten Anwendungsentwickler nicht mit mehr Plattformversionen als nötig umgehen. In der Zwischenzeit behält Google die Verantwortung für die strategische Ausrichtung von Android als Plattform und Produkt. Unser Ansatz konzentriert sich auf eine kleine Anzahl von Flaggschiff-Geräten, um Funktionen zu steuern und gleichzeitig den Schutz des geistigen Eigentums von Android zu gewährleisten.

Infolgedessen verfügt Google häufig über vertrauliche Informationen von Dritten und darf keine sensiblen Funktionen preisgeben, bis der entsprechende Schutz gewährleistet ist. Darüber hinaus bestehen echte Risiken für die Plattform, wenn zu viele Plattformversionen gleichzeitig vorhanden sind. Aus diesen Gründen haben wir das Open Source-Projekt (einschließlich Beiträge von Drittanbietern) so strukturiert, dass es sich auf die derzeit öffentlich stabile Version von Android konzentriert. Die tiefgreifende Entwicklung der nächsten Version der Plattform erfolgt privat, bis sie offiziell veröffentlicht werden kann.

Wir erkennen an, dass viele Mitwirkende diesem Ansatz nicht zustimmen, und respektieren ihre Standpunkte. Dies ist jedoch der Ansatz, den wir für den besten halten und den wir für Android implementiert haben.