Suporte à versão da câmera

Esta página detalha as diferenças de versão em Camera HALs, APIs e testes de Compatibility Test Suite (CTS) associados. Ele também abrange várias 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 da câmera no nível do aplicativo em dispositivos Android 4.4 e inferiores, exposta por meio da classe android.hardware.Camera .
API2 da câmera
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 de câmera implementada pelos fornecedores de SoC. As estruturas públicas no nível do aplicativo são construídas sobre o HAL da câmera.
Câmera HAL3.1
Versão do dispositivo de câmera HAL lançado com Android 4.4.
Câmera HAL3.2
Versão do dispositivo de câmera HAL lançado com Android 5.0.
Câmera API1 CTS
Conjunto de testes de câmera CTS que são executados em cima da Camera API1.
Câmera API2 CTS
Conjunto adicional de testes CTS de câmera executados em cima da Camera API2.
Agudo
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 o Treble e usada para especificar a interface entre um HAL e seus usuários.
VTS
Conjunto de testes do fornecedor 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 preteriu a Camera API1, que continua a ser descontinuada à medida que o desenvolvimento da nova plataforma se concentra na Camera API2. No entanto, o período de eliminação gradual será longo e as versões do Android continuarão a oferecer suporte aos 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 inferiores do Android.
  • Versões da câmera HAL. Inclui suporte para Câmera HAL1.0.

API2 da câmera

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

O Android 5.0 e superior inclui Camera API2; no entanto, os dispositivos que executam o Android 5.0 e superior podem não ser compatíveis com 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 para aplicativos por meio das interfaces Camera API2 que são aproximadamente os mesmos recursos daqueles expostos para aplicativos por meio das interfaces Camera API1. O código das estruturas legadas converte conceitualmente as chamadas Camera API2 em chamadas Camera API1; dispositivos legados não são compatíveis com 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 de fluxo de saída adicionais.
  • 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. No entanto, o recurso BACKWARD_COMPATIBLE deve sempre ser definido.

O nível de hardware compatível do dispositivo, bem como os recursos específicos da Camera API2 que ele suporta, estão disponíveis como os seguintes sinalizadores de recursos 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

Os dispositivos com Android 5.0 e superior devem ser aprovados 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 Camera API2 são mapeadas conceitualmente para chamadas Camera API1) para que quaisquer testes de Camera API2 CTS relacionados a recursos ou capacidades além da Camera API1 sejam ignorados automaticamente.

Em dispositivos legados, os testes CTS Camera API2 que são executados usam as interfaces e recursos públicos da Camera API1 existentes sem novos requisitos. Os bugs que são expostos (e que causam uma falha no 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, esses bugs devem ser corrigidos para passar nos testes Camera API2 CTS).

Requisitos VTS

Os dispositivos que executam o Android 8.0 e superior com implementações de HAL vinculadas devem ser aprovados nos testes do Camera VTS .

Endurecimento da estrutura da câmera

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

Mudanças de arquitetura para API1

A gravação de vídeo API1 pode assumir a câmera e o codificador de vídeo ao vivo 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 e pilha de mídia do Android 7.0 na API1 no HAL3

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

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

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

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

Mudanças de arquitetura para API2

Para API2 em HAL1 ou HAL3, BufferQueue passa buffers para que esses caminhos continuem funcionando. A arquitetura do 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 e pilha de mídia do Android 7.0 na API2 no HAL3

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

