Google은 흑인 공동체를 위한 인종 간 평등을 진전시키기 위해 노력하고 있습니다. Google에서 어떤 노력을 하고 있는지 확인하세요.

카메라 버전 지원

이 페이지에서는 카메라 HAL, API 및 관련 호환성 테스트 도구 모음(CTS) 테스트의 버전 차이를 자세히 설명합니다. 또한 Android 7.0의 카메라 프레임워크를 강화하고 보호하기 위한 여러 아키텍처 변경사항, Android 8.0에서 Treble로의 전환, 그리고 카메라 구현에서 이러한 변경사항을 지원하기 위해 제공업체에서 수행해야 하는 업데이트에 관해 다룹니다.

용어

이 페이지에서 사용되는 용어는 다음과 같습니다.

카메라 API1
Android 4.4 이하 기기의 앱 수준 카메라 프레임워크로, android.hardware.Camera 클래스를 통해 노출됩니다.
카메라 API2
Android 5.0 이상 기기의 앱 수준 카메라 프레임워크로, android.hardware.camera2 패키지를 통해 노출됩니다.
카메라 HAL
SoC 제공업체에서 구현하는 카메라 모듈 레이어입니다. 앱 수준 공개 프레임워크는 카메라 HAL을 기반으로 하여 빌드됩니다.
카메라 HAL3.1
Android 4.4에서 출시된 카메라 기기 HAL 버전입니다.
카메라 HAL3.2
Android 5.0에서 출시된 카메라 기기 HAL 버전입니다.
카메라 API1 CTS
카메라 API1에서 실행되는 카메라 CTS 테스트 세트입니다.
카메라 API2 CTS
카메라 API2에서 실행되는 추가적인 카메라 CTS 테스트 세트입니다.
Treble
새로운 제공업체 인터페이스를 통해 제공업체 구현(실리콘 제조업체에서 작성한 기기별 하위 수준 소프트웨어)을 Android OS 프레임워크로부터 분리합니다.
HIDL
Treble과 함께 도입된 HAL 인터페이스 정의 언어로서 HAL과 사용자 간의 인터페이스를 지정하는 데 사용됩니다.
VTS
Treble과 함께 도입된 제공업체 테스트 도구 모음입니다.

카메라 API

Android에는 다음과 같은 카메라 API가 포함됩니다.

카메라 API1

Android 5.0에서는 카메라 API1의 지원이 중단되었으며, 이는 카메라 API2에 중점을 둔 새로운 플랫폼을 개발함에 따라 단계적으로 중단됩니다. 그러나 단계적 중단 기간은 길어질 예정이며 Android 릴리스에서는 카메라 API1 앱을 일정 기간 계속 지원합니다. 구체적으로 다음에 대한 지원이 계속됩니다.

  • 앱용 카메라 API1 인터페이스: 카메라 API1을 기반으로 빌드된 카메라 앱은 더 낮은 Android 릴리스 버전을 실행 중인 기기에서와 마찬가지로 작동합니다.
  • 카메라 HAL 버전: 카메라 HAL1.0에 대한 지원이 포함됩니다.

카메라 API2

카메라 API2 프레임워크는 효율적인 제로 카피 버스트/스트리밍 흐름, 프레임별 노출 제어, 게인, 화이트 밸런스 게인, 색상 변환, 노이즈 제거, 선명화 등 하위 수준의 카메라 제어를 앱에 노출합니다. 자세한 내용은 Google I/O 동영상 개요를 참조하세요.

