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.

Personalizar apps

Agora que os componentes e recursos da biblioteca da interface do carro nos apps, para personalizar nesses apps, os OEMs precisam oferecer duas sobreposições:

A sobreposição de tempo de criação adiciona os recursos necessários para o de recursos do ambiente de execução (RROs, na sigla em inglês). Isso inclui:
- Drawables
- Estilos (por exemplo, aparências de texto)
- Recursos compartilhados (por exemplo, cores)
A pasta de sobreposição de RRO contém os recursos usados para gerar uma RRO por aplicativo de destino. Esses recursos podem se referir apenas a:
- Valores definidos dentro da mesma RRO (por exemplo, para uma cor, seria uma string hexadecimal ).
- Recursos de framework do Android (por exemplo, @android:color/accent).
- Um recurso definido na sobreposição de tempo de build acima.

Estrutura geral

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

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

Os OEMs podem ter mais de uma dessas estruturas, dependendo do número de marcas que querem em um só destino de criação (consulte Lidar com várias marcas).

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

A pasta RRO na pasta de sobreposição de OEM precisa conter recursos a serem aplicados a todos os apps de destino. As RROs têm limitações que afetam a capacidade de sobrepor recursos compostos. Em resumo, uma RRO:

Não podem se referir a identificadores de recursos definidos no APK de destino ou no a própria RRO. Isso significa que as RROs não podem adicionar novos identificadores, como novos drawables, cores ou estilos.
Pode referir-se a identificadores de recurso definidos no independentemente de esses recursos serem definidos em /frameworks/base/core/res ou por meios de uma sobreposição de tempo de build. Esses identificadores precisam ser referenciados usando o atributo android: nome-espaço:
- Para RROs públicas do DeviceDefault, use android.
  Por exemplo, @android:style/TextAppearance.DeviceDefault.Large.
- Para todos os outros (recursos não públicos ou adicionados pelo sobreposição de tempo de build), use *android.
  Por exemplo, @*android/style:TextAppearance.OEM.Brand1.Title.

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

AndroidManifest.xml: No exemplo abaixo, RRO_PACKAGE_NAME e TARGET_PACKAGE_NAME são marcadores de posição 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 todas as RROs geradas 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

Configurar RROs

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

Para configurar o controle de acesso de RRO:

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

Defina os grupos de recursos que podem ser sobrepostos. Exemplo:

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

Para aplicar as seguintes mudanças ao 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.
Adicionar android:resourcesMap="@xml/overlays" ao <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 só pode segmentar um dos grupos que podem ser sobrepostos.

Considere este exemplo. A primeira seção pertence a AndroidManifest.xml enquanto a segunda seção se refere 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, as RROs anteriores funcionam no Android 10. A ressalva sejam instalados com o PackageManagerRRO, os pacotes devem ser pré-instalados ou assinado com a mesma chave do app de destino. No Android 10, os arquivos de layout podem ser sobrepostos. No entanto, isso requer o uso de requireViewById() para receber a visualização em vez de findViewById(). No Android 10, essa mudança foi implementada em car-ui-lib para são compatíveis com sobreposições de layout.

A próxima versão principal do Android vai permitir a sobreposição de um arquivo de layout e define novos recursos no pacote RRO e os referencia internamente.

Adicionar recursos específicos de OEM

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

Amplie os frameworks/base usando uma sobreposição de tempo de build, adicionando o necessário do Google Cloud.
Consulte estes recursos das RROs dos OEMs usando o namespace *android:.

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

Lidar com várias marcas

Os arquivos de manifesto de RRO têm uma sintaxe que permite a aplicação condicional com base no sistema propriedades. Para lidar com várias marcas em uma única imagem do sistema, os OEMs podem usar isso como segue (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 de android:requiredSystemPropertyName e android:requiredSystemPropertyValue faria com que essa RRO fosse ativada apenas se a propriedade do sistema correspondente corresponder ao valor fornecido. Os OEMs podem, então, definir vários RROs, todas ativadas estaticamente e com apenas uma ativa por vez.

Adicionar a biblioteca de interface do carro a um destino

Para incorporar a biblioteca Car UI a um destino do Android, inclua 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 \
      ...

Observação : o prefixo oem- precisa corresponder ao CAR_UI_RRO_SET_NAME definida na RRO Android.mk. O código acima:

Faz com que o <path-to-OEM-overlays>/rro/Android.mk gere uma RRO para cada dos pacotes nomeados em CAR_UI_RRO_PACKAGE_NAMES.
Inclui as RROs geradas em PRODUCT_PACKAGES.
Inclui uma sobreposição de tempo de build em PRODUCT_PACKAGE_OVERLAYS para adicionar informações específicas de OEM do Google Cloud.

Para saber quais pacotes têm suporte a car-ui-lib, consulte Lista de pacotes que contêm car-ui-lib.