Subsistema HAL

Esta página descreve o subsistema HAL, incluindo solicitações, o subsistema da câmera, a sequência de inicialização e operação, os níveis de hardware e as interações.

Solicitações

O framework do app emite solicitações de resultados capturados para o subsistema da câmera. Uma solicitação corresponde a um conjunto de resultados. Uma solicitação encapsula todas as informações de configuração sobre a captura e o processamento desses resultados. Isso inclui itens como resolução e formato de pixel; sensor manual, lente e controle de flash; modos de operação 3A; controle de processamento de RAW para YUV; e geração de estatísticas. Isso permite muito mais controle sobre a saída e o processamento dos resultados. Várias solicitações podem estar em andamento ao mesmo tempo, e o envio de solicitações não é bloqueador. E as solicitações são sempre processadas na ordem em que são recebidas.

Figura 1. Modelo da câmera.

HAL e subsistema da câmera

O subsistema da câmera inclui as implementações dos componentes no pipeline da câmera , como o algoritmo 3A e os controles de processamento. O HAL da câmera fornece interfaces para você implementar suas versões desses componentes. Para manter a compatibilidade multiplataforma entre vários fabricantes de dispositivos e fornecedores de processadores de sinal de imagem (ISP, na sigla em inglês, ou sensor de câmera), o modelo de pipeline da câmera é virtual e não corresponde diretamente a nenhum ISP real. No entanto, ele é semelhante o suficiente aos pipelines de processamento reais para que você possa mapeá-lo ao seu hardware com eficiência. Além disso, ele é abstrato o suficiente para permitir vários algoritmos e ordens de operação diferentes sem comprometer a qualidade, a eficiência ou a compatibilidade entre dispositivos.

O pipeline da câmera também oferece suporte a acionadores que o framework do app pode iniciar para ativar itens como o foco automático. Ele também envia notificações de volta ao framework do app, notificando os apps sobre eventos como um bloqueio de foco automático ou erros.

Figura 2. Pipeline da câmera.

Observe que alguns blocos de processamento de imagem mostrados no diagrama acima não estão bem definidos na versão inicial. O pipeline da câmera faz as seguintes suposições:

• A saída RAW Bayer não passa por nenhum processamento dentro do ISP.
• As estatísticas são geradas com base nos dados brutos do sensor.
• Os vários blocos de processamento que convertem dados brutos do sensor em YUV estão em uma ordem arbitrária.
• Embora várias unidades de escala e corte sejam mostradas, todas as unidades de escalonador compartilham os controles da região de saída (zoom digital). No entanto, cada unidade pode ter uma resolução de saída e um formato de pixel diferentes.

Resumo do uso da API

Este é um breve resumo das etapas para usar a API Android Camera. Consulte a seção Sequência de inicialização e operação esperada para uma análise detalhada de estas etapas, incluindo chamadas de API.

1. Detecte e enumere dispositivos de câmera.
2. Abra o dispositivo e conecte listeners.
3. Configure as saídas para o caso de uso de destino (como captura ou gravação de imagens estáticas).
4. Crie solicitações para o caso de uso de destino.
5. Capture/repita solicitações e sequências.
6. Receba metadados de resultados e dados de imagem.
7. Ao mudar os casos de uso, volte à etapa 3.

Resumo da operação HAL

• As solicitações assíncronas de capturas vêm do framework.
• O dispositivo HAL precisa processar as solicitações em ordem. E, para cada solicitação, produza metadados de resultados de saída e um ou mais buffers de imagem de saída.
• FIFO para solicitações e resultados e para streams referenciados por solicitações subsequentes.
• Os carimbos de data/hora precisam ser idênticos para todas as saídas de uma determinada solicitação, para que o framework possa combiná-las, se necessário.
• Toda a configuração e o estado de captura (exceto as rotinas 3A) são encapsulados nas solicitações e nos resultados.

Figura 3. Visão geral do HAL da câmera.

Sequência de inicialização e operação esperada

Esta seção contém uma explicação detalhada das etapas esperadas ao usar a API Camera. Para definições de interface HIDL, consulte platform/hardware/interfaces/camera/.

Enumerar, abrir dispositivos de câmera e criar uma sessão ativa