Android 5.0 이상에는 카메라 API2가 포함되어 있습니다. 그러나 Android 5.0 이상을 실행하는 기기는 일부 카메라 API2 기능을 지원하지 않을 수도 있습니다. 앱이 카메라 API2 인터페이스를 통해 쿼리할 수 있는 android.info.supportedHardwareLevel 속성은 다음 지원 수준 중 하나를 보고합니다.

  • LEGACY: 이러한 기기는 카메라 API1 인터페이스를 통해 앱에 노출되는 것과 대체로 동일한 기능을 카메라 API2 인터페이스를 통해 앱에 노출합니다. 기존 프레임워크 코드는 개념적으로 카메라 API2 호출을 카메라 API1 호출로 변환합니다. 기존 기기는 프레임별 제어와 같은 카메라 API2 기능을 지원하지 않습니다.
  • LIMITED: 이러한 기기는 일부 카메라 API2 기능을 지원하며 카메라 HAL 3.2 이상을 사용해야 합니다.
  • FULL: 이러한 기기는 카메라 API2의 모든 주요 기능을 지원하며 카메라 HAL 3.2 이상 및 Android 5.0 이상을 사용해야 합니다.
  • LEVEL_3: 이러한 기기는 YUV 재처리 및 RAW 이미지 캡처 외에도 더 많은 출력 스트림 구성을 지원합니다.
  • EXTERNAL: 이러한 기기는 LIMITED 기기와 유사하지만 몇 가지 예외가 있습니다. 예를 들어 일부 센서 또는 렌즈 정보가 보고되지 않거나 프레임 속도가 안정적이지 않을 수 있습니다. 이 수준은 USB 웹캠과 같은 외장 카메라에 사용됩니다.

개별 기능은 카메라 API2 인터페이스의 android.request.availableCapabilities 속성을 통해 노출됩니다. FULL 기기에는 특히 MANUAL_SENSORMANUAL_POST_PROCESSING 기능이 필요합니다. RAW 기능은 FULL 기기에서도 선택사항입니다. LIMITED 기기는 이러한 기능의 하위 집합을 광고하거나 광고하지 않을 수 있습니다. 하지만 BACKWARD_COMPATIBLE 기능은 항상 정의되어야 합니다.

기기에서 지원되는 하드웨어 수준 및 특정 카메라 API2 기능은 카메라 API2 카메라 앱의 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

CTS 요구사항

Android 5.0 이상을 실행하는 기기는 카메라 API1 CTS, 카메라 API2 CTS 및 CTS 인증기 카메라 테스트를 통과해야 합니다.

카메라 HAL3.2 구현을 제공하지 않으며 전체 카메라 API2 인터페이스를 지원할 수 없는 기기이더라도 카메라 API2 CTS 테스트를 통과해야 합니다. 하지만 기기는 카메라 API2 호출을 개념적으로 카메라 API1 호출로 매핑하는 카메라 API2 LEGACY 모드로 실행되므로 카메라 API1을 넘어서는 기능과 관련된 카메라 API2 CTS 테스트는 자동으로 건너뜁니다.

기존 기기에서 실행되는 카메라 API2 CTS 테스트는 새로운 요구사항이 없는 기존의 공개 카메라 API1 인터페이스와 기능을 사용합니다. 카메라 API2 CTS 오류의 원인이 되는 버그는 기기의 기존 카메라 HAL에 이미 존재하는 버그이므로 기존 카메라 API1 앱에서도 발견됩니다. 이러한 버그는 많지 않을 것으로 예상되지만 카메라 API2 CTS 테스트를 통과하려면 버그를 수정해야 합니다.

VTS 요구사항

Android 8.0 이상에서 바인더화된 HAL 구현을 실행하는 기기는 카메라 VTS 테스트를 통과해야 합니다.

카메라 프레임워크 강화

미디어 및 카메라 프레임워크 보안을 강화하기 위해 Android 7.0에서는 카메라 서비스를 미디어 서버에서 분리합니다. Android 8.0부터 바인더화된 각 카메라 HAL은 카메라 서비스로부터 독립된 프로세스로 실행됩니다. 제공업체는 사용 중인 API 및 HAL 버전에 따라 카메라 HAL을 변경해야 할 수도 있습니다. 다음 섹션에서는 HAL1 및 HAL3에 관한 AP1 및 AP2의 아키텍처 변경사항과 일반적인 요구사항을 설명합니다.

