Vor ein paar Tagen Die Nachricht über eine neue Änderung wurde veröffentlicht dass Google implementiert hat in der Android-Entwicklungund jetzt das neue Modell Android-Entwicklung durch den Verzicht auf die Veröffentlichung von Zwischenberichten im öffentlichen Bereich und Beschränkung der offenen Überprüfung von Änderungen an seinen Komponenten. Obwohl Android eine Open-Source-Plattform bleibt, die unter Apache 2.0 lizenziert ist, wird der Code erst dann im AOSP-Repository (Android Open Source Project) veröffentlicht, wenn jede neue Version vollständig fertig ist.
Bisher Die Android-Entwicklung folgte einem gemischten Modell, wobei einige Teile, wie etwa der Bluetooth-Stack, öffentlich entwickelt wurden, während andere bis zur Veröffentlichung in internen Google-Repositories aufbewahrt wurden. Darüber hinaus hatten Hersteller von Geräten mit GMS-Lizenz (Google Mobile Services) vor der offiziellen Veröffentlichung des Quellcodes Zugriff auf den internen Zweig.
Jedoch Google hat beschlossen, diese Strategie aufzugeben und die gesamte Entwicklung in einen eigenen internen Zweig zu verlagern., wodurch die Trennung zwischen öffentlichem und privatem Code aufgehoben wird. Zukünftig werden alle Beiträge und Verbesserungen Closed Source sein und der Code wird erst freigegeben, wenn die endgültige Version zur Verteilung bereit ist.
Es wird das erwähnt Diese Änderung hat keine Auswirkungen auf die Verfügbarkeit des Codes für Entwickler. Firmware-basiert in AOSP, da diese normalerweise auf bereits getaggten Versionen und nicht auf dem Hauptentwicklungszweig funktionieren. Allerdings wird es für diejenigen, die Änderungen in Echtzeit überwachen möchten, eine Herausforderung darstellen, da sie nicht mehr in der Lage sein werden, die Entwicklung einzelner Komponenten zu verfolgen, sondern die Änderungen analysieren müssen, sobald die Vollversion veröffentlicht ist.
Warum werden einige Teile von Android privat entwickelt?
Normalerweise dauert es mehr als ein Jahr, bis ein Gerät auf den Markt kommt. Und natürlich möchten Gerätehersteller die aktuellste Software bereitstellen. Gleichzeitig möchten Entwickler beim Schreiben des App-Codes nicht ständig neue Plattformversionen verfolgen. In beiden Gruppen kommt es zu Spannungen zwischen dem Wunsch, Produkte zu versenden und gleichzeitig nicht zurückgelassen zu werden.Um dieses Problem zu beheben, werden Teile der nächsten Android-Version, einschließlich der APIs der Kernplattform, in einem privaten Zweig entwickelt. Diese APIs bilden die nächste Version von Android. Unser Ziel ist es, uns auf die aktuelle stabile Version des Android-Quellcodes zu konzentrieren, während wir die nächste Version der Plattform erstellen.
Einige Die Entwickler weisen darauf hin, dass dieses neue Modell auch die Beitragszahlungen erschweren wird. außerhalb des Projekts, da die AOSP-Codebasis im Vergleich zum internen Zweig immer veraltet sein wird, was die Fähigkeit der Community einschränkt, aktiv an der Weiterentwicklung von Android teilzunehmen.
Zu den Elementen, die nicht mehr offen entwickelt und vollständig in den internen Zweig verschoben werden, gehören:
- Das Android-Build-System
- Die Update-Engine
- Der Bluetooth-Stack
- Das Virtualisierungsframework
- SELinux-Konfiguration
Gründe für Googles Entscheidung
Der Hauptgrund für diese Änderung ist laut Googles Vereinfachung des Entwicklungsprozesses. Die Aufrechterhaltung zweier paralleler Zweige führte zu einer Anhäufung von Unterschiedens zwischen ihnen, was zusätzlichen Aufwand erforderte, um Änderungen zu synchronisieren und Patches zwischen der öffentlichen und der internen Version zusammenzuführen. Diese Lücke wird deutlich, wenn man einen sauberen Build von AOSP mit den neuesten Betaversionen von Android 16 vergleicht, die auf dem internen Zweig von Google basieren.
Der Übergang zu einem Trunk-basierten Entwicklungsmodell hat zwar dazu beigetragen, diese Diskrepanz zu verringern, sie bleibt jedoch weiterhin bestehen und stellt für Google weiterhin eine Herausforderung dar.
Da die meiste API-Entwicklung bereits im internen Zweig erfolgte, war der öffentliche Zweig zudem häufig veraltet, was beim Verschieben von Änderungen zwischen den beiden zu Konflikten führte. Mit dem neuen Modell möchte Google die Codeverwaltung optimieren und die Integrationskomplexität reduzieren, auch wenn dies weniger Transparenz für die Community bedeutet.