O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Suporte para versão de câmera

Esta página detalha diferenças de versão em Hals Câmera, APIs e associados Compatibilidade Teste Suite (CTS) testes. 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
O quadro câmera de nível de aplicativo no Android 4.4 e inferiores dispositivos, exposta através da android.hardware.Camera classe.
Camera API2
O quadro câmera de nível de aplicativo no Android 5.0 e dispositivos maiores, expostas através do android.hardware.camera2 pacote.
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 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.
Treble
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
HAL linguagem de definição de interface introduzidas com Treble e usado para especificar a interface entre um HAL e seus usuários.
VTS
Conjunto de testes fornecedor introduzido ao lado de Agudos.

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 como 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 mais detalhes, ver a visão geral em vídeo 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 oferecer suporte a todos os recursos da API2 da câmera. O android.info.supportedHardwareLevel propriedade que os aplicativos podem consultar através das interfaces Camera API2 relata um dos seguintes níveis de suporte:

  • LEGACY : Estes dispositivos expor capacidades para aplicativos através de interfaces API2 câmera que são aproximadamente os mesmos recursos que aqueles expostos a aplicativos através de interfaces Camera API1. O código de estruturas legadas traduz conceitualmente chamadas Camera API2 em chamadas Camera API1; dispositivos legados não oferecem suporte a recursos Camera API2, como controles por quadro.
  • LIMITED : Estes dispositivos suportam algumas capacidades Camera API2 (mas não todos) e devem usar a câmera HAL 3.2 ou superior.
  • FULL : Estes dispositivos suportam todos os principais recursos do API2 Camera e deve usar a câmera HAL 3.2 ou superior e Android 5.0 ou superior.
  • LEVEL_3 : Estes dispositivos suportam YUV reprocessamento e captura de imagem RAW, juntamente com configurações de fluxo de saída adicionais.
  • EXTERNAL : Estes dispositivos são semelhantes aos LIMITED dispositivos 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 expostos através da android.request.availableCapabilities propriedade nas interfaces Camera API2. FULL dispositivos exigem os MANUAL_SENSOR e MANUAL_POST_PROCESSING capacidades, entre outros. A RAW capacidade é opcional mesmo para FULL dispositivos. LIMITED dispositivos pode anunciar qualquer subconjunto desses recursos, incluindo nenhum deles. No entanto, o BACKWARD_COMPATIBLE capacidade deve ser sempre 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 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 em câmera API2 LEGACY modo (em que as chamadas Camera API2 são conceitualmente mapeados para chamadas Camera API1) Assim, qualquer câmera API2 CTS testes relacionados a recursos ou capacidades para além API1 Camera são ignorados automaticamente.

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 no Camera API2 CTS) são bugs já presentes no Camera HAL existente do dispositivo e, portanto, seriam encontrados por 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 com o Android 8.0 e superior com implementações HAL binderized deve passar a câmera testes VTS .

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 HAL de câmera 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 da API e das versões do 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 câmara utiliza BufferQueue passar buffers entre processos, nenhuma atualização do fornecedor é necessário.

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

    Figura 1. Android 7,0 câmara e meios empilhar em API1 em HAL3

  • HAL1, que suporta a passagem de metadados em buffers de vídeo, os fornecedores devem atualizar o HAL usar kMetadataBufferTypeNativeHandleSource . ( kMetadataBufferTypeCameraSource já não é suportado em Android 7.0.)

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

    Figura 2. Android 7,0 câmara e meios empilhar 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:

  • HAL1 não é afetado pelo movimento cameraservice, e nenhuma atualização fornecedor é necessário.
  • HAL3 é afetada, mas nenhuma atualização fornecedor é necessário:

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

    Figura 3. Android 7,0 câmara e meios empilhar 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.

  • 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. Fornecedores podem medir o impacto real executando android.hardware.camera2.cts.PerformanceTest e a aplicação Câmara Google para 120/240 FPS gravação de vídeo de alta velocidade. Os dispositivos também requerem uma pequena quantidade de RAM adicional para criar o novo processo.
  • Passar os metadados em tampões vídeo (apenas HAL1). Se lojas HAL1 metadados em vez de dados do quadro verdadeiro YUV 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 já não é suportado em Android 7.0.) Com VideoNativeHandleMetadata , da câmara e meios de comunicação quadros são capazes de passar os buffers de vídeo entre os processos de serialização e deserializing as alças nativas adequadamente.
  • Tampão endereço pega nem sempre armazenar o mesmo tampão (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 fornecem permissões de servidor de mídia para executar a câmera, você deve atualizar as políticas de 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 o servidor de mídia e o 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. Além disso, o Android 8.0 e superior separam o HAL da câmera encadernado em um processo diferente do servidor de câmera. IPC atravessa definida-HIDL interfaces.

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 o VTS.

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

Para uma lista de testes disponíveis para avaliar o Android Camera HAL, ver a câmera HAL Testing Checklist .

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 da câmara estática para um ID da câmera física apoiar um dispositivo de câmera lógica. Veja Suporte Multi-Camera .
  • isStreamCombinationSupported : Este método oferece suporte a uma API pública que ajuda a consulta clientes, se uma configuração de sessão é suportado. Veja API para combinações de fluxo consulta .

ICameraDeviceSession

  • isReconfigurationNeeded : Método que conta a estrutura da câmara se reconfiguração fluxo completo é necessário para possíveis valores novos parâmetros de sessão. Isso ajuda a evitar atrasos desnecessários na reconfiguração da câmera. Veja consulta reconfiguração Session .
  • APIs de gestão tampão HAL : Essas APIs permitem que o HAL câmera para solicitação buffers de quadro da câmera apenas quando necessário, em vez de acoplamento cada pedido de captura com seus buffers associados em todo o pipeline de câmera, resultando em economia de memória potencialmente significativas.
    • signalStreamFlush : Sinais para o HAL que o serviço câmara está prestes a realizar configureStreams_3_5 e que o HAL deve retornar todos os buffers de fluxos designados.
    • configureStreams_3_5 : Semelhante ao ICameraDevice3.4.configureStreams , mas, além disso, o streamConfigCounter contador é fornecido para verificar se há uma condição de corrida entre as configureStreams_3_5 e signalStreamFlush chamadas.

Atualizações para ICameraDeviceCallback :

  • requestStreamBuffers : callback Synchronous que a câmera HAL chama para pedir o servidor de câmera para buffers. Veja requestStreamBuffers .
  • returnStreamBuffers : callback Synchronous para o HAL câmera para voltar buffers de saída para o servidor de 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 o ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT chave
    • 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 de lançamento com o nível de API 29 ou superior deve relatar 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 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. Veja Suporte Multi-Camera .
  • 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. Veja os parâmetros de sessão .
  • Adiciona chaves de dados de estabilização ótica (OIS) para estabilização e efeitos no nível do aplicativo. Veja STATISTICS_OIS_SAMPLES .
  • Adiciona suporte a flash externo. Veja CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
  • Adiciona um movimento de monitoramento intenção em CAPTURE_INTENT . Veja CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • Deprecates LENS_RADIAL_DISTORTION e acrescenta LENS_DISTORTION em seu lugar.
  • Adiciona modos de correção de distorção CaptureRequest . Veja DISTORTION_CORRECTION_MODE .
  • Adiciona suporte para câmeras externas USB / UVC em dispositivos compatíveis. Veja 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 Treble, vendedor implementações Camera HAL deve ser binderized . O Android 8.0 também contém estas melhorias importantes para o serviço de câmera:

  • Superfícies compartilhadas: Habilitar múltiplas superfícies que compartilham 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 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 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 informando que essa combinação de consumidores não é compatível.

Veja a enableSurfaceSharing documentação do desenvolvedor 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 capuz, o modo é apenas um número inteiro passado para configure_streams . Veja: 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 esse 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 . Veja: 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 requer nenhum 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 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 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 ao suporte data_space:

  • Adicionar ANDROID_SENSOR_OPAQUE_RAW_SIZE estática metadados como obrigatória se RAW_OPAQUE formato é suportado.
  • Adicionar ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE estática metadados como obrigatório se qualquer formato RAW é suportado.
  • Interruptor camera3_stream_t data_space campo para uma definição mais flexível, usando a definição versão 0 de codificação DataSpace.
  • Adições de metadados gerais 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.
  • Além de data_space campo para camera3_stream_t .
  • Além de campo de rotação para camera3_stream_t .
  • A adição do modo de funcionamento de configuração corrente para camera3 camera3_stream_configuration_t .

3,2

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

  • Deprecates get_metadata_vendor_tag_ops . Use get_vendor_tag_ops em camera_common.h vez.
  • Deprecates register_stream_buffers . Todos os buffers gralloc fornecidos pelo quadro de HAL em process_capture_request pode ser novo 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 do resultado completo está disponível.
  • Adicionar modelo manual para 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 tampão é 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 bandeiras de uso de consumo 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 mudança nos recursos de hardware necessários ou no 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.
  • Consolidou todas as chamadas de retorno em quadro em uma estrutura, e todos os métodos de configuração em um único initialize() chamada.
  • Transformou a configuração do stream em uma única chamada para simplificar o gerenciamento do stream. Fluxos bidirecionais substituir o STREAM_FROM_STREAM construção.
  • 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]:

  • Suficientes para a implementação existente android.hardware.Camera API.
  • 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 de 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á conflitos de recursos, como open() é chamado para abrir um dispositivo de câmera, o módulo HAL câmara deve notificar o quadro através do status de retorno de chamada modo de tocha que o modo 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álidos quando o estado 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 oferecer suporte a várias versões de API de dispositivo. A chamada aberta módulo de hardware padrão ( common.methods->open ) continua a abrir o dispositivo da câmera com a mais recente versão suportada, que também é a versão registrada no camera_info_t.device_version .

2,2

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

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 válido set_callbacks() relatório método deve, pelo menos esse 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. 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 device_version campo da camera_info é sempre válida; o static_camera_characteristics campo da camera_info é válido se o device_version campo é 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 device_version e static_camera_characteristics campos de camera_info não são válidos. Apenas o android.hardware.Camera API pode ser suportado por este módulo e seus dispositivos.