Suporte à versão da câmera

Esta página detalha as diferenças de versão em HALs de câmera, APIs e Testes do conjunto de teste de compatibilidade (CTS). Ele também abrange vários mudanças na arquitetura para fortalecer e proteger o framework da câmera no Android. 7.0, a mudança para o Treble no Android 8.0, e os fornecedores de atualizações precisam fazer oferecem suporte a essas alterações 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. usando a 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 por fornecedores de SoC. O público no nível do app são construídos sobre a 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 API1 da câmera
Conjunto de testes CTS da câmera executados na câmera API1
CTS da API2 da câmera
Conjunto adicional de testes de CTS da câmera executados com base na API Camera2.
Agudo
Separa a implementação do fornecedor (software específico do dispositivo e de nível mais baixo) escritos por fabricantes de silício) do framework do SO Android por uma nova interface do fornecedor.
HIDL
Linguagem de definição da interface HAL introduzido com o Treble e usado para especificar a interface entre uma HAL e e seus usuários.
VTS
Pacote de testes de fornecedor introduzido junto com Agudo.

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 como novo o desenvolvimento de plataformas se concentra na API2 Camera. No entanto, o período de descontinuação ser demorada, e as versões do Android continuarão a oferecer suporte a apps da API1 Camera para algum tempo. Mais especificamente, o suporte continua disponível para:

  • Interfaces de câmera API1 para apps. Apps de câmera criados na parte de cima da câmera A API1 funciona da mesma forma que em dispositivos com versões anteriores do Android.
  • Versões da HAL da câmera. Inclui suporte à câmera HAL1.0.

API 2 da câmera

O framework da API Camera2 expõe o controle da câmera de nível inferior ao app. incluindo fluxos de burst/streaming de cópia zero eficientes e controles por frame do exposição, ganho, ganhos de balanço de branco, conversão de cor, remoção de ruído, nitidez, e muito mais. Para mais detalhes, assista ao Visão geral em vídeo do Google I/O (em inglês).

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

  • LEGACY: esses dispositivos expõem recursos aos apps pela Interfaces da API2 Camera que têm aproximadamente os mesmos recursos que as expostos a apps pelas interfaces da API1 Camera. O código de frameworks legados converte conceitualmente chamadas da Camera API2 em chamadas da Camera API1; dispositivos legados não têm suporte para recursos da API2 da câmera, como controles por frame.
  • LIMITED: esses dispositivos oferecem suporte a alguns recursos da API2 Camera. (mas não todos) e precisa usar a câmera HAL 3.2 ou mais recente.
  • FULL: esses dispositivos são compatíveis com as principais funcionalidades do Camera API2 e precisa 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 YUV e imagens RAW captura, além de configurações adicionais de fluxo de saída.
  • EXTERNAL: esses dispositivos são semelhantes a LIMITED dispositivos, com algumas exceções. Por exemplo, algumas informações de sensores ou lentes podem não ser relatado ou ter taxas de quadros menos estáveis. Esse nível é usado para aplicativos externos como webcams USB.

Capacidades individuais são expostas Propriedade android.request.availableCapabilities na API Camera2. do Google Cloud. Os dispositivos FULL exigem os atributos MANUAL_SENSOR e MANUAL_POST_PROCESSING, entre outros. A O recurso RAW é opcional mesmo para dispositivos FULL. LIMITED dispositivos podem anunciar qualquer subconjunto desses recursos, incluindo nenhuma delas. No entanto, o capability BACKWARD_COMPATIBLE sempre precisa ser definido.

O nível de hardware suportado do dispositivo, assim como a câmera específica as capacidades da API2 com suporte, estão disponíveis como as seguintes flags de recursos para permitir a filtragem do Google Play de apps de câmera da API2 da câmera.

  • 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

Dispositivos com o Android 5.0 e versões mais recentes precisam passar na API Camera1, CTS, Camera Testes de câmera API2 CTS e CTS Verifier.

