Das Car UI Toolkit bietet ein Framework für die Benutzeroberflächenentwicklung, mit dem Sie dafür sorgen können, dass in Autos installierte Apps (Google-Apps sowie System- und Anbieter-Apps) Folgendes erreichen:
-
Selbstkonsistenz der Infotainment-UI/UX Selbstkonsistenz ist die Fähigkeit eines Nutzers, basierend auf früheren Erfahrungen mit demselben System vorherzusagen, wie er mit einem Infotainmentsystem interagieren kann.
-
Anpassung. OEMs können das Erscheinungsbild des Systems ändern, um die Funktionen bestmöglich in das Fahrzeuginnere und die Hardware einzubinden.
Weitere Informationen zur Integration der Car UI Library finden Sie auf den folgenden Seiten:
- Auto-UI-Mediathek in Apps einbinden
- Apps anpassen
- Benutzerdefinierte Schriftarten hinzufügen
- Einstellungen für die Benutzeroberfläche des Autos anpassen
- CarUiListItem
- CarUiRecyclerView anpassen
- Probleme mit Laufzeit-Ressourcen-Overlays beheben
- Versionshinweise
- Anhang A: Mit RROs arbeiten
- Anhang B, Richtlinien für die Anpassung
Auto-UI-Bibliothek
Die Auto-UI-Bibliothek ist eine statisch verknüpfte Bibliothek, die eine Reihe von Komponenten und Ressourcen bietet, mit denen Sie Folgendes implementieren können:
- System- und OEM-Apps (Gerrit)
- Android Automotive (AAOS)-Apps
Diese Bibliothek dient als:
-
Customization API von:
- Definieren, welche Ressourcen angepasst werden können, z. B. Farben, Abmessungen und Zeichnelemente.
- Die Ressourcen als API mit abwärtskompatiblen Garantien behandeln.
- Kompatibilitätsschicht zwischen der kurzfristigen Lösung in Android 9 und Android 10 und der derzeit in Entwicklung befindlichen Lösung für die langfristige Nutzung.
Ressourcen-Overlays
Android bietet derzeit mehrere Möglichkeiten, Anpassungen vorzunehmen, ohne dass Änderungen an den betroffenen Subsystemen und Apps erforderlich sind:
-
Buildzeit-Overlays Diese Anpassung wird beim Erstellen des Android-System-Images angewendet. Während des Builds erhalten alle Apps im System Ressourcen aus ihrem
res-Ordner und ausoverlay-Ordnern, die in den Ziel-Makefiles definiert sind. -
Dynamische Laufzeit-Overlays (dynamic RRO) Diese speziellen APKs enthalten nur Ressourcen und eine Manifestdatei, die angibt, auf welches Ziel-APK sie sich auswirken. Dynamische RROs werden unabhängig vom System-Image kompiliert und bereitgestellt und können aktiviert und deaktiviert werden. Wenn das System eine Ressourcensuche für eine bestimmte App durchführt, wird auch geprüft, ob ein RRO darauf ausgerichtet ist und ob das RRO eine Ressource mit demselben Namen enthält.
-
Statische Laufzeit-Overlays (static RRO). Ähnlich wie dynamische RROs sind sie immer aktiviert. Das bedeutet, dass sie nicht deinstalliert oder aktualisiert werden können, ohne ein vollständiges System-Image-Upgrade durchzuführen. Statische RROs dienen als Zwischenschicht zwischen Buildzeit- und dynamischen Laufzeit-Overlays.
Neben UI-Komponenten bietet die Car UI-Bibliothek einen Mechanismus, mit dem Ressourcen, die statisch in jede App eingebunden sind, mithilfe von statischen RROs direkt überlagert werden können. OEMs müssen einen Ordner mit ihren Ressourcen-Overlays und einer Liste der entsprechenden Apps bereitstellen. Während eines Builds verwendet die Car UI-Bibliothek diese Informationen, um für jede anvisierte App eine statische RRO zu generieren.
Abbildung 1 Komponenten der Auto-UI-Bibliothek
Im Bild oben:
-
Grün. Vom OEM bereitgestellte Anpassungen, eine Mischung aus Overlay-Ressourcen zur Build- und zur Laufzeit.
-
Gelb Unterstützung durch die Car UI-Bibliothek, einschließlich überlagerbarer Ressourcen, Komponenten (Java-Code) und Build-Unterstützung zum Generieren der erforderlichen RROs.
-
Blau Anpassbare Ziele, einschließlich Framework, System-Apps, Anbieter-Apps und GAS-Apps, die die Auto-UI-Bibliothek zum Anpassen von UI-Elementen verwenden.