API1의 아키텍처 변경사항

API1 동영상 녹화는 카메라 및 동영상 인코더가 동일한 프로세스에 있다고 가정할 수 있습니다. API1 사용 위치:

  • HAL3: 카메라 서비스가 BufferQueue를 사용하여 프로세스 간에 버퍼를 전달하므로 제공업체 업데이트가 필요하지 않습니다.

    HAL3에 위치한 API1의 Android 7.0 카메라 및 미디어 스택

    그림 1. HAL3에 위치한 API1의 Android 7.0 카메라 및 미디어 스택

  • 동영상 버퍼에서 메타데이터 전달을 지원하는 HAL1의 경우 제공업체는 kMetadataBufferTypeNativeHandleSource를 사용하기 위해 HAL을 업데이트해야 합니다. (kMetadataBufferTypeCameraSource는 Android 7.0에서 더 이상 지원되지 않습니다.)

    HAL1에 위치한 API1의 Android 7.0 카메라 및 미디어 스택

    그림 2. HAL1에 위치한 API1의 Android 7.0 카메라 및 미디어 스택

API2의 아키텍처 변경사항

HAL1 또는 HAL3에 위치한 API2의 경우 BufferQueue가 버퍼를 전달하므로 해당 경로는 계속 유효합니다. API2용 Android 7.0 아키텍처의 위치는 다음과 특징이 있습니다.

  • HAL1: cameraservice 이동의 영향을 받지 않으며 제공업체 업데이트가 필요하지 않습니다.
  • HAL3: 영향을 받지만 제공업체 업데이트는 필요하지 않습니다.

    HAL3에 위치한 API2의 Android 7.0 카메라 및 미디어 스택

    그림 3. HAL3에 위치한 API2의 Android 7.0 카메라 및 미디어 스택

추가 요구사항

미디어 및 카메라 프레임워크 보안 강화를 위한 아키텍처 변경사항에는 다음과 같은 추가 기기 요구사항이 있습니다.

  • 일반: IPC로 인해 기기에서 추가 대역폭을 필요로 하며 이는 고속 동영상 녹화와 같이 시간이 중요한 카메라 사용 사례에 영향을 줄 수 있습니다. 제공업체는 android.hardware.camera2.cts.PerformanceTest와 Google 카메라 앱을 실행하여 120/240FPS 고속 동영상 녹화 시 받는 실제 영향을 측정할 수 있습니다. 또한 기기에는 새 프로세스를 만들기 위한 소량의 추가 램이 필요합니다.
  • 메타데이터를 동영상 버퍼에 전달(HAL1만 해당): HAL1이 실제 YUV 프레임 데이터 대신 메타데이터를 동영상 버퍼에 저장하는 경우 HAL은 메타데이터 버퍼 유형으로 kMetadataBufferTypeNativeHandleSource를 사용하여 동영상 버퍼에 VideoNativeHandleMetadata를 전달해야 합니다. (kMetadataBufferTypeCameraSource는 Android 7.0에서 더 이상 지원되지 않습니다.) VideoNativeHandleMetadata를 사용하면 카메라 및 미디어 프레임워크가 네이티브 핸들을 적절하게 직렬화 및 역직렬화하여 프로세스 간에 동영상 버퍼를 전달할 수 있습니다.
  • 버퍼 핸들 주소가 항상 동일한 버퍼를 저장하지는 않음(HAL3만 해당): HAL3은 각 캡처 요청 시 버퍼 핸들의 주소를 가져옵니다. 주소는 HAL이 버퍼를 반환한 이후에 다른 버퍼 핸들을 저장할 수 있으므로 HAL은 주소를 사용하여 버퍼를 식별할 수 없습니다. 버퍼 핸들을 사용하여 버퍼를 식별하려면 HAL을 업데이트해야 합니다. 예를 들어 HAL은 버퍼 핸들 A를 저장하는 버퍼 핸들 주소 A를 수신합니다. HAL이 버퍼 핸들 A를 반환한 후 버퍼 핸들 주소 A는 다음 번에 HAL에서 수신할 때 버퍼 핸들 B를 저장할 수 있습니다.
  • Cameraserver용 SELinux 정책 업데이트: 기기별 SELinux 정책에서 카메라 실행 권한을 mediaserver에 부여하는 경우 SELinux 정책을 업데이트해야 cameraserver에 적절한 권한을 부여할 수 있습니다. cameraserver와 관련하여 mediaserver의 SELinux 정책을 복제하는 것은 권장하지 않습니다. 일반적으로 mediaserver와 cameraserver는 시스템에서 다른 리소스를 필요로 하기 때문입니다. cameraserver에는 카메라 기능을 실행하는 데 필요한 권한만 있어야 하며 mediaserver에 있는 불필요한 카메라 관련 권한은 삭제해야 합니다.
  • 카메라 HAL과 cameraserver 간 분리: Android 8.0 이상에서는 바인더화된 카메라 HAL이 cameraserver와는 다른 프로세스에서 추가로 분리됩니다. IPC는 HIDL에서 정의한 인터페이스를 통과합니다.

