Apps anpassen

Nachdem die Komponenten und Ressourcen der Auto-UI-Bibliothek in die Apps eingebunden wurden, müssen OEMs zwei Overlays bereitstellen, um diese Apps anzupassen:

  • Mit dem Build-Time-Overlay werden alle Ressourcen hinzugefügt, die für das Laufzeit-Ressourcen-Overlay (RRO) erforderlich sind. Sie beinhalten die folgenden Funktionen:

    • Drawables
    • Stile (z. B. Textdarstellung)
    • Freigegebene Ressourcen (z. B. Farben)

  • Der Ordner RRO-Overlay enthält die Ressourcen, mit denen eine RRO pro Ziel-App generiert wird. Diese Ressourcen können sich nur auf Folgendes beziehen:

    • Werte, die innerhalb derselben RRO definiert sind (z. B. ein Hexadezimalwert für eine Farbe).
    • Android-Framework-Ressourcen (z. B. @android:color/accent)
    • Eine Ressource, die im obigen Buildzeit-Overlay definiert ist.

Allgemeine Struktur

Die vorgeschlagene Struktur für das Anpassungs-Overlay sieht so aus:

  • <path-to-OEM-overlays>/

    • overlay/framework/base/core/res/. Overlay-Ressourcen zur Buildzeit

    • rro/

      • Android.mk. Makefile, mit dem die RROs für jedes Zielpaket anhand der in diesem Ordner enthaltenen Ressourcen generiert werden.

      • AndroidManifest.xml. Eine Manifestdateivorlage, die vom obigen Makefile verwendet wird.

      • res/. Laufzeit-Overlays, die auf alle Ziel-Apps angewendet werden sollen.

OEMs können mehrere dieser Strukturen haben, je nachdem, wie viele Marken sie in einem einzigen Build-Ziel verwalten möchten (siehe Mehrere Marken verwalten).

Overlays für Laufzeitressourcen

Der Ordner „RRO“ im Ordner „OEM-Overlay“ sollte Ressourcen enthalten, die auf alle Ziel-Apps angewendet werden sollen. RROs haben Einschränkungen, die sich auf ihre Fähigkeit auswirken, zusammengesetzte Ressourcen zu überlagern. Zusammenfassend lässt sich sagen, dass eine RRO:

  • Keine Verweis auf Ressourcen-IDs, die im Ziel-APK oder in der RRO selbst definiert sind. Das bedeutet, dass RROs keine neuen IDs wie neue drawables, Farben oder Stile hinzufügen können.

  • Können auf im Framework definierte Ressourcen-IDs verweisen, unabhängig davon, ob diese Ressourcen in /frameworks/base/core/res oder mithilfe eines Overlays zur Buildzeit definiert sind. Diese IDs müssen mit dem Namespace android: referenziert werden:

    • Verwenden Sie für öffentliche DeviceDefault-RROs android.
      Beispiel: @android:style/TextAppearance.DeviceDefault.Large.

    • Für alle anderen (nicht öffentlichen oder über das Overlay zur Buildzeit hinzugefügten Ressourcen) verwenden Sie *android.
      Beispiel: @*android/style:TextAppearance.OEM.Brand1.Title.

Neben den Ressourcen muss der RRO-Ordner Folgendes enthalten:

  • AndroidManifest.xml. Im Beispiel unten sind RRO_PACKAGE_NAME und TARGET_PACKAGE_NAME Platzhalter für die Makefiles:

    <?xml version=“1.0” encoding=“utf-8”?>
<manifest xmlns:android=“http://schemas.android.com/apk/res/android”
    package=“{{RRO_PACKAGE_NAME}}” />
    <application android:hasCode=“false” />
    <overlay android:priority=“10”
        android:targetPackage=“{{TARGET_PACKAGE_NAME}}”
        android:requiredSystemPropertyName=“ro.product.sku”
        android:requiredSystemPropertyValue=“<your-product-sku>” />
</manifest>
  • Android.mk, wobei oem im folgenden Makefile das Präfix definiert, das alle generierten RROs haben. 
      LOCAL_PATH := $(call my-dir)
  include $(CLEAR_VARS)
  CAR_UI_RRO_SET_NAME := oem
  CAR_UI_RESOURCE_DIR := $(LOCAL_PATH)/res
  CAR_UI_RRO_TARGETS := $(CAR_UI_RRO_PACKAGE_NAMES)
  include packages/apps/Car/libs/car-ui-lib/generate_rros.mk

RROs konfigurieren

Es wird eine neue Konfigurationsdatei namens overlayable.xml unterstützt, mit der Sie Zugriffssteuerungen definieren können. Sie können beispielsweise festlegen, wer Ressourcen überlagern darf und welche Ressourcen überlagert werden dürfen. Ressourcen können jetzt auf unterschiedliche Weise gruppiert werden, damit sie von verschiedenen RROs überlagert werden können.

So richten Sie die Zugriffssteuerung für RRO ein:

  1. Erstellen Sie im Ordner res/values die Datei overlayable.xml.
  2. Erstellen Sie die <overlayable>-Ressourcen-Tags.
  3. Definieren Sie das name-Attribut für das <overlayable>-Tag. Es muss im Paket eindeutig sein. Jedes Overlay kann nur auf eine Gruppe ausgerichtet werden, die überlagert werden kann.
  4. Definiere das <policy>-Tag innerhalb von <overlayable>.
  5. Definieren Sie die Gruppen von Ressourcen, die überlagert werden können. Beispiel: 
      <resources>
      <overlayable name="OverlayableResources">
          <policy type="public">
              <item type="string" name="app_title" />
          </policy>
      </overlayable>
  </resources>

