Suporte à versão da câmera

Esta página detalha as diferenças de versão em HALs de câmera, APIs e testes associados do Compatibility Test Suite (CTS). Ele também aborda várias mudanças de arquitetura feitas para reforçar e proteger o framework da câmera no Android 7.0, a mudança para o Treble no Android 8.0 e as atualizações que os fornecedores precisam fazer para oferecer suporte a essas mudanças nas implementações de câmera.

Terminologia

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

API Camera1
O framework da câmera no nível do app em dispositivos Android 4.4 e anteriores, exposto pela classe android.hardware.Camera.
API 2 da câmera
O framework da câmera no nível do app em dispositivos Android 5.0 e mais recentes, exposto pelo pacote android.hardware.camera2.
HAL da câmera
A camada do módulo da câmera implementada pelos fornecedores de SoC. Os frameworks públicos no nível do app são criados com base no HAL da câmera.
Câmera HAL3.1
Versão da HAL do dispositivo de câmera lançada com o Android 4.4.
Câmera HAL3.2
Versão da HAL do dispositivo de câmera lançada com o Android 5.0.
CTS da API Camera1
Conjunto de testes CTS da câmera executados em cima da API Camera1.
CTS da API Camera2
Conjunto adicional de testes CTS da câmera executados na API Camera2.
Agudo
Separa a implementação do fornecedor (software específico do dispositivo e de nível inferior escrito por fabricantes de silício) da estrutura do SO Android por uma nova interface do fornecedor.
HIDL
Linguagem de definição de interface da HAL introduzida com o Treble e usada para especificar a interface entre uma HAL e os usuários.
VTS
O pacote de testes do fornecedor foi introduzido com o Treble.

APIs Camera

O Android inclui as seguintes APIs de câmera.

API Camera1

O Android 5.0 suspendeu o uso da API Camera1, que continua a ser descontinuada conforme o desenvolvimento da nova plataforma se concentra na API Camera2. No entanto, o período de descontinuação será longo, e as versões do Android vão continuar a oferecer suporte a apps da API Camera1 por algum tempo. Especificamente, o suporte continua para:

  • Interfaces de câmera API1 para apps. Os apps de câmera criados com base na API Camera1 precisam funcionar da mesma forma que em dispositivos com versões mais antigas do Android.
  • Versões da HAL da câmera. Inclui suporte para a HAL1.0 da câmera.

API Camera2

O framework da API Camera2 expõe o controle de câmera de baixo nível ao app, incluindo fluxos de burst/streaming eficientes sem cópia e controles por frame de exposição, ganho, ganhos de balanço de branco, conversão de cores, redução de ruído, nitidez e muito mais. Para mais detalhes, assista a visão geral do vídeo do Google I/O.

O Android 5.0 e versões mais recentes incluem a API Camera2. No entanto, os dispositivos com o Android 5.0 e versões mais recentes podem não oferecer suporte a todos os recursos da API Camera2. A propriedade android.info.supportedHardwareLevel que os apps podem consultar pelas interfaces da API Camera2 informa um dos seguintes níveis de suporte:

  • LEGACY: esses dispositivos expõem recursos para apps usando as interfaces da API Camera2 que são aproximadamente os mesmos recursos expostos aos apps usando as interfaces da API Camera1. O código dos frameworks legados converte conceitualmente as chamadas da API2 Camera em chamadas da API1 da câmera. Os dispositivos legados não oferecem suporte a recursos dessa API, como controles por frame.
  • LIMITED: esses dispositivos oferecem suporte a alguns recursos da API Camera2 (mas não a todos) e precisam usar o HAL 3.2 da câmera ou mais recente.
  • FULL: esses dispositivos oferecem suporte a todos os principais recursos da API Camera2 e precisam usar o HAL 3.2 da câmera ou mais recente e o Android 5.0 ou mais recente.
  • LEVEL_3: esses dispositivos oferecem suporte ao reprocessamento YUV e à captura de imagens RAW, além de outras configurações de stream de saída.
  • EXTERNAL: esses dispositivos são semelhantes aos dispositivos LIMITED, com algumas exceções. Por exemplo, algumas informações de sensores ou lentes podem não ser informadas ou ter frame rates menos estáveis. Esse nível é usado para câmeras externas, como webcams USB.

