Android-Softwareverwaltung

Das Android Open Source Project (AOSP) unterhält 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 beigesteuert, die erforderlich sind, um moderne Geräte auf den Markt zu bringen.

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

AOSP-Codeverwaltung

Das folgende Diagramm zeigt die Konzepte hinter der AOSP-Codeverwaltung und den Releases.

Abbildung 1. AOSP-Code und -Versionen

1. Zu jedem Zeitpunkt gibt es eine aktuelle neueste Version der Android-Plattform. Dies nimmt typischerweise die Form eines Astes im Baum an.
2. Gerätehersteller und Mitwirkende arbeiten mit der aktuellsten 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 wurden, dass sie Android in die Richtung bringen, in die es unserer Meinung nach gehen sollte.
4. Wenn die n+1-te Version fertig ist, wird sie im öffentlichen Quellbaum veröffentlicht und wird zur neuen neuesten Version.

Hinweis: Wir verwenden den Begriff Codezeilen anstelle von Verzweigungen , einfach weil es zu einem bestimmten Zeitpunkt mehr als eine Verzweigung für eine bestimmte Codezeile geben kann. (Codelines enthalten die Sätze sich entwickelnder Dateien.) Wenn zum Beispiel eine Veröffentlichung gekürzt wird, kann sie je nach den aktuellen Anforderungen zu einem neuen Zweig werden oder auch nicht.

Begriffe und Vorbehalte

• Ein Release entspricht einer formalen Version der Android-Plattform, z. B. 1.5 oder 8.1. Ein Release der Plattform entspricht der Version im SdkVersion -Feld der AndroidManifest.xml Dateien und ist in frameworks/base/api in der Quellstruktur definiert.
• Ein Upstream -Projekt ist ein Open-Source-Projekt, aus dem der Android-Stack Code bezieht. 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 gezogen.
• Eine Release-Codeline (die aus mehr als einem Git-Zweig bestehen kann) gilt zu jeder Zeit als einziger kanonischer Quellcode für eine bestimmte Android-Plattformversion. OEMs und andere Gruppen, die Geräte bauen, sollten nur aus einem Release-Zweig ziehen.
• Experimentelle Codelines werden eingerichtet, um Änderungen aus der Community zu erfassen, damit 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 Fehlerbehebungen, Anwendungsverbesserungen und andere Änderungen, die sich nicht auf die APIs der Plattform auswirken.
• Änderungen werden nach Bedarf aus Upstream-Projekten (einschließlich der Android-Upstream-Projekte) in Release-Zweige gezogen.
• Die n+1. Version (die nächste Hauptversion des Frameworks und der Plattform-APIs) wird von Google intern entwickelt. Einzelheiten finden Sie unter Private Codelines .
• Änderungen werden bei Bedarf aus Upstream-, Release- und Experimental-Zweig in den privaten Zweig von Google gezogen.
• 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 öffentlichen Release-Zweig gemacht wird, und der neuen aktuellen Plattform-Codeline.
• Wenn eine neue Plattformversion geschnitten wird, wird gleichzeitig eine entsprechende experimentelle Codeline erstellt.

Private Codelines

Die obige Quellenverwaltungsstrategie enthält eine Codezeile, 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 sich Anwendungsentwickler nicht mit mehr Plattformversionen als nötig befassen. 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 voranzutreiben und gleichzeitig den Schutz von Android-bezogenem geistigem Eigentum sicherzustellen.

Infolgedessen ist Google häufig im Besitz vertraulicher Informationen von Dritten und muss vertrauliche Merkmale nicht preisgeben, 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äge Dritter) so strukturiert, dass es sich auf die derzeit öffentliche stabile Version von Android konzentriert. Die tiefgreifende Entwicklung der nächsten Version der Plattform findet im Geheimen statt, bis sie bereit ist, eine offizielle Veröffentlichung zu werden.

Wir erkennen an, 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 ausgewählt haben.