유효성 검사

카메라가 있고 Android 7.0을 실행하는 모든 기기의 경우 Android 7.0 CTS를 실행하여 구현을 확인합니다. Android 7.0에는 카메라 서비스 변경사항을 확인하는 새로운 CTS 테스트가 포함되어 있지 않지만, 위와 같이 업데이트하지 않으면 기존 CTS 테스트는 실패합니다.

카메라가 있고 Android 8.0 이상을 실행하는 모든 기기의 경우 VTS를 실행하여 제공업체 구현을 확인합니다.

카메라 HAL 버전 기록

Android 카메라 HAL을 평가하는 데 사용할 수 있는 테스트의 목록은 카메라 HAL 테스트 체크리스트를 참조하세요.

Android 10

Android 10에서는 다음과 같은 업데이트가 도입되었습니다.

카메라 API

카메라 HAL

다음 Camera HAL 버전은 Android 10에서 업데이트됩니다.

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics: 로지컬 카메라 기기를 지원하는 피지컬 카메라 ID에 관한 정적 카메라 정보입니다. 다중 카메라 지원을 참조하세요.
  • isStreamCombinationSupported: 이 메서드는 클라이언트가 세션 구성이 지원되는지 쿼리하는 데 도움이 되는 공개 API를 지원합니다. 스트림 조합을 쿼리하기 위한 API를 참조하세요.

ICameraDeviceSession

  • isReconfigurationNeeded: 사용할 수 있는 새 세션 매개변수 값에 전체 스트림 재구성이 필요한지 카메라 프레임워크에 알려주는 메서드입니다. 이렇게 하면 불필요한 카메라 재구성으로 인한 지연을 방지할 수 있습니다. 세션 재구성 쿼리를 참조하세요.
  • HAL 버퍼 관리 API: 이러한 API는 카메라 HAL이 각 캡처 요청을 카메라 파이프라인 전반의 관련 버퍼와 연결하는 대신 필요할 때만 카메라 프레임워크에서 버퍼를 요청하여 메모리를 크게 절약할 수 있습니다.
    • signalStreamFlush: 카메라 서비스가 configureStreams_3_5를 수행하고자 하며 HAL이 지정된 스트림의 모든 버퍼를 반환해야 한다고 HAL에 신호를 보냅니다.
    • configureStreams_3_5: ICameraDevice3.4.configureStreams와 유사하지만, 이와는 별개로 streamConfigCounter 카운터가 제공되어 configureStreams_3_5 호출과 signalStreamFlush 호출 간에 경합 상태가 있는지 확인합니다.