Os recursos individuais são expostos pela propriedade android.request.availableCapabilities nas interfaces da API Camera2. Os dispositivos FULL exigem os recursos MANUAL_SENSOR e MANUAL_POST_PROCESSING, entre outros. A capacidade RAW é opcional, mesmo para dispositivos FULL. Os dispositivos LIMITED podem anunciar qualquer subconjunto desses recursos, incluindo nenhum deles. No entanto, o capability BACKWARD_COMPATIBLE sempre precisa ser definido.

O nível de hardware compatível do dispositivo, bem como os recursos específicos da API Camera2, estão disponíveis como os seguintes flags de recursos para permitir a filtragem de apps de câmera da API Camera2 no Google Play.

  • 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 do CTS

Os dispositivos com o Android 5.0 e versões mais recentes precisam passar nos testes de câmera da API1, da API2 e do verificador do CTS.

Os dispositivos que não têm uma implementação do HAL3.2 da câmera e não oferecem suporte às interfaces completas da API Camera2 ainda precisam passar nos testes CTS da API Camera2. No entanto, o dispositivo é executado no modo LEGACY da API Camera2, em que as chamadas da API Camera2 são mapeadas conceitualmente para chamadas da API Camera1. Portanto, todos os testes da API Camera2 do CTS relacionados a recursos ou recursos além da API Camera1 são pulados automaticamente.

Em dispositivos legados, os testes de CTS da API Camera2 que são executados usam as interfaces e os recursos públicos da API Camera1 sem novos requisitos. Os bugs expostos (e que causam uma falha da CTS da API Camera2) já estão presentes na HAL da câmera do dispositivo e, portanto, seriam encontrados pelos apps da API Camera1. Não esperamos muitos bugs dessa natureza. No entanto, esses bugs precisam ser corrigidos para passar nos testes de CTS da API2 da Câmera.

Requisitos do VTS

Dispositivos com o Android 8.0 e versões mais recentes com implementações de HAL vinculadas precisam passar nos testes VTS da câmera.

Aumento da proteção do framework da câmera

Para aumentar a segurança do framework de mídia e câmera, o Android 7.0 remove o serviço de câmera do mediaserver. No Android 8.0 e versões mais recentes, cada HAL de câmera vinculada é executada em um processo separado do serviço de câmera. Os fornecedores podem precisar fazer mudanças na HAL da câmera, dependendo das versões da API e da HAL em uso. As seções a seguir detalham as mudanças de arquitetura em AP1 e AP2 para HAL1 e HAL3, além de requisitos gerais.

Mudanças na arquitetura da API1

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

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

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

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

  • HAL1, que oferece suporte à transmissão de metadados em buffers de vídeo, os fornecedores precisam atualizar a HAL para usar kMetadataBufferTypeNativeHandleSource. O kMetadataBufferTypeCameraSource não é mais compatível com o Android 7.0.

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

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

Mudanças na arquitetura da API2

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

  • A HAL1 não é afetada pela movimentação do Cameraservice, e nenhuma atualização do fornecedor é necessária.
  • O HAL3 é afetado, mas nenhuma atualização do fornecedor é necessária:

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

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

Outros requisitos

As mudanças arquitetônicas feitas para aumentar a proteção da mídia e do framework da câmera incluem os outros requisitos de dispositivo a seguir.

  • Geral. Os dispositivos exigem mais largura de banda devido à IPC, o que pode afetar casos de uso de câmeras urgentes, como gravação de vídeo de alta velocidade. Os fornecedores podem medir o impacto real executando android.hardware.camera2.cts.PerformanceTest e o app Câmera do Google para gravação de vídeo de alta velocidade de 120/240 QPS. Os dispositivos também exigem uma pequena quantidade de RAM adicional para criar o novo processo.
  • Transmitir metadados em buffers de vídeo (somente HAL1). Se o HAL1 armazenar metadados em vez de dados de frames YUV reais em buffers de vídeo, o HAL precisará usar kMetadataBufferTypeNativeHandleSource como o tipo de buffer de metadados e transmitir VideoNativeHandleMetadata em buffers de vídeo. O kMetadataBufferTypeCameraSource não é mais compatível com o Android 7.0. Com VideoNativeHandleMetadata, os frameworks de câmera e mídia podem transmitir 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 recebe 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 retornar o buffer. É necessário atualizar o HAL para usar identificadores de buffer. Por exemplo, o HAL recebe um endereço de identificador de buffer A, que armazena o identificador de buffer A. Depois que a HAL retornar o identificador de buffer A, o endereço do identificador de buffer A poderá armazenar o identificador de buffer B na próxima vez que a HAL o receber.
  • Atualização das políticas do SELinux para o cameraserver. Se as políticas do SELinux específicas do dispositivo concederem permissões ao mediaserver para executar a câmera, você precisará atualizar as políticas do SELinux para conceder as permissões adequadas ao cameraserver. Não recomendamos replicar as políticas de SELinux do mediaserver para o Cameraserver, já que o mediaserver e o Cameraserver geralmente exigem recursos diferentes no sistema. O Cameraserver precisa ter apenas as permissões necessárias para executar as funcionalidades da câmera, e todas as permissões desnecessárias relacionadas à câmera no Mediaserver precisam ser removidas.
  • Separação entre a HAL da câmera e o cameraserver. O Android 8.0 e versões mais recentes também separam a HAL da câmera vinculada em um processo diferente do cameraserver. O IPC passa por interfaces definidas por HIDL.

