Personalizza le app

Ora che i componenti e le risorse della libreria dell'UI dell'auto sono disponibili nelle app, per personalizzare queste app, gli OEM devono fornire due overlay:

  • L'overlay di build aggiunge eventuali risorse necessarie per l'overlay delle risorse di runtime. Ad esempio:

    • Drawable
    • Stili (ad es. aspetto del testo)
    • Risorse condivise (ad es. colori)

  • La cartella dell'overlay RRO contiene le risorse utilizzate per generare un RRO per app di destinazione. Queste risorse possono fare riferimento solo a:

    • Valori definiti all'interno dello stesso RRO (ad esempio, per un colore si tratta di un valore esadecimale ).
    • Risorse framework Android (ad esempio, @android:color/accent).
    • Una risorsa definita nell'overlay del tempo di build sopra.

Struttura generale

La struttura dell'overlay di personalizzazione proposta è la seguente:

  • <path-to-OEM-overlays>/

    • overlay/framework/base/core/res/. Risorse overlay in fase di creazione

    • rro/

      • Android.mk. Makefile utilizzato per generare gli RRO per ciascun pacchetto target in base alle risorse contenute in questa cartella.

      • AndroidManifest.xml. Un modello di file manifest utilizzato da quanto sopra creatore del file.

      • res/. Overlay di runtime da applicare a tutte le app target.

Gli OEM possono avere più di una di queste strutture, a seconda del numero di brand che vogliono in un singolo target di build (vedi Gestire più brand).

Overlay di risorse di runtime

La cartella RRO nella cartella dell'overlay dell'OEM deve contenere risorse da applicare a tutte le app di destinazione. Gli RRO hanno limitazioni che influiscono sulla loro capacità di sovrapporre risorse composte. In sintesi, un RRO:

  • Non può fare riferimento agli identificatori di risorse definiti nell'APK di destinazione o nel l'RRO stesso. Ciò significa che gli RRO non possono aggiungere nuovi identificatori, come nuovi drawable, colori o stili.

  • Può fare riferimento agli identificatori di risorse definiti nel stesso, indipendentemente dal fatto che queste risorse siano definite in /frameworks/base/core/res o mediante di un overlay tempo di build. Questi identificatori devono essere indicati tramite l'android: spazio dei nomi:

    • Per gli RRO di DeviceDefault pubblici, utilizza android.
      Ad esempio, @android:style/TextAppearance.DeviceDefault.Large.

    • Per tutti gli altri (risorse non pubbliche o aggiunte tramite overlay durante la creazione), usa *android.
      Ad esempio, @*android/style:TextAppearance.OEM.Brand1.Title.

Oltre alle risorse, la cartella RRO deve contenere:

  • AndroidManifest.xml. Nell'esempio riportato di seguito, RRO_PACKAGE_NAME e TARGET_PACKAGE_NAME sono segnaposto per i makefile:

    <?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 cui oem nel seguente makefile definisce il prefisso che tutti gli RRO generati avrebbero avuto. 
      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

Configurare gli RRO

È supportato un nuovo file di configurazione, overlayable.xml, che puoi utilizzare per definire controlli dell'accesso. Ad esempio, puoi specificare chi può sovrapporre risorse e quali risorse possono essere sovrapposti. Di conseguenza, ora le risorse possono essere raggruppate in diversi modi essere sovrapponibili a diversi RRO.

Per configurare il controllo dell'accesso RRO:

  1. Nella cartella res/values, crea overlayable.xml.
  2. Crea i tag delle risorse <overlayable>.
  3. Definisci l'attributo name per il tag <overlayable>, che devono essere univoci nel pacchetto. Ogni overlay può avere come target un solo gruppo sovrapponibile.
  4. Definisci il tag <policy> all'interno di <overlayable>.
  5. Definisci i gruppi di risorse che possono essere sovrapposti. Ad esempio: 
      <resources>
      <overlayable name="OverlayableResources">
          <policy type="public">
              <item type="string" name="app_title" />
          </policy>
      </overlayable>
  </resources>

Per applicare le seguenti modifiche al progetto RRO:

  1. Nella cartella res/xml, crea overlays.xml. Vedi la voce nel di esempio di codice riportato di seguito per overlay.
  2. Definisci le risorse di cui eseguire l'override.
  3. Aggiungi android:resourcesMap="@xml/overlays" a <overlay> in AndroidManifest.xml. Nell'esempio di codice riportato di seguito, vedi la voce relativa <overlay>
  4. Imposta android:isStatic=”true” per un overlay statico. Ogni overlay può avere come target solo uno dei gruppi che può essere sovrapposto.

Considera il seguente esempio. La prima sezione appartiene a AndroidManifest.xml mentre la seconda sezione riguarda 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>

Con un'avvertenza, gli RRO esistenti funzionano in Android 10. L'avvertenza essere installati con PackageManagerRRO, i pacchetti devono essere preinstallati firmato con la stessa chiave dell'app di destinazione. In Android 10, i file di layout possono essere sovrapposti. Tuttavia, questa operazione richiede l'utilizzo di requireViewById() durante il recupero della vista anziché findViewById(). In Android 10, questa modifica è stata implementata in car-ui-lib per supportare overlay di layout.

La prossima versione principale di Android vi permetterà di sovrapporre un file di layout e definire nuove risorse nel pacchetto RRO e farvi riferimento internamente.

Aggiungi risorse specifiche per l'OEM

Per superare i limiti RRO che impediscono l'aggiunta di risorse OEM:

  • Estendi i framework/base utilizzando un overlay in fase di creazione, aggiungendo l'eventuale necessità Google Cloud.
  • Fai riferimento a queste risorse dei RRO dell'OEM utilizzando lo spazio dei nomi *android:.

Ad esempio, di seguito è riportato un modo per aggiungere un drawable specifico dell'OEM e utilizzarlo in un RRO:

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

Gestire più brand

I file manifest RRO hanno una sintassi che ne consente l'applicazione condizionale in base al sistema proprietà. Per gestire più brand in un'unica immagine di sistema, gli OEM possono utilizzare questa (vedi Struttura generale). 

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

La sintassi per android:requiredSystemPropertyName e android:requiredSystemPropertyValue comporta l'attivazione di questo RRO solo se la proprietà di sistema corrispondente corrisponde al valore fornito. Gli OEM possono quindi definire questi RRO, sono tutti abilitati in modo statico e hanno un solo attivo alla volta.

Aggiungi la libreria di UI dell'auto a un target

Per incorporare la libreria dell'UI dell'auto in un target Android, devi includere il seguente snippet di codice: 

# 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 \
      ...
di Gemini Advanced.

  • Di conseguenza, <path-to-OEM-overlays>/rro/Android.mk genera un RRO per ciascuno dei pacchetti denominati in CAR_UI_RRO_PACKAGE_NAMES.

  • Include gli RRO generati in PRODUCT_PACKAGES.

  • Include un overlay dei tempi di build in PRODUCT_PACKAGE_OVERLAYS per aggiungere elementi specifici dell'OEM Google Cloud.

Per informazioni sui pacchetti che supportano car-ui-lib, consulta la sezione Elenco di pacchetti contenenti car-ui-lib.