Suporte à versão da câmera

Esta página detalha as diferenças de versão em HALs de câmera, APIs e testes associados do Compatibility Test Suite (CTS) . Ele também aborda diversas alterações arquitetônicas feitas para fortalecer e proteger a estrutura da câmera no Android 7.0, a mudança para o Treble no Android 8.0 e as atualizações que os fornecedores devem fazer para oferecer suporte a essas alterações em suas implementações de câmera.

Terminologia

Os seguintes termos são usados ​​nesta página:

API da câmera1
A estrutura de câmera no nível do aplicativo em dispositivos Android 4.4 e anteriores, exposta por meio da classe android.hardware.Camera .
API da câmera2
A estrutura da câmera no nível do aplicativo em dispositivos Android 5.0 e superiores, exposta por meio do pacote android.hardware.camera2 .
Câmera HAL
A camada do módulo da câmera implementada pelos fornecedores de SoC. As estruturas públicas em nível de aplicativo são construídas sobre o HAL da câmera.
Câmera HAL3.1
Versão do dispositivo de câmera HAL lançada com Android 4.4.
Câmera HAL3.2
Versão do dispositivo de câmera HAL lançada com Android 5.0.
Câmera API1 CTS
Conjunto de testes CTS de câmera executados na API1 da câmera.
Câmera API2 CTS
Conjunto adicional de testes CTS de câmera que são executados na Camera API2.
Agudos
Separa a implementação do fornecedor (software de nível inferior específico do dispositivo escrito por fabricantes de silício) da estrutura do sistema operacional Android por meio de uma nova interface do fornecedor.
HIDL
Linguagem de definição de interface HAL introduzida com Treble e usada para especificar a interface entre um HAL e seus usuários.
VTS
Conjunto de testes de fornecedores introduzido junto com o Treble.

APIs de câmera

O Android inclui as seguintes APIs de câmera.

API da câmera1

O Android 5.0 descontinuado Camera API1, que continua a ser descontinuado à medida que o desenvolvimento da nova plataforma se concentra na Camera API2. No entanto, o período de eliminação será longo e as versões do Android continuarão a oferecer suporte a aplicativos Camera API1 por algum tempo. Especificamente, o suporte continua para:

  • Interfaces API1 da câmera para aplicativos. Os aplicativos de câmera criados com base na Camera API1 devem funcionar como em dispositivos que executam versões anteriores do Android.
  • Versões HAL da câmera. Inclui suporte para câmera HAL1.0.

API da câmera2

A estrutura Camera API2 expõe o controle de câmera de nível inferior ao aplicativo, incluindo fluxos eficientes de burst/streaming de cópia zero e controles por quadro de exposição, ganho, ganhos de equilíbrio de branco, conversão de cores, remoção de ruído, nitidez e muito mais. Para obter detalhes, assista ao vídeo de visão geral do Google I/O .

Android 5.0 e superior inclui Camera API2; no entanto, os dispositivos que executam o Android 5.0 e superior podem não suportar todos os recursos da Camera API2. A propriedade android.info.supportedHardwareLevel que os aplicativos podem consultar por meio das interfaces Camera API2 relata um dos seguintes níveis de suporte:

  • LEGACY : esses dispositivos expõem recursos aos aplicativos por meio das interfaces Camera API2 que são aproximadamente os mesmos recursos expostos aos aplicativos por meio das interfaces Camera API1. O código da estrutura legada traduz conceitualmente chamadas de Camera API2 em chamadas de Camera API1; dispositivos legados não suportam recursos da Camera API2, como controles por quadro.
  • LIMITED : esses dispositivos suportam alguns recursos da Camera API2 (mas não todos) e devem usar o Camera HAL 3.2 ou superior.
  • FULL : Esses dispositivos suportam todos os principais recursos da Camera API2 e devem usar Camera HAL 3.2 ou superior e Android 5.0 ou superior.
  • LEVEL_3 : Esses dispositivos suportam reprocessamento YUV e captura de imagem RAW, juntamente com configurações adicionais de fluxo de saída.
  • EXTERNAL : Esses dispositivos são semelhantes aos dispositivos LIMITED , com algumas exceções; por exemplo, algumas informações do sensor ou da lente podem não ser relatadas ou ter taxas de quadros menos estáveis. Este nível é usado para câmeras externas, como webcams USB.

