Exploração aprofundada do Android HAL (1): visão geral da arquitetura

Neste artigo, aprenderemos em profundidade sobre as diferentes formas e arquiteturas do Android HAL, bem como as diferenças e conexões entre elas. Ele começará com o HAL legado mais antigo e, em seguida, apresentará o novo método de definição de HAL a partir do Android 8.0 (Oreo): HIDL (Hardware Interface Definition Language). Serão comparados dois modos de HIDL: modo Passthrough e modo Binderizado, e suas respectivas vantagens e desvantagens serão analisadas. Finalmente, resumiremos o papel e a importância do HAL e aguardaremos a direção do desenvolvimento futuro.A estrutura do código é baseada no exemplo SystemGpio personalizado (HAL legado).

Série de artigos:
Exploração aprofundada do Android HAL (1): Visão geral da arquitetura
Exploração aprofundada do Android HAL (2): HAL tradicional e simulação de criptografia e descriptografia de arquivos
Exploração aprofundada do Android HAL (3): Modo de passagem HIDL e porta serial simulação de retorno de chamada de dados
Exploração aprofundada do Android HAL (4): Modo HIDL Binderizado e simulação de retorno de chamada de dados CAN
Exploração aprofundada do Android HAL (5): Depuração de relatórios e soluções de erros HAL

0. Aprendizagem de referência

Visão geral da camada de abstração de hardware (HAL)
HIDL C++ | Projeto de código aberto Android
Tipo HAL | Projeto de código aberto Android
HIDL Explicação detalhada - Android10.0 Princípio de comunicação HwBinder (2)
Parte de hardware de interface GPIO personalizada da série Rockchip (3)

1. HAL legado

Antes do HIDL, o Android usava o HAL tradicional, que era escrito em linguagem C. Este HAL define uma série de estruturas e ponteiros de função, um dos quais hw_module_trepresenta um módulo de hardware. Este estilo de HAL geralmente está localizado /hardware/libhardware/include/hardware/em um diretório.

modo interativo

O HAL tradicional precisa interagir com a estrutura Android para fornecer funções e serviços relacionados ao hardware. Para conseguir isso, o HAL tradicional precisa passar pelos seguintes níveis:

• Interface Java Framework : Esta é uma classe ou interface Java definida na estrutura Android, usada para fornecer APIs para aplicativos ou serviços. Por exemplo, android.os.SystemGpioé uma classe Java usada para controlar a porta GPIO (General Purpose Input/Output).
• Interface AIDL : Este é um arquivo AIDL (Android Interface Definition Language) definido na estrutura Android, que é usado para descrever os tipos de dados e assinaturas de métodos que precisam ser passados ​​​​ou retornados durante a comunicação entre processos. android.os.IGpioService.aidlÉ um arquivo AIDL usado para definir a interface que o serviço GPIO precisa implementar.
• Implementação de serviço em Java : esta é uma classe Java na estrutura Android que implementa a interface AIDL, usada para executar em segundo plano como um serviço e lidar com solicitações de outros processos ou aplicativos. com.android.server.GpioServiceÉ uma classe Java usada para implementar serviços GPIO.
• Camada JNI : Este é o código C/C++ na estrutura Android que usa JNI (Java Native Interface) para fazer a ponte entre a interação entre a camada Java e a camada C. A camada JNI é responsável por converter os parâmetros passados ​​pela camada Java em tipos de dados que podem ser reconhecidos pela camada C e chamar as funções C correspondentes. vice-versa. com_android_server_GpioService.cppÉ um arquivo de camada JNI usado para chamar funções relacionadas ao GPIO HAL.
• Cabeçalho HAL : Este é um arquivo de cabeçalho C no HAL tradicional que define especificações de interface, como estruturas e ponteiros de função. Esses arquivos de cabeçalho geralmente estão localizados hardware/libhardware/include/hardware/em diretórios e _hal.hterminam com . gpio_hal.hÉ um arquivo de cabeçalho HAL usado para definir interfaces relacionadas ao GPIO HAL.
• Implementação HAL : Este é o código C que implementa a especificação de interface definida no arquivo de cabeçalho HAL no HAL tradicional. Esses códigos geralmente estão localizados hardware/libhardware/modules/em diretórios e _hal.cterminam com . gpio_hal.cÉ um arquivo de implementação HAL usado para implementar funções relacionadas ao GPIO HAL.
• Driver do Kernel : Este é o código da camada do driver que interage diretamente com o hardware e geralmente faz parte do kernel do sistema operacional. Esses códigos geralmente estão localizados kernel/drivers/em diretórios e terminam com .cou .h. gpio.cÉ um arquivo da camada de driver usado para controlar o status de entrada e saída da porta GPIO.

