O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Suporte para versão de câmera

Esta página detalha as diferenças de versão em HALs de câmera, APIs e testes de Compatibility Test Suite (CTS) associados. Ele também cobre várias mudanças 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 mudanças em suas implementações de câmera.

Terminologia

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

Camera API1
A estrutura da câmera no nível do aplicativo no Android 4.4 e dispositivos inferiores, exposta por meio da classe android.hardware.Camera .
Camera API2
A estrutura da câmera no nível do aplicativo em dispositivos Android 5.0 e superior, exposta por meio do pacote android.hardware.camera2 .
Câmera HAL
A camada de módulo da câmera implementada por fornecedores de SoC. As estruturas públicas de nível de aplicativo são construídas na parte superior do 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 CTS de câmera executados na API1 da câmera.
Câmera API2 CTS
Conjunto adicional de testes de CTS de câmera executados na API2 da câmera.
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
Pacote de teste do fornecedor introduzido junto com o Treble.

APIs de câmera

O Android inclui as seguintes APIs de câmera.

Camera API1

O Android 5.0 tornou o Camera API1 obsoleto, que continua a ser descontinuado conforme o desenvolvimento de uma 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 aos aplicativos Camera API1 por algum tempo. Especificamente, o suporte continua para:

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

Camera API2

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

Android 5.0 e superior inclui Camera API2; no entanto, dispositivos que executam o Android 5.0 e superior podem não oferecer suporte a todos os recursos API2 da câmera. A propriedade android.info.supportedHardwareLevel que os aplicativos podem consultar por meio das interfaces da API2 da câmera 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 expostos para aplicativos por meio das interfaces Camera API1. O código de estruturas legadas traduz conceitualmente chamadas Camera API2 em chamadas Camera API1; dispositivos legados não suportam recursos Camera API2, como controles por quadro.
  • LIMITED : Esses dispositivos suportam alguns recursos API2 da câmera (mas não todos) e devem usar a câmera HAL 3.2 ou superior.
  • FULL : Esses dispositivos suportam todos os principais recursos da Camera API2 e devem usar o Camera HAL 3.2 ou superior e Android 5.0 ou superior.
  • LEVEL_3 : Esses dispositivos suportam reprocessamento YUV e captura de imagem RAW, junto 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.

Capacidades individuais são expostas por meio da propriedade android.request.availableCapabilities nas interfaces Camera API2. FULL dispositivos exigem os MANUAL_SENSOR e MANUAL_POST_PROCESSING capacidades, 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 sempre deve 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 recurso 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 que executam o Android 5.0 e superior devem passar nos testes de câmera Camera API1 CTS, Camera API2 CTS e CTS Verifier.

Dispositivos que não apresentam uma implementação Camera HAL3.2 e não são capazes de suportar as interfaces Camera API2 completas 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 conceitualmente mapeadas para chamadas Camera API1), portanto, quaisquer testes de Camera API2 CTS 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 Camera API1 existentes 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, qualquer um desses bugs deve ser corrigido para passar nos testes Camera API2 CTS).

Requisitos VTS

Dispositivos executando o Android 8.0 e superior com implementações de HAL binderized devem passar nos testes de VTS da câmera.

Endurecimento da estrutura da câmera

Para fortalecer a segurança da estrutura de mídia e câmera, o Android 7.0 move o serviço de câmera do mediaserver. A partir do Android 8.0, cada Camera HAL binderized é executado 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 de API e HAL em uso. As seções a seguir detalham as mudanças arquitetônicas em 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 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 de fornecedor é necessária.

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

    Figura 1. Câmera Android 7.0 e pilha de mídia em API1 em 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 em API1 em HAL1

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

Mudanças arquitetônicas para API2

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

