Zum Hauptinhalt Zur Navigation

Für Chromebooks: Wie Google Android in einen Container zwängt

Das Android auf Chromebooks läuft in einem Container auf dem zugrundeliegenden Linux-Kernel. Auf der Linuxcon 2016 erklärt der Google-Angestellte Dylan Reid, dass das im Prinzip ganz einfach ist. Für ein gutes Nutzererlebnis musste das Team aber einige Anpassungen an Android und Chrome OS umsetzen.
/ Sebastian Grüner
5 Kommentare News folgen (öffnet im neuen Fenster)
Chromebooks wie das C201 von Asus könnten dank der Android-Integration für viele interessanter werden. (Bild: Asus)
Chromebooks wie das C201 von Asus könnten dank der Android-Integration für viele interessanter werden. Bild: Asus

Der Anfang der Arbeiten sei noch sehr einfach gewesen, sagt der Google-Angestellte Dylan Reid auf der Linuxcon Europe 2016 über das Vorhaben, Android-Apps auf Chromebooks zu bringen. Denn die Technik, die dafür genutzt wird, ist seit Jahren im Linux-Kernel vorhanden. So musste nur der Init-Prozess von Android in einem Linux-Namespace untergebracht werden und dem Android-Container Zugriff auf sämtliche Hardware gegeben werden, in dem die Gerätedateien(öffnet im neuen Fenster) als Bind-Mount weitergereicht wurden. Und schon lief das Android auf dem Kernel von Chrome OS in dem Chromebook.

Zwar ist dies Laut Reid eine perfekte Containerumgebung, für Google hatte dies aber einige eklatante Nachteile, die zwingend gelöst werden mussten. Immerhin wird durch die komplette Freigabe der Hardware das Sicherheitssystem von Chrome OS mit einem vollständig verifizierten System grundlegend unterlaufen. Darüber hinaus lief das Android in dieser ersten Phase nicht in der grafischen Umgebung des Chrome-OS-Desktops, sondern in einem eigenen virtuellen Terminal (VT). Das heißt, beim Start einer Android-App aus dem Desktop heraus, ist ein Wechsel auf ein anderes VT forciert worden und die App lief im Vollbild ohne eine Möglichkeit, zurückzuwechseln.

Das ist aber verständlicherweise nichts, was an die Zielgruppennutzer von Chrome OS ausgeliefert werden könnte. Das Team musste also einige Änderungen an beiden Systemen vornehmen, damit diese mehr oder weniger reibungslos miteinander interagieren könnten. Der wohl schwierigste Teil daran war laut Reid die Verbindung der grafischen Oberflächen, die unter anderem durch die Verwendung von Wayland gelöst worden ist, das zur Kommunikation der beiden Systeme genutzt wird und um die eigentlichen Buffer mit den grafischen Inhalten auszutauschen.

Aus zwei mach "eins"

Vergleichbare Arten der Verknüpfung durch das Weiterreichen von verschiedenen Informationen setzt Google in vielen weiteren Bereichen ein, um die Android-Apps auf Chrome OS laufen zu lassen. Das Android-System selbst bekomme davon aber eigentlich nichts mit, betont Reid. Genau das ist wohl der größte Vorteil des Einsatzes der Container-Technologie.

So nutzt das Android-System einen Namespace(öffnet im neuen Fenster) für seine eigenen Mounts, um diese überhaupt anlegen und verändern zu können. Ebenso ist dadurch sehr genau konfigurierbar, ob und welchen Zugriff Android auf das Host-System bekommt. Zudem wird für das Android ein Cgroup(öffnet im neuen Fenster) Namespace eingesetzt, damit das System weiter die Ressourcenverwaltung für Apps übernehmen kann. Die Aufgaben der Userspace-Bestandteile der Interprozesskommunikation (IPC) Binder werden an die Chrome-OS-IPC weitergereicht und dafür entsprechend umgewandelt.

Für eine Netzwerkverbindung wird dem Android-System einfach eine Bridge(öffnet im neuen Fenster) -Schnittstelle zur Verfügung gestellt, deren Konfiguration und Verwaltung der Chrome-OS-Dienst Shill(öffnet im neuen Fenster) übernimmt. Ähnlich wird dies auch für die Energieverwaltung umgesetzt oder für Audioausgaben über den Audio Server ( Cras(öffnet im neuen Fenster) ), wofür letztlich einfache Unix-Domain-Sockets verwendet werden.

Ein Android-System ohne Telefon

Mit all diesen Arbeiten läuft das Android zwar in Chrome OS, ist allerdings für einen praktischen Einsatz viel zu langsam, weshalb das Team vor allem den Boot des Android-Containers beschleunigen musste. Dies sei vor allem dem vergleichsweise hardwarenahem Aufbau von Android geschuldet. So gebe es einige Code-Bestandteile in Android, die auf Ereignisse der Geräte warteten, um Nutzer das zu erwartende Erlebnis liefern zu können.

Da das Android auf Chromebooks jedoch in einem Container laufe, könne auf all das verzichtet werden, so Reid. Deshalb benötige der Container letztlich auch nur einige wenige Sekunden, um das System bereitzustellen, was auch nur einmal beim Login des Nutzers geschieht. Da der Container dann läuft, bemerken die Nutzer dadurch idealerweise gar nicht, dass im Grunde ein zweites Betriebssystem auf ihrem Laptop gestartet ist.

Um die Sicherheit des Chrome-OS-Systems aufrechtzuerhalten, muss aber auch die Sicherheit des Android-Containers bedacht werden. Dafür setze Google etwa weiter auf das in Android vorhandene SELinux, das selbst aber noch nicht in einem Namespace genutzt werden könne, weshalb die SELinux-Konfiguration unter Chrome OS erstellt wird und über Dateipfade an den Android-Container weitergereicht wird.

Außerdem verwendet Google für den Android-Container eine eigene Liste der verfügbaren Systemaufrufe und leitet diese aus dem Container an das Host-System weiter. Die Aufrufe können somit gefiltert und falls nötig auch "eingesperrt" werden, indem deren Berechtigungen (Capabilities) modifiziert werden.

Derzeit wird die Möglichkeit, Android-Apps auf Chromebooks zu verwenden, nur auf drei Geräten unterstützt. Google plant allerdings, das Projekt auf viele weitere Geräte(öffnet im neuen Fenster) auszuweiten.


Relevante Themen