Von Zircon bis Topaz: Ein Überblick über die Layer-Architektur von Googles Android-Nachfolger Fuchsia

Veröffentlicht am von Jens
fuchsia 

Mit Fuchsia basteln Googles Entwickler derzeit an einem potenziellen Android-Nachfolger, der aus den Erfahrungen und auch Fehlern des aktuell dominierenden Betriebssystems lernen und alles besser machen soll. Dazu gehört vor allem auch die grundlegende Architektur, die genauso modular aufgebaut sein wird wie der ganze Rest des Betriebssystems. Grundlegend wird Fuchsia aus nicht weniger als vier Layern bestehen, die beliebig austauschbar sind.


Mit Fuchsia führt Google nicht nur viele neue Konzepte, sondern auch genauso viele neue Begriffe ein. Heute kommen wieder mindestens vier neue dazu, so dass ihr euch vielleicht erst noch einmal eine Auffrischung der bereits vorgestellten „Vokabeln“ holen wollt.

fuchsia

In den letzten Wochen haben wir uns viele Details über die grundlegende Struktur von Fuchsia angesehen, das vollständig modular aufgebaut ist. Gepaart mit einer starken Versionsverwaltung sorgt das Betriebssystem stets dafür, dass die neuesten Apps und Oberflächen verwendet werden. Aber auch die Schnittstellen zwischen den Apps, die bei Fuchsia sehr grundlegend für das Konzept und den Aufbau von Modulen und Stories sind, sind selbst modular und werden von Amber verwaltet, so dass stets die passenden Versionen zur Verfügung stehen – selbst wenn die Kompatibilität eigentlich gar nicht mehr möglich wäre.

Diese vollständige Modularität ist aber nicht nur an der Oberfläche zu sehen und von App-Entwicklern zu nutzen, sondern geht bis in die tiefste Schicht des Betriebssystems. Von der Oberfläche bis zum Kernel ist alles modular und kann ausgetauscht werden. Dabei ist nur wichtig, dass die Schnittstellen kompatibel bleiben und die entsprechenden Anforderungen erfüllen. Ist das gegeben, sollen sie vollständig austauschbar und auch weitgehend unabhängig voneinander sein.

Bei Fuchsia wird es unter der Haube gleich vier Layer geben, die zwischen dem Nutzer bzw. den Anwendungen und dem Kernel liegen. Über diesen vier Layern liegt dann die eigentliche Oberfläche, die ebenfalls wieder aus verschiedenen Komponenten bestehen und dadurch für alle Plattformen angepasst werden kann. Die für den Desktop geplante Oberfläche mit dem Codenamen „Capybara“ könnt ihr euch in dieser Mini-Demo etwas genauer ansehen.



fuchsia architektur

Oben seht ihr die einzelnen Layer von Fuchsia, die von unten nach oben gestapelt die Hierarchie vom Kernel bis zur Verbindung mit der Oberfläche zeigen. Alle Layer haben jeweils eigene Codenamen, die sich im Laufe der Zeit aber noch ändern können. Als Endnutzer kommt man mit diesen aber sowieso (vermutlich) niemals in Berührung, deswegen müssen sie nicht unbedingt auswendig gelernt werden 😉

Zircon
Zircon ist ein völlig neuer Kernel, der von Google von Grund auf neu entwickelt wurde und somit erstmals die Zöpfe zu Linux abschneidet. Der Kernel übernimmt die Kommunikation der Software mit der Hardware und steht somit auf der untersten Ebene. In frühen Versionen wurde Zircon auch als „Magenta“ bezeichnet. Zircon selbst hat mit dem reinen Fuchsia nicht viel zu tun und könnte auch für viele weitere Google-Betriebssysteme (vor allem bei Internet of Things-Geräten) zum Einsatz kommen.

Garnet
Garnet ist der unterste Layer des Fuchsia-Betriebssystems und übernimmt viele Basic-Aufgaben. Garnet verwaltet die Hardware-Treiber, regelt die gesamte Kommunikation, hält die zur Verfügung stehenden Anwendungen im Speicher bereit und ähnliche Dinge. Das Update-System Amber ist ein Teil von Garnet und läuft auf dieser Ebene. Hier findet also die gesamte Verwaltung und damit vermutlich auch die Kommunikation mit den Google-Servern zum Streaming von Apps statt.

Peridot
Peridot befindet sich schon auf der ersten App-Ebene. Hier werden die modularen Anwendungen verwaltet und passend für den Nutzer zusammengestellt. Die Synchronisierung der vom Nutzer verwendeten Anwendungen und Daten über Ledger findet auf dieser Ebene statt und auch die Assistant-Schnittstelle Kronk & Bucky ist hier zu Hause. Die Peridot-Ebene sorgt also dafür, dass der Nutzer auf allen Geräten stets die Inhalte vorfindet, die auch auf anderen Plattformen zu finden waren. Damit ist es der erste Layer, der von anderen Unternehmen für eigene Zwecke ausgetauscht werden könnte.

