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 arquitetônicas feitas para proteger e reforçar 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 de câmera no nível do app em dispositivos com Android 4.4 e versões anteriores, exposto pela classe android.hardware.Camera.
API Camera2
O framework de 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 de câmera implementada pelos fornecedores de SoC. Os frameworks públicos no nível do app são criados com base na HAL da câmera.
Câmera HAL3.1
Versão da HAL do dispositivo de câmera lançada com o Android 4.4.
HAL3.2 da câmera
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 na API Camera1.
CTS da API Camera2
Conjunto adicional de testes do 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 hardware) do framework do SO Android por uma nova interface do fornecedor.
HIDL
Linguagem de definição da interface HAL introduzida com o Treble e usada para especificar a interface entre uma HAL e os usuários dela.
VTS
O
pacote de testes de fornecedor foi lançado junto com o Treble.

APIs de câmera

O Android inclui as seguintes APIs de câmera.

API Camera1

O Android 5.0 descontinuou a API Camera1, que continua sendo desativada à medida que o novo desenvolvimento da plataforma se concentra na API Camera2. No entanto, o período de descontinuação será longo, e as versões do Android continuarão oferecendo suporte aos apps da API Camera1 por algum tempo. Especificamente, o suporte continua para:

  • Interfaces da API Camera1 para apps. Os apps de câmera criados com base na API 1 da câmera devem funcionar como em dispositivos com versões mais antigas do Android.
  • Versões da HAL da câmera. Inclui suporte para Camera HAL 1.0.

API Camera2

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

O Android 5.0 e versões mais recentes incluem a API Camera2, mas os dispositivos com essas versões podem não oferecer suporte a todos os recursos da API. 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 aos apps pelas interfaces da API Camera2, que são aproximadamente os mesmos recursos expostos aos apps pelas interfaces da API Camera1. O conceito de código dos frameworks legados traduz conceitualmente as chamadas da API Camera2 em chamadas da API Camera1. Os dispositivos legados não são compatíveis com recursos da API Camera2, como controles por frame.
  • LIMITED: esses dispositivos são compatíveis com alguns recursos da API Camera2 (mas não todos) e precisam usar o HAL 3.2 da câmera ou uma versão mais recente.
  • FULL: esses dispositivos são compatíveis com todos os principais recursos da API Camera2 e precisam usar a HAL da câmera 3.2 ou mais recente e o Android 5.0 ou mais recente.
  • LEVEL_3: esses dispositivos são compatíveis com o reprocessamento de YUV e a captura de imagens RAW, além de outras configurações de stream de saída.
  • EXTERNAL: esses dispositivos são semelhantes aos LIMITED, com algumas exceções. Por exemplo, algumas informações de sensor ou lente podem não ser informadas ou ter taxas de frames 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 Camera API2. Os dispositivos FULL exigem os recursos MANUAL_SENSOR e MANUAL_POST_PROCESSING, entre outros. A funcionalidade RAW é opcional, mesmo para dispositivos FULL. Os dispositivos LIMITED podem anunciar qualquer subconjunto desses recursos, incluindo nenhum deles. No entanto, a capacidade BACKWARD_COMPATIBLE sempre precisa ser definida.

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

  • 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 do CTS da API1 e API2 da câmera e do CTS Verifier.

Os dispositivos que não têm uma implementação do HAL3.2 de câmera e não são capazes de oferecer suporte a todas as interfaces da API Camera2 ainda precisam passar nos testes do 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 do CTS da API Camera2 relacionados a recursos ou capacidades além da API Camera1 são ignorados automaticamente.

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

Requisitos do VTS

Os dispositivos que executam o Android 8.0 e versões mais recentes com implementações de HAL binderizadas precisam passar nos testes VTS da câmera.

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

Para reforçar a segurança da mídia e do framework da câmera, o Android 7.0 move o serviço de câmera para fora do mediaserver. A partir do Android 8.0, cada HAL de câmera binderizado é executado em um processo separado do serviço de câmera. Os fornecedores talvez precisem 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 nas AP1 e AP2 para HAL1 e HAL3, além dos requisitos gerais.

Mudanças arquitetônicas para a API1

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

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

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

    Figura 1. Câmera e pilha de mídia 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. (kMetadataBufferTypeCameraSource não é mais compatível com o Android 7.0.)

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

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

Mudanças arquitetônicas para a API2

Para API2 no HAL1 ou HAL3, o BufferQueue transmite 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. Pilha de mídia e câmera do Android 7.0 na API2 no HAL3

Outros requisitos

