O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Suporte da versão da câmera

Esta página detalha as diferenças de versão nos HALs da câmera, APIs e testes associados do Compatibility Test Suite (CTS) . Ele também abrange várias alterações arquiteturais feitas para proteger e proteger a estrutura da câmera no Android 7.0, a mudança para o Treble no Android 8.0 e os fornecedores de atualizações que devem fazer para suportar essas alterações nas implementações da câmera.

Terminologia

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

API1 da câmera
A estrutura da câmera no nível do aplicativo no Android 4.4 e dispositivos inferiores, exposta pela classe android.hardware.Camera .
API2 da câmera
A estrutura da câmera no nível do aplicativo nos dispositivos Android 5.0 e superiores, expostos pelo pacote android.hardware.camera2 .
Camera HAL
A camada do módulo da câmera implementada pelos fornecedores de SoC. As estruturas públicas no nível do aplicativo são construídas sobre a câmera HAL.
Camera HAL3.1
Versão do dispositivo de câmera HAL lançada com o Android 4.4.
Camera HAL3.2
Versão do dispositivo de câmera HAL lançada no Android 5.0.
Câmera API1 CTS
Conjunto de testes de câmera CTS executados em cima da API da câmera1.
Câmera API2 CTS
Conjunto adicional de testes CTS da câmera que são executados sobre a API2 da câmera.
Agudos
Separa a implementação do fornecedor (software específico de dispositivo, de nível inferior, criado 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 de fornecedores apresentado ao lado do Treble.

APIs de câmera

O Android inclui as seguintes APIs de câmera.

API1 da câmera

O Android 5.0 descontinuou a Camera API1, que continua a ser eliminada à 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 da Camera API1 por algum tempo. Especificamente, o suporte continua para:

  • Interfaces API1 da câmera para aplicativos. Os aplicativos de câmera criados sobre a API1 da câmera devem funcionar como nos dispositivos com versões mais baixas do Android.
  • Versões da câmera HAL. Inclui suporte para a câmera HAL1.0.

API2 da câmera

A estrutura Camera API2 expõe o controle da 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 balanço de branco, conversão de cores, denoising, nitidez e muito mais. Para detalhes, assista à visão geral do vídeo de E / S do Google .

O Android 5.0 e superior inclui a Camera API2; no entanto, os dispositivos com 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 a aplicativos por meio das interfaces Camera API2, que são aproximadamente os mesmos recursos que os expostos a aplicativos por meio das interfaces Camera API1. O código das estruturas herdadas traduz conceitualmente as chamadas da Camera API2 em chamadas da Camera API1; dispositivos herdados não suportam recursos da API da câmera2, como controles por quadro.
  • LIMITED : esses dispositivos suportam alguns recursos da API da câmera 2 (mas não todos) e devem usar o Camera HAL 3.2 ou superior.
  • FULL : Esses dispositivos oferecem suporte a todos os principais recursos do Camera API2 e devem usar o Camera HAL 3.2 ou superior e o Android 5.0 ou superior.
  • LEVEL_3 : esses dispositivos suportam reprocessamento YUV e captura de imagem RAW, além de 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 de sensor ou lente podem não ser relatadas ou ter taxas de quadro menos estáveis. Este nível é usado para câmeras externas, como webcams USB.

Os recursos individuais são expostos pela propriedade android.request.availableCapabilities nas interfaces da API2 da câmera. FULL dispositivos exigem os MANUAL_SENSOR e MANUAL_POST_PROCESSING capacidades, entre outros. O recurso RAW é opcional, mesmo para dispositivos FULL . LIMITED dispositivos LIMITED podem anunciar qualquer subconjunto desses recursos, incluindo nenhum deles. No entanto, o recurso BACKWARD_COMPATIBLE sempre deve ser definido.

O nível de hardware suportado do dispositivo, bem como os recursos específicos da Camera API2 que ele suporta, estão disponíveis como os seguintes sinalizadores de recurso para permitir a filtragem do Google Play dos aplicativos de câmera da API 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 passar nos testes da câmera API1 CTS, Camera API2 CTS e Verificador CTS.

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

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

Requisitos VTS

Os dispositivos executando o Android 8.0 e superior com implementações HAL vinculadas devem passar nos testes de câmera VTS .

Proteção da estrutura da câmera

Para reforçar a segurança da mídia e da estrutura da câmera, o Android 7.0 remove o serviço da câmera do servidor de mídia. A partir do Android 8.0, cada Camera HAL vinculado é executado em um processo separado do serviço da 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 alterações arquiteturais no AP1 e AP2 para HAL1 e HAL3, bem como requisitos gerais.

Alterações na arquitetura da 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 a API1 em:

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

    Pilha de câmera e mídia do Android 7.0 na API1 no HAL3

    Figura 1. Câmera do Android 7.0 e pilha de mídia 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 suportado no Android 7.0.)

    Pilha de câmera e mídia do Android 7.0 na API1 no HAL1

    Figura 2. Câmera e pilha do Android 7.0 na API1 no HAL1

