Betriebssysteme
Taugt Android für Embedded- Anwendungen?
Fortsetzung des Artikels von Teil 2
Architektur
Linux besteht aus einem monolithischen Kernel, der Speicher und Prozesse verwaltet und die Infrastruktur für Dateisysteme, Gerätetreiber, Netzwerkkommunikation usw. bereitstellt (Bild 3).
Über ein System-API findet die Kommunikation zwischen User Space und Kernel Space statt. Systemaufrufe werden üblicherweise über C-Bibliotheken wie die Standard-C-Bibliothek glibc abgewickelt, aber es steht den Entwicklern frei, in ihre Anwendungsprogramme direkt Systemaufrufe einzubauen - auch wenn das nicht empfohlen wird.
Was die Software-Schichten über dem Kernel betrifft, so bestehen keine Einschränkungen hinsichtlich Frameworks, Bibliotheken und Programmiersprachen.
Das Android-Konzept lautet: Man nehme einen Linux-Kernel und eine Java Virtual Machine und füge einige Zutaten für mobile Geräte hinzu (Bild 4). Der Linux-Kernel ist allerdings kein Mainline-Kernel, sondern enthält Android-spezifische Patches, was dazu führt, dass für Android geschriebene Treiber u.U. nicht auf einem Mainline-Linux-Kernel laufen und umgekehrt.
Jobangebote+ passend zum Thema
Der größte Unterschied der Kernel liegt im Power Management. Das Power-Management von Android ist auf Mobiltelefone optimiert und kann z.B. eine Endlosschleife stoppen, die die Gefahr birgt, die gesamte Batterie innerhalb kurzer Zeit zu leeren. Für andere Anwendungen wie z.B. Automotive ist das Android-Power-Management ohne Modifikationen nicht brauchbar.
Beim GNU/Linux-Betriebssystem wird hier zwischen Mechanismen und Policy unterschieden. Obwohl es Power-Management im Kernel gibt (Mechanismus), ist es nicht der Kernel, der entscheidet, wann man in den entsprechenden Stromsparmodus geht (Policy), sondern das kommt üblicherweise von der Anwendung aus dem User Space. Allerdings gibt es ein „Android Mainlining Project“ mit dem Ziel, die Android-Patches dem Mainline-Kernel zuzuführen, so dass die Kompatibilität in der Zukunft wiederhergestellt werden könnte. Dennoch wird die Kompatibilität zwischen beiden Systemen eingeschränkt bleiben, denn auch die bereits erwähnte C-Bibliothek Bionic ist weder vollständig zu glibc noch zu System-V und POSIX kompatibel.
Bionic unterstützt nicht die Interprozess-Kommunikation von POSIX (Message Queues, Semaphore und Shared Memory), mit der Begründung, dass diese Mechanismen zu Ressourcen- problemen wie Memory Leaks führen könnten, wenn sie durch fehlerhafte oder böswillige Applikationen genutzt werden. Eine weitere Besonderheit von Android ist das Windowing-System SurfaceFlinger. Es tritt an die Stelle eines nativen Window-Systems wie Qt-Embedded bei Embedded-Linux.
Als virtuelle Java-Maschine wird Dalvik verwendet, eine VM, die ein eigenes Bytecode-Format (dex) ausführt, das kompakter ist als Java-Klassen. Die VM stellt ein API bereit, das von den Apps benutzt wird. Ein sog. Activity Manager verwaltet die Apps.
Um Android auf eigener Hardware zum Laufen zu bringen, gibt es zwei Möglichkeiten: Man portiert ein Linux auf das Board und versucht dann, die Android-Patches anzuwenden. Die andere Möglichkeit ist, einen Non-Main-line-Kernel zu verwenden, auf dem Android sofort läuft.
Friss oder stirb
Für Anwendungen, die von einem schicken Touch-Interface profitieren, wäre Android eigentlich eine interessante Wahl. Das beträfe z.B. Digital-Signage-Systeme, Point-of-Service-Terminals, Kfz-Unterhaltungssysteme, Navigationsgeräte (Bild 5) und manche industriellen oder semi-industriellen Anwendungen wie vielleicht Steuerungen für die Gebäudeautomatisierung. Alle diese Anwendungen hat Google nicht „auf dem Radar“.
Google und seine Partner richten die Weiterentwicklung von Android ausschließlich an den Bedürfnissen des Smartphone- und Tablet-Markts aus. Allerdings ist das genau der Markt, der die Impulse für neue Benutzeroberflächen liefert. Wer in solch einem dynamischen Markt mitspielen will, muss sich dann aber eine gute Strategie zurechtlegen, wie er z.B. mit Updates umgehen will. Denn da der Android-Code von Google gewartet wird, ist nicht vorhersehbar, was aus der Linux-Mainline-Entwicklung in die nächste Android-Version einfließen wird, und die Community hat auch keinen Einfluss darauf. So sind mit jedem Update wieder Anpassungen fällig, falls die bestehende Hardware überhaupt in der Lage ist, die neue Version auszuführen.
Für größere industrielle Projekte mit längerer Entwicklungszeit kann das bedeuten, dass eine neue Android-Version - womöglich sogar mehrmals - während der Entwicklung erscheint, was zusätzlichen Zeit- und Arbeitsaufwand bedeutet. Auch im laufenden Betrieb können ggf. Patches oder Updates nötig sein. Die einfache Strategie, die die Smartphone-Hersteller ihren Kunden aufnötigen, lautet: Kaufe ein neues Gerät. Denn die wenigsten von ihnen produzieren Updates für ältere Geräte. Diese Masche dürfte aber in den wenigsten Fällen für Embedded-Geräte funktionieren.
Die Situation erinnert in gewisser Weise an die frühen Zeiten von Windows CE. Auch dieses Betriebssystem wurde einst für den Konsumgütermarkt entwickelt und die Embedded-Community musste nehmen, was der umsatzstarke Verbrauchermarkt hergab - und so ist es auch heute wieder bei Android. Wer diese Kompromisse nicht eingehen will, für den existiert mit Realtime- und Embedded-Linux ein zuverlässiger und berechenbarer Software-Zweig, der zwar nicht so „hip“ ist, aber über Gateways (Bild 6) auch eine Brücke zu Android- oder iPhone-Apps schlagen kann.
Die Informationen zu diesem Beitrag beruhen auf einem Vortrag von Robert Berger, www.reliableembeddedsystems.com
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
AndEBench-Pro
EEMBC veröffentlich Android-Benchmark
Betriebssysteme
Fünf Meinungen zu Windows 8 in der Industrie
Windows 8
Erfolgskriterium Desktop
Neben Apple und Microsoft
Android – die dritte Kraft
