Camera3_device_ops 構造体のリファレンス

構成ストリーム:

CAMERA_DEVICE_API_VERSION_3_0 のみ:

HAL カメラ デバイスの処理パイプラインをリセットし、新しい入力ストリームと出力ストリームをセットアップします。この呼び出しにより、既存のストリーム構成が、stream_list で定義されたストリームに置き換えられます。このメソッドは、 initialize()の後、 process_capture_request()でリクエストが送信される前に、少なくとも 1 回呼び出されます。

stream_list には、少なくとも 1 つの出力可能なストリームが含まれている必要があり、複数の入力可能なストリームを含めることはできません。

stream_list には、(configure_stream() への前回の呼び出しからの) 現在アクティブなストリームのセットにも含まれるストリームが含まれる場合があります。これらのストリームには、使用法、max_buffers、およびプライベート ポインターの有効な値がすでに含まれています。

このようなストリームに既にバッファが登録されている場合、そのストリームに対してregister_stream_buffers() が再び呼び出されることはなく、ストリームからのバッファをすぐに入力リクエストに含めることができます。

新しい構成のために HAL が既存のストリームのストリーム構成を変更する必要がある場合、configure 呼び出し中に use や max_buffers の値を書き換える可能性があります。

フレームワークはそのような変更を検出し、ストリーム バッファを再割り当てし、リクエストでそのストリームのバッファを使用する前にregister_stream_buffers()を再度呼び出します。

現在アクティブなストリームが stream_list に含まれていない場合、HAL はそのストリームへの参照を安全に削除できます。これはフレームワークによる後のconfigure()呼び出しでは再利用されず、 configure_streams()呼び出しが戻った後にすべてのgrallocバッファが解放されます。

stream_list 構造はフレームワークによって所有されており、この呼び出しが完了するとアクセスできなくなる場合があります。個々の Camera3_stream_t 構造体のアドレスは、stream_list 引数に Camera3_stream_t が含まれなくなる最初の configure_stream() 呼び出しが終了するまで、HAL によるアクセスに対して有効なままになります。 HAL は、 configure_streams()呼び出し自体中の使用法および max_buffers メンバーを除き、プライベート ポインターの外側のストリーム構造内の値を変更することはできません。

ストリームが新しい場合、ストリーム構造の使用状況、max_buffer、およびプライベート ポインター フィールドはすべて 0 に設定されます。HAL デバイスは、configure_streams()呼び出しが戻る前にこれらのフィールドを設定する必要があります。これらのフィールドは、フレームワークとプラットフォームの gralloc モジュールによって使用され、各ストリームに gralloc バッファーを割り当てます。

このような新しいストリームのバッファーをキャプチャ リクエストに含める前に、フレームワークはそのストリームでregister_stream_buffers()を呼び出します。ただし、フレームワークは、リクエストを送信する前にすべてのストリームのバッファを登録する必要はありません。これにより、(たとえば) プレビュー ストリームを迅速に開始し、他のストリームへの割り当てを後からまたは同時に行うことができます。

CAMERA_DEVICE_API_VERSION_3_1 のみ:

HAL カメラ デバイスの処理パイプラインをリセットし、新しい入力ストリームと出力ストリームをセットアップします。この呼び出しにより、既存のストリーム構成が、stream_list で定義されたストリームに置き換えられます。このメソッドは、 initialize()の後、 process_capture_request()でリクエストが送信される前に、少なくとも 1 回呼び出されます。

stream_list には、少なくとも 1 つの出力可能なストリームが含まれている必要があり、複数の入力可能なストリームを含めることはできません。

stream_list には、(configure_stream() への前回の呼び出しからの) 現在アクティブなストリームのセットにも含まれるストリームが含まれる場合があります。これらのストリームには、使用法、max_buffers、およびプライベート ポインターの有効な値がすでに含まれています。

このようなストリームに既にバッファが登録されている場合、そのストリームに対してregister_stream_buffers() が再び呼び出されることはなく、ストリームからのバッファをすぐに入力リクエストに含めることができます。

新しい構成のために HAL が既存のストリームのストリーム構成を変更する必要がある場合、configure 呼び出し中に use や max_buffers の値を書き換える可能性があります。

フレームワークはそのような変更を検出し、ストリーム バッファを再割り当てし、リクエストでそのストリームのバッファを使用する前にregister_stream_buffers()を再度呼び出します。