Alterações na arquitetura da API2

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

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

    Pilha de câmera e mídia do Android 7.0 na API2 no HAL3

    Figura 3. Câmera e pilha do Android 7.0 na API2 no HAL3

Requisitos adicionais

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

  • Geral. Os dispositivos exigem largura de banda adicional devido ao IPC, o que pode afetar os casos de uso da câmera com sensibilidade 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 em alta velocidade de 120/240 FPS. Os dispositivos também requerem uma pequena quantidade de RAM adicional para criar o novo processo.
  • Passe os metadados nos buffers de vídeo ( somente HAL1 ). Se o HAL1 armazenar metadados em vez de dados de quadro YUV reais nos buffers de vídeo, o HAL deverá usar kMetadataBufferTypeNativeHandleSource como o tipo de buffer de metadados e passar VideoNativeHandleMetadata nos buffers de vídeo. ( kMetadataBufferTypeCameraSource não é mais suportado no Android 7.0.) Com VideoNativeHandleMetadata , as estruturas de câmera e mídia são capazes de passar os buffers de vídeo entre os 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. O HAL não pode usar os endereços para identificar buffers porque os endereços podem armazenar outro identificador de buffer depois que o HAL retorna o buffer. Você deve atualizar o HAL para usar identificadores de buffer para identificar os buffers. Por exemplo, o HAL recebe um endereço de identificador de buffer A, que armazena o identificador de buffer A. Depois que o 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 do SELinux específicas do dispositivo concedem permissões ao servidor de mídia para executar a câmera, você deve atualizar as políticas do SELinux para fornecer permissões adequadas ao servidor de câmera. Nós desencorajamos a replicação das políticas SELinux do mediaserver para cameraserver (como mediaserver e cameraserver geralmente exigem recursos diferentes no sistema). O servidor de câmera 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 servidor de mídia 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 pelo 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 no serviço da 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 do Camera HAL

Para obter uma lista dos testes disponíveis para avaliar o HAL da câmera Android, consulte a 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

Camera 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 físico de câmera que faz backup de um dispositivo de câmera lógica. Consulte Suporte para várias câmeras .
  • isStreamCombinationSupported : este método suporta uma API pública que ajuda os clientes a consultar se há suporte para uma configuração de sessão. Consulte API para consultar combinações de fluxos .

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 da 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 aos buffers associados ao longo do pipeline da câmera, resultando em economia de memória potencialmente significativa.
    • signalStreamFlush : signalStreamFlush ao HAL que o serviço da câmera está prestes a executar o configureStreams_3_5 e que o HAL deve retornar todos os buffers dos fluxos designados.
    • configureStreams_3_5 : Semelhante ao 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 ao 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
  • Recursos
    • 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 dinâmicas de fluxo de profundidade 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 da câmera são atualizadas no Android 10.

2.5

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

2.4

  • Os dispositivos iniciados com o nível 29 da API ou superior DEVEM reportar true para isTorchModeSupported .

Android 9

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

API da câmera

  • Introduz a API de várias câmeras 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 abrangidos por uma câmera lógica. Consulte Suporte para várias câmeras .
  • Introduz parâmetros de sessão. Os parâmetros da sessão são um subconjunto dos parâmetros de captura disponíveis que podem causar atrasos graves no processamento 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 da sessão .
  • Adiciona chaves de dados de estabilização óptica (OIS) para estabilização e efeitos 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 suportados. Consulte INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL .

Camera HAL

3.4.

Atualizações no ICameraDeviceSession

Atualizações no ICameraDeviceCallback

3.3.

As seguintes chaves são adicionadas aos metadados da câmera no Android 9.

  • Recursos
    • 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 os principais aprimoramentos do serviço Câmera:

  • Superfícies compartilhadas: ative várias superfícies que compartilham o mesmo OutputConfiguration
  • API do sistema para modos de câmera personalizados
  • onCaptureQueueEmpty

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

Superfícies compartilhadas

