Arquitetura HAL

O hardware POS varia conforme o fabricante, mas o software de pagamentos da Getnet precisa conversar com todos os dispositivos da mesma forma. A arquitetura HAL (Hardware Abstraction Layer) é como a Getnet resolve isso: um contrato fixo que qualquer fabricante pode implementar. As camadas acima dele nunca precisam saber qual hardware estão operando.

O que é a arquitetura HAL

A arquitetura tem quatro camadas, e cada uma depende apenas da que está abaixo:

1. SDK PagoNxt — o SDK que os parceiros da Getnet embarcam nas próprias aplicações. Chama as funções de hardware por duas bibliotecas: libposemv (processamento EMV) e libposdigital (acesso geral ao hardware).
2. Middleware App — fica entre o SDK e seu serviço. Recebe as chamadas de libposemv e libposdigital e as encaminha ao serviço do fabricante instalado no dispositivo.
3. libhalservice — a biblioteca de interfaces AIDL que a Getnet entrega aos fabricantes. Define todos os métodos que a Middleware App pode chamar, sem definir como eles funcionam.
4. Manufacturer Service App — sua implementação da libhalservice, com o nome de pacote com.pagonxt.hal.platform.service. É a única camada que conhece o hardware real do seu dispositivo.

Uma requisição nasce na camada do SDK PagoNxt e atravessa a Middleware App sem alteração. Termina na Manufacturer Service App instalada naquele dispositivo específico. A resposta volta pelo mesmo caminho.

Por que a camada de middleware existe

Sem um contrato compartilhado, as aplicações dos parceiros da Getnet precisariam de código específico para cada fabricante de POS que quisessem suportar. A Middleware App elimina essa necessidade: chama os mesmos métodos independentemente do dispositivo. Sua Manufacturer Service App é o único lugar onde vive o comportamento específico do dispositivo.

Isso também isola mudanças. A Getnet pode atualizar a Middleware App ou o SDK PagoNxt sem tocar na sua implementação, desde que você siga implementando as interfaces que a libhalservice define. Da mesma forma, você pode mudar como seu dispositivo trata uma leitura de cartão ou um trabalho de impressão. Isso nunca afeta a Middleware App nem qualquer aplicação de parceiro acima dela.

Responsabilidades do seu serviço

Sua Manufacturer Service App é responsável por toda interação com o dispositivo físico: ler cartões, imprimir recibos, acionar o beeper e os LEDs, ler a câmera e reportar estatísticas de uso. A Middleware App nunca acessa o hardware diretamente. Ela só chama as interfaces que seu serviço expõe e espera uma resposta no formato que essas interfaces definem.

A interface EMV segue o mesmo padrão, mas com mais estado. Em vez de uma única chamada e resposta, ela funciona como uma máquina de estados que seu serviço e a Middleware App percorrem juntos. Consulte Máquina de estados EMV para esse fluxo.

Recursos relacionados

• Visão geral de fabricantes POS — onde esta arquitetura se encaixa no processo de homologação.
• Configuração da integração HAL — nome de pacote, interfaces exigidas e o Intent de vinculação.
• Referência de interfaces de serviço — todos os métodos que seu serviço pode implementar.