Topaz
Topaz ist die Schnittstelle mit dem Nutzer und übernimmt die gesamte Oberfläche. Die Benuteroberflächen Capybara (Desktop) oder Armadillo (Mobil) werden in dieser Ebene dargestellt und die Oberflächen der Anwendungen entsprechend angepasst. Auch Googles Geheimwaffe Flutter kommt erst auf dieser Ebene zum Einsatz, so dass auch „alte“ Apps aus den anderen Betriebssystemen ausgeführt und wie gewohnt genutzt werden können. Topaz dürfte dann wohl der Teil sein, der von den Herstellern am umfangreichsten angepasst oder ausgetauscht wird (so wie heute etwa die Android-Launcher).



Die Vorteile einer solch modularen Layer-Architektur liegen auf der Hand und mussten von Googles Entwicklern erst auf die harte Tour erlernt werden. Das ewige Update-Problem von Android wird gerade erst mit dem Project Treble angegangen, dass riesige Umbauten am Betriebssystem benötigte und nur EINEN neuen Layer einfügt. Fuchsia schafft nun von Anfang an eine saubere Trennung, so dass jeweils nur ein Teil ausgetauscht werden muss. Dadurch könnte es auch möglich werden, dass Google direkt – unabhängig von den Herstellern – das Betriebssystem ständig aktualisiert.

Die Smartphone/Tablet/Laptop-Hersteller – und wohl auch viele andere Bereiche – können einfach nur den von ihnen benötigten Teil austauschen. Angepasste Oberfläche? Weg mit Capybara/Armadillo, das direkt über Topaz läuft. Umfangreiche Hardware-Anpassungen? Einfach Garnet austauschen und alles läuft stabil wie bisher. Selbst Unternehmen wie Amazon, die vollständig angepasste Geräte auf den Markt bringen, könnten einfach nur die beiden obersten Ebenen austauschen, während die unteren beiden Layer noch immer im Original vorhanden sind.

Eine solche Architektur ist nichts bahnbrechend neues, kommt aber erstmals in einem (möglicherweise) sehr weit verbreitetem Betriebssystem zum Einsatz, das von allen Herstellern verwendet werden kann. Hoffen wir, dass Googles Entwickler das Thema Modularität nicht zu weit treiben, denn am Ende kann aus dem extrem flexiblen Fuchsia schnell auch ein bunt gewürfelter Haufen werden. Aber das wird man sich wohl gut überlegt haben.

[9to5Google]


Teile diesen Artikel:

Facebook twitter Pocket Pocket

comment 7 Kommentare zum Thema "Von Zircon bis Topaz: Ein Überblick über die Layer-Architektur von Googles Android-Nachfolger Fuchsia"

    • „relativ sicher“. Offiziell hat sich Google dazu bisher nicht geäußert, aber es wird allgemein von vielen Menschen davon ausgegangen.
      Warum sonst sollte Fuchsia auf Smartphones zum Einsatz kommen und (auch) Android-Apps über Flutter ausführen?

  • also keine feste Quelle…war klar. Flutter ist ein neues Framework für die Cross-Plattform Entwicklung von Apps in der Programmiersprache Dart. Es ähnelt sehr React Native. Google hat intern sehr viele Projekte. Nur weil Fuchsia hochgepusht wird heißt es nicht das es Android ersetzen wird. Google hat doch erst vor kurzem Google Treble veröffentlicht und Chrome OS näher an Android gebracht. Außerdem sieht man nun Kotlin als offizielle Sprache für Android.

  • Bis jetzt gab es nur mal ein Fuchsia, das auf einem Chromebook lief. In die Richtung(Notebooks/Desktops)
    würde ich Fuchsia auch eher platzieren, denn als Android-Nachfolger.Möglicherweise fließen in Android
    noch Elemente von Fuchsia ein, um die beiden Systeme nahtlos zu verknüpfen.
    Aber als Nachfolger von Android sehe ich Fuchsia derzeit auch nicht.

    • Genau weiß man es nicht, aber die Armadillo-Oberfläche von Fuchsia ist für Smartphones konzipiert.
      Da es bisher nicht 100% sicher ist (aber meiner Meinung nach eben doch sehr wahrscheinlich), spreche ich auch häufig vom „potenziellen Android-Nachfolger“, nur diesmal hat das Wörtchen nicht mehr in die Überschrift gepasst.

Kommentare sind geschlossen.