Os recursos individuais são expostos por meio da propriedade android.request.availableCapabilities nas interfaces Camera API2. Dispositivos FULL requerem os recursos MANUAL_SENSOR e MANUAL_POST_PROCESSING , entre outros. A capacidade RAW é opcional mesmo para dispositivos FULL . Dispositivos LIMITED podem anunciar qualquer subconjunto desses recursos, incluindo nenhum deles. Entretanto, o recurso BACKWARD_COMPATIBLE sempre deve ser definido.

O nível de hardware compatível do dispositivo, bem como os recursos específicos da Camera API2 compatíveis, estão disponíveis como os sinalizadores de recurso a seguir para permitir a filtragem do Google Play de aplicativos de câmera Camera API2.

  • android.hardware.camera.hardware_level.full
  • android.hardware.camera.capability.raw
  • android.hardware.camera.capability.manual_sensor
  • android.hardware.camera.capability.manual_post_processing

Requisitos CTS

Dispositivos com Android 5.0 e superior devem passar nos testes de câmera Camera API1 CTS, Camera API2 CTS e CTS Verifier.

Os dispositivos que não apresentam uma implementação Camera HAL3.2 e não são capazes de suportar as interfaces completas da Camera API2 ainda devem passar nos testes Camera API2 CTS. No entanto, o dispositivo é executado no modo Camera API2 LEGACY (no qual as chamadas da Camera API2 são mapeadas conceitualmente para chamadas da Camera API1), portanto, quaisquer testes CTS da Camera API2 relacionados a recursos ou capacidades além da Camera API1 são automaticamente ignorados.

Em dispositivos legados, os testes Camera API2 CTS executados usam as interfaces e recursos públicos existentes da Camera API1 sem novos requisitos. Os bugs expostos (e que causam uma falha do Camera API2 CTS) são bugs já presentes no Camera HAL existente do dispositivo e, portanto, seriam encontrados pelos aplicativos Camera API1 existentes. Não esperamos muitos bugs dessa natureza (no entanto, quaisquer bugs devem ser corrigidos para passar nos testes Camera API2 CTS).

Requisitos VTS

Dispositivos que executam Android 8.0 e superior com implementações HAL vinculadas devem passar nos testes Camera VTS .

Endurecimento da estrutura da câmera

Para fortalecer a segurança da estrutura de mídia e câmera, o Android 7.0 remove o serviço de câmera do mediaserver. A partir do Android 8.0, cada HAL de câmera vinculado é executado em um processo separado do serviço de câmera. Os fornecedores podem precisar fazer alterações no HAL da câmera dependendo da API e das versões do HAL em uso. As seções a seguir detalham as alterações arquitetônicas no AP1 e AP2 para HAL1 e HAL3, bem como os requisitos gerais.

Mudanças arquitetônicas para API1

A gravação de vídeo API1 pode assumir que a câmera e o codificador de vídeo estão ativos no mesmo processo. Ao usar API1 em:

  • HAL3, onde o serviço de câmera usa BufferQueue para passar buffers entre processos, nenhuma atualização do fornecedor é necessária.

    Câmera Android 7.0 e pilha de mídia na API1 em HAL3

    Figura 1. Câmera e pilha de mídia do Android 7.0 na API1 no HAL3

  • HAL1, que suporta a passagem de metadados em buffers de vídeo, os fornecedores devem atualizar o HAL para usar kMetadataBufferTypeNativeHandleSource . ( kMetadataBufferTypeCameraSource não é mais compatível com Android 7.0.)

    Câmera Android 7.0 e pilha de mídia na API1 em HAL1

    Figura 2. Câmera e pilha de mídia do Android 7.0 na API1 em HAL1

Mudanças arquitetônicas para API2