So wenden Sie die folgenden Änderungen auf Ihr RRO-Projekt an:

  1. Erstellen Sie im Ordner res/xml die Datei overlays.xml. Siehe den Eintrag für overlay im Codebeispiel unten.
  2. Definieren Sie die Ressourcen, die überschrieben werden sollen.
  3. Fügen Sie dem <overlay>-Tag in AndroidManifest.xml android:resourcesMap="@xml/overlays" hinzu. Im folgenden Codebeispiel sehen Sie beispielsweise den Eintrag für <overlay> .
  4. Legen Sie android:isStatic=”true” für ein statisches Overlay fest. Jedes Overlay kann nur auf eine der Gruppen ausgerichtet werden, die überlagert werden können.

Betrachten Sie dazu das folgende Beispiel: Der erste Abschnitt gehört zu AndroidManifest.xml, der zweite zu overlays.xml. 

  <manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.android.car.ui.rro"
      android:versionCode="1"
      android:versionName="1.0">
      <overlay android:targetName="OverlayableResources"
               android:resourcesMap="@xml/overlays"
               android:targetPackage="com.android.car.ui"
               android:priority="1"
               android:isStatic="false" />
  </manifest>
  <overlay>
      <item target="string/app_title" value="@ string/app_title" />
  </overlay>

Bisher vorhandene RROs funktionieren unter Android 10 mit einer Einschränkung. Pakete, die mit PackageManagerRRO installiert werden sollen, müssen entweder vorinstalliert oder mit demselben Schlüssel wie die Ziel-App signiert sein. Unter Android 10 können Layoutdateien überlagert werden. Dazu muss jedoch requireViewById() anstelle von findViewById() verwendet werden. In Android 10 wurde diese Änderung in der car-ui-lib implementiert, um Layout-Overlays zu unterstützen.

Mit der nächsten Hauptversion von Android können Sie eine Layoutdatei überlagern, neue Ressourcen im RRO-Paket definieren und intern darauf verweisen.

OEM-spezifische Ressourcen hinzufügen

So können Sie die Einschränkungen von RROs umgehen, die das Hinzufügen von OEM-Ressourcen verhindern:

  • Erweitern Sie Frameworks/Base mit einem Build-Time-Overlay und fügen Sie alle erforderlichen Ressourcen hinzu.
  • Verweise auf diese Ressourcen aus den OEM-RROs mit *android:-Namensraum.

So können Sie beispielsweise ein OEM-spezifisches drawable hinzufügen und in einer RRO verwenden:

  • <path-to-OEM-overlays>

    • overlay/framework/base/core/res/res/drawable/

      • oem_background_drawable.xml

    • rro/res/values

      • drawables.xml

        <resources>
    <item type="drawable" name="car_ui_toolbar_background">
        @*android:drawable/oem_background_drawable
    </item>
</resources>

Mehrere Marken verwalten

RRO-Manifestdateien haben eine Syntax, die es ermöglicht, sie basierend auf Systemeigenschaften bedingt anzuwenden. Wenn OEMs mehrere Marken in einem einzigen System-Image verarbeiten möchten, können sie dies so tun (siehe Allgemeine Struktur). 

<?xml version=“1.0” encoding=“utf-8”?>
<manifest xmlns:android=“http://schemas.android.com/apk/res/android”
    package=“{{RRO_PACKAGE_NAME}}”/>
    <application android:hasCode=“false”/>
    <overlay android:priority=“10”
        android:targetPackage=“{{TARGET_PACKAGE_NAME}}”
        android:requiredSystemPropertyName=“ro.product.sku”
        android:requiredSystemPropertyValue=“<your-product-sku>”/>
</manifest>

Aufgrund der Syntax für android:requiredSystemPropertyName und android:requiredSystemPropertyValue wird diese RRO nur aktiviert, wenn die entsprechende Systemeigenschaft mit dem angegebenen Wert übereinstimmt. OEMs können dann mehrere dieser RROs definieren, die alle statisch aktiviert sind und jeweils nur eine davon aktiv ist.

Auto-UI-Mediathek einem Ziel hinzufügen

Wenn Sie die Car UI-Bibliothek in ein Android-Ziel einbinden möchten, müssen Sie das folgende Code-Snippet einfügen: 

# Include build-time overlays
    PRODUCT_PACKAGE_OVERLAYS += \
      <path-to-oem-overlays>/overlay
    # Define package names to generate RROs for
    CAR_UI_RRO_PACKAGE_NAMES += \
      com.android.car.ui.paintbooth \
      com.android.car.media \
      com.android.car.dialer \
      com.android.car.linkviewer \
      com.android.car.settings \
      com.android.car.systemupdater \
      com.google.android.apps.automotive.inputmethod \
      com.google.android.apps.automotive.templates.host \
      ...
    # Include generated RROs
    PRODUCT_PACKAGES += \
      oem-com-android-car-ui-paintbooth \
      oem-com-android-car-media \
      oem-com-android-car-dialer \
      oem-com-android-car-linkviewer \
      oem-com-android-car-settings \
      oem-com-android-car-systemupdater \
      oem-com-google-android-apps-automotive-inputmethod \
      oem-com-google-android-apps-automotive-templates-host \
      ...

  • Dadurch wird in <path-to-OEM-overlays>/rro/Android.mk für jedes der in CAR_UI_RRO_PACKAGE_NAMES genannten Pakete eine RRO generiert.

  • Enthält die generierten RROs in PRODUCT_PACKAGES.

  • Enthält ein PRODUCT_PACKAGE_OVERLAYS-Overlay zur Buildzeit, um OEM-spezifische Ressourcen hinzuzufügen.

Informationen dazu, welche Pakete car-ui-lib unterstützen, finden Sie in der Liste der Pakete mit car-ui-lib.