Dispositivos que não têm uma implementação da câmera HAL3.2 e não são capaz de oferecer suporte a interfaces completas de API2 da Câmera ainda precisam passar o código Testes CTS da API2. No entanto, o dispositivo é executado na API2 Camera Modo LEGACY (em que as chamadas da API 2 da câmera são mapeadas conceitualmente) para chamadas da API1 da Câmera), de modo que todos os testes CTS da API2 da câmera relacionados a recursos ou recursos além da API1 da câmera são ignorados automaticamente.

Em dispositivos legados, os testes CTS da API2 Camera que são executados usam o as interfaces e recursos públicos da Camera API1 atuais sem novidades e cumprimento de requisitos regulatórios. Bugs que são expostos (e que causam uma falha de CTS da API2 da câmera) já estão presentes na HAL da câmera do dispositivo e, dessa forma, podem ser encontradas por apps da API1 Camera1. Não esperamos muitos insetos dessa natureza No entanto, esses bugs precisam ser corrigidos para passar nos testes CTS da API2 da câmera.

Requisitos de VTS

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

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 move a câmera fora do mediaserver. A partir do Android 8.0, cada câmera vinculada A HAL é executada em um processo separado do serviço da câmera. Os fornecedores podem precisar fazer mudanças na HAL da câmera, dependendo da versão da API e da HAL em uso. A as seções a seguir detalham as alterações arquitetônicas em AP1 e AP2 para a HAL1 e HAL3, além de requisitos gerais.

Mudanças na arquitetura da API1

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

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

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

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

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

    Figura 2. Câmera e mídia do Android 7.0 pilha em 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 para funcionar. A arquitetura do Android 7.0 para a API2 em:

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

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

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

