このページでは、Camera HAL、API、および関連する互換性テストスイート（CTS）テストのバージョンの違いについて説明します。また、カメラ フレームワークを強化し、安全性を高めるための Android 7.0 でのアーキテクチャの変更、Android 8.0 での Treble への移行、そしてカメラ実装の際にこれらの変更をサポートするためにベンダーが行うべき更新についても説明します。
用語
このページで使用される用語は次のとおりです。
- Camera API1
android.hardware.Cameraクラスで公開される、Android 4.4 以前のデバイスのアプリレベルのカメラ フレームワーク。- Camera API2
android.hardware.camera2パッケージで公開される、Android 5.0 以降のデバイスのアプリレベルのカメラ フレームワーク。- Camera HAL
- SoC ベンダーが実装するカメラ モジュール レイヤ。アプリレベルの公開フレームワークは Camera HAL 上に構築されます。
- Camera HAL3.1
- Android 4.4 でリリースされたカメラデバイス HAL のバージョン。
- Camera HAL3.2
- Android 5.0 でリリースされたカメラデバイス HAL のバージョン。
- Camera API1 CTS
- Camera API1 上で実行されるカメラ CTS テストのセット。
- Camera API2 CTS
- Camera API2 上で実行されるカメラ CTS テストの追加セット。
- 高音
- 新しいベンダー インターフェースを使用して、ベンダー実装（シリコン メーカーが作成したデバイス固有の下位レベルのソフトウェア）を Android OS フレームワークから分離します。
- HIDL
- HAL インターフェース定義言語（HAL interface definition language）の略称。Treble で導入され、HAL とユーザー間のインターフェースを指定する目的で使用されます。
- VTS
- ベンダーテスト スイート（Vendor test suite）の略称。Treble とともに導入されました。
Camera API
Android には次の Camera API が含まれます。
Camera API1
Camera API1 は Android 5.0 でサポート終了になりました。新しいプラットフォームの開発は Camera API2 が中心であり、Camera API1 は段階的に廃止されています。ただし、段階的廃止には時間がかかるため、Android リリースでは当面、Camera API1 アプリも引き続きサポートされる予定です。具体的には、次のサポートが継続されます。
- アプリ用 Camera API1 インターフェース。Camera API1 上に構築されたカメラアプリは、下位の Android リリース バージョンを実行するデバイスでの動作と同じように動作します。
- Camera HAL のバージョン。Camera HAL1.0 のサポートが含まれます。
Camera API2
Camera API2 フレームワークは、下位レベルのカメラ制御をアプリに公開します。これには、効率的なゼロコピー バーストまたはストリーミング フロー、フレームごとの露出、ゲイン、ホワイト バランス ゲイン、色変換、ノイズ除去、シャープニングの制御が含まれます。詳細については、Google I/O の動画による説明をご覧ください。
Android 5.0 以降には Camera API2 が搭載されています。ただし、Android 5.0 以降を実行しているデバイスで必ずすべての Camera API2 の機能がサポートされているわけではありません。アプリが Camera API2 インターフェースを通じてクエリできる android.info.supportedHardwareLevel プロパティは、次のいずれかのサポートレベルをレポートします。
LEGACY: このデバイスは、Camera API1 インターフェースを通じてアプリに公開される機能とほぼ同じ機能を、Camera API2 インターフェースを通じてアプリに公開します。レガシー フレームワーク コードは、Camera API2 の呼び出しを概念的に Camera API1 の呼び出しに変換します。レガシー デバイスは、フレームごとの制御などの Camera API2 の機能をサポートしていません。LIMITED: このデバイスは Camera API2 の機能の一部をサポートします。Camera HAL 3.2 以上を使用する必要があります。FULL: このデバイスは Camera API2 の主要な機能をすべてサポートします。Camera HAL 3.2 以上、および Android 5.0 以上を使用する必要があります。LEVEL_3: このデバイスは、YUV 再処理および RAW 画像キャプチャ、さらに追加の出力ストリーム構成をサポートします。EXTERNAL: このデバイスはLIMITEDデバイスに似ていますが、センサーまたはレンズの一部の情報がレポートされないことがある点、フレームレートの安定性が低いなどの点が異なります。このレベルは、USB ウェブカメラなどの外部カメラに使用されます。
個々の機能は、Camera API2 インターフェースの android.request.availableCapabilities プロパティを介して公開されます。FULL デバイスでは特に、MANUAL_SENSOR および MANUAL_POST_PROCESSING 機能が必要になります。FULL デバイスでも RAW 機能はオプションです。
LIMITED デバイスでは、Camera API2 の機能をサブセットでアドバタイズできます（機能をまったくアドバタイズしないことも可能）。ただし、BACKWARD_COMPATIBLE 機能は常に定義する必要があります。
デバイスでサポートされているハードウェア レベル、そのデバイスでサポートされている Camera API2 の特定の機能は、Google Play での Camera API2 カメラアプリのフィルタリングを可能にする次の機能フラグで確認できます。
android.hardware.camera.hardware_level.fullandroid.hardware.camera.capability.rawandroid.hardware.camera.capability.manual_sensorandroid.hardware.camera.capability.manual_post_processing
CTS の要件
Android 5.0 以降を実行しているデバイスは、Camera API1 CTS、Camera API2 CTS、および CTS Verifier カメラテストにパスする必要があります。
Camera HAL3.2 を実装しておらず、Camera API2 インターフェースをすべてサポートできないデバイスでも、Camera API2 CTS テストに合格する必要があります。ただし、デバイスが Camera API2 LEGACY モード（Camera API2 呼び出しが Camera API1 呼び出しに概念的にマッピングされる）で実行されている場合、Camera API1 以上の機能に関する Camera API2 CTS テストは自動的にスキップされます。
レガシー デバイスで Camera API2 CTS テストを実行する場合、既存の公開 Camera API1 インターフェースと機能が使用され、新しい要件は設定されません。公開されているバグ（および Camera API2 CTS テストの不合格の原因となるバグ）は、デバイスの既存の Camera HAL にすでに存在しているバグであるため、既存の Camera API1 アプリで検出されます。このようなバグは、大量には発生しません（ただし Camera API2 CTS テストに合格するには、そのようなバグを修正する必要があります）。
VTS 要件
バインダ化された HAL を実装し、Android 8.0 以降を実行するデバイスは、Camera VTS テストに合格する必要があります。
カメラ フレームワークの強化
メディア フレームワークとカメラ フレームワークのセキュリティを強化するため、Android 7.0 ではカメラサービスがメディア サーバーから分離されています。Android 8.0 以降、バインダ化された各 Camera HAL はカメラサービスとは別のプロセスで実行されています。ベンダーは、使用する API および HAL バージョンに応じて、Camera HAL を変更する必要があります。次のセクションでは、HAL1 と HAL3 における API1 と API2 のアーキテクチャ変更、および一般的な要件について詳しく説明します。
API1 のアーキテクチャ変更
API1 の動画録画は、カメラと動画エンコーダが同じプロセスに存在するとみなすことができます。HAL3 と HAL1 上で API1 アプリを実行する場合の違いを以下に示します。
- HAL3 の場合、カメラサービスは BufferQueue を使用してプロセス間でバッファを渡すため、ベンダーによる更新は不要です。
図 1.HAL3 上で API1 アプリを実行する場合の Android 7.0 カメラとメディア スタック
- HAL1 の場合、動画バッファ内でメタデータの受け渡しをサポートするため、ベンダーは HAL を更新してから
kMetadataBufferTypeNativeHandleSourceを使用する必要があります（kMetadataBufferTypeCameraSourceは Android 7.0 ではサポートされなくなりました）。
図 2.HAL1 上で API1 アプリを実行する場合の Android 7.0 カメラとメディア スタック
API2 のアーキテクチャ変更
HAL1 または HAL3 上で API2 アプリを実行する場合、どちらも BufferQueue でバッファが渡されるため、このパスは引き続き動作します。HAL1 と HAL3 で API2 アプリを実行する場合の Android 7.0 アーキテクチャの違いを以下に示します。
- HAL1 の場合、アーキテクチャはカメラサービスの移動の影響を受けず、ベンダーによる更新は不要です。
- HAL3 の場合、アーキテクチャは影響を受けますが、ベンダーによる更新は不要です。
図 3. HAL3 上で API2 アプリを実行する場合の Android 7.0 カメラとメディア スタック
追加の要件
メディア フレームワークとカメラ フレームワークのセキュリティを強化するためのアーキテクチャの変更により、次のデバイス要件が追加されています。
- 一般: デバイスでは IPC のために追加の帯域幅が必要となります。これは、高速性が求められる高速動画録画など、特定のカメラのユースケースに影響を与える可能性があります。ベンダーは、
android.hardware.camera2.cts.PerformanceTestと、Google カメラアプリで 120/240 FPS の高速動画録画を実行することにより、実際の影響を測定できます。また、新しいプロセスを作成するためにデバイスに追加の RAM が少し必要になります。 - 動画バッファのメタデータに渡す（HAL1 のみ）: HAL1 が実際の YUV フレームデータの代わりにメタデータを動画バッファに格納する場合、HAL は
kMetadataBufferTypeNativeHandleSourceをメタデータ バッファタイプとして使用し、動画バッファにVideoNativeHandleMetadataを渡す必要があります （kMetadataBufferTypeCameraSourceは Android 7.0 ではサポートされなくなりました）。VideoNativeHandleMetadataにより、カメラ フレームワークとメディア フレームワークは、ネイティブ ハンドルを適切にシリアル化およびシリアル化解除することで、プロセス間で動画バッファを渡すことができます。 - バッファ ハンドル アドレスは、常に同じバッファを格納するとは限りません（HAL3 のみ）。HAL3 は各キャプチャ リクエストでバッファ ハンドルのアドレスを受け取ります。HAL はアドレスを使用してバッファを識別することはできません。これは、HAL がバッファを返した後にそのアドレスが別のバッファ ハンドルを格納する可能性があるためです。バッファ ハンドルを使用してバッファを識別できるよう、HAL を更新する必要があります。たとえば、HAL がバッファ ハンドル A を格納するバッファ ハンドル アドレス A を受け取ります。HAL がバッファ ハンドル A を返すと、次に HAL がバッファ ハンドル A を受け取るときにはバッファ ハンドル アドレス A にはバッファ ハンドル B が格納されている可能性があります。
- カメラサーバーの SELinux ポリシーを更新する: デバイス固有の SELinux ポリシーがメディア サーバーにカメラを実行するための権限を付与する場合、カメラサーバーに適切な権限を付与するように SELinux ポリシーを更新する必要があります。カメラサーバー用にメディアサーバーの SELinux ポリシーを複製することはおすすめしません（メディアサーバーとカメラサーバーでは一般的に、システムで必要とするリソースが異なります）。カメラサーバーはカメラ機能を実行するために必要な権限のみ保持すべきであり、メディア サーバーのカメラに関連する不要な権限は削除する必要があります。
- Camera HAL とカメラサーバー間の分離: Android 8.0 以降では、カメラサーバーとバインダ化された Camera HAL のプロセスは分離されます。IPC は HIDL 定義のインターフェースを経由します。
検証
Android 7.0 を実行するカメラ搭載のすべてのデバイスで、Android 7.0 CTS を実行して実装を検証する必要があります。Android 7.0 にはカメラサービスの変更を検証するための新しい CTS テストは含まれていませんが、上記の更新を適用していない場合、既存の CTS テストは失敗します。
また、Android 8.0 を実行するカメラ搭載のデバイスでは、VTS を実行してベンダー実装を確認します。
Camera HAL バージョンの履歴
Android Camera HAL の評価に使用できるテストのリストについては、Camera HAL テスト チェックリストをご覧ください。
Android 10
Android 10 で以下のアップデートが導入されます。
Camera API
- マルチカメラの改善。これにより、個別に物理カメラを使用することも、物理カメラ ID を隠して対応する複数の論理カメラを通じて物理カメラを使用することもできるようになりました。マルチカメラ サポートをご覧ください。
- セッションを新しく作成してパフォーマンス オーバーヘッドを発生させることなく、特定のセッション設定がサポートされているかを確認するための機能。
CameraDeviceをご覧ください。 - 特定のユースケースに対して推奨されるストリーム構成を取得し、クライアントの電力効率とパフォーマンスを向上させる機能。
getRecommendedStreamConfigurationMapをご覧ください。 - 深度 JPEG 画像形式のサポート。詳細については、Dynamic Depth の指定をご覧ください。
- HEIC 画像形式のサポート。HEIF イメージングをご覧ください。
- プライバシーの改善。クライアントが
CameraCharacteristicsからCAMERA権限を取得するには、特定のキーが必要になります。getKeysNeedingPermissionをご覧ください。
Camera HAL
Android 10 では次の Camera HAL バージョンが更新されています。
3.5
ICameraDevice
-
getPhysicalCameraCharacteristics: 論理カメラデバイスに関連付けられている物理カメラ ID の静的カメラ情報。マルチカメラ サポートをご覧ください。 isStreamCombinationSupported: このメソッドは、セッション構成がサポートされているかどうかをクライアントがクエリするための公開 API をサポートします。ストリームの組み合わせをクエリするための API をご覧ください。
ICameraDeviceSession
-
isReconfigurationNeeded: 新しいセッション パラメータ値に対して、ストリームを完全に再構成する必要があるかどうかをカメラ フレームワークに伝えるためのメソッドです。これにより、不要なカメラの再構成に伴う遅延を回避できます。セッション再構成クエリをご覧ください。 - HAL buffer management API : この API により、Camera HAL はカメラ パイプライン全体で各キャプチャ リクエストとそれに関連するバッファをカップリングするのではなく、必要な場合にのみカメラ フレームワークからバッファをリクエストできるようになるため、メモリを大幅に節約できます。
-
signalStreamFlush: カメラサービスがconfigureStreams_3_5を実行しようとしていること、および HAL が指定ストリームのすべてのバッファを返す必要があることを HAL に通知します。 -
configureStreams_3_5:ICameraDevice3.4.configureStreamsに似ていますが、それに加えてconfigureStreams_3_5とsignalStreamFlushの呼び出し間の競合状態をチェックできるstreamConfigCounterカウンタを備えています。
-
ICameraDeviceCallback のアップデート:
-
requestStreamBuffers: Camera HAL がカメラサーバーにバッファを要求するために呼び出す同期コールバック。requestStreamBuffersをご覧ください。 -
returnStreamBuffers: 出力バッファをカメラサーバーに返す Camera HAL の同期コールバック。returnStreamBuffersをご覧ください。
3.4
Android 10 では、以下のキーがカメラ メタデータに追加されました。
- 画像形式
ANDROID_SCALER_AVAILABLE_FORMATS_RAW10ANDROID_SCALER_AVAILABLE_FORMATS_RAW12ANDROID_SCALER_AVAILABLE_FORMATS_Y8
- カメラ メタデータ タグ
ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSIONANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONSANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAPANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSIONANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONSANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONSANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONSANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_IDANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONSANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONSANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONSANDROID_HEIC_INFO_SUPPORTEDANDROID_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_MONOANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
- 使用可能な Dynamic Depth ストリーム構成
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUTANDROID_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
- 折りたたみなど、物理的な変更がカメラとルーティングに影響する場合に、デバイスがそのことを Camera HAL に通知するための
notifyDeviceStateChangeメソッドが追加されました。
2.4
- API レベル 29 以上で起動するデバイスは
isTorchModeSupportedに対してtrueをレポートする必要があります。
Android 9
Android 9 リリースでは、Camera API2 と HAL インターフェースに対して以下の更新が導入されました。
Camera API
- multi-camera API が導入され、同方向のカメラを複数搭載したデバイスのサポートが向上しました。これにより、ボケやシームレスなズームなどの機能が追加されました。また、デバイスの複数のカメラを 1 つの論理ユニットとして表示することも可能になりました。1 台の論理カメラとしてまとめられた個々のカメラデバイスにキャプチャ リクエストを送信できるようになりました。マルチカメラ サポートをご覧ください。
- セッション パラメータが導入されました。セッション パラメータは利用可能なキャプチャ パラメータのサブセットです。キャプチャ パラメータが変更されると、深刻な処理遅延が発生することがあります。この遅延は、キャプチャ セッションの初期化中にクライアントが初期値を渡すことで、軽減できます。セッション パラメータをご覧ください。
- アプリレベルの安定化と効果を実現するために、光学式手ぶれ補正（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をご覧ください。
Camera HAL
3.4
ICameraDeviceSession の更新は以下のとおりです。
-
configureStreams_3_4:sessionParametersおよび論理カメラのサポートが追加されました。 -
processCaptureRequest_3_4: ストリーム構造に物理カメラ ID を含めるためのサポートが追加されました。
ICameraDeviceCallback の更新は以下のとおりです。
-
processCaptureResult_3_4: キャプチャ結果に物理カメラのメタデータが追加されました。
3.3
Android 9 では、以下のキーがカメラ メタデータに追加されました。
- 機能
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERAANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKINGANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
- カメラ メタデータ タグ
ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDSANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPEANDROID_DISTORTION_CORRECTION_AVAILABLE_MODESANDROID_LENS_POSE_REFERENCE-
ANDROID_LENS_DISTORTION ANDROID_REQUEST_AVAILABLE_SESSION_KEYSANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYSANDROID_STATISTICS_OIS_DATA_MODEANDROID_STATISTICS_OIS_TIMESTAMPSANDROID_STATISTICS_OIS_X_SHIFTSANDROID_STATISTICS_OIS_Y_SHIFTS
Android 8.0
Android 8.0 リリースでは Treble が導入されました。Treble では、ベンダーの Camera HAL 実装はバインダ化されている必要があります。Android 8.0 には、カメラサービスの以下の主要な拡張機能が含まれています。
- 共有サーフェス: 複数のサーフェスで同じ
OutputConfigurationを共有できるようになりました。 - カスタム カメラモード用のシステム API
onCaptureQueueEmpty
これらの機能の詳細については、以下のセクションをご覧ください。
共有サーフェス
この機能により、単一のバッファセットで、プレビューと動画エンコーディングなどの 2 つの出力に対応できるようになり、電力とメモリの消費が削減されます。デバイス メーカーがこの機能をサポートするには、単一のコンシューマではなく、複数の異なるコンシューマ（ハードウェア コンポーザ /GPU や動画エンコーダなど）によって使用される gralloc バッファを camera HAL および gralloc HAL 実装で作成できるようにする必要があります。カメラサービスは、コンシューマの使用フラグを camera HAL および gralloc HAL に渡します。両方の HAL が適切な種類のバッファを割り当てるか、このコンシューマの組み合わせがサポートされていないことを示すエラーを camera HAL が返す必要があります。
詳細については、
enableSurfaceSharing のデベロッパー ドキュメントをご覧ください。
カスタム カメラモード用のシステム API
公開 Camera API は、通常録画または制限付き高速録画の 2 つの動作モードを定義します。この 2 つのモードのセマンティクスはかなり異なります。たとえば、高速モードでは、出力が一度に最大で 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 側での作業を必要としません。フレームワーク側で作業が追加されるだけです。アプリでこの API のメリットを活用する場合、そのコールバックをリッスンするリスナーを追加し、適切に応答する必要があります。通常、コールバックに適切に応答するには、追加のキャプチャ リクエストをカメラデバイスに送信します。
Camera HIDL インターフェース
Camera HIDL インターフェースは、Camera HAL インターフェースを全面的に見直したものであり、安定性に優れた HIDL 定義の API を使用します。最新のレガシー バージョン 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_BOOSTANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGEANDROID_SENSOR_DYNAMIC_BLACK_LEVELANDROID_SENSOR_DYNAMIC_WHITE_LEVELANDROID_SENSOR_OPAQUE_RAW_SIZEANDROID_SENSOR_OPTICAL_BLACK_REGIONS
-
3.3
拡張機能 HAL のマイナー リビジョンです。
- OPAQUE および YUV 再処理 API が更新されました。
- 深度出力バッファの基本なサポートが追加されました。
camera3_stream_tにdata_spaceフィールドが追加されました。camera3_stream_tに回転フィールドが追加されました。camera3_stream_configuration_tに camera3 ストリーム構成オペレーション モードが追加されました。
3.2
拡張機能 HAL のマイナー リビジョンです。
get_metadata_vendor_tag_opsのサポートが終了しました。代わりにcamera_common.hのget_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.CameraAPI の実装に関して十分に要件を満たします。 - カメラサービス レイヤで ZSL キューが可能になりました。
- マニュアル キャプチャ コントロール、Bayer RAW キャプチャ、RAW データの再処理など、新機能のテストは実施されていません。
1.0
初期の Android Camera HAL（Android 4.0）[camera.h] です。
- C ++ CameraHardwareInterface アブストラクション レイヤから変換されました。
android.hardware.CameraAPI をサポートします。
カメラ モジュールのバージョン履歴
このセクションには、camera_module_t.common.module_api_version に基づく、カメラ ハードウェア モジュールのモジュール バージョニング情報が掲載されています。16 進数の最上位 2 桁はメジャー バージョンを、最下位 2 桁はマイナー バージョンを表します。
2.4
このカメラ モジュールのバージョンでは、次の API の変更が適用されています。
- 懐中電灯モードのサポート。このフレームワークでは、フラッシュ ユニットを備えたカメラデバイスで、カメラデバイスを開かずに懐中電灯モードをオンにできます。カメラデバイスは、フラッシュ ユニットへのアクセスについてカメラ モジュールに優先します。フラッシュがモジュール インターフェースにより有効化されていた場合、カメラデバイスを開くとフラッシュがオフになります。
open()が呼び出されてカメラデバイスが開かれている場合など、リソースの競合が発生する場合、camera HAL モジュールは、懐中電灯モードがオフになったことを懐中電灯モード ステータスのコールバックによりフレームワークに通知する必要があります。 - 外部カメラ（USB ホットプラグ カメラなど）のサポート。この API の更新では、カメラが接続され、外部ホットプラグ カメラに対して使用する準備ができている場合にのみ、カメラの静的情報の使用を許可します。静的情報を取得する呼び出しは、カメラ ステータスが
CAMERA_DEVICE_STATUS_PRESENTであるとき以外は無効です。フレームワークはデバイス ステータスの変更に関するコールバックのみをカウントして、使用可能な外部カメラリストを管理します。 - カメラ間の調整のヒント。同時に開いて使用できるカメラデバイスの数を明示的に示すためのサポートが追加されました。デバイスの有効な組み合わせを指定するには、
get_camera_info呼び出しによって返されるcamera_infoストラクチャ内でresource_costおよびconflicting_devicesフィールドを常に設定する必要があります。 - モジュールの初期化メソッド。HAL モジュールが読み込まれて HAL の 1 回限りの初期化が許可された後、カメラサービスによって呼び出されます。初期化メソッドは他のモジュール メソッドよりも前に呼び出されます。
2.3
このカメラ モジュール バージョンでは、オープンなレガシー camera HAL デバイスのサポートが追加されました。
同じデバイスが複数デバイスの API バージョンをサポートできる場合、フレームワークはこのサポートにより、下位デバイス HAL バージョンの HAL デバイスとしてカメラデバイスを開くことができます。標準ハードウェア モジュールのオープン呼び出し（common.methods->open）は、サポート対象の最新バージョン（camera_info_t.device_version にリストされているバージョン）のカメラデバイスを引き続き開きます。
2.2
このカメラ モジュール バージョンでは、モジュールからのベンダータグのサポートが追加され、以前はデバイスを開いた状態でのみアクセスできた古い vendor_tag_query_ops のサポートが終了しました。
2.1
このカメラ モジュール バージョンでは、camera HAL モジュールからフレームワークへの非同期コールバックのサポートが追加されました。この非同期コールバックを使用することで、カメラ モジュールの状態の変更をフレームワークに通知できます。有効な set_callbacks() メソッドを提供するモジュールでは、少なくともこのバージョン番号をレポートする必要があります。
2.0
このバージョン番号をレポートするカメラ モジュールでは、2.0 バージョンのカメラ モジュール HAL インターフェースが実装されます。このモジュールで開くことができるカメラデバイスは、バージョン 1.0 またはバージョン 2.0 のいずれかのカメラデバイス HAL インターフェースをサポートします。camera_info の device_version フィールドは常に有効です。つまり、device_version フィールドが 2.0 以上の場合、camera_info の static_camera_characteristics フィールドは有効です。
1.0
このバージョン番号をレポートするカメラ モジュールでは、初期カメラ モジュール HAL インターフェースが実装されます。このモジュールで開くことができるすべてのカメラデバイスは、バージョン 1 のカメラデバイス HAL のみをサポートします。camera_info の device_version および static_camera_characteristics フィールドは有効ではありません。このモジュールとそのデバイスでサポートできるのは android.hardware.Camera API のみです。