Para API2 em HAL1 ou HAL3, BufferQueue passa buffers para que esses caminhos continuem funcionando. A arquitetura Android 7.0 para API2 em:

  • O HAL1 não é afetado pela mudança do serviço de câmera e nenhuma atualização do fornecedor é necessária.
  • HAL3 é afetado, mas nenhuma atualização do fornecedor é necessária:

    Câmera Android 7.0 e pilha de mídia em API2 em HAL3

    Figura 3. Câmera e pilha de mídia do Android 7.0 em API2 em HAL3

Requisitos adicionais

As alterações arquitetônicas feitas para fortalecer a segurança da mídia e da estrutura da câmera incluem os seguintes requisitos adicionais de dispositivo.

  • Em geral. Os dispositivos exigem largura de banda adicional devido ao IPC, o que pode afetar casos de uso de câmeras urgentes, como gravação de vídeo em alta velocidade. Os fornecedores podem medir o impacto real executando android.hardware.camera2.cts.PerformanceTest e o aplicativo Google Camera para gravação de vídeo em alta velocidade de 120/240 FPS. Os dispositivos também requerem uma pequena quantidade de RAM adicional para criar o novo processo.
  • Passe metadados em buffers de vídeo ( somente HAL1 ). Se HAL1 armazenar metadados em vez de dados de quadro YUV reais em buffers de vídeo, o HAL deverá usar kMetadataBufferTypeNativeHandleSource como o tipo de buffer de metadados e passar VideoNativeHandleMetadata em buffers de vídeo. ( kMetadataBufferTypeCameraSource não é mais compatível com Android 7.0.) Com VideoNativeHandleMetadata , as estruturas de câmera e mídia são capazes de passar os buffers de vídeo entre processos serializando e desserializando os identificadores nativos corretamente.
  • O endereço do identificador do buffer nem sempre armazena o mesmo buffer ( somente HAL3 ). Para cada solicitação de captura, o HAL3 obtém endereços de identificadores de buffer. HAL não pode usar os endereços para identificar buffers porque os endereços podem armazenar outro identificador de buffer depois que HAL retornar o buffer. Você deve atualizar o HAL para usar identificadores de buffer para identificar os buffers. Por exemplo, HAL recebe um endereço de identificador de buffer A, que armazena o identificador de buffer A. Depois que HAL retorna o identificador de buffer A, o endereço de identificador de buffer A pode armazenar o identificador de buffer B na próxima vez que o HAL o receber.
  • Atualize as políticas SELinux para cameraserver. Se as políticas SELinux específicas do dispositivo concederem permissões ao mediaserver para executar a câmera, você deverá atualizar as políticas SELinux para conceder permissões adequadas ao cameraserver. Desencorajamos a replicação das políticas SELinux do mediaserver para cameraserver (já que mediaserver e cameraserver geralmente requerem recursos diferentes no sistema). O Cameraserver deve ter apenas as permissões necessárias para executar as funcionalidades da câmera e quaisquer permissões desnecessárias relacionadas à câmera no mediaserver devem ser removidas.
  • Separação entre Camera HAL e cameraserver. O Android 8.0 e superior separam adicionalmente o Camera HAL vinculado em um processo diferente do cameraserver. O IPC passa por interfaces definidas por HIDL .

Validação

Para todos os dispositivos que incluem uma câmera e executam o Android 7.0, verifique a implementação executando o Android 7.0 CTS. Embora o Android 7.0 não inclua novos testes CTS que verificam alterações no serviço de câmera, os testes CTS existentes falharão se você não tiver feito as atualizações indicadas acima.

Para todos os dispositivos que incluem uma câmera e executam o Android 8.0 e superior, verifique a implementação do fornecedor executando o VTS.

Histórico de versões da câmera HAL

Para obter uma lista de testes disponíveis para avaliar o HAL da câmera do Android, consulte Lista de verificação de testes do HAL da câmera .

Android 10

O Android 10 apresenta as seguintes atualizações.

API da câmera

Câmera HAL

