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 atributoandroid:
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
eTARGET_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 queoem
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
, crieoverlayable.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
, crieoverlays.xml
. Consulte a entrada no exemplo de código abaixo paraoverlay
. - Defina os recursos a serem substituídos.
- Adicionar
android:resourcesMap="@xml/overlays"
ao<overlay>
emAndroidManifest.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 \ ...
-
Faz com que o
<path-to-OEM-overlays>/rro/Android.mk
gere uma RRO para cada dos pacotes nomeados emCAR_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.