Integrationsleitfaden für die Auto-UI-Bibliothek

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Das Car User Interface (UI)-Toolkit bietet ein UI-Entwicklungs-Framework, mit dem Sie sicherstellen können, dass in Autos vorhandene Apps (Google-Apps und System- und Anbieter-Apps) Folgendes erreichen können:

  • Selbstkonsistenz von Infotainment UI/UX. Selbstkonsistenz ist die Fähigkeit eines Benutzers, vorherzusagen, wie er mit einem Infotainmentsystem interagieren soll, basierend auf früheren Erfahrungen bei der Interaktion mit demselben System.

  • Anpassung. OEMs können das Look-and-Feel des Systems modifizieren, um die Funktionalität optimal in den Fahrzeuginnenraum und die Hardware zu integrieren.

Weitere Informationen zur Integration der Car UI Library finden Sie in diesen Artikeln:

Über die Auto-UI-Bibliothek

Die Car UI-Bibliothek ist eine statisch verknüpfte Bibliothek, die eine Reihe von Komponenten und Ressourcen bereitstellt, mit denen Sie Folgendes implementieren 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 Drawables.
    • Behandeln der Ressourcen als API mit abwärtskompatiblen Garantien.
  • Kompatibilitätsschicht zwischen der kurzfristig in Android 9 und Android 10 bereitgestellten und der längerfristigen Lösung, die derzeit entwickelt wird.

Ressourcenüberlagerungen

Android bietet derzeit mehrere Möglichkeiten, Anpassungen ohne zusätzliche Arbeit auf die betroffenen Subsysteme und Apps anzuwenden:

  • Bauzeit-Overlays. Diese Anpassung wird zur Erstellungszeit des Android-Systemabbilds angewendet. Während des Builds erhalten alle Apps im System Ressourcen aus ihrem res -Ordner und aus overlay -Ordnern, die in den Ziel-Makefiles definiert sind.

  • Dynamische Laufzeit-Overlays (dynamisches RRO). Diese speziellen APKs enthalten nur Ressourcen und eine Manifestdatei, um anzugeben, auf welches Ziel-APK sie sich auswirken. Dynamische RROs werden unabhängig vom Systemabbild kompiliert und bereitgestellt und können ein- und ausgeschaltet werden. Wenn das System eine Ressourcensuche für eine bestimmte Anwendung durchführt, prüft das System auch, ob ein RRO darauf abzielt und ob das RRO eine Ressource mit demselben Namen enthält.

  • Statische Laufzeit-Overlays (statisches RRO). Ähnlich wie dynamische RROs in der Struktur sind diese immer aktiviert, was bedeutet, dass sie nicht deinstalliert oder aktualisiert werden können, ohne ein vollständiges System-Image-Upgrade durchzuführen. Statische RROs dienen als Zwischenstufe von Build-Time- und dynamischen Laufzeit-Overlays.

Zusätzlich zu den UI-Komponenten bietet die Auto-UI-Bibliothek einen Mechanismus zum direkten Überlagern von Ressourcen (die statisch mit jeder App verknüpft sind) mit den OEM-Ressourcen, indem ein Satz statischer RROs verwendet wird . OEMs müssen einen Ordner bereitstellen, der ihre Ressourcen-Overlays und eine Liste der Zielanwendungen enthält. Während eines Builds würde die Car-UI-Bibliotheksinfrastruktur diese Informationen verwenden, um ein statisches RRO für jede Zielanwendung zu generieren.

Komponenten der Auto-UI-Bibliothek

Abbildung 1 . Komponenten der Auto-UI-Bibliothek

Im Bild oben:

  • Grün . Vom OEM bereitgestellte Anpassung, eine Mischung aus Build-Time- und Run-Time-Overlay-Ressourcen.

  • Gelb. Unterstützung durch die Auto-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, Systemanwendungen, Anbieteranwendungen und GAS-Anwendungen, die die Auto-UI-Bibliothek verwenden, um UI-Elemente anzupassen .