As seguintes versões do Camera HAL são atualizadas no Android 10.

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics : as informações estáticas da câmera para um ID de câmera física que suporta um dispositivo de câmera lógica. Consulte Suporte para múltiplas câmeras .
  • isStreamCombinationSupported : este método oferece suporte a uma API pública que ajuda os clientes a consultar se uma configuração de sessão é compatível. Consulte API para consultar combinações de fluxo .

ICameraDeviceSession

  • isReconfigurationNeeded : Método que informa à estrutura da câmera se a reconfiguração completa do fluxo é necessária para possíveis novos valores de parâmetros de sessão. Isso ajuda a evitar atrasos desnecessários na reconfiguração da câmera. Consulte Consulta de reconfiguração de sessão .
  • APIs de gerenciamento de buffer HAL : essas APIs permitem que o HAL da câmera solicite buffers da estrutura da câmera somente quando necessário, em vez de acoplar cada solicitação de captura com seus buffers associados em todo o pipeline da câmera, resultando em economias de memória potencialmente significativas.
    • signalStreamFlush : sinaliza ao HAL que o serviço de câmera está prestes a executar configureStreams_3_5 e que o HAL deve retornar todos os buffers dos fluxos designados.
    • configureStreams_3_5 : semelhante a ICameraDevice3.4.configureStreams , mas além disso, o contador streamConfigCounter é fornecido para verificar uma condição de corrida entre as chamadas configureStreams_3_5 e signalStreamFlush .

Atualizações para ICameraDeviceCallback :

  • requestStreamBuffers : retorno de chamada síncrono que o HAL da câmera chama para solicitar buffers ao servidor da câmera. Consulte requestStreamBuffers .
  • returnStreamBuffers : retorno de chamada síncrono para o HAL da câmera para retornar buffers de saída para o servidor da câmera. Consulte returnStreamBuffers .

3.4

As chaves a seguir foram adicionadas aos metadados da câmera no Android 10.

  • Formatos de imagem
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • Tags de metadados da câmera
    • ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSION
    • ANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONS
    • ANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAP
    • ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION
    • ANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONS
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONS
    • ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS
    • ANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONS
    • ANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONS
    • ANDROID_HEIC_INFO_SUPPORTED
    • ANDROID_HEIC_INFO_MAX_JPEG_APP_SEGMENTS_COUNT
  • Capacidades
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • Valores para a chave ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Configurações de fluxo de profundidade dinâmica disponíveis
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Configurações de fluxo HEIC disponíveis
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Módulo de câmera

As seguintes versões do módulo de câmera são atualizadas no Android 10.

2,5

  • Adiciona o método notifyDeviceStateChange para dispositivos notificarem o HAL da câmera quando alterações físicas, como dobramento, afetarem a câmera e o roteamento.

2.4

  • Dispositivos iniciados com API de nível 29 ou superior DEVEM ser true para isTorchModeSupported .

Android 9

A versão do Android 9 apresenta as seguintes atualizações na API2 da câmera e na interface HAL.

API da câmera

  • Apresenta a API multicâmera para melhor suporte a dispositivos com múltiplas câmeras voltadas na mesma direção, habilitando recursos como bokeh e zoom contínuo. Isso permite que os aplicativos visualizem diversas câmeras em um dispositivo como uma unidade lógica (câmera lógica). As solicitações de captura também podem ser enviadas para dispositivos de câmera individuais abrangidos por uma câmera lógica. Consulte Suporte para múltiplas câmeras .
  • Apresenta parâmetros de sessão. Os parâmetros de sessão são um subconjunto dos parâmetros de captura disponíveis que podem causar graves atrasos no processamento quando modificados. Estes custos podem ser atenuados se os clientes passarem os seus valores iniciais durante a inicialização da sessão de captura. Consulte Parâmetros de Sessão .
  • Adiciona chaves de dados de estabilização óptica (OIS) para estabilização e efeitos em nível de aplicativo. Consulte STATISTICS_OIS_SAMPLES .
  • Adiciona suporte a flash externo. Consulte CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
  • Adiciona uma intenção de rastreamento de movimento em CAPTURE_INTENT . Consulte CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • Descontinua LENS_RADIAL_DISTORTION e adiciona LENS_DISTORTION em seu lugar.
  • Adiciona modos de correção de distorção no CaptureRequest . Consulte DISTORTION_CORRECTION_MODE .
  • Adiciona suporte para câmeras USB/UVC externas em dispositivos suportados. Consulte INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL .

Câmera HAL

3.4

Atualizações para ICameraDeviceSession

Atualizações para ICameraDeviceCallback

3.3

As chaves a seguir foram adicionadas aos metadados da câmera no Android 9.

  • Capacidades
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Tags de metadados da câmera
    • ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
    • ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE
    • ANDROID_DISTORTION_CORRECTION_AVAILABLE_MODES
    • ANDROID_LENS_POSE_REFERENCE
    • ANDROID_LENS_DISTORTION
    • ANDROID_REQUEST_AVAILABLE_SESSION_KEYS
    • ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS
    • ANDROID_STATISTICS_OIS_DATA_MODE
    • ANDROID_STATISTICS_OIS_TIMESTAMPS
    • ANDROID_STATISTICS_OIS_X_SHIFTS
    • ANDROID_STATISTICS_OIS_Y_SHIFTS

Android 8.0

A versão Android 8.0 apresenta o Treble. Com o Treble, as implementações HAL da câmera do fornecedor devem ser vinculadas . O Android 8.0 também contém estas melhorias importantes no serviço Câmera:

  • Superfícies compartilhadas: habilite várias superfícies compartilhando a mesma OutputConfiguration
  • API do sistema para modos de câmera personalizados
  • onCaptureQueueEmpty

Consulte as seções abaixo para obter mais informações sobre esses recursos.

Superfícies compartilhadas

Esse recurso permite que apenas um conjunto de buffers acione duas saídas, como visualização e codificação de vídeo, o que reduz o consumo de energia e memória. Para oferecer suporte a esse recurso, os fabricantes de dispositivos precisam garantir que suas implementações HAL de câmera e HAL gralloc possam criar buffers gralloc que são usados ​​por vários consumidores diferentes (como o compositor/GPU de hardware e o codificador de vídeo), em vez de apenas um consumidor. O serviço de câmera passa os sinalizadores de uso do consumidor para o HAL da câmera e o HAL gralloc; eles precisam alocar os tipos corretos de buffers ou o HAL da câmera precisa retornar um erro informando que essa combinação de consumidores não é suportada.

Consulte a documentação do desenvolvedor enableSurfaceSharing para obter detalhes adicionais.

API do sistema para modos de câmera personalizados

A API da câmera pública define dois modos de operação: gravação normal e restrita em alta velocidade. Eles têm semânticas bastante diferentes; por exemplo, o modo de alta velocidade é limitado a no máximo duas saídas específicas ao mesmo tempo. Vários OEMs manifestaram interesse em definir outros modos personalizados para recursos específicos de hardware. Nos bastidores, o modo é apenas um número inteiro passado para configure_streams . Consulte: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

Este recurso inclui uma chamada de API do sistema que os aplicativos de câmera OEM podem usar para ativar um modo personalizado. Esses modos devem começar no valor inteiro 0x8000 para evitar conflitos com modos futuros adicionados à API pública.

Para oferecer suporte a esse recurso, os OEMs precisam apenas adicionar o novo modo ao seu HAL, acionado por esse número inteiro passado ao HAL em configure_streams, e então fazer com que seu aplicativo de câmera personalizado use a API do sistema.

O nome do método é android.hardware.camera2.CameraDevice#createCustomCaptureSession . Veja: frameworks/base/core/java/android/hardware/camera2/CameraDevice .

onCaptureQueueEmpty

O objetivo desta API é reduzir a latência de alterações de controle como zoom, mantendo a fila de solicitações o mais vazia possível. onCaptureQueueEmpty não requer trabalho HAL; foi puramente uma adição do lado da estrutura. Os aplicativos que desejam tirar vantagem disso precisam adicionar um ouvinte a esse retorno de chamada e responder adequadamente. Geralmente isso ocorre enviando outra solicitação de captura para o dispositivo da câmera.

