Fornecemos uma implementação de referência para a VHAL da AIDL. A linha de execução principal do serviço é implementada
em
VehicleService.cpp
.
A implementação da interface VHAL está localizada em
DefaultVehicleHal.cpp
.
A implementação de referência é baseada em uma arquitetura de duas camadas. Na camada superior, o
DefaultVehicleHal
implementa a interface AIDL da VHAL e fornece uma lógica genérica
para todos os dispositivos de hardware. Na camada inferior, FakeVehicleHardware
implementa a interface IVehicleHardware
. Essa classe simula a lógica da VHAL
de interação com hardware ou barramento de veículo real e é específica do dispositivo. Os fornecedores também podem adaptar essa mesma arquitetura, reutilizar a mesma classe DefaultVehicleHal
(estendendo-a para substituir um método) e fornecer a própria implementação de IVehicleHardware
.
DefaultVehicleHal
contém a seguinte lógica, que é considerada genérica e pode ser aplicada a qualquer implementação
de VHAL.
- Implementa a interface
IVehicle
. - Realiza verificações básicas de entrada, incluindo uma verificação de IDs duplicados.
- Aloca objetos de cliente (por exemplo,
GetValuesClient
) para cada operação de cada cliente de binder e adiciona cada um a um pool global. - Gerencia a lógica de callbacks assíncronos, como adicionar uma solicitação pendente a um pool de solicitações pendentes. Resolve solicitações pendentes quando recebemos os resultados ou retorna um erro quando uma das solicitações pendentes atinge o tempo limite.
- Serializa e desserializa
LargeParcelable
(consulteParcelableUtils.h
). - Gerencia a assinatura (consulte
SubscriptionManager.h
). - Verifica as permissões. Consulte as funções
checkReadPermission
echeckWritePermission
. - Chama
IVehicleHardware.checkHealth
periodicamente e envia sinais de pulsação (consulte a funçãocheckHealth
).
IVehicleHardware
é uma interface genérica usada para representar uma implementação
específica de hardware da VHAL. A implementação de referência para IVehicleHardware
é
FakeVehicleHardware
,
que usa um mapa na memória para armazenar o valor da propriedade e não
se comunica com um barramento de veículo real. Ele foi criado para ser executado em um emulador e não tem dependências específicas de hardware. As implementações de fornecedores não podem usar esse código como está e precisam adicionar lógica específica do barramento do veículo.
A partir do Android 14, FakeVehicleHardware
lê a configuração de propriedade compatível em tempo de execução
durante a inicialização da pasta /vendor/etc/automotive/vhalconfig/
do dispositivo,
que contém um arquivo de configuração no estilo JSON. Consulte o
arquivo README do VHAL de referência
para ver o formato e o conteúdo do arquivo de configuração.
O FakeVehicleHardware
também oferece suporte à substituição de arquivos de configuração para testes. Se a propriedade
do sistema persist.vendor.vhal_init_value_override
estiver definida (essa propriedade precisa ser
definida no momento da criação ou no início da inicialização antes da inicialização do VHAL), ela usará o arquivo de configuração
da pasta /vendor/etc/automotive/vhaloverride/
no dispositivo para substituir
a configuração atual. Uma implementação do fornecedor pode usar uma abordagem semelhante para que a configuração de propriedade compatível com VHAL não seja codificada e possa ser decidida dinamicamente no momento da inicialização.
A lista de configurações de propriedades do veículo precisa ser estática após a inicialização da VHAL.
A partir do Android 16, o GRPCVehicleHardware
fornece outra implementação de referência IVehicleHardware
. Essa implementação
pressupõe que há um servidor separado em execução em uma máquina ou VM remota que contém a lógica de
processamento de propriedades. A VHAL executada em dispositivos AAOS funciona como um proxy que encaminha solicitações para
o servidor remoto. Consulte grpc para mais detalhes.