arquitetura de código

O HAL tradicional é o design inicial da camada de abstração de hardware do sistema Android. Seu principal objetivo é fornecer uma interface unificada para o framework Android, para que o framework possa interagir com o hardware subjacente sem se preocupar com a implementação específica do hardware.

• Interface da estrutura Java :

  • frameworks/base/core/java/android/os/SystemGpio.java: Esta é a interface Java na estrutura Android por meio da qual aplicativos e serviços do sistema interagem com o hardware GPIO.

• Interface AIDL :

  • frameworks/base/core/java/android/os/IGpioService.aidl: AIDL (Android Interface Definition Language) define uma interface entre processos que permite que aplicativos se comuniquem com serviços GPIO em execução em outro processo.

• Implementação de serviço em Java :

  • frameworks/base/services/core/java/com/android/server/GpioService.java: Esta é uma implementação Java de um serviço GPIO que lida com solicitações de aplicativos e interage com o hardware subjacente via JNI.

• Camada JNI :

  • frameworks/base/services/core/jni/com_android_server_GpioService.cpp: A camada JNI (Java Native Interface) permite que o código Java interaja com o código C/C++ nativo. O código JNI aqui serve para fazer a ponte entre a comunicação entre o serviço Java e o HAL.

• Cabeçalho HAL :

  • hardware/libhardware/include/hardware/gpio_hal.h: Este é o arquivo de cabeçalho do HAL, que define a interface e as estruturas de dados necessárias para interagir com o hardware.

• Implementação HAL :

  • hardware/libhardware/modules/gpio/gpio_hal.c: Esta é uma implementação C do HAL, que interage com o driver de hardware subjacente.

• Driver do kernel :

  • kernel/drivers/misc/gpio/gpio.c: Este é o driver GPIO no kernel Linux, que interage diretamente com o hardware.

Diagrama de arquitetura

A arquitetura HAL tradicional é mostrada na figura abaixo:

A vantagem do HAL tradicional é que ele é simples e direto, fácil de entender e implementar. Mas também tem algumas deficiências, principalmente as seguintes:

• Falta de controle de versão e compatibilidade com versões anteriores : O HAL tradicional não possui um número de versão claro e um mecanismo de alteração de interface. Se o fornecedor de hardware ou o sistema Android precisar modificar ou estender a interface HAL, todos os códigos relacionados precisarão ser modificados ao mesmo tempo, incluindo a camada JNI, a camada de estrutura e a camada de aplicativo . Isso torna a manutenção e atualização do código difícil e demorada.
• Falta de segurança e estabilidade : O HAL tradicional está diretamente ligado ao processo do cliente como uma biblioteca, o que significa que as chamadas entre o cliente e o HAL são intraprocessos, sem a sobrecarga da comunicação entre processos. Mas isso também significa que se houver um erro ou falha no HAL, isso afetará o processo do cliente e até causará a falha de todo o sistema. O HAL tradicional não possui mecanismo de sandbox e nem controle de permissão. Qualquer processo pode acessar qualquer módulo , o que pode trazer riscos de segurança.

Para resolver as deficiências do HAL tradicional, o Android introduziu um novo método de definição de HAL: HIDL a partir de 8.0 (Oreo).

HIDL (Hardware Interface Definition Language) é uma linguagem usada para definir a interface do HAL. O HIDL oferece melhor controle de versão e compatibilidade com versões anteriores do que o HAL tradicional. HIDL também oferece suporte a dois modos diferentes: modo Passthrough e modo Binderized. Esses dois modos correspondem a diferentes métodos e arquiteturas de comunicação.

2. Modo de passagem HIDL