Outros requisitos

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

  • Geral. Os dispositivos exigem mais largura de banda devido à IPC. o que pode afetar casos de uso de câmeras urgentes, como vídeos de alta velocidade gravação. Os fornecedores podem medir o impacto real realizando android.hardware.camera2.cts.PerformanceTest e a Câmera do Google app para gravação de vídeo de alta velocidade a 120/240 QPS. Os dispositivos também exigem uma uma pequena quantidade de RAM adicional para criar o novo processo.
  • Transmitir metadados em buffers de vídeo (somente HAL1). Se HAL1 armazena metadados em vez de dados de frames YUV reais em buffers de vídeo, a HAL precisa usar kMetadataBufferTypeNativeHandleSource como o buffer de metadados; e transmitir VideoNativeHandleMetadata em buffers de vídeo. (kMetadataBufferTypeCameraSource não é mais compatível com o Android 7.0. Com VideoNativeHandleMetadata, frameworks de mídia e câmera são capazes de passar os buffers de vídeo entre processos serializando e desserializando corretamente os identificadores nativos.
  • O endereço do identificador do buffer nem sempre armazena o mesmo buffer (somente HAL3). Para cada solicitação de captura, a HAL3 recebe endereços do buffer alças A HAL não pode usar os endereços para identificar buffers porque os endereços pode armazenar outro identificador de buffer depois que a HAL retornar o buffer. É necessário atualizar que a HAL use identificadores para identificar esses buffers. Por exemplo, a HAL recebe um identificador de buffer de endereço A, que armazena o identificador de buffer A. Depois que o HAL retornar o identificador de buffer A pode armazenar o identificador de buffer B na próxima vez que o pela HAL a recebe.
  • Atualização de políticas de SELinux para o servidor da câmera. Se Políticas SELinux específicas do dispositivo dão permissões de mediaserver para executar a câmera, atualize as políticas do SELinux para dar as permissões adequadas ao servidor de câmera. Qa desencorajar a replicação das políticas SELinux do mediaserver para o servidor da câmera (já que o mediaserver e o cameraserver geralmente exigem recursos diferentes no sistema. O Cameraserver deve ter apenas as permissões necessárias para executar a câmera funcionalidades e permissões desnecessárias relacionadas à câmera no mediaserver deve ser removido.
  • Separação entre a HAL da câmera e o servidor da câmera. Android As versões 8.0 e mais recentes também separam a HAL da câmera vinculada em um processo. diferente do servidor da câmera. A IPC passa pela definidas por HIDL.

Validação

Para todos os dispositivos que incluem câmera e executam o Android 7.0, verifique o implementação executando o Android 7.0 CTS. Embora o Android 7.0 não inclua Novos testes de CTS que verificam alterações no serviço de câmera, os testes CTS existentes falham caso não tenha feito as atualizações indicadas acima.

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

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

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

Android 10

O Android 10 apresenta 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,50

ICameraDevice

  • getPhysicalCameraCharacteristics: As informações da câmera estática para um ID de câmera física que apoia uma lógica dispositivo de câmera Consulte Compatibilidade com várias câmeras.
  • isStreamCombinationSupported: esse método oferece suporte a uma API que ajuda os clientes a consultar se a configuração de uma sessão é aceita. Consulte a API para consultar combinações de streams.

ICameraDeviceSession

  • isReconfigurationNeeded: Método que informa ao framework da câmera se a transmissão completa a reconfiguração é necessária para possíveis novos valores de parâmetro da sessão. Isso ajuda a evitar atrasos desnecessários na reconfiguração da câmera. Consulte Consulta de reconfiguração de sessão.
  • HAL APIs de gerenciamento de buffer: 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 capturar solicitações com os buffers associados em todo o pipeline da câmera. o que resulta em economias de memória potencialmente significativas.
    • signalStreamFlush: sinaliza à HAL que a câmera serviço está prestes a executar configureStreams_3_5 e que a HAL retornar todos os buffers dos streams designados.
    • configureStreams_3_5: semelhante a ICameraDevice3.4.configureStreams, mas em Além disso, o contador streamConfigCounter é fornecido para verificar se há uma disputa entre os configureStreams_3_5 e chamadas de signalStreamFlush.

Atualizações do ICameraDeviceCallback:

  • requestStreamBuffers: Callback síncrono que a HAL da câmera chama para solicitar ao servidor da câmera reservas. Consulte requestStreamBuffers.
  • returnStreamBuffers: Callback síncrono para a HAL da câmera retornar buffers de saída ao servidor da câmera. Consulte returnStreamBuffers.

3,40

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 ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT chave
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Configurações disponíveis do stream de profundidade dinâmica
    • 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,50

  • Adiciona o método notifyDeviceStateChange para os dispositivos notificarem a HAL da câmera quando mudanças físicas, como dobra, afetar a câmera e e roteamento de alto desempenho.

2,40

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

Android 9

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

API da câmera

  • Apresenta a API de várias câmeras para oferecer melhor suporte a dispositivos com várias câmeras voltadas para a mesma direção, ativando recursos como bokeh e zoom contínuo. Isso permite que os apps visualizem várias câmeras em um dispositivo como uma só unidade lógica (câmera lógica). As solicitações de captura também podem ser enviadas dispositivos de câmera incluídos por uma câmera lógica. Consulte Compatibilidade com várias câmeras.
  • Apresenta os parâmetros da sessão. Eles são um subconjunto parâmetros de captura disponíveis que podem causar grandes atrasos no processamento quando modificado. Esses custos podem ser atenuados se os clientes passarem 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 no nível do app e efeitos Consulte STATISTICS_OIS_SAMPLES.
  • Adiciona suporte para 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.
  • Foram adicionados modos de correção de distorção no CaptureRequest. Consulte DISTORTION_CORRECTION_MODE.
  • Adiciona suporte a câmeras externas USB/UVC em dispositivos compatíveis. Consulte INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

HAL da câmera

3,40

Atualizações de ICameraDeviceSession

Atualizações de ICameraDeviceCallback

3,30

As chaves a seguir foram adicionadas aos metadados da câmera no Android 9.

  • Recursos
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Tags de metadados da câmera
    • ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
    • ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE
    • ANDROID_DISTORTION_CORRECTION_AVAILABLE_MODES
    • ANDROID_LENS_POSE_REFERENCE
    • ANDROID_LENS_DISTORTION
    • ANDROID_REQUEST_AVAILABLE_SESSION_KEYS
    • ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS
    • ANDROID_STATISTICS_OIS_DATA_MODE
    • ANDROID_STATISTICS_OIS_TIMESTAMPS
    • ANDROID_STATISTICS_OIS_X_SHIFTS
    • ANDROID_STATISTICS_OIS_Y_SHIFTS

Android 8.0

A versão do Android 8.0 apresenta o Treble. Com o Treble, a HAL da câmera do fornecedor implementações precisam ser binderized. O Android 8.0 também contém estas melhorias importantes para o serviço Câmera:

  • Plataformas compartilhadas: ative várias plataformas que compartilham o mesmo. OutputConfiguration
  • API System para modos de câmera personalizados
  • onCaptureQueueEmpty

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

Plataformas compartilhadas

Esse recurso permite que apenas um conjunto de buffers gere duas saídas, como e codificação de vídeo, o que diminui o consumo de energia e memória. Para oferecem suporte a esse recurso, os fabricantes de dispositivos precisam garantir que a HAL da câmera e As implementações de HAL gralloc podem criar buffers gralloc que são usados por vários consumidores diferentes (como o compositor de hardware/GPU e o codificador), em vez de apenas um consumidor. O serviço de câmera passa pela sinalizações de uso do consumidor para a HAL da câmera e a HAL gralloc; eles precisam alocar os tipos certos de buffers, ou a HAL da câmera precisará retornar um erro que essa combinação de consumidores não é aceita.

Consulte a enableSurfaceSharing documentação do desenvolvedor para mais detalhes.

API System para modos de câmera personalizados

A API pública da câmera define dois modos de operação: normal e restrito. gravação em alta velocidade. Elas 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. Diversos Os OEMs manifestaram 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 uma personalizado. Esses modos precisam começar com um valor inteiro de 0x8.000 para evitar conflitos com modos futuros adicionados à API pública.

Para oferecer suporte a esse recurso, os OEMs só precisam adicionar o novo modo à HAL, acionadas por esse número inteiro, transmitidos à HAL em configure_streams e o app de câmera personalizado usam 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 das mudanças de controle, como o zoom, manter a fila de solicitações o mais vazia possível. onCaptureQueueEmpty não exige trabalho da HAL; foi puramente uma adição no lado da estrutura. Apps que quiser aproveitá-lo, é necessário adicionar um listener a esse callback adequadamente. Geralmente, isso é enviar outra solicitação de captura para a câmera dispositivo.

Interface HIDL da câmera

A interface HIDL da câmera é uma reformulação completa da interface HAL da câmera. que usa APIs estáveis definidas por HIDL. Todos os recursos e funcionalidades da câmera introduzido nas versões legadas mais recentes 3.4 e 2.4 (para a câmera ) também fazem parte das definições de HIDL.

3.4

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

  • Adicionar metadados estáticos ANDROID_SENSOR_OPAQUE_RAW_SIZE como obrigatórios se o formato RAW_OPAQUE for compatível.
  • Adicionar ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE estático metadados obrigatórios se qualquer formato RAW for compatível.
  • Mudar o campo camera3_stream_t data_space para um 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 de reprocessamento OPAQUE e YUV.
  • Suporte básico a buffers de saída de profundidade.
  • O campo data_space foi adicionado à camera3_stream_t.
  • O campo de rotação foi adicionado a camera3_stream_t.
  • Adição do modo de operação de configuração de stream da Camera3 ao camera3_stream_configuration_t:

3.2

Pequena revisão da HAL com capacidade expandida:

  • Descontinua o get_metadata_vendor_tag_ops. Usar get_vendor_tag_ops em camera_common.h.
  • Descontinua o register_stream_buffers. Todos os buffers gralloc fornecidos pelo framework à HAL em process_capture_request podem ser novos a qualquer momento.
  • Adiciona compatibilidade com resultados parciais. process_capture_result pode ser chamado várias vezes com um subconjunto dos resultados disponíveis antes da chamada resultado esteja disponível.
  • Adicionar modelo manual a camera3_request_template. Aplicativos pode usar esse modelo para controlar as configurações de captura diretamente.
  • Reformular 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

Pequena revisão da HAL com capacidade expandida:

  • O configure_streams transmite as sinalizações de uso do consumidor para a HAL.
  • chamada de saída para descartar todas as solicitações/buffers em trânsito o mais rápido possível.

3.0

Primeira revisão da HAL com capacidade expandida:

  • Mudança de versão importante, já que a ABI é completamente diferente. Nenhuma alteração no os recursos de hardware necessários ou o modelo operacional 2.0.
  • Interfaces de solicitação de entrada e fila de stream reformuladas: chamadas de framework na HAL com a próxima solicitação e buffers de stream já desenfileirados. Suporte a frameworks de sincronização necessário para implementações eficientes.
  • Acionadores movidos para solicitações, e a maioria das notificações para resultados.
  • Consolidou todos os callbacks em um framework em uma estrutura, com toda a configuração em uma única chamada initialize().
  • Fez a configuração de stream em uma única chamada para simplificar o gerenciamento do stream. Os streams bidirecionais substituem o STREAM_FROM_STREAM constroem.
  • Semântica de modo limitado para dispositivos de hardware mais antigos/limitados.

2.0

Versão inicial da HAL com capacidade expandida (Android 4.2) [camera2.h]:

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

1.0

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

  • Convertido 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 sobre controle de versões de módulos para o hardware Câmera módulo com base em camera_module_t.common.module_api_version. Os dois os dígitos hexadecimais mais significativos representam a versão principal e os dois menos significativos mais significativos representam a versão secundária.

2.4

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

  1. Compatibilidade com o modo tocha. O framework pode ativar o modo lanterna para qualquer dispositivo de câmera que tem uma unidade de flash, sem abrir o dispositivo de câmera. A dispositivo de câmera tem uma prioridade mais alta acessando a unidade de flash do que a câmera module; abrir um dispositivo de câmera desliga a lanterna, caso ela tenha 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 por meio do callback de status do modo de tocha que a lanterna foi desativado.
  2. Suporte para câmera externa (por exemplo, câmera com hot-plug USB). A As atualizações da API especificam que as informações estáticas da câmera só ficam disponíveis quando a câmera está conectado e pronto para uso em câmeras externas com hot-plug. Chamadas para receber estática as informações são chamadas inválidas quando o status da câmera não é CAMERA_DEVICE_STATUS_PRESENT: A estrutura 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 resource_cost e Os campos conflicting_devices sempre devem ser definidos no Estrutura camera_info retornada pelo get_camera_info a chamada.
  4. Método de inicialização do módulo. Chamado pelo serviço de câmera após o carregamento do módulo HAL 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 para dispositivos HAL de câmera legada aberta. O framework pode usá-lo para abrir a câmera como uma versão anterior da HAL do dispositivo. Dispositivo HAL se o mesmo dispositivo oferecer suporte a várias versões da API do dispositivo. A chamada de abertura do módulo de hardware padrão (common.methods->open) continua para abrir a câmera com a versão suportada mais recente, 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 à tag de fornecedor no módulo e descontinua o antigo vendor_tag_query_ops, que antes só era usado acessíveis com um dispositivo aberto.

2.1

Esta versão do módulo de câmera adiciona suporte para callbacks assíncronos ao 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 endereço O método set_callbacks() precisa 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 da câmera. Dispositivos de câmera que podem ser abertos por este pode ser compatível com a versão 1.0 ou 2.0 do dispositivo de câmera HAL. O campo device_version de camera_info é sempre válido no campo static_camera_characteristics do camera_info será 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 HAL do módulo da câmera. Todos os dispositivos de câmera podem ser abertos com este oferecem suporte somente à versão 1 da HAL do dispositivo de câmera. A device_version e static_camera_characteristics campos de camera_info não são válidos. Somente o A API android.hardware.Camera pode ser suportada por este módulo e o dispositivos.