Samsung beschleunigt One-UI-Entwicklung mit der Hilfe von Google

Der südkoreanische Branchenprimus Samsung folgt Google bei der Art der Entwicklung neuer OS-Versionen. Mithilfe des sogenannten „Trunk-Stable“-Entwicklungsmodells, mit dem Google das Update auf Android 16 Monate früher als bisher fertigstellen konnte, hat es auch Samsung geschafft, One UI 8 schneller denn je auf erste Geräte zu bringen. Neben der flinkeren Entwicklungszeit soll die neue Art der Entwicklung sich auch positiv auf die Softwarequalität auswirken.

One UI 8 schneller denn je fertig

Nachdem Samsung sich mit dem Release von One UI 7 enorm viel Zeit gelassen hatte, ging es mit One UI 8 so schnell wie nie. Nur wenige Wochen nach Googles Veröffentlichung von Android 16 für seine Pixel-Geräte und im AOSP, liefert Samsung seine neuen Foldables Galaxy Z Fold 7 und Z Flip 7 mit One UI 8 auf Basis von Android 16 aus. Dies ist kein Zufall: Wie Sally Hyesoon Jeong, Executive Vice President und Leiterin der Abteilung Framework R&D bei Samsung Mobile Experience Business, im Zuge eines Medienroundtables erklärte, arbeitet der Hersteller wie Google nur noch mit einem Entwicklungszweig und verfolge damit das Trunk-Stable-Modell.

Google verlange dies zwar nicht von Smartphone-Herstellern wie Samsung, da diese über unabhängige Entwicklungsprozesse verfügen und lediglich den zugrunde liegenden Plattformcode erhalten. Samsung erkannte jedoch die Vorteile der Trunk-Stable-Entwicklung und stellte die eigene One-UI-Entwicklung auf das Modell um. Sie erklärte weiter, dass das Unternehmen mit Google zusammenarbeitet, um das neue Entwicklungsmodell zu entwerfen.

Samsung passt sich an Androids Release-Zyklus an

Laut Jeong ist der Trunk-Stable-Ansatz dafür verantwortlich, dass Samsung One UI 8 so schnell nach der Einführung von Android 16 auf den Markt bringen konnte. Weiter erklärte sie, dass Samsung sich künftig an den Release-Rhythmus von Google anpassen wolle, um „die neuesten Android-Versionen so schnell wie möglich auf die Geräte zu bringen“. Derweil warten Besitzerinnen und Besitzer anderer Galaxy-Modelle noch auf die Verteilung des One-UI-8-Updates. Derzeit bietet der Hersteller immerhin für einige Modelle Betaversionen an – der Rollout des fertigen Updates dürfte bald erfolgen.

Sollte Google am neuen Release-Zyklus festhalten, dürften dann auch Samsungs neue One-UI-Versionen nicht mit der S-Serie, die traditionsgemäß Anfang eines jeden Jahres auf den Markt kommen, erscheinen. Stattdessen könnten die großen One-UI-Versionen im Sommer mit den Foldables kommen.

Was ist Trunk-Stable?

Mit dem sogenannten Trunk-Stable-Entwicklungsmodell gibt es nur noch einen zentralen Code-Zweig, von dem sämtliche Releases abgehen, sowohl stabile Updates als auch Developer-Versionen werden aus diesem erstellt.

Alle neuen Funktionen, APIs und Fehlerbehebungen werden hinter sogenannten „Feature-Flags“ entwickelt. Sie sind Teil des Codes, können aber in öffentlichen Releases deaktiviert werden, bis sie vollständig fertig sind. Dieses Verfahren führt unter anderem dazu, dass die vierteljährlichen Maintenance-Releases und die Entwicklungsversionen immer ähnlicher werden. Auf diese Weise könnten öfter neue Funktionen Einzug halten. Zudem können Bastler mit Tricks noch unfertige oder schlummernde Funktionen aktivieren.

Der neue Ansatz unterscheidet sich deutlich vom bisherigen verzweigten Modell, bei dem für jede neue Version ein separater Codezweig erstellt wurde. Diesem wurden dann bis zur Finalisierung einer Android-Version neue Funktionen hinzugefügt. Anschließend wurde dieser Zweig in den internen Hauptentwicklungszweig von Android integriert.

Der traditionelle Ansatz klingt zwar logisch, jedoch verursachte er bei einem so hochkomplexen Projekt wie Android erhebliche Probleme, erklärt der ehemalige Android-Entwickler Serban Constantinescu in einer Präsentation zu Trunk-Stable. Denn die Zusammenführung zweier umfangreicher Codebasen verlief selten reibungslos und führte häufig zu Fehlern und Inkonsistenzen, deren Behebung schließlich wertvolle Entwicklungszeit in Anspruch nahm.

Das alte Entwicklungsmodell machte offenbar auch bei der Entwicklung neuer Funktionen Probleme. Denn konnte eine Funktion bis zum Veröffentlichungstermin doch nicht fertiggestellt werden, mussten die Entwickler den unfertigen Code wieder in den Hauptzweig einfügen, sowie alle daraus resultierenden Konflikte lösen und dann ihre Arbeit im Zweig der nächsten Version fortsetzen.

(afl)