Custom-ROM-Design: Umgebungen über mehrere Systemebenen

Der Beitrag beschreibt ein Custom-ROM, das Anwendungen und App-Instanzen jeweils eine konfigurierbare Umgebung zuweist. Die Umsetzung verteilt sich auf einen Agenten, eine Geräte-Zwischenschicht, AOSP, ART, Systembibliotheken und den Linux-Kernel.

Custom-ROM-Design: Umgebungen über mehrere Systemebenen

Das Wichtigste

  • Geräteeigenschaften, Dateisicht, Ressourcen, Standort und Telefoninformationen werden pro Anwendung und Instanz in getrennten Konfigurationsräumen organisiert.
  • Hooks in AOSP und Methodenersetzungen in ART greifen an unterschiedlichen Stellen ein und müssen gemeinsam initialisiert werden.
  • Die Zuordnung des realen Prozess-UIDs bestimmt den verwendeten Parametersatz, ändert jedoch nicht automatisch die Linux-Berechtigungen des Prozesses.

Einordnung

Der technische Schwerpunkt liegt auf der Frage, an welcher Schicht eine virtualisierte oder simulierte Geräteumgebung in den Android-Aufrufpfad eingefügt wird. Besonders relevant sind dabei Identitätszuordnung, Pfade, Caches, native Schnittstellen und Abbildung zwischen Java-, Native- und direkten Systemaufrufen. Die dargestellten Szenarien stammen aus selbst entwickelten Beispielanwendungen.

Was das für Sie heisst

Direkt anwendbar

Der Ansatz bietet Entwicklern und technischen Entscheidern ein konkretes Modell für den Entwurf geschichteter Android-Umgebungen und für die Auswahl geeigneter Eingriffspunkte.

Wer davon profitiert: Entwickler und technische Entscheider profitieren vor allem bei der Analyse von Systemgrenzen, Laufzeitverhalten und der Einordnung vergleichbarer Legacy-Architekturen.

Artikel teilen: