O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Personalizando aplicativos

Agora que os componentes e recursos da biblioteca Car UI estão nos aplicativos, para personalizar esses aplicativos, os OEMs devem fornecer duas sobreposições:

Sobreposição em tempo de construção. Essa sobreposição adicionaria quaisquer recursos necessários para os RROs. Isso inclui:
- Drawables
- Estilos (por exemplo, aparências de texto)
- Recursos compartilhados (por exemplo, cores)
Sobreposição RRO. Essa pasta contém os recursos usados para gerar um RRO por aplicativo de destino. Esses recursos só podem se referir a:
- Valores definidos dentro do mesmo RRO (por exemplo, para uma cor seria um valor hexadecimal).
- Recursos da estrutura do Android (por exemplo, @android:color/accent ).
- Um recurso definido na sobreposição de tempo de compilação acima.

Estrutura geral

A estrutura de sobreposição de personalização proposta é a seguinte:

<path-to-OEM-overlays>/
- overlay/framework/base/core/res/ . Recursos de sobreposição em tempo de compilação
- rro/
  - Android.mk . Makefile usado para gerar os RROs para cada pacote de destino com base nos recursos contidos nesta pasta.
  - AndroidManifest.xml . Um modelo de arquivo de manifesto usado pelo makefile acima.
  - res/ . Sobreposições de tempo de execução para aplicar a todos os aplicativos de destino.

Os OEMs podem ter mais de uma dessas estruturas, dependendo do número de marcas que desejam manipular em um único destino de compilação (consulte Manipulação de várias marcas ).

Sobreposições de recursos de tempo de execução

A pasta RRO na pasta de sobreposição OEM deve conter recursos a serem aplicados a todos os aplicativos de destino. Os RROs têm limitações que afetam sua capacidade de sobrepor recursos compostos. Em resumo, um RRO:

Não é possível fazer referência a identificadores de recursos definidos no APK de destino ou no próprio RRO. Isso significa que os RROs não podem adicionar novos identificadores, como novos drawables, cores ou estilos.
lata referem-se a identificadores de recursos definidos na estrutura, sejam esses recursos definidos em /frameworks/base/core/res ou por meio de uma sobreposição de tempo de construção. Esses identificadores devem ser referidos usando o android: name-space:
- Para RROs DeviceDefault públicos , use android
  Por exemplo, @android:style/TextAppearance.DeviceDefault.Large
- Para todos os outros (não público ou recursos adicionados por meio de sobreposição em tempo de compilação), use *android
  Por exemplo, @*android/style:TextAppearance.OEM.Brand1.Title

Além dos recursos, a pasta RRO deve conter:

AndroidManifest.xml . No exemplo abaixo, RRO_PACKAGE_NAME e TARGET_PACKAGE_NAME são espaços reservados para os 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 em que oem no makefile a seguir define o prefixo que todos os RROs gerados teriam.

  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

Configurando sobreposições de RRO

Há suporte para um novo arquivo de configuração, overlayable.xml , que pode ser usado para definir controles de acesso. Por exemplo, você pode especificar quem pode sobrepor recursos e quais recursos podem ser sobrepostos. Como resultado, os recursos agora podem ser agrupados de diferentes maneiras para disponibilizá-los para serem sobrepostos por diferentes RROs.

Para configurar o controle de acesso RRO:

Na pasta res/values , crie overlayable.xml .
Crie as tags de recurso <overlayable> .
Defina o atributo name para a tag <overlayable> , que deve ser exclusiva no pacote. Cada sobreposição pode segmentar apenas um grupo de sobreposição.
Defina a tag <policy> dentro de <overlayable> .

Defina os grupos de recursos que podem ser sobrepostos. Por exemplo:

  <resources>
      <overlayable name="OverlayableResources">
          <policy type="public">
              <item type="string" name="app_title" />
          </policy>
      </overlayable>
  </resources>

Para aplicar as seguintes alterações ao seu projeto RRO:

Na pasta res/xml , crie overlays.xml . Consulte a entrada no exemplo de código abaixo para overlay .
Defina os recursos a serem substituídos.
Adicione android:resourcesMap="@xml/overlays" à tag <overlay> em AndroidManifest.xml . Por exemplo, no exemplo de código abaixo, consulte a entrada para <overlay> .
Defina android:isStatic=”true” para uma sobreposição estática. Cada sobreposição pode segmentar apenas um dos grupos que podem ser sobrepostos.

Considere o exemplo a seguir. A primeira seção pertence a AndroidManifest.xml enquanto a segunda seção pertence a 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>

Com uma ressalva, os RROs existentes anteriormente continuarão a funcionar no Android 10. A ressalva é que, para serem instalados com o PackageManagerRRO, os pacotes devem ser pré-instalados ou assinados com a mesma chave do aplicativo de destino. No Android 10, os arquivos de layout podem ser sobrepostos. No entanto, isso requer o uso de requireViewById() ao obter a visualização em vez de findViewById() . No Android 10, essa alteração foi implementada no car-ui-lib para oferecer suporte a sobreposições de layout.

A próxima versão principal do Android permitirá que você sobreponha um arquivo de layout e defina novos recursos no pacote RRO e faça referência a eles internamente.

Adicionando recursos específicos de OEM

Para superar as limitações de RRO que impedem a adição de recursos OEM:

Estenda estruturas/base usando uma sobreposição em tempo de compilação , adicionando quaisquer recursos necessários.
Consulte esses recursos dos RROs OEM usando *android: namespace.

Por exemplo, a seguir está uma maneira de adicionar um drawable específico do OEM e usá-lo em um 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>

Lidando com várias marcas

Os arquivos de manifesto RRO têm uma sintaxe para permitir que sejam aplicados condicionalmente com base nas propriedades do sistema. Para lidar com várias marcas em uma única imagem de sistema, os OEMs podem usar isso da seguinte maneira (consulte Estrutura geral ).

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

A sintaxe para android:requiredSystemPropertyName e android:requiredSystemPropertyValue faria com que esse RRO fosse ativado somente se a propriedade de sistema correspondente corresponder ao valor fornecido. Os OEMs podem então definir vários desses RROs, todos habilitados estaticamente, e ter apenas um ativo por vez.

Adicionando biblioteca de IU de carro a um destino

Para incorporar a biblioteca Car UI a um destino Android, você deve incluir o seguinte snippet de código:

# 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: O prefixo oem- deve corresponder à variável CAR_UI_RRO_SET_NAME definida no RRO Android.mk . O código acima:

Faz <path-to-OEM-overlays>/rro/Android.mk gere um RRO para cada um dos pacotes nomeados em CAR_UI_RRO_PACKAGE_NAMES .
Inclui os RROs gerados em PRODUCT_PACKAGES .
Inclui uma sobreposição de tempo de compilação em PRODUCT_PACKAGE_OVERLAYS para adicionar recursos específicos de OEM.

Para saber quais pacotes suportam car-ui-lib , consulte Pacotes Suportados por car-ui-lib .