現在アクティブなストリームが stream_list に含まれていない場合、HAL はそのストリームへの参照を安全に削除できます。これはフレームワークによる後のconfigure()呼び出しでは再利用されず、 configure_streams()呼び出しが戻った後にすべてのgrallocバッファが解放されます。

stream_list 構造はフレームワークによって所有されており、この呼び出しが完了するとアクセスできなくなる場合があります。個々の Camera3_stream_t 構造体のアドレスは、stream_list 引数に Camera3_stream_t が含まれなくなる最初の configure_stream() 呼び出しが終了するまで、HAL によるアクセスに対して有効なままになります。 HAL は、 configure_streams()呼び出し自体中の使用法および max_buffers メンバーを除き、プライベート ポインターの外側のストリーム構造内の値を変更することはできません。

ストリームが新しい場合、ストリーム構造の max_buffer およびプライベート ポインタ フィールドはすべて 0 に設定されます。使用法はコンシューマ使用法フラグに設定されます。 HAL デバイスは、 configure_streams()呼び出しが戻る前に、これらのフィールドを設定する必要があります。これらのフィールドは、フレームワークとプラットフォームの gralloc モジュールによって使用され、各ストリームに gralloc バッファーを割り当てます。

このような新しいストリームのバッファーをキャプチャ リクエストに含める前に、フレームワークはそのストリームでregister_stream_buffers()を呼び出します。ただし、フレームワークは、リクエストを送信する前にすべてのストリームのバッファを登録する必要はありません。これにより、(たとえば) プレビュー ストリームを迅速に開始し、他のストリームへの割り当てを後からまたは同時に行うことができます。

>= CAMERA_DEVICE_API_VERSION_3_2:

HAL カメラ デバイスの処理パイプラインをリセットし、新しい入力ストリームと出力ストリームをセットアップします。この呼び出しにより、既存のストリーム構成が、stream_list で定義されたストリームに置き換えられます。このメソッドは、 initialize()の後、 process_capture_request()でリクエストが送信される前に、少なくとも 1 回呼び出されます。

stream_list には、少なくとも 1 つの出力可能なストリームが含まれている必要があり、複数の入力可能なストリームを含めることはできません。

stream_list には、(configure_stream() への前回の呼び出しからの) 現在アクティブなストリームのセットにも含まれるストリームが含まれる場合があります。これらのストリームには、使用法、max_buffers、およびプライベート ポインターの有効な値がすでに含まれています。

新しい構成のために HAL が既存のストリームのストリーム構成を変更する必要がある場合、configure 呼び出し中に use や max_buffers の値を書き換える可能性があります。

フレームワークはそのような変更を検出し、リクエストでそのストリームのバッファを使用する前に、ストリーム バッファを再割り当てすることがあります。

現在アクティブなストリームが stream_list に含まれていない場合、HAL はそのストリームへの参照を安全に削除できます。これはフレームワークによる後のconfigure()呼び出しでは再利用されず、 configure_streams()呼び出しが戻った後にすべてのgrallocバッファが解放されます。

stream_list 構造はフレームワークによって所有されており、この呼び出しが完了するとアクセスできなくなる場合があります。個々の Camera3_stream_t 構造体のアドレスは、stream_list 引数に Camera3_stream_t が含まれなくなる最初の configure_stream() 呼び出しが終了するまで、HAL によるアクセスに対して有効なままになります。 HAL は、 configure_streams()呼び出し自体中の使用法および max_buffers メンバーを除き、プライベート ポインターの外側のストリーム構造内の値を変更することはできません。

ストリームが新しい場合、ストリーム構造の max_buffer およびプライベート ポインタ フィールドはすべて 0 に設定されます。使用法はコンシューマ使用法フラグに設定されます。 HAL デバイスは、 configure_streams()呼び出しが戻る前に、これらのフィールドを設定する必要があります。これらのフィールドは、フレームワークとプラットフォームの gralloc モジュールによって使用され、各ストリームに gralloc バッファーを割り当てます。

新しく割り当てられたバッファは、フレームワークによっていつでもキャプチャ リクエストに含めることができます。 process_capture_result を使用して gralloc バッファがフレームワークに返されると (そして、それぞれの release_fence が通知されると)、フレームワークはいつでもそれを解放または再利用できます。

前提条件:

フレームワークは、キャプチャが処理されていない場合にのみこのメソッドを呼び出します。つまり、すべての結果がフレームワークに返され、すべての実行中の入力および出力バッファーが返され、その解放同期フェンスが HAL によって通知されています。フレームワークは、 configure_streams()呼び出しの進行中は、新しいキャプチャ要求を送信しません。

事後条件:

HAL デバイスは、カメラ デバイスの静的メタデータに記載されているように、出力ストリームのサイズと形式を考慮して、可能な最大出力フレーム レートを提供するように自身を構成する必要があります。

性能要件：

この呼び出しは負荷が高く、イメージ センサーとカメラ処理パイプラインのリセットと再構成が必要になる可能性があるため、完了までに数百ミリ秒かかる可能性があります。それにもかかわらず、HAL デバイスは、アプリケーションの動作モード変更 (静止画キャプチャからビデオ録画への切り替えなど) 中にユーザーに見える一時停止を最小限に抑えるために、再構成の遅延を最小限に抑えるように努める必要があります。

HAL はこの呼び出しから 500 ミリ秒以内に戻り、この呼び出しから 1000 ミリ秒以内に戻る必要があります。

戻り値:

0: ストリーム設定が成功したとき

-EINVAL: 要求されたストリーム構成が無効な場合。無効なストリーム構成の例としては、次のようなものがあります。

• 複数の入力可能なストリーム (INPUT または BIDIRECTIONAL) を含む
• 出力可能なストリーム (OUTPUT または BIDIRECTIONAL) は含まれません。
• サポートされていない形式、またはその形式でサポートされていないサイズのストリームが含まれています。
• 特定の形式の出力ストリームが多すぎます。
• サポートされていないローテーション構成 (バージョン >= CAMERA_DEVICE_API_VERSION_3_3 のデバイスにのみ適用されます)
• ストリームのサイズ/形式が非 NORMAL モードの Camera3_stream_configuration_t->operation_mode 要件を満たしていないか、要求された Operation_mode が HAL でサポートされていません。 (バージョン >= CAMERA_DEVICE_API_VERSION_3_3 のデバイスにのみ適用されます)

ストリーム構成は構成前にチェックされるため、無効なストリーム構成を送信するフレームワークは通常の動作ではないことに注意してください。無効な構成は、フレームワーク コードにバグが存在するか、HAL の静的メタデータとストリームの要件の間に不一致があることを意味します。

-ENODEV: 致命的なエラーが発生し、デバイスが動作しなくなった場合。このエラーが返された後、フレームワークによって正常に呼び出せるのは close() のみです。

ファイルCamera3.hの2769行目の定義。

構築_デフォルト_リクエスト_設定:

標準的なカメラの使用例に合わせてキャプチャ設定を作成します。

デバイスは、要求されたユースケースを満たすように構成された設定バッファーを返す必要があります。これは、CAMERA3_TEMPLATE_* 列挙型の 1 つである必要があります。すべてのリクエスト制御フィールドを含める必要があります。

HAL はこの構造体の所有権を保持しますが、構造体へのポインタはデバイスが閉じられるまで有効でなければなりません。フレームワークと HAL は、この呼び出しによってバッファーが返された後は、バッファーを変更できません。同じテンプレートまたは他のテンプレートに対する後続の呼び出しに対して、同じバッファが返される場合があります。

性能要件：

これはノンブロッキング呼び出しである必要があります。 HAL はこの呼び出しから 1 ミリ秒以内に戻り、この呼び出しから 5 ミリ秒以内に戻る必要があります。

戻り値:

有効なメタデータ: デフォルト設定バッファーの作成が成功したとき。

NULL: 致命的なエラーの場合。これが返された後、フレームワークは close() メソッドのみを正常に呼び出すことができます。

ファイルCamera3.hの2859行目の定義。

ごみ：

カメラデバイスのデバッグ状態を出力します。これは、カメラ サービスがデバッグ ダンプを要求されたとき (dumpsys ツールを使用するとき、またはバグレポートをキャプチャするときに発生します) にフレームワークによって呼び出されます。

渡されたファイル記述子は、dprintf() または write() を使用してデバッグ テキストを書き込むために使用できます。テキストは ASCII エンコードのみである必要があります。

性能要件：

これはノンブロッキング呼び出しである必要があります。 HAL はこの呼び出しから 1 ミリ秒以内に戻る必要があり、この呼び出しからは 10 ミリ秒以内に戻る必要があります。この呼び出しはカメラ操作中のどの時点でも呼び出される可能性があるため、デッドロックを回避する必要があります。使用される同期プリミティブ (ミューテックス ロックやセマフォなど) は、タイムアウトを指定して取得する必要があります。