As mudanças arquitetônicas feitas para reforçar a segurança da mídia e da estrutura da câmera incluem os seguintes requisitos adicionais do dispositivo.

  • Geral. Os dispositivos exigem mais largura de banda devido à 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 app Google Câmera para gravação de vídeo em alta velocidade de 120/240 FPS. Os dispositivos também precisam de 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 frame YUV reais em buffers de vídeo, ele precisará usar kMetadataBufferTypeNativeHandleSource como o tipo de buffer de metadados e transmitir VideoNativeHandleMetadata em buffers de vídeo. (kMetadataBufferTypeCameraSource não é mais compatível com o Android 7.0.) Com o VideoNativeHandleMetadata, as estruturas 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 eles podem armazenar outro identificador de buffer depois que o HAL retorna o buffer. Atualize a HAL para usar identificadores de buffer e identificar os buffers. Por exemplo, a HAL recebe um endereço A de identificador de buffer, que armazena o identificador de buffer A. Depois que a HAL retorna o identificador de buffer A, o endereço do identificador de buffer A pode armazenar o identificador de buffer B na próxima vez que a HAL o receber.
  • Atualize as 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, atualize as políticas do SELinux para conceder permissões adequadas ao cameraserver. Não recomendamos replicar as políticas do SELinux do mediaserver para o cameraserver, já que eles geralmente exigem recursos diferentes no sistema. O cameraserver só pode ter as permissões necessárias para realizar funcionalidades de 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 servidor de câmera. O Android 8.0 e versões mais recentes também separam a HAL de 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 CTS do Android 7.0. Embora o Android 7.0 não inclua novos testes do CTS que verificam mudanças no serviço de câmera, os testes atuais 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 ou 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 Lista de verificação de testes da HAL da câmera.

Android 10

O Android 10 traz as seguintes atualizações.

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 da câmera para um ID de câmera física que apoia um dispositivo de câmera lógica. Consulte Compatibilidade com várias câmeras.
  • isStreamCombinationSupported: esse método oferece suporte a uma API pública que ajuda os clientes a consultar se uma configuração de sessão é compatível. Consulte API para consultar combinações de streams.

ICameraDeviceSession

  • isReconfigurationNeeded: Método que informa ao framework da câmera se uma 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 da 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 com os 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 de câmera está prestes a executar configureStreams_3_5 e que a HAL precisa retornar todos os buffers de 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 a HAL da câmera chama para pedir buffers ao servidor da câmera. Consulte requestStreamBuffers.
  • returnStreamBuffers: Callback síncrono para o HAL da câmera retornar buffers de saída ao servidor de 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 de stream 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 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 de câmera foram atualizadas no Android 10.

2.5

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

2.4

  • 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 introduz as seguintes atualizações na API2 da câmera e na interface HAL.

API da câmera

  • Apresenta a API de várias câmeras para oferecer melhor suporte a dispositivos com várias câmeras apontando na mesma direção, permitindo recursos como bokeh e zoom contínuo. Isso permite que os apps vejam 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 Compatibilidade com várias câmeras.
  • Apresenta os parâmetros de sessão. Os parâmetros de sessão são um subconjunto dos parâmetros de captura disponíveis que podem causar atrasos graves no processamento quando modificados. Esses custos podem ser reduzidos 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, na sigla em inglês) 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 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 para 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.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

O lançamento do Android 8.0 introduz o Treble. Com o Treble, as implementações de HAL da câmera do fornecedor precisam ser binderizadas. O Android 8.0 também contém estas melhorias principais no serviço de Câmera:

  • Superfícies compartilhadas: permitem 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 mais informações sobre esses recursos.

Superfícies compartilhadas

Esse recurso permite que apenas um conjunto de buffers acione duas saídas, como prévia 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 as implementações de HAL da câmera 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 transmite as flags de uso do consumidor para a HAL da câmera e a HAL do gralloc. Elas precisam alocar os tipos certos de buffers ou a HAL da câmera precisa retornar um erro informando que essa combinação de consumidores não é compatível.

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

API do sistema para modos de câmera personalizados

A API pública de câmera define dois modos de operação: gravação normal e de alta velocidade restrita. Elas têm semânticas bem 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. Por baixo dos panos, 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 conflitos com modos futuros adicionados à API pública.

Para oferecer suporte a esse recurso, os OEMs só precisam adicionar o novo modo ao HAL, acionado por esse número inteiro transmitido ao HAL em configure_streams, e 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 zoom, mantendo a fila de solicitações o mais vazia possível. onCaptureQueueEmpty não exige trabalho de HAL. É apenas uma adição do lado do framework. Os apps que quiserem aproveitar esse recurso precisam adicionar um listener a esse callback e responder de maneira adequada. Geralmente, isso é feito enviando outra solicitação de captura para o dispositivo de 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 em HIDL. Todos os recursos e funcionalidades da 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 de HIDL.