Validação

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

Para todos os dispositivos que incluem câmera e executam o Android 8.0 e versões mais recentes, verifique a implementação do fornecedor executando o VTS.

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

Para conferir uma lista de testes disponíveis para avaliar a HAL da câmera do Android, consulte a Checklist de testes de HAL da câmera.

Android 10

O Android 10 traz as atualizações a seguir.

API da câmera

HAL da câmera

As seguintes versões da HAL da câmera foram atualizadas no Android 10.

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics: as informações estáticas de uma câmera física que oferece suporte a um dispositivo de câmera lógica. 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 a API para consultar combinações de transmissão.

ICameraDeviceSession

  • isReconfigurationNeeded: método que informa ao framework 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 de HAL: essas APIs permitem que a HAL da câmera solicite buffers do framework da câmera somente quando necessário, em vez de acoplar cada solicitação de captura aos buffers associados em todo o pipeline da câmera, resultando em uma economia de memória potencialmente significativa.
    • signalStreamFlush: sinaliza para a HAL que o serviço da câmera está prestes a executar configureStreams_3_5 e que a HAL precisa retornar todos os buffers dos streams 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 do ICameraDeviceCallback:

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

3.4

As chaves a seguir 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 de transmissão 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 streaming de HEIC disponíveis
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Módulo de câmera

As versões do módulo da câmera a seguir foram atualizadas no Android 10.

2,50

  • O método notifyDeviceStateChange foi adicionado para que os dispositivos notifiquem a HAL da câmera quando mudanças físicas, como dobras, afetam a câmera e o roteamento.

2,40

  • Os dispositivos lançados com o nível 29 da API ou mais recente PRECISAM informar true para isTorchModeSupported.

Android 9

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

API da câmera

  • Introdução da API de várias câmeras para oferecer melhor compatibilidade com dispositivos com várias câmeras voltadas para a mesma direção, permitindo recursos como efeito bokeh e zoom contínuo. Isso permite que os apps 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 incluídos em uma câmera lógica. Consulte Compatibilidade com 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 grandes atrasos no processamento quando modificados. Esses custos podem ser mitigados se os clientes transmitirem os valores iniciais durante a inicialização da sessão de captura. Consulte Parâmetros de sessão.
  • Adiciona chaves de dados de estabilização óptica (OIS) para estabilização e efeitos no nível do app. Consulte STATISTICS_OIS_SAMPLES.
  • Adiciona suporte a flash externo. Consulte CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
  • Adiciona uma intent de rastreamento de movimento em CAPTURE_INTENT. Consulte CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
  • Descontinua o LENS_RADIAL_DISTORTION e adiciona LENS_DISTORTION no lugar dele.
  • Adiciona modos de correção de distorção em CaptureRequest. Consulte DISTORTION_CORRECTION_MODE.
  • Adiciona suporte a câmeras USB/UVC externas em dispositivos compatíveis. Consulte INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

HAL da câmera

3.4

Atualizações do ICameraDeviceSession

Atualizações do ICameraDeviceCallback

3,30

As chaves a seguir 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

O lançamento do Android 8.0 apresenta o Treble. Com o Treble, as implementações do HAL da câmera do fornecedor precisam ser vinculadas. O Android 8.0 também contém estas melhorias importantes 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

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

Superfícies compartilhadas

Esse recurso permite que apenas um conjunto de buffers gere duas saídas, como a visualização e a 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 as implementações do HAL da câmera e do HAL gralloc possam criar buffers gralloc que sejam 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 transmite as flags de uso do consumidor para a HAL da câmera e a HAL gralloc. Elas precisam alocar os tipos corretos de buffers, ou a HAL da câmera precisa retornar um erro de que essa combinação de consumidores não tem suporte.

