Das Car User Interface (UI)-Toolkit bietet ein UI-Entwicklungsframework, mit dem Sie sicherstellen können, dass in Autos vorhandene Apps (Google-Apps sowie System- und Anbieter-Apps) Folgendes erreichen können:
Selbstkonsistenz von Infotainment UI/UX. Unter Selbstkonsistenz versteht man die Fähigkeit eines Benutzers, basierend auf früheren Erfahrungen bei der Interaktion mit demselben System vorherzusagen, wie er mit einem Infotainmentsystem interagieren soll.
Anpassung. OEMs können das Erscheinungsbild des Systems ändern, um die Funktionalität optimal in den Fahrzeuginnenraum und die Hardware zu integrieren.
Weitere Informationen zur Integration der Car UI Library finden Sie auf diesen Seiten:
- Integrieren Sie die Car UI-Bibliothek in Apps
- Passen Sie Apps an
- Fügen Sie benutzerdefinierte Schriftarten hinzu
- Passen Sie die Einstellungen der Auto-Benutzeroberfläche an
- CarUiListItem
- Passen Sie CarUiRecyclerView an
- Fehlerbehebung bei Laufzeitressourcen-Overlays
- Versionshinweise
- Anhang A, Arbeit mit RROs
- Anhang B, Anpassungsrichtlinien
Über die Car UI-Bibliothek
Die Car UI-Bibliothek ist eine statisch verknüpfte Bibliothek, die eine Reihe von Komponenten und Ressourcen bereitstellt, die Sie zur Implementierung verwenden können:
- System- und OEM-Apps (Gerrit)
- Android Automotive (AAOS)-Apps
Diese Bibliothek dient als:
Anpassungs-API von:
- Definieren, welche Ressourcen angepasst werden können, einschließlich Farben, Abmessungen und Zeichenelementen.
- Behandeln der Ressourcen als API mit abwärtskompatiblen Garantien.
- Kompatibilitätsschicht zwischen der in Android 9 und Android 10 bereitgestellten kurzfristigen Lösung und der derzeit entwickelten längerfristigen Lösung.
Ressourcen-Overlays
Android bietet derzeit mehrere Möglichkeiten, Anpassungen ohne zusätzlichen Aufwand an den betroffenen Subsystemen und Apps vorzunehmen:
Build-Time-Overlays. Diese Anpassung wird zum Zeitpunkt der Erstellung des Android-System-Images angewendet. Während des Builds erhalten alle Apps im System Ressourcen aus ihrem
res-Ordner und ausoverlayOrdnern, die in den Ziel-Makefiles definiert sind.Dynamische Laufzeit-Overlays (dynamisches RRO). Diese speziellen APKs enthalten nur Ressourcen und eine Manifestdatei, die angibt, welches Ziel-APK sie betreffen. Dynamische RROs werden unabhängig vom System-Image kompiliert und bereitgestellt und können ein- und ausgeschaltet werden. Wenn das System eine Ressourcensuche für eine bestimmte App durchführt, prüft das System auch, ob eine RRO darauf abzielt und ob die RRO eine Ressource mit demselben Namen enthält.
Statische Laufzeit-Overlays (statisches RRO). Diese ähneln in ihrer Struktur dynamischen RROs und sind immer aktiv , was bedeutet, dass sie nicht deinstalliert oder aktualisiert werden können, ohne ein vollständiges System-Image-Upgrade durchzuführen. Statische RROs dienen als Zwischenprodukt zwischen Build-Time- und dynamischen Laufzeit-Overlays.
Zusätzlich zu den UI-Komponenten bietet die Car UI-Bibliothek einen Mechanismus zum direkten Überlagern von Ressourcen (statisch mit jeder App verknüpft) mit den OEM-Ressourcen mithilfe einer Reihe statischer RROs . OEMs müssen einen Ordner mit ihren Ressourcen-Overlays und einer Liste der Ziel-Apps bereitstellen. Während eines Builds würde die Infrastruktur der Car UI-Bibliothek diese Informationen verwenden, um ein statisches RRO für jede Ziel-App zu generieren.
Abbildung 1 . Komponenten der Auto-UI-Bibliothek
Im Bild oben:
Grün . Vom OEM bereitgestellte Anpassung, eine Mischung aus Overlay-Ressourcen zur Build- und 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 des Frameworks, System-Apps, Anbieter-Apps und GAS-Apps, die die Car-UI-Bibliothek zum Anpassen von UI-Elementen verwenden.