Interface HIDL da câmera

A interface Camera HIDL é uma revisão completa da interface Camera HAL que usa APIs estáveis ​​definidas por HIDL. Todos os recursos e capacidades de câmera introduzidos nas versões legadas 3.4 e 2.4 mais recentes (para o módulo de câmera) também fazem parte das definições HIDL.

3.4

Pequenas adições aos metadados suportados e alterações ao suporte data_space:

  • Adicione metadados estáticos ANDROID_SENSOR_OPAQUE_RAW_SIZE como obrigatório se o formato RAW_OPAQUE for compatível.
  • Adicione metadados estáticos ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE como obrigatórios se qualquer formato RAW for compatível.
  • Mude o campo camera3_stream_t data_space para uma definição mais flexível, usando a definição da versão 0 de codificação de espaço de dados.
  • Adições gerais de metadados que estão disponíveis para uso no HALv3.2 ou mais recente:
    • ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
    • ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
    • ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
    • ANDROID_SENSOR_OPAQUE_RAW_SIZE
    • ANDROID_SENSOR_OPTICAL_BLACK_REGIONS

3.3

Revisão secundária do HAL de capacidade expandida:

  • Atualizações da API de reprocessamento OPAQUE e YUV.
  • Suporte básico para buffers de saída de profundidade.
  • Adição do campo data_space a camera3_stream_t .
  • Adição do campo de rotação a camera3_stream_t .
  • Adição do modo de operação de configuração de stream camera3 a camera3_stream_configuration_t .

3.2

Revisão secundária do HAL de capacidade expandida:

  • Descontinua get_metadata_vendor_tag_ops . Use get_vendor_tag_ops em camera_common.h .
  • Obsoleto register_stream_buffers . Todos os buffers gralloc fornecidos pela estrutura para HAL em process_capture_request podem ser novos a qualquer momento.
  • Adicione suporte a resultados parciais. process_capture_result pode ser chamado várias vezes com um subconjunto dos resultados disponíveis antes que o resultado completo esteja disponível.
  • Adicione modelo manual a camera3_request_template . Os aplicativos podem usar esse modelo para controlar diretamente as configurações de captura.
  • Retrabalhe as especificações do fluxo bidirecional e de entrada.
  • Altere o caminho de retorno do buffer de entrada. O buffer é retornado em process_capture_result em vez de process_capture_request .

3.1

Revisão secundária do HAL de capacidade expandida:

  • configure_streams passa sinalizadores de uso do consumidor para o HAL.
  • chamada flush para descartar todas as solicitações/buffers em andamento o mais rápido possível.

3,0

Primeira revisão do HAL de capacidade expandida:

  • Mudança importante de versão, já que a ABI é completamente diferente. Nenhuma alteração nos recursos de hardware necessários ou no modelo operacional da versão 2.0.
  • Interfaces de solicitação de entrada e fila de fluxo reformuladas: Chamadas de estrutura para HAL com a próxima solicitação e buffers de fluxo já retirados da fila. O suporte à estrutura de sincronização está incluído, necessário para implementações eficientes.
  • Gatilhos movidos para solicitações, a maioria das notificações para resultados.
  • Consolidou todos os retornos de chamada na estrutura em uma estrutura e todos os métodos de configuração em uma única chamada initialize() .
  • Configuração de stream transformada em uma única chamada para simplificar o gerenciamento de stream. Os fluxos bidirecionais substituem a construção STREAM_FROM_STREAM .
  • Semântica de modo limitado para dispositivos de hardware mais antigos/limitados.

2,0

Lançamento inicial do HAL com capacidade expandida (Android 4.2) [camera2.h]:

  • Suficiente para implementar a API android.hardware.Camera existente.
  • Permite fila ZSL na camada de serviço de câmera.
  • Não testado para novos recursos, como controle de captura manual, captura Bayer RAW, reprocessamento de dados RAW, etc.

1,0

