Ein Angebot von

Android anpassen – die Untiefen der Android-Anpassungsarchitektur

| Autor / Redakteur: Martin Becker * / Sebastian Gerstl

Die Konfigurations- und Anpassungsarchitektur im Android-Betriebssystem 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 Überblick zu verschaffen.
Die Konfigurations- und Anpassungsarchitektur im Android-Betriebssystem 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 Überblick zu verschaffen. (Bild: gemeinfrei / CC0)

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. Welche Arten von Anpassungen erlaubt Android, wie sind diese in der Android-Architektur umgesetzt?

Der Bedarf an Softwarelösungen, die passgenau auf den Kundenbedarf zugeschnitten sind, steigt ungebremst. Im Entwicklungsalltag stellt sich hier oftmals die Frage, wie man die notwendigen Anpassungen geschickt unterstützen kann. In früheren Beiträgen haben wir hierzu typische Mechanismen und Architekturen betrachtet. In diesem Beitrag beleuchten wir, wie die notwendigen Anpassungen im Open-Source-Betriebssystem Android unterstützt werden.

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. Die Codebasis von Android ist sehr groß und umfasst einen erheblichen Anteil von anderen Open-Source-Projekten. Der breite Einsatz von Android lässt vermuten, dass es hochgradig an die spezifischen Einsatzkontexte angepasst werden kann. Neben einer Vielzahl von Hardwareplattformen werden auch weitreichende Anpassungen des Funktionsumfangs unterstützt. 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 Überblick zu verschaffen. Um hier Abhilfe zu leisten, haben wir das Android-Buildsystem tiefergehend analysiert. Dieser Beitrag stellt die Analyseergebnisse von Nicolas Fußberger: "Analyzing the Variability Realization in Android" (TU Kaiserslautern) und Nicolas Fußberger, Bo Zhang, and Martin Becker: "A Deep Dive into Android's Variability Realizations", in Proceedings of the 21st International Systems and Software Product Line Conference (SPLC '17) kurz vor. Er beleuchtet dabei, welche Arten von Anpassungen in Android unterstützt werden und wie diese in der Android-Anpassungsarchitektur umgesetzt sind.

Android Code-Repository

Unserer Analyse liegt das Code-Repository von Android 6 zugrunde. Obwohl Android eine Vielzahl von anderen Open-Source-Projekten verwendet, haben wir das komplette Code-Repository analysiert. Der Repository-Inhalt ist wie in Bild 1 dargestellt sehr groß 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ßteil von Android in C/C++ programmiert ist. Der Buildprozess wird über 4475 Makefiles gesteuert – eine durchaus stattliche Anzahl, die sich nicht einfach überblicken lässt.

Der Code ist grob über drei Ebenen verteilt (siehe Bild 2). Die Android Configuration-Ebene umfasst Produkt- und Boardkonfigurationen. Letztere befinden sich hauptsächlich im Ordner Device. Einige generische Produktkonfigurationen finden sich in /build/target/product. Die entsprechenden Configuration-Items werden in Makefiles definiert, welche sich typischerweise in device/<vendor_name>/<device_name> befinden. 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ür ein Gerät benötigt werden. Boardkonfigurationen werden immer in einem Makefile namens BoardConfig.mk festgelegt, in denen eine Vielzahl von Parametern rund um Peripheriegeräte auf dem Board gesetzt werden. Diese Parameter werden in den Codemodulen verwendet.

Das Android Buildsystem besteht aus zwei Teilen:

  • globalen Builddateien, die den übergeordneten Buildprozess festlegen und
  • lokalen Builddateien, die einzelne Module bauen.

Wie in Bild 2 dargestellt, befinden sich die globalen Builddateien im build Ordner. Das Makefile main.mk stellt den Einstiegspunkt in den Buildprozess dar. Das Makefile product.mk definiert Hilfsfunktionen, z.B. um Produktabhängigkeiten aufzulösen. In jedem Codemodul existiert ein Makefile namens Android.mk, welches das Modul baut. Makefiles des Buildsystems können Konfigurationsvariablen, die in den Konfigurationsdateien definiert wurden, verwenden.

Android Quellcode ist in Module strukturiert, die sich in getrennten Ordnern befinden. Die Ordner sind dabei hierarchisch geschachtelt. Einige davon gehören zur Android Basisinfrastruktur (z.B. der Linux Kern), andere gehören zur Applikationsunterstützung (z.B. Phone). Einige Module sind Hersteller-spezifisch und befinden sich deshalb im device Ordner.

Anpassungen auf der Konfigurationsebene

Konfigurationen werden über Makefile-Variablen definiert, die Software- und Hardware-Einstellungen vornehmen. Die entsprechenden Makefiles befinden sich im device Ordner. Insgesamt haben wir mit einem selbstgebauten Parser 206 Konfigurationsvariablen gefunden. Die meisten Variablen folgen der Namenskonvention PRODUCT_* oder BOARD_*. Unsere Analyse zeigte, dass ein Großteil 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äufig referenziert, während die Mehrzahl der Variablen nur an wenigen Stellen verwendet wird. Hier hinterlässt das Buildsystem einen recht aufgeräumten Eindruck. Eine Übersicht hierzu findet sich in Tab. 1. Dabei werden Referenzen im globalen build Ordner, in Hersteller-spezifischen Modulen im device Ordner sowie sonstigen Modulen unterschieden. Zu den am meistverwendeten Konfigurationsvariablen zählen TARGET_ARCH und TARGET_BOARD_PLATFORM, was letztlich zu erwarten war.

Bild 3 zeigt eine typische Verwendung der Konfigurationsvariablen in den Makefiles. Hier werden Abhängigkeiten rund um dex-preoptimization (Optimierung von Libraries und Apps, um einen schnelleren Start von Android zu ermöglichen) umgesetzt. In Abhängigkeit vom Wert von übergeordneten Variablen wird der Wert von anderen Variablen gesetzt.

Zwischen den Produktkonfigurationen wird eine Art von Vererbung unterstützt. Dabei kann ein Makefile von mehreren Parent-Makefiles Einstellungen erben. Dies wird durch die Hilfsfunktion inherit-product in product.mk ermöglicht. Hierdurch lassen sich gemeinsame Einstellungen einfacher wiederverwenden. Dabei sind Einstellungen in den übergeordneten Makefiles als Default-Werte zu sehen, die in spezifischeren Produktkonfigurationen überschrieben werden können. Der Vererbungsgraph zwischen den Produktkonfigurationsdateien ist in Bild 5 dargestellt. Er lässt sich mit make product-graph erstellen. Wie man sieht, kommt dabei auch an mehreren Stellen eine Mehrfachvererbung zum Einsatz. Hier muss darauf geachtet werden, dass die Belegungen richtig überlagert werden.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45661669 / Open Source)