ICameraDeviceCallback 업데이트:

  • requestStreamBuffers: 카메라 HAL이 카메라 서버에 버퍼를 요청하기 위해 호출하는 동기식 콜백입니다. requestStreamBuffers를 참조하세요.
  • returnStreamBuffers: 카메라 HAL이 출력 버퍼를 카메라 서버에 반환하기 위한 동기식 콜백입니다. returnStreamBuffers를 참조하세요.

3.4

다음 키는 Android 10의 카메라 메타데이터에 추가됩니다.

  • 이미지 형식
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • 카메라 메타데이터 태그
    • 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
  • 기능
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT 키 값
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • 사용 가능한 다이내믹 포커스 스트림 구성
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • 사용 가능한 HEIC 스트림 구성
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

카메라 모듈

다음 카메라 모듈 버전이 Android 10에서 업데이트되었습니다.

2.5

  • 접기와 같은 물리 변화로 인해 카메라 및 라우팅에 영향을 줄 때 기기에서 카메라 HAL에 알릴 수 있도록 notifyDeviceStateChange 메서드를 추가합니다.

2.4

  • API 수준 29 이상과 함께 출시되는 기기는 isTorchModeSupported에서 true를 보고해야 합니다.

Android 9

Android 9 릴리스에서는 카메라 API2 및 HAL 인터페이스가 다음과 같이 업데이트되었습니다.

카메라 API

  • 동일한 방향을 바라보는 여러 카메라를 갖춘 기기에 대한 지원을 강화하고자 다중 카메라 API를 도입하여 보케와 끊김 없는 줌과 같은 기능을 지원합니다. 이렇게 하면 앱에서 기기의 여러 카메라를 하나의 논리 단위(로지컬 카메라)로 볼 수 있습니다. 캡처 요청은 하나의 로지컬 카메라에 포함된 개별 카메라 기기로 전송될 수도 있습니다. 다중 카메라 지원을 참조하세요.
  • 세션 매개변수를 도입합니다. 세션 매개변수는 사용 가능한 캡처 매개변수의 하위 세트로, 수정 시 심각한 처리 지연을 유발할 수 있습니다. 클라이언트가 캡처 세션 초기화 중에 초기값을 전달하면 이러한 비용을 줄일 수 있습니다. 세션 매개변수를 참조하세요.
  • 앱 수준 안정화 및 효과를 위해 광학 안정화(OIS) 데이터 키를 추가합니다. STATISTICS_OIS_SAMPLES를 참조하세요.
  • 외장 플래시 지원을 추가합니다. CONTROL_AE_MODE_ON_EXTERNAL_FLASH를 참조하세요.
  • 모션 추적 의도를 CAPTURE_INTENT에 추가합니다. CONTROL_CAPTURE_INTENT_MOTION_TRACKING을 참조하세요.
  • LENS_RADIAL_DISTORTION은 지원 중단되며 그 대신 LENS_DISTORTION을 추가합니다.
  • 왜곡 수정 모드를 CaptureRequest에 추가합니다. DISTORTION_CORRECTION_MODE를 참조하세요.
  • 지원되는 기기에 외장 USB/UVC 카메라 지원을 추가합니다. INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL을 참조하세요.

카메라 HAL

3.4

ICameraDeviceSession 업데이트

ICameraDeviceCallback 업데이트

3.3

다음 키는 Android 9의 카메라 메타데이터에 추가됩니다.

  • 기능
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • 카메라 메타데이터 태그
    • 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

Android 8.0 릴리스에는 Treble이 도입되었습니다. Treble을 사용하는 경우 제공업체 카메라 HAL 구현이 바인더화되어야 합니다. Android 8.0에는 카메라 서비스의 다음과 같은 주요 개선사항도 포함되어 있습니다.

  • 표면 공유: 여러 표면에서 동일한 OutputConfiguration 공유
  • 맞춤 카메라 모드용 시스템 API
  • onCaptureQueueEmpty

이러한 기능에 관한 자세한 내용은 아래 섹션을 참조하세요.

표면 공유