modo interativo

No modo Passthrough, o serviço HAL é executado como uma biblioteca no processo cliente. Isto significa que as chamadas entre o cliente e o HAL estão em processo, sem a sobrecarga da comunicação entre processos. Este modo é semelhante ao HAL tradicional, mas possui as seguintes diferenças:

• Use C++ em vez de C : O HIDL HAL no modo Passthrough é escrito em C++. Isso permite que o HAL use recursos do C++, como classes, herança, polimorfismo, etc.
• Use .hal em vez de .h : HIDL HAL no modo Passthrough usa .halarquivos para definir especificações de interface, não .harquivos. .halArquivo é uma sintaxe especial usada para descrever os tipos de dados e assinaturas de métodos que precisam ser passados ​​ou retornados na interface HAL. .halOs arquivos geralmente estão localizados hardware/interfaces/em diretórios e .halterminam com . Por exemplo, IGpio.halé um .halarquivo usado para definir interfaces relacionadas ao GPIO HAL.
• Use hidl-gen em vez de escrever código manualmente : O HIDL HAL no modo Passthrough usa uma ferramenta: para gerar código C++ e Java hidl-gena partir de arquivos. .halEsses códigos incluem implementação de interface, proxy de cliente, registro de serviço e outras funções. Isso evita escrever manualmente código repetitivo e tedioso e garante que o código seja consistente com a especificação da interface.
• Use Android.bp em vez de Android.mk : HIDL HAL no modo Passthrough usa um novo sistema de compilação: Soong para compilar o código. Soong usa .bparquivos para descrever os tipos de dados e assinaturas de métodos que precisam ser passados ​​ou retornados na interface HAL. .halOs arquivos geralmente estão localizados hardware/interfaces/em diretórios e .halterminam com . IGpio.halÉ um .halarquivo usado para definir interfaces relacionadas ao GPIO HAL.
• Use Android.bp em vez de Android.mk : HIDL HAL no modo Passthrough usa um novo sistema de compilação: Soong para compilar o código. Soong usa .bparquivos em vez de arquivos para descrever regras e dependências de construção .mk. .bpOs arquivos geralmente estão localizados no mesmo diretório do código de implementação HAL e .bpterminam com . Gpio.bpÉ um .bparquivo usado para compilar código relacionado ao GPIO HAL.

A vantagem do modo Passthrough é o alto desempenho e a ausência de sobrecarga de comunicação entre processos. Mas também tem algumas deficiências, principalmente as seguintes:

• Falta de segurança e estabilidade : O modo Passthrough ainda apresenta os problemas de segurança e estabilidade do HAL tradicional. Como o serviço HAL é executado como uma biblioteca no processo do cliente, se ocorrer um erro ou travamento no HAL, isso afetará o processo do cliente e até causará o travamento de todo o sistema. O modo passthrough também não possui mecanismo sandbox e nenhum controle de permissão. Qualquer processo pode acessar qualquer módulo HAL, o que pode trazer riscos de segurança.
• Falta de flexibilidade e escalabilidade : HIDL HAL no modo Passthrough só pode ser vinculado ao processo do cliente como uma biblioteca, o que significa que o cliente deve ser um serviço ou aplicativo nativo C++. Se o cliente for um aplicativo ou serviço da camada Java, a camada JNI ainda será necessária para fazer a ponte entre Java e C++. Isso aumenta a complexidade do código e os custos de manutenção. O modo Passthrough também não oferece suporte a vários clientes acessando o mesmo serviço HAL ao mesmo tempo, o que limitará a escalabilidade do serviço HAL.

Para resolver as deficiências do modo Passthrough, o Android também oferece outro modo HIDL: o modo Binderized.

arquitetura de código

HIDL (Hardware Interface Definition Language) é um novo mecanismo de abstração de hardware introduzido no Android Oreo (8.0). O modo Passthrough é um dos modos que permite que o HAL seja executado de maneira tradicional, mas interaja com a estrutura Android por meio da interface HIDL.

• Interface da estrutura Java :

  • frameworks/base/core/java/android/os/SystemGpio.java: Esta é a interface Java na estrutura Android por meio da qual aplicativos e serviços do sistema interagem com o hardware GPIO.