HAL inicial da câmera Android (Android 4.0) [camera.h]:

  • Convertido da camada de abstração C++ CameraHardwareInterface.
  • Suporta API android.hardware.Camera .

Histórico de versões do módulo da câmera

Esta seção contém informações de versão do módulo de hardware da câmera, com base em camera_module_t.common.module_api_version . Os dois dígitos hexadecimais mais significativos representam a versão principal e os dois menos significativos representam a versão secundária.

2.4

Esta versão do módulo de câmera adiciona as seguintes alterações de API:

  1. Suporte ao modo tocha. A estrutura pode ativar o modo tocha para qualquer dispositivo de câmera que possua uma unidade de flash, sem abrir um dispositivo de câmera. O dispositivo da câmera tem maior prioridade de acesso à unidade de flash do que ao módulo da câmera; abrir um dispositivo de câmera desliga a tocha se ela tiver sido habilitada por meio da interface do módulo. Quando há algum conflito de recursos, como open() é chamado para abrir um dispositivo de câmera, o módulo HAL da câmera deve notificar a estrutura por meio do retorno de chamada de status do modo tocha de que o modo tocha foi desligado.
  2. Suporte para câmera externa (por exemplo, câmera hot-plug USB). As atualizações da API especificam que as informações estáticas da câmera estão disponíveis somente quando a câmera está conectada e pronta para uso em câmeras hot-plug externas. As chamadas para obter informações estáticas são inválidas quando o status da câmera não é CAMERA_DEVICE_STATUS_PRESENT . A estrutura conta apenas com callbacks de mudança de status do dispositivo para gerenciar a lista de câmeras externas disponíveis.
  3. Dicas de arbitragem da câmera. Adiciona suporte para indicar explicitamente o número de dispositivos de câmera que podem ser abertos e usados ​​simultaneamente. Para especificar combinações válidas de dispositivos, os campos resource_cost e conflicting_devices devem sempre ser definidos na estrutura camera_info retornada pela chamada get_camera_info .
  4. Método de inicialização do módulo. Chamado pelo serviço de câmera após o módulo HAL ser carregado para permitir a inicialização única do HAL. Ele é chamado antes de qualquer outro método de módulo ser invocado.

2.3

Esta versão do módulo de câmera adiciona suporte a dispositivos HAL de câmera legada aberta. A estrutura pode usá-lo para abrir o dispositivo de câmera como dispositivo HAL de versão HAL de dispositivo inferior se o mesmo dispositivo puder suportar várias versões de API de dispositivo. A chamada aberta do módulo de hardware padrão ( common.methods->open ) continua a abrir o dispositivo de câmera com a versão suportada mais recente, que também é a versão listada em camera_info_t.device_version .

2.2

Esta versão do módulo de câmera adiciona suporte a tags de fornecedor do módulo e descontinua o antigo vendor_tag_query_ops que anteriormente só era acessível com um dispositivo aberto.

2.1

Esta versão do módulo de câmera adiciona suporte para retornos de chamada assíncronos à estrutura do módulo HAL da câmera, que é usado para notificar a estrutura sobre alterações no estado do módulo de câmera. Módulos que fornecem um método set_callbacks() válido devem relatar pelo menos este número de versão.

2,0

Os módulos de câmera que relatam esse número de versão implementam a segunda versão da interface HAL do módulo de câmera. Os dispositivos de câmera que podem ser abertos por meio deste módulo podem suportar a versão 1.0 ou a versão 2.0 da interface HAL do dispositivo de câmera. O campo device_version de camera_info é sempre válido; o campo static_camera_characteristics de camera_info será válido se o campo device_version for 2.0 ou superior.

1,0

Os módulos de câmera que relatam esses números de versão implementam a interface HAL inicial do módulo de câmera. Todos os dispositivos de câmera que podem ser abertos por meio deste módulo suportam apenas a versão 1 do dispositivo de câmera HAL. Os campos device_version e static_camera_characteristics de camera_info não são válidos. Somente a API android.hardware.Camera pode ser suportada por este módulo e seus dispositivos.