Consulte a documentação para desenvolvedores enableSurfaceSharing para mais detalhes.

API do sistema para modos de câmera personalizados

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

Esse recurso inclui uma chamada de API do sistema que os apps de câmera OEM podem usar para ativar um modo personalizado. Esses modos precisam 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 HAL, acionando esse número inteiro transmitido ao HAL em configure_streams e, em seguida, fazer com que o app 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 mudanças de controle, como o zoom, mantendo a fila de solicitações o mais vazia possível. onCaptureQueueEmpty não requer trabalho com HAL. Foi apenas uma adição ao framework. Os apps que querem aproveitar esse recurso precisam adicionar um listener a esse callback 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 HIDL da câmera é uma revisão completa da interface HAL da câmera que usa APIs estáveis definidas por HIDL. Todos os recursos e recursos de câmera introduzidos nas versões 3.4 e 2.4 mais recentes (para o módulo da câmera) também fazem parte das definições HIDL.

3.4

Pequenas adições aos metadados compatíveis e alterações no suporte a data_space:

  • Os metadados estáticos ANDROID_SENSOR_OPAQUE_RAW_SIZE são obrigatórios se o formato RAW_OPAQUE for aceito.
  • Os metadados estáticos ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE foram adicionados como obrigatórios se houver suporte a qualquer formato RAW.
  • Mudar 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 de metadados gerais 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

Pequena revisão da HAL com capacidade expandida:

  • Atualizações da API OPAQUE e YUV para reprocessamento.
  • Suporte básico para buffers de saída de profundidade.
  • O campo data_space foi adicionado 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 fluxo da câmera3 a camera3_stream_configuration_t.

3.2

Revisão menor da HAL de recursos expandidos:

  • Descontinua o get_metadata_vendor_tag_ops. Use get_vendor_tag_ops em camera_common.h.
  • Descontinuamos o uso de register_stream_buffers. Todos os buffers gralloc fornecidos pelo framework para HAL em process_capture_request podem ser novos a qualquer momento.
  • Adicionar 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 a camera3_request_template. Os apps podem usar esse modelo para controlar as configurações de captura diretamente.
  • Retrabalhe as especificações de fluxo de entrada e bidirecional.
  • 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 menor do HAL de recursos expandidos:

  • O configure_streams transmite as sinalizações de uso do consumidor para a HAL.
  • Chamada de limpeza para descartar todas as solicitações/buffers em andamento o mais rápido possível.

3.0

Primeira revisão do HAL de recursos expandidos:

  • Mudança de versão principal, já que a ABI é completamente diferente. Nenhuma mudança nos recursos de hardware ou no modelo operacional necessário da versão 2.0.
  • Interfaces de solicitação de entrada e fila de stream reformuladas: chamadas de framework para a HAL com os próximos buffers de solicitação e stream já removidos da fila. O suporte ao framework de sincronização está incluído, necessário para implementações eficientes.
  • Os acionadores foram movidos para solicitações, e a maioria das notificações foi movida para resultados.
  • Todos os callbacks foram consolidados no framework em uma estrutura, e todos os métodos de configuração em uma única chamada initialize().
  • Transformamos a configuração do stream em uma única chamada para simplificar o gerenciamento. Os streams bidirecionais substituem o conjunto STREAM_FROM_STREAM.
  • Semântica de modo limitado para dispositivos de hardware mais antigos/limitados.

2.0

Versão inicial da HAL de recursos expandidos (Android 4.2) [camera2.h]:

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

1.0

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

  • Conversão da camada de abstração CameraHardwareInterface do C++.
  • Oferece suporte à API android.hardware.Camera.

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

Esta seção contém informações de versionamento 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 mudanças de API:

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

2.3

Essa versão do módulo de câmera adiciona suporte ao dispositivo HAL de câmera legada aberta. O framework pode usá-lo para abrir o dispositivo da câmera como uma versão HAL de dispositivo mais baixa se o mesmo dispositivo puder oferecer suporte a várias versões de 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 com suporte mais recente, que também é a versão listada em camera_info_t.device_version.

2.2

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

2.1

Essa versão do módulo da câmera adiciona suporte a callbacks assíncronos ao framework do módulo HAL da câmera, que é usado para notificar o framework sobre mudanças no estado do módulo da câmera. Os módulos que fornecem um método set_callbacks() válido precisam informar pelo menos esse número de versão.

2.0

Os módulos da câmera que informam 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 usando esse módulo podem oferecer suporte às versões 1.0 ou 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 mais recente.

1.0

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