Requisitos adicionais

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

  • Em geral. Os dispositivos requerem largura de banda adicional devido ao IPC, o que pode afetar casos de uso de câmera sensíveis ao tempo, 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 de 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 armazena metadados em vez de dados de quadro YUV reais em buffers de vídeo, o HAL deve usar kMetadataBufferTypeNativeHandleSource como o tipo de buffer de metadados e passar VideoNativeHandleMetadata em buffers de vídeo. ( kMetadataBufferTypeCameraSource não é mais compatível com o Android 7.0.) Com VideoNativeHandleMetadata , as estruturas de câmera e mídia podem passar os buffers de vídeo entre processos serializando e desserializando os identificadores nativos corretamente.
  • O endereço do identificador de 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 retorna 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 do SELinux para o servidor de câmeras. Se as políticas SELinux específicas do dispositivo derem permissões ao servidor de mídia para executar a câmera, você deverá atualizar as políticas do SELinux para conceder as permissões adequadas ao servidor de câmeras. Desencorajamos a replicação das políticas SELinux do servidor de mídia para o servidor de câmeras (já que o servidor de mídia e o servidor de câmeras geralmente exigem 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. Além disso, o Android 8.0 e superior separam o Camera HAL encadernado em um processo diferente do servidor de câmeras. 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 as alterações do serviço de câmera, os testes CTS existentes falham 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 Android Camera HAL, consulte a Lista de verificação de teste do Camera HAL .

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 de câmera estática para um ID de câmera física que suporta um dispositivo de câmera lógico. Consulte Suporte a várias câmeras .
  • isStreamCombinationSupported : esse 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âmetro 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 a câmera HAL 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 para o 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 a câmera HAL para retornar buffers de saída para o servidor da câmera. Consulte returnStreamBuffers .

3.4

As seguintes chaves são 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 da 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 que os dispositivos notifiquem o HAL da câmera quando alterações físicas, como dobrar, afetarem a câmera e o roteamento.

2.4

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

Android 9

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

API da câmera

  • Apresenta a API multicâmera para oferecer melhor suporte a dispositivos com várias câmeras voltadas para a mesma direção, permitindo recursos como bokeh e zoom contínuo. Isso permite que os aplicativos visualizem várias 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 englobados por uma câmera lógica. Consulte Suporte a várias câmeras .
  • Introduz 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 atrasos de processamento graves quando modificados. Esses custos podem ser mitigados se os clientes passarem 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 efeitos e estabilização no nível do 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 .
  • 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 compatíveis. Consulte INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL .

Câmera HAL

3.4

Atualizações para ICameraDeviceSession

Atualizações para ICameraDeviceCallback

3.3

As seguintes chaves são 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 de Camera HAL do fornecedor devem ser encadernadas . O Android 8.0 também contém estes aprimoramentos importantes para o serviço Câmera:

  • Superfícies compartilhadas: ative várias superfícies compartilhando o mesmo 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 gere 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 de HAL de câmera e HAL de gralloc possam criar buffers de 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 do 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 de câmera pública define dois modos de operação: gravação de alta velocidade normal e restrita. Eles têm uma semântica bastante diferente; por exemplo, o modo de alta velocidade é limitado a no máximo duas saídas específicas de uma só vez. Vários OEMs manifestaram interesse em definir outros modos personalizados para recursos específicos de hardware. Sob o capô, o modo é apenas um número inteiro passado para configure_streams . Consulte: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

Esse recurso inclui uma chamada de API do sistema que os aplicativos de câmera OEM podem usar para habilitar 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 HAL, acionado por esse número inteiro passado para o HAL em configure_streams e, em seguida, fazer com que seu aplicativo de câmera personalizado use a API do sistema.

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

onCaptureQueueEmpty

O objetivo dessa 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 proveito disso precisam adicionar um ouvinte a esse retorno de chamada e responder adequadamente. Geralmente, isso é feito 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 definidas por HIDL estáveis. Todos os recursos e capacidades de câmera introduzidos nas versões legadas mais recentes 3.4 e 2.4 (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 no suporte data_space:

  • Adicione metadados estáticos ANDROID_SENSOR_OPAQUE_RAW_SIZE como obrigatório se o formato RAW_OPAQUE for suportado.
  • Adicione metadados estáticos ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE como obrigatório se qualquer formato RAW for suportado.
  • Alterne o campo camera3_stream_t data_space para uma definição mais flexível, usando a definição da versão 0 da codificação do espaço de dados.
  • Adições gerais de metadados que estão disponíveis para uso para 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

Pequena revisão 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 de campo de rotação para camera3_stream_t .
  • Adição do modo de operação de configuração de stream camera3 ao camera3_stream_configuration_t .

3.2

Pequena revisão do HAL de capacidade expandida:

  • get_metadata_vendor_tag_ops . Em vez disso, use get_vendor_tag_ops em camera_common.h .
  • Desaprova register_stream_buffers . Todos os buffers gralloc fornecidos pelo framework 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 o modelo manual ao camera3_request_template . Os aplicativos podem usar este modelo para controlar diretamente as configurações de captura.
  • Reformule as especificações bidirecionais e de fluxo 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

Pequena revisão do HAL de capacidade expandida:

  • configure_streams passa sinalizadores de uso do consumidor para o HAL.
  • flush call 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:

  • Grande mudança de versão, pois a ABI é completamente diferente. Nenhuma alteração nos recursos de hardware necessários ou no modelo operacional de 2.0.
  • Interfaces de fila de fluxo e solicitação de entrada retrabalhadas: Chamadas de estrutura para HAL com a próxima solicitação e buffers de fluxo já desenfileirados. O suporte da estrutura de sincronização está incluído, necessário para implementações eficientes.
  • Movimentamos gatilhos para solicitações, a maioria das notificações para resultados.
  • Consolidou todos os retornos de chamada no framework em uma estrutura e todos os métodos de configuração em uma única chamada initialize() .
  • Configuração de stream feita em uma única chamada para simplificar o gerenciamento de stream. 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 de capacidade expandida (Android 4.2) [camera2.h]:

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

1,0

Câmera inicial do Android HAL (Android 4.0) [camera.h]:

  • Convertido da camada de abstração C++ CameraHardwareInterface.
  • Suporta a 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 para o 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 de tocha. A estrutura pode ativar o modo de tocha para qualquer dispositivo de câmera que tenha uma unidade de flash, sem abrir um dispositivo de câmera. O dispositivo da câmera tem uma prioridade mais alta 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 através 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 de tocha que o modo de tocha foi desativado.
  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 externas hot-plug. As chamadas para obter informações estáticas são chamadas inválidas quando o status da câmera não é CAMERA_DEVICE_STATUS_PRESENT . A estrutura conta apenas com retornos de chamada de alteração 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 depois que o módulo HAL é 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 herdada aberta. A estrutura pode usá-lo para abrir o dispositivo da câmera como dispositivo HAL da versão HAL do dispositivo inferior se o mesmo dispositivo puder oferecer suporte a várias versões da API do dispositivo. A chamada aberta do módulo de hardware padrão ( common.methods->open ) continua a abrir o dispositivo da câmera com a última versão suportada, 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 tag 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 da 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 da câmera. Módulos que fornecem um método set_callbacks() válido devem informar pelo menos este número de versão.

2,0

Os módulos de câmera que relatam este 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 é 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 do módulo de câmera inicial. Todos os dispositivos de câmera que podem ser abertos através 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. Apenas a API android.hardware.Camera pode ser suportada por este módulo e seus dispositivos.