Wir haben uns jetzt schon sehr viele Bereiche von Fuchsia angesehen und vor allem die neuen Definitionen und Begriffe des Betriebssystems beleuchtet. Heute kommt wieder ein neuer Begriff dazu, hinter dem sich eine der wichtigsten Fuchsia-Funktionen verbirgt: Amber. Amber ist für die Abwicklung und Durchführung von Updates aller Bestandteile des Betriebssystems zuständig und sorgt für eine umfangreiche Versionsverwaltung.
Da Google den Android-Nachfolger als Open Source entwickelt und jedem Einblicke in das Projekt gewährt, sind schon sehr viele Informationen rund um Fuchsia bekannt geworden. Wer sich noch einmal zur Wiederholung einlesen möchte, bekommt im folgenden alle Informationen rund um das neue Betriebssystem:
- Module & Stories: Arbeitsbereiche statt Apps
- Ledger: Umfangreiche Synchronisierung aller Daten
- Entities: Informationen statt Dateien
- Instant Apps: Gestreamte Module statt echte Apps
- Kronk & Bucky: Mögliche Nachfolger für den Google Assistant
- Komponenten, Agents & mehr: Die Struktur von Fuchsia
- Flutter: Geheimwaffe für den Übergang von Android & iOS zu Fuchsia
Wenn es etwas gibt, das bei Android dringend verbessert werden muss, dann sind es die Updates. App-Updates dauern manchmal bis zu einer Woche, bis sie den Weg auf das Smartphone des Nutzers finden. Von Updates des Betriebssystems brauchen wir eigentlich gar nicht erst reden, denn die Situation ist jedem bekannt. Mit Chrome OS hat Google schon gezeigt, wie man es besser machen kann – allerdings gilt das nur das Betriebssystem.
Fuchsia setzt bekanntlich auf gestreamte Apps, so dass ein Update eigentlich gar nicht notwendig wäre – und aus diesem Grund scheint es auch viel mehr eine interne Versionsverwaltung als ein Updater zu sein. Diese Verwaltung ist vor allem deswegen grundlegend wichtig, weil die Fuchsia-Apps bzw. Module stark ineinander greifen und untereinander kompatibel sein müssen. Ändert eine App eine Schnittstelle, kann das gesamte System zusammenbrechen. Genau das soll mit Amber verhindert werden.
Von den Google-Entwicklern wird Amber mit „with the ambition of updating all components running on a Fuchsia system“ beschrieben. Das Betriebssystem selbst ist dabei auch nur eine grundlegende Komponente und wird ebenfalls vom gleichen Update-Prozess verwaltet. Das ganze ist derzeit noch sehr vage und wenig dokumentiert. Ohne eine solche Versionsverwaltung wird ein modular aufgebautes Betriebssystem aber wohl nicht funktionieren können.
Um den Sinn und Zweck hinter Amber nachzuvollziehen, muss man erst noch einmal die grundlegende Struktur hinter Fuchsia verstehen. Dann wird schnell klar, dass die Zusammenarbeit zwischen den einzelnen Apps (Packages) bzw. die von Fuchsia konstruierten Stories nur dann funktionieren können, wenn alles reibungslos wie ein Zahnradgetriebe ineinander greifen kann. Das ist aber nur dann möglich, wenn sich an den Apps niemals etwas ändert – und dieser Stillstand bringt natürlich auch niemanden weiter.
Ein kleines Beispiel: Greift die Telefon-App auf die Kontakt-App zu, dann wird sie immer eine Telefonnummer erwarten. Ändert der Entwickler der Kontakt-App nun aber etwas an seiner App (ein anderes Format, zusätzlich Sicherheitsabfrage oder ähnliches), dann kann die Telefon-App plötzlich keinen Anruf mehr durchführen. Um das zu verhindern, kann die Telefon-App stets auf die gleiche Version der Kontakt-App zugreifen, ganz egal wie viele Änderungen an dieser vorgenommen worden sind.
Fuchsia wird also von allen Modulen unzählige Versionen vorrätig halten, die direkt abgefragt und verwendet werden können. Dann macht natürlich auch die haarkleine Aufteilung von Anwendungen in Komponenten und Modulen wieder Sinn, da sich die Änderungen stets im Rahmen halten. Theoretisch sollte es so also möglich sein, dass der Nutzer eine aktuelle Version verwendet, im Hintergrund aus Kompatibilitätsgründen auf eine ältere Version zugegriffen wird.
Die einzelnen Versionen und Updates werden, so wie die Apps, von verschiedenen Quellen heruntergeladen und gestreamt – und das kann selbst von Geräten unbekannter Personen sein. Um sicherzustellen, dass dabei kein Schadcode oder manipulierte Versionen in die Oberfläche kommen, wird es umfangreiche Prüfungen auf Grundlage des Update Framework geben.
Auch in Zukunft soll es die klassischen Versionsnummern geben, die vom Menschen gelesen und zur Identifizierung verwendet werden können. Fuchsia selbst wird aber für jede kleine Änderung auch interne Versionsnummern anlegen, mit denen das Betriebssystem und die Entwickler dann arbeiten können – das dürfte wohl in etwa mit Build-Nummern vergleichbar sein, wobei Fuchsia aber noch eine Stufe tiefer gehen und noch detaillierter sein könnte.
Obwohl das klassische Betriebssystem- oder Play Store-Update nicht nötig sein wird, benötigt Fuchsia also eine umfangreiche Update- und Versionsverwaltung. Fraglich ist nur, wo genau diese Verwaltung angesiedelt sein wird. Wird es einen zentralen, wohl von Google betriebenen, Fuchsia-Server geben? Das ist noch nicht geklärt und befindet sich derzeit noch in einem so frühen Entwicklungsstadium, dass wir wohl erst in einigen Monaten weitere Details erwarten können.
Um einen ersten Eindruck von Fuchsia gewinnen zu können, könnt ihr euch auch einmal diese kleine Browser-Demo ansehen, die das Betriebssystem simuliert. Möglicherweise hat Google mit Android P den ersten Schritt in Richtung Fuchsia getan – aber auch das wird sich wohl erst in Zukunft zeigen.
- Module & Stories: Arbeitsbereiche statt Apps
- Ledger: Umfangreiche Synchronisierung aller Daten
- Entities: Informationen statt Dateien
- Instant Apps: Gestreamte Module statt echte Apps
- Kronk & Bucky: Mögliche Nachfolger für den Google Assistant
- Komponenten, Agents & mehr: Die Struktur von Fuchsia
- Flutter: Geheimwaffe für den Übergang von Android & iOS zu Fuchsia