• Definição de interface HIDL :

  • hardware/interfaces/gpio/1.0/IGpio.hal: Esta é uma interface definida pelo HIDL que descreve como interagir com o hardware GPIO.

• Implementação de serviço nativo :

  • frameworks/base/services/core/jni/com_android_server_GpioService.cpp: Se a camada Java precisar acessar o hardware diretamente, ela interagirá com a interface HIDL por meio dessa camada JNI.

• Implementação HAL :

  • hardware/interfaces/gpio/1.0/default/Gpio.cpp: Esta é a implementação do HIDL HAL, que interage com o driver de hardware subjacente.

• Driver do kernel :

  • kernel/drivers/misc/gpio/gpio.c: Este é o driver GPIO no kernel Linux, que interage diretamente com o hardware.

Diagrama de arquitetura

A arquitetura do HIDL HAL no modo Passthrough é mostrada na figura abaixo:

3. Modo HIDL Binderizado:

modo interativo

No modo Binderizado, o serviço HAL é executado como um processo independente. A comunicação entre o cliente e o HAL é feita através do Binder IPC. Este modo é diferente do modo Passthrough, mas tem os seguintes pontos em comum:

• Use C++ em vez de C : O HIDL HAL no modo Binderizado também é escrito em C++.
• Use .hal em vez de .h : HIDL HAL no modo Binderizado também usa .halarquivos para definir especificações de interface.
• Use hidl-gen em vez de escrever código manualmente : HIDL HAL no modo Binderizado também é usado hidl-genpara gerar código C++ e Java a partir de .halarquivos.
• Use Android.bp em vez de Android.mk : HIDL HAL no modo Binderized também usa Soong para compilar o código.

A vantagem do modo Binderizado é a alta segurança e estabilidade, pois o serviço HAL é executado em seu próprio ambiente sandbox e pode ser permitido através do SELinux. O modo Binderizado também oferece suporte a vários clientes para acessar o mesmo serviço HAL ao mesmo tempo, melhorando a escalabilidade do serviço HAL. Mas também tem algumas deficiências, principalmente as seguintes:

• Baixo desempenho : HIDL HAL no modo Binderizado requer comunicação entre processos por meio do Binder IPC, o que traz sobrecarga e latência adicionais. Especialmente para alguns serviços de hardware com requisitos de alta frequência ou baixa latência, como áudio, vídeo, sensores, etc., o Binder IPC pode afetar seu desempenho e experiência.
• Alta complexidade : HIDL HAL no modo Binderizado precisa implementar um processo de serviço independente, o que aumentará a complexidade do código e os custos de manutenção. Especialmente para alguns serviços de hardware simples ou pouco usados, como GPIO, LED, etc., pode ser desnecessário implementar um processo de serviço independente.

arquitetura de código

O modo Binderizado é outro modo de HIDL onde o HAL é executado como um processo separado e interage com a estrutura Android por meio do Binder IPC.

• Interface da estrutura Java :

  • frameworks/base/core/java/android/os/SystemGpio.java: Esta é a interface Java na estrutura Android por meio da qual aplicativos e serviços do sistema interagem com o hardware GPIO.

• Definição de interface HIDL :

  • hardware/interfaces/gpio/1.0/IGpio.hal: Esta é uma interface definida pelo HIDL que descreve como interagir com o hardware GPIO.

• Implementação do serviço HAL :

  • hardware/interfaces/gpio/1.0/service/GpioService.cpp: Esta é a implementação do serviço HAL no modo Binderizado, que funciona como um processo independente e interage com a estrutura Android através do Binder IPC.

• Driver do kernel :

  • kernel/drivers/misc/gpio/gpio.c: Este é o driver GPIO no kernel Linux, que interage diretamente com o hardware.

Diagrama de arquitetura

A arquitetura do HIDL HAL no modo Binderizado é mostrada na figura abaixo:

Resumo: O HIDL oferece dois modos diferentes: modo Passthrough e modo Binderized. Esses dois modos correspondem a diferentes métodos e arquiteturas de comunicação. O modo Passthrough tem alto desempenho, mas baixa segurança e estabilidade. O modo Binderizado possui alta segurança e estabilidade, mas baixo desempenho. Você pode escolher o modo apropriado com base em necessidades e serviços de hardware específicos.

