Android-Softwareverwaltung

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 erforderlich sind, um moderne Geräte auf den Markt zu bringen.

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

AOSP-Codeverwaltung

Die folgende Tabelle zeigt die Konzepte hinter der AOSP-Codeverwaltung und -Releases.

Codeliniendiagramm
Abbildung 1. AOSP-Code und -Releases
  1. Zu jedem Zeitpunkt gibt es eine aktuelle Version der Android-Plattform. Dies geschieht typischerweise in Form eines Astes im Baum.
  2. Geräteentwickler und Mitwirkende arbeiten mit der aktuell neuesten Version, beheben Fehler, bringen neue Geräte auf den Markt, experimentieren mit neuen Funktionen und so weiter.
  3. Parallel dazu arbeitet Google intern an der nächsten Version der Android-Plattform und des 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 so ausgewählt sind, dass sie Android in die Richtung vorantreiben, in die es unserer Meinung nach gehen sollte.
  4. Wenn die n+1. Version fertig ist, wird sie im öffentlichen Quellbaum veröffentlicht und wird zur neuen neuesten Version.

Bedingungen und Vorbehalte

  • Eine Veröffentlichung entspricht einer formalen Version der Android-Plattform, beispielsweise 1.5 oder 8.1. Eine Version der Plattform entspricht der Version im Feld SdkVersion der AndroidManifest.xml Dateien und ist in frameworks/base/api im Quellbaum definiert.
  • Ein Upstream- Projekt ist ein Open-Source-Projekt, aus dem der Android-Stack Code abruft. Zusätzlich zu 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 Upstream-Projekten tragen Entwickler direkt zum Upstream-Projekt bei. Einzelheiten finden Sie unter Upstream-Projekte . In beiden Fällen werden Snapshots regelmäßig in Releases übernommen.
  • Eine Release-Codezeile (die aus mehr als einem Git-Zweig bestehen kann) gilt jederzeit als einziger kanonischer Quellcode für eine bestimmte Android-Plattformversion. OEMs und andere Gruppen, die Geräte erstellen, sollten nur aus einem Release-Zweig abrufen.
  • Es werden experimentelle Codelines erstellt, um Änderungen aus der Community zu erfassen, sodass sie mit Blick auf Stabilität iteriert werden können.
  • Änderungen, die sich als stabil erweisen, werden schließlich in einen Release-Zweig übernommen. Dies gilt nur für Fehlerbehebungen, Anwendungsverbesserungen und andere Änderungen, die sich nicht auf die APIs der Plattform auswirken.
  • Änderungen werden bei 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. Einzelheiten finden Sie unter Private Codelines .
  • Änderungen werden bei Bedarf aus Upstream-, Release- und Experimental-Branches in den privaten Branch von Google übernommen.
  • Wenn die Plattform-APIs für die nächste Version stabilisiert und vollständig getestet sind, veröffentlicht Google die nächste Plattformversion (insbesondere eine neue SdkVersion ). Dies entspricht der Umwandlung der internen Codeline in einen öffentlichen Release-Zweig und der neuen aktuellen Plattform-Codeline.
  • Beim Schnitt einer neuen Plattformversion wird gleichzeitig eine entsprechende experimentelle Codeline erstellt.

Private Codezeilen

Die obige Quellverwaltungsstrategie beinhaltet 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 Android-Version ausliefern. Ebenso möchten Anwendungsentwickler nicht mit mehr Plattformversionen als nötig umgehen. Unterdessen bleibt Google für die strategische Ausrichtung von Android als Plattform und Produkt verantwortlich. Unser Ansatz konzentriert sich auf eine kleine Anzahl von Flaggschiff-Geräten, um Funktionen voranzutreiben und gleichzeitig den Schutz des geistigen Eigentums im Zusammenhang mit Android zu gewährleisten.

Daher ist Google häufig im Besitz vertraulicher Informationen von Dritten und muss die Offenlegung sensibler Merkmale unterlassen, bis die entsprechenden Schutzmaßnahmen sichergestellt sind. 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ägen Dritter) so strukturiert, dass es sich auf die derzeit öffentliche stabile Version von Android konzentriert. Die tiefgreifende Entwicklung der nächsten Version der Plattform erfolgt privat, bis sie zur offiziellen Veröffentlichung bereit ist.

Wir sind uns bewusst, dass viele Mitwirkende mit diesem Ansatz nicht einverstanden sind, und wir respektieren ihre Standpunkte. Dies ist jedoch der Ansatz, den wir für den besten halten und den wir für die Implementierung für Android gewählt haben.