ファイルCamera3.hの2971行目の定義。

流す：

指定されたデバイス上のパイプライン内の現在処理中のすべてのキャプチャとすべてのバッファをフラッシュします。フレームワークはこれを使用して、すべての状態をできるだけ早くダンプし、 configure_streams()呼び出しの準備をします。

バッファが正常に返される必要はないため、 flush()の時点で保持されているすべてのバッファ (正常に埋められたかどうかに関係なく) は CAMERA3_BUFFER_STATUS_ERROR で返される場合があります。バッファが正常に埋められていれば、HAL はこの呼び出し中に有効な (CAMERA3_BUFFER_STATUS_OK) バッファを返すことができることに注意してください。

現在 HAL 内にあるすべてのリクエストは、できるだけ早く返されることが期待されます。処理中のリクエストはすぐにエラーを返す必要があります。割り込み可能なハードウェア ブロックは停止し、割り込み不可能なブロックは待機する必要があります。

flash()は、 process_capture_request()と同時に呼び出すことができます。これは、 process_capture_request がすぐに戻り、その process_capture_request 呼び出しで送信されたリクエストが他のすべての実行中のリクエストと同様に扱われることを期待しています。同時実行性の問題により、HAL の観点からは、フラッシュが呼び出されてもまだ戻っていない後にprocess_capture_request()呼び出しが開始される可能性があります。このような呼び出しが、 flush()が返される前に発生した場合、HAL は新しいキャプチャ リクエストを他の処理中の保留中のリクエストと同様に扱う必要があります (下記 #4 を参照)。

より具体的には、HAL はさまざまな場合に応じて以下の要件に従う必要があります。

1. HAL がキャンセル/停止するには遅すぎるキャプチャの場合、HAL によって正常に完了します。つまり、HAL は通常どおりシャッター/通知、process_capture_result、およびバッファーを送信できます。
2. 何も処理を行っていない保留中のリクエストの場合、HAL は、notify CAMERA3_MSG_ERROR_REQUEST を呼び出し、エラー状態 (CAMERA3_BUFFER_STATUS_ERROR) の process_capture_result を持つすべての出力バッファを返す必要があります。 HAL はリリース フェンスをエラー状態にしてはなりません。代わりに、リリース フェンスをフレームワークによって渡された取得フェンスに設定するか、すでに HAL によって待機されている場合は -1 に設定する必要があります。これは、HAL が CAMERA3_MSG_SHUTTER を使用してnotify() をすでに呼び出しているが、メタデータ/有効なバッファを生成しないキャプチャに対してたどるパスでもあります。 CAMERA3_MSG_ERROR_REQUEST の後は、特定のフレームに対して、CAMERA3_BUFFER_STATUS_ERROR 内のバッファーを持つ process_capture_results のみが許可されます。それ以上の通知や、null 以外のメタデータを含む process_capture_result は許可されません。

3. すべての出力バッファーがないか、メタデータが欠落している可能性がある、部分的に完了した保留中のリクエストの場合、HAL は以下に従う必要があります。

   3.1.予期される結果メタデータの一部 (つまり、1 つ以上の部分メタデータ) がキャプチャに使用できない場合は、CAMERA3_MSG_ERROR_RESULT で通知を呼び出します。

   3.2.キャプチャ用に生成されないバッファごとに、CAMERA3_MSG_ERROR_BUFFER を指定して notification を呼び出します。

   3.3 process_capture_result でバッファ/メタデータが返される前に、キャプチャ タイムスタンプを指定して CAMERA3_MSG_SHUTTER で Notice を呼び出します。

   3.4 何らかの結果が生成されるキャプチャの場合、完全な失敗を示すため、HAL は CAMERA3_MSG_ERROR_REQUEST を呼び出してはなりません。

   3.5.有効なバッファ/メタデータは通常どおりフレームワークに渡される必要があります。

   3.6.失敗したバッファは、ケース 2 で説明したようにフレームワークに返される必要があります。ただし、失敗したバッファは、有効なバッファの厳密な順序に従う必要はなく、有効なバッファに関して順序が狂っている場合があります。たとえば、バッファ A、B、C、D、E が送信され、D と E が失敗した場合、A、E、B、D、C は許容可能な戻り順序になります。

   3.7.メタデータが完全に欠落している場合は、CAMERA3_MSG_ERROR_RESULT を呼び出すだけで十分です。NULL メタデータまたは同等のものを指定して process_capture_result を呼び出す必要はありません。

4. process_capture_request () の呼び出しがアクティブなときにフラッシュ()が呼び出された場合、そのプロセス呼び出しはできるだけ早く返される必要があります。さらに、 flush( ) が呼び出された後、 flush()が戻る前にprocess_capture_request () 呼び出しが行われた場合、遅い process_capture_request 呼び出しによって提供されたキャプチャ リクエストは、上記のケース #2 の保留中のリクエストのように扱われる必要があります。

flash() は、 HAL 内に未処理のバッファまたはリクエストが残っていない場合にのみ返される必要があります。フレームワークは、configure_streams を呼び出すか (HAL 状態が静止しているため)、新しいリクエストを発行することがあります。

完全に成功した場合と完全に失敗した結果のケースのみをサポートするだけで十分であることに注意してください。ただし、フラッシュ呼び出しの全体的なパフォーマンスの向上に役立つ可能性があるため、部分的な失敗のケースもサポートすることが非常に望ましいです。

性能要件：

HAL はこの呼び出しから 100 ミリ秒以内に戻り、この呼び出しから 1000 ミリ秒以内に戻る必要があります。また、この呼び出しはパイプライン レイテンシーを超えてブロックされてはなりません (定義については S7 を参照)。

バージョン情報：

デバイスのバージョン >= CAMERA_DEVICE_API_VERSION_3_1 の場合にのみ使用できます。

戻り値:

0: カメラ HAL のフラッシュが成功したとき。

-EINVAL: 入力の形式が不正な場合 (デバイスが無効な場合)。

-ENODEV: カメラ デバイスで重大なエラーが発生した場合。このエラーが返された後、フレームワークは close() メソッドのみを正常に呼び出すことができます。

ファイルCamera3.hの3077行目の定義。

get_metadata_vendor_tag_ops:

ベンダー拡張メタデータ タグ情報をクエリするためのメソッドを取得します。 HAL は、ベンダー タグの操作メソッドをすべて入力するか、ベンダー タグが定義されていない場合は操作を変更しないままにしておく必要があります。

vendor_tag_query_ops_t の定義は、system/media/camera/include/system/camera_metadata.h にあります。

>= CAMERA_DEVICE_API_VERSION_3_2: 非推奨。この関数は非推奨になっているため、HAL によって NULL に設定する必要があります。代わりに、 camera_common.hに get_vendor_tag_ops を実装してください。

ファイルCamera3.hの2950行目の定義。

初期化:

フレームワーク コールバック関数ポインターを HAL に渡すための 1 回限りの初期化。 open() 呼び出しが成功した後、 camera3_device_ops構造体で他の関数が呼び出される前に 1 回呼び出されます。

性能要件：

これはノンブロッキング呼び出しである必要があります。 HAL はこの呼び出しから 5 ミリ秒以内に戻り、この呼び出しから 10 ミリ秒以内に戻る必要があります。

戻り値:

0: 初期化が成功したとき

-ENODEV: 初期化が失敗した場合。この後、フレームワークによって正常に呼び出せるのは close() のみです。

ファイルCamera3.hの2530行目の定義。

プロセスキャプチャリクエスト:

新しいキャプチャ リクエストを HAL に送信します。 HAL は、処理する次のリクエストを受け入れる準備ができるまで、この呼び出しから戻ってはなりません。 process_capture_request()への呼び出しはフレームワークによって一度に 1 つだけ行われ、呼び出しはすべて同じスレッドから行われます。新しいリクエストとそれに関連するバッファが利用可能になるとすぐに、 process_capture_request()への次の呼び出しが行われます。通常のプレビュー シナリオでは、これは、関数がほぼ即座にフレームワークによって再度呼び出されることを意味します。

実際のリクエスト処理は非同期であり、キャプチャの結果は process_capture_result() 呼び出しを通じて HAL によって返されます。この呼び出しでは、結果のメタデータが利用可能であることが必要ですが、出力バッファーは待機する同期フェンスを提供するだけで済みます。最大の出力フレーム レートを維持するために、複数のリクエストが同時に処理されることが予想されます。

フレームワークはリクエスト構造の所有権を保持します。この呼び出しの間のみ有効であることが保証されます。 HAL デバイスは、キャプチャ処理のために保持する必要がある情報のコピーを作成する必要があります。 HAL はバッファのフェンスを待機して閉じ、バッファ ハンドルをフレームワークに返す責任があります。

input_buffer が NULL でない場合、HAL は入力バッファのリリース同期フェンスのファイル記述子を input_buffer->release_fence に書き込む必要があります。 HAL が入力バッファー解放同期フェンスに対して -1 を返した場合、フレームワークは入力バッファーをすぐに自由に再利用できます。それ以外の場合、フレームワークは入力バッファを再充填して再利用する前に同期フェンスで待機します。

>= CAMERA_DEVICE_API_VERSION_3_2:

各リクエストでフレームワークによって提供される入力/出力バッファは、まったく新しいものである可能性があります (HAL がこれまで見たことのないもの)。

パフォーマンスに関する考慮事項:

新しいバッファの処理は非常に軽量である必要があり、フレーム レートの低下やフレーム ジッターが発生しないようにする必要があります。

この呼び出しは、特にストリーミングの場合 (後処理品質設定が FAST に設定されている場合)、要求されたフレーム レートを維持できるように十分な速度で返される必要があります。 HAL はこの呼び出しを 1 フレーム間隔で返し、この呼び出しから 4 フレーム間隔で戻る必要があります。

戻り値:

0: キャプチャ リクエストの処理が正常に開始されたとき

-EINVAL: 入力が不正な場合 (許可されていない場合に設定が NULL である、出力バッファーが 0 であるなど)、キャプチャ処理を開始できません。リクエスト処理中の失敗は、 Camera3_callback_ops_t.notify()を呼び出して処理する必要があります。このエラーが発生した場合、フレームワークはストリーム バッファーのフェンスとバッファー ハンドルに対する責任を保持します。 HAL はフェンスを閉じたり、process_capture_result でこれらのバッファを返したりすべきではありません。

-ENODEV: カメラ デバイスで重大なエラーが発生した場合。このエラーが返された後、フレームワークは close() メソッドのみを正常に呼び出すことができます。

ファイルCamera3.hの2928行目の定義。

register_stream_buffers:

>= CAMERA_DEVICE_API_VERSION_3_2:

非推奨。これは呼び出されないため、NULL に設定する必要があります。

<= CAMERA_DEVICE_API_VERSION_3_1:

特定のストリームのバッファを HAL デバイスに登録します。このメソッドは、configure_streams によって新しいストリームが定義された後、そのストリームからのバッファがキャプチャ リクエストに含まれる前に、フレームワークによって呼び出されます。同じストリームが後続のconfigure_streams()呼び出しにリストされている場合、そのストリームに対して register_stream_buffers が再び呼び出されることはありません。

フレームワークは、最初のキャプチャ リクエストを送信する前に、構成されたすべてのストリームのバッファを登録する必要はありません。これにより、他のストリームが割り当てられている間でも、プレビュー (または同様の使用例) を迅速に起動できます。

このメソッドは、HAL デバイスが後で使用するためにバッファをマッピングまたは準備できるようにすることを目的としています。渡されたバッファは使用のためにすでにロックされています。呼び出しの終了時には、すべてのバッファをストリームに返す準備ができている必要があります。 buffer_set 引数は、この呼び出しの間のみ有効です。

ストリーム形式が HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED に設定されている場合、カメラ HAL はここで渡されたバッファを検査して、プラットフォームのプライベート ピクセル形式情報を判断する必要があります。

性能要件：

これはノンブロッキング呼び出しである必要があります。 HAL はこの呼び出しから 1 ミリ秒以内に戻り、この呼び出しから 5 ミリ秒以内に戻る必要があります。

戻り値:

0: 新しいストリーム バッファの登録が成功したとき

-EINVAL: stream_buffer_set が有効なアクティブ ストリームを参照していない場合、またはバッファ配列が無効な場合。

-ENOMEM: バッファの登録に失敗した場合。フレームワークは、すべてのストリーム バッファーが登録解除されていると見なす必要があり、後で再度登録を試みることができます。

-ENODEV: 致命的なエラーが発生し、デバイスが動作しなくなった場合。このエラーが返された後、フレームワークによって正常に呼び出せるのは close() のみです。

ファイルCamera3.hの2823行目の定義。

ファイルCamera3.hの3080行目の定義。