이 기능은 한 세트의 버퍼에서만 미리보기 및 비디오 인코딩과 같은 두 개의 출력을 구동하도록 하여 전력 및 메모리 소비를 줄입니다. 이 기능을 지원하려면 기기 제조업체가 카메라 HAL 및 gralloc HAL 구현이 하나의 소비자가 아닌 여러 다른 소비자(예: 하드웨어 컴포저/GPU 및 동영상 인코더)에 사용되는 gralloc 버퍼를 만들 수 있도록 해야 합니다. 카메라 서비스는 소비자 사용 플래그를 카메라 HAL 및 gralloc HAL에 전달합니다. 적절한 종류의 버퍼를 할당하거나 카메라 HAL이 이 소비자 조합이 지원되지 않는다는 오류를 반환해야 합니다.

추가 세부정보는 enableSurfaceSharing 개발자 문서를 참조하세요.

맞춤 카메라 모드용 시스템 API

공개 카메라 API는 일반 및 제한 고속 녹화의 두 가지 작동 모드를 정의합니다. 이는 매우 다른 시맨틱을 가지고 있습니다. 예를 들어 고속 모드는 한 번에 최대 2개의 특정 출력으로 제한됩니다. 다양한 OEM에서 하드웨어 관련 기능에 다른 맞춤 모드를 정의하는 데 관심을 보였습니다. 내부적으로 이 모드는 configure_streams에 전달되는 정수에 불과합니다. hardware/camera/device/3.2/ICameraDeviceSession#configurestreams를 참조하세요.

이 기능에는 OEM 카메라 앱에서 맞춤 모드를 사용 설정하기 위한 시스템 API 호출이 포함됩니다. 이러한 모드는 향후 공개 API에 추가될 모드와의 충돌을 피하기 위해 정수값 0x8000에서 시작해야 합니다.

이 기능을 지원하기 위해 OEM은 HAL에 configure_streams의 HAL로 전달된 이 정수로 트리거된 새 모드를 추가한 다음 맞춤 카메라 앱이 시스템 API를 사용하도록 하기만 하면 됩니다.

메서드 이름은 android.hardware.camera2.CameraDevice#createCustomCaptureSession입니다. frameworks/base/core/java/android/hardware/camera2/CameraDevice를 참조하세요.

onCaptureQueueEmpty

이 API의 목적은 요청 대기열을 가능한 한 비워둠으로써 확대/축소와 같은 컨트롤 변경으로 인한 지연을 줄이는 것입니다. onCaptureQueueEmpty는 HAL 작업이 필요하지 않습니다. 이는 프레임워크 측에서의 추가 작업일 뿐입니다. 이를 활용하려는 애플리케이션은 해당 콜백에 리스너를 추가하여 적절하게 응답해야 합니다. 일반적으로는 이를 위해 다른 캡처 요청을 카메라 기기로 전송합니다.

카메라 HIDL 인터페이스

카메라 HIDL 인터페이스의 경우 안정적인 HIDL 정의 API를 사용하는 카메라 HAL 인터페이스의 대대적인 개편이 이루어졌습니다. 카메라 모듈용으로 최신 기존 버전 3.4 및 2.4에 도입된 모든 기능과 카메라 기능도 HIDL 정의의 일부입니다.

3.4

지원되는 메타데이터가 소량 추가되었으며 data_space 지원에 변경사항이 있습니다.

  • RAW_OPAQUE 형식이 지원되는 경우 ANDROID_SENSOR_OPAQUE_RAW_SIZE 정적 메타데이터를 필수로 추가합니다.
  • RAW 형식이 지원되는 경우 ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE 정적 메타데이터를 필수로 추가합니다.
  • 데이터 공간 인코딩의 버전 0 정의를 사용하여 camera3_stream_t data_space 필드를 더 유연한 정의로 전환합니다.
  • HALv3.2 이상에서 사용할 수 있는 일반 메타데이터가 다음과 같이 추가되었습니다.
    • 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

