Autor: Martin Becker, Fraunhofer Institut f\u00fcr Experimentelles Software Engineering (IESE)<\/p>\n
Das Android–Betriebssystem wird seit Jahren in einer Vielzahl von eingebetteten Systemen eingesetzt. Dabei kann es hochgradig und weitreichend an die spezifischen Einsatzkontexte angepasst werden. Dies gelingt durch ein ausgefeiltes Zusammenspiel von unterschiedlichen Mechanismen auf verschiedenen Systemebenen. Diese Konfigurations- und Anpassungsarchitektur ist ein sehr guter Ideengeber, wie man in der eigenen Systemlandschaft notwendige Anpassungen effizient umsetzen und beherrschen kann. Leider ist es nicht ganz einfach, sich einen entsprechenden \u00dcberblick zu verschaffen. Der Beitrag beleuchtet daher, welche Arten von Anpassungen in Android unterst\u00fctzt werden und wie diese in der Android-Architektur umgesetzt sind.<\/p>\n
Der Bedarf an Softwarel\u00f6sungen, die passgenau auf den Kundenbedarf zugeschnitten sind, steigt ungebremst. Im Entwicklungsalltag stellt sich hier oftmals die Frage, wie man die notwendigen Anpassungen geschickt unterst\u00fctzen kann. In fr\u00fcheren Beitr\u00e4gen haben wir hierzu typische Mechanismen und Architekturen betrachtet. In diesem Beitrag beleuchten wir, wie die notwendigen Anpassungen im Open-Source-Betriebssystem Android unterst\u00fctzt werden.<\/p>\n
Android wird seit einigen Jahren in einer Vielzahl von eingebetteten Systemen sehr erfolgreich eingesetzt. Neben der mobilen Unterhaltungselektronik finden sich auch Anwendungen im Automobilbereich und der Gesundheitsversorgung [1]. Die Codebasis von Android ist sehr gro\u00df und umfasst einen erheblichen Anteil von anderen Open-Source-Projekten. Der breite Einsatz von Android l\u00e4sst vermuten, dass es hochgradig an die spezifischen Einsatzkontexte angepasst werden kann.<\/p>\n
Neben einer Vielzahl von Hardwareplattformen werden auch weitreichende Anpassungen des Funktionsumfangs unterst\u00fctzt. Dies gelingt durch ein ausgefeiltes Zusammenspiel von unterschiedlichen Mechanismen auf verschiedenen Ebenen. Diese Konfigurations- und Anpassungsarchitektur ist ein guter Ideengeber, wie man in der eigenen Systemlandschaft notwendige Anpassungen effizient umsetzen und beherrschen kann. Leider ist es nicht ganz so einfach, sich einen entsprechenden \u00dcberblick zu verschaffen. Um hier Abhilfe zu leisten, haben wir das Android-Buildsystem tiefergehend analysiert. Dieser Beitrag stellt die Analyseergebnisse aus [2][3] kurz vor. Er beleuchtet dabei, welche Arten von Anpassungen in Android unterst\u00fctzt werden und wie diese in der Android-Anpassungsarchitektur umgesetzt sind.<\/p>\n
Unserer Analyse liegt das Code-Repository von Android 6 [4] zugrunde. Obwohl Android eine Vielzahl von anderen Open-Source-Projekten verwendet, haben wir das komplette Code-Repository analysiert. Der Repository-Inhalt ist wie in Abb. 1 (s.\u00a0PDF<\/a>) dargestellt sehr gro\u00df und im Hinblick auf die verwendeten Dateitypen auch recht heterogen. Offenkundig kommen mit Java, C, C++, Python, Go und Javascript eine Reihe von Programmiersprachen zum Einsatz, wobei der Gro\u00dfteil von Android in C\/C++ programmiert ist. Der Buildprozess wird \u00fcber 4475 Makefiles gesteuert \u2013 eine durchaus stattliche Anzahl, die sich nicht einfach \u00fcberblicken l\u00e4sst.<\/p>\n Der Code ist grob \u00fcber drei Ebenen verteilt (s.\u00a0PDF<\/a>, Abb. 2).<\/p>\n Die Android Configuration-Ebene umfasst Produkt- und Boardkonfigurationen. Letztere befinden sich haupts\u00e4chlich im Ordner\u00a0Device<\/span>. Einige generische Produktkonfigurationen finden sich in\u00a0\/build\/target\/product<\/span>. Die entsprechenden Configuration-Items werden in Makefiles definiert, welche sich typischerweise in\u00a0device\/<vendor_name>\/<device_name><\/span>\u00a0befinden. Dadurch lassen sich diese im Buildsystem und im Quellcode verwenden. Produktkonfigurationen umfassten generelle Produktinformationen, wie Produktname und Hersteller, sowie eine Liste von Modulen, die f\u00fcr ein Ger\u00e4t ben\u00f6tigt werden. Boardkonfigurationen werden immer in einem Makefile namens\u00a0BoardConfig.mk<\/span>\u00a0festgelegt, in denen eine Vielzahl von Parametern rund um Peripherieger\u00e4te auf dem Board gesetzt werden. Diese Parameter werden in den Codemodulen verwendet.<\/p>\n Das Android Buildsystem besteht aus zwei Teilen: i) globalen Builddateien, die den \u00fcbergeordneten Buildprozess festlegen und ii) lokalen Builddateien, die einzelne Module bauen. Wie in Abb. 2 dargestellt, befinden sich die globalen Builddateien im\u00a0build<\/span>\u00a0Ordner. Das Makefile\u00a0main.mk<\/span>\u00a0stellt den Einstiegspunkt in den Buildprozess dar. Das Makefile\u00a0product.mk<\/span>\u00a0definiert Hilfsfunktionen, z.B. um Produktabh\u00e4ngigkeiten aufzul\u00f6sen. In jedem Codemodul existiert ein Makefile namens\u00a0Android.mk<\/span>, welches das Modul baut. Makefiles des Buildsystems k\u00f6nnen Konfigurationsvariablen, die in den Konfigurationsdateien definiert wurden, verwenden.<\/p>\n Android Quellcode ist in Module strukturiert, die sich in getrennten Ordnern befinden. Die Ordner sind dabei hierarchisch geschachtelt. Einige davon geh\u00f6ren zur Android Basisinfrastruktur (z.B. der Linux Kern), andere geh\u00f6ren zur Applikationsunterst\u00fctzung (z.B. Phone). Einige Module sind Hersteller-spezifisch und befinden sich deshalb im\u00a0device<\/span>\u00a0Ordner.<\/p>\n Konfigurationen werden \u00fcber Makefile-Variablen definiert, die Software- und Hardware-Einstellungen vornehmen. Die entsprechenden Makefiles befinden sich im\u00a0device<\/span>\u00a0Ordner. Insgesamt haben wir mit einem selbstgebauten Parser 206 Konfigurationsvariablen gefunden. Die meisten Variablen folgen der Namenskonvention\u00a0PRODUCT_*<\/span>\u00a0oder\u00a0BOARD_*<\/span>. Unsere Analyse zeigte, dass ein Gro\u00dfteil der Produktvariablen lediglich zu Beschreibungszwecken verwendet wird. Im Gegensatz dazu, werden die Boardvariablen zur Steuerung des Buildprozesses verwendet. Dabei wird eine recht kleine Anzahl von Variablen h\u00e4ufig referenziert, w\u00e4hrend die Mehrzahl der Variablen nur an wenigen Stellen verwendet wird. Hier hinterl\u00e4sst das Buildsystem einen recht aufger\u00e4umten Eindruck. Eine \u00dcbersicht hierzu findet sich in Tab. 1. Dabei werden Referenzen im globalen\u00a0build<\/span>\u00a0Ordner, in Hersteller-spezifischen Modulen im\u00a0device<\/span>\u00a0Ordner sowie sonstigen Modulen unterschieden. Zu den am meistverwendeten Konfigurationsvariablen z\u00e4hlen\u00a0TARGET_ARCH<\/span>\u00a0und\u00a0TARGET_BOARD_PLATFORM<\/span>, was letztlich zu erwarten war.<\/p>\n <\/p>\nAnpassungen auf der Konfigurationsebene<\/h2>\n