3.4

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

  • Adicione metadados estáticos ANDROID_SENSOR_OPAQUE_RAW_SIZE como obrigatórios se o formato RAW_OPAQUE for compatível.
  • Adicione metadados estáticos ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE como obrigatórios se algum formato RAW for compatível.
  • Mude 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 do espaço de 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 da API de reprocessamento OPAQUE e YUV.
  • 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 de fluxo camera3 a camera3_stream_configuration_t.

3.2

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

  • Descontinua get_metadata_vendor_tag_ops. Use get_vendor_tag_ops em camera_common.h.
  • Descontinua register_stream_buffers. Todos os buffers gralloc fornecidos pelo framework para a HAL em process_capture_request podem ser novos a qualquer momento.
  • Adição de 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 um modelo manual a camera3_request_template. Os apps podem usar esse modelo para controlar as configurações de captura diretamente.
  • Refaça 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 secundária do HAL de capacidade expandida:

  • O configure_streams transmite flags 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 capacidade expandida:

  • Mudança na versão principal porque a ABI é completamente diferente. Não há mudanças nos recursos de hardware ou no modelo operacional necessários da versão 2.0.
  • Interfaces de solicitação de entrada e fila de stream reformuladas: o framework chama o HAL com a próxima solicitação e buffers de stream já removidos da fila. O suporte ao framework de sincronização está incluído e é necessário para implementações eficientes.
  • Movemos os gatilhos para solicitações e a maioria das notificações para resultados.
  • Consolidei todos os callbacks no framework em uma estrutura e todos os métodos de configuração em uma única chamada initialize().
  • Transformamos a configuração de stream em uma única chamada para simplificar o gerenciamento. Fluxos bidirecionais substituem a construção STREAM_FROM_STREAM.
  • Semântica do modo limitado para dispositivos de hardware mais antigos/limitados.

2.0

Versão 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 manual de captura, captura Bayer RAW, reprocessamento de dados RAW etc.

1.0

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

  • Convertida da camada de abstração C++ CameraHardwareInterface.
  • Compatível com a API android.hardware.Camera.

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

Esta seção contém informações sobre o controle de versões do módulo de hardware da câmera, com base em camera_module_t.common.module_api_version. Os dois dígitos hexadecimais mais significativos representam a versão principal, e os dois menos significativos representam a versão secundária.

2.4

Esta versão do módulo de câmera adiciona as seguintes mudanças na API:

  1. Compatibilidade com o modo de lanterna. O framework pode ativar o modo de lanterna para qualquer dispositivo de câmera com flash sem abrir o dispositivo. O dispositivo de câmera tem uma prioridade maior de acesso à unidade de flash do que o módulo de câmera. Abrir um dispositivo de câmera desativa a lanterna se ela tiver sido ativada pela interface do módulo. Quando há conflitos de recursos, como open() sendo 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 iluminação que o modo foi desativado.
  2. Suporte para câmera externa (por exemplo, câmera USB hot-plug). As atualizações da API especificam que as informações estáticas da câmera só estão disponíveis quando ela está conectada e pronta para uso em câmeras externas com hot-plug. As chamadas para receber informações estáticas são inválidas quando o status da câmera não é CAMERA_DEVICE_STATUS_PRESENT. O framework conta apenas com 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 sempre ser definidos na estrutura camera_info retornada pela chamada get_camera_info.
  4. Método de inicialização do módulo. Chamado pelo serviço de câmera depois que o módulo HAL é carregado para permitir a inicialização única da HAL. Ele é chamado antes de qualquer outro método do módulo ser invocado.

2.3

Esta versão do módulo de câmera adiciona suporte a dispositivos HAL de câmera legada aberta. A estrutura pode usar isso para abrir o dispositivo de câmera como uma versão HAL de dispositivo inferior HAL se o mesmo dispositivo for compatível com várias versões da API do dispositivo. A chamada aberta do módulo de hardware padrão (common.methods->open) continua abrindo o dispositivo de câmera com a versão compatível mais recente, que também é a versão listada em camera_info_t.device_version.

2.2

Essa versão do módulo de câmera adiciona suporte a tags de fornecedor do módulo e descontinua as antigas vendor_tag_query_ops que antes só eram acessíveis com um dispositivo aberto.

2.1

Esta versão do módulo de 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 de 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 de 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 por esse módulo podem oferecer suporte à versão 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 superior.

1.0

Os módulos de câmera que informam esses números de versão implementam a interface inicial HAL do módulo de câmera. Todos os dispositivos de câmera que podem ser abertos por este módulo oferecem suporte apenas à versão 1 do HAL do dispositivo de câmera. 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 compatível com esse módulo e os dispositivos dele.