확장 기능 HAL의 일부 수정사항:

  • OPAQUE 및 YUV 재처리 API 업데이트
  • 심도 출력 버퍼에 대한 기본 지원
  • camera3_stream_tdata_space 필드 추가
  • camera3_stream_t에 회전 필드 추가
  • camera3_stream_configuration_t에 camera3 스트림 설정 동작 모드 추가

3.2

확장 기능 HAL의 일부 수정사항:

  • get_metadata_vendor_tag_ops가 지원 중단됩니다. 그 대신 camera_common.hget_vendor_tag_ops를 사용합니다.
  • register_stream_buffers가 지원 중단됩니다. 프레임워크에서 process_capture_request의 HAL에 제공하는 모든 gralloc 버퍼는 언제든지 새로 추가될 수 있습니다.
  • 부분 결과 지원을 추가합니다. process_capture_result는 전체 결과가 나오기 전에 제공되는 결과의 하위 집합으로 여러 번 호출될 수 있습니다.
  • 수동 템플릿을 camera3_request_template에 추가합니다. 애플리케이션은 이 템플릿을 사용하여 캡처 설정을 직접 제어할 수 있습니다.
  • 양방향 및 입력 스트림 사양을 재작업합니다.
  • 입력 버퍼 반환 경로를 변경합니다. 버퍼는 process_capture_request 대신 process_capture_result에 반환됩니다.

3.1

확장 기능 HAL의 일부 수정사항:

  • configure_streams는 소비자 사용 플래그를 HAL에 전달합니다.
  • 진행 중인 모든 요청/버퍼를 최대한 빠르게 삭제하도록 호출을 플러시합니다.

3.0

확장 기능 HAL의 첫 번째 버전:

  • ABI가 완전히 다르므로 버전이 크게 변경되었습니다. 2.0과 비교하여 필수 하드웨어 기능 또는 작동 모델은 변경되지 않습니다.
  • 입력 요청 및 스트림 대기열 인터페이스 재작업: 프레임워크는 다음 요청 및 스트림 버퍼가 이미 대기열에서 해제된 상태에서 HAL을 호출합니다. 효율적인 구현에 필요한 동기화 프레임워크 지원이 포함됩니다.
  • 트리거를 요청으로 이동했으며 대부분의 알림을 결과로 이동했습니다.
  • 프레임워크를 통해 모든 콜백을 단일 구조로 통합했으며, 모든 설정 메서드를 단일 initialize() 호출로 통합했습니다.
  • 스트림 구성을 단일 호출로 만들어 스트림 관리를 단순화했습니다. 양방향 스트림은 STREAM_FROM_STREAM 구조체를 대체합니다.
  • 이전 하드웨어 기기 및 제한된 하드웨어 기기에서 제한 모드 시맨틱을 지원합니다.

2.0

확장 기능 HAL의 초기 릴리스(Android 4.2)[camera2.h]:

  • 기존 android.hardware.Camera API를 구현하는 데 충분합니다.
  • 카메라 서비스 계층에서 ZSL 대기열을 허용합니다.
  • 수동 캡처 제어, Bayer RAW 캡처, RAW 데이터 재처리 등의 새로운 기능은 테스트를 거치지 않았습니다.

1.0

초기 Android 카메라 HAL(Android 4.0)[camera.h]:

  • C++ CameraHardwareInterface 추상화 레이어에서 변환되었습니다.
  • android.hardware.Camera API를 지원합니다.

카메라 모듈 버전 기록

이 섹션에는 camera_module_t.common.module_api_version에 기반하여 카메라 하드웨어 모듈을 위한 버전 관리 정보가 포함되어 있습니다. 최상위 16진수 2자리는 주 버전을 나타내며, 최하위 2자리는 부 버전을 나타냅니다.

2.4

