Implementação de referência

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 (consulte ParcelableUtils.h).
• Gerencia a assinatura (consulte SubscriptionManager.h).
• Verifica as permissões. Consulte as funções checkReadPermission e checkWritePermission.
• Chama IVehicleHardware.checkHealth periodicamente e envia sinais de pulsação (consulte a função checkHealth).

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.