Questa pagina è stata tradotta dall'API Cloud Translation.

Personalizza le app

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

L'overlay in fase di compilazione aggiunge tutte le risorse necessarie per l'overlay delle risorse di runtime (RRO). Ciò comprende:
- Disegnabili
- Stili (ad esempio, aspetti del testo)
- Risorse condivise (ad esempio, colori)
La cartella overlay RRO contiene le risorse utilizzate per generare un RRO per app di destinazione. Queste risorse possono riferirsi solo a:
- Valori definiti all'interno dello stesso RRO (ad esempio, per un colore questo sarebbe un valore esadecimale).
- Risorse del framework Android (ad esempio @android:color/accent ).
- Una risorsa definita nella sovrapposizione della fase di compilazione precedente.

Struttura generale

La struttura di sovrapposizione della personalizzazione proposta è la seguente:

<path-to-OEM-overlays>/
- overlay/framework/base/core/res/ . Risorse di sovrapposizione in fase di compilazione
- rro/
  - Android.mk . Makefile utilizzato per generare gli RRO per ciascun pacchetto di destinazione in base alle risorse contenute in questa cartella.
  - AndroidManifest.xml . Un modello di file manifest utilizzato dal makefile precedente.
  - res/ . Overlay di runtime da applicare a tutte le app di destinazione.

Gli OEM possono avere più di una di queste strutture, a seconda del numero di marchi che desiderano gestire in un unico target di costruzione (vedi Gestire più marchi ).

Sovrapposizioni di risorse runtime

La cartella RRO nella cartella di sovrapposizione OEM deve contenere risorse da applicare a tutte le app di destinazione. Le RRO hanno limitazioni che incidono sulla loro capacità di sovrapporre risorse composte. In sintesi, un RRO:

Non può fare riferimento agli identificatori di risorsa definiti nell'APK di destinazione o nell'RRO stesso. Ciò significa che le RRO non possono aggiungere nuovi identificatori come nuovi drawable, colori o stili.
Potere fare riferimento agli identificatori delle risorse definiti nel framework, indipendentemente dal fatto che tali risorse siano definite in /frameworks/base/core/res o tramite un overlay in fase di compilazione. Questi identificatori devono essere riferiti utilizzando android: name-space:
- Per gli RRO DeviceDefault pubblici , utilizzare android .
  Ad esempio, @android:style/TextAppearance.DeviceDefault.Large .
- Per tutti gli altri (non pubblici o risorse aggiunte tramite overlay in fase di compilazione), utilizzare *android .
  Ad esempio, @*android/style:TextAppearance.OEM.Brand1.Title .

Oltre alle risorse, la cartella RRO deve contenere:

AndroidManifest.xml . Nell'esempio seguente, 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 makefile seguente definisce il prefisso che avrebbero tutti gli RRO generati.

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

È supportato un nuovo file di configurazione, overlayable.xml , che è possibile utilizzare per definire i controlli di accesso. Ad esempio, puoi specificare chi può sovrapporre le risorse e quali risorse possono essere sovrapposte. Di conseguenza, le risorse possono ora essere raggruppate in modi diversi per renderle disponibili per essere sovrapposte da diverse RRO.

Per impostare il controllo dell'accesso RRO:

Nella cartella res/values creare overlayable.xml .
Crea i tag di risorsa <overlayable> .
Definire l'attributo name per il tag <overlayable> , che deve essere univoco nel pacchetto. Ciascun overlay può avere come target un solo gruppo sovrapponibile.
Definire il tag <policy> all'interno di <overlayable> .

Definire 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 tuo progetto RRO:

Nella cartella res/xml , crea overlays.xml . Vedere la voce nell'esempio di codice riportato di seguito per overlay .
Definire le risorse da sovrascrivere.
Aggiungi android:resourcesMap="@xml/overlays" al tag <overlay> in AndroidManifest.xml . Nell'esempio di codice riportato di seguito, ad esempio, vedere la voce per <overlay> .
Imposta android:isStatic=”true” per un overlay statico. Ogni sovrapposizione può avere come target solo uno dei gruppi che possono essere sovrapposti.

Considera il seguente esempio. La prima sezione appartiene ad 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 avvertimento, gli RRO esistenti in precedenza funzionano in Android 10. L'avvertenza è che per essere installati con PackageManagerRRO, i pacchetti devono essere preinstallati o firmati con la stessa chiave dell'app di destinazione. In Android 10, i file di layout possono essere sovrapposti. Tuttavia, ciò richiede l'uso di requireViewById() mentre si ottiene la vista invece di findViewById() . In Android 10, questa modifica è stata implementata in car-ui-lib per supportare le sovrapposizioni di layout.

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

Aggiungi risorse specifiche dell'OEM

Per superare le limitazioni RRO che impediscono l'aggiunta di risorse OEM:

Estendi framework/base utilizzando un overlay in fase di compilazione , aggiungendo tutte le risorse necessarie.
Fare riferimento a queste risorse degli RRO OEM utilizzando *android: namespacing.

Ad esempio, il seguente è 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>

Gestisci più marchi

I file manifest RRO hanno una sintassi che ne consente l'applicazione condizionale in base alle proprietà del sistema. Per gestire più marchi in un'unica immagine di sistema, gli OEM possono utilizzarla come segue (vedere 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 causerebbe l'abilitazione di questo RRO solo se la proprietà di sistema corrispondente corrisponde al valore fornito. Gli OEM possono quindi definire più di questi RRO, tutti abilitati staticamente e averne solo uno attivo alla volta.

Aggiungi la libreria dell'interfaccia utente dell'auto a una destinazione

Per incorporare la libreria Car UI in una destinazione 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 \
      ...

Nota: il prefisso oem- deve corrispondere alla variabile CAR_UI_RRO_SET_NAME definita in RRO Android.mk . Il codice sopra:

Fa sì che <path-to-OEM-overlays>/rro/Android.mk generi un RRO per ciascuno dei pacchetti denominati in CAR_UI_RRO_PACKAGE_NAMES .
Include gli RRO generati in PRODUCT_PACKAGES .
Include un overlay in fase di compilazione in PRODUCT_PACKAGE_OVERLAYS per aggiungere risorse specifiche dell'OEM.

Per sapere quali pacchetti supportano car-ui-lib , vedere Elenco dei pacchetti contenenti car-ui-lib .