Esse recurso permite que apenas um conjunto de buffers conduza 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 câmera HAL e gralloc HAL possam criar buffers gralloc usados ​​por vários consumidores diferentes (como o compositor de hardware / GPU 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 a câmera HAL e o gralloc HAL; eles precisam alocar os tipos certos de buffers ou a câmera HAL precisa retornar um erro de 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 de alta velocidade. Eles têm semântica bastante diferente; por exemplo, o modo de alta velocidade é limitado a no máximo duas saídas específicas ao mesmo tempo. Vários OEMs demonstraram 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 ativar um modo personalizado. Esses modos devem iniciar no valor inteiro 0x8000 para evitar conflitos com os modos futuros adicionados à API pública.

Para oferecer suporte a esse recurso, os OEMs apenas precisam adicionar o novo modo ao seu HAL, acionado por esse número inteiro passado ao 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 . Veja: frameworks/base/core/java/android/hardware/camera2/CameraDevice .

onCaptureQueueEmpty

O objetivo desta API é reduzir a latência das alterações de controle, como o zoom, mantendo a fila de solicitações o mais vazia possível. onCaptureQueueEmpty não requer trabalho HAL; era 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 é enviado 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 recursos da câmera introduzidos nas versões herdadas mais recentes 3.4 e 2.4 (para o módulo da câmera) também fazem parte das definições do HIDL.

3.4.

Pequenas inclusões nos metadados suportados e alterações no suporte data_space:

  • Adicionar ANDROID_SENSOR_OPAQUE_RAW_SIZE estática metadados como obrigatória se RAW_OPAQUE formato é suportado.
  • Adicione os metadados estáticos ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE como obrigatórios 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 para dados.
  • Adições gerais de metadados 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 de API de reprocessamento OPAQUE e YUV.
  • Suporte básico para buffers de saída de profundidade.
  • Adição do campo data_space à camera3_stream_t .
  • Adição do campo de rotação à camera3_stream_t .
  • Adição do modo de operação de configuração do fluxo camera3_stream_configuration_t ao camera3_stream_configuration_t .

3.2.

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

  • get_metadata_vendor_tag_ops . Use get_vendor_tag_ops em camera_common.h .
  • Descontinua register_stream_buffers . Todos os buffers gralloc fornecidos pela estrutura ao HAL em process_capture_request podem ser novos a qualquer momento.
  • Adicione suporte parcial ao resultado. 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 ao camera3_request_template . Os aplicativos podem usar este modelo para controlar diretamente as configurações de captura.
  • Retrabalhe as especificações bidirecionais e do fluxo de entrada.
  • Mude 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 de liberação para eliminar todos os pedidos / buffers em voo o mais rápido possível.

3.0

Primeira revisão do HAL de capacidade expandida:

  • A principal alteração de versão, pois a ABI é completamente diferente. Nenhuma alteração nos recursos de hardware ou modelo operacional necessários da 2.0.
  • Solicitações de entrada reformuladas e interfaces da fila de fluxos: o Framework chama o HAL com a próxima solicitação e os buffers de fluxo já desenfileirados. O suporte à estrutura de sincronização está incluído, necessário para implementações eficientes.
  • Movimentos acionados em solicitações, a maioria das notificações em resultados.
  • Consolidou todos os retornos de chamada na estrutura em uma estrutura e todos os métodos de instalação em uma única chamada initialize() .
  • Tornou a configuração do fluxo em uma única chamada para simplificar o gerenciamento do fluxo. 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 novos recursos, 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 API android.hardware.Camera .

Histórico de versão do módulo da câmera

Esta seção contém informações sobre a 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 da câmera adiciona as seguintes alterações de API:

  1. Suporte ao modo tocha. A estrutura pode ativar o modo de lanterna 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 acessando a unidade de flash que o módulo da câmera; abrir um dispositivo de câmera apaga a tocha se ela tiver sido ativada pela interface do módulo. Quando houver 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 através do retorno de chamada de status do modo tocha que o modo 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 apenas 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 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 resource_cost e conflicting_devices campos devem sempre ser definido no camera_info estrutura retornada pela get_camera_info chamada.
  4. Método de inicialização do módulo. Chamado pelo serviço da câmera após o carregamento do módulo HAL para permitir a inicialização única do HAL. É chamado antes de qualquer outro método de módulo ser chamado.

2.3

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

2.2

Esta versão do módulo da câmera adiciona suporte a tags de fornecedor do módulo e descontinua os antigos vendor_tag_query_ops que antes eram acessíveis apenas com um dispositivo aberto.

2.1

Esta versão do módulo da câmera adiciona suporte para retornos de chamada assíncronos à estrutura a partir 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 válido set_callbacks() devem relatar pelo menos esse 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 esse 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. Somente a API android.hardware.Camera pode ser suportada por este módulo e seus dispositivos.