이 카메라 모듈 버전에서는 다음과 같은 API 변경사항이 추가되었습니다.

  1. 토치 모드 지원: 프레임워크는 카메라 기기를 열지 않고도 플래시 장치가 있는 카메라 기기의 토치 모드를 켤 수 있습니다. 카메라 기기는 카메라 모듈보다 플래시 장치에 더 우선적으로 액세스합니다. 카메라 기기를 열면 모듈 인터페이스를 통해 사용 설정된 토치는 사용 중지됩니다. open()이 호출되어 카메라 기기를 여는 경우와 같이 리소스 충돌이 있는 경우 카메라 HAL 모듈은 토치 모드 상태 콜백을 통해 토치 모드가 사용 중지되었음을 프레임워크에 알려야 합니다.
  2. 외장 카메라(예: USB 핫플러그 카메라) 지원: API 업데이트는 카메라가 연결되어 있고 외장 핫플러그 카메라에 사용할 준비가 되었을 때만 사용할 수 있는 카메라 정적 정보를 지정합니다. 카메라 상태가 CAMERA_DEVICE_STATUS_PRESENT가 아닌 경우 정적 정보를 얻기 위한 호출은 잘못된 호출입니다. 프레임워크는 사용 가능한 외장 카메라 목록을 관리하기 위해 기기 상태 변경 콜백에만 의존합니다.
  3. 카메라 조정 힌트: 동시에 열거나 사용할 수 있는 카메라 기기 수를 명시적으로 나타낼 수 있도록 지원을 추가합니다. 유효한 기기 조합을 지정하려면 resource_costconflicting_devices 필드가 항상 get_camera_info 호출에 의해 반환된 camera_info 구조에 설정되어야 합니다.
  4. 모듈 초기화 메서드: HAL 모듈이 로드된 후 카메라 서비스에서 호출하여 HAL을 1회 초기화할 수 있도록 허용합니다. 이는 다른 모듈 메서드가 호출되기 전에 호출됩니다.

2.3

이 카메라 모듈 버전에서는 기존 카메라 HAL 기기 열기 지원이 추가됩니다. 프레임워크는 이를 사용하여 동일한 기기가 여러 기기의 API 버전을 지원할 수 있는 경우 하위 기기 HAL 버전의 HAL 기기로 카메라 기기를 열 수 있습니다. 표준 하드웨어 모듈 열기 호출(common.methods->open)은 지원되는 최신 버전으로 카메라 기기를 계속 엽니다. 이는 camera_info_t.device_version에 나열된 버전이기도 합니다.

2.2

이 카메라 모듈 버전에서는 모듈의 제공업체 태그 지원이 추가되고, 이전에는 기기가 열린 상태에서만 액세스할 수 있었던 이전 vendor_tag_query_ops가 지원 중단됩니다.

2.1

이 카메라 모듈 버전에서는 카메라 HAL 모듈에서 프레임 워크로의 비동기식 콜백 지원이 추가됩니다. 이는 카메라 모듈 상태의 변경사항을 프레임워크에 알리는 데 사용됩니다. 유효한 set_callbacks() 메서드를 제공하는 모듈은 최소한 이 버전 번호를 보고해야 합니다.

2.0

이 버전 번호를 보고하는 카메라 모듈은 카메라 모듈 HAL 인터페이스의 두 번째 버전을 구현합니다. 이 모듈을 통해 열 수 있는 카메라 기기는 카메라 기기 HAL 인터페이스의 버전 1.0 또는 버전 2.0을 지원할 수 있습니다. camera_info의 device_version 필드는 항상 유효합니다. camera_infostatic_camera_characteristics 필드는 device_version 필드가 2.0 이상인 경우에 유효합니다.

1.0

이러한 버전 번호를 보고하는 카메라 모듈은 초기 카메라 모듈 HAL 인터페이스를 구현합니다. 이 모듈을 통해 열 수 있는 모든 카메라 기기는 카메라 기기 HAL의 버전 1만 지원합니다. camera_infodevice_versionstatic_camera_characteristics 필드는 유효하지 않습니다. android.hardware.Camera API만 이 모듈과 해당 기기에서 지원할 수 있습니다.