Requisitos adicionais

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

  • 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 Câmera do Google 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 o HAL1 armazenar 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 são capazes de passar os buffers de vídeo entre os processos serializando e desserializando as alças nativas de maneira adequada.
  • 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. O HAL não pode usar os endereços para identificar buffers porque os endereços podem armazenar outro identificador de buffer após o HAL retornar 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 SELinux específicas do dispositivo fornecerem permissões ao servidor de mídia para executar a câmera, você deve atualizar as políticas do SELinux para dar as permissões adequadas ao servidor de câmera. Não recomendamos a replicação das políticas SELinux do servidor de mídia para o servidor de câmera (já que servidor de mídia e servidor de câmera 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 HAL da câmera e servidor de câmera. O Android 8.0 e superior separam adicionalmente o HAL da câmera binderized em um processo diferente do servidor de câmera. 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 mudanças 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 VTS.

Histórico da versão HAL da câmera

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

Android 10

O Android 10 apresenta as seguintes atualizações.

API de câmera

Câmera HAL

As seguintes versões do HAL da câmera são atualizadas no Android 10.

3,5

ICameraDevice

  • getPhysicalCameraCharacteristics : As informações estáticas da câmera para uma ID de câmera física apoiando um dispositivo de câmera lógico. Consulte Suporte para várias 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 stream é 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 o HAL da câmera solicite buffers da estrutura da câmera apenas 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 da câmera está prestes a realizar 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 se há uma condição de corrida entre as chamadas configureStreams_3_5 e signalStreamFlush .

Atualizações para ICameraDeviceCallback :

  • requestStreamBuffers : requestStreamBuffers chamada síncrono que o HAL da câmera chama para solicitar buffers ao servidor da câmera. ConsulterequestStreamBuffers .
  • returnStreamBuffers : retorno de chamada síncrono para o HAL da câmera para retornar buffers de saída para o servidor da câmera. Veja 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 de 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 dinâmico de profundidade disponíveis
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Configurações de stream 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 notifyDeviceStateChange método para dispositivos para notificar o HAL câmara quando as alterações físicas, tais como dobragem, afectar câmara e encaminhamento.

2,4

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

Android 9

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

API de 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 abrangidos por uma câmera lógica. Consulte Suporte para várias câmeras .
  • Apresenta os parâmetros da 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 os parâmetros da sessão .
  • Adiciona chaves de dados de estabilização óptica (OIS) para estabilização e efeitos no nível do aplicativo. Veja 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 em CaptureRequest . Veja DISTORTION_CORRECTION_MODE .
  • Adiciona suporte para câmeras externas USB / UVC 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 de 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 do Android 8.0 apresenta o Treble. Com o Treble, as implementações do fornecedor Camera HAL devem ser encadernadas . O Android 8.0 também contém estas melhorias importantes para o serviço de câmera:

  • Superfícies compartilhadas: permite que várias superfícies compartilhem 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 acione duas saídas, como visualização e codificação de vídeo, o que reduz o consumo de energia e memória. Para suportar 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 de câmera e o HAL de gralloc; eles precisam alocar os tipos certos de buffers ou o HAL da câmera precisa retornar um erro de que essa combinação de consumidores não é compatível.

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 de uma vez. Vários OEMs expressaram interesse em definir outros modos personalizados para recursos específicos de hardware. Sob o capô, o modo é apenas um 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 habilitar um modo personalizado. Esses modos devem começar com o valor inteiro 0x8000 para evitar conflito 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 este inteiro passado para o 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 . Consulte: frameworks/base/core/java/android/hardware/camera2/CameraDevice .

onCaptureQueueEmpty

O objetivo desta API é reduzir a latência das alterações de controle, como zoom, mantendo a fila de solicitações o mais vazia possível. onCaptureQueueEmpty não requer trabalho de 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 apropriadamente. Geralmente, isso é feito enviando outra solicitação de captura para o dispositivo de 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 da câmera introduzidos nas versões legadas mais recentes 3.4 e 2.4 (para o módulo da 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:

  • Adicionar ANDROID_SENSOR_OPAQUE_RAW_SIZE estática metadados como obrigatória se RAW_OPAQUE formato é suportado.
  • Adicione 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 de codificação de 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

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 do stream camera3_stream_configuration_t a 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 em vez disso.
  • Obsoleta register_stream_buffers . Todos os buffers gralloc fornecidos pelo framework para HAL em process_capture_request podem ser novos a qualquer momento.
  • Adicione suporte de resultado parcial. 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 a camera3_request_template . Os aplicativos podem usar este modelo para controlar as configurações de captura diretamente.
  • Retrabalhe 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

Revisão secundária 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:

  • Mudança de versão principal, uma vez que a ABI é completamente diferente. Nenhuma alteração nos recursos de hardware necessários ou modelo operacional de 2.0.
  • Solicitação de entrada retrabalhada e interfaces de fila de fluxo: chamadas de estrutura em HAL com a próxima solicitação e buffers de fluxo já retirados da fila. Inclui suporte de framework de sincronização, necessário para implementações eficientes.
  • Movidos gatilhos para solicitações, a maioria das notificações para resultados.
  • Todos os retornos de chamada consolidados em uma estrutura em uma estrutura e todos os métodos de configuração em uma única chamada initialize() .
  • Transformou a configuração do stream em uma única chamada para simplificar o gerenciamento do 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 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 quaisquer novos recursos, como controle de captura manual, captura Bayer RAW, reprocessamento de dados RAW, etc.

1.0

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

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

Histórico da versão 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 da câmera adiciona as seguintes alterações de API:

  1. Suporte ao modo 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 maior prioridade de acesso à unidade de flash do que o módulo da câmera; abrir um dispositivo de câmera desliga a tocha se ela tiver sido ativada por meio da interface do módulo. Quando há qualquer conflito de recursos, como open() é chamado para abrir um dispositivo de câmera, o módulo HAL de câmera deve notificar a estrutura por meio do retorno de chamada de status do modo de tocha que o modo de tocha foi desligado.
  2. Suporte para câmera externa (por exemplo, câmera USB hot-plug). As atualizações de 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 para câmeras externas hot-plug. 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 mudança de status do dispositivo para gerenciar a lista de câmeras externas disponíveis.
  3. Dicas de arbitragem de 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 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 chamado.

2,3

Esta versão de módulo de câmera adiciona suporte a dispositivo 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 mais recente 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 do fornecedor do módulo e descarta o antigo vendor_tag_query_ops que antes só era acessível com um dispositivo aberto.

2,1

Esta versão do módulo da câmera adiciona suporte para callbacks assíncronos à estrutura do módulo HAL da câmera, que é usado para notificar a estrutura sobre mudanças no estado do módulo da 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

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

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 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. Apenas a API android.hardware.Camera pode ser compatível com este módulo e seus dispositivos.