# 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](/pt/pos-manufacturers/core-concept-pos-mfg/emv-state-machine) para esse fluxo.

## Recursos relacionados

* [Visão geral de fabricantes POS](/pt/pos-manufacturers/pos-manufacturers-overview) — onde esta arquitetura se encaixa no processo de homologação.
* [Configuração da integração HAL](/pt/pos-manufacturers/first-steps-pos-mfg/hal-integration-setup) — nome de pacote, interfaces exigidas e o Intent de vinculação.
* [Referência de interfaces de serviço](/pt/pos-manufacturers/reference-pos-mfg/service-interfaces) — todos os métodos que seu serviço pode implementar.