O papel e o significado do HAL

HAL é uma ponte entre o sistema Android e o hardware. Ele fornece uma interface padrão para a estrutura Android, permitindo que a estrutura Android interaja com uma variedade de hardware sem conhecer os detalhes específicos de implementação do hardware. As funções e significado do HAL incluem principalmente os seguintes pontos:

• Compatibilidade aprimorada entre fornecedores de hardware e o sistema Android : Através do HAL, os fornecedores de hardware podem fornecer ao seu hardware uma interface que atenda às especificações do Android sem precisar modificar seus drivers ou o sistema Android. Isso torna mais fácil para os fornecedores de hardware adaptarem seu hardware à plataforma Android e atualizarem seus drivers com mais rapidez.
• Abstração aprimorada entre o sistema Android e os aplicativos : por meio do HAL, o sistema e os aplicativos Android podem usar uma API unificada para acessar serviços de hardware sem ter que se preocupar com os detalhes específicos de implementação do hardware. Isso torna mais fácil para os sistemas e aplicativos Android suportar múltiplas plataformas e dispositivos de hardware e expandir e otimizar suas funções com mais flexibilidade.
• Maior segurança e estabilidade entre sistemas e aplicativos Android : Através do HAL, os sistemas e aplicativos Android podem restringir o acesso a serviços de hardware por meio de mecanismos de sandbox e controle de permissão, evitando que operações maliciosas ou errôneas causem danos ao hardware ou sistemas. Através do HAL, o sistema e os aplicativos Android também podem isolar ou recuperar problemas causados ​​por erros ou falhas nos serviços de hardware para garantir o funcionamento normal do sistema e dos aplicativos.

direção de desenvolvimento futuro

À medida que o sistema Android e a plataforma de hardware continuam a se desenvolver e inovar, o HAL também mudará e evoluirá de acordo. Possíveis direções de desenvolvimento:

• Mais HIDLização : HIDL é uma nova maneira de definir HAL, que fornece melhor controle de versão e compatibilidade com versões anteriores. Atualmente, o HIDL cobre a maioria dos serviços de hardware, como áudio, vídeo, sensores, câmeras, etc. Mas ainda existem alguns HAL tradicionais que não foram HIDLizados, como gerenciamento de energia, gerenciamento de memória, etc. No futuro, poderemos ver HALs mais tradicionais sendo HIDLizados para melhorar sua compatibilidade e capacidade de manutenção.
• Mais Binderizado : O modo Binderizado é um novo método de comunicação HAL que oferece maior segurança e estabilidade. Atualmente, o modo Binderizado é aplicável à maioria dos HALs HIDL, como áudio, vídeo, sensores, câmeras, etc. Mas ainda existem alguns modos Passthrough que não foram Binderizados, como GPIO, LED, etc. É possível ver mais padrões Passthrough sendo Binderizados para melhorar sua segurança e escalabilidade.
• Mais VTS : VTS (Vendor Test Suite) é uma nova ferramenta de teste HAL que pode conduzir automaticamente testes funcionais, de compatibilidade, segurança e desempenho de HAL. Atualmente, o VTS suporta a maioria dos HALs HIDL, como áudio, vídeo, sensores, câmeras, etc. Mas ainda existem alguns HALs que não foram dimensionados para VTS, como gerenciamento de energia, gerenciamento de memória, etc. Poderemos ver mais HALs sendo dimensionados em VTS para melhorar sua qualidade e confiabilidade.

Resumir

Android HAL é um componente importante que fornece uma interface padrão entre o sistema Android e o hardware. Os diferentes métodos e arquiteturas do HAL refletem o contínuo desenvolvimento e inovação dos sistemas Android e plataformas de hardware. Neste artigo, exploramos profundamente os conceitos básicos de três maneiras de aprender Android HAL: Legacy HAL, modo HIDL Passthrough e modo HIDL Binderized, e analisamos as diferenças e conexões entre eles. Também resume o papel e a importância da HAL e aguarda com expectativa a direção futura do desenvolvimento.