Diese Seite wurde von der Cloud Translation API übersetzt.

Passen Sie Apps an

Da nun Komponenten und Ressourcen der Car UI-Bibliothek in die Apps integriert sind, müssen OEMs zur Anpassung dieser Apps zwei Overlays bereitstellen:

Das Build-Time-Overlay fügt alle Ressourcen hinzu, die für das Runtime Resource Overlay (RROs) benötigt werden. Das beinhaltet:
- Zeichenelemente
- Stile (zum Beispiel Textdarstellungen)
- Gemeinsam genutzte Ressourcen (z. B. Farben)
Der RRO-Overlay- Ordner enthält die Ressourcen, die zum Generieren eines RRO pro Ziel-App verwendet werden. Diese Ressourcen können sich nur beziehen auf:
- Werte, die innerhalb desselben RRO definiert sind (für eine Farbe wäre dies beispielsweise ein Hexadezimalwert).
- Android-Framework-Ressourcen (z. B. @android:color/accent ).
- Eine im obigen Build-Time-Overlay definierte Ressource.

Allgemeine Struktur

Die vorgeschlagene Anpassungs-Overlay-Struktur sieht wie folgt aus:

<path-to-OEM-overlays>/
- overlay/framework/base/core/res/ . Overlay-Ressourcen zur Erstellungszeit
- rro/
  - Android.mk . Makefile wird verwendet, um die RROs für jedes Zielpaket basierend auf den in diesem Ordner enthaltenen Ressourcen zu generieren.
  - AndroidManifest.xml . Eine Manifestdateivorlage, die vom obigen Makefile verwendet wird.
  - res/ . Laufzeitüberlagerungen zur Anwendung auf alle Ziel-Apps.

OEMs verfügen möglicherweise über mehr als eine dieser Strukturen, abhängig von der Anzahl der Marken, die sie in einem einzigen Build-Ziel verwalten möchten (siehe Umgang mit mehreren Marken ).

Laufzeitressourcen-Overlays

Der RRO-Ordner im OEM-Overlay-Ordner sollte Ressourcen enthalten, die auf alle Ziel-Apps angewendet werden sollen. RROs haben Einschränkungen hinsichtlich ihrer Fähigkeit, zusammengesetzte Ressourcen zu überlagern. Zusammenfassend ein RRO:

Es kann nicht auf Ressourcen- IDs verwiesen werden, die im Ziel-APK oder im RRO selbst definiert sind. Das bedeutet, dass RROs keine neuen Bezeichner wie neue Zeichenelemente, Farben oder Stile hinzufügen können.
Kann beziehen sich auf im Framework definierte Ressourcenkennungen , unabhängig davon, ob diese Ressourcen in /frameworks/base/core/res oder mittels eines Build-Time-Overlays definiert sind. Auf diese Bezeichner muss mit dem Namensraum android: verwiesen werden:
- Verwenden Sie für öffentliche DeviceDefault-RROs android .
  Beispiel: @android:style/TextAppearance.DeviceDefault.Large .
- Für alle anderen (nicht öffentliche oder über Build-Time-Overlay hinzugefügte Ressourcen) verwenden Sie *android .
  Beispiel: @*android/style:TextAppearance.OEM.Brand1.Title .

Zusätzlich zu den Ressourcen muss der RRO-Ordner Folgendes enthalten:

AndroidManifest.xml . Im folgenden Beispiel 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 in dem oem im folgenden Makefile das Präfix definiert, das alle generierten RROs haben würden.

  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

Konfigurieren Sie RROs

Es wird eine neue Konfigurationsdatei unterstützt, overlayable.xml , mit der Sie Zugriffskontrollen definieren können. Sie können beispielsweise angeben, wer Ressourcen überlagern darf und welche Ressourcen überlagert werden können. Dadurch können Ressourcen nun auf unterschiedliche Weise gruppiert werden, um sie für die Überlagerung durch verschiedene RROs verfügbar zu machen.

So richten Sie die RRO-Zugriffskontrolle ein:

Erstellen Sie im Ordner res/values die Datei overlayable.xml .
Erstellen Sie die Ressourcen-Tags <overlayable> .
Definieren Sie das name für das <overlayable> -Tag, das im Paket eindeutig sein muss. Jedes Overlay kann nur auf eine überlagerbare Gruppe abzielen.
Definieren Sie das Tag <policy> innerhalb <overlayable> .

Definieren Sie die Ressourcengruppen, 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 an Ihrem RRO-Projekt an:

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

Betrachten Sie das folgende Beispiel. Der erste Abschnitt gehört zu AndroidManifest.xml , während der zweite Abschnitt zu overlays.xml gehört.

  <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>

Mit einer Einschränkung funktionieren zuvor vorhandene RROs in Android 10. Die Einschränkung besteht darin, dass Pakete zur Installation mit PackageManagerRRO entweder vorinstalliert oder mit demselben Schlüssel wie die Ziel-App signiert sein müssen. In Android 10 können Layoutdateien überlagert werden. Dies erfordert jedoch die Verwendung von requireViewById() beim Abrufen der Ansicht anstelle von findViewById() . In Android 10 wurde diese Änderung in 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 auf sie verweisen.

Fügen Sie OEM-spezifische Ressourcen hinzu

So überwinden Sie die RRO-Einschränkungen, die das Hinzufügen von OEM-Ressourcen verhindern:

Erweitern Sie Frameworks/Basis mithilfe eines Build-Time- Overlays und fügen Sie alle erforderlichen Ressourcen hinzu.
Verweisen Sie auf diese Ressourcen der OEM-RROs mit dem Namensraum *android: :.

Im Folgenden finden Sie beispielsweise eine Möglichkeit, ein OEM-spezifisches Drawable hinzuzufügen und es in einem RRO zu 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>

Behandeln Sie mehrere Marken

RRO-Manifestdateien verfügen über eine Syntax, die eine bedingte Anwendung basierend auf Systemeigenschaften ermöglicht. Um mehrere Marken in einem einzigen Systemabbild zu verwalten, können OEMs dies wie folgt verwenden (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>

Die Syntax für android:requiredSystemPropertyName und android:requiredSystemPropertyValue würde dazu führen, dass dieser RRO nur aktiviert wird, wenn die entsprechende Systemeigenschaft mit dem bereitgestellten Wert übereinstimmt. OEMs können dann mehrere dieser RROs definieren, die alle statisch aktiviert sind und jeweils nur eines aktiv haben.

Fügen Sie einem Ziel eine Car-UI-Bibliothek hinzu

Um die Car UI-Bibliothek in ein Android-Ziel zu integrieren, müssen Sie den folgenden Codeausschnitt einbinden:

# 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 \
      ...

Hinweis: Das oem- Präfix muss mit der in RRO Android.mk definierten Variablen CAR_UI_RRO_SET_NAME übereinstimmen. Der obige Code:

Bewirkt, dass <path-to-OEM-overlays>/rro/Android.mk ein RRO für jedes der in CAR_UI_RRO_PACKAGE_NAMES genannten Pakete generiert.
Schließt die generierten RROs in PRODUCT_PACKAGES ein.
Enthält ein Build-Time-Overlay in PRODUCT_PACKAGE_OVERLAYS , um OEM-spezifische Ressourcen hinzuzufügen.

Um zu erfahren, welche Pakete car-ui-lib unterstützen, lesen Sie die Liste der Pakete, die car-ui-lib enthalten .