1. Após a inicialização, o framework começa a detectar todos os provedores de câmera presentes que implementam a ICameraProvider interface. Se um ou mais provedores estiverem presentes, o framework tentará estabelecer uma conexão.
2. O framework enumera os dispositivos de câmera usando ICameraProvider::getCameraIdList.
3. O framework instancia um novo ICameraDevice chamando o ICameraProvider::getCameraDeviceInterface_VX_X correspondente.
4. O framework chama ICameraDevice::open para criar uma nova sessão de captura ativa ICameraDeviceSession.

Usar uma sessão de câmera ativa

1. O framework chama ICameraDeviceSession::configureStreams com uma lista de streams de entrada/saída para o dispositivo HAL.
2. O framework solicita configurações padrão para alguns casos de uso com chamadas para ICameraDeviceSession::constructDefaultRequestSettings. Isso pode ocorrer a qualquer momento depois que o ICameraDeviceSession for criado por ICameraDevice::open.
3. O framework cria e envia a primeira solicitação de captura para o HAL com configurações baseadas em um dos conjuntos de configurações padrão e com pelo menos um stream de saída que foi registrado anteriormente pelo framework. Isso é enviado ao HAL com ICameraDeviceSession::processCaptureRequest. O HAL precisa bloquear o retorno dessa chamada até que esteja pronto para o envio da próxima solicitação.
4. O framework continua enviando solicitações e chama ICameraDeviceSession::constructDefaultRequestSettings para receber buffers de configurações padrão para outros casos de uso, conforme necessário.
5. Quando a captura de uma solicitação começa (o sensor começa a ser exposto para a captura), o HAL chama ICameraDeviceCallback::notify com a mensagem SHUTTER, incluindo o número do frame e o carimbo de data/hora do início da exposição. Esse callback de notificação não precisa ocorrer antes da primeira processCaptureResult chamada para uma solicitação, mas nenhum resultado é entregue a um app para uma captura até que notify para essa captura seja chamado.
6. Após algum atraso no pipeline, o HAL começa a retornar capturas concluídas ao framework com ICameraDeviceCallback::processCaptureResult. Elas são retornadas na mesma ordem em que as solicitações foram enviadas. Várias solicitações podem estar em andamento ao mesmo tempo, dependendo da profundidade do pipeline do dispositivo HAL da câmera.

Depois de algum tempo, uma das seguintes situações ocorre:

• O framework para de enviar novas solicitações, aguarda a conclusão das capturas atuais (todos os buffers preenchidos, todos os resultados retornados) e chama ICameraDeviceSession::configureStreams novamente. Isso redefine o hardware e o pipeline da câmera para um novo conjunto de streams de entrada/saída. Alguns streams podem ser reutilizados da configuração anterior. O framework continua da primeira solicitação de captura para o HAL, se pelo menos um stream de saída registrado permanecer. Caso contrário, ICameraDeviceSession::configureStreams é necessário primeiro.
• O framework pode chamar ICameraDeviceSession::close para encerrar a sessão da câmera. Isso pode ser chamado a qualquer momento em que nenhuma outra chamada do framework esteja ativa, embora a chamada possa ser bloqueada até que todas as capturas em andamento sejam concluídas (todos os resultados retornados, todos os buffers preenchidos). Depois que a chamada close retornar, nenhuma outra chamada para ICameraDeviceCallback será permitida no HAL. Quando a chamada close estiver em andamento, o framework não poderá chamar nenhuma outra função de dispositivo HAL.
• Em caso de erro ou outro evento assíncrono, o HAL precisa chamar ICameraDeviceCallback::notify com a mensagem de erro/evento apropriada. Depois de retornar de uma notificação de erro fatal em todo o dispositivo, o HAL precisa agir como se close tivesse sido chamado nele. No entanto, o HAL precisa cancelar ou concluir todas as capturas pendentes antes de chamar notify, para que, depois que notify for chamado com um erro fatal, o framework não receba mais callbacks do dispositivo. Os métodos diferentes de close precisam retornar -ENODEV ou NULL depois que o método notify retornar de uma mensagem de erro fatal.

Figura 4. Fluxo operacional da câmera.

Níveis de hardware

Os dispositivos de câmera podem implementar vários níveis de hardware, dependendo das funcionalidades. Para mais informações, consulte nível de hardware compatível.

Interação entre a solicitação de captura do app, o controle 3A e o pipeline de processamento

Dependendo das configurações no bloco de controle 3A, o pipeline da câmera ignora alguns dos parâmetros na solicitação de captura do app e usa os valores fornecidos pelas rotinas de controle 3A. Por exemplo, quando a exposição automática está ativa, o tempo de exposição, a duração do frame e os parâmetros de sensibilidade do sensor são controlados pelo algoritmo 3A da plataforma, e todos os valores especificados pelo app são ignorados. Os valores escolhidos para o frame pelas rotinas 3A precisam ser informados nos metadados de saída. A tabela a seguir descreve os diferentes modos do bloco de controle 3A e as propriedades controladas por esses modos. Consulte o arquivo platform/system/media/camera/docs/docs.html para definições dessas propriedades.

Parâmetro	Estado	Propriedades controladas
android.control.aeMode	OFF	Nenhum.
	ON	android.sensor.exposureTime, android.sensor.frameDuration, android.sensor.sensitivity, android.lens.aperture (se compatível) e android.lens.filterDensity (se compatível).
	ON_AUTO_FLASH	Tudo está ON, além de android.flash.firingPower, android.flash.firingTime e android.flash.mode.
	ON_ALWAYS_FLASH	Igual a ON_AUTO_FLASH.
	ON_AUTO_FLASH_RED_EYE	Igual a ON_AUTO_FLASH.
android.control.awbMode	OFF	Nenhum.
	WHITE_BALANCE_*	android.colorCorrection.transform. Ajustes específicos da plataforma se android.colorCorrection.mode for FAST ou HIGH_QUALITY.
android.control.afMode	OFF	Nenhum
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	OFF	Nenhum.
	ON	Pode ajustar android.scaler.cropRegion para implementar a estabilização de vídeo.
android.control.mode	OFF	AE, AWB e AF estão desativados.
	AUTO	As configurações individuais de AE, AWB e AF são usadas.
	SCENE_MODE_*	Pode substituir todos os parâmetros listados acima. Os controles 3A individuais estão desativados.

Os controles no bloco de processamento de imagem na Figura 2 operam em um princípio semelhante, e cada bloco tem três modos:

• OFF: esse bloco de processamento está desativado. Os blocos de ajuste de curva de tom, correção de cor e demosaico não podem ser desativados.
• FAST: nesse modo, o bloco de processamento pode não diminuir a frame rate de saída em comparação com o modo OFF, mas, caso contrário, precisa produzir a saída de melhor qualidade possível, considerando essa restrição. Normalmente, isso seria usado para modos de visualização ou gravação de vídeo ou captura em sequência para imagens estáticas. Em alguns dispositivos, isso pode ser equivalente ao modo OFF (nenhum processamento pode ser feito sem diminuir a frame rate) e, em alguns dispositivos, isso pode ser equivalente ao HIGH_QUALITY (a melhor qualidade ainda não diminui a frame rate).
• HIGH_QUALITY: nesse modo, o bloco de processamento precisa produzir o resultado da melhor qualidade possível, diminuindo a frame rate de saída conforme necessário. Normalmente, isso seria usado para captura de imagens estáticas de alta qualidade. Alguns blocos incluem um controle manual que pode ser selecionado opcionalmente em vez de FAST ou HIGH_QUALITY. Por exemplo, o bloco de correção de cor oferece suporte a uma matriz de transformação de cor, enquanto o ajuste da curva de tom oferece suporte a uma curva de mapeamento de tom global arbitrária.

A frame rate máxima que pode ser compatível com um subsistema de câmera é uma função de muitos fatores:

• Resoluções solicitadas de streams de imagem de saída
• Disponibilidade de modos de binning/pular no imager
• A largura de banda da interface do imager
• A largura de banda dos vários blocos de processamento de ISP

Esses fatores podem variar muito entre diferentes ISPs e sensores. Portanto, a interface HAL da câmera tenta abstrair as restrições de largura de banda em um modelo o mais simples possível. O modelo apresentado tem as seguintes características:

• O sensor de imagem é sempre configurado para gerar a menor resolução possível, considerando os tamanhos de stream de saída solicitados pelo app. A menor resolução é definida como pelo menos tão grande quanto o maior tamanho de stream de saída solicitado.
• Qualquer solicitação pode usar qualquer ou todos os streams de saída configurados no momento, portanto, o sensor e o ISP precisam ser configurados para oferecer suporte ao escalonamento de uma única captura para todos os streams ao mesmo tempo.
• Os streams JPEG agem como streams YUV processados para solicitações em que não estão incluídos. Em solicitações em que são referenciados diretamente, eles atuam como streams JPEG.
• O processador JPEG pode ser executado simultaneamente ao restante do pipeline